4

I have a fairly unique Java service I'm working on that has a working set in the order of 50-100 GBs. Within the service I have a very complicated object graph. The vast majority of these objects live for the entirety of the process lifecycle and will never be collected.

Currently I have garbage collection times of around 10 seconds for the old generation heap. I'm wondering if there's any way to exclude these objects to speed up the performance of my garbage collection?

Kellen
  • 621
  • 1
  • 5
  • 15
  • You have extremely limited control of garbage collection. But one very strong piece of control you have is that you can prevent garbage collection by persisting an accessible hard reference to any object you don't want collected – Kon Aug 10 '15 at 15:55
  • 1
    Short answer, no. But most JVMs implement _generational_ garbage collection: Older objects get migrated to heaps that are GCd less frequently and, if they live long enough, maybe to a "permanent" space that is never GCd. – Solomon Slow Aug 10 '15 at 16:08
  • 1
    related - http://ehcache.org/ – ZhongYu Aug 10 '15 at 16:34
  • If GC pauses are your problem, are you sure you have exhausted available GC tuning options? – the8472 Aug 11 '15 at 04:55
  • We're looking into tuning GC G1 to mitigate our pauses, but it seems unnecessary given that we know that by design 95% of our heap will never be collected. Thanks for the responses, looks like our two options are tuning GC G1 and packing our data structure into a large sequential array of some kind. We'll look at both options. – Kellen Aug 11 '15 at 08:38

5 Answers5

1

The only way I can think of to would be to reduce the number of Objects in the heap. You may be able to achieve this by taking direct control of the graph. Perhaps allocate yourself a chunk of memory as a large int[] and allocate/free space in there. Could you post some code that demonstrates the structure of the nodes in your graph? Perhaps we could give more concrete suggestions.

OldCurmudgeon
  • 64,482
  • 16
  • 119
  • 213
1

You may want to take a look at some caching solutions which utilize off-heap data store:

The on-heap store refers to objects that will be present in the Java heap (and also subject to GC). On the other hand, the off-heap store refers to (serialized) objects that are managed by EHCache, but stored outside the heap (and also not subject to GC). As the off-heap store continues to be managed in memory, it is slightly slower than the on-heap store, but still faster than the disk store.

Community
  • 1
  • 1
Dragan Bozanovic
  • 23,102
  • 5
  • 43
  • 110
1

If you just want primitive data outside the heap then direct byte buffers should do the job.

Serializing/deserializing on-heap objects to/from native memory is also what many off-heap storage libraries do.

But they might not really be necessary with the right collector choice. CMS does not move tenured objects and can just skip large primitive arrays, so even very large heaps shouldn't incur much extra GC costs as long as they are mostly filled with primitive arrays and if you manage to tune your GC to avoid concurrent mode failures.

If you want full-blown objects outside the grasp of the garbage collector, then there is jillegal.

As its name and documentation suggests it reaches deep into VM internals and comes with a lot of caveats/forward compatibility problems.

Only use it if you feel doing open heart surgery next to a pool of sharks is the most reasonable solution to your problem.

the8472
  • 40,999
  • 5
  • 70
  • 122
0

Invert the logic, and put the graph in a separately running database. And then operate with more volatile queries. Whether this must be a graph database depends (- the commercial Neo4J?).

You may pay a bit of speed with having persistence and in case of a graph database a fast query language & implementation.

Joop Eggen
  • 107,315
  • 7
  • 83
  • 138
0

Garbage collector collects/frees an object in heap area when it is unreachable. So to exclude an object from being tracked by the garbage collector you should always have reference id of that object(best case will be when it is in form of strong reference)

Gaur93
  • 685
  • 7
  • 19