[Vm-dev] Re: [squeak-dev] uncompacting classes

David T. Lewis lewis at mail.msen.com
Thu Dec 1 19:22:07 UTC 2011

On Wed, Nov 30, 2011 at 07:39:05PM -0800, Eliot Miranda wrote:
> On Wed, Nov 30, 2011 at 1:19 AM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
> >
> > Eliot, a simple question: In Pharo:
> > Smalltalk compactClassesArray asSet size -> 15
> > Smalltalk compactClassesArray asSet size -> 13
> >
> > I would like to have one extra free bit in the object header. I can hack
> > my own VM which uses 4 bits for CompactClasses rather than 5, but do you
> > think we can do this for the official Cog VM as well? this would allow
> > "researched" a much nice infrastructure out of the box. How much work can
> > be such change? is there someone needing 32 compact classes?  if I do a
> > SpaceTally new printSpaceAnalysis  it looks like if I only need the first
> > 10 classes....
> >
> > I know in the future you want to change all this thing about compact
> > classes, but if we can have one free bit tomorrow (instead of "in the
> > future"), then this is very very good.
> >
> Seems reasonable.  What do you think Andreas, David, Esteban, Ian?  Shall
> we make this change?

My answer is strictly from the point of view of VM maintainance. As long
as we manage the change so as to not cause problems for existing VMs and
images, then this proposal has my full support.

By "manage the change" I mean:

- Agree in advance a new image format number (i.e. allocate a free bit
in the image format number) such that a VM can decide based on the image
format whether or not it knows how to support this format.

- Document the change in the ImageFormat package in VMMaker, such that
the new image format identification will be documented to avoid conflicts
with other VM projects.

- Keep the ObjectMemory related code organized such that we can easily
generate both the old and new format.

Eliot, I think that the way you have separated ObjectMemory from Interpreter
in VMMaker makes this sort of change very easy to manage, so from my
point of view if you think this is a good thing to do, there is no reason
not to do it.


More information about the Vm-dev mailing list