memory safety and weak references

Hudson, Rick rick.hudson at intel.com
Mon Apr 1 14:37:21 PDT 2013


This brings up another interesting point. Do WeakRefs change a compiler's liveness analysis? This could complicate some apparently useful optimizations.

{
    var x = new Something();
    someWeakRef.set(x);
    // Is x dead? (yes) Is x required to contribute to the root set? (I hope not.)
    gc();
    someWeakRef.get() // null or foo?
    ...
}


-        Rick
For the optimization see
@inproceedings{Agesen:1998:GCL:277650.277738,
author = {Agesen, Ole and Detlefs, David and Moss, J. Eliot},
title = {Garbage collection and local variable type-precision and liveness in Java virtual machines},
booktitle = {Proceedings of the ACM SIGPLAN 1998 conference on Programming language design and implementation},
series = {PLDI '98},
year = {1998},
isbn = {0-89791-987-4},
location = {Montreal, Quebec, Canada},
pages = {269--279},
numpages = {11},
url = {http://doi.acm.org/10.1145/277650.277738},
doi = {10.1145/277650.277738},
acmid = {277738},
publisher = {ACM},
address = {New York, NY, USA},
}
From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Oliver Hunt
Sent: Monday, April 01, 2013 4:37 PM
To: Marius Gundersen
Cc: es-discuss discussion
Subject: Re: memory safety and weak references

There are numerous problems with weak references and primitives, mostly revolving around the ability to regenerate a primitive, e.g.

    someWeakRef.set("foo")
    gc()
    var something = "foo"
    someWeakRef.get() // null or "foo"?

 vs.

    someWeakRef.set("foo")
    var something = "foo"
    gc()
    someWeakRef.get() // null or "foo"?

vs.

    someWeakRef.set("foo")
    var something = "fo"
    something += "o"
    gc()
    someWeakRef.get() // null or "foo"?

And of course all this just becomes worse for numeric primitives -- All existing engines use tagged values for some set of numeric values, and can also end up with the same value stored in different ways.  V8 (at least in 32bit) gc allocates doubles, but not a subset of integers, this means that if you get the value 1 as a double then it might be gc'd and so the weak ref could go away, but if it were in the tagged int form it would not.

JSC doesn't immediately intern strings, but over time duplicates do get merged, at which point weakness starts acquiring odd behaviour.  Because off the implicitly shared heap in different pages this may even be exploitable as a way to find out information about other pages (essentially the weak reference to a primitive allows a side channel for determining content of other pages that you would not otherwise have access to)

This means that any consistent semantic for primitives results in useless behaviour - either the weak ref has to be (essentially) strong on primitives, or be cleared on ever gc() regardless of "liveness" of other references.

--Oliver


On Apr 1, 2013, at 1:22 PM, Marius Gundersen <gundersen at gmail.com<mailto:gundersen at gmail.com>> wrote:


This seems to be more a problem with the garbage collector than with weak references. If I understood it correctly, any double value can look like a pointer, and the garbage collector will check what it is pointing at. To me this seems like a source for memory leaks. This problem exists even without weak references (or weak iterable maps/sets); the weak references just makes it observable. Does this mean the main reason weak references (or, again, weak iterable maps/sets) are not to be implemented is because of a bug in the garbage collector of popular JS enginges? As noted earlier, the implementation of the garbage collector is not specified in the ecmascript standard, so this is a problem with implementors, not with the specification.
Again, I'm far from an expert on GC or JS implementations (and would love a simplified explanation if I have misunderstood the problem), but this seems less like a problem with weak references, and more like a problem with specific implementations of GCs.
Marius Gundersen

On Fri, Mar 29, 2013 at 3:47 AM, Oliver Hunt <oliver at apple.com<mailto:oliver at apple.com>> wrote:

On Mar 29, 2013, at 7:36 AM, David Herman <dherman at mozilla.com<mailto:dherman at mozilla.com>> wrote:

> On Mar 27, 2013, at 4:52 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu<mailto:samth at ccs.neu.edu>> wrote:
>
>> On Tue, Mar 26, 2013 at 11:44 PM, Oliver Hunt <oliver at apple.com<mailto:oliver at apple.com>> wrote:
>>> That said I believe that this does kill any dreams i may have had w.r.t primitive-keyed WeakMaps, kudos to MarkM.
>>
>> Wouldn't a primitive-keyed WeakMap just be a strong Map for those
>> keys?  And therefore immune to any GC attacks?
>
> Indeed, and also deeply misleading (a weak map with strongly held entries?), which is why I argued that WeakMap should disallow primitive keys.
>
> Oliver-- can you clarify what you were hoping for?
I was dreaming of primitive keys, i was convinced in an earlier meeting of the problems that they would cause, but this security problem is a nail in the coffin :-/

>
> Dave
>

_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130401/9fcde14f/attachment-0001.html>


More information about the es-discuss mailing list