Consider exposing weakrefs and finalisers to JS.

NEW
Unassigned

Status

()

Core
JavaScript: GC
P3
enhancement
7 months ago
3 months ago

People

(Reporter: pbone, Unassigned)

Tracking

({triage-deferred})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 months ago
Consider exposing weakrefs and finalisers to JS.

https://github.com/tc39/proposal-weakrefs/issues/15#issuecomment-303131429

Comment 1

7 months ago
Thank you, Paul for taking this up here! This is very appreciated and I hope for a good solution.
Exposing GC behavior to the web doesn't sound too good. Or does the proposal somehow manage to not expose it?

Comment 3

7 months ago
Any weakref proposal necessarily makes gc observable, and hence the non-determinism of gc. EcmaScript does not actually specify gc, but EcmaScript engines in practice all have some kind of gc supporting WeakMaps. (Note that our WeakMaps do not make GC observable. This was a major motivation for separating the weakmap vs weakref abstractions.)

However, even if gc were specified, most EcmaScript engines in practice would not be in a position to provide precise gc, and so no one would agree to specify precise gc. This means that gc will remain non-deterministic both regarding timing and even whether any non-reachable object is ever gc'ed.

That said, this weakref proposal does as much as if feasible to reduce the impact of this non-determinism. https://github.com/tc39/proposal-weakrefs/blob/master/specs/weakrefs.md#portability-and-observable-garbage-collection
I doubt any practical and approvable weakref proposal could do much better to further reduce the impact of this problem. Needless to say, as co-sponsor, I think that with this level of non-determinism-reduction, the pros substantially outweigh the cons.

We would appreciate help getting at least some trial form implemented for SpiderMonkey, even if on a branch, as Bradley has done for v8. Thanks.
Do not mistake the existence of this bug for an intent to implement. The GC team has other projects that are considered to be much higher priority at the moment, but we felt it was better to have a bug on file to have a place to put the SpiderMonkey-specific issues.

SpiderMonkey has a specific additional reason to avoid observable GC: we have the capability to partition the heap (into "zones") and only collect a portion. Most of our GCs in practice are zonal, and we would like to make more if not all of them zonal. So it is plausible that you could have a finalized or weak referenced portion of the graph in a zone that we never collect in practice. Or worse, that we *would* collect right now, but would stop collecting with future optimizations.

Most discussion of the policy question of whether or not to implement would probably be better done elsewhere, eg on the proposal, or on https://groups.google.com/forum/#!forum/mozilla.dev.tech.js-engine or (for the actual implementation bits) https://groups.google.com/forum/#!forum/mozilla.dev.tech.js-engine.internals
And now I'll violate my own request, and mention that my personal position is that (1) weakrefs do support some important use cases that there is really no other way to address; (2) the majority of things that people want weakrefs for are incorrect and should not be using weakrefs (eg managing non-memory resources); (3) the weakref proposal linked in comment 3 does seem very good and about the best we can hope for in terms of minimizing the damage; (4) but the whole "privileged" aspect seems fuzzy and too unformed to prevent the cat from getting out of the bag; and (5) as I said, at this time we have other things I'd much rather we spend time on to make things better before working on stuff that may make things worse. ;-)
Keywords: triage-deferred
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.