[squeak-dev] Two new questions about VM machinery :-)

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Tue Sep 8 08:34:44 UTC 2020


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?


(*) 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.


What do you think? :-)


Best,

Christoph

<http://www.hpi.de/>
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Eliot Miranda <eliot.miranda at gmail.com>
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 <Christoph.Thiede at student.hpi.uni-potsdam.de<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>> 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:.

<http://www.hpi.de/>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200908/a5cb5491/attachment.html>


More information about the Squeak-dev mailing list