[9] RFR(L) 8166413: Integrate VM part of AOT changes

Coleen Phillimore coleen.phillimore at oracle.com
Tue Nov 1 01:35:21 UTC 2016

I looked at the runtime code and it looks fine to me.  I'm pleased the 
changes were not more invasive.   Some minor questions and nits:


*+ virtual void set_to_interpreted(methodHandle method, CompiledICInfo& 
info) {*

Can you pass methodHandle by const reference so that the copy 
constructor and destructor aren't called?


Why does this add a Method* pointer for #ifndef AOT code?   This could 
be a lot of additional footprint.


Why are the AOT parameters in two separate sections?  The intx ones 
should be defined with a valid range.


Why is this added and the SA code fixed?  AOT doesn't use the SA, does 
it?  Was it added for debugging?


On 10/26/16 9:15 PM, Vladimir Kozlov wrote:
> https://bugs.openjdk.java.net/browse/JDK-8166089
> Subtask:
> https://bugs.openjdk.java.net/browse/JDK-8166415
> Webrev:
> http://cr.openjdk.java.net/~kvn/aot/hs.webrev/
> Please, review Hotspot VM part of AOT changes.
> Only Linux/x64 platform is supported. 'jaotc' and AOT part of Hotspot 
> will be build only on Linux/x64.
> AOT code is NOT linked during AOT libraries load as it happens with 
> normal .so libraries. AOT code entry points are not exposed (not 
> global) in AOT libraries. Only class data has global labels which we 
> look for with dlsym(klass_name).
> AOT-compiled code in AOT libraries is treated by JVM as *extension* of 
> existing CodeCache. When a java class is loaded JVM looks if 
> corresponding AOT-compiled methods exist in loaded AOT libraries and 
> add links to them from java methods descriptors (we have new field 
> Method::_aot_code). AOT-compiled code follows the same 
> invocation/deoptimization/unloading rules as normal JIT-compiled code.
> Calls in AOT code use the same methods resolution runtime code as 
> calls in JITed code. The difference is call's destination address is 
> loaded indirectly because we can't patch AOT code - it is immutable 
> (to share between multiple JVM instances).
> Classes and Strings referenced in AOT code are resolved lazily by 
> calling into runtime. All mutable pointers (oops (mostly strings), 
> metadata) are stored and modified in a separate mutable memory (GOT 
> cells) - they are not embedded into AOT code.
> Changes includes klass fingerprint generation since we need it to find 
> correct klass data in loaded AOT libraries.
> Thanks,
> Vladimir

More information about the hotspot-dev mailing list