Its different based on hardware architecture, OS, and compiler but here are some general numbers:

X86:
MaxHeapSize= 64m
NewSize = 640k
PermSize = 12m
MaxPermSize = 64m

You can look up most of this info in the source code, its all in src/share/vm/runtime/globals.hpp and src/cpu/<arch>/vm/globals.hpp (or c1_globals_<arch>.hpp

Thanks for the numbers, which are surprising.

If the young generation starts at 640 KB, then this means that the tenured space starts at only 5 MB (assuming  the NewRatio is 8 ).That's a low starting value.

Also, eden space will be only 512 KB, since the survivor spaces are 64KB; more small defaults.

Are there any reasons for choosing these numbers?

- Andrew

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 have always wished Java had the ability to specify multiple heaps, at runtime, with individual garbage collectors. Ah well. Maybe in Java 50


Cas

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

Cas

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.

- Andrew

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)


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?

One way to implement multiple heaps might be to make use of JSR 121 (Isolates).
http://www.jcp.org/en/jsr/detail?id=121

Each isolate would have its own heap which is discarded when the isolate completes.