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

I'm not sure whether that function you're using will see
GC_malloc_uncollectable things. I seem to recall that the mark bits aren't
set for those, maybe? (I'm away from the computer at the moment)

The reason I ask about large objects is that objects larger than 4 KB (GC
heap block size) require finding continuous heap blocks. Finding 2 or 3
contiguous isn't usually a problem, but if you need dozens or hundreds of
contiguous blocks then that can require allocating new memory. If that
object is then freed, and the GC uses a block or two of that space for
small objects ... and then you allocate a large object again ... that space
isn't contiguous any more and another had to be allocated.

That's a very fast way to go through VM...

There's a setting (USE_ENTIRE_HEAP??? Something like that) which should be
false if you don't want this to happen. (leave the space for GC'd large
objects intact in case you allocate another one)


On Sat, Jun 7, 2014 at 1:11 PM, Christian Schafmeister <
[email protected]> wrote:

>
> I might also be leaking memory some other way.   I’m trying to figure it
> out now.
>
> Is the Boehm function:   GC_get_heap_size() an accurate measure of the
> size of the heap allocated by Boehm?
>
> Best,
>
> .Chris.
>
>
> On Jun 6, 2014, at 7:07 PM, Christian Schafmeister <
> [email protected]> wrote:
>
> > Apologies if this is a duplicate - I ran into trouble with the size due
> to a graph I included.
> >
> > I used the code that Peter sent me as-is - it works very well - thanks!
> >
> > I’m writing a Common Lisp implementation that interoperates with C++ and
> uses LLVM as the back end.  I’ve written a static analyzer for my C++ code
> to help me clean it up and add features. When I run the static analyzer on
> the 165 C++ source files using the Boehm GC it blows up.
> >
> > At the end of processing 165 source files the process consumes about
> 30GB (gigabytes) of memory.
> >
> > So I run the static analyzer on one source file 10 times and use the
> code that Peter sent me and walk the reachable objects and add up their
> memory footprint.   There are a handful of objects that don’t have valid
> headers - I filter them out and currently don’t count them. I find that the
> total reachable memory used by the system remains pretty constant at 62MB
> to 34MB (it spikes and then goes down).
> >
> > But the total memory used by my process goes up and up and up very
> quickly!
> >
> > I ran the OS X program “heap” on the process and it reports “non-object”
> heap memory - which I assume is allocated by the Boehm GC (this assumption
> may be wrong - please correct me if you know better).
> >
> > Here is a graph that shows all of the memory usage each time after
> parsing/generating an AST/searching the AST for the same C++ file. A bit of
> explanation… The Y axis is log(Bytes)  The red points are what “heap”
> reports as “non-object” memory - I assume this is total Boehm memory. The
> green points are the total reachable Boehm memory that has a valid header
> that I built.   The blue points are the reachable Boehm memory that was
> allocated just since the start of loading the most recent C++ file. I
> measure this by writing an integer marker into the header of each newly
> allocated object and changing that marker each time I read the source file
> - this lets me track what objects are allocated since the last operation.
> >
> > Graph link: http://imgur.com/tSN5jRL
> >
> >
> >
> > This can’t be memory fragmentation can it?
> > Is Boehm not reusing memory properly?
> > Am I not configuring Boehm properly?
> >
> _______________________________________________
> bdwgc mailing list
> [email protected]
> https://lists.opendylan.org/mailman/listinfo/bdwgc
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>

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