Re: [Squeak-VMdev] Versiojn 4 changes

[Andreas R. <and...@gm...>]

Hi Dan,

> 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?

Fine with me. One thing to keep in mind here: When the "split primitive
index" was introduced we lost one bit in the method header which would have
allowed us to use up to 31 args for methods. The bytecodes to support it are
actually there but the method header doesn't have that extra bit. I'm not
saying that we should necessarily use it but we should be Really Careful
before assigning it for something else and later realize that we might need
it.

> 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?

No strong opinions here. If we agree that the savings in size aren't worth
it, we should go with whatever is best for speed (both, current and future
such as a JIT - it might have a benefit to "tag classes" via their cc
index).

> 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?

A very clear "NO" to the idea of taking away a bit from SmallInteger. 30bit
floats are almost useless - if I had understood the trouble I'm getting into
when I first encountered them in VW I would've never used them ;-) Even
32bit floats are almost always useless except in very limited situations
(say 3D stuff where accuracy really doesn't count all that much).

Here is an alternative that I considered a while ago: Instead of using
"another tag" bit we could declare a tag pattern which looks like:

00 - OOP
10 - Immediate
x1 - SmallInteger

With "Immediate" being described by 6 further bits which specify the index
into the "immediate classes array" (precisely the same as compact classes).
This would leave 24 bits which I could (out of my mind) think of 4
situations in which they would be useful:
* Colors (8 bits each)
* Immediate Points (signed 12 bits x/y)
* Wide characters (Unicode is defined as 21 bit; but Yoshiki really needs
24)
* Scaled decimals (16.8 or 12.12)

The only problem with using the 10 tag is that the garbage collector
currently uses that - but I believe this is fixable. In any case, there is a
clear objection from my end against taking away a bit from SmallIntegers.

> 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?

A key question is whether the "bits" of a 64bit form would store 32bit
quantities or 64bit. If the latter I'd say this is going to get problematic.
If the first, e.g., we merely extend the form bits to make sure we have
always 64bit aligned pixel rows, that should fine.

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

I don't have a good understanding about the tradeoffs involved (Ian should
comment on this) so I'll just throw in a general thought: I think that if we
can (e.g., not being overly wasteful in terms of space) we should leave some
"unused" slot. Much of the experimentation we saw in the past was only
possible because such "unused" places existed (say, MethodContext's
receiverMap).

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

I guess a key issue here is the question whether any changes in V4 could
have a long-term benefit for the closure work. As it stands, Anthony's stuff
works out of the box with a VM that has a few extra primitives so it seems
as if it isn't intrinsically related to image format changes.

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

Not very much. Obviously you need to put an "immutable object" into some
place where you have a cheap write barrier or at least don't have to check
on every store (so clearly it can't reside in young space). But other than
that, no.

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

Uh... what is a monitor bit? This is the first time I hear this term ;-)

Cheers,
  - Andreas