Re: [Gc] Is there a way to walk the entire heap of live objects

It's pretty complicated to walk the live objects — there's an awful lot of
code in the marking engine to figure all that out, given different marking
procedures etc.

Really, the only sensible way is to hook into marking yourself. Maybe we
should have this facility but we don't, at least not in the sense of
calling arbitrary user code.

If we did have it, it would be a GC library compile time option, so as to
not slow down production code.

I believe the best thing for you to do as it stands is to look in
include/private/gc_pmark.h where you'll find two implementations of
the PUSH_CONTENTS_HDR macro. Only one is used on each platform, depending
on whether we use a bit or a byte as the object mark "bit".

At the end of each you'll see:

    TRACE(source, GC_log_printf("GC #%u: previously unmarked\n", \
                                (unsigned)GC_gc_no)); \
    TRACE_TARGET(base, \
        GC_log_printf("GC #%u: marking %p from %p instead\n", \
                      (unsigned)GC_gc_no, base, source)); \
    INCR_MARKS(hhdr); \
    GC_STORE_BACK_PTR((ptr_t)source, base); \
    PUSH_OBJ(base, hhdr, mark_stack_top, mark_stack_limit); \

I'd add a call to your own function somewhere in there .. it doesn't matter
.. let's say just before the PUSH_OBJ.

   christian_heap_trace(base); \

Maybe pass hhdr->hb_sz as well if it will help you. NB it will in general
be rounded up from the size that the client program actually asked for.
There is no record kept of the originally requested size.

You'll want to add a declaration for christian_heap_trace(ptr_t) somewhere
in gc_pmark.h also.

Obviously you need to be very careful in your christian_heap_trace()
function! For sure don't call any functions from the GC in it. I'd
recommend you do a printf() with what you find (e.g. the object address and
type) and analyse the emitted text file later using perl or whatever you
like.

I think that should work :-)



On Thu, Jun 5, 2014 at 11:57 PM, Christian Schafmeister <
[email protected]> wrote:

> Hi there,
>
> Is there any functionality in the Boehm GC that would allow me to freeze
> the garbage collector and walk the heap of live objects?    I’d like to
> take an inventory of all of the live objects to determine the source of my
> current memory problems (30 GB of virtual memory used after 4 hours of
> runtime).
>
> I recently incorporated the Boehm garbage collector into a Common Lisp
> system that I’ve written in C++ that uses LLVM as the back-end and
> interoperates with C++.
>
> I’ve exposed the Clang compiler front end and the Clang AST Matcher
> library to the Common Lisp system and I’ve written a static analyzer to
> analyze and clean-up the C++ source code for the Common Lisp system (165
> C++ source files).
>
> The static analyzer takes about 4 hours to run and when it is done the
> REPL sits there and the application is consuming about 30 GB (gigabytes) of
> virtual memory.
>
> I have made all of the objects self-describing so if I could walk the live
> objects I could count the number of each class (~500 classes) and measure
> their size.
>
> Either I’ve got some enormous data structures in there that I have
> forgotten about or heap fragmentation
> is very bad.
>
> In case I’m not configuring the Boehm library correctly - here is my
> configuration.
> boehm-setup:
> (cd boehm-$(BOEHM_VERSION); \
> export ALL_INTERIOR_PTRS=1; \
> CFLAGS="-DUSE_MMAP -DMMAP_FIXED -DHEAP_START=0x7AE147AE1000" \
> ./configure --with-large-heap=yes --enable-cplusplus
> --prefix=$(CLASP_APP_RESOURCES_EXTERNALS_COMMON_DIR);)
>
>
>
> Best,
>
> Christian Schafmeister
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
> _______________________________________________
> bdwgc mailing list
> [email protected]
> https://lists.opendylan.org/mailman/listinfo/bdwgc
>

_______________________________________________
bdwgc mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/bdwgc