Can I use the GC to find the number and type of each java obj ect?

Mon May 10 20:21:00 GMT 2004

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 2004年5月10日, 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gc_diffs2_ChangeLog
Type: application/octet-stream
Size: 3159 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20040510/42554be0/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gc_diffs2
Type: application/octet-stream
Size: 42140 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20040510/42554be0/attachment-0001.obj>