memory safety and weak references

Kevin Gadd kevin.gadd at gmail.com
Mon Apr 1 14:40:50 PDT 2013


In that case it would be alive unless you destroyed the local variable 'x',
but in some environments the compiler is free to treat it as dead. I
believe in .NET the variable 'x' is only alive up until its last reference,
so the variable would become dead immediately after the construction of the
weak reference. The WR itself definitely should not affect object liveness.
If you mean liveness in terms of like... escape analysis? Then I think you
would have no issues as long as the weak reference doesn't escape.
Optimization in the presence of weak references is probably not something
authors should rely on, though.

P.S. That gc() call wouldn't be guaranteed to collect x. The GC is free to
keep it alive for whatever reason it chooses (I'm not aware of any of these
reasons, but I've encountered this behavior before)


On Mon, Apr 1, 2013 at 2:37 PM, Hudson, Rick <rick.hudson at intel.com> wrote:

>  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> 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> wrote:****
>
>
> On Mar 29, 2013, at 7:36 AM, David Herman <dherman at mozilla.com> wrote:
>
> > On Mar 27, 2013, at 4:52 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>
> wrote:
> >
> >> On Tue, Mar 26, 2013 at 11:44 PM, Oliver Hunt <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
> https://mail.mozilla.org/listinfo/es-discuss****
>
> ** **
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


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


More information about the es-discuss mailing list