GC and CDS
Peter B. Kessler
Peter.B.Kessler at Oracle.COM
Fri Jul 30 17:36:23 PDT 2010
The classes "loaded" from the CDS image are loaded by the system class loader, so there's always a reference from the system class loader to the read-write part of the class meta-data, and from there to the read-only part of the class meta-data. The tricky part is that the read-only part of the class meta-data can't be marked in the usual way, because it's read-only so the "marked" bit can't be toggled. That's finessed by having the read-only part of the class meta-data built with the "marked" bit set, so the usual heap walks see it as live, stop marking when they visit it, etc.
Johannes Rudolph wrote:
> I'm just browsing the OpenJDK sources and try to understand how the
> class data sharing mechanism works in detail. I've already quite
> learned a bit but what I still don't understand is how CDS works
> together with garbage collection.
> Is my understanding correct: When a full GC is done class metadata
> (and other PermGen stuff) is subject to gc as with other things in the
> heap. As far as I understood shared classes are mapped into the memory
> space of the JVM process read only logically as a part of the PermGen
> and should not be changed afterwards. How is it accomplished that the
> GC doesn't touch this space? I've still not found the code which skips
> over objects in the CDS PermGen in contrast to the normal PermGen.
More information about the hotspot-gc-dev