What are the Default Heap Sizes?

Performance Tuning
#1

Dear All,

Does anyone know the default settings for the various heap spaces when using the 5.0 hotspot client on Windows XP?

For example, when I run an application using java with no additional options, what are the initial, default sizes for the eden space, tenured space, permanent space, and the new and survivor ratios?

I’ve found partial information for the server JVM on 32-bit Solaris, but almost nothing for other platforms.

This sort of information should be part of the java tool documentation, or be accessible as Property values.

  • Andrew
#2

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//vm/globals.hpp (or c1_globals_.hpp

#3

+1 for making the current values for these things accessible via a runtime property.

#4

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
#5

As they are suspiciously computery numbers, they would appear to simply be a random shot in the dark that mostly works for most apps.

Cas :slight_smile:

#6

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.

#7

Nicely put :slight_smile:

Kev

#8

I have always wished Java had the ability to specify multiple heaps, at runtime, with individual garbage collectors. Ah well. Maybe in Java 50 :smiley:

Cas :slight_smile:

#9

What would you do with multiple heaps?

#10

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 :slight_smile:

Cas :slight_smile:

#11

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 beyond
the 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.

  • Andrew
#12

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
#13

FYI: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6233917

This bug will be fixed in beta.

Thanks,
Dmitri
Java2D Team

#14

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 :frowning: ), 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? :wink:

#15

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.

#16

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.