So, theoretically if V8 decides that it has reached its limit does it try to deallocate every time you try to create a new object in V8 or will it only free those resources on a GC? Say you try to create an object but V8 says it reached its limit, but you still try to create more objects. Does V8 report back, or should you be calling IsDead to check if V8 can still run?
Do you know if this limit is pretty big or could you possibly get into a situation where you are trying to create objects in V8 and it is at the limit and wont deallocate until the next GC. On Mar 17, 1:53 pm, Erik Corry <[email protected]> wrote: > 2009/3/17 MJ <[email protected]>: > > > > > On Mar 17, 3:31 pm, Erik Corry <[email protected]> wrote: > >> unflushed data. This is unlikely to work in a satisfactory way since > >> your non-memory resources will only be cleaned up if the memory system > >> of V8 is under pressure. > > > "if the memory system of V8 is under pressure"......when dealing with > > memory management does V8 have its own environment that it considers > > is the available memory or does it check system memory. Will V8 die > > V8 does not check system memory except to the extent that if V8 asks > for memory and the system says no then you have a fatal out-of-memory > situation. > > > because of an out-of-memory exception because it thinks it is out of > > memory or does out-of-memory mean the system memory as a whole. > > V8 has its own limit and will not allocate more V8 heap memory than > that limit even if the system has more. V8 will also allocate some > memory on the C++ heap but this is supposed to be fairly limited. > > > > > > > On Mar 17, 1:20 pm, Stephan Beal <[email protected]> wrote: > >> On Mar 17, 3:31 pm, Erik Corry <[email protected]> wrote: > > >> > unflushed data. This is unlikely to work in a satisfactory way since > >> > your non-memory resources will only be cleaned up if the memory system > >> > of V8 is under pressure. > > >> If we could get *some* form of trigger to explicitly call v8's gc we > >> could literally eliminate all of the "supplemental GC" we're having to > >> add for all the wrapped types (this is intrusive not only on the types > >> but on the apps which use them, which is unacceptable for plugin-based > >> architectures). Then we could just force a gc at app exit (while v8 is > >> still alive), going through the weak pointer dtors, and all objects > >> would be happy (especially since v8 would still be alive and they > >> wouldn't have to check before doing any JS-related activities during > >> cleanup). A problem i'm having is getting plugged-in types to clean up > >> before v8 dies. When they clean up afterwards they can inadvertently > >> use a Handle (e.g. to clean up an associated resource) and die trying. > >> If i only had a guaranteed gc trigger, this wouldn't have to happen. > > >> PLEASE PLEASE PLEASE!!!! Exposing that feature would be a GOOD thing > >> for ALL of us! If apps want to call a gc every 3 seconds, that's their > >> business, not v8's! > > >> Until then, i'll try creating a bogus context after my main context > >> goes out of scope, to trigger my dtors. (With the caveat that this > >> heuristic is not official and may change, as you mention.) > > -- > Erik Corry, Software Engineer > Google Denmark ApS. CVR nr. 28 86 69 84 > c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 > Copenhagen K, Denmark. --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
