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

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Oct 27 01:15:34 UTC 2016


AOT JEP:
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