Two new questions about VM machinery :-)

Hi all, hi Eliot,

just for curiosity, I have two new questions about the VM machinery (which are far away from praxis but close to my interests):

1. super on ProtoObject

What would you expect the following to return?

x := Compiler evaluate: 'super identityHash' for: ProtoObject new.

thisContext objectClass: x.

I would have guessed that either the VM crashes or ProtoObject >> #cannotInterpret: is called.

But actually, it answers you the ProtoObject instance, which I find very interesting because it means that if a message cannot be looked up, it is simply and silently skipped.

If you debug the call instead (Context class >> #runSimulated:), Context >> #send:to:with:lookupIn: raises a nil DNU error, which makes more sense but unfortunately is not consistent with the original VM behavior.

Maybe the Compiler should forbid any call to super from ProtoObject instances at all (more formally: if the receiver's class's superclass is nil)? Or should we adjust the simulation code?

(By the way: If you do the same in Squeak.js, you'll get an infinite recursion :D)

2. Mirror primitives

What is the reason for primitives such as 75 (#identityHash) or 78/139 (#nextInstance/#nextObject) not being mirrored in Context?

Was this simply forgotten, or don't we have the claim to mirror any "essential" primitive without it actually being needed by the simulation machinery?

As always, looking forward to your interesting explanations! :-) 

Best,

Christoph

Hi Eliot,

this sounds very convincing. If you have patched this in the VM, it would be great if you could send me a link to the relevant patch. :-)

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Donnerstag, 10. September 2020 07:16:30
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Two new questions about VM machinery :-)

 

Hi Christoph,

On Tue, Sep 8, 2020 at 1:34 AM Thiede, Christoph <[hidden email]> wrote:

Hi Eliot,

thanks for your answer!

Just to be sure: What class do you intend to lookup #doesNotUnderstand: for if the message not understood's lookupClass is ProtoObject superclass (i.e. nil)? Are you thinking of ProtoObject again? This would break the existing rule "If a message is sent to super but not understood, send #doesNotUnderstand: to super as well" (*), or am I misinterpreting this? Shouldn't you rather signal some special selector in this case?

Right, it seems asymmetric, but one *has* to lookup in the class of the receiver when doing doesNotUndersatnd:.  For example, imagine one has a special doesNotUnderstand: method.  If a super send causes doesNotUnderstand: but doesn't invoke your special doesNotUnderstand: the system is effectively broken, preventing you from intercepting certain messages.

 

(*) I'm not sure about this, but I think this results from the Bluebook, page 589. According to the implementation given there, the VM had to crash with a recursion error if a nil class is reached while looking up #doesNotUnderstand:. Because the Bluebook states that the existence of a #doesNotUnderstand: implementation is guaranteed, I would also find it reasonable to have the VM crashed if you actually make a call to super from a method compiled on ProtoObject.

That's still the case today. If one removes the doesNotUnderstand: method, or one creates a detached class hierarchy which doesn't contain a doesNotUnderstand: method then the VM will still abort with a recursive doesNotUnderstand: error.  One could add a fall-back, say send a message to thisContext such as object:doesNotUnderstand: . But what's to say one hasn't removed the object:doesNotUnderstand:.  Analogous to Gödel's theorem, if the system is powerful enough to modify itself then it is able to destroy itself.  Dan Ingalls gave a lovely talk at Xerox PARC a few years ago and Donald Knuth was in the audience.  His question to Dan was "With the power to modify the system on the fly, how do you avoid shooting yourself in the foot?". Dan's answer was the same as the Doctor who, when the patient says "Dr, it hurts when I do X",  replies "Don't do X".  Dan simply said "we tend not to, and we have crash recovery tools when we do."

What do you think? :-)

I think that the major difference between the Blue Book's doesNotUndersatnd: and modern doesNotUnderstand: is that if a Message instance has three inst vars then the VM fills in the third inst var with the class in which the message lookup started, so that now in a doesNotUnderstand: method one can find out if the doesNotUnderstand: was the result of a normal send or a super send, and hence a doesNotUnderstand: method has the necessary info if it in fact wanted to do super doesNotUnderstand: for MNUs resulting from super sends.

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Sonntag, 6. September 2020 04:49:54
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Two new questions about VM machinery :-)

 

Hi Christophe, Hi Tobias,

On Sat, Sep 5, 2020 at 4:10 AM Thiede, Christoph <[hidden email]> wrote:

Hi all, hi Eliot,

just for curiosity, I have two new questions about the VM machinery (which are far away from praxis but close to my interests):

1. super on ProtoObject

What would you expect the following to return?

x := Compiler evaluate: 'super identityHash' for: ProtoObject new.

thisContext objectClass: x.

I would have guessed that either the VM crashes or ProtoObject >> #cannotInterpret: is called.

My guess before looking at the code was that the send provoked a doesNotUnderstand: and hence the expression returned the result of raising a MessageNotUnderstood exception.  But looking at the code I see that at least in the JIT there is undefined behavior in looking up a message in a nil class (the superclass of ProtoObject is nil).  So thank you for this.  I'll have to firm up the behaviour to ensure a doesNotUnderstand: is the result.

But actually, it answers you the ProtoObject instance, which I find very interesting because it means that if a message cannot be looked up, it is simply and silently skipped.

Which is a bug.  The only reasonable thing to do here (IMO) is for the VM to send doesNotUnderstnnd:.

 

If you debug the call instead (Context class >> #runSimulated:), Context >> #send:to:with:lookupIn: raises a nil DNU error, which makes more sense but unfortunately is not consistent with the original VM behavior.

Maybe the Compiler should forbid any call to super from ProtoObject instances at all (more formally: if the receiver's class's superclass is nil)? Or should we adjust the simulation code?

(By the way: If you do the same in Squeak.js, you'll get an infinite recursion :D)

2. Mirror primitives

What is the reason for primitives such as 75 (#identityHash) or 78/139 (#nextInstance/#nextObject) not being mirrored in Context?

Was this simply forgotten, or don't we have the claim to mirror any "essential" primitive without it actually being needed by the simulation machinery?

They're not needed by the execution simulation machinery.

 

As always, looking forward to your interesting explanations! :-) 

Best,

Christoph

Cheers 

_,,,^..^,,,_

best, Eliot

--

_,,,^..^,,,_

best, Eliot