Re: weak reference proposal

[Isiah Meadows]

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:

1. Child 1 creates shared reference.
2. Child 1 sends reference to parent.
3. Parent receives reference.
4. 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
m...@isiahmeadows.com

On Sat, Dec 31, 2016 at 12:31 PM, Uther Pendragon  wrote:
>
> ...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.
>
> On Dec 31, 2016 11:20 AM,  wrote:
>>
>> 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?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: weak reference proposal

[Uther Pendragon]

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

On Dec 31, 2016 11:20 AM, <es-discuss-requ...@mozilla.org> wrote:

> 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-requ...@mozilla.org> wrote:
>
> Send es-discuss mailing list submissions to
> es-discuss@mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
> es-discuss-requ...@mozilla.org
>
> You can reach the person managing the list at
> es-discuss-ow...@mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
>
> Today's Topics:
>
>1. Re: Weak Reference proposal (Isiah Meadows)
>2. Re: Weak Reference proposal (Alexander Jones)
>3. Re: Resource management (Isiah Meadows)
>4. Re: Resource management (Isiah Meadows)
>5. Re: Weak Reference proposal (Isiah Meadows)
>
>
> -- Forwarded message --
> From: Isiah Meadows <isiahmead...@gmail.com>
> To: Steve Fink <sph...@gmail.com>
> Cc: "es-discuss@mozilla.org" <es-discuss@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
> m...@isiahmeadows.com
>
>
> On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink <sph...@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@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
> -- Forwarded message --
> From: Alexander Jones <a...@weej.com>
> To: Isiah Meadows <isiahmead...@gmail.com>
> Cc: "es-discuss@mozilla.org" <es-discuss@mozilla.org>
> Date: Sat, 31 Dec 2016 14:23:38 +
> 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 <isiahmead...@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
>> mitigat

Re: weak reference proposal

[Uther Pendragon]

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-requ...@mozilla.org> wrote:

Send es-discuss mailing list submissions to
es-discuss@mozilla.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.mozilla.org/listinfo/es-discuss
or, via email, send a message with subject or body 'help' to
es-discuss-requ...@mozilla.org

You can reach the person managing the list at
es-discuss-ow...@mozilla.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of es-discuss digest..."

Today's Topics:

   1. Re: Weak Reference proposal (Isiah Meadows)
   2. Re: Weak Reference proposal (Alexander Jones)
   3. Re: Resource management (Isiah Meadows)
   4. Re: Resource management (Isiah Meadows)
   5. Re: Weak Reference proposal (Isiah Meadows)


-- Forwarded message --
From: Isiah Meadows <isiahmead...@gmail.com>
To: Steve Fink <sph...@gmail.com>
Cc: "es-discuss@mozilla.org" <es-discuss@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
m...@isiahmeadows.com


On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink <sph...@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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- Forwarded message --
From: Alexander Jones <a...@weej.com>
To: Isiah Meadows <isiahmead...@gmail.com>
Cc: "es-discuss@mozilla.org" <es-discuss@mozilla.org>
Date: Sat, 31 Dec 2016 14:23:38 +
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 <isiahmead...@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
> m...@isiahmeadows.com
>
>
> On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink <sph...@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 e

Re: Weak Reference proposal

[Isiah Meadows]

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
m...@isiahmeadows.com


On Sat, Dec 31, 2016 at 9:23 AM, Alexander Jones <a...@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 <isiahmead...@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
>> m...@isiahmeadows.com
>>
>>
>> On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink <sph...@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@mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Alexander Jones]

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 <isiahmead...@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
> m...@isiahmeadows.com
>
>
> On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink <sph...@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@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Isiah Meadows]

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
m...@isiahmeadows.com


On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink <sph...@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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Steve Fink]

On 12/27/2016 04:45 AM, Isiah Meadows wrote:
The weak reference proposal 
<https://github.com/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?


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Weak Reference proposal

[Isiah Meadows]

The weak reference proposal <https://github.com/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
m...@isiahmeadows.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[John Lenz]

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.

On Fri, Feb 19, 2016 at 5:51 PM, Mark S. Miller  wrote:

> On Fri, Feb 19, 2016 at 5:36 PM, John Lenz  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
>
> https://github.com/tc39/proposal-weakrefs/issues/5#issuecomment-185955167
>
> 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.
>
>
>> On Fri, Feb 19, 2016 at 12:30 AM, Dean Tribble 
>> wrote:
>>
>>> 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.
>>>
>>> On Thu, Feb 18, 2016 at 10:42 PM, John Lenz 
>>> wrote:
>>>
 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?



 On Sun, Feb 14, 2016 at 11:35 PM, Dean Tribble 
 wrote:

> I have posted a stage 1 proposal for weak references in ES7 for your
> perusal and feedback.
>
> https://github.com/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.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Mark S. Miller]

On Fri, Feb 19, 2016 at 5:36 PM, John Lenz  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

https://github.com/tc39/proposal-weakrefs/issues/5#issuecomment-185955167

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.


> On Fri, Feb 19, 2016 at 12:30 AM, Dean Tribble  wrote:
>
>> 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.
>>
>> On Thu, Feb 18, 2016 at 10:42 PM, John Lenz 
>> wrote:
>>
>>> 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?
>>>
>>>
>>>
>>> On Sun, Feb 14, 2016 at 11:35 PM, Dean Tribble 
>>> wrote:
>>>
 I have posted a stage 1 proposal for weak references in ES7 for your
 perusal and feedback.

 https://github.com/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.

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[John Lenz]

The finalizer holdings, could itself could hold a reference to the
weakrefernce correct?

On Fri, Feb 19, 2016 at 12:30 AM, Dean Tribble  wrote:

> 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.
>
> On Thu, Feb 18, 2016 at 10:42 PM, John Lenz  wrote:
>
>> 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?
>>
>>
>>
>> On Sun, Feb 14, 2016 at 11:35 PM, Dean Tribble 
>> wrote:
>>
>>> I have posted a stage 1 proposal for weak references in ES7 for your
>>> perusal and feedback.
>>>
>>> https://github.com/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.
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Dean Tribble]

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.

On Thu, Feb 18, 2016 at 10:42 PM, John Lenz  wrote:

> 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?
>
>
>
> On Sun, Feb 14, 2016 at 11:35 PM, Dean Tribble  wrote:
>
>> I have posted a stage 1 proposal for weak references in ES7 for your
>> perusal and feedback.
>>
>> https://github.com/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.
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[John Lenz]

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?



On Sun, Feb 14, 2016 at 11:35 PM, Dean Tribble  wrote:

> I have posted a stage 1 proposal for weak references in ES7 for your
> perusal and feedback.
>
> https://github.com/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.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Jonas Sicking]

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

On Wed, Feb 17, 2016 at 5:23 AM, Joris van der Wel
 wrote:
> Here is an example of using a NodeIterator:
>
>
> ```
> const jsdom = require("jsdom");
> const document = jsdom.jsdom(``);
>
> 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:
>
> 1. Keep a history of all changes a Document has gone through, forever.
> 2. 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 Wed, Feb 17, 2016 at 9:41 AM, Jonas Sicking  wrote:
>>
>> On Tue, Feb 16, 2016 at 11:02 PM, Domenic Denicola  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 

Re: Weak Reference proposal

[Boris Zbarsky]

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.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Joris van der Wel]

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(``);

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:

1. Keep a history of all changes a Document has gone through, forever.
2. 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 Wed, Feb 17, 2016 at 9:41 AM, Jonas Sicking  wrote:
> On Tue, Feb 16, 2016 at 11:02 PM, Domenic Denicola  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



-- 
github.com/Joris-van-der-Wel
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Jonas Sicking]

On Tue, Feb 16, 2016 at 11:02 PM, Domenic Denicola  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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Weak Reference proposal

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mark S. 
Miller

> On Tue, Feb 16, 2016 at 7:04 PM, Isiah Meadows 
>  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][1], 
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][2]:

> 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][3] 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:

- https://dom.spec.whatwg.org/#garbage-collection
- https://xhr.spec.whatwg.org/#garbage-collection (last sentence)
- https://fetch.spec.whatwg.org/#garbage-collection
- https://html.spec.whatwg.org/#garbage-collection-2 (notable by the 
circumstances where there is *not* a strong reference, as well as the last 
clause)


[1]: https://github.com/tmpvar/jsdom
[2]: https://dom.spec.whatwg.org/#concept-node-remove
[3]: 
https://github.com/tmpvar/jsdom/blob/master/lib/jsdom/living/node-iterator.js

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Jonas Sicking]

On Tue, Feb 16, 2016 at 7:50 PM, Isiah Meadows  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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Isiah Meadows]

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, 22:09 Mark S. Miller  wrote:

> What are the GC semantics specified for DOM? How are these observable?
>
>
> On Tue, Feb 16, 2016 at 7:04 PM, Isiah Meadows 
> 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.
>>
>> On Tue, Feb 16, 2016, 20:24 Allen Wirfs-Brock 
>> wrote:
>>
>>> 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 on the TC39 github site.  However, when a proposal, like
>>> this one, is actively being developed using contributions (eg, discussion)
>>> by multiple TC39 members it seems like the record of that SHOULD be
>>> included in the Ecma archives.  The best way to ensure that is for such
>>> discussion to be hosted on the TC39 github account, even if the proposal is
>>> only at stage 0.
>>>
>>> Allen
>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>
>
> --
> Cheers,
> --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Mark S. Miller]

What are the GC semantics specified for DOM? How are these observable?


On Tue, Feb 16, 2016 at 7:04 PM, Isiah Meadows 
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.
>
> On Tue, Feb 16, 2016, 20:24 Allen Wirfs-Brock 
> wrote:
>
>> 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 on the TC39 github site.  However, when a proposal, like this one,
>> is actively being developed using contributions (eg, discussion) by
>> multiple TC39 members it seems like the record of that SHOULD be included
>> in the Ecma archives.  The best way to ensure that is for such discussion
>> to be hosted on the TC39 github account, even if the proposal is only at
>> stage 0.
>>
>> Allen
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Isiah Meadows]

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.

On Tue, Feb 16, 2016, 20:24 Allen Wirfs-Brock  wrote:

> 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 on the TC39 github site.  However, when a proposal, like this one,
> is actively being developed using contributions (eg, discussion) by
> multiple TC39 members it seems like the record of that SHOULD be included
> in the Ecma archives.  The best way to ensure that is for such discussion
> to be hosted on the TC39 github account, even if the proposal is only at
> stage 0.
>
> Allen
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Allen Wirfs-Brock]

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 on the TC39 github site.  However, when a proposal, like this one, is 
actively being developed using contributions (eg, discussion) by multiple TC39 
members it seems like the record of that SHOULD be included in the Ecma 
archives.  The best way to ensure that is for such discussion to be hosted on 
the TC39 github account, even if the proposal is only at stage 0. 

Allen


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Dean Tribble]

I'm happy to do whatever is appropriate here. Is there a message I should
put in the Readme to emphasize the early stage?

On Tue, Feb 16, 2016 at 4:38 PM, Mark S. Miller  wrote:

>
>
> On Tue, Feb 16, 2016 at 4:26 PM, Kevin Smith  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:  https://github.com/zenparsing/async-iteration
>>
>>>
> Cool! I did not know that.
>
>
> --
> Cheers,
> --MarkM
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Mark S. Miller]

On Tue, Feb 16, 2016 at 4:26 PM, Kevin Smith  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:  https://github.com/zenparsing/async-iteration
>
>>
Cool! I did not know that.


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Kevin Smith]

>
> 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:  https://github.com/zenparsing/async-iteration

>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Mark S. Miller]

On Tue, Feb 16, 2016 at 3:52 PM, Kevin Smith  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 .
>

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.



>
> On 6:32PM, Tue, Feb 16, 2016 Mark S. Miller  wrote:
>
>> On Tue, Feb 16, 2016 at 2:02 PM, Daniel Ehrenberg <
>> dehrenb...@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?
>>
>>
>>
>>>
>>> Dan
>>>
>>> On Sun, Feb 14, 2016 at 11:35 PM, Dean Tribble 
>>> wrote:
>>> > I have posted a stage 1 proposal for weak references in ES7 for your
>>> perusal
>>> > and feedback.
>>> >
>>> > https://github.com/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.
>>> >
>>> > ___
>>> > es-discuss mailing list
>>> > es-discuss@mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>> >
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>>
>> --
>> Cheers,
>> --MarkM
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Kevin Smith]

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 .

On 6:32PM, Tue, Feb 16, 2016 Mark S. Miller  wrote:

> On Tue, Feb 16, 2016 at 2:02 PM, Daniel Ehrenberg  > 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?
>
>
>
>>
>> Dan
>>
>> On Sun, Feb 14, 2016 at 11:35 PM, Dean Tribble 
>> wrote:
>> > I have posted a stage 1 proposal for weak references in ES7 for your
>> perusal
>> > and feedback.
>> >
>> > https://github.com/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.
>> >
>> > ___
>> > es-discuss mailing list
>> > es-discuss@mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
> Cheers,
> --MarkM
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Mark S. Miller]

On Tue, Feb 16, 2016 at 2:02 PM, Daniel Ehrenberg 
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?



>
> Dan
>
> On Sun, Feb 14, 2016 at 11:35 PM, Dean Tribble  wrote:
> > I have posted a stage 1 proposal for weak references in ES7 for your
> perusal
> > and feedback.
> >
> > https://github.com/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.
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Daniel Ehrenberg]

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 Sun, Feb 14, 2016 at 11:35 PM, Dean Tribble  wrote:
> I have posted a stage 1 proposal for weak references in ES7 for your perusal
> and feedback.
>
> https://github.com/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.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Weak Reference proposal

[Dean Tribble]

I have posted a stage 1 proposal for weak references in ES7 for your
perusal and feedback.

https://github.com/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.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss