[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory accounting in libgc

From: Neil Jerram
Subject: Re: Memory accounting in libgc
Date: Thu, 13 Mar 2014 14:46:42 +0000
User-agent: Roundcube Webmail/0.9.5

On 2014-03-12 06:57, Mark H Weaver wrote:
Andy Wingo <address@hidden> writes:

How does this affect libgc?

First of all, it gives an answer to the question of "how much memory
does an object use" -- simply stop the world, mark the heap in two parts
(the first time ignoring the object in question, the second time
starting from the object), and subtract the live heap size of the former from the latter. Libgc could do this without too much problem, it seems
to me, on objects of any kind.  It would be a little extra code but it
could be useful.  Or not?  Dunno.

This could be generalized to the far more useful question: "How much
memory does this set of objects use?", although that's a slippery
question that might better be formulated as "How much memory would be
freed if this set of objects were no longer needed?".

For example, suppose you have a large data structure that is referenced
from two small header objects, A and B.  If you ask "How much memory
does A use?", the answer will be the size of the small header, and ditto
for B.  Without being able to ask the more general question, there's no
way to find out how much would be freed by releasing both.


Absolutely agree that this would be useful, but I suspect a problem in how far one can push libgc to simulate a set of objects being freed without them actually _being_ freed. For example there could be guardians associated with the objects, and I think one can validly imagine them doing either of the possible extremes (or anywhere in between), namely:

- resurrecting the objects again

- freeing up a whole load more objects/memory that the guardians know to be associated with the original objects, but which wasn't (for some reason) simply referenced by them.

Hope that's a useful thought - interesting subject!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]