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

[Vitaly Davidovich]

Thanks Vladimir, those are helpful clarifications.

On Wednesday, October 26, 2016, Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

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

-- 
Sent from my phone