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" <golov...@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
