Hi all,Well I am quite happy to report that after exhaustive testing, my team is adopted ArrayLists from the java.util/Collections APIs for container functionality in final core game engine classes.

Previous testing on several Collection classes has shown less than please results WRT performance, class size and extraneous garbage collection.

It seems 1.4.2 gc is really handling Collection issues well, so well in fact that we are slowly adopting in more as we see fit. With this adoption, Java 1.5 will also be able to take advantage of the new "for" syntax and run-time benefits.

For us, this is a significant change, as in the past we have publicly "denounced" the Collections APIs in PRODUCTION level game code. For tools and prototyping fine, but high performance, very controlled per frame code, no. With the latest VM (on Windows at least), we can found ArrayLists to be of production level quality when needing a growable/dynamic sized list.

Last years GDC presentation on this topic yielded some interesting (heated) floor discussion about Collections and GCing. In the end, we still did not endorse them. However, this year we will endorse a growing sub-set as testing progresses.

For many of you, this probably means squat as you either didn't care, or were already convinced on using Collections. :-) For those who weren't (read C game developers reviewing Java) our position is that it is now an option.

Nice to hear Now I'm just curious about how the GC and optimizer will perform for primitive collections that use the auto-boxing feature in Java 1.5.

Can, and will, the optimizer make these an alternative to custom-written primitive collections for performance-critical code, or will the boxing/unboxing slow things down too much? Anyone know how well the C# VM optimizes these?

Well, obviously not - it's got to construct an object on the heap somewhere, where it might linger awhile and end up fragmenting memory a bit, and later on it'll have to garbage collect it at some point. None of which is entirely cost-free, as an int is. It'll all come down to the nitty-gritty fine detail, as usual...

Let me get this straight. If I plan to convert my game to multiplayer and have numerous client threads access a "list" of sectors/rooms/whateva, I should use Collections.synchronizedList() to store my list of objects that I will loop through for sending data to clients?

Yes. Collections.synchronizedList() will prevent the list from being corrupted when more than one thread is using it. But you would also need additional synchronization to prevent the list from changing while you are iterating it.

Nice to hear Now I'm just curious about how the GC and optimizer will perform for primitive collections that use the auto-boxing feature in Java 1.5.

Can, and will, the optimizer make these an alternative to custom-written primitive collections for performance-critical code, or will the boxing/unboxing slow things down too much? Anyone know how well the C# VM optimizes these?

Isn't this and the casting feature they are adding simply going to be dirty compiler tricks instead of at runtime?

Isn't this and the casting feature they are adding simply going to be dirty compiler tricks instead of at runtime?

The techniques will be performed at compile time, yes. That's perfectly appropriate for eliminating casts since the only benefits you get from generics are clearer code and compile-time type safety. At least Sun's VM has optimized away the cost of casts in all the apps I have benchmarked, so performance isn't an issue there.

I also don't know of any runtime optimization specificly for autoboxing objects (which is why I asked about it). The object creation optimizations (like generational garbage collection) that Hotspot uses seem to apply to all object allocations, so I can't see any good reason to break backwards compatability and make autoboxing a part of the VM.

Yes. Collections.synchronizedList() will prevent the list from being corrupted when more than one thread is using it. But you would also need additional synchronization to prevent the list from changing while you are iterating it.

I find a lot of the time I can just get rid of the synchronized collection because of this extra synchronization that must be added anyway for keeping the list constant while iterating over it.

I the add/remove methods I call have to use this 'additional' synchronization anyway, so what good is the synchronization that is built-in? It's redundant.

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