The point I'm trying to make is that v8 obviously has a need for MakeWeak()
in C++ land, and for the reasons it exists there, the same reasons exist in
JavaScript code.
JavaScript proper doesn't provide for a finalize() kind of mechanism like
Java does (I'm not particularly a Java fan), but Java saw the need for
implementing such a thing.
I've been fed the line that garbage collection, as done in languages like
C#, Java, JavaScript, et al, was meant to free the programmer from making
certain mistakes. The answer that we should manually call a destroy() type
function because we know it's a good time to do so suggests we should call
delete (operator) as well for every object we call new (operator).
I think we're in 100% agreement that finalization time is a poor time to
manage resource deallocation. This is the point of my suggestion that
there be some mechanism to register a destructor with the JS engine for the
object that is called when completely dereferenced.
Sometimes you can express things in JavaScript that make calling a
destroy() function impossible:
var binary = new BinaryThing('abc').concat(new BinaryThing('def'));
The 'def' one is created and dereferenced without a means to call its
destroy() method. Assume BinaryThing is written in JavaScript, but makes
calls to C++ code that allocates system resources.
The ECMAScript 1.8.5 method I referenced is an example of how the language
(or environment) has evolved to address things lacking in previous versions
(such as the ability to protect properties from deletion).
Cheers
On Tuesday, July 10, 2012 6:57:54 AM UTC-7, Andreas Rossberg wrote:
>
> On 10 July 2012 15:33, mschwartz <myk...@gmail.com> wrote:
>
>> JavaScript doesn't have a concept of destructors like many OO languages,
>>
>
> I think "most OO languages" is an exaggeration. Rather, it is an artifact
> of the few (though popular) OO-languages with manual memory management.
>
>
>
>> 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?
>>
>
> In practice, there is no difference between (1) and (2), because you
> cannot generally find out that something is no longer referenced except by
> doing (most of the work of) a garbage collection. At least not in a
> language with first-class functions and objects.
>
>
>
>> 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.
>>
>
> You are talking about finalization. It is folklore that using finalization
> for managing resources other than memory (especially limited resources like
> OS handles) is almost always a bad idea, because garbage collection is far
> too non-deterministic for that. You will have no guarantee that finalizers
> are invoked in a timely manner, because the GC cannot tell.
>
>
> I note that JavaScript 1.8.5 provides this:
>>
>> https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/defineProperty
>>
>
> Maybe I misunderstand, but Object.defineProperty is perfectly standard ES5
> functionality, and fully supported by V8. Where do you see the connection
> to finalization?
>
> /Andreas
>
>
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
