[Vm-dev] Fwd: issues with Alien sendInvokeCallback:Stack:Registers:Jmpbuf:

[John M McIntosh]

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

--
= 
= 
= 
========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
= 
= 
= 
========================================================================