Higher values would further increase the whining about how much space Java uses.

It would be nice to be able to give the gc a hint at run time to the effect that you were about to allocate ~40MB of data. In effect to override the -Xms value. I have code that allocates several hundred megabytes of data and the run time is very dependent on the minimum heap size. I understand that there are difficulties changing the maximum heap size at runtime, but surely changing the minimum size is much easier.

I'd have one heap which managed texture VRAM which would be separate to the ordinary heap, for starters. Rather than allocating memory, it only has to track memory allocation. Subtle.

More enterprising and clever folk than I would probably use multiple heaps for application separation within a single VM, which would allow some seriously useful tuning of serverside applications of course. But this is a games forum and no-one cares about that except Blah^3 and Jeff

I can guess an answer to my own remark about the initial allocations being small. It's to encourage multiple small garbage collections in eden space, so there's no long pauses in an application during the early stages of its execution.

The JVM will adjust itself to deal with larger size applications during execution. On Windows, the young space can increase to 5 MB and tenured to as much as 47 MB (I'm not sure on that last number).

---As regards having multiple heaps and garbage collectors, that's already (sort of) done by using a generational heap structure, and different collectors for the young and old parts.

----I'm on shakey ground here, but aren't textures passed over to OpenGL, and therefore beyondthe reach of Java and any heap management scheme? In fact, any data managed by DLLs is outside of Java's control, and not counted as part of its heap.

It seems like the various heap settings (and a lot more) are accessible, by using the JConsole tool in J2SE 5. JConsole gets its data from managed beans (MBeans) which monitor and manage various parts of the JVM. It's possible to write your own MBeans. There's an article on JConsole at http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html.

It's one of the top 5 things that professional C++ games devs in mainstream games industry cite as "things I'd need to be able to seriously develop games in java on console". IIRC, reasoning is that an awful lof of modern games mem management is ... odd ... yet entirely predictable - textures are the most obvious example. It's relatively easy to do coarse-grained mem-management at the heap level, directed by the scenegraph and/or loading of new levels (load new level => throw away your level-geometry-heap) that is more effective than a general-purpose heap manager would be, yet cost very little in programmer time.

Not that I ever sent you my collated list of such things ( I need to cull down some 20 odd pages of conversations and anonymize all speakers ), but off the top of my head the other major ones included:

- ability to load an entire serialized chain of game-data (hundreds of megabytes) directly into memory, raw direct from disk, and use it immediately with no post-processing (console CPU's are slow. Console DVD-read performance is poor)

More enterprising and clever folk than I would probably use multiple heaps for application separation within a single VM, which would allow some seriously useful tuning of serverside applications of course. But this is a games forum and no-one cares about that except Blah^3 and Jeff

Cas

Can you *imagine* how easy it would be to find + fix memory leaks if I could have a "grexengine heap", a "3rd party modules heap", a "JDBC driver heap" etc?

Blah^3 hti it on the head - having multiple heaps would simplify things where you need large blocks of data for various purposes. I would love to allocate a block for a levels data and objects then throw it all away when done. We basically do the same thing with vertex array data now using nio and indexes into the data, but so much more could be done if we could choose to allocate objects in different memory heaps. As it is now, memory leaks in Java games are very easy to create and hard to isolate because of mixing and matching nio data with non-nio objects. Given that garbage collection/simplified memory management is supposed to be a selling point of Java for gaming, in practice it's not.

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