Fwd: issues with Alien sendInvokeCallback:Stack:Registers:Jmpbuf:

> From: John M McIntosh <[hidden email]>
> Date: February 23, 2009 9:45:11 PM PST (CA)
> To: squeak vm <[hidden email]>
> Cc: Craig Latta <[hidden email]>
> Subject: issues with Alien sendInvokeCallback:Stack:Registers:Jmpbuf:
> Reply-To: [hidden email]
>
> 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 <[hidden email]>
> 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 <[hidden email]
> > wrote:
>
>
>
> Begin forwarded message:
>
> From: John M McIntosh <[hidden email]>
> Date: February 23, 2009 9:45:11 PM PST (CA)
> To: squeak vm <[hidden email]>
> Cc: Craig Latta <[hidden email]>
> Subject: issues with Alien sendInvokeCallback:Stack:Registers:Jmpbuf:
> Reply-To: [hidden email]
>
> 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 <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>
> --
> =
> =
> =
> =
> =
> ======================================================================
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>