Excluding objects from garbage collection
caustik
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).
If there isn't an existing way to exclude objects from garbage
collection, I would like to tackle this problem personally and
contribute a patch to allow others to benefit. Is there any advice you
can give me, to point me in the right direction in the V8 source code
so I can begin?
<3
caustik
Erik Corry
> 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
caustik
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;
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 <erik.co...@gmail.com> wrote:
Erik Corry
> 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.
> --
> v8-dev mailing list
> v8-...@googlegroups.com
> 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