[Squeak-VMdev] Versiojn 4 changes

[Dan I. <Da...@Sq...>]

Hi, folks -

I know many of you are busy, but I'd like some input in the next few days about various possible or desirable changes to be included in the Version 4 image format.  Feel free to mark up the swiki page, and I'll try to pull some consensus out of the discussion toward the end of the week.


Cleanups
There are a couple of cleanups like the size of the numbered primitive field and the layout of the format field in classes.  I am assuming we'll just do those, and that they'll take a day or two each.  Any problems with Tim's suggestion to drop the limit to 511?

More important to me are...


Compact classes
I put these in way back, and they do save almost a word per object in small kernel images.  They complicate things a bit, but the code is already written, and it has been stable for nearly a decade now.

On the other hand, the complexity is an inhibition to trying out various other cool hacks.  Moreover if we dropped the compact class feature, we could pick up 5 more bits of object hash, which would definitely be nice.  With regard to compactness, my experience is that the savings due to this feature is less than the difference between a well-designed kernel and a poor one, so I don't consider it a bit issue.  Even PDA's have plenty of space these days (yes, there's an upside to the Microsoft world ;-), and for extreme compactness issues (like web downloads), there are all sorts of other compactness strategies.

I'm inclined to drop them and give the bits back to the hash, but it's only a mild inclination.  How do you guys feel?


Immediate objects (tagging)
We *could* do lots of things here -- enough so I start to get worried about doing too much.  For instance, we could have immediate Floats of, say, 30 bits, and immediate Characters of 30 bits, in addition to our current immediate SmallIntegers.

I'm inclined not to do any of these, but how do you feel?


The 64-bit format
My inclination is to tie this as closely to the 32-bit format as possible for now, just to simplify the project.  To me that means just extending every oop, and header word with zeroes, and sign-extending every "small" integer.  The trade-off is complex between having a different range of SmallIntegers in the 64- and 32-bit worlds, and sticking with the same 31-bit range in each.  I hope to understand this better in the coming days.  If you do already, please speak up.


Form bits modulus
I want to change the modulus of Form bitmaps to 64 bits in both 32- and 64-bit images.  It will simplify things for them to be the same, and I think we can convert old ones on the fly for compatibility (ie, when reading in a project, or an old '.form' file.  Do you see any problems with this?


CompiledMethods
A major question to decode is whether to split up bytecodes and literals (and source pointer) as in Tim's NewCompiledMethod work. This adds a little space overhead, but it certainly makes things simpler.

And what about native methods support?  Is there something simple that would suffice, or something better?  This is a time when we could open some possibilities.  If we had some idea, then at least we could put the right hooks in the image, even if we need to do some VM work to use it later.


Closures
I'm just assuming we would load some form of Anthony's work, which probably also means using his compiler.  Ian, are you happy with the structures he chose, or should we make some changes before loading them up?  I'm assuming this is separable from the contiguous stack work, but maybe not.  We probably want to start with something that doesn't change the existing context structures much.


Immutability bit
This sounds intriguing.  Has anyone here thought seriously about what is needed to support it?


Monitor bit
This was a concern of Alan's way back.  Andreas - is this needed for any of the Croquet synchronization work?