Escape Analysis and Stack Allocation (original) (raw)

Aaron Grunthal aaron.grunthal at infinite-source.de
Sun Jan 26 12:26:19 PST 2014

There also is an issue with merge points [1] which prevents objects in loops with an accumulator (e.g. reduce operations on streams) to stack-allocate the intermediate values.

[1] https://bugs.openjdk.java.net/browse/JDK-6853701

On 26.01.2014 07:04, Benedict Elliott Smith wrote:

Hi,

I was digging into some (to me) unexpected behaviour of escape analysis, namely that some references that clearly weren't escaping, and easily determined to be so, were not being stack allocated. So, after some digging through the hotspot code, I discovered some things that were probably obvious to everyone on this list, but also some things I'm still a little perplexed about. I was hoping somebody could enlighten me about the latter. 1) I cannot see a reason why stores to a primitive array, for instance, should cause the argument to escape in bcEscapeAnalyser.cpp iterateoneblock(); most interestingly, a store to an object array does not result in this, which seems incongruous; 2) An object array store does however result in setglobalescape() for the value being stored, which makes sense, except that this should only be setmethodescape(), as per the paper, in the case where the target array is one of the method arguments. This seems to be missing, here and for putfield. Some other weird ones are arraylength, getfield, ifnonnull, etc. The fact that these all result in setmethodescape(), and that putfieldand aastore don't optimise setglobalescape() to *setmethodescape()*where possible, seem to point to the conclusion that *isargstack / setmethodescape()* actually encode only !isscalarreplaceable. Is this the case? If so, why the confusing name?*

Which leads to a much trickier but more interesting question, which is: what are the barriers to performing actual stack allocation of full objects, instead of scalar replacement? It is something I would be keen to investigate, but given my lack of familiarity with the codebase, it would be immensely helpful to hear what the major difficulties / showstoppers might be before trying to attack it. Thanks in advance, Benedict *I do note that in escape.cpp ArgEscape is defined and is explicitly overloaded to include some of the characteristics of isscalarreplaceable. However the isargstack() method is commented with "The given argument escapes the callee, but does not become globally reachable." which seems to correspond to ArgEscape in the paper, but only invoke() seems to follow the spec, when invoking a method that cannot be analysed, and this would also be true for !isscalarreplaceable.

More information about the hotspot-dev mailing list