Compact class bits ([SqF]Report of VI4 Project for Feb '02)

Hans-Martin Mosner hmm at heeg.de
Sun Feb 3 13:08:30 UTC 2002


Scott A Crosby wrote:

> On Fri, 1 Feb 2002, Tim Rowledge wrote:

...

> > Plans: Any further proposals for image format affecting changes are
> > needed as soon as possible; this is not something we want to do more
> > than once.
>
> 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.
>
> Just a brainstorm, cause everyone seems to want header bits.
>
> Scott

We could probably do with just 3 bits for compact class index, if we include
the object's format bits into account. If you look at the #instSpec value of
the 15 compact classes, you'll find that there is no instSpec value which has
more than 4 compact classes. Here are the pairs class->instSpec:

(only fixed fields)
Association->1
Point->1
Rectangle->1

(only indexable pointer fields)
Array->2
TranslatedMethod->2

(fixed and indexable pointer fields)
BlockContext->3
MethodContext->3
PseudoContext->3
MethodDictionary->3

(indexable word fields)
Bitmap->6
Float->6

(indexable byte fields)
String->8
Symbol->8
LargePositiveInteger->8

(CompiledMethods, will move to instSpec 3 with the new CM format)
CompiledMethod->12

We'd use (ccIndex << 4 bitOr: instSpec) as the index into a 128-element array
of compact classes.

This would result in 2 free header bits at the cost of some complication.
Probably dropping compact classes altogether is easier indeed. But perhaps
the 6-7% figure gets higher for severely stripped-down images for PDA usage,
which might be an argument against dropping the compact classes?

Cheers,
Hans-Martin




More information about the Squeak-dev mailing list