Memory profile

[Godmar Back]

> 
> Hello.
> 
> I just forgot to start letter from main thing -
> experiments shows, that kaffe allocates
> 18 bytes per "new Object()".
> That was the source of wonder, why kaffe allocates
> 18 bytes instead of 6 bytes it needs...
> Well, let's say, 2 bytes are used for gc_block
> header and other stuff like this.
> And 8 bytes for gc_unit?
> 
> That was the real question, I'm sorry.

It needs 8 bytes for gc_unit, 4 bytes for the dtable field,
which makes 12 bytes.  The smallest allocation unit is 16 bytes.
(See the table in gc-mem.c with the "S(_)" macros).
Plus, it uses 2 bytes for status information.  Makes 18 bytes.

So there's two things to look at: first, the 10 byte overhead.
As I already explained, this is in part because of the historical
8 bytes for the doubly linked list, and because we generously
reserve 2 bytes for status information.  

Second, the 4 bytes introduced due to the choice of 16 as the smallest
possible allocation size.  So, my question is: how frequent are allocations
of objects of type "Object", or other types that don't have any member
variables?  I'd say they're infrequent, but as always I may be wrong.

If, however, there's at least one word of data, then the 16 works
out just fine.  In fact, I remember gathering statistics and
plotting a histogram of allocation sizes for three unrepresentative
applications that allowed me to choose the sizes I have chosen.  
I didn't write a linear programming model or anything like that, so 
there's room for error.  This was discussed on this list, if you 
consult the mailing list archives.
 
If you enable -vmdebug SLACKANAL, it'll tell you how much memory is
wasted.  Does Kiev allocate large amount of objects with no member 
variables?  What output do you get for SLACKANAL with your application?

If Kiev has a specific allocation pattern, you can change the table
in gc-mem for it.  Alternatively, we could change Kaffe to read in
an allocation size histogram and adapt accordingly for a specific
application.

I feel the real answer here is to use a mostly copying collector
and allocation regions where you don't have these internal fragmentation
problems.

> 
> And another thing. In memory profile I added
> to kaffe I did count requested and actually
> allocated memory. At the start of the program
> up to the middle of execution the difference
> was about 1.2:1, but then raised to 1.5:1
> I can't say what sizes of objects caused
> this change. What kind of allocation scheme
> kaffe uses for middle-sized and big objects?
> Does it still uses page strategy or it
> uses usuall malloc strategy?
> 

Again, use -vmdebug SLACKANAL and look at the table in gc-mem.c.

	- Godmar