On Mon, Apr 9, 2012 at 4:51 PM, caustik <[email protected]> wrote: > Hmm.. let me walk through this and ask a few questions to clarify what > you mean exactly. > > Here's the rough idea how these Objects are created and associated > with one another: > > pNode = new Object(); > pNode->pL = pNodeA; > pNode->pR = pNodeB; > pNode->pU = pNodeC; > pNode->pD = pNodeD;
There is some misunderstanding here. These objects are all created from JS, not through the API so there are no handles involved at all. For V8 > 3.7 there should not be big pauses during GC unless something strange is happening. I am not sure why you are seeing such big pauses unless there is something going wrong with the GC heuristics. Vyacheslav pointed out yesterday that the calculations related to external memory were based on 32 bit values, so we fixed that yesterday (not on trunk yet). There may be other places where the heursitics are going wrong. > > Questions: > > 1) Does this create 1 object and an additional 4 handles? > 2) When pNode's links later change, will those handles (pL, pR, pU, > pD) require garbage collection, or are they immediately destroyed? > > The links between objects may be possible to replace with integers, > which then can be used to index into an array of Objects. Might that > reduce the handle count? > > On Apr 9, 6:09 am, Erik Corry <[email protected]> wrote: >> On Sun, Apr 8, 2012 at 7:03 AM, caustik <[email protected]> wrote: >> > I have a large, fixed collection of objects which reference one >> > another (e.g. linked list) >> >> > There are over 1,000,000 of these objects. I've noticed that the limit >> > to my project's scalability is the garbage collection cycle which take >> > a full second to run as a result of having this many object handles in >> > the context. Normal operation is extremely fast, the only bottleneck >> > is this traversal of these objects by garbage collection. I can try to >> > avoid creating garbage, to limit how frequent this collection occurs, >> > but it's inevitable to need GC at some point, and with these objects >> > excluded, the GC pass would be extremely fast and no longer a >> > bottleneck. >> >> > So, is there any existing technique I may use to exclude this set of >> > objects from garbage collection? This would fix the bottleneck, and >> > presumably this particular problem is applicable to a huge portion of >> > (for example) node.js projects, thus solving one of the biggest >> > hurdles against even more widespread adoption of V8 (GC is often the >> > biggest performance bottleneck). >> >> Is it possible to avoid having so many handles? The GC can handle >> lots of interlinked objects on the JS side without big pauses, but the >> large number of handles is the issue. A solution that reduces the >> large number of handles (and doesn't just create one huge array on the >> JS side with all the references) will likely make pauses smaller. >> >> -- >> Erik Corry > > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev -- Erik Corry, Software Engineer Google Denmark ApS - Frederiksborggade 20B, 1 sal, 1360 København K - Denmark - CVR nr. 28 86 69 84 -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
