Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (808)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (872)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Did the Java designers just not care?  (Read 17578 times)
0 Members and 1 Guest are viewing this topic.
Offline ags1

JGO Kernel


Medals: 367
Projects: 7


Make code not war!


« Posted 2015-06-02 19:53:33 »

Why does the Java foreach construction get compiled to an iterator loop and not just to a for(int i = 0;i < list.size(); i++) {}.

It seems to me the iterator implmentation is a classically lazy heap spammer. I just remembered to get rid of the foreach loops from my AABB code, but why do I need to do this? If the old Java 1 index increment loop is technically better and the end user syntax is the same either way, why does Java go the iterator() route?

Offline BurntPizza

« JGO Bitwise Duke »


Medals: 486
Exp: 7 years



« Reply #1 - Posted 2015-06-02 19:54:29 »

So that you can foreach on any Iterable. (also arrays, but that's a special case)
Offline ags1

JGO Kernel


Medals: 367
Projects: 7


Make code not war!


« Reply #2 - Posted 2015-06-02 20:09:06 »

But for most cases I can do the index incrementor style... they didn't need to apply the worst case scenario to ALL iterations.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #3 - Posted 2015-06-02 20:09:46 »

My experience with the Hotspot compiler for about a year or so, is that the Iterable is completely removed. There is no object on the heap, it's turned into local variables (native stack) and/or held completely in registers. They will show up in some profilers as objects on the heap, but that's because these profilers inject bytecode that prevents the stack allocation optimisation. If you loop through nested loops of loops of loops backed by iterables, you'll see no garbage is created. I think it's safe to say that Iterables from the Collections API, in foreach-loops, are now almost guaranteed to be entirely optimized away.

Predictable stack allocation of arbitrary types is on the horizon. Value types are approaching the same problem from another angle, but the support will greatly enhance stack allocation optimisations.

Yadda. Yadda.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline theagentd
« Reply #4 - Posted 2015-06-02 20:42:35 »

That sounds nice. How close is this to our daily lives? And at what Java version is the Iterable guaranteed to be gone? 8?

Myomyomyo.
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #5 - Posted 2015-06-02 21:23:12 »

i dont trust it and rather loop it backwards.
for( int i = list.size() ; i-- != 0 ; ) list.elements[i].; 


for native arrays i always use iterable, but i dont see how this would work with any custom collection. would be interesting to know how hotspot detects the default java collections. Huh
Offline theagentd
« Reply #6 - Posted 2015-06-03 01:15:56 »

would be interesting to know how hotspot detects the default java collections. Huh
It doesn't. It just uses escape analysis to realize that the Iterator it creates can't leak (it's probably the most trivial case in the world since it's even hidden from the user). Then it can just allocate the Iterator on the stack instead of on the heap by simply dumping the local variables of the Iterator on the stack, like Riven said.

Myomyomyo.
Offline KevinWorkman

« JGO Plugged Duke »


Medals: 288
Projects: 12
Exp: 12 years


HappyCoding.io - Coding Tutorials!


« Reply #7 - Posted 2015-06-03 12:53:33 »

BurntPizza already covered it, but let me expand: how would your "index foreach" work on data structures that have no concept of indexes? How would they work on a Set, for example? What about data structures where get(index) is much less efficient than an iterator, such as linked lists?

The Iterator approach allows us to "foreach" over custom classes just by implementing Iterable. With your approach, we'd have to implement a get(index), which doesn't make sense for every (or even most?) data structures.

Besides that, nothing is forcing you to use the "enhanced for" shortcut. If you really need to iterate over your data structure by index, then you can still do that.

I assure you that the developers of Java have put more thought into this than any of us have. What exactly are you saying is the downside? What profiling have you done? What is the alternative?

To get a better understanding of the considerations that go into these kinds of decisions, I recommend Program Development in Java by Barbara Liskov, or really any of the books she's written on API design, abstraction, and substitutability.

HappyCoding.io - Coding Tutorials!
Happy Coding forum - Come say hello!
Offline noctarius

JGO Knight


Medals: 61


Manager Developer Relations @Hazelcast


« Reply #8 - Posted 2015-06-03 18:29:56 »

My experience with the Hotspot compiler for about a year or so, is that the Iterable is completely removed. There is no object on the heap, it's turned into local variables (native stack) and/or held completely in registers. They will show up in some profilers as objects on the heap, but that's because these profilers inject bytecode that prevents the stack allocation optimisation. If you loop through nested loops of loops of loops backed by iterables, you'll see no garbage is created. I think it's safe to say that Iterables from the Collections API, in foreach-loops, are now almost guaranteed to be entirely optimized away.

Predictable stack allocation of arbitrary types is on the horizon. Value types are approaching the same problem from another angle, but the support will greatly enhance stack allocation optimisations.

Yadda. Yadda.

Absolutely right, however Hotspot still uses an Iterator on LinkedLists and similar data structures - and it makes sense. The optimization, btw, only applies to internal types because those optimizations are based on knowledge about the class. They are also completely Hotspot specific, IBM for example (with the J9 JVM) calls toArray and uses and index based loop.

The best thing actually (when on Java 8+) use internal iterations using Collection::forEach and it is up to the implementation of the collection to select the best iteration strategy. It also looks cleaner, easier to read and is way less boilerplate to write Smiley

Pages: [1]
  ignore  |  Print  
 
 

 
Riven (847 views)
2019-09-04 15:33:17

hadezbladez (5791 views)
2018-11-16 13:46:03

hadezbladez (2603 views)
2018-11-16 13:41:33

hadezbladez (6207 views)
2018-11-16 13:35:35

hadezbladez (1499 views)
2018-11-16 13:32:03

EgonOlsen (4734 views)
2018-06-10 19:43:48

EgonOlsen (5792 views)
2018-06-10 19:43:44

EgonOlsen (3276 views)
2018-06-10 19:43:20

DesertCoockie (4175 views)
2018-05-13 18:23:11

nelsongames (5501 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!