Hi John,<div><br></div><div>   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</div>
<div><br></div><div><div>interpret</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>&quot;This is the main interpreter loop. It normally loops forever, fetching and executing</div><div><span class="Apple-tab-span" style="white-space:pre">        </span> bytecodes.  When running in the context of a browser plugin VM, however, it must</div>
<div><span class="Apple-tab-span" style="white-space:pre">        </span> return control to the browser periodically.  This should done only when the state of</div><div><span class="Apple-tab-span" style="white-space:pre">        </span> the currently running Squeak thread is safely stored in the object heap.  Since this</div>
<div><span class="Apple-tab-span" style="white-space:pre">        </span> is the case at the moment that a check for interrupts is performed, that is when we</div><div><span class="Apple-tab-span" style="white-space:pre">        </span> return to the browser if it is time to do so.  Interrupt checks happen quite frequently.&quot;</div>
<div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>&lt;inline: false&gt; &quot;should *not* be inlined into sendInvokeCallback:Stack:Registers:Jmpbuf:&quot;</div><div>...</div><div><br></div>
<div>and you should be good to go.</div><div><br></div><div>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:</div>
<div><br></div><div><div>justActivateNewMethod</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>&quot;Activate the new method but *do not* copy receiver or argumernts from activeContext.&quot;</div><div>
<span class="Apple-tab-span" style="white-space:pre">        </span>| methodHeader initialIP newContext tempCount needsLarge where |</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>self inline: true.</div>
<div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>....</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>activeContext := newContext.</div><div>&gt;<span class="Apple-tab-span" style="white-space:pre">        </span>(self oop: newContext isLessThan: youngStart) ifTrue:</div>
<div>&gt;<span class="Apple-tab-span" style="white-space:pre">                </span>[self beRootIfOld: newContext]</div></div><br></div><div><br></div><div>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&#39;s your head package version?</div>
<div><br><div class="gmail_quote">On Mon, Feb 23, 2009 at 10:06 PM, John M McIntosh <span dir="ltr">&lt;<a href="mailto:johnmci@smalltalkconsulting.com">johnmci@smalltalkconsulting.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
<br>
Begin forwarded message:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: John M McIntosh &lt;<a href="mailto:johnmci@smalltalkconsulting.com" target="_blank">johnmci@smalltalkconsulting.com</a>&gt;<br>
Date: February 23, 2009 9:45:11 PM PST (CA)<br>
To: squeak vm &lt;<a href="mailto:vm-dev@discuss.squeakfoundation.org" target="_blank">vm-dev@discuss.squeakfoundation.org</a>&gt;<br>
Cc: Craig Latta &lt;<a href="mailto:craig@netjam.org" target="_blank">craig@netjam.org</a>&gt;<br>
Subject: issues with Alien sendInvokeCallback:Stack:Registers:Jmpbuf:<br>
Reply-To: <a href="mailto:johnmci@smalltalkconsulting.com" target="_blank">johnmci@smalltalkconsulting.com</a><br>
<br>
Ok, many many hours ago I decided to integrate Craig&#39;s Spoon work with VMMaker dtl-108  and Alien support. Need to start somewhere, should be easy.<br>
Well no, after integrating the changed and doing a extrude and a compile I get missing sendInvokeCallback:Stack:Registers:Jmpbuf<br>
<br>
?<br>
<br>
After much puzzlement and creating a subclass of Dictionary so I could figure out why sendInvokeCallback:Stack:Registers:Jmpbuf gets removed from the methods<br>
dictionary before we decide to remove methods not used, I discovered it&#39;s actually removed in removeMethodsReferingToGlobals:except:<br>
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()<br>
loop thus can be discarded before we reach the point where we discard non-used memorys if not in the don&#39;t discard set.<br>
<br>
?<br>
<br>
The last part of  sendInvokeCallback:Stack:Registers:Jmpbuf  which is marked self export: true.<br>
reads<br>
<br>
        self fetchContextRegisters: activeContext.<br>
        self interpret.<br>
<br>
and Craig&#39;s code added<br>
<br>
interpret<br>
<br>
        self browserPluginInitialiseIfNeeded.<br>
===&gt;    self markAllActiveMethods.<br>
        self internalizeIPandSP.<br>
<br>
<br>
?<br>
<br>
Lots of ? tonight<br>
<br>
so in looking at the Tmetihod parse tree wonders of wonder, the innocent  adding of the markAllActiveMethods alters the inlining decision for<br>
sendInvokeCallback:Stack:Registers:Jmpbuf  and it inlines the browserPluginInitialiseIfNeeded, markAllActiveMethods and internalizeIPandSP<br>
which of course as a side effect makes us drop the method because the logic *assumes* then it&#39;s part of the interpret() loop since the internalizeIPandSP<br>
drags in the interpret() local variables.<br>
<br>
<br>
To fix well we do<br>
<br>
interpretNoInline<br>
        self inline: false.<br>
        self interpret<br>
<br>
and make sendInvokeCallback:Stack:Registers:Jmpbuf call that.<br>
<br>
Oddly before Craig&#39;s changes why sendInvokeCallback:Stack:Registers:Jmpbuf reads...<br>
<br>
        interpret();<br>
        return 1;<br>
<br>
No idea at this late hour WHY that didn&#39;t get inlined  back last Nov when I touched it last<br>
<br>
--<br>
===========================================================================<br>
John M. McIntosh &lt;<a href="mailto:johnmci@smalltalkconsulting.com" target="_blank">johnmci@smalltalkconsulting.com</a>&gt;<br>
Corporate Smalltalk Consulting Ltd.  http://<a href="http://www.smalltalkconsulting.com" target="_blank">www.smalltalkconsulting.com</a><br>
===========================================================================<br>
<br>
<br>
<br>
</blockquote>
<br>
--<br>
===========================================================================<br>
John M. McIntosh &lt;<a href="mailto:johnmci@smalltalkconsulting.com" target="_blank">johnmci@smalltalkconsulting.com</a>&gt;<br>
Corporate Smalltalk Consulting Ltd.  <a href="http://www.smalltalkconsulting.com" target="_blank">http://www.smalltalkconsulting.com</a><br>
===========================================================================<br>
<br>
<br>
<br>
</blockquote></div><br></div>