On 11/01/2013 11:52 AM, David Bruant wrote:
One use case of cross-vat communication is the remote debugger
protocol implemented in Firefox/OS. I haven't taken the time to run
over related bugs and follow its development (and probably won't for
now, because it'd be a lot of work), but it'd be in
On 11/01/2013 10:48 AM, Steve Fink wrote:
Why? I agree, but only for some general reasons and some
dimly-remembered reasons that I've encountered in the past where the
implications turned out to be far worse than I would have initially
thought. I'd really like to have a crisp explanation of exact
For completeness (and irrelevant to this particular message I am replying...) I
should mention that Bill pointed out in email that the cycle collector can't be
completely oblivious to weak references, as I said before. Right now, when the
CC identifies a JS object as garbage, it doesn't do anyt
This topic has come up on es-discuss again[1], with Mark Miller
referencing[2] an older post of his to the list that contains a proposal
for mitigating the issues with making GCs visible[3].
[1]: https://mail.mozilla.org/pipermail/es-discuss/2013-November/034619.html
[2]: https://mail.mozilla.org
Terrence Cole wrote:
Recently, Luke tried turning down the incremental slice time
knob to see how low we could go. He found that2ms is easily doable,
except when traversing the browser C++ heap, taking about6ms.
I wonder how this scales on, say, a Nexus 4 (not to drag us all down to
a ZTE Ope
On 11/02/2013 02:59 PM, Brendan Eich wrote:
> David Bruant wrote:
>> Article version and longer talk at
>> http://www.html5rocks.com/en/tutorials/memory/effectivemanagement/
>
> Thanks.
>
>>> They showed historical plots revealing gmail bugs, V8 GC regressions,
>>> all the interesting dirt. Their
On 11/02/2013 10:24 AM, Allen Wirfs-Brock wrote:
>
> On Nov 1, 2013, at 3:17 PM, Jason Orendorff wrote:
>
>> On 11/1/13 1:52 PM, David Bruant wrote:
>>> In any case, I've stopped being against weakrefs after a message by
>>> Mark Miller[...]
>> I am now going to try to convince you that you shoul
On 11/03/2013 08:16 AM, Brendan Eich wrote:
> Bobby Holley wrote:
>> This won't solve esoteric cross-vat use cases, but I think it would be a
>> nice way to bulldoze the subtle gotchas that make it so easy to introduce
>> subtle leaks in large-scale JS.
>
> With an MVC framework, nukeSandbox is of
Bobby Holley wrote:
On Sun, Nov 3, 2013 at 1:50 PM, David Bruant wrote:
> hueyfix-style tools for client code or implementors?
> Client code will have one in ES6 in the form of revocable proxies. Initial
> post on the topic (mentioning GC specifically) [1] and API [2] (also
> available in
On Sun, Nov 3, 2013 at 1:50 PM, David Bruant wrote:
> hueyfix-style tools for client code or implementors?
> Client code will have one in ES6 in the form of revocable proxies. Initial
> post on the topic (mentioning GC specifically) [1] and API [2] (also
> available in the latest ES6 draft).
>
Y
On Nov 1, 2013, at 3:17 PM, Jason Orendorff wrote:
> On 11/1/13 1:52 PM, David Bruant wrote:
>> In any case, I've stopped being against weakrefs after a message by
>> Mark Miller[...]
> I am now going to try to convince you that you shouldn't have been
> convinced by this use case. :)
>
>> To ke
On Nov 1, 2013, at 1:26 PM, Terrence Cole wrote:
> ...
>
> Secondly, correctness. The GC is by definition a cross-cutting concern;
> you cannot build anything in SpiderMonkey without considering GC. This
> makes weak primitives a cross-cutting concern of a cross-cutting
> concern. Our experience
On Nov 3, 2013, at 1:07 PM, Niko Matsakis wrote:
>
> In any case, Brendan's e-mail suggesting tenuring weakly referenced
> objects offered one possible workaround for maintaining top nursery
> performance in the face of weak refs. (I have no idea, of course, if
> this is what the JVM does.)
>
Niko Matsakis wrote:
- Why do you say Java doesn't have a weakmap? What is the
[WeakHashMap][2] class if not a WeakMap? Presumably we are using the
term differently? (I imagine there are many variations of weakmaps
which vary in subtle but significant ways)
Quoting from [2]:
"*Impleme
On 11/01/2013 05:26 PM, Jason Orendorff wrote:
This proposal is before TC39 for inclusion in the next ECMAScript spec
edition following ES6:
http://wiki.ecmascript.org/doku.php?id=strawman:weak_references
Mozilla GC hackers are opposed, for reasons they can articulate; I'm
opposed because I c
On 3 November 2013 22:07, Niko Matsakis wrote:
> - Aren't we talking about weak refs? I thought a weakmap in JS was a
> done deal? I believe Java's weak refs, and in particular weak
> references when combined with [reference queues][1], are pretty
> similar to what the strawman proposed.
>
>
On Sun, Nov 3, 2013 at 10:07 PM, Niko Matsakis wrote:
> On Sat, Nov 02, 2013 at 09:22:31PM +0100, Igor Bukanov wrote:
> > On 2 November 2013 12:24, Niko Matsakis wrote:
> > > The Java VM (where G1 was developed) supports weak refs. Any idea what
> is
> > > different there or how they managed it?
On Sat, Nov 02, 2013 at 09:22:31PM +0100, Igor Bukanov wrote:
> On 2 November 2013 12:24, Niko Matsakis wrote:
> > The Java VM (where G1 was developed) supports weak refs. Any idea what is
> > different there or how they managed it?
>
> Java does not have WeakMap. Weak references, despite their
>
Bobby Holley wrote:
This won't solve esoteric cross-vat use cases, but I think it would be a
nice way to bulldoze the subtle gotchas that make it so easy to introduce
subtle leaks in large-scale JS.
With an MVC framework, nukeSandbox is of no avail. The subject does not
want to extend the life
Le 03/11/2013 11:29, Bobby Holley a écrit :
The problem with weak references is that they put the GC in the driver's
seat, which makes it very hard to avoid revealing GC secrets to the client.
Instead, I propose that we let the client code drive, and see how far we
get with hueyfix-style tools.
Le 03/11/2013 12:49, Jorge Chamorro a écrit :
When would be the right time to free(something)?
What would `something` be after the call to free(), null?
What if `something` isn't the only reference to the thing?
I don't think Bobby was suggesting the addition of a free function or
operator. Th
On 3 November 2013 12:49, Jorge Chamorro wrote:
> If not, what exactly would free(thing) do?
That is is easy - it ensures that the thing does not reference any
other GC things (including references as keys in a WeakMap) so it
cannot be a part of reference cycle. Currently this cannot be even
impl
On 2 November 2013 15:28, David Bruant wrote:
>>function f(e){tellSomebodyAboutTheEvent(x);}
>>
>>(function(){
>>var iframe = document.getElementByTagName('iframe')[0];
>>iframe.addEventListener('someEvent', f);
>>})()
>>
> There is a point in your p
On 03/11/2013, at 11:29, Bobby Holley wrote:
>
>
> What if we give script the ability to say "this Foo is semantically dead -
> please neuter cross-global references to it"? This is effectively what we
> have with Cu.nukeSandbox, and it works well. It doesn't in any way expose
> GC behavior, but
The problem with weak references is that they put the GC in the driver's
seat, which makes it very hard to avoid revealing GC secrets to the client.
Instead, I propose that we let the client code drive, and see how far we
get with hueyfix-style tools.
One of the major difficulties with leak preven
David Bruant wrote:
Article version and longer talk at
http://www.html5rocks.com/en/tutorials/memory/effectivemanagement/
Thanks.
They showed historical plots revealing gmail bugs, V8 GC regressions,
all the interesting dirt. Their tooling is great
I wouldn't say "great". It's state-of-the-ar
Le 02/11/2013 20:41, Brendan Eich a écrit :
At JSConf.eu, John McCutchan of Google and a colleague who works on
gmail gave a good talk on GC, showing off Chrome's memory profiling tool.
Article version and longer talk at
http://www.html5rocks.com/en/tutorials/memory/effectivemanagement/
They s
On 2 November 2013 12:24, Niko Matsakis wrote:
> The Java VM (where G1 was developed) supports weak refs. Any idea what is
> different there or how they managed it?
Java does not have WeakMap. Weak references, despite their
expose-GC-to-the-world semantics, are much easier to implement.
WeakMap i
Terrence Cole wrote:
The performance of the web is vital. With gaming and video as
first-class citizens, we have to consider both the throughput and
latency of the GC as priorities. Any added complexity in the GC will
either directly make the web slower or will disproportionately divert
our energ
Allen Wirfs-Brock wrote:
My experience is that Terrence is absolutely correct in this regard
and that this position is share by virtually all experienced GC
implementors. A former colleague of mine, George Bosworth, expressed
it this way in an experience report at a ISMM a number of years ago:
Steve Fink wrote:
Yeah, that's some very critical weasel-wording in the strawman. "Let's
add this to the language, but not expose it to things it shouldn't be
exposed to." Huh?
To be fair to the author, Mark Miller, he knows well that this must be
specified. It's not, ergo (among other reasons
Le 01/11/2013 23:17, Jason Orendorff a écrit :
On 11/1/13 1:52 PM, David Bruant wrote:
In any case, I've stopped being against weakrefs after a message by
Mark Miller[...]
I am now going to try to convince you that you shouldn't have been
convinced by this use case. :)
You can try :-p
To kee
Le 01/11/2013 21:13, Andrew McCreight a écrit :
- Original Message -
Why so?
function f(e){}
(function(){
var iframe = document.getElementByTagName('iframe')[0];
iframe.addEventListener('someEvent', f);
})()
In this case, f doesn't hold a referenc
On Fri, Nov 01, 2013 at 01:26:14PM -0700, Terrence Cole wrote:
> First, performance: this particular proposal would force us to visit
> objects that are being swept.
This is an interesting ramification that should have been obvious in
retrospect.
> Our nursery design is currently such that this i
On 11/1/13 1:52 PM, David Bruant wrote:
> In any case, I've stopped being against weakrefs after a message by
> Mark Miller[...]
I am now going to try to convince you that you shouldn't have been
convinced by this use case. :)
> To keep the object granularity across machines, in E, they've created
On 11/01/2013 08:26 AM, Jason Orendorff wrote:
> This proposal is before TC39 for inclusion in the next ECMAScript spec
> edition following ES6:
> http://wiki.ecmascript.org/doku.php?id=strawman:weak_references
>
> Mozilla GC hackers are opposed, for reasons they can articulate; I'm
> opposed be
- Original Message -
> Why so?
>
> function f(e){}
>
> (function(){
> var iframe = document.getElementByTagName('iframe')[0];
> iframe.addEventListener('someEvent', f);
> })()
>
> In this case, f doesn't hold a reference to anything besides itself, not
>
On 11/01/2013 11:52 AM, David Bruant wrote:
> That requires weakrefs in some way, I'm afraid. I'm interested if
> other solutions can be proposed to achieve object-granularity
> communication across machines (I'm sure Mark Miller will be interested
> as well).
>
Good use case. What if you had a se
On 11/1/13 3:10 PM, David Bruant wrote:
Why so?
function f(e){}
(function(){
var iframe = document.getElementByTagName('iframe')[0];
iframe.addEventListener('someEvent', f);
})()
This is very fragile. It assumes that nowhere up the scopes that f is
closing o
Le 01/11/2013 19:34, Andrew McCreight a écrit :
3. Finally, though I'm generally opposed to weak references, as they are
complex to implement, I do understand that there's a need for them. When
working on the leaks in bug 893012, to fix some of the individual leaks, like
bug 894147, we had to
[sorry for previous early send error]
Hi,
Le 01/11/2013 16:26, Jason Orendorff a écrit :
This proposal is before TC39 for inclusion in the next ECMAScript spec
edition following ES6:
http://wiki.ecmascript.org/doku.php?id=strawman:weak_references
Mozilla GC hackers are opposed, for reasons
I have a few disjoint thoughts here.
1. Here's a link to a previous ES-discuss thread about somebody trying to
create an exploit by combining observable weak references with conservative GC.
https://mail.mozilla.org/pipermail/es-discuss/2013-March/029489.html
I think the basic idea is that yo
On 11/01/2013 09:42 AM, Bobby Holley wrote:
> From the proposal:
>
> Note that makeWeakRef is not safe for general access since it grants access
>> to the non-determinism inherent in observing garbage collection.
>
> What does that mean? That they don't expect this to be exposed to the web?
> In th
Hi,
Le 01/11/2013 17:42, Bobby Holley a écrit :
From the proposal:
Note that makeWeakRef is not safe for general access since it grants access
to the non-determinism inherent in observing garbage collection.
What does that mean? That they don't expect this to be exposed to the web?
In tha
>From the proposal:
Note that makeWeakRef is not safe for general access since it grants access
> to the non-determinism inherent in observing garbage collection.
What does that mean? That they don't expect this to be exposed to the web?
In that case, why bother speccing it, and why would we nee
This proposal is before TC39 for inclusion in the next ECMAScript spec
edition following ES6:
http://wiki.ecmascript.org/doku.php?id=strawman:weak_references
Mozilla GC hackers are opposed, for reasons they can articulate; I'm
opposed because I can't stick the nondeterminism and because the tota
46 matches
Mail list logo
