1367476 - Consider exposing weakrefs and finalisers to JS.

Status: RESOLVED DUPLICATE of bug 1561074

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

Description

[Paul Bone [:pbone]]

Consider exposing weakrefs and finalisers to JS.

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

Comment 1

[alfa146ti]

Thank you, Paul for taking this up here! This is very appreciated and I hope for a good solution.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Exposing GC behavior to the web doesn't sound too good. Or does the proposal somehow manage to not expose it?

Comment 3

[Mark S. Miller]

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.

Comment 4

[Steve Fink [:sfink] [:s:]]

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

Comment 5

[Steve Fink [:sfink] [:s:]]

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. ;-)

Comment 6

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

I'm working on this.

Comment 7

[Jon Coppeard (:jonco)]

(In reply to Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8] from comment #6)
Are you still working on this?

Comment 8

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

I'm not, other things came up and I de-prioritized this. Please steal it :)

Comment 9

[Alex Vincent [:WeirdAl]]

Attachment: WeakRef.stub.js

Based on a surface reading of the specification, and the existence of JS files in js/src/builtin, I decided to take a first pass at what this might look like, with a dependency on XPConnect's Components.

I'm not claiming this is anywhere near correct, nor that it should be implemented in JavaScript. Think of this as a starting point for bootstrapping an implementation, if Mozilla developers consider that desirable. Note this is completely untested!!

Comment 10

[Mathieu Hofman]

FYI, I have an experimental implementation of the weakrefs proposal for SpiderMonkey in my shim. It's based on nondeterministicGetWeakMapKeys and a backing-off interval check for finding empty cells in FinalizationGroups.

I'd be happy to adapt the code to XPConnect's Components, I just don't have enough knowledge of Firefox or a dev environment setup for it.

https://github.com/mhofman/tc39-weakrefs-shim/tree/spec-update/src/spidermonkey

PS: I have an overdue update pending to update the shim to the latest version of the spec, clean some things up and improve the documentation.

Comment 11

[Alex Vincent [:WeirdAl]]

Possible duplicate: bug 1561074.

It's pretty obvious to me now that nobody's going to take a .js file to implement WeakRef or FinalizationGroup. That was just a bad idea on my part.

Comment 12

[Paul Bone [:pbone]]

I'm going to close this in favour of Bug 1561074.