[Pharo-project] #recreateSpecialObjectsArray woes
Hello, i attempted to load Alien-Core package into trunk image, and it failed. One of the problem is override of recreateSpecialObjectsArray method.. I wonder, maybe we should design a nicer API for extending/reserving slots in special objects array, so it won't require overriding this method by every package which needs to extend special objects, like FFI or Alien. Another aspect of replacing this method is , that it makes problematic to unload such package, in case one wants to unload it. So, my proposal is to add a simple API to SmalltalkImage class, and in order to install additional special objects one should do like: MyClass class>>initialize Smalltalk registerSpecialObject: myObject at: 55. Smalltalk registerSpecialObject: myObject at: 56. ... or: Smalltalk registerSpecialObjects: #( x y z) startingAt: 56. upon package unload, a reverse scheme should be supported: MyClass class>>unload Smalltalk unregisterSpecialObjectAt: 55. Smalltalk unregisterSpecialObjectAt: 56. ... or: Smalltalk unregisterSpecialObjects: 3 startingAt: 56. what you think? -- Best regards, Igor Stasenko AKA sig.
On Apr 12, 2010, at 4:17 11PM, Igor Stasenko wrote:
Hello,
i attempted to load Alien-Core package into trunk image, and it failed.
One of the problem is override of recreateSpecialObjectsArray method..
I wonder, maybe we should design a nicer API for extending/reserving slots in special objects array, so it won't require overriding this method by every package which needs to extend special objects, like FFI or Alien.
Another aspect of replacing this method is , that it makes problematic to unload such package, in case one wants to unload it.
So, my proposal is to add a simple API to SmalltalkImage class, and in order to install additional special objects one should do like:
MyClass class>>initialize
Smalltalk registerSpecialObject: myObject at: 55. Smalltalk registerSpecialObject: myObject at: 56. ...
or:
Smalltalk registerSpecialObjects: #( x y z) startingAt: 56.
upon package unload, a reverse scheme should be supported:
MyClass class>>unload
Smalltalk unregisterSpecialObjectAt: 55. Smalltalk unregisterSpecialObjectAt: 56. ...
or:
Smalltalk unregisterSpecialObjects: 3 startingAt: 56.
what you think?
-- Best regards, Igor Stasenko AKA sig.
+1 for the overall idea. Implementation-wise, I'd also vote for raising errors in registerSpecialObject:at: if something other than myObject is already registered, changing to unregisterSpecialObject: at: in order to not unintentionally unregistering something else, and disallow unregisterSpecialObjects:startingAt: ;) Cheers, Henry
+ 1 for that. Stef On Apr 12, 2010, at 4:42 PM, Henrik Johansen wrote:
On Apr 12, 2010, at 4:17 11PM, Igor Stasenko wrote:
Hello,
i attempted to load Alien-Core package into trunk image, and it failed.
One of the problem is override of recreateSpecialObjectsArray method..
I wonder, maybe we should design a nicer API for extending/reserving slots in special objects array, so it won't require overriding this method by every package which needs to extend special objects, like FFI or Alien.
Another aspect of replacing this method is , that it makes problematic to unload such package, in case one wants to unload it.
So, my proposal is to add a simple API to SmalltalkImage class, and in order to install additional special objects one should do like:
MyClass class>>initialize
Smalltalk registerSpecialObject: myObject at: 55. Smalltalk registerSpecialObject: myObject at: 56. ...
or:
Smalltalk registerSpecialObjects: #( x y z) startingAt: 56.
upon package unload, a reverse scheme should be supported:
MyClass class>>unload
Smalltalk unregisterSpecialObjectAt: 55. Smalltalk unregisterSpecialObjectAt: 56. ...
or:
Smalltalk unregisterSpecialObjects: 3 startingAt: 56.
what you think?
-- Best regards, Igor Stasenko AKA sig.
+1 for the overall idea. Implementation-wise, I'd also vote for raising errors in registerSpecialObject:at: if something other than myObject is already registered, changing to unregisterSpecialObject: at: in order to not unintentionally unregistering something else, and disallow unregisterSpecialObjects:startingAt: ;)
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Good idea! I had a similar idea when initially worked on Alien loader. I think that what is needed also is remove the dependency with the array, i mean explicitly calling the indexes make the image crash if you didn't had the assumed special object array size. For example: Smalltalk registerSpecialObject: myObject with: aName And later you reference that special object by aName instead of an index to the array. So it would be easier to load/unload the packages that extend the special objects array, because there would be no explicit dependency to indexes. Fernando On Apr 12, 2010, at 4:17 PM, Igor Stasenko wrote:
Hello,
i attempted to load Alien-Core package into trunk image, and it failed.
One of the problem is override of recreateSpecialObjectsArray method..
I wonder, maybe we should design a nicer API for extending/reserving slots in special objects array, so it won't require overriding this method by every package which needs to extend special objects, like FFI or Alien.
Another aspect of replacing this method is , that it makes problematic to unload such package, in case one wants to unload it.
So, my proposal is to add a simple API to SmalltalkImage class, and in order to install additional special objects one should do like:
MyClass class>>initialize
Smalltalk registerSpecialObject: myObject at: 55. Smalltalk registerSpecialObject: myObject at: 56. ...
or:
Smalltalk registerSpecialObjects: #( x y z) startingAt: 56.
upon package unload, a reverse scheme should be supported:
MyClass class>>unload
Smalltalk unregisterSpecialObjectAt: 55. Smalltalk unregisterSpecialObjectAt: 56. ...
or:
Smalltalk unregisterSpecialObjects: 3 startingAt: 56.
what you think?
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 12 April 2010 17:43, Fernando olivero <oliverof@lu.unisi.ch> wrote:
Good idea! I had a similar idea when initially worked on Alien loader.
I think that what is needed also is remove the dependency with the array, i mean explicitly calling the indexes make the image crash if you didn't had the  assumed special object array size.
For example: Â Â Â Â Smalltalk registerSpecialObject: myObject with: aName
    And later you reference that special object by aName instead of an index to the array.
So it would be easier to load/unload the packages that extend the special objects array, because there would be no explicit dependency to indexes.
Yeah, that would be nice. But this will require VM changes.. and therefore is doomed :) Also, this could impact the VM speed significantly, because its using special object quite frequently. Imagine replacing a simple index-based lookup with name(string) based.
Fernando
On Apr 12, 2010, at 4:17 PM, Igor Stasenko wrote:
Hello,
i attempted to load Alien-Core package into trunk image, and it failed.
One of the problem is override of recreateSpecialObjectsArray method..
I wonder, maybe we should design a nicer API for extending/reserving slots in special objects array, so it won't require overriding this method by every package which needs to extend special objects, like FFI or Alien.
Another aspect of replacing this method is , that it makes problematic to unload such package, in case one wants to unload it.
So, my proposal is to add a simple API to SmalltalkImage class, and in order to install additional special objects one should do like:
MyClass class>>initialize
Smalltalk registerSpecialObject: myObject at: 55. Smalltalk registerSpecialObject: myObject at: 56. ...
or:
Smalltalk registerSpecialObjects: #( x y z) startingAt: 56.
upon package unload, a reverse scheme should be supported:
MyClass class>>unload
Smalltalk unregisterSpecialObjectAt: 55. Smalltalk unregisterSpecialObjectAt: 56. ...
or:
Smalltalk unregisterSpecialObjects: 3 startingAt: 56.
what you think?
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Apr 12, 2010, at 5:16 PM, Igor Stasenko wrote:
On 12 April 2010 17:43, Fernando olivero <oliverof@lu.unisi.ch> wrote:
Good idea! I had a similar idea when initially worked on Alien loader.
I think that what is needed also is remove the dependency with the array, i mean explicitly calling the indexes make the image crash if you didn't had the assumed special object array size.
For example: Smalltalk registerSpecialObject: myObject with: aName
And later you reference that special object by aName instead of an index to the array.
So it would be easier to load/unload the packages that extend the special objects array, because there would be no explicit dependency to indexes.
Yeah, that would be nice. But this will require VM changes.. and therefore is doomed :) Also, this could impact the VM speed significantly, because its using special object quite frequently. Imagine replacing a simple index-based lookup with name(string) based.
Hi Igor, i wasn't speaking of an on-image API change. For example if you introduced the API you mentioned we could replace Utilities>> initializeClosures "Eliminate the prototype BlockContext from the specialObjectsArray. The VM doesn't use it. This paves the way for removing BlockCOntext altogether and merging ContextPart and MethodContext into e.g. Context." (Smalltalk specialObjectsArray at: 38) class == BlockContext ifTrue:[Smalltalk specialObjectsArray at: 38 put: nil]. With Utilities>> initializeClosures ...... (Smalltalk hasSpecialObjectNamed: #BlockContext) ifTrue:[ Smalltalk unregisterSpecialObjectNamed: #BlockContext ]. ....
On 12 April 2010 18:30, Fernando olivero <oliverof@lu.unisi.ch> wrote:
On Apr 12, 2010, at 5:16 PM, Igor Stasenko wrote:
On 12 April 2010 17:43, Fernando olivero <oliverof@lu.unisi.ch> wrote:
Good idea! I had a similar idea when initially worked on Alien loader.
I think that what is needed also is remove the dependency with the array, i mean explicitly calling the indexes make the image crash if you didn't had the  assumed special object array size.
For example: Â Â Â Â Smalltalk registerSpecialObject: myObject with: aName
    And later you reference that special object by aName instead of an index to the array.
So it would be easier to load/unload the packages that extend the special objects array, because there would be no explicit dependency to indexes.
Yeah, that would be nice. But this will require VM changes.. and therefore is doomed :) Also, this could impact the VM speed significantly, because its using special object quite frequently. Imagine replacing a simple index-based lookup with name(string) based.
Hi Igor, i wasn't speaking of an on-image API change.
For example if you introduced the API you mentioned we could replace
Utilities>> initializeClosures     "Eliminate the prototype BlockContext from the specialObjectsArray.  The VM doesn't use it. This paves the way for removing BlockCOntext altogether and merging ContextPart and MethodContext into e.g. Context."     (Smalltalk specialObjectsArray at: 38) class == BlockContext         ifTrue:[Smalltalk specialObjectsArray at: 38 put: nil].
With
Utilities>> initializeClosures     ......     (Smalltalk hasSpecialObjectNamed: #BlockContext)         ifTrue:[ Smalltalk unregisterSpecialObjectNamed: #BlockContext ].     ....
Ah you mean associating indexes with corresponding names, so code can use a nice-looking names instead of bare indexes? But then who is responsible for providing these associations? Somewhere you have to put things like: BlockContextIndex := 38. so, then later you can do nice: Smalltalk unregisterSpecialObjectNamed: #BlockContextIndex The problem is, that we don't know these names beforehead. So, should a newly loaded package also define a new index names then? Like Smalltalk registerSpecialObjectIndex: 55 named: #MyName. and then to register an object, it should do: Smalltalk specialObjectAt: #MyName put: MySpecialObject. ?
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
participants (4)
-
Fernando olivero -
Henrik Johansen -
Igor Stasenko -
Stéphane Ducasse