RE: GC statistics (was Re: big project ported)

["Boehm, Hans" <hboehm at exch dot hpl dot hp dot com>]

Off-hand, that seems like a reasonable technique if you exact pointer
information for nearly all the pointers, and you need to perform pointer
validity checks only in a small number of cases (which is probably true for
them).  If you routinely scan C objects (or large thread stacks) for
conservatively identified pointers, that strikes me as quite expensive, even
if you can quickly retrieve the object size from the object pointer.

It would be nice to know how much time they spend in the pointer
identification code.  Certainly for our collector, I consider that to be
very much on the critical path (usually even more so than the allocation
code).

-----Original Message-----
From: Godmar Back [mailto:gback@cs.utah.edu]
Sent: Thursday, October 28, 1999 1:20 PM
To: hboehm@exch.hpl.hp.com
Cc: olson@mmsi.com; gback@cs.utah.edu; krab@daimi.au.dk;
bryce@albatross.co.nz; jsturm@sigma6.com;
java-discuss@sourceware.cygnus.com
Subject: Re: GC statistics (was Re: big project ported)



Hans,

latte and SRCJava use an allocation scheme where small objects are
allocated contigously within a page.  This reduces discretization 
overhead and allows for fast allocation in the common case.

However, in order to find out whether a pointer points to the beginning 
of an object, you first have to find out whether the page contains 
small objects, and secondly you have to linearly scan through the objects
on the page until you find or miss the location you're looking for.

How would you rate such a scheme compared to a bitmap-based allocator?

	- Godmar