`free` operator

Herby Vojčík herby at mailbox.sk
Sat Oct 27 04:18:48 PDT 2012

Issac, what about the already mentioned way of revokable proxies? Why 
don't you go that way - it should be pretty easy to create (primitive 
version of) them at C++ level, if they're not in V8 yet. Just a wrapper 
around the object forwarding everything to its target until it gets the 
signal to stop that, whereupon it frees the reference (thus, GC clears 
it). You can even log / throw at the point of access-past-revocation, 
thus find the code that holds and uses it.


Isaac Schlueter wrote:
> So, yes, you can certainly use debugging tools to find which objects
> are leaking.  But, there are times when you have a program where
> something is leaking, and you read through the code, and see that
> there is no possible way that it could be leaking (but it is, as
> reality sometimes stubbornly refuses to be told what to do.)
> Use-after-free bugs are not great, but they are relatively easy to
> track down.  And, in general, a program that crashes when it does
> something wrong, is handling it exactly right.  Slowly leaking memory
> is much harder to diagnose, and usually much harder to correct.
> 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 that it's
> not so badly architected, but as is so often the case, we didn't
> realize the architectural mistakes until we had made them, and fixing
> them is quite costly.  (Node's http implementation will get a massive
> refactor in 0.12.)
> 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.  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')
> }
> 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.
> On Fri, Oct 26, 2012 at 5:11 PM, Patrick Mueller<pmuellr at gmail.com>  wrote:
>> On Fri, Oct 26, 2012 at 11:51 AM, John J Barton
>> <johnjbarton at johnjbarton.com>  wrote:
>>> Debugging tools lag other tools in part because test-cases or
>>> use-models are hard not readily available.
>> But the only debugging tools we really have are proprietary low-level APIs
>> (eg, V8 debug stuff), and some existing debug ui frameworks (eg, Web
>> Inspector).  The barrier is so, so high for this stuff.  Compared to a
>> number of other environments where the barrier is not so high.  Eg, in C, if
>> you're debugging memory issues, switching to using a debug malloc library
>> isn't a huge barrier.
>> It would be nice to lower the barrier, expose some "debug" stuff in JS.
>> Implying that I want "debug APIs" available in JS, and I want to write my
>> debug helpers in JS.
>> V8's --expose-debug-as (or whatever) trick is a step in the right direction.
>> It would be nice to have some commonality here, so I don't have to write one
>> set of debug helpers for V8, another for JSC, another for *Monkey, etc.
>>> The js-tools group would be ideal for more discussions of these
>>> issues: https://groups.google.com/forum/?fromgroups=#!forum/js-tools
>> Ah, nice.  I'll stop pestering here, and start pestering there.  :-)
>> --
>> Patrick Mueller
>> http://muellerware.org
>> _______________________________________________
>> 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