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

[John M McIntosh]

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
= 
= 
= 
========================================================================