Begin forwarded message:
From: John M McIntosh johnmci@smalltalkconsulting.com Date: February 23, 2009 9:45:11 PM PST (CA) To: squeak vm vm-dev@discuss.squeakfoundation.org Cc: Craig Latta craig@netjam.org Subject: issues with Alien sendInvokeCallback:Stack:Registers:Jmpbuf: Reply-To: johnmci@smalltalkconsulting.com
Ok, many many hours ago I decided to integrate Craig's Spoon work with VMMaker dtl-108 and Alien support. Need to start somewhere, should be easy. Well no, after integrating the changed and doing a extrude and a compile I get missing sendInvokeCallback:Stack:Registers:Jmpbuf
?
After much puzzlement and creating a subclass of Dictionary so I could figure out why sendInvokeCallback:Stack:Registers:Jmpbuf gets removed from the methods dictionary before we decide to remove methods not used, I discovered it's actually removed in removeMethodsReferingToGlobals:except: where we look at the parse tree and decide that the method contains interpreter() loop local variables so the method *should* be fully contained by the interpreter() loop thus can be discarded before we reach the point where we discard non-used memorys if not in the don't discard set.
?
The last part of sendInvokeCallback:Stack:Registers:Jmpbuf which is marked self export: true. reads
self fetchContextRegisters: activeContext. self interpret.
and Craig's code added
interpret
self browserPluginInitialiseIfNeeded. ===> self markAllActiveMethods. self internalizeIPandSP.
?
Lots of ? tonight
so in looking at the Tmetihod parse tree wonders of wonder, the innocent adding of the markAllActiveMethods alters the inlining decision for sendInvokeCallback:Stack:Registers:Jmpbuf and it inlines the browserPluginInitialiseIfNeeded, markAllActiveMethods and internalizeIPandSP which of course as a side effect makes us drop the method because the logic *assumes* then it's part of the interpret() loop since the internalizeIPandSP drags in the interpret() local variables.
To fix well we do
interpretNoInline self inline: false. self interpret
and make sendInvokeCallback:Stack:Registers:Jmpbuf call that.
Oddly before Craig's changes why sendInvokeCallback:Stack:Registers:Jmpbuf reads...
interpret(); return 1;
No idea at this late hour WHY that didn't get inlined back last Nov when I touched it last
-- = = = = = ====================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Hi John, the solution is to prevent interpret being inlined in the first place. Clearly interpret should not be inlined in itself or anywhere else. To do this just mark it as unlineable, e.g. if using pragmas
interpret "This is the main interpreter loop. It normally loops forever, fetching and executing bytecodes. When running in the context of a browser plugin VM, however, it must return control to the browser periodically. This should done only when the state of the currently running Squeak thread is safely stored in the object heap. Since this is the case at the moment that a check for interrupts is performed, that is when we return to the browser if it is time to do so. Interrupt checks happen quite frequently."
<inline: false> "should *not* be inlined into sendInvokeCallback:Stack:Registers:Jmpbuf:" ...
and you should be good to go.
That markAllActiveMethods hack is not the right fix. Instead justActivateNewMehtod needs to make the new active context a root if it is old. Add the two marked lines at the end:
justActivateNewMethod "Activate the new method but *do not* copy receiver or argumernts from activeContext." | methodHeader initialIP newContext tempCount needsLarge where | self inline: true.
....
activeContext := newContext.
(self oop: newContext isLessThan: youngStart) ifTrue: [self beRootIfOld: newContext]
This mirrors the code in internalNewActiveContext:. Note that if a context is a block then its home gets marked as a root if required in (internal)fetchContextRegisters. Do you want me to integrate these? If so, what's your head package version?
On Mon, Feb 23, 2009 at 10:06 PM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:
Begin forwarded message:
From: John M McIntosh johnmci@smalltalkconsulting.com
Date: February 23, 2009 9:45:11 PM PST (CA) To: squeak vm vm-dev@discuss.squeakfoundation.org Cc: Craig Latta craig@netjam.org Subject: issues with Alien sendInvokeCallback:Stack:Registers:Jmpbuf: Reply-To: johnmci@smalltalkconsulting.com
Ok, many many hours ago I decided to integrate Craig's Spoon work with VMMaker dtl-108 and Alien support. Need to start somewhere, should be easy. Well no, after integrating the changed and doing a extrude and a compile I get missing sendInvokeCallback:Stack:Registers:Jmpbuf
?
After much puzzlement and creating a subclass of Dictionary so I could figure out why sendInvokeCallback:Stack:Registers:Jmpbuf gets removed from the methods dictionary before we decide to remove methods not used, I discovered it's actually removed in removeMethodsReferingToGlobals:except: where we look at the parse tree and decide that the method contains interpreter() loop local variables so the method *should* be fully contained by the interpreter() loop thus can be discarded before we reach the point where we discard non-used memorys if not in the don't discard set.
?
The last part of sendInvokeCallback:Stack:Registers:Jmpbuf which is marked self export: true. reads
self fetchContextRegisters: activeContext. self interpret.
and Craig's code added
interpret
self browserPluginInitialiseIfNeeded.
===> self markAllActiveMethods. self internalizeIPandSP.
?
Lots of ? tonight
so in looking at the Tmetihod parse tree wonders of wonder, the innocent adding of the markAllActiveMethods alters the inlining decision for sendInvokeCallback:Stack:Registers:Jmpbuf and it inlines the browserPluginInitialiseIfNeeded, markAllActiveMethods and internalizeIPandSP which of course as a side effect makes us drop the method because the logic *assumes* then it's part of the interpret() loop since the internalizeIPandSP drags in the interpret() local variables.
To fix well we do
interpretNoInline self inline: false. self interpret
and make sendInvokeCallback:Stack:Registers:Jmpbuf call that.
Oddly before Craig's changes why sendInvokeCallback:Stack:Registers:Jmpbuf reads...
interpret(); return 1;
No idea at this late hour WHY that didn't get inlined back last Nov when I touched it last
--
=========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================
--
John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Ok, well I'm integrating Craig's spoon stuff with Alien and vmmaker- dtl 108 I think you suggestion goes back to Craig for review. I've not published anything, at the moment Spoon is a fork, but I'm interested in building a iPhone VM with it.
On 24-Feb-09, at 9:21 AM, Eliot Miranda wrote:
Hi John,
the solution is to prevent interpret being inlined in the first place. Clearly interpret should not be inlined in itself or anywhere else. To do this just mark it as unlineable, e.g. if using pragmas
interpret "This is the main interpreter loop. It normally loops forever, fetching and executing bytecodes. When running in the context of a browser plugin VM, however, it must return control to the browser periodically. This should done only when the state of the currently running Squeak thread is safely stored in the object heap. Since this is the case at the moment that a check for interrupts is performed, that is when we return to the browser if it is time to do so. Interrupt checks happen quite frequently."
<inline: false> "should *not* be inlined into sendInvokeCallback:Stack:Registers:Jmpbuf:" ...
and you should be good to go.
That markAllActiveMethods hack is not the right fix. Instead justActivateNewMehtod needs to make the new active context a root if it is old. Add the two marked lines at the end:
justActivateNewMethod "Activate the new method but *do not* copy receiver or argumernts from activeContext." | methodHeader initialIP newContext tempCount needsLarge where | self inline: true.
....
activeContext := newContext.
(self oop: newContext isLessThan: youngStart) ifTrue: [self beRootIfOld: newContext]
This mirrors the code in internalNewActiveContext:. Note that if a context is a block then its home gets marked as a root if required in (internal)fetchContextRegisters. Do you want me to integrate these? If so, what's your head package version?
On Mon, Feb 23, 2009 at 10:06 PM, John M McIntosh <johnmci@smalltalkconsulting.com
wrote:
Begin forwarded message:
From: John M McIntosh johnmci@smalltalkconsulting.com Date: February 23, 2009 9:45:11 PM PST (CA) To: squeak vm vm-dev@discuss.squeakfoundation.org Cc: Craig Latta craig@netjam.org Subject: issues with Alien sendInvokeCallback:Stack:Registers:Jmpbuf: Reply-To: johnmci@smalltalkconsulting.com
Ok, many many hours ago I decided to integrate Craig's Spoon work with VMMaker dtl-108 and Alien support. Need to start somewhere, should be easy. Well no, after integrating the changed and doing a extrude and a compile I get missing sendInvokeCallback:Stack:Registers:Jmpbuf
?
After much puzzlement and creating a subclass of Dictionary so I could figure out why sendInvokeCallback:Stack:Registers:Jmpbuf gets removed from the methods dictionary before we decide to remove methods not used, I discovered it's actually removed in removeMethodsReferingToGlobals:except: where we look at the parse tree and decide that the method contains interpreter() loop local variables so the method *should* be fully contained by the interpreter() loop thus can be discarded before we reach the point where we discard non-used memorys if not in the don't discard set.
?
The last part of sendInvokeCallback:Stack:Registers:Jmpbuf which is marked self export: true. reads
self fetchContextRegisters: activeContext. self interpret.
and Craig's code added
interpret
self browserPluginInitialiseIfNeeded.
===> self markAllActiveMethods. self internalizeIPandSP.
?
Lots of ? tonight
so in looking at the Tmetihod parse tree wonders of wonder, the innocent adding of the markAllActiveMethods alters the inlining decision for sendInvokeCallback:Stack:Registers:Jmpbuf and it inlines the browserPluginInitialiseIfNeeded, markAllActiveMethods and internalizeIPandSP which of course as a side effect makes us drop the method because the logic *assumes* then it's part of the interpret() loop since the internalizeIPandSP drags in the interpret() local variables.
To fix well we do
interpretNoInline self inline: false. self interpret
and make sendInvokeCallback:Stack:Registers:Jmpbuf call that.
Oddly before Craig's changes why sendInvokeCallback:Stack:Registers:Jmpbuf reads...
interpret(); return 1;
No idea at this late hour WHY that didn't get inlined back last Nov when I touched it last
-- = = = = = ====================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
-- = = = = = ====================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
vm-dev@lists.squeakfoundation.org