memory safety and weak references

Mark S. Miller erights at google.com
Mon Apr 1 15:17:04 PDT 2013


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

> If the compiler can prove x does not escape the block and it is not used
> again then it is dead and the compiler is free to reuse the stack slot
> holding the last reference.
>
> So I am arguing that x = null; is not required to kill x.
>
> If we agree on that then I think we agree that someWeakRef.get(); is
> allowed to return null.
>

I see. I misunderstood the question. Yes, I believe this should be allowed
but not required. <
http://wiki.ecmascript.org/doku.php?id=strawman:gc_semantics> states "Our
safety requirements allow some reachable objects to be collected as well,
so long as the garbage collector can ascertain that they will never be
reached."




>
> - Rick
>
> -----Original Message-----
> From: Brendan Eich [mailto:brendan at mozilla.com]
> Sent: Monday, April 01, 2013 5:56 PM
> To: Hudson, Rick
> Cc: Oliver Hunt; Marius Gundersen; es-discuss discussion
> Subject: Re: memory safety and weak references
>
> Hudson, Rick wrote:
> >
> > This brings up another interesting point. Do WeakRefs change a
> > compiler's liveness analysis?
> >
>
> Yes, of course.
>
> > 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.)
> >
>
> You dind't kill x yet. Did you forget
>
> x = null;
>
> here?
>
> > gc();
> >
> > someWeakRef.get() // null or foo?
> >
>
> If x = null; happened before gc() then null else the original ref.
>
> /be
>
> > ...
> >
> > }
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130401/6f4beed3/attachment.html>


More information about the es-discuss mailing list