GC dynamic generation resizing

Does anyone know if the young/old/permanent heap sections are dynamically resized during the life of an application ? By resizing I mean something different than ramp-up to the correct size, or increase/decrease as the whole heap changes in size.

I've been reading gc tuning docs and it seems like once the size of the young generation is determined, either via Max/NewSize or NewRatio its size does not change anymore (under ParallelGC). Hopefully I'm missing something.

For an application which generates large numbers of short lived objects for a long period of time (pretty common memory usage) and a tiny fraction of them make it to the old generation it seems optimal to start with a large young generation (say 80% of heap) and then shrink it down (say 30% of heap) as more an more room is needed in the old generation.

If dynamic generation resizing is not possible then I think there is some serious resource wasting caused by the memory management system. The reason being that there is plenty of memory sitting idle in the old generation which could be better utilized in the young generation. Since smaller young generations result in more, in this case unnecessary, minor collections CPU cycles and application time are wasted.

Thanks

Ledion Bitincka

[1306 byte] By [Lediona] at [2007-11-27 5:31:59]
# 1

The spaces inside the young gen (eden, from and to) are dynamically and adaptively resized by default to meet the specified pause and/or thoughtput goals. If you want the VM to adaptively move the boundary between the old and young gen, please try specifying -XX:+UseAdaptiveGCBoundary option (that's for ParallelGC). It's turned off by default.

Igor Veresov, HotSpot GC

ihva at 2007-7-12 14:57:41 > top of Java-index,Java HotSpot Virtual Machine,HotSpot Internals...
# 2

Thanks for the reply Igor.

However even with that option turned on the young generation size seems to hit the wall around 270MB with heap size fixed ~2.4GB. The option you mentioned is not documented in any of the sun's docs (that I could find) so can you elaborate on other options that work with this options for example, what's the effect of NewRatio or MaxNewSize when adaptive boundaries are used ?

Ledion Bitincka

Lediona at 2007-7-12 14:57:41 > top of Java-index,Java HotSpot Virtual Machine,HotSpot Internals...
# 3

I think NewRatio and NewSize will set the initial size of the young gen, while MaxNewSize will set the limit for the young gen size. By default the VM will set them to some reasonable values depending on a machine.

If you really want to know more about numerous undocumented tuning options you would probably want to look into the globals.hpp file in the hotspot source.

Igor Veresov, Hotspot GC

ihva at 2007-7-12 14:57:41 > top of Java-index,Java HotSpot Virtual Machine,HotSpot Internals...
# 4

Thanks again Igor. Finally I was able to get the generations to resize after setting NewSize to a large chunk of the whole heap, 2GB out of 2.4GB . The young generation started shrinking when the old generation was full. However, to my surprise, the application runs slower in this configuration. I'm not sure whether the slowdown comes from the GC generation resizing or the lose of locality of scope.

Thanks again

Ledion Bitincka

Lediona at 2007-7-12 14:57:41 > top of Java-index,Java HotSpot Virtual Machine,HotSpot Internals...
# 5

Hi,

my observation is that resizing of generations has a heavy impact on garbage collection times. Since we have very high "low pause" requirements, we therefore only work with fixed generation sizes. Other than the garbage collection pause times I didn't observe any performance penalties from dynamic generation sizes, though.

Young garbage collection times also depend on the number of surviving objects. If with the new configuration more objects survive a collection cycle than before, you may see longer pause times. Other than that a larger young generation is usually beneficial for throughput.

Nick.

nicolasmichaela at 2007-7-12 14:57:41 > top of Java-index,Java HotSpot Virtual Machine,HotSpot Internals...
# 6

Yes, there are more objects that survive as the application runs longer and longer - however the rate of "garbage generation" is virtually constant. As I understand it, the adaptive sizing of the generations is supposed to make better use of idle resources (in my case memory sitting idle in the tenured generation.

Going through the GC options again I think that -XX:+AlwaysTenure (or MaxTenuringThreshold) could achieve the same goal - using otherwise idle tenured space to store young object.

Any thoughts on how adaptive generation resizing differs from this ?

Ledion Bitincka

Lediona at 2007-7-12 14:57:41 > top of Java-index,Java HotSpot Virtual Machine,HotSpot Internals...