RE: Can I use the GC to find the number and type of each java object?

["Boehm, Hans" <hans dot boehm at hp dot com>]

You might also try the attached patch, which should allow you to print
random backtraces from heap objects, thus telling you why objects are not
going away.  These backtraces should also usually include Java types.

With this patch, if you set the GC_BACKTRACES environment
variable to N, at each GC, the collector
will pick N random addresses inside heap objects, and print the backwards
chain of objects referencing the one it picked.  The last thing it will
print in each chain is the root location.

I'm still hoping for some comments on the patch before I check it in.
(I previously posted it on Mar. 17, and I haven't retested recently.)

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> Jeff Sturm
> Sent: Monday, May 10, 2004 1:07 PM
> To: David Daney
> Cc: java@gcc.gnu.org
> Subject: Re: Can I use the GC to find the number and type of each java
> object?
> 
> 
> On Mon, 10 May 2004, David Daney wrote:
> > I occasionally run out of memory when running GCJ compiled 
> code, and in
> > the interests of understanding what is happening, I would like to be
> > able to dump the type, size and occurrence count of each 
> reachable object.
> >
> > It there a predefined method, or lacking that a good place 
> to hook in to
> > boehm-gc to find information about all reachable objects?
> 
> GC_print_block_list() does some of this, though it knows 
> little about java
> objects.  You can call it from within gdb.
> 
> Output looks like:
> 
> (kind(0=ptrfree,1=normal,2=unc.,3=stubborn):size_in_bytes, 
> #_marks_set)
> (0:56,73)(0:56,73)(0:56,73)(4:24,170)(0:56,73)(0:56,73)(4:24,1
> 70)(0:56,73)
> ...
> blocks = 2133, bytes = 9154560
> 
> Java objects have either kind 0 ("pointer-free", strings and primitive
> arrays) or 4-6 (most objects).  Each block contains objects 
> of one size
> only.  The "#_marks_set" field gives you an idea how many objects in a
> block are reachable (I think this number is accurate only after a
> collection).
> 
> Hans will probably correct me if I got any of that wrong :-)
> 
> Jeff
>

Attachment: gc_diffs2_ChangeLog
Description: Binary data

Attachment: gc_diffs2
Description: Binary data