Does JVM record generation count on Object or block?

2
votes

From http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html, I found that JVM record generation count on object:

At the next minor GC, the same thing happens for the eden space. Unreferenced objects are deleted and referenced objects are moved to a survivor space. However, in this case, they are moved to the second survivor space (S1). In addition, objects from the last minor GC on the first survivor space (S0) have their age incremented and get moved to S1. Once all surviving objects have been moved to S1, both S0 and eden are cleared. Notice we now have differently aged object in the survivor space.

JVM record generation count on object

However, from Thinking in Java 4th, page 124, author said JVM record generation count on block of memory:

As previously mentioned, in the JVM described here memory is allocated in big blocks. If you allocate a large object, it gets its own block. Strict stop-and-copy requires copying every live object from the source heap to a new heap before you can free the old one, which translates to lots of memory. With blocks, the garbage collection can typically copy objects to dead blocks as it collects. Each block has a generation count to keep track of whether it’s alive. In the normal case, only the blocks created since the last garbage collection are compacted; all other blocks get their generation count bumped if they have been referenced from somewhere. This handles the normal case of lots of short-lived temporary objects. Periodically, a full sweep is made—large objects are still not copied (they just get their generation count bumped), and blocks containing small objects are copied and compacted. The JVM monitors the efficiency of garbage collection and if it becomes a waste of time because all objects are long-lived, then it switches to mark-andsweep. 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-andsweep.”

Which one is correct? Or maybe they are just saying something different? Please help me figure out.

1
javagarbage-collectionjvm
There are about six garbage collectors for the Oracel JVM. Are you sure both extracts refer to the same one? - user207421
The first cite describes a copying collector, the second describes a compacting collector. Current JVMs typically use a copying collector for the young generation and a compacting collector for the old generation. The latter is organized in cards for most available garbage collectors. These cards may match the blocks of the cite in several technical aspects, but there might also be some differences. - Holger

1 Answers

2
votes

In HotSpot JVM (Oracle's JVM), a few bits are reserved for object age in object's header. Number of bits may vary, but at least 4 bits would be available in any configuration.

So, age is tracked for each object individually. This is true for all collectors available on HotSpot JVM.

Other vendors may have different approach, though. E.g. Azul Zing track age on memory block granularity.