Escape analysis for objects with injected fields

[Doug Simon @ Oracle]

Upon further investigation, it seems as though HotSpot could not (currently) crash due to this issue as I believe it will never escape analyze objects with injected fields as such objects are either created in native code (e.g., java.lang.Class) or always escape (e.g., java.lang.ClassLoader) along any code path where the injected fields are used or traced by GC. Since Graal performs partial escape analysis, we are not so lucky ;-)

Given this context, I'm not sure it's possible to come up with a test case. My recommendation for now would be to add an check in the compiler(s) to prevent performing EA for such objects.

-Doug

On Nov 9, 2012, at 12:51 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> You are right, we are lucky :)
> 
> File bug, add a test case and I will fix it.
> 
> Thanks,
> Vladimir
> 
> Doug Simon @ Oracle wrote:
>> While debugging a deoptimization issue in Graal[1], I (painfully) learnt of the importance of field ordering in the relationship between escape analyzed (EA) objects and deoptimization. In particular, the values in the DebugInfo for an EA'ed object must correspond with the field order returned by Klass::do_nonstatic_fields(). However, that latter function does not include internal/injected fields such as the 'loader_data' and 'dependencies' fields injected into java.lang.ClassLoader instances. So, my question is what happens when such an object is EA'ed and rematerialized during deoptimization? As far as I can tell, these fields will be left uninitialized. At least, I cannot see any code in c1 or c2 (e.g., line 704 of [2]) that omits such objects from EA.
>> Am I missing something or is HotSpot just getting lucky by never determining that such objects are worthy of EA?
>> -Doug
>> [1] http://openjdk.java.net/projects/graal/
>> [2] http://hg.openjdk.java.net/hsx/hsx25/hotspot/raw-file/8e47bac5643a/src/share/vm/opto/macro.cpp