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

[Coleen Phillimore]

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:

http://cr.openjdk.java.net/~kvn/aot/hs.webrev/src/share/vm/code/nmethod.cpp.udiff.html

*+ 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?

http://cr.openjdk.java.net/~kvn/aot/hs.webrev/src/share/vm/oops/methodCounters.hpp.udiff.html

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

http://cr.openjdk.java.net/~kvn/aot/hs.webrev/src/share/vm/runtime/globals.hpp.udiff.html

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

http://cr.openjdk.java.net/~kvn/aot/hs.webrev/src/share/vm/runtime/vmStructs.cpp.udiff.html

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

Thanks,
Colee

On 10/26/16 9:15 PM, Vladimir Kozlov wrote:
> 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