That does look a bit peculiar. Maybe the reason that it is explicitly dismantling the list is so that the list is cleared for existing iterators and sublists as well as the parent list.
It is certainly NOT done to make the garbage collection faster. A garbage collector doesn't traverse the references in an unreachable object, so nulling them won't make any difference.
UPDATE
A more recent version of the method has these comments:
// Clearing all of the links between nodes is "unnecessary", but:
// - helps a generational GC if the discarded nodes inhabit
// more than one generation
// - is sure to free memory even if there is a reachable Iterator
So, it appears that there is an benefit for the GC, at least in some cases.
Suppose that a Node
in an older generation contains a reference to an object (e.g. a Node
or an element) in a younger generation. That reference becomes a "root" when collecting of the younger generation, causing the young generation object to be retained, even if the old generation Node
is unreachable. This state continues until the older generation is collected. Old generations are collected infrequently.
If you traverse the list and dismantle it, the variable containing the old -> new reference is assigned a null
. The write-barrier for that assignment causes (immediately or at GC time) the original reference to no longer be a "root". Thus, the object in the younger generation can now be collected, and it doesn't end up "tenured" to an older generation (which brings forward the time when that generation needs to be collected).
Presumably, the GC benefits outweigh the cost of unpicking the list ... either on average, or in cases where the costs are disastrous.
For more information, refer to "Garbage Collection algorithms for dynamic memory management" by Jones and Lins. It is in chapter 7.5 in my (first edition) copy.
Generally speaking, it is better to throw a Collection
object away and start again than it is to clear it for reuse.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…