[Vm-dev] Fwd: issues with Alien
eliot.miranda at gmail.com
Tue Feb 24 17:21:59 UTC 2009
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
"This is the main interpreter loop. It normally loops forever, fetching and
bytecodes. When running in the context of a browser plugin VM, however, it
return control to the browser periodically. This should done only when the
the currently running Squeak thread is safely stored in the object heap.
is the case at the moment that a check for interrupts is performed, that is
return to the browser if it is time to do so. Interrupt checks happen
<inline: false> "should *not* be inlined into
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:
"Activate the new method but *do not* copy receiver or argumernts from
| 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.
>> self fetchContextRegisters: activeContext.
>> self interpret.
>> and Craig's code added
>> 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
>> drags in the interpret() local variables.
>> To fix well we do
>> self inline: false.
>> self interpret
>> and make sendInvokeCallback:Stack:Registers:Jmpbuf call that.
>> Oddly before Craig's changes why sendInvokeCallback:Stack:Registers:Jmpbuf
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev