Scott A Crosby <crosby at qwes.math.cmu.edu> is claimed by the authorities to have written:

> On Fri, 1 Feb 2002, Tim Rowledge wrote:
> 
> > iv) cleanup some header fields
> 
> What sorts of header field cleanups are under consideration?
Sorry - I was a bit unclear here; I was thinking _method_ header bits,
where the prim number was split into two fields. My favourite cleanup
here is to cut back to <256 numbered prims (plus fake special prims
256-519 for the pushing of instvars) and rely on named prims for
everything else. The two method header bits thus freed would do nicely
as the exception marking bits mentioned in Interpreter>isUnwindMarked:

> Looking at an STSpace output...
> 
> About 310k objects in my image, 240k are stored compactly, saving about a
> megabyte (6%) of the image size, but costing 5 bits in each header, and an
> extra branch&table lookup on every findClassOf reference.
> 
> So, 6-7% space savings for 5 bits in the object header. Are they
> good/bad/ugly.
We've never really evaluated the worth of the compact classes.
On one hand they do save some space, which is not to be sneezed at -
despite the fact that you can indeed get 128Mb of ram for stupidly low
prices, this is only applicable to some machines. Some of us want to be
able to use 2Mb images on 4Mb machines to do useful things.
On the other hand, they do cost bits in the header that might be useful
for other things, and they do cost some time in decoding.

Anyone wanting to evaluate the difference in performance and space can
do so by looking at the 'private' prococol of Behavior - you can make
all the currently compact classes non-compact without any vm changes.
check the image size profile and performance before and after.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: HEM: Hide Evidence of Malfunction