JEPs proposed to target JDK 9 (2016/10/19)

[Vladimir Kozlov]

I added some clarification to JEP description to avoid possible misunderstanding.

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

Regards,
Vladimir

On 10/19/16 3:51 PM, Vladimir Kozlov wrote:
> On 10/19/16 3:31 PM, Vitaly Davidovich wrote:
>>
>>
>> On Wednesday, October 19, 2016, John Rose <john.r.rose at oracle.com
>> <mailto:john.r.rose at oracle.com>> wrote:
>>
>>     On Oct 19, 2016, at 3:11 PM, Vitaly Davidovich <vitalyd at gmail.com
>>     <javascript:_e(%7B%7D,'cvml','vitalyd at gmail.com');>> wrote:
>>>
>>>     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 supports deoptimization and re-JIT-ing, so it would be easy to
>>     omit methods from AOT output, and just use interpreter or JIT to
>>     handle the execution.
>>
>> This would have to be opt-in, I'd imagine, as otherwise it would defeat
>> the purpose of AOT.  Or it would have to very limited where it does this.
>
> re-JIT-ing (generating profiling code in AOT methods) is triggered by --compile-for-tiered flag. By default is off.
> But AOT code is following the same deoptimization rules as normal JITed code. For example, class unloading or redefinition.
>
>>
>> Separately, what optimizations (if any) will be done in AOT? Clearly
>> there's no profiling info, which is where the big gains typically come
>> from, but will anything be done? For example, are loops optimized
>> (unrolled, unswitched, etc)? Are statically known (at AOT time) callees
>> inlined? Or is it basically C1 level of optimization (i.e. very minimal)?
>
> Currently it is C1 level only or even less - based on CHA without profiling information. We may add profiling information feedback in a future.
> No C2 type loop optimizations - Graal-core does some but not all.
> Also in tiered mode AOT code contains profiling code similar to Tiered level 3 in current Tiered compilation.
> AOT code is immutable - have to do indirect klass loads and calls.
> Also klass loading in AOT code is lazy - it has dynamic checks for class loading.
>
> In short - do not expect good peak performance from current AOT code. That is why we added --compile-for-tiered to re-JIT to get peak performance.
>
> We bet on compiled static initializers and skipping Interpreter for startup improvement.
>
> Vladimir
>
>>
>>
>>     AOT could do stuff like tree shaking (static call graph
>>     minimization) or enforcement of strong encapsulation, but it doesn't
>>     yet.  It's early days for this technology.
>>
>>
>>     — John
>>
>>
>>
>> --
>> Sent from my phone