Memory profile

[Maxim Kizub]

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.

Also, I've found an error in my mem->gc_block
scheme (that removes the need for gc_unit).
#define MEM2UNIT(mem) ((mem) & ~0x1FFF)
will work for small objects only, i.e. for
those, that filly fits in one page, i.e. are
stored in gc_block. If we allocate a big object,
this simple macro will not help...
But I'm shure there must be workaround
for big objects. I think, 8 bytes per object
will save enough of memory (if you remember,
that most of object's have only a few fields,
and I think, this may save about 15-25%
of memory).

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?


D.W.Hughes at exeter.ac.uk wrote:
> 
> Maxim Kizub wrote:
> > Ok. I have another question about gc_unit and gc_blocks.
> > Looks like I do not understand one thing - why we need
> > gc_unit ?
> >
> > [snip]
> >
> > 1 byte per object state (colour & state),
> > 1 byte per GC walk func (really need 4 bits, IMHO).
> > 4 bytes per dtable of object itself.
> 
> The way I see it, any marking non-moving collector has to maintain
> some structure of objects, so that it has an efficient way of
> traversing the set of (for example) grey objects.  So, you've got to
> have some overhead for that.  Kaffe, of course, uses the `gclists' --
> though I admit that I don't see why it uses doubly- instead of
> singly-linked lists.  I'm planning a copying generational collector
> which should do away with (among other things) a lot of the
> block-management overhead, but even so I don't think I can get away
> with less than a word per object of structuring information.
> 
> > Additionaly, we may move classes
> > and interned strings too.  ...
> 
> Ouch!  I'd completely missed that!
> 
> -- Dave
> 
> D.W.Hughes at exeter.ac.uk
> Department of Computer Science, University of Exeter, UK
> 
>               ---  ${HOME} is where the .emacs is.  ---