On Mar 9, 9:12 pm, Alex Iskander <[email protected]> wrote:
> It will be freed, you just don't have any control over when unless you
> use external garbage collection.
If i don't use external collection at all, it might not be freed (been
there, done that). In my tests, my Weak callbacks were never getting
called until i created thousands of the objects, and if i didn't
create thousands of them, the context would eventually exit without
calling the callbacks. So i've been forced to add "just in case" GC
which gets "removed" *if* v8 gc calls the weak pointer callback,
otherwise it cleans up all remaining objects at app exit.
> Objects in v8 exist outside of contexts, so their weak handle callback
> will get called whenever v8 garbage collects, even if "their" context
> dies (as, since the object is not tied to a single context, it never
> has a context that can die). So as long as v8 is still being used for
> any scripts, you won't have any leaks, because garbage collection will
> keep occurring.
In my tests, i my callbacks would normally never be called, so "will
get called" is a tad bit misleading (unless that's been fixed in the
past week or so). i tested this by adding debug output to my callback
routines and class dtors. The only time i could get ANY weak callback
was when memory use jumped (which it didn't when the script is only "if
(1){var x = new MyType()}", which "should" call gc when the script (or
context) exits).
> You don't have to worry about memory leaks, because when the
> application itself dies, all of its memory will be freed by the
> operating system.
That's not the way C++ does destruction. A C++ destructor may free
resources, and dtors are not called at app exit if the objects are on
the heap (which nearly all JS/Native wrapped objects are). That leads
to db handles, file handles, etc. which don't get closed in a well-
defined fashion (i.e. could lead to corruption). In the cases of the
ncurses bindings, such behaviour (destruction via non-dtor) will cause
the app to stay in curses screen mode when it exits (which is ugly and
requires one to type "reset" to get the screen back in order). That
type of problem is unfortunately only solved via extra client-side
garbage collection. IMO v8 should either guaranty that gc is called at
context shutdown or give us a Context configuration option which
enables that guaranty for those of us who (dearly) care about it. It
would save tons of client-side GC efforts which we have to add only
for the sake of Chrome's performance (as that is reportedly the reason
that v8 GC is considered so time-critical).
> The only times you need external garbage collection, from what I can
> tell, are when destructors must be called, which is only necessary
> when doing file i/o, etc, with resources that must be explicitly closed.
And almost certainly necessary when we're wrapping arbitrary classes
(with arbitrary dtors). In my experience, most classes worth wrapping
aren't coypable, which means we cannot wrap an arbitrary number of
them to JS, as we don't have a place to store them which could
guaranty their proper destruction (e.g. a std:: container where they
would be destroyed when the container goes). e.g. sqlite3 db, window
handles of any sort, any opaque handle of any type, etc., all have to
be created on the heap. And those are also the types of objects for
which dtors *need* to be called to ensure proper clean-up.
Nondeterministism is the nature of GC, and i'm fine with that. But a
GC which says "your object *will* be collected [at some point]" and
then doesn't do it "for performance reasons", i just can't accept as
proper/correct behaviour. v8 developers: at least give us a Context
configuration option to tell it force GC at context exit (or during v8/
static destruction, if cross-context objects are a problem)!
--~--~---------~--~----~------------~-------~--~----~
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
-~----------~----~----~----~------~----~------~--~---
