Hi Guillermo,
On Sun, Mar 18, 2012 at 5:46 PM, Guillermo Polito <guillermopolito@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@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
On Mon, Mar 19, 2012 at 10:01:23AM -0700, Eliot Miranda wrote:
Hi Guillermo,
On Sun, Mar 18, 2012 at 5:46 PM, Guillermo Polito <guillermopolito@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@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?
Good question. I took a quick look at senders of #splObj: and I do not see any usage of these entries in the special objects array. It appears that the entries are (or were) intended to support fast object initialization:
"Prototype instances that can be copied for fast initialization" newArray at: 32 put: (Float new: 2). newArray at: 33 put: (LargePositiveInteger new: 4). newArray at: 34 put: Point new.
I cannot guarantee that these entries are unused, but it may well be that they are obsolete.
I guess one way to confirm this is to nil them out in the array and see what breaks.
Dave
vm-dev@lists.squeakfoundation.org