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

[Vladimir Kozlov]

Thank you, Volker

I will integrate ppc and s390 changes after I merge jdk9/hs into AOT repo.
And I will look on .hgignore.

I use 'hg import --no-commit AOT.patch' command to apply patches.

Thanks,
Vladimir

On 10/27/16 9:42 AM, Volker Simonis wrote:
> Hi,
>
> first of all I had some problems importing the patch from the webrev
> because of this sequence:
>
> --- old/./.hgignore       2016-10-26 14:56:22.000000000 -0700
> +++ new/./.hgignore       2016-10-26 14:56:22.000000000 -0700
> @@ -24,3 +24,19 @@
>   ^test/compiler/jvmci/\w[\w\.]*/.*\.iml
>   ^test/compiler/jvmci/\w[\w\.]*/nbproject
>
> The error (when using hg qpush -v) was:
>
> applying 8166413_AOT.patch
> path './.hgignore' is inside nested repo '.'
> committing changelog
> patch failed, rejects left in working directory
> errors during apply, please fix and qrefresh 8166413_AOT.patch
>
> I don't know how it was generated, but I could easily fix it by
> replacing the above sequence by:
>
> --- old/.hgignore       2016-10-26 14:56:22.000000000 -0700
> +++ new/.hgignore       2016-10-26 14:56:22.000000000 -0700
>
>
> Besides that, it would be great if you could integrate the followinf
> ppc/s390 specific changes which are required to keep the corresponding
>   ports building:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2016/8166413_ppc_s390_addon/
>
> Thanks,
> Volker
>
>
> On Thu, Oct 27, 2016 at 3:15 AM, Vladimir Kozlov
> <vladimir.kozlov at oracle.com> 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