Bringing back gc-live-object-stats

Bringing back gc-live-object-stats

[Amirouche Boubekki]

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

Hello all,


I am stuck with a memory leak. I think *gc-live-object-stats* [0] would
help.

[0]
https://www.gnu.org/software/guile/manual/html_node/Garbage-Collection-Functions.html#index-gc_002dlive_002dobject_002dstats

Can some explain to me how to bring it back?

Thanks in advance,


Amirouche ~ amz3

[-- Attachment #2: Type: text/html, Size: 670 bytes --]

Re: Bringing back gc-live-object-stats

[Mark H Weaver]

Amirouche Boubekki <amirouche.boubekki@gmail.com> writes:

> I am stuck with a memory leak. I think gc-live-object-stats [0] would help.
>
> [0] https://www.gnu.org/software/guile/manual/html_node/Garbage-Collection-Functions.html#index-gc_002dlive_002dobject_002dstats
>
> Can some explain to me how to bring it back?

I don't believe that libgc provides the necessary APIs to efficiently
provide that old interface.  You'd need to begin by learning libgc
internals, and figure out what needs to be done.  Then you'd need to
convince the libgc developers to incorporate your changes.  Two broad
approaches that come to mind would be: (1) for libgc to keep a running
count of the number of live objects of each type, incrementing the
counts during allocations and decrementing them in the sweep phase, or
(2) provide an interface to iterate over all live objects.  In the
latter case there'd be thread safety issues.  Guile would also need
modifications to tell libgc the types of the objects.

Personally, I suggest finding another approach to debug your leak.

I don't want to spend much time on this, because I suspect it would be a
lot of work for questionable benefit, and it's not clear whether the
result of that work will be acceptable to either libgc or Guile.  It
might introduce too much added complexity or overhead.

     Regards,
       Mark

Re: Bringing back gc-live-object-stats

[Amirouche Boubekki]

[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]

Thanks for your reply.

Le jeu. 16 mai 2019 à 03:41, Mark H Weaver <mhw@netris.org> a écrit :

> Amirouche Boubekki <amirouche.boubekki@gmail.com> writes:
>
> > I am stuck with a memory leak. I think gc-live-object-stats [0] would
> help.
> >
> > [0]
> https://www.gnu.org/software/guile/manual/html_node/Garbage-Collection-Functions.html#index-gc_002dlive_002dobject_002dstats
> >
> > Can some explain to me how to bring it back?
>
> Personally, I suggest finding another approach to debug your leak.
>

> I don't want to spend much time on this, because I suspect it would be a
> lot of work for questionable benefit, and it's not clear whether the
> result of that work will be acceptable to either libgc or Guile.  It
> might introduce too much added complexity or overhead.
>

Then it would be preferable to remove it from the manual.

My understanding of how GC works makes unlikely there is a leak
in the Guile code except particular cases that I don't know about,
but I tested some of those. For instance, dynamic-func pointers are
collected.

Also while experimenting with the official Python bindings, I discovered
that I did not setup proper eviction configuration which leads to something
that looks like a leak. In fact, it is just that wiredtiger can not keep up
with
the batch load in the default configuration.

Anyway, Thanks!

[-- Attachment #2: Type: text/html, Size: 2312 bytes --]