2

My understanding is that the JVM specification only defines the behavior of a garbage collector, but does not provide implementation details. This means it is up to the JVM implementation to build the garbage collector out.

There appears to be 3rd party garbage collectors such as the Azul Pauseless GC. To me, this implies that my JVM implementation, say HotSpot or JRockit, is configured by default to use its own built-in garbage collector. But, perhaps through configuration, I could use a 3rd party garbage collector (such as the one by Azul, or another).

So I ask: How does one "swap out" the built-in garbage collector with another one? If the answer is JVM implementation-specific, let's assume HotSpot.

closed as off-topic by Jarrod Roberson, amon, durron597, GlenH7, user22815 May 14 '15 at 15:33

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – Jarrod Roberson, amon, durron597, GlenH7, Community
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 5
    That's not a garbage collector that you linked to; it's an entire JVM having its own custom collector. It doesn't have to be configurable at all, if you're changing out the whole JVM. – Robert Harvey May 13 '15 at 18:23
  • This question is a specific tooling implementation question (rather than conceptual design and architecture) and should instead be asked on Stack Overflow (the answer, if there is one, is some application of command line switches). – user40980 May 13 '15 at 18:24
  • Also explained here: javapapers.com/java/types-of-java-garbage-collectors – Robert Harvey May 13 '15 at 18:29
8

Garbage collectors and code generators (in particular the JIT engine inside any industrial JVM) are tightly related, in particular because most GCs are generational, and need some write barrier (which is a constraint on the code generator), and also depend upon multithreading issues. And the GC is also (obviously) tied to object allocations which is JVM specific. Read the GC handbook for more explanations.

Generational GCs are handling differently young objects (which usually die quickly) from older ones. They often copy the live young objects in some older memory region, then the entire birth region can be released. But they need to track any old object which has been modified to hold a pointer to the newest region. This is a write barrier and needs special code to be emitted by the JIT engine for field modifications of (young) object.

BTW, the Azul PGC link you gave has a video explaining all that!

So in practice you cannot easily plug another GC inside your JVM without patching significantly the JVM code.

  • Thanks @Basile (+1) - I understand everything you said except this bit: "GCs are generational, and need some write barrier (which is a constraint on the code generator)". Any chance you can elaborate more on what this means? What write barrier, and why is this write barrier a "constraint" on the code generator? Thanks again! – smeeb May 13 '15 at 19:57
  • @smeeb: I tried to explain a little bit, but I don't have the patience to explain what a good book of several hundred pages would teach you. – Basile Starynkevitch May 13 '15 at 20:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.