`free` operator

Hudson, Rick rick.hudson at intel.com
Sun Oct 28 15:07:44 PDT 2012


Another performance killing but valuable heap debugging tool, implementable if you have a GC write barrier that covers all pointer writes, is to have the write barrier trace any and all writes/overwrites of the pointer to the traced object. It isn't magic and the GC has to also trace the object as it is moved about but it is a step in the right direction and a tool I have used to debug GC implementations.

This type of functionality should be part of the debugger / software development environment and not part of the language,  performant runtime, or ES standard.

- Rick

-----Original Message-----
From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Brendan Eich
Sent: Sunday, October 28, 2012 4:49 PM
To: David Bruant
Cc: es-discuss
Subject: Re: `free` operator

Of course we are not going to add *unsafe* manual memory management to 
JS. No need to worry about that!

Isaac proposed safe yet horribly inefficient memory management, whereby 
any unwanted strong refs are found (by a global scan) and then nulled or 
set to undefined. This is bad for the reasons given on the thread, but 
also because it requires a full GC in general.

Safe and efficient manual memory management is a feature of Rust and 
other languages which range from "Research" to (at best) "Advanced 
Technology", and which seem to require fancy type/ownership systems.

As a debugging tool, something like Alex's assertFree (of course, you 
couldn't have a weak ref to pass in, so maybe assertSingleRef is a 
better name) could be done. Again, in some (many high performance) 
implementations, it would require a full mark/sweep GC. So it is a 
debug-build or debug-mode only tool, not to be used lightly.

What I did years ago as a debugging tool in SpiderMonkey, which I 
believe survives in the JS_DumpHeap C API, is along these lines. Rather 
than null any leaky paths to cover up the bug, it dumps all paths by 
which the allegedly single-ref (or just mysteriously still-alive) 
GC-thing-to-find that you pass in as an optional parameter still is 
connected to the graph of rooted live things.

The path names are formed by property names with unambiguous or 
sufficiently unlikely separators. Internal strong refs (e.g., roots in 
native data structures held as opaque or private parts of a JS object, 
e.g. a DOM object peering a C++ struct or class instance) may be given 
constant-string names when made strong (rooted).

Usually when debugging a leak, getting the set of strong-ref paths leads 
quickly to progress in fixing the bug.

/be

David Bruant wrote:
> 2012/10/26 Isaac Schlueter <i at izs.me <mailto:i at izs.me>>
>
>     (...)
>
>
>     We've got some band-aids in place in the node http.js file to prevent
>     parser leaks.  A more forcible free() method would have made it much
>     easier.  The long-term solution is to rewrite the program (...)
>
> So you're suggesting that a language-level feature with abusive 
> authority introducing use-after-free bugs (and maybe others) should be 
> included to solve short-term problems?
>
>     Yehuda's "action at a distance" complaint is definitely a valid
>     concern.  However, note that an object can't be freed unless you have
>     a reference to the object.
>
> Everyone has a reference to built-ins so a bug or an attacker could 
> free built-ins.
>
>     Thus, any code that would set my reference
>     to undefined could only do so if it was also capable of mutating the
>     object in any other way (adding/removing properties, etc.)
>
>     So, we already have this:
>
>     function () {
>     // acquire a ref from some external code
>     // no way of knowing what else is sharing this object
>     var x = func()
>     x.foo = 'bar'
>     // other code...
>     doAnotherThing()
>     // not guaranteed!
>     assert(x.foo === 'bar')
>     }
>
> With non-configurable properties and making objects non-extensible, 
> you have a way to prevent this, a way to protect your objects from 
> "action at a distance". Even proxies are required to respect some 
> invariants for the sake of application securability.
> The free operator you're proposing cannot be protected against. Anyone 
> can release any object it has a reference to without the object 
> creator (or the other object reference holder) having their word to 
> say to prevent it. That's unbalanced.
>
>     Whenever you have a reference to an object that is shared with some
>     other code, there's the potential for action at a distance.  The
>     proposal here is to make that action a bit more powerful.
>
>     I don't agree that it's necessarily a problem in production.  We free
>     objects in other languages all the time.
>
> I agree with you, C and C++ are absurdly unsafe languages. No wonder 
> double free and use after-free bugs are so common! As the rumor goes, 
> use-after-free bugs lead to security issues sometimes [1]. Really not 
> an example to follow in my opinion.
>
> What do you think about the revokable proxy solution? I agree it's 
> less sexy than a 4-letter keyword operator, but it's close enough to 
> standard and seems to solve your short-term issue as efficiently.
> Tom's shim [2] simulates the direct proxy API on top of the current 
> V8's one. It includes revokable proxies I see. It can work today (as 
> in Sat Oct 27th 2012) I think.
>
> David
>
> [1] http://www.mozilla.org/security/announce/2012/mfsa2012-85.html 
> (just pick the first result Google gave me against "use after free 
> security").
> [2] https://github.com/tvcutsem/harmony-reflect
> _______________________________________________
> 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


More information about the es-discuss mailing list