JEPs proposed to target JDK 9 (2016/10/19)
Vitaly Davidovich
vitalyd at gmail.com
Wed Oct 19 22:35:06 UTC 2016
Also, do you envision giving users ability to influence AOT decisions? For
instance, force inlining, unlikely/likely branch hints, etc - basically
similar (but likely a lot narrower) to what you have for C and C++
compilers?
On Wednesday, October 19, 2016, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>
> On Wednesday, October 19, 2016, John Rose <john.r.rose at oracle.com
> <javascript:_e(%7B%7D,'cvml','john.r.rose at oracle.com');>> wrote:
>
>> On Oct 19, 2016, at 3:11 PM, Vitaly Davidovich <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.
>
> 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)?
>
>>
>> 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
More information about the jdk9-dev
mailing list