[Vm-dev] Re: [Pharo-project] Enhancing SmalltalkImage>>recreateSpecialObjectsArray to lower coupling

[Eliot Miranda]

Hi Guillermo,

On Sun, Mar 18, 2012 at 5:46 PM, Guillermo Polito <guillermopolito at gmail.com
> wrote:

> What about changing #recreateSpecialObjectsArray so having in mind some
> classes like Bitmap or Display may not be in the kernel?
> This only changes some lines like:
>
> ...
>     newArray at: 5 put: (self at: #Bitmap ifAbsent: [ nil ]).
>
> ...
>
>     newArray at: 13 put: (self at: #Point ifAbsent: [ nil ]).
>
> ...
>
>     newArray at: 15 put: (self at:  #Display ifAbsent: [ nil ]).
>
> ...
>
>     newArray at: 34 put: (self at: #Point ifPresent: [ :cls | 0 at 0]
> ifAbsent: [ nil ]).
>

The last one isn't used in Cog (in fact indices 32, 33 & 34 are unused) and
probably unused in the Interpreter.  David?

You may be able to get away with making Bitmap and DIsplay optional.  But
Point is dug pretty deep into the VM.  Point is used for the special
selector send bytecodes for #x, #y & #@.  For #x & #y there's a check that
the class of the receiver is Point, and if so, evaluate in-line.  So that
is fine; if Point is nil then #x will get sent, rather than evaluated
inline.  But if the system sends #@ it'll likely crash, trying to create an
object whose class is nil.

To do what you're proposing properly the VM would need to be modified to be
safe.  We should perhaps discuss what the right approach is.  e.g. if Point
is in fact nil then #x #y and #@ would all slow down slightly in normal use
checking for the possibility of Point being nil.  This isn't an issue in
Cog since these messages are compiled to regular sends; but t=in the
regular interpreter and the StackInterpreter (used on e.g. Android) it may
be.


A different approach might be to move these classes to Kernel, or to
provide rump classes that raise errors when used, e.g.

newArray at: 13 put: (self at: #Point ifAbsent: [ RumpPoint ]).

(the rump of something being what's left when you take everything away,
rump = behind, bottom etc)


>
> Does anyone know if this should this break something?
>
> Guille
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120319/9a4f6d17/attachment.htm