4 ms·

Also for(Foo x : y) will allocate iterators on some JVM implementations which will nail you on the GC.

_old_dude_ 9y ago
It's not on some JVM implementations, to be able to remove the Iterator creation, the VM requires the call to y.iterator() to be either monomorphic or bimorphic. Hence the advice "Keep Things Monomorphic or Bimorphic" !
- jnordwick 9y ago
  Even if it inline the iteration creation and calls, then hoist and remove the allocation, you're likely to see suboptimal instructions. On hot paths, I often find it better to just avoid iterators in the first place than trying to clean up the mess later.
  - _old_dude_ 9y ago
    yes, the Iterator protocol of Java is sub-optimal - hasNext() has to be called twice so you hope the VM will kick the common sub expression elimination which i have found works well only if you do not do any side effect in hasNext. - and most of the Iterator are fail fast so the code has to check that the modCount of the collection has not changed. but from my own experience, you usually do not have to optimize that far, removing that 'synchronized' block, is far more common.
hyperpape 9y ago
Is this really a consideration outside of cases where someone is tuning their system so that it never does garbage collection?
- vvanders 9y ago
  Very much so, I see this all the time in production Android code. Someone throws in an iterator like this in an onDraw() and now your super-fast code is hitting a GC pause every hundred ms or so.
  - _old_dude_ 9y ago
    Android do not use a real JIT (no inlining) so it's mostly an AOT, and removing the Iterator allocation require to know the real class of the iterator. I'm not a pro of Android, so i wonder if the AOT system of Android (ART) has an option to provide a profile like you can do with gcc. It seems a better idea than to have to rewrite all the codes, third party codes included.
reader_1000 9y ago
Escape analysis should handle this [1], but I don't know if it does all the time. Reliably profiling this is hard, I guess. http://psy-lob-saw.blogspot.com.tr/2014/12/the-escape-of-arraylistiterator.html http://psy-lob-saw.blogspot.com.tr/2014/12/the-escape-of-arr...

It's not on some JVM implementations, to be able to remove the Iterator creation, the VM requires the call to y.iterator() to be either monomorphic or bimorphic. Hence the advice "Keep Things Monomorphic or Bimorphic" !

jnordwick 9y ago
Even if it inline the iteration creation and calls, then hoist and remove the allocation, you're likely to see suboptimal instructions. On hot paths, I often find it better to just avoid iterators in the first place than trying to clean up the mess later.
- _old_dude_ 9y ago
  yes, the Iterator protocol of Java is sub-optimal - hasNext() has to be called twice so you hope the VM will kick the common sub expression elimination which i have found works well only if you do not do any side effect in hasNext. - and most of the Iterator are fail fast so the code has to check that the modCount of the collection has not changed. but from my own experience, you usually do not have to optimize that far, removing that 'synchronized' block, is far more common.

hyperpape 9y ago

Is this really a consideration outside of cases where someone is tuning their system so that it never does garbage collection?

vvanders 9y ago
Very much so, I see this all the time in production Android code. Someone throws in an iterator like this in an onDraw() and now your super-fast code is hitting a GC pause every hundred ms or so.
- _old_dude_ 9y ago
  Android do not use a real JIT (no inlining) so it's mostly an AOT, and removing the Iterator allocation require to know the real class of the iterator. I'm not a pro of Android, so i wonder if the AOT system of Android (ART) has an option to provide a profile like you can do with gcc. It seems a better idea than to have to rewrite all the codes, third party codes included.

reader_1000 9y ago

Escape analysis should handle this [1], but I don't know if it does all the time. Reliably profiling this is hard, I guess. http://psy-lob-saw.blogspot.com.tr/2014/12/the-escape-of-arraylistiterator.html http://psy-lob-saw.blogspot.com.tr/2014/12/the-escape-of-arr...