JEPs proposed to target JDK 9 (2016/10/19)
vitalyd at gmail.com
Wed Oct 19 22:11:41 UTC 2016
On Wednesday, October 19, 2016, Vladimir Kozlov <vladimir.kozlov at oracle.com>
> Sorry, David, I don't understand what do you mean under "set of known
> entry points into the code" and "change the set".
I think David must be talking about stripping the binary to just the set of
methods known to be used - think of internal linkage, like static functions
in C which may just get inlined and aren't present in the binary. So in
Java AOT, closest parallel would be a private method but of course that's
callable at runtime, so I don't see how AOT can just omit it entirely.
> AOT compiler is not JIT compiler. It is static compiler (similar to javac)
> which loads specified classes and compiles their methods *without*
> executing these methods (in most cases). It does execute class initializer
> <clinit> but we may address that in a future to avoid side effects. There
> are also methods which are executed by Graal.
> AOT also records fingerprint (checksum) calculated during class loading to
> make sure that aot methods are used for the same class when application is
> run. As result if class redefinition or other methods change class
> corresponding aot methods will be not used anymore.
> On 10/19/16 12:39 PM, David M. Lloyd wrote:
>> On 10/19/2016 12:14 PM, mark.reinhold at oracle.com wrote:
>>> 295: Ahead-of-Time Compilation
>> I have a question on this one - maybe it's best addressed specifically
>> to John Rose though, and please forgive my relatively shallow
>> understanding of the JIT and this new AOT compiler.
>> Does the AOT compiler depend on knowing all possible entry points into
>> certain methods? Is it possible for things like --add-exports with
>> reflection, which change the set of known entry points into the code, to
>> cause unexpected operation? I saw no mention of these things on the JEP
>> page but it was my understanding that AOT compilation depends on this
>> kind of information.
Sent from my phone
More information about the jdk9-dev