I'm not sure why noteAsRoot:headerLoc: uses a red zone. Why can't it just not update the root table? The root table is only used for incremental GCs and they will perform a full GC if the root table has overflowed?
I'm asking because I had a bug in Exupery's version of this which I fixed by setting allocationCount on root table overflow. This appears to work but is there a good reason for the logic that the interpreter uses now?
Bryce
P.S. The method is: noteAsRoot: oop headerLoc: headerLoc "Record that the given oop in the old object area points to an object in the young area. HeaderLoc is usually = oop, but may be an addr in a forwarding block." | header | self inline: true. header := self longAt: headerLoc. (header bitAnd: RootBit) = 0 ifTrue: ["record oop as root only if not already recorded" rootTableCount < RootTableRedZone ifTrue: ["record root if there is enough room in the roots table " rootTableCount := rootTableCount + 1. rootTable at: rootTableCount put: oop. self longAt: headerLoc put: (header bitOr: RootBit)] ifFalse: ["we're getting in the red zone" rootTableCount < RootTableSize ifTrue: ["but there's still space to record it" rootTableCount := rootTableCount + 1. rootTable at: rootTableCount put: oop. self longAt: headerLoc put: (header bitOr: RootBit). "but force an IGC on the next allocation" allocationCount := allocationsBetweenGCs + 1]]]
bryce@kampjes.demon.co.uk wrote:
I'm not sure why noteAsRoot:headerLoc: uses a red zone. Why can't it just not update the root table? The root table is only used for incremental GCs and they will perform a full GC if the root table has overflowed?
Yes. But a root table overflow shouldn't trigger a full GC - it should tenure. That's what the red zone achieves; If we hit the red zone we force an IGC upon next allocation which will then tenure.
I'm asking because I had a bug in Exupery's version of this which I fixed by setting allocationCount on root table overflow. This appears to work but is there a good reason for the logic that the interpreter uses now?
Yes. Avoiding excessive full GCs is a good reason.
Cheers, - Andreas
Andreas Raab writes:
I'm asking because I had a bug in Exupery's version of this which I fixed by setting allocationCount on root table overflow. This appears to work but is there a good reason for the logic that the interpreter uses now?
Yes. Avoiding excessive full GCs is a good reason.
Thanks, I've now fixed Exupery's version to use the same logic as the interpreter does.
Bryce
vm-dev@lists.squeakfoundation.org