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