Weak Reference proposal
I think this proposal is currently at Stage 0, right? Do we typically put Stage 0 proposals on the TC39 GitHub? My understanding was that proposals typically get moved after Stage 2.
Dan
On Tue, Feb 16, 2016 at 2:02 PM, Daniel Ehrenberg <dehrenberg at chromium.org>
wrote:
I think this proposal is currently at Stage 0, right?
Right. It is stage 0.
Do we typically put Stage 0 proposals on the TC39 GitHub? My understanding was that proposals typically get moved after Stage 2.
Typically yes. My assumption is that our desire here was one way -- we want to ensure it is on the (tc39) hub once it is at stage 2. I was assuming there was no issue in the opposite direction, i.e., that we do not actively want to ensure that it is or is not on the hub prior to stage 2. Perhaps I misunderstood. Is there anything about this in our process docs or prior discussions?
Certainly, if for some reason we wish to ensure that earlier proposals are not on the hub, it would be easy to move off, and then back on later. This has a cost in broken links. What is the compensating benefit?
I suggest that this one be left on tc39 since it's already there and there is a history of weakref proposals anyway. But in general we should only move proposals to tc39 at stage <whatever>.
On Tue, Feb 16, 2016 at 3:52 PM, Kevin Smith <zenparsing at gmail.com> wrote:
I suggest that this one be left on tc39 since it's already there and there is a history of weakref proposals anyway. But in general we should only move proposals to tc39 at stage <whatever>.
I have no problem with that, but do wonder, why? What is the downside of proposals being on the tc39 hub starting at an earlier stage, if the authors are so inclined? The upside is fewer broken links.
I have no problem with that, but do wonder, why? What is the downside of
proposals being on the tc39 hub starting at an earlier stage, if the authors are so inclined? The upside is fewer broken links.
Because having the tc39 "brand" on things sends a signal to the broader community about the future state of ecma262?
Also, github forwards URLs when the repo is transferred, so we're good there. Case in point: zenparsing/async
On Tue, Feb 16, 2016 at 4:26 PM, Kevin Smith <zenparsing at gmail.com> wrote:
I have no problem with that, but do wonder, why? What is the downside of
proposals being on the tc39 hub starting at an earlier stage, if the authors are so inclined? The upside is fewer broken links.
Because having the tc39 "brand" on things sends a signal to the broader community about the future state of ecma262?
Makes sense.
Also, github forwards URLs when the repo is transferred, so we're good there. Case in point: zenparsing/async-iteration
Cool! I did not know that.
I'm happy to do whatever is appropriate here. Is there a message I should put in the Readme to emphasize the early stage?
Ecma International needs to capture a accurate historical archive of the contributions and deliberation that goes into TC39’s design decisions. The current “policy” of TC39 is that once a proposal reaches Stage 1 is MUST be hosted
I know this is only tangentially related, but I just remembered weak refs are required for a fully conforming DOM implementation because of their GC semantics. I feel this is relevant with the semi-recent DOM-in-JS efforts.
What are the GC semantics specified for DOM? How are these observable?
As an example, if you observe a node with a MutationObserver, but unmount it and don't retain an explicit reference to it, your mutation observer will soon stop providing updates, since it only maintains a weak reference to the node by spec. It can be observed.
On Tue, Feb 16, 2016 at 7:50 PM, Isiah Meadows <isiahmeadows at gmail.com> wrote:
As an example, if you observe a node with a MutationObserver, but unmount it and don't retain an explicit reference to it, your mutation observer will soon stop providing updates, since it only maintains a weak reference to the node by spec. It can be observed.
How is this different from the MutationObserver holding a strong reference to the node?
The observer will still not receive any notifications since if no one else is holding references to the node, then no one else is going to modify it either. Hence there will be nothing to notify about.
It might certainly be possible to use a WeakRef in order to optimize the implementation (I can't say with certainty without checking the spec more thoroughly), but it doesn't seem required.
/ Jonas
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Mark S. Miller
On Tue, Feb 16, 2016 at 7:04 PM, Isiah Meadows <mailto:isiahmeadows at gmail.com> wrote:
I know this is only tangentially related, but I just remembered weak refs are required for a fully conforming DOM implementation because of their GC semantics. I feel this is relevant with the semi-recent DOM-in-JS efforts.
What are the GC semantics specified for DOM? How are these observable?
Adding Sebastian and Joris, my co-collaborators on the jsdom project, which has at times found the lack of weakrefs in JavaScript troubling. I'm not sure if any of the cases we've run into are required, per se, so this might not answer your question directly. But answering the related question of "how would weakrefs be useful when implementing a self-hosted DOM", I know of at least one instance Joris ran into so far. From the DOM spec:
For each NodeIterator object iterator whose root’s node document is node’s node document, run the NodeIterator pre-removing steps given node and iterator.
Rephrased: every time you remove a Node from a document, you must go through all of the document's NodeIterators and run some cleanup steps (which have the effect of changing observable properties and behavior of the NodeIterator).
The weak references come in with the phrase "the document's NodeIterators". The only way to implement this that comes to mind is for the document to keep weak references to all of the relevant NodeIterators (or, equivalently, to keep an iterable weak set of them). You don't want the document to hold a strong reference, since otherwise the NodeIterators will be kept alive as long as the document is, even if they are unreachable from author code. And if they are unreachable from author code, they don't matter, since the cleanup steps don't have any side effects outside of the NodeIterator itself.
How Joris worked around this in jsdom was to have a user-configurable option "maxNodeIterators" per jsdom-Document, which gives the maximum number of well-behaved NodeIterators the user is allowed to use (default 10). The Document holds strong references to these. If the user users more than maxNodeIterators NodeIterators, the strong references to the oldest NodeIterators are dropped, and all of their public APIs which can change due to the aforementioned cleanup steps start throwing errors (instead of giving potentially incorrect results). This caps the memory usage at maxNodeIterators strong references, in the hope that older ones will not be relevant to the user code (e.g. because they would have otherwise been GCed, if not for the strong reference).
Obviously this is all pretty silly and weak references would make things a lot easier.
Other places to look:
- dom.spec.whatwg.org/#garbage-collection
- xhr.spec.whatwg.org/#garbage-collection (last sentence)
- fetch.spec.whatwg.org/#garbage-collection
- html.spec.whatwg.org/#garbage-collection-2 (notable by the circumstances where there is not a strong reference, as well as the last clause)
On Tue, Feb 16, 2016 at 11:02 PM, Domenic Denicola <d at domenic.me> wrote:
For each NodeIterator object iterator whose root’s node document is node’s node document, run the NodeIterator pre-removing steps given node and iterator.
Rephrased: every time you remove a Node from a document, you must go through all of the document's NodeIterators and run some cleanup steps (which have the effect of changing observable properties and behavior of the NodeIterator).
Could you implement all of this using MutationObservers? I.e. have the NodeIterators observe the relevant nodes using MutationObservers?
The only case that I can think of where the DOM could use weak references is for the getElementsByTagName(x) function. This function will either return a new NodeList object, or an existing one. The reason it sometimes returns an existing one is for performance reasons. We saw a lot of code doing:
var i; for (i = 0; i < document.getElementsByTagName("div").length; i++) { var elem = document.getElementsByTagName("div")[i]; doStuffWith(elem); }
This generated a ton of NodeList objects, which are expensive to allocate. Hence browsers started caching these objects and returned an existing object "sometimes".
The gecko implementation of "sometimes" uses a hash map keyed on tagname containing weak references to the returned NodeList. This is observable by for example doing:
document.getElementsByTagName("div").foopy = "foopy"; if (document.getElementsByTagName("div").foopy != "foopy") { // GC ran between the getElementsByTagName calls. }
However this exact behavior is not defined by spec. But I believe that all major browsers do do something similar for performance reasons. (This API is as old as it is crummy. And it is no surprise that it is poorly used).
But it likely would be possible to write an implementation of "sometimes" which doesn't use weak references, at the cost of higher memory usage.
/ Jonas
Resending because I the mailing list reject my previous email:
Here is an example of using a NodeIterator:
const jsdom = require("jsdom");
const document = jsdom.jsdom(`<a></a><b></b><c></c>`);
let it = document.createNodeIterator(document.body);
console.log(it.nextNode().nodeName); // BODY
console.log(it.nextNode().nodeName); // A
console.log(it.nextNode().nodeName); // B
console.log(it.nextNode().nodeName); // C
console.log(it.nextNode()); // null
it = document.createNodeIterator(document.body);
console.log(it.nextNode().nodeName); // BODY
document.body.removeChild(document.body.firstChild); // This remove
operation updates the internal state of the NodeIterator
console.log(it.nextNode().nodeName); // B
console.log(it.nextNode().nodeName); // C
console.log(it.nextNode()); // null
it = null;
In the case of NodeIterator, there are currently (read: in ES6) two spec (DOM whatwg) compliant implementations possible:
- Keep a history of all changes a Document has gone through, forever.
- Keep a list of all NodeIterators which have been created for a Document, forever.
jsdom uses solution #2. This not only leaks memory, but remove operations become slower as more and more NodeIterator's are created. (however as domenic described earlier we limit this list to 10 entries by default).
The conflict between the DOM spec and ES6 is that we can not detect if a NodeIterator is still in use by code outside of jsdom:
it = document.createNodeIterator(document.body);
console.log(it.nextNode().nodeName); // BODY
// ... wait an hour ...
console.log(it.nextNode().nodeName); // A
it = null; // and only now we can stop updating the NodeIterator state
(There used to be a it.detach() method for this purpose, but this has been removed from the spec.)
Being able to keep a list of NodeIterator's weakly would be the only solution if we want to avoid leaking resources.
Weak references might also be required for MutationObserver, although I've not yet looked at this feature extensively, so I could be wrong. Other features which you could implement using a weak reference (like in the live collections) could be implemented using ES6 Proxy instead.
XMLHttpRequest, fetch, WebSocket, etc would even require a something similar to a phantom reference (like in java) so that we can close the connection when the object is no longer strongly or weakly referenced.
I would also really like to use weak references not just for jsdom, there are some uses cases where they can simplify my code.
Gr. Joris
On 2/17/16 8:30 AM, Joris van der Wel wrote:
XMLHttpRequest, fetch, WebSocket, etc would even require a something similar to a phantom reference (like in java) so that we can close the connection when the object is no longer strongly or weakly referenced.
None of these allow closing the connection merely because the object is not referenced from elsewhere.
Or put another way, the connection must hold a reference to the object.
Yeah, you are right. NodeIterators, and presumably Ranges, suffer from the observer problem. I.e. they want to be notified about mutations to the DOM, but only as long as the NodeIterator/Range stay alive.
My understanding is that this is one of the more common scenarios where the need for weak-references come up. Where you want to register something as an observer, but don't want the notification mechanism to hold a strong reference to the observer.
Fortunately though, neither NodeIterators nor Ranges expose this in their public API. I.e. there is no way to use them to detect when GC happens.
/ Jonas
This seems like a very solid proposal. I like that the finalizers run on their own turn (it had to be that way in retrospect).
I'm unclear about one thing: the reasoning for not running finalizers when weak-references them become unreferenced. Did I misunderstand this? Doesn't this force he "hard" reference to also a soft reference "weak reference" to insure that finalizer run (such as closing a file, etc)? If aren't concerned about non-memory resources is there any point to having holding at all?
Thanks for your comments.
A practical answer to your question: If you drop references to a subsystem that internally uses weak references, the "finalization" it would engage is just death throes. For example, if you drop an Xml parser, then there's no reason to muck out it's internal cache since that's going to be collected anyway. Thus, this variant is more expressive.
It also breaks the retention properties of the system. In order to require the executor to run, *something *has to point at it (and the holdings) strongly. Otherwise for example the holdings and executor might not be retained (and you couldn't run finalization). You can end up with cycles of executors pointing at each other's targets such that neither can ever be collected because the system is keeping them around strongly.
Oh and note that if the current version of the proposal (459f825) were implemented, it would not be usable for jsdom. This is because of the authority constraints. jsdom supports being run within a different browser (e.g. so that you can parse html within a Worker, which does not provide access to the native DOM). As I read it, weak references would not be available for scripts within a normal web page. So in jsdom we would have to support the lowest common denominator, which means no weak references.
I am kind of worried about the authority concept. One of my major use cases for ecmascript is that I can share modules between server (node.js) and the browser. I would rather not have an unnecessary divide of ES features between them. If all sorts of (public) modules start using weak references for the convenience, it would add a lot of head aches for me because I can no longer use them easily in the browser, even though they are not using any node.js api's which would normally only make sense on the server (reading files, opening random sockets, etc)
While admittedly I do not have much experience with the internals of ecmascript engines, surely a side channel attack proof implementation is possible? For example, would it help to add a random variance to the timing of condemning objects as soon as they become unreachable?
Gr. Joris
The finalizer holdings, could itself could hold a reference to the weakrefernce correct?
On Fri, Feb 19, 2016 at 5:36 PM, John Lenz <concavelenz at gmail.com> wrote:
The finalizer holdings, could itself could hold a reference to the weakrefernce correct?
The holdings can certainly strongly point to the weakref itself, yes. There is no reason to think this is a mistake.
By contrast, though we cannot prevent the holdings from strongly pointing to the target, this would almost certainly be a mistake. It would prevent the finalization that would involve this holdings. See the four scenarios at
If the weakref with these holdings is itself strongly reachable (scenarios 1 and 2) then this will also prevent the target from being collected. If the holdings is strongly reachable (scenario 4) the target again cannot be collected. If the weakref and the holdings are both not reachable (scenario 3), then they and the target can all be collected at the same time without any finalization action involving that holdings. Other weakrefs onto target (wr3a) can observe target disappear, and can have their own finalization actions. These will still be triggered.
There is a possible controversy regarding scenario 2, for which I'll refer you to the issue.
Right, I was suggesting that having the "holdings" hold the weakref itself would be a means of by-passing the "don't run this finalizer if I forget about this weakref" here. So it would still be useful to collect non-memory resources, assuming you can live with the laziness inherent in GC/weakref collection.
The weak reference proposal tc39/proposal-weakrefs hasn't
seen a lot of activity, and I haven't found much news elsewhere on it. What's the status on it?
Where I'm building a language-integrated process pool in Node.js, complete with shared "references" and async iterator support, I really badly need weak references to avoid otherwise inevitable memory leaks across multiple processes if the references aren't explicitly released. So far, my only option is to take a native dependency (I have no other dependencies), but that's very suboptimal, and it eliminates the possibility of porting to browsers. So I really badly need language-level weak references.
Isiah Meadows me at isiahmeadows.com
On 12/27/2016 04:45 AM, Isiah Meadows wrote:
The weak reference proposal tc39/proposal-weakrefs hasn't seen a lot of activity, and I haven't found much news elsewhere on it. What's the status on it?
Where I'm building a language-integrated process pool in Node.js, complete with shared "references" and async iterator support, I really badly need weak references to avoid otherwise inevitable memory leaks across multiple processes if the references aren't explicitly released. So far, my only option is to take a native dependency (I have no other dependencies), but that's very suboptimal, and it eliminates the possibility of porting to browsers. So I really badly need language-level weak references.
Would weak references be enough to solve cross-process garbage collection? How would you recover a cycle of references among your processes?
For my particular case, yes it is. Everything mirrored have globally unique IDs assigned to them, managed independently of the child process (in most cases), and the state is tied to the ID, not the value, so I only need a weak reference to clear the backing ID and its associated state. And reference cycles within the process are mitigated by the existing mark-and-sweep derivatives engines already use.
Isiah Meadows me at isiahmeadows.com
Please correct me Isiah/Steve - but I think the problem Steve is talking about is cross-process cycles. Without an inter-process protocol to express the referencing graph, or otherwise negotiate cycles for GC, you'll never have a way to reclaim them. Each side thinks the other side is still needing the resource.
That is a concern largely independent of my need for weak references (despite the relation). I can still implement a basic tiered mark-and-sweep without weak references, given I can already destroy things manually with just the ID. All I want is a way to implicitly call that destructor within the individual process.
Isiah Meadows me at isiahmeadows.com
If it were me, I would use a socket for ipc and use the socket as the weak map reference... Thus, when the socket was destroyed, and you get the SIGPIPE, free the socket reference, and it's referenced object should be cleared. This should work, however if you have too many objects, then you might have to tree it out or something.
I think the idea is a good one for library, I just don't think it's worth polluting the spec with... thoughts?
On Dec 31, 2016 11:20 AM, <es-discuss-request at mozilla.org> wrote:
Send es-discuss mailing list submissions to es-discuss at mozilla.org
To subscribe or unsubscribe via the World Wide Web, visit mail.mozilla.org/listinfo/es-discuss or, via email, send a message with subject or body 'help' to es-discuss-request at mozilla.org
You can reach the person managing the list at es-discuss-owner at mozilla.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of es-discuss digest..."
Today's Topics:
- Re: Weak Reference proposal (Isiah Meadows)
- Re: Weak Reference proposal (Alexander Jones)
- Re: Resource management (Isiah Meadows)
- Re: Resource management (Isiah Meadows)
- Re: Weak Reference proposal (Isiah Meadows)
---------- Forwarded message ---------- From: Isiah Meadows <isiahmeadows at gmail.com>
To: Steve Fink <sphink at gmail.com>
Cc: "es-discuss at mozilla.org" <es-discuss at mozilla.org>
Date: Sat, 31 Dec 2016 08:48:19 -0500 Subject: Re: Weak Reference proposal For my particular case, yes it is. Everything mirrored have globally unique IDs assigned to them, managed independently of the child process (in most cases), and the state is tied to the ID, not the value, so I only need a weak reference to clear the backing ID and its associated state. And reference cycles within the process are mitigated by the existing mark-and-sweep derivatives engines already use.
Isiah Meadows me at isiahmeadows.com
On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink <sphink at gmail.com> wrote:
On 12/27/2016 04:45 AM, Isiah Meadows wrote:
The weak reference proposal hasn't seen a lot of activity, and I haven't found much news elsewhere on it. What's the status on it?
Where I'm building a language-integrated process pool in Node.js, complete with shared "references" and async iterator support, I really badly need weak references to avoid otherwise inevitable memory leaks across multiple processes if the references aren't explicitly released. So far, my only option is to take a native dependency (I have no other dependencies), but that's very suboptimal, and it eliminates the possibility of porting to browsers. So I really badly need language-level weak references.
Would weak references be enough to solve cross-process garbage collection? How would you recover a cycle of references among your processes?
es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss
---------- Forwarded message ---------- From: Alexander Jones <alex at weej.com>
To: Isiah Meadows <isiahmeadows at gmail.com>
Cc: "es-discuss at mozilla.org" <es-discuss at mozilla.org>
Date: Sat, 31 Dec 2016 14:23:38 +0000 Subject: Re: Weak Reference proposal Please correct me Isiah/Steve - but I think the problem Steve is talking about is cross-process cycles. Without an inter-process protocol to express the referencing graph, or otherwise negotiate cycles for GC, you'll never have a way to reclaim them. Each side thinks the other side is still needing the resource.
Cheers
On 31 December 2016 at 13:48, Isiah Meadows <isiahmeadows at gmail.com> wrote:
For my particular case, yes it is. Everything mirrored have globally unique IDs assigned to them, managed independently of the child process (in most cases), and the state is tied to the ID, not the value, so I only need a weak reference to clear the backing ID and its associated state. And reference cycles within the process are mitigated by the existing mark-and-sweep derivatives engines already use.
Isiah Meadows me at isiahmeadows.com
On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink <sphink at gmail.com> wrote:
On 12/27/2016 04:45 AM, Isiah Meadows wrote:
The weak reference proposal hasn't seen a lot of activity, and I haven't found much news elsewhere on it. What's the status on it?
Where I'm building a language-integrated process pool in Node.js, complete with shared "references" and async iterator support, I really badly need weak references to avoid otherwise inevitable memory leaks across multiple processes if the references aren't explicitly released. So far, my only option is to take a native dependency (I have no other dependencies), but that's very suboptimal, and it eliminates the possibility of porting to browsers. So I really badly need language-level weak references.
Would weak references be enough to solve cross-process garbage collection? How would you recover a cycle of references among your processes?
es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss
es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss
---------- Forwarded message ---------- From: Isiah Meadows <isiahmeadows at gmail.com>
To: Jamesernator <thejamesernator at gmail.com>
Cc: "Raul-Sebastian Mihăilă" <raul.mihaila at gmail.com>, es-discuss <
es-discuss at mozilla.org>
Date: Sat, 31 Dec 2016 10:46:28 -0500
Subject: Re: Resource management
Certainly not optimal, though, and I'd rather it not become the
primary idiom - it lacks the intent of a Python-like with statement.
Also, next/return doesn't exactly mirror __enter__/__exit__
from Python. What really happens with for ... of is closer to
next/next, where the first call reports {done: false, value: whatever}, and the second {done: true}. It's more of a unusual pun
than anything, a theoretical equivalence providing an unintuitive
workaround.
I would welcome a strict-mode-only modification to with that allows
something like that, and adding with await for Promise-resolving
equivalents.
Isiah Meadows me at isiahmeadows.com
On Thu, Dec 29, 2016 at 11:05 PM, Jamesernator <thejamesernator at gmail.com> wrote:
The
forloop approach works for synchronous resources as well actually, there's nothing special about thoseawaited things e.g.const fs = require('fs') function* open(file, opts) { const fd = fs.openSync(file, opts) try { yield fd } finally { fs.closeSync(fd) } } for (const fd of open("/path/to/file", {mode: "r+"})) { const bit = fs.readSync(fd) ... }I can definitely imagine a Python-esque
withstatement though (perhaps withSymbol.open/Symbol.close) then you just use something like Python's contextlib (docs.python.org/3.7/library/contextlib.html) utility functions for converting generator based resources toSymbol.open/Symbol.close.For now though the
forloop approach is a relatively good workaround (asnext/returneffectively emulate Python's__enter__/__exit__).On 30/12/16 04:17, Isiah Meadows wrote:
But keep in mind it still doesn't cover two key issues:
- Synchronous resources do in fact exist (primarily in Node). You need both for it to be effective.
- Your suggestion isn't composable at all (like nearly every other callback-driven API), and it prevents returning from inside the block without the use of exceptions.
Isiah Meadows me at isiahmeadows.com
On Thu, Dec 29, 2016 at 9:05 AM, Raul-Sebastian Mihăilă <raul.mihaila at gmail.com> wrote:
I agree, but note that a resolved promise is not the same as a fulfilled promise (tc39.github.io/ecma262/#sec-promise-objects).
On Thu, Dec 29, 2016 at 11:40 AM, Jordan Harband <ljharb at gmail.com> wrote:
You'd need to wrap the body of your
openfunction in a try/finally, and do thefsp.closein thefinallyblock - but otherwise that would certainly work, provided that the promise returned fromfuncdid actually settle (resolve or reject).
es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss
es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss
---------- Forwarded message ---------- From: Isiah Meadows <isiahmeadows at gmail.com>
To: J Decker <d3ck0r at gmail.com>
Cc: "Raul-Sebastian Mihăilă" <raul.mihaila at gmail.com>, es-discuss <
es-discuss at mozilla.org>
Date: Sat, 31 Dec 2016 11:33:45 -0500
Subject: Re: Resource management
Not enough. Not looking for an await replacement, but something
closer to Python's with statement or Java's try-with-resources.
Or, if you want something
Python: preshing.com/20110920/the-python-with-statement-by-example Java: docs.oracle.com/javase/tutorial/essential exceptions/tryResourceClose.html
JavaScript's idioms tend towards Python, Java, C#, etc. in how
resources are handled, so things like Ruby's begin-ensure wouldn't
work as well (that was where I got my generator workaround from,
actually, and as you can see, it's not exactly very obvious).
Isiah Meadows me at isiahmeadows.com
On Fri, Dec 30, 2016 at 2:03 AM, J Decker <d3ck0r at gmail.com> wrote:
Just a shot; but something ilke deasync ? www.npmjs.com/package/deasync
it's not so much about ordering wait in the current code, but the current code within outer code that's the issue somehow?
---------- Forwarded message ---------- From: Isiah Meadows <isiahmeadows at gmail.com>
To: Alexander Jones <alex at weej.com>
Cc: "es-discuss at mozilla.org" <es-discuss at mozilla.org>
Date: Sat, 31 Dec 2016 12:19:32 -0500 Subject: Re: Weak Reference proposal That is a concern largely independent of my need for weak references (despite the relation). I can still implement a basic tiered mark-and-sweep without weak references, given I can already destroy things manually with just the ID. All I want is a way to implicitly call that destructor within the individual process.
Isiah Meadows me at isiahmeadows.com
On Sat, Dec 31, 2016 at 9:23 AM, Alexander Jones <alex at weej.com> wrote:
Please correct me Isiah/Steve - but I think the problem Steve is talking about is cross-process cycles. Without an inter-process protocol to express the referencing graph, or otherwise negotiate cycles for GC,
you'll
never have a way to reclaim them. Each side thinks the other side is still needing the resource.
Cheers
On 31 December 2016 at 13:48, Isiah Meadows <isiahmeadows at gmail.com>
wrote:
For my particular case, yes it is. Everything mirrored have globally unique IDs assigned to them, managed independently of the child process (in most cases), and the state is tied to the ID, not the value, so I only need a weak reference to clear the backing ID and its associated state. And reference cycles within the process are mitigated by the existing mark-and-sweep derivatives engines already use.
Isiah Meadows me at isiahmeadows.com
On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink <sphink at gmail.com> wrote:
On 12/27/2016 04:45 AM, Isiah Meadows wrote:
The weak reference proposal hasn't seen a lot of activity, and I
haven't
found much news elsewhere on it. What's the status on it?
Where I'm building a language-integrated process pool in Node.js, complete with shared "references" and async iterator support, I really badly
need
...additionally, I think the term "weak reference" is inaccurate for ipc referencing... I would describe that more as super-strong references than weak... resilient referencing.
There's a problem with that idea: I've got one socket per process, but I can have anywhere from 0 to N shared references per process that I still have to track. And also, the shared references can be exposed to any other child within other pools, and even released by the child it was created in afterwards. Consider this:
- Child 1 creates shared reference.
- Child 1 sends reference to parent.
- Parent receives reference.
- Child 1 releases reference.
At this point, the parent has already received the reference it didn't create, but the child released the reference itself locally. Therein lies the problem.
Isiah Meadows me at isiahmeadows.com
I have posted a stage 1 proposal for weak references in ES7 for your perusal and feedback.
tc39/proposal-weakrefs.git
Thanks to Mark Miller and the authors of earlier proposals for help with the document and content! Finally thanks to a few intrepid early reviewers for their edits, comments, and feedback.