Good discussion, Thank you to everyone. Now I understand better :)
On Fri, May 7, 2010 at 10:06 AM, Marco Rogers <[email protected]>wrote: > Yes they're C++ objects. The problem with trying to read the memory is > that libxml has several different structs it uses for different node types. > And I can't tell through the pointer what type it is. Plus I don't know > enough about libxml yet. I don't know what struct properties to also > include in the allocation count. I don't want to count child nodes and > such. I'm sure it can be done with a lot of research and a lot of checking, > but an easier solution would be preferable. > > Yes, I would rather let v8 handle things. The reason this is an issue in my > instance, is that my users want to be able to allocate huge node trees over > and over again in tight loops. So the memory stacks up fast and v8 doesn't > know about it so you chew through your memory before the GC has a chance to > run. I know it can be solved with a good hint system for the GC. In tests, > we were able alleviate the problem by invoking the GC manually at certain > intervals. So the destructors are good, they're just not being called often > enough. > > I'm probably going to end up with a combination of this cheap hint solution > plus Anton's awesome memory checker from Chromium. > > Thanks all > :Marco > > > On Fri, May 7, 2010 at 9:58 AM, Stephan Beal <[email protected]>wrote: > >> On Fri, May 7, 2010 at 3:54 PM, Stephan Beal <[email protected]>wrote: >> >>> elements themselves are destroyed. If your elements are C++ bound classes >>> then that probably isn't much work, whereas if they are plain JS objects it >>> would be problematic to capture the destruction for purposes of decrementing >>> the memory use. >>> >> >> OTOH, if the elements are "pure JS" then v8 already knows how much memory >> is used by them. You would only need to track the memory for any native >> libxml components which you keep around for the life of the parser. >> >> But if it becomes too much of a pain, just keep in mind that this level of >> management isn't technically necessary - it's just a way to allow v8 to help >> enforce any hard memory limit by making it aware of external allocation >> sizes. >> >> -- >> ----- stephan beal >> http://wanderinghorse.net/home/stephan/ >> >> -- >> v8-users mailing list >> [email protected] >> http://groups.google.com/group/v8-users >> > > > > -- > Marco Rogers > [email protected] > > Life is ten percent what happens to you and ninety percent how you respond > to it. > - Lou Holtz > > -- > 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
