On Mon, 4 Feb 2002, Tim Rowledge wrote:

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

> 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:

Ok.. I've been looking at interpreter technology, seeing if there is
anything that can be borrowed from FORTH implementations and used in
squeak. That, if ever done, might add quite a few bytecodes.

>
> > 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 a basically stock #4600 image, there are 336k objects, of which 270k
are compact. This means that they save 1mb, or about 7% of the 15mb image.


> 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.

Based on profiling the entire VM.
  1.9% is spent reading the 5 compact class bits [*] (in commonSend)
   .8% is spent loading it if it is. (in commonSend)
   .2% on the conditional (in commonSend)

[*] We're probably paying cache misses here.

This is ignoring any GC effects. Thus, the performance cost appears to be
2-4%.

They also cost 5 bits of header. With the current image, the expected cost
in bits/object dedicated to identifying the class is 9.86. The minimum
with a simple index is 11 (1.8k classes in the default image).

A few days ago I proposed a new header that has 18 bits of size, 16 bits
of class index, 16 bits of hash, 6 bits for image maintance, and 8 unused
bits.

> 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.

I tried that, as the first part in building a VM with no compact classes
at all; it doesn't work.

    CompiledMethod BlockContext MethodContext

override basicNew to error; there may be a way to uncompact them, but the
normal technique does not work. Removing the failure messages and trying
again leads to VM failure.

Scott