Kaffe Memory Management

[Jason Baker]

"Johan Andersson" <anderssj at tcd.ie> writes:

> This is a multi-part message in MIME format.
> 
> ------=_NextPart_000_00E2_01BFD0A4.E4857A30
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> Hi.
> 
> 
> Why does Kaffe (linux) uses sbrk(..) to allocate memory. According to =
> the man. pages for sbrk(..) it is not very feasible. Why doesn't Kaffe =
> use malloc(..)?

Why isn't is feasible?  We want pages of memory to manage on our own.

> In gc_small_alloc(..) and gc_large_alloc(..):
> 
> info->funcs=3D(unitp8*)GCBLOCK2BASE(info);
> info->state=3D(unitp8*)(info->funcs+nr);
> info->data=3D....;
> .
> What happens here? Where do these pointers point to. Memory addresses in =
> the heap or to addresses in the space allocated by malloc for a number =
> of gc_blocks (which is used by the gc_primary_freelist).
> 
> The bottom line is, what of the gc_block is put on the heap?

GCBLOCK2BASE computes the base address of the page corresponding to
info.  The funcs and state bytes are allocated at the base of this
page.  We then take the next address after state, align it to 8 bytes,
and start putting objects there.  Strictly speaking, none of gc_block
is put on the heap, since it defines the heap.

Other arrangements are possible: For instance, we could allocate a
page of gc_block structures which describes itself along with the next
63 pages (assuming that pages are 4096 bytes in size, and gc_blocks 32
bytes).  What do you mean by `the heap'?

Jason