good catch! I had written “Collection>>inject:into: inside an <img src= … tag. Hence a lot of code was missing.

Thanks!

thank you so much for this series of posts, which I finally came around to read today. Implicitly, it’s a great tutorial on Squeak VM hacking, which I very much appreciate.

In this post, I found a little glitch - just after the text saying “and now I can see what Collection>>inject:into: looks like:”, some method implementations are given without mentioning where they belong. I believe they go to ContextPart. Is that right?

Best,

Michael

I remember being asked this at ParcPlace, where to an extent it was a standard question to ask of new members of the team. Your idea has two sides. One is as a space saving technique, the other as a jit performance technique. Let me take the former first.

It doesn’t apply to Squeak which has Blue-book compiled methods which are half literals half bytecodes and hence don’t have a separate byte code array to share. But it does apply to VisualWorks and other Smalltalks where a method’s byte codes are (at least notionally) stored in an instance variable.

It turns out that in VisualWorks at least the idea doesn’t fly because there is another optimization for small methods. In VisualWorks methods with 6 or less bytecodes have them encoded in two SmallIntegers, up to three bytecodes per integer, the first integer living in the bytecode instance variable, the other being an extra literal. Because of this in VisualWorks your idea would apply only to methods of 7 bytecodes or more and by that time there is already such variance that the uniquing table occupies more space tha n it saves.

But I’m sure your idea would hold water for systems that have distinct byte code arrays but don’t do the bytecode compression technique that VisualWorks uses, e.g. because the system mixes an interpreter with a JIT or is just an interpreter.

The second side of your question is, um, complex to discuss and I hope to get to it in a blog post on the jit. One of the complications is having to record teh selector for any send site so that when methods are discarded or redefined send sites can be unlinked.

Suffice it to say that doing things like architecting polymorphic inline caches so that accessors can be stored there-in achieves what you’re aiming at in a slightly more general way. PICs can also optimize message-not-understood and, as I plan to do in Cog, interpret-method. David Simmons does a lot more with PICs; something I hope he will write about some time. I plan to do accessors, MNU and interpret-method.

One thing I have been wondering recently is whether one could get a performance improvement by ensuring byte code arrays were unique (in the way that Symbols are). If all the “return instance variable #n”, “set instance variable #n”, and other common byte array patterns existed just once each, and were compiled to native code just once, that surely would help performance.

Perhaps you would have to impose a size limitation on that, so that only “small enough” methods were managed this way.

I suspect the “byte code array” would get replaced by a more elaborate structure which also includes some kind of link to the native code with the null pointer or whatever telling the JIT compiler this method needs to be JIT compiled.

Best wishes to all for a peaceful and prosperous new year,

Kent

Ouch ^2. Yes I am lucky. At least know that I’m hugely grateful to be able to follow the ST dream. But well spotted that Unicode makes things more complicated. Yes, most current Smalltalk implementations are Unicode savvy, and in fact Squeak’s String>>asLowercase implementation looks like

asLowercase
	"Answer a String made up from the receiver whose characters are all
	lowercase."

	^ self copy asString translateToLowercase

translateToLowercase
	"Translate all characters to lowercase, in place"

	self translateWith: LowercasingTable

Which looks a little over-complicated to me. But its not my problem

Somebody give Pete a job … doing Smalltalk!

Sorry, bit off-topic!

Ouch!. Forgive me, I wasn’t thinking about the C, only about the Smalltalk output. But I shouldn’t be displaying bad examples all the same.

But this is interesting. The equivalent Smalltalk code is simply
aString asLowercase
but in C I had to write a function to do it. There was no strtolower function to hand in the C library, a library routine that would be tried and tested and free of errors. The Smalltalk code is something as simple as

asLowercase
        ^self collect: [:c| c asLowercase]

whereas the C code has - count ‘em - 9 lines!
So C forces one to write more code, providing much more opportunity for mistakes, and makes it far harder to debug and correct (low level debuggers, no edit-and-continue).

I make mistakes. I’m currently working on a JIT written in Smalltalk that will be transliterated into C. Were I in C I would be making snail-like progress but in Smalltalk I feel like I’m flying along. Programming systems should be designed for humans, with all their failings. I put down my O(n^2) blunder to the paucity of the C development ecosystem and yet another example of why trying to implement a faster Smalltalk VM makes sense

That said, next time I’ll be sure to write

char *
lower(char *s)
{
    int i = strlen(s);
    buf[i] = 0;
    while (–i >= 0)
        buf[i] = tolower(s[i]);
    return buf;
}

        for (i = 0; i < strlen(s); i++)
                 buf[i] = tolower(s[i]);

as a “Whats’s wrong with this code?” interview question. The answer is of course that it exhibits highly avoidable O(n^2) performance, since strlen(), which is O(n), is being called n times. You can certainly argue that performance hardly matters in this case (and n is rather small), but seeing that idiom out there in the wild still causes me to gasp a little