After figuring out how to wrap a class, with the help of another site,
I have run into a strange issue ... or undocumented feature ... which
there seems to be a lot of.
When i create an object, lets say EventManager, it calls back to C++
and uses the new keyword and wraps itself into several v8 objects.
That is fine; however, when I do something like
var evtMgr = new EventManager();
and then turn around and do
delete evtMgr;
The object still exists. Futhermore, when the program exits it leaves
a dangling pointer to the EventManager object that was created. In
addition to this, any object or variable that i create by doing
NS = {};
delete NS;
Works just fine and
var foo = 20;
delete foo;
Does not remove the variable. Any thoughts on this?
> After figuring out how to wrap a class, with the help of another site,
> I have run into a strange issue ... or undocumented feature ... which
> there seems to be a lot of.
> When i create an object, lets say EventManager, it calls back to C++
> and uses the new keyword and wraps itself into several v8 objects.
> That is fine; however, when I do something like
> var evtMgr = new EventManager();
> and then turn around and do
> delete evtMgr;
> The object still exists. Futhermore, when the program exits it leaves
> a dangling pointer to the EventManager object that was created. In
> addition to this, any object or variable that i create by doing
> NS = {};
> delete NS;
> Works just fine and
> var foo = 20;
> delete foo;
> Does not remove the variable. Any thoughts on this?
> This is also with the case with the shell program in the example code.
> On Jun 8, 7:05 pm, CodeJunkie <isrne...@gmail.com> wrote:
> > After figuring out how to wrap a class, with the help of another site,
> > I have run into a strange issue ... or undocumented feature ... which
> > there seems to be a lot of.
> > When i create an object, lets say EventManager, it calls back to C++
> > and uses the new keyword and wraps itself into several v8 objects.
> > That is fine; however, when I do something like
> > var evtMgr = new EventManager();
> > and then turn around and do
> > delete evtMgr;
> > The object still exists. Futhermore, when the program exits it leaves
> > a dangling pointer to the EventManager object that was created. In
> > addition to this, any object or variable that i create by doing
> > NS = {};
> > delete NS;
> > Works just fine and
> > var foo = 20;
> > delete foo;
> > Does not remove the variable. Any thoughts on this?
On Thu, Jun 9, 2011 at 4:05 AM, CodeJunkie <isrne...@gmail.com> wrote:
> var evtMgr = new EventManager();
> and then turn around and do
> delete evtMgr;
> The object still exists.
Unlike C++, new and delete in JavaScript are not related to each other. The keyword new constructs a new object. However, the keyword delete removes a *property* from an object. The value named by the property will not necessarily be garbage collected---there may be other references to it. The value is normally not deallocated immediately in any case.
Properties introduced with 'var' are not deletable, so 'delete' correctly does not delete the property.
> addition to this, any object or variable that i create by doing > NS = {}; > delete NS;
> Works just fine and
> var foo = 20; > delete foo;
> Does not remove the variable. Any thoughts on this?
Properties introduce with 'var' are not deletable. Most other properties are.
Kevin is absolutely correct. On top of that, you can actually check whether a delete operations works - it is an expression that evaluates to either true or false, depending on whether it manages to delete the property. In this case it evaluates to false, which you can see by doing, e.g., print(delete foo); in the shell.
On Thu, Jun 9, 2011 at 06:58, Kevin Millikin <kmilli...@chromium.org> wrote: > On Thu, Jun 9, 2011 at 4:05 AM, CodeJunkie <isrne...@gmail.com> wrote:
>> var evtMgr = new EventManager();
>> and then turn around and do
>> delete evtMgr;
>> The object still exists.
> Unlike C++, new and delete in JavaScript are not related to each other. The > keyword new constructs a new object. However, the keyword delete removes a > *property* from an object. The value named by the property will not > necessarily be garbage collected---there may be other references to it. The > value is normally not deallocated immediately in any case. > Properties introduced with 'var' are not deletable, so 'delete' correctly > does not delete the property.
>> addition to this, any object or variable that i create by doing >> NS = {}; >> delete NS;
>> Works just fine and
>> var foo = 20; >> delete foo;
>> Does not remove the variable. Any thoughts on this?
> Properties introduce with 'var' are not deletable. Most other properties > are.
Hmm, yes I did test if the delete operation worked.
But I am getting some conflicting info regarding what the chrome
console can do opposed to what a base v8 build can do.
Suppose you test this:
V = {};
V.X = new Object("Test");
delete V.X; // returns true in chrome, false in the shell program
delete V; // returns true in both;
V = {};
V.X = new Object();
delete V.X // Returns true in both
delete V; // returns true in both
// Native testing with v8
V = {};
V.X = new EventEngine();
delete V.X; // false;
delete V; // true,
Now X is lost and dangling. The C++ destructor is never called, even
at program exit. Supposedly MakeWeak will take care of this but
possibly slow down v8?
On Jun 8, 10:18 pm, "Lasse R.H. Nielsen" <l...@chromium.org> wrote:
> Kevin is absolutely correct. On top of that, you can actually check
> whether a delete operations works - it is an expression that evaluates
> to either true or false, depending on whether it manages to delete the
> property. In this case it evaluates to false, which you can see by
> doing, e.g.,
> print(delete foo);
> in the shell.
> /Lasse
> On Thu, Jun 9, 2011 at 06:58, Kevin Millikin <kmilli...@chromium.org> wrote:
> > On Thu, Jun 9, 2011 at 4:05 AM, CodeJunkie <isrne...@gmail.com> wrote:
> >> var evtMgr = new EventManager();
> >> and then turn around and do
> >> delete evtMgr;
> >> The object still exists.
> > Unlike C++, new and delete in JavaScript are not related to each other. The
> > keyword new constructs a new object. However, the keyword delete removes a
> > *property* from an object. The value named by the property will not
> > necessarily be garbage collected---there may be other references to it. The
> > value is normally not deallocated immediately in any case.
> > Properties introduced with 'var' are not deletable, so 'delete' correctly
> > does not delete the property.
> >> addition to this, any object or variable that i create by doing
> >> NS = {};
> >> delete NS;
> >> Works just fine and
> >> var foo = 20;
> >> delete foo;
> >> Does not remove the variable. Any thoughts on this?
> > Properties introduce with 'var' are not deletable. Most other properties
> > are.
So I guess my real question is, how do I "delete", remove, kill, etc.
a native bound object? And yes I am aware of the GC and that it will
clean up when there are no more references to said object ... and when
it feels it needs to collect.
On Jun 8, 10:18 pm, "Lasse R.H. Nielsen" <l...@chromium.org> wrote:
> Kevin is absolutely correct. On top of that, you can actually check
> whether a delete operations works - it is an expression that evaluates
> to either true or false, depending on whether it manages to delete the
> property. In this case it evaluates to false, which you can see by
> doing, e.g.,
> print(delete foo);
> in the shell.
> /Lasse
> On Thu, Jun 9, 2011 at 06:58, Kevin Millikin <kmilli...@chromium.org> wrote:
> > On Thu, Jun 9, 2011 at 4:05 AM, CodeJunkie <isrne...@gmail.com> wrote:
> >> var evtMgr = new EventManager();
> >> and then turn around and do
> >> delete evtMgr;
> >> The object still exists.
> > Unlike C++, new and delete in JavaScript are not related to each other. The
> > keyword new constructs a new object. However, the keyword delete removes a
> > *property* from an object. The value named by the property will not
> > necessarily be garbage collected---there may be other references to it. The
> > value is normally not deallocated immediately in any case.
> > Properties introduced with 'var' are not deletable, so 'delete' correctly
> > does not delete the property.
> >> addition to this, any object or variable that i create by doing
> >> NS = {};
> >> delete NS;
> >> Works just fine and
> >> var foo = 20;
> >> delete foo;
> >> Does not remove the variable. Any thoughts on this?
> > Properties introduce with 'var' are not deletable. Most other properties
> > are.
On Thu, Jun 9, 2011 at 8:52 AM, CodeJunkie <isrne...@gmail.com> wrote: > Now X is lost and dangling. The C++ destructor is never called, even > at program exit.
Don't get lured into that false sense of security (as i did). v8 does NOT guaranty that GC will EVER be called, including at app exit. It does not do a full GC at exit (supposedly as a performance boost when closing tabs in Chrome, if my memory serves me correctly).
That means that when wrapping types which REQUIRE destructor calls for proper semantics, you must add functions to those objects which performs such cleanup, and call those functions from your JS code. The canonical examples are file handles and db connections, which would have a close() member (or similar) which cleans up the native object and sets up the object state so that future method calls on that object will not step on a destructed pointer.
In other words, you have to go out of your way to delete C++ objects
which would most likely mean that you would have to have your own
memory management scheme to deal with it. So this means V8 is geared
more towards browsers than for general purpose use and should really
not be used outside the browser verse. I think that more documentation
is needed on the v8 engine to help shed light on the subject. Guess
it's back to Lua. (-_-).
On Jun 9, 10:08 am, Stephan Beal <sgb...@googlemail.com> wrote:
> On Thu, Jun 9, 2011 at 8:52 AM, CodeJunkie <isrne...@gmail.com> wrote:
> > Now X is lost and dangling. The C++ destructor is never called, even
> > at program exit.
> Don't get lured into that false sense of security (as i did). v8 does NOT
> guaranty that GC will EVER be called, including at app exit. It does not do
> a full GC at exit (supposedly as a performance boost when closing tabs in
> Chrome, if my memory serves me correctly).
> That means that when wrapping types which REQUIRE destructor calls for
> proper semantics, you must add functions to those objects which performs
> such cleanup, and call those functions from your JS code. The canonical
> examples are file handles and db connections, which would have a close()
> member (or similar) which cleans up the native object and sets up the object
> state so that future method calls on that object will not step on a
> destructed pointer.
On Thu, Jun 9, 2011 at 11:33 PM, CodeJunkie <isrne...@gmail.com> wrote: > In other words, you have to go out of your way to delete C++ objects > which would most likely mean that you would have to have your own > memory management scheme to deal with it. So this means V8 is geared > more towards browsers than for general purpose use and should really...
It is a disappointing detail, yes, but there is a way to force GC at app shutdown:
while( !v8::V8::IdleNotification() ) { }
that will stop looping when v8 says there is nothing left to clean up.
Finalizers are more complicated than most people think, and they are *not* a replacement for destructors! Reading Boehm's classic paper "Destructors, Finalizers, and Synchronization" ( http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html) can help understanding all issues involved before blaming implementations... ;-)
