Long collection times (Perm/Static heap)

Is there anything that can be done about the long collection times caused by having large numbers of objects in the VM?

Basically, if I have 10 million live objects in the VM, the garbage collection takes forever, because it’s scanning all of those objects. I know that these 10 million objects are going to live a very long time - they’re essentially static data - so if there were some way for me to indicate that they should go directly into some special heap (static heap?) that only gets examined very rarely (perhaps a scan can be specifically requested), then the garbage collection times would go back down to nothing.

As it is now, the only way to work around this is to represent those objects as primitive values, on or off the Java heap.

Azeem, can you respond to this?

God bless,
-Toby Reyelts

I’m not a GC expert at all, but I asked a GC guy, and one thing you could do is speed up the moving of objects from new space to old space. Use the flags -XX:InitialTenuringThreshold=1 -XX:MaxTenuringThreshold=1. Of course you’ll have other issues because you’ll be putting other objects that would have stayed in new space over to old space. There are pause times to worry about, and other issues.

Do you really need to keep 10 million objects live? Can’t you create them when you need them, even if they live for a long time, just don’t create them all at once?

[quote]I’m not a GC expert at all, but I asked a GC guy
[/quote]
Thanks.

[quote]and one thing you could do is speed up the moving of objects from new space to old space. Use the flags -XX:InitialTenuringThreshold=1 -XX:MaxTenuringThreshold=1. Of course you’ll have other issues because you’ll be putting other objects that would have stayed in new space over to old space. There are pause times to worry about, and other issues.
[/quote]
The problem isn’t the objects being in new space. They all end up in tenured space pretty fast. When a full collection runs (which happens fairly often), the collector scans all the objects in the tenured space, which takes forever. 99.9% of those objects in tenured space won’t ever need to be collected.

[quote]Do you really need to keep 10 million objects live? Can’t you create them when you need them, even if they live for a long time, just don’t create them all at once?
[/quote]
Yes, I need all of those objects. They belong to large data sets like road networks, spatial indices, etc… Those data structures get created at load time and are never released. What I want is an additional memory space, beyond tenured, that those objects can be placed in, where they will rarely or never be scanned.

God bless,
-Toby Reyelts

Hmmm well from what I’ve been told, unfortunetly there isn’t much we can do. You might try one of the other collectors, but I think they’re all the same in this respect. Like I said before, definitly not a GC expert. Sorry

Sounds like what you need is either Structs (ie. lightweight objects), or a way to utilise different heaps with different collection characteristics, along the lines of

HugeRoadStructureThing x = new HugeRoadStructureThing() in UncollectedHeap;

Cas :slight_smile:

Right - like Real Time Java.

Node node = ImmortalMemory.instance().newInstance( Node.class );

God bless,
-Toby Reyelts

My solution to this was to put all these big structures in a separate process that was started with a suitable initial size for the heap. Then it is just a matter of keeping the amount of gc subsequently needed by this process reasonably low.

[quote]Then it is just a matter of keeping the amount of gc subsequently needed by this process reasonably low.
[/quote]
Sure, if you can avoid running any algorithms on those data structures that would generate garbage in the tenured heap. That’s not been my experience.

God bless,
-Toby Reyelts

It doesn’t avoid the problem altogether, but does reduce it by not having to contend with garbage generated by unrelated activities. Also many of the algorithms I use on such structures either generate very little garbage or generate short lived garbage which doesn’t trouble us. What causes trouble is creating large volumes of objects which live long enough to migrate out of the nursery area(s).