[Squeak-VMdev] DING! End of Round One

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

Hi, Guys -

Thanks for all your comments and suggestions.  I don't know about you, but I find this to be a lot of fun.

Now that discussion has tapered off, I will do my best to summarize the various areas, and to make some tentative decisions for your approval or further discussion in the second round.  I do this, not because I make the best decisions, but because we need to reduce uncertainty to move forward.  Please object now if you feel like I'm leaning the wrong way on items above the line here.


Cleanups
First of these is the split primitive field of method headers.  I think there's good agreement on returning to a 9-bit field and doing away with (or converting to named access) all those that were using higher indices.  I have a specific proposal which I will document soon on the web site, but it is essentially what Tim suggested, except I would drop of the loadInstVar range so we leave room for 50 or so unused inedexed primitives at the top.  My reasoning is that, ugly or not, indexed primitives are the easiest way for curious hackers to experiment with new capabilities in Squeak.

[By the way, it looks like "External primitive support primitives" 570-574 are still in use and would need to be slid down]


Compact classes
Nobody seems to care much here.  I was impressed that Andreas picked up on the slight "tagging" advantage that CCs offer.  This actually saves an instruction or two testing for contexts, as I recall.

I checked the stats of 'mini.image', the" complete" MVC Smalltalk in 520k.  It has 13426 instances of compact classes, most of which would be 4 bytes bigger without CCs (some are large enough to have big headers already).  The real count is less, since I picked up 1000 contexts  in my stats, but those are meaningful, too.  So the space cost for this example is about 54k.  I expect this factor or 10% would scale pretty well to any small kernel, since it will mostly be full of the same stuff (methods, symbols, arrays, points and rectangles).

However... Consider if we revamp CompiledMethods as well.  Then the 4600 methods in this benchmark become either 9200 or 13,800 objects, all with 2-word headers.  So the cost (versus doing new CMs, but with CCs) would be an additional 18.4k or 37k depending on whether methods become 2 or 3 objects.

I think this change is worth one more round of contemplation on grounds of IIABDFI (if it ain't broke...).  The part that bothers me most is actually compatibility with Version-3 projects (image segments), but we're going to have to do something for this anyway.  What's nasty about this change is that it's harder to do on the fly, since some objects get bigger.


SmallIntegers
We had some interesting discussion about changing the format of SmallIntegers.  I'm going to invoke executive privilege however, to say that we will not change the current representation on this go round.  I'm sure it would be an interesting exercise, but I don't see a really big payoff, and I can imagine it ending up being a lot of work.

If anyone wants to do this on their own and give me the code, or if they want to argue one last time for the benefits, I'm still willing to reconsider.  I really mean this -- i just don't want to get bogged down in gratuitous changes.


Immediate objects (tagging)
I like Adreas's proposal for an extensible set of Immediate Objects.  I still haven't researched the GC conflict with the 10 tag.  Also I haven't looked at how small a kernel of support we could have in the VM.


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.  For now, we'll also stick with the same 31-bit value range in both systems.


Form bits modulus
I want to change the modulus of Form bitmaps to 64 bits in both 32- and 64-bit images. As per discussion this does not change the format, only the raster width.


CompiledMethods
A major question to decide 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.  I'm going to assume that we go with Tim's 2-object format, and throw in a "serendipity" field for fun this summer.
[By the way, I'm assuming this adds another very high bandwidth register to access literals independent of bytecodes, right?  And Ian please comment on the relative importance of 3 objects vs two]


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?  We probably want to start with something that doesn't change the existing context structures much.


Order of evaluation
I know we've chatted about this in the past, and believe me I *want* to do this.  Unfortunately, I think for Squeak it would be a mistake.  There is a fair amount of useful software (mainly compilers) in the community that has the left-to-right convention built in.  Then there is the occasional bad usage of the form (strm next * 256 + strm next), but they deserve what they get.  Hey, I know -- how about left-to-right on big-endian machines, and right to left on little-endian.  Just kidding.  I'm mainly concerned about bucking a convention that has paid off in synergy over the years.


Decoupling GC from Primitives
This seems like an all-around win, although not really V4-related.  i would love it if someone would take it upon themselves to spec this and estimate difficulty, so we can review it, and then actually do it.


Separate Allocation of some Bits Objects
I understand that this one matters.  I'm just the wrong person to spec it or do it (since I know relatively little about media engines and OS resource management).  Most other serious implementations have such a facility, and I'm sure it would help with any serious media work.  I'm happy to manage it as part of this project.

If someone can pull this off in a compatible time frame, I'll do my best to merge it with the V4 changes.  If not, perhaps we could at least spec it in such a way that future V4 VMs could add it without needing further image changes.
-----------------------------------------


Other Changes  "While we have it in the shop..."
Beyond here are changes I haven't thought about enough to render even a temporary judgement.  I'd love to hear more pro's and con's and maybe some estimate of how much work and who would do it.


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


Proxy support (divergent "self' and "receiver")
Is 'receiverMap' (ie a spare slot in Contexts) enough for now?
Also I've heard of "resend" bytecodes for delegation that re-use the context without having to load and push all the args as well, when all you want to do is forward the message to, eg, an aspect variable.


Squat Support
Need to hear more discussion.


Flat Rectangles
I never wrote about this, but I came very close do doing this in the early history of Squeak.  It saves time getting to BitBlt, doing intersections, etc, and it saves a little space, too.  I wouldn't do this for me right now, but I'm wondering if Mr. Graphics has ever wished for it.  I think it's not a hugely hard change to make (at least it wasn't back then).

I probably left something out -- please remind me

Thanks all -- you guys are great!

	- Dan