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

[Volker Simonis]

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