Which optimizations does Hotspot apply?

[Remi Forax]

On 01/24/2014 11:01 PM, Vitaly Davidovich wrote:
> This would be predicated on escape analysis, whose effectiveness is in turn
> driven by sufficient inlining whereby compiler can see that instance
> doesn't escape.  Inlining, in turn, can be screwed up by (amongst other
> things) polymorphic call sites.  So in the end, it's all quite brittle and
> sensitive :).  Personally, in places where it matters, I try to allocate as
> little as possible explicitly - a lot of times much more effective than
> hoping compiler helps out and/or turning GC knobs.
>
> Sent from my phone

Hi Andrej,
if you see a lot of instances of ArrayList iterator it means that you 
have a code path that create an iterator and use it later and the JIT is 
not able to see the creation and the use in the same inlining horizon. 
As Vitaly said, it's perhaps because you have the same code called with 
several different kinds of List (teach your programmer to stop to use 
LinkedList :) or because the code create an Iterator too far from where 
you use it (by example if the iterator is stored in a List or a Map).

If you use -XX:+PrintInlining, the VM will print the reason why 
something is not inlined.

cheers,
Rémi


> On Jan 24, 2014 4:36 PM, "Andrej Golovnin" <golovnin at gmx.net> wrote:
>
>> Hi Rémi,
>>
>>> With latest jdk8, it's not true anymore.
>>> (and most of the time the iterator object is not created anymore at
>> least with jdk7+).
>>
>> Could you please explain it a little bit more? When is that optimization
>> applied,
>> e.g. what conditions are required for this optimization, since which
>> version
>> of JDK/Hotspot it is supported, where it is implemented in JDK?
>>
>> When I take look at a product I'm working on, I see a lot instances of
>> ArrayList$Itr objects,
>> which are created by for-each loops (we use JDK 7u51).
>>
>> Thanks in advance!
>>
>> Best regards,
>> Andrej Golovnin
>>
>>
>>