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

Eliot Miranda eliot.miranda at gmail.com
Thu Feb 21 05:24:26 UTC 2013


On Wed, Feb 20, 2013 at 4:39 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>
> it looks like we finally found the root problem with #become:
> i was always wondering why VM so fragile with #becoming compiled methods.
>
> the crash is often happened during code loading time (when code loads,
> new methods get compiled),

but this doesn't do become:. it creates new methods.

> when some of the methods which has activation get modified.
> interesting that this problem does not reveals itself during live
> debugging sessions, when you modifying the
> code in debugger and continue running it.

that does not do a become:.  It adds a new method.

>
> On 21 February 2013 00:50, 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
>
>
>
> --
> Best regards,
> Igor Stasenko.



-- 
best,
Eliot


More information about the Vm-dev mailing list