[Vm-dev] a problem with JIT and become:

Camillo Bruni camillobruni at gmail.com
Thu Feb 21 22:46:55 UTC 2013


Thanks guys for the joint effort!

On 2013-02-21, at 23:36, Esteban Lorenzano <estebanlm at gmail.com> wrote:
> Hi Eliot,
> 
> I merged the code and looks working fine. 
> It looks a lot more stable now (I managed to crash it anyway but I don't know how to reproduce it yet). 
> 
> thanks!
> Esteban
> 
> On Feb 21, 2013, at 12:50 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
>> 
>> Hi Esteban,
>> 
>>   I'm checking in the fix now.  You'll want to integrate and test
>> thoroughly in your own version.  But I think I have it.  this will
>> only cope with one-way become when the code of a method doesn't
>> change.  Two-way become, where both methods have machine-code, is too
>> much for my brain right now :)  In any case if two-way become is
>> attempted (on a pair of machine-code methods) I hope the VM will exit
>> with an error message instead of merely crashing.
>> 
>> On Wed, Feb 20, 2013 at 8:21 AM, Esteban Lorenzano <estebanlm at gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Ok, I tried this code:
>>> 
>>> (Delay class>>#handleTimerEvent) setSourcePosition: 200 inFile: 1.
>>> (ProcessorScheduler class>>#idleProcess) setSourcePosition: 200 inFile: 1
>>> 
>>> in latest pharo image: http://pharo.gforge.inria.fr/ci/image/20/20560.zip
>>> 
>>> and it crashes the vm
>>> 
>>> (tried in mac vm, with latest cog from Eliot)
>>> 
>>> this does not happens in squeak because squeak uses another algorithm... but placing same method source in squeak crashes it too.
>>> 
>>> I suspected it was because something in the JIT becomes dizzy, so  I "workarounded" the problem by adding a call voidVMStateForSnapshot before each become (it was just an experiment, don't kill me). Weird is that it solved the problem... of course, this is not usable because then  other places get stuck (like ByteString>>#at:put:), but I think it is showing a problem... isn't?
>>> 
>>> cheers,
>>> Esteban
>> 
>> 
>> 
>> -- 
>> best,
>> Eliot
> 



More information about the Vm-dev mailing list