[Vm-dev] Re: Cog Crash in allocateOpcodesbytecodes

Fri Apr 27 17:34:02 UTC 2012

On Fri, Apr 27, 2012 at 1:33 AM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
>
> On Fri, Apr 27, 2012 at 2:00 AM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>
>>
>>
>>
>> On Thu, Apr 26, 2012 at 3:26 PM, Mariano Martinez Peck <
>> marianopeck at gmail.com> wrote:
>>
>>>
>>>
>>>
>>>> On Thu, Apr 26, 2012 at 10:42 PM, Mariano Martinez Peck <
>>>> marianopeck at gmail.com> wrote:
>>>>
>>>>> Hi Eliot. We are doing a crazy experiment where we serialize almost
>>>>> all PharoCore and we materialize it in a PharoKernel image. During the
>>>>> initialization (after the load), there is one line that crashes Cog:
>>>>>
>>>>> PolymorphSystemSettings showDesktopLogo: true.
>>>>>
>>>>>
>>>
>>>> For what I can see, I may be related to the fact that
>>>>> #pharoLogoContents is too long or something like that?
>>>>>
>>>>
>>> hehehe now I remember we are putting the source code in the method
>>> trailer. And #pharoLogoContents is too much I guess:
>>>
>>> (PolymorphSystemSettings class >> #pharoLogoContents)  trailer size  ->
>>> 49726
>>>
>>> so..is this a known limitation?
>>>
>>
>> It's been invisible until now :)
>>
>>
>>
>> Ah!  I see.  The JIT compilation process in Cog goes as follows (see
>> Cogit>compileCogMethod:).  Guess the endPC of the method based on its byte
>> size.  Stack allocate space for compilation based on this.  Make an initial
>> pass over the bytecode to a) initialize fixups for the targets of backward
>> jumps, b) count how many blocks the method contains, and c) determine the
>> method's real endPC.  Fixups are used to generate code for branches; they
>> point from the target instruction back to the jump(s) to this instruction.
>>  Since we scan forward we can create the fixups for forward branches when
>> we encounter the branch.  But backward jumps have to be done up front.
>>
>> So there's a chicken-and-egg problem.  The JIT either needs to guess how
>> many fixups it needs before it scans, or it needs to make an extra scan of
>> the bytecocde to determine the actual endPC before it scans to initialize
>> fixups.  I hate to add an extra pass unnecessarily.  So is there a simple
>> criterion the JIT can use to know whether it has to make an extra pass?
>>
>>
> Hi Eliot. We thought about different possibilities but I think the easier
> is to just modify #methodWithHeaderShouldBeCogged: to reject methods "too
> long". So apart from checking the number of literals you can also check the
> total amount of bytes and be sure to be less that the amount that causes
> the crash in allocateOpcodesbytecodes. ?
>
> Another possibility is to add a word to CompiledMethod header that stores
> the endPC, so there is not need to guess. But we will need some
> image-changes and break comptatbilty.
>

I think the right thing to do if for the JIT to do a scan to determine the
actual end pc if the method's byte codes are greater than some limit, e.g.
1024 bytes of bytecodes.  It then rejects the method if the actual end pc
is greater than some limit that we find empirically causes the JIT to crash
because of the size of the alloca.

> Cheers
>
>
>
>
>
>>
>>
>>>
>>> thanks!
>>>
>>>
>>>>  the same experiment with StackVM works fine.
>>>>> Of course in a normal image (without this experiment) I can do
>>>>> PolymorphSystemSettings showDesktopLogo: true. without problems.
>>>>>
>>>>>
>>>>> From gdb i see:
>>>>>
>>>>> (gdb) bt
>>>>> #0  0x0000a190 in compileCogMethod (selector=528828260) at
>>>>> /Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../src/vm/cogit.c:
>>>>> 3601
>>>>> #1  0x00009088 in cogselector (aMethodObj=531503072,
>>>>> aSelectorOop=528828260) at
>>>>> /Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../src/vm/cogit.c:
>>>>> 3129
>>>>> #2  0x0003268b in ceSendsupertonumArgs (selector=528828260,
>>>>> superNormalBar=0, rcvr=536158520, numArgs=0) at
>>>>> /Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../src/vm/gcc3x-cointerpmt.c:11007
>>>>> #3  0x1f40006c in ?? ()
>>>>> #4  0x00067350 in threadSchedulingLoop (vmThread=0x1030c00) at
>>>>> /Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../src/vm/gcc3x-cointerpmt.c:44006
>>>>> #5  0x0003d2cb in initialEnterSmalltalkExecutive () at
>>>>> /Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../src/vm/gcc3x-cointerpmt.c:17788
>>>>> #6  0x0003df8f in initStackPagesAndInterpret () at
>>>>> /Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../src/vm/gcc3x-cointerpmt.c:18208
>>>>> #7  0x00022618 in interpret () at
>>>>> /Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../src/vm/gcc3x-cointerpmt.c:2066
>>>>> #8  0x0006dc60 in -[sqSqueakMainApplication runSqueak]
>>>>> (self=0x1d0ca60, _cmd=0x124ebf) at
>>>>> /Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../platforms/iOS/vm/Common/Classes/sqSqueakMainApplication.m:174
>>>>> #9  0x93ad586c in __NSFirePerformWithOrder ()
>>>>> #10 0x908b8dd2 in __CFRunLoopDoObservers ()
>>>>> #11 0x90874ced in __CFRunLoopRun ()
>>>>> #12 0x908743c4 in CFRunLoopRunSpecific ()
>>>>> #13 0x908741f1 in CFRunLoopRunInMode ()
>>>>> #14 0x97760e04 in RunCurrentEventLoopInMode ()
>>>>> #15 0x97760af5 in ReceiveNextEventCommon ()
>>>>> #16 0x97760a3e in BlockUntilNextEventMatchingListInMode ()
>>>>> #17 0x96d1a595 in _DPSNextEvent ()
>>>>> #18 0x96d19dd6 in -[NSApplication
>>>>> nextEventMatchingMask:untilDate:inMode:dequeue:] ()
>>>>> #19 0x96cdc1f3 in -[NSApplication run] ()
>>>>> #20 0x96cd4289 in NSApplicationMain ()
>>>>> #21 0x0006b9f9 in main (argc=1, argv=0xbffff688, envp=0xbffff690) at
>>>>> /Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../platforms/iOS/vm/Common/main.m:52
>>>>>
>>>>>
>>>>> And the line that fails is:     allocateOpcodesbytecodes((numBytecodes
>>>>> + extra) * 10, numBytecodes);
>>>>>
>>>>> numBytecodes is 49729 and extra is 10.
>>>>>
>>>>> Any idea?
>>>>>
>>>>> thanks!
>>>>>
>>>>> --
>>>>> Mariano
>>>>> http://marianopeck.wordpress.com
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Mariano
>>>> http://marianopeck.wordpress.com
>>>>
>>>>
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>>
>>>
>>
>>
>> --
>> best,
>> Eliot
>>
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120427/55a9136d/attachment-0001.htm