Memory profile

[jason]

Maxim Kizub writes:
> 
> 
> 
> I think this will not help.
> 
> I'm looking for memory leaks, and they unlikely
> in _java_ objects. If they exists, they must be in
> memory that is explicitly allocated and freed.
> I need a pointer in raw memory blocks...
> But I can't understant how gc_unit and gc_block
> are allocated and used...

It looks like you already found the (or at least the most serious)
problem,  but I can try to answer your question anyway.

gc_blocks describe pages of memory.  A page contains several small
objects, or a run of pages contains one large object.  The an
gc_blocks is allocated at startup, and normally it stays put.

The gc_blocks contain three pointers into the pages they manage: funcs
state and data.  Funcs and state are byte arrays allocated at the
start of the page, each object has a func and state.  data points to
the first actual object on the page.

gc_unit is the object header used in the psuedo-treadmill collector.
gcMalloc allocates the requested size + 8 bytes.  The gc_unit is at
the base of the allocated memory, and the object reference just above
the gc_unit.  This is why markObject does UTOMEM (which subtracts 8
from a pointer) before checking if the pointer is a valid object.

I haven't looked at the post-libtool version of kaffe, so my
information could be out of date.

Jason