Menu
While collecting the young generation memory, JVM collectors scan only those root objects (obejcts in the heap directly accessible from the root set) that belong to the young generation and also use a write barrier backed card table/remembered set to determine regions of the old generation which could possibly contain objects that contain references to objects in the young generation.
The question that I have is that if the young collector determines that a particular object in the young generation only has a single external reference from an object in the old generation, how does it know if the old generation object itself is not garbage and thus making the young generation object 'live' and not eligible for collection? For example, there could be a path from the root set directly to this object in the old generation that in turn has a reference to the said young generation object. Does the young collector typically consider this young generation object as live or does it some how determine whether the old generation object pointing to it is live/garbage before deciding to ignore/collect it?
371
When objects are garbage collected from the Old Generation, it is a major garbage collection event. Permanent Generation: Metadata such as classes and methods are stored in the Permanent Generation. Classes that are no longer in use may be garbage collected from the Permanent Generation.
As long as an object is being referenced, the JVM considers it alive. Once an object is no longer referenced and therefore is not reachable by the application code, the garbage collector removes it and reclaims the unused memory. As simple as this sounds, it raises a question: what is the first reference in the tree?
The Old Generation is used to store long surviving objects. Typically, a threshold is set for young generation object and when that age is met, the object gets moved to the old generation. Eventually the old generation needs to be collected. This event is called a major garbage collection.
When the JVM doesn't have necessary memory space to run, the garbage collector will run and delete unnecessary objects to free up memory. Unnecessary objects are the objects which have no other references (address) pointing to them.
At a very high level, the most basic functionality of garbage collection algorithms in the JVM are the following: Upon an allocation request for memory from the application, the GC provides memory. Providing that memory should be as quick as possible. The GC detects memory that the application is never going to use again.
When objects get garbage collected from the old generation, a major garbage collection event occurs. Let’s see what a promotion from the survivor space of the young generation to the old generation looks like. Courtesy Oracle.
Rather, the permanent generation is immediately filled up by the JVM with the metadata that represents the applications’ classes and methods at runtime. The JVM may sometimes follow certain rules to clean out the permanent generation, and when it does, it’s called a full garbage collection.
From a high level, the young generation is where all new objects start out. Once they’re allocated in the Java code, they go specifically to this subsection called the eden space. Eventually, the eden space fills up with objects. At this point, a minor garbage collection event occurs.
how does it know if the old generation object itself is not garbage?
It doesn't that is what a major/full collection is for. The assumption is that old gen object doesn't die often.
When a full collection is performed it checks all the objects, but when a minor/young collection is performed only the objects in the young collection are cleaned up.
153
The question is “how to you get to such a scenario?”
To create a reference from an old object to a young object, the old object must be reachable, as otherwise we can’t store a reference to the young object in it. In order to become unreachable afterwards, we have to modify at least either, a root reference or another old object that previously referenced the old object in question.
As you already mentioned, these kind of writes are tracked by the JVM, which is crucial, as in order to detect that an old object now references a young object, it must know that the memory area of the old object (aka card) has been modified. In principle, since card marking also implies remembering the incoming references, the gc is now capable of detecting that the old object became unreachable, even without a major gc. It only has to consider the modified card (or the root set) to learn about it. Whether it does, depends on environmental factors, like the chosen gc algorithm, i.e. whether you use CMS (won’t) or G1 (might), and how “mixed collections” are configured or the actual memory pressure.
Of course, if you use a concurrent collector, there is the possibility that the modification that will make the old object unreachable happens while a collection cycle is already ongoing. In this situation, it is possible that the young object is considered reachable during this gc cycle, even if it wasn’t if the modification happened just a nanosecond earlier.
40
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
