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

[Vladimir Kozlov]

Thank you, Coleen

On 10/31/16 6:35 PM, Coleen Phillimore wrote:
>
> 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?

It was original declaration for CompiledStaticCall::set_to_interpreted():
http://hg.openjdk.java.net/jdk9/hs/hotspot/file/031e87605d21/src/share/vm/code/compiledIC.hpp#l300

But your suggestion is good - I implemented it:

set_to_interpreted(const methodHandle& method,

I also have the same change for set_to_far().

>
> 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.

Good catch. Put under $if INCLUDE_AOT.

> 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.

We think Tiered compilation flags should be together. I added missing 
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?

Yes, AOT does not use SA. It is for debugging of core files to correctly 
calculate size of instanceKlass structure - it depends on presence of 
fingerprint field:
+//    [EMBEDDED fingerprint] only if should_store_fingerprint()==true

Ioi added that for klass fingerprint code which is part of hotspot AOT 
changes:

https://bugs.openjdk.java.net/browse/JDK-8165142

Thanks,
Vladimir

>
> 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
>