Why does updating the root table use a red zone?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Why does updating the root table use a red zone?

Bryce Kampjes
 

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]]]
Reply | Threaded
Open this post in threaded view
|

Re: Why does updating the root table use a red zone?

Andreas.Raab
 
[hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: Why does updating the root table use a red zone?

Bryce Kampjes
 
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