RFR(L) 8166413: Integrate VM part of AOT changes
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&
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:
> AOT JEP:
> 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.
More information about the hotspot-dev