698463 - (guardians) SpiderMonkey should implement guardians to provide clean finalization

Status: RESOLVED WONTFIX

(Core :: JavaScript: GC, defect)

Description

[Jim Blandy :jimb]

I think guardians would be really helpful in writing the debugger client.

I've put up a proposal on the wiki here: https://wiki.mozilla.org/Guardians

It's got a link to the original 'guardians' paper, and link to the Chez Scheme documentation describing Chez's interface to them.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Let's make sure we understand how these will interact with the cycle collector first. Every time we add another IsAboutToBeFinalized call to the GC, it seems to add a lot of pain down the road.

Also, this would allow JS code to know when a GC has been done. I think we've tried to avoid that until now because of security issues. That sounds sorta bogus to me, but we should find out how real a concern it is.

Comment 2

[Jim Blandy :jimb]

I think the CC's shadow graph can just treat guardians as strong references to the objects they guard. While the guardian is alive, its members live.

When the CC has decided to delete some reference-counted objects, that means those objects simply won't appear as roots in the next JS GC --- at which point guardians might notice that some objects must move to their "inaccessible" groups.

I'd like to hear what Andrew (mccr8) has to say, but I think this will be pretty easy for the CC. (Famous last words!)

Comment 3

[Andrew McCreight [:mccr8]]

What happens when a guardian guards itself?  I guess the guardian just goes away without anything special happening?

What should happen when a guardian is reachable from a JS root, and it is guarding a cycle involving DOM that is otherwise unreachable from a JS root?  I assume the cycle should die?

Comment 4

[David Mandelin [:dmandelin]]

(In reply to Bill McCloskey (:billm) from comment #1)
> Let's make sure we understand how these will interact with the cycle
> collector first. Every time we add another IsAboutToBeFinalized call to the
> GC, it seems to add a lot of pain down the road.

What about the GC itself: how much complexity will it add there (including for generational)?

> Also, this would allow JS code to know when a GC has been done. I think
> we've tried to avoid that until now because of security issues. That sounds
> sorta bogus to me, but we should find out how real a concern it is.

I would assume that since this is nonstandard, we'd expose it only to chrome/extension code in Firefox.

Comment 5

[Jim Blandy :jimb]

Actually, when you think about it, it's inevitable that the CC will need to treat guardians specially.

Suppose we have a JS root pointing to a guardian, guarding a JS object X which refers to a DOM node Y, and Y refers to X. (Perhaps X is Y's wrapper.)

The guardian needs to move the reference to X from its accessible group to its inaccessible group when X can only be reached through guardians. But from the point of view of the JS GC alone, Y's reference is a root. There's no way the JS GC on its own can recognize, "Hey, the only *real* references to X are through this guardian."

So it seems that the CC would need to re-implement the guardian logic itself, just as it reimplemented the WeakMap logic itself.

Comment 6

[Andrew McCreight [:mccr8]]

Right, the CC needs to tell the GC that Y is inaccessible (so that the GC can conclude that X is inaccessible).  But normally when the CC decides that something is "inaccessible" it will kill it, so Y will get Unlinked.  This is bad, because when the Guardian calls X's finalizer, the finalizer presumably can examine X's children, which have gone away.

Comment 7

[Jim Blandy :jimb]

The CC shouldn't decide that Y is inaccessible; it should determine that X is unreachable except via the guardian. The process is reminiscent of the one we follow for WeakMaps: you iterate to closure *excluding* certain edges, and thereby determine that some of those edges are critical; then you add those edges and resume iteration.

Comment 8

[Jim Blandy :jimb]

With WeakMaps, you're determining that the edge from the map entry to the key *is not* critical, and thus the entry (and its value) is live. With guardians, you're determining that the edge from the guardian's "accessible" group to the object *is* critical, and thus the reference should be moved to the guardian's "inaccessible" group.

Comment 9

[Jon Coppeard (:jonco)]

JS now has FinalizationRegistry to cover this use case.