First of all for an arbitrary object in a garbage collected
environment you can't get an instant notification when objects is no
longer referenced. GC does not know that until it runs.

If you are fully controlling the way objects are produced and consumed
you can implement your own memory management (e.g. reference counting
based scheme) in pure JS (but it will be error prone).

That said if you are doing server side JS you can easily expose
MakeWeak to your code. Some node.js modules do that.

--
Vyacheslav Egorov


On Tue, Jul 10, 2012 at 3:33 PM, mschwartz <[email protected]> wrote:
> I was reading this great commentary on V8:
> http://code.google.com/p/v8-juice/wiki/CommentaryOnV8
>
> I think most of it still applies.
>
> JavaScript doesn't have a concept of destructors like many OO languages, but
> in a server-side context, there's a real need for them.  Garbage collection
> in JavaScript is done behind the scenes on objects that are no longer
> referenced.  When would you call an object's destructor: 1) when it is no
> longer referenced, or 2) when it is garbage collected?
>
> I suggest that if we could have some "destructor" support in v8, that it be
> the former (no longer referenced).  It is critical in server-side
> environments that any (external) resources can be freed as soon as possible.
> For example, there are a limited number of file descriptors (fds) available
> to a Unix/Linux system, and if they're all tied up (open) in some JS object
> that's been dereferenced, the server can run out of them.  If you deal with
> fds in wrapped C++ classes made as weak references, those fds can be tied up
> for a long long time, until v8 maybe decides to GC and call the weak
> callback.  But if there were a mechanism to register a callback to be called
> when an object is no longer referenced, the fds could be closed and released
> to the OS/application for reuse long before V8 maybe decides to garbage
> collect.
>
> Generally, application developers pretty much know when they're effectively
> doing a C++ style delete of a JS object (by dereferencing it), so they could
> be forced to call an agreed upon method, say destroy(), at that time.  But I
> don't find that so elegant, and it's error prone and can lead to
> memory/resource leaks that are hard to track down.
>
> I note that JavaScript 1.8.5 provides this:
> https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/defineProperty
>
> It leads me to ponder a similar mechanism that might be trivially
> implemented by the v8 team to help us server-side developers out.  I mean,
> there are means to define getters and setter and with Harmony there are
> proxies.  Basically, a lot of functionality that was restricted to C++ code
> (like MakeWeak) are being exported to JS.
>
> It's time to provide a mechanism to allow us to define a MakeWeak callback
> in JS from JS, and ultimately to also implement a destructor type function
> when an object becomes fully dereferenced.
>
> Am I missing something that's already there?
>
> --
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users

-- 
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users

Reply via email to