Open Bug 1600300 Opened 2 years ago Updated 2 years ago

Work out what to do about dependency of HeapPtr destuctor on its referent's arena not having been released

Categories

(Core :: JavaScript: GC, task, P3)

task

Tracking

()

People

(Reporter: jonco, Unassigned)

Details

As described in bug 1600238 comment 4.

It would be nice if we could make HeapPtr's destructor not check its referent's zone if it's called during finalization (it's checking whether it needs to trigger a pre-barrier, which it doesn't have to in this case). I'm not sure that is possible though.

Another possibility is to defer releasing all object arenas until everything in that sweep group has been finalized. This does make things simpler to understand, but it means free arenas can't be reused until later in the collection.

Tricky. It seems like it's generally a problem when a finalizer needs to access any other Cell, apart from some that are explicitly allowed by our ordering rules. (Which considers both the type and the zone.)

I do wonder if we should have some declarative contract at the beginning of the finalizer:

    FinalizerAccesses<FinalizationGroup, JSObjectZone> assertCanAccess1;

or

    FinalizerAccesses<FinalizationGroup> assertCanAccess1(ZoneOf<JSObject>());
    FinalizerAccesses<FinalizationGroup> assertCanAccess1(IdentityOf<JSObject>());

or in the body

    FinalizerAccesses<FinalizationGroup, JSObjectZone> assertCanAccess(this, obj);

that would boil down to static_asserts for what can be checked at compile time, plus runtime asserts for cross-zone access, foreground/background mixups, etc. And future "sufficiently smart static analysis" that complains if you access anything else.

But it all feels very complicated, especially when considering barriers that impose their own rules.

Maybe we could start with a comment that describes what the present rules are.

(In reply to Steve Fink [:sfink] [:s:] from comment #1)
I'm thinking we should go the other way and disallow finalizers from accessing any other cells. Doing this creates ordering requirements which are hard to spot and prevent the GC from freeing memory as quickly as it might. As far as I know all uses of this have been removed.

(In reply to Jon Coppeard (:jonco) from comment #2)

(In reply to Steve Fink [:sfink] [:s:] from comment #1)
I'm thinking we should go the other way and disallow finalizers from accessing any other cells. Doing this creates ordering requirements which are hard to spot and prevent the GC from freeing memory as quickly as it might. As far as I know all uses of this have been removed.

Huh, looks like you're right. I expected some types of accesses to be common (eg a JSObject looking at its ObjectGroup), but in skimming through a bunch of example finalizers, I found zero instances of this.

Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.