Java garbage collector

1. reference counting: simple but slow garbage-collection technique. Reference counting schemes often release an object as soon as the count goes to zero. The one drawback is that if objects circularly refer to each other they can have nonzero reference counts while still being garbage. Locating such self-referential groups requires significant extra work for the garbage collector.

2. faster schemes any non-dead object must ultimately be traceable back to a reference that lives either on the stack or in static storage. There is no problem with detached self-referential groups.

In the approach described above, the JVM uses an adaptive garbage-collection scheme, and what it does with the live objects it locates depends on the variant currently used.

• One of these variants is stop-and-copy.

There are two issues that make these so-called “copy collectors” inefficient.

1) The first is the idea that you have two heaps and you slosh all the memory back and forth between these two separate heaps, maintaining twice as much memory as you actually need.

2) The second issue is the copying process itself.

• The other variant is called mark-and-sweep , and it’s what earlier versions of Sun’s JVM used all the time.

1) For general use, mark-and-sweep is fairly slow, but when you know you’re generating little or no garbage, it’s fast.

2) no copying happens.

3) also requires that the program be stopped.

 

 

The JVM monitors the efficiency of garbage collection and if it becomes a waste of time because all objects are long-lived, it switches to mark-and-sweep. Similarly, the JVM keeps track of how successful mark-and-sweep is, and if the heap starts to become fragmented, it switches back to stop-and-copy. This is where the “adaptive” part comes in, so you end up with a mouthful: “Adaptive generational stop-and-copy mark-and-sweep.”

There are a number of additional speedups possible in a JVM.

1. just-in-time (JIT) compiler.

A JIT compiler partially or fully converts a program into native machine code so it doesn’t need interpretation by the JVM and thus runs much faster.

two drawbacks.

1) It takes a little more time, which, compounded throughout the life of the program, can add up;

2) it increases the size of the executable (bytecodes are significantly more compact than expanded JIT code), and this might cause paging, which definitely slows down a program.

 

2. lazy evaluation.

means the code is not JIT compiled until necessary.

references:

1. On Java 8 - Bruce Exckel