Hello all, There have been some questions about the status of the block closure version and when it will get into the main release. The short answer is its not ready for the main release yet. There are still more enhancements I want to add that will change the bytecodes, and thus image format. Plus other VI4 enhancements need to be added. So the best strategy for now is to treat BC as a fork and evolve it, then when we think it is stable we will make it the main release. Note, the BC fork will be able to stay current with the latest updates, since it can read from the update stream just like the main image. Here is what I suggest: First, let's make BC and VI4 the same thing. Before, BC was a component of VI4, but now I will include other VI4 enhancements when building the BC version, and will drop the use of the term "BC" and now call it "VI4". Second, let's make the previous BC swiki page the main VI4 page. http://minnow.cc.gatech.edu/squeak/2119 will now contain all the changesets needed to make the VI4 version from the main version and, as a convenience, the pre-built VI4 version itself. Updates specific to VI4 will also be maintained on this page ready to be downloaded and filed-in to the VI4 image. Contributers are free to add changesets/updates to this page. That's it. We now have two flavors of Squeak, the main one and the VI4 one. Go to http://minnow.cc.gatech.edu/squeak/VI4 to check out VI4. Please feel free to add other changesets that you think should be included in VI4. Just make sure they work with the rest of VI4 (the BC stuff). Much of the Interpreter related to the call stack and bytecodes has changed, and some of its instance variables have changed with it, but you should be able to figure it out. The rest of the Interpreter/ObjectMemory has not changed. Cheers, Anthony
Anthony Hannan ajh18@cornell.edu is claimed by the authorities to have written:
First, let's make BC and VI4 the same thing. Before, BC was a component of VI4, but now I will include other VI4 enhancements when building the BC version, and will drop the use of the term "BC" and now call it "VI4".
Sounds ok to me; it does after all already include the two main candidates for the VI format change (closures and corrected compiled method format) so let's try to get the other aspects moving. It's way past time.
On my list to tackle are:- + cleaning up the split primitive number fields in the method header (in fact since we have named primitives sorted out these days, maybe we should drop the nonsense of trying to allow thousands of numbered ones. I suspect the freed up bits can be found useful labour pretty quickly) + remove the obsoleteIndexed/Named prim redirection tables since they are now uneeded. + move any named prims not yet in a plugin into a plugin + drop some old dead primitives + clean out the special object array - some residents are surely dead + see if we can find some more bits for hash values + oh, I don't know, loads more I'm sure.
Other people have in the past asked for bits in object headers to signal persistence, immovability, immutability, inscrutability, incontinence, in a database, in a bun, inadmissable, and probably other things. Maybe we can provide some of them.
Not all the above are strictly image format changing, but may simply be something worth getting in whilst already breaking backwards compatability.
Oh, and we'll need to think of a new image version number - '6502' (or '1969') has been used since the beginning and needs replacing to avoid the older vms getting upset. How about:- 8086 (yuck) 1972 err...
tim
...since we have named primitives sorted out these days, maybe we should drop the nonsense of trying to allow thousands of numbered ones.
Yeah! I'd love to get the numbered primitives down to an absolute minimum (zero would be nice :).
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
...since we have named primitives sorted out these days, maybe we should drop the nonsense of trying to allow thousands of numbered ones.
Yeah! I'd love to get the numbered primitives down to an absolute minimum (zero would be nice :).
While I agree on general principles I'd advise to run a few benchmarks first. The overhead of calling named primitives is not to be underestimated for cases like SmallInteger>>+ or Stream>>next and similar. Also, making all primitives named might have various negative implications for any JIT compilation.
Cheers, - Andreas
Oh, and we'll need to think of a new image version number - '6502' (or '1969') has been used since the beginning and needs replacing to avoid the older vms getting upset. How about:- 8086 (yuck) 1972 err...
I'd like 4 (suitably padded), to indicate that this is the fourth image format, or 2002, to indicate the year of introduction (assuming this sort of thing won't happen more than once a year... hee hee).
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
Hi,
When making up new Imageversion Numbers make also sure you don't use by accaident a byte-swapped version of an existing image-version number. The mechanism (at least in the interpreter-simulator) relies on the absence of such coincidences.
Just my 2P Torge Craig Latta wrote:
Oh, and we'll need to think of a new image version number - '6502' (or '1969') has been used since the beginning and needs replacing to avoid the older vms getting upset. How about:- 8086 (yuck) 1972 err...
I'd like 4 (suitably padded), to indicate that this is the fourth imageformat, or 2002, to indicate the year of introduction (assuming this sort of thing won't happen more than once a year... hee hee).
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
If you guys are creating a new image version, you might also want to revisit which classes use compact class indices. There are currently a couple of weird choices, most notably TextLineInterval, of which I can find no instances. Rectangle, and perhaps Point also seem like candidates for replacement with more common classes.
See SystemTracer>>initCompactClasses for the current list.
-- Duane
Duane Maxwell wrote:
See SystemTracer>>initCompactClasses for the current list (of compact
classes)
Sorry to answer myself, but it turns out the source of the above method is incorrect, at least in #3552 The correct current list can be found with:
Smalltalk compactClassesArray
However, there are still possible improvements by replacing or adding some classes. In particular, I would think that Character would be a good candidate.
-- Duane
"Duane Maxwell" dmaxwell@san.rr.com is claimed by the authorities to have written:
In particular, I would think that Character would be a good candidate.
It's probably not worth worrying about Character because there's only the 256 if them; unless of course somebody is about to implement unicode!
The real candidates for compact class status are anything that is common and very likely to be of suitable small size. Quite a few of the common collection classes might be considered. It would probably be worth having a class for ByteCodeArray and making it compact - especially for VI4 where blocks have their own bytecode arrays, so there are lots of them around.
Most of the high frequency classes are already captured in thecurrent list of compact classes, though a few like MethodChangeRecord, ClassOrganizer etc are missing. The really good news is that altering this doesn't need a new image format since classes can be compactifizated (hey, I'm in the US now, I can get away with that!) simply by using Behavior>becomeCompact et al.
tim
On Tue, 11 Jun 2002, Tim Rowledge wrote:
Other people have in the past asked for bits in object headers to signal persistence, immovability, immutability, inscrutability, incontinence, in a database, in a bun, inadmissable, and probably other things. Maybe we can provide some of them.
Not all the above are strictly image format changing, but may simply be something worth getting in whilst already breaking backwards compatability.
I had a couple of other ideas, including a different header scheme that I covered a few months ago.. Roughly its along the idea of:
Header word 1: 16 bits: class index. 1 bit: root 2 bits: GC mark bits. ? bits: whatever other flags we can imagine... - weak, - immutable - literal (do not scan for references with GC) Header word 2: 18 bits: size. (all -1 means see header word 3) 14 bits: hash. (Optional) Header word 3: 32 bits: size.
There's a seperate class index table at the head of the image.
--
First, its a lot simpler, class lookup for, for example, methodcache lookup is a lot faster. Just read the first header word, mask off the bits, and hash with the symbol keyword. No compact class bits.
And, this saves the 5 compact class bits completely. Second, reserving 32 bits for every class not in the compact class array seems extreme overkill, we afford indirection without affecting methodcache lookup. So, we can use a 16 bit classid (or 20 bits if 65536 classes isn't enough).
Also, this can handle a wide range of class sizes with no branches based on header type, (those are expensive). Just use the second header word. For the few classes over, say, 256kb, you have a third header word with the actual size.
And, this scheme seems to offer a lot of extra bits for whatever we may want it to do. We can reserve 6 bits in the first header for GC (for experimenting with different GC algorithms) and still have 10 bits for whatever else we wish. We can get another 4 bits or so if we had to, by masking off a few of the high bits in the second header.
And, it should be faster. Since there's pretty much no class that uses the third header, the CPU can accurately predict that it'll almost never be used. Thus, we don't have to do several hard-for-CPU's-to-predict branches in the methodcache lookup, or in the garbage collector trying to determine object sizes or class-id's... And, as that code is inlined all over, getting rid of it will help the CPU's instruction cache.
True, we do pay some extra RAM for classes that were formerly compact, about another meg worth of image size, but in exchange, we should get simpler faster code, and 10-16 bits free in every object header.
And, if you're thinking of wiping the compact class bits anyways, you're paying the same bloat for much less than this would give you.
Scott
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Anthony Hannan -
Craig Latta -
Duane Maxwell -
Ian Piumarta -
Scott A Crosby -
Tim Rowledge -
Torge Husfeldt