Martin McClure wrote:

> At 9:06 PM -0500 2/2/02, Scott A Crosby wrote:
> >  >
> >>  This second class of usage is the primary motivation for adding the
> >>  header bit. All the alternatives to this that I've seen either
> >>  severely limit the functionality or are extremely ugly.
> >>
> >
> >Do you really need a header bit? What about just reserving a seperate
> >range of memory for such objects, then, you just see if its in that range
> >before deciding whether or not to allow the mutation.
>
> This would be of some use, and is a conceivable compromise
> implementation. However, I need to be able to toggle a given object
> in and out of this state fairly frequently, and that gets more
> complicated and less performant with a separate memory area.
>
> Also, when objects are created I can't always tell whether they
> should go in the separate memory area or not, and that complicates
> things further.

At the moment, the image has only 15 compact classes, which means that 4 bits
for the compact class index would suffice. However, that would prevent Squeak
users from making their own heavily-used classes compact. Would we be willing
to pay the price?
2 compact classes are for use by the JIT engine (PseudoContext and
TranslatedMethod).
BlockContext has only 480 instances in the 3.2gamma image, but without
looking at the interpreter source I can't say whether one could drop
BlockContext compactness without affecting MethodContext.
So this would be one possible source for a read-only bit...

Cheers,
Hans-Martin