Just curious if the probing of the intepreter method cache for forwarding pointers had been sorted out, per SpurMemoryManager class comment...
The inline cache failure code is then responsible for following the forwarding pointer chain (these are Iliffe vectors :) ) and resolving to the actual target.
(In the interpreter there needs to be a similar check when probing the method cache). It has yet to be determined exactly how this is done (e.g. change the receiver register and/or stack contents and retry the send, perhaps scanning the current activation).
cheers -ben
Hi Ben,
On Wed, Jun 1, 2016 at 7:29 AM, Ben Coman btc@openinworld.com wrote:
Just curious if the probing of the intepreter method cache for forwarding pointers had been sorted out, per SpurMemoryManager class comment...
The inline cache failure code is then responsible for following the
forwarding pointer chain (these are Iliffe vectors :) ) and resolving to the actual target.
(In the interpreter there needs to be a similar check when probing the
method cache). It has yet to be determined exactly how this is done (e.g. change the receiver register and/or stack contents and retry the send, perhaps scanning the current activation).
In the StackInterpeter look at internalFindNewMethodOrdinary and under which circumstances it sends handleForwardedSelectorFaultFor: and handleForwardedSendFaultForTag:. In the Cogit look at ceSICMiss: (code entry Single Inline Cache miss) and under which circumstances it sends ceSendFromInLineCacheMiss:.
_,,,^..^,,,_ best, Eliot
vm-dev@lists.squeakfoundation.org
-
Ben Coman -
Eliot Miranda