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