[Vm-dev] Re: Cog Crash in allocateOpcodesbytecodes

Mariano Martinez Peck marianopeck at gmail.com
Fri Apr 27 18:28:58 UTC 2012


On Fri, Apr 27, 2012 at 8:01 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
>
>
> On Fri, Apr 27, 2012 at 10:51 AM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>>
>>
>>
>> On Fri, Apr 27, 2012 at 7:34 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>>
>>>
>>>
>>>
>>> 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
>>>
>>
>> but how do you determinate the end pc ?
>>
>
> Scan the bytecodes.  See Cogit>scanMethod.
>
>


Hi Eliot. It seems I am still far away from understanding scanMethod. I
cannot figure out how you get the endPC. I see you only set it in this part:
(descriptor isReturn
         and: [pc >= latestContinuation]) ifTrue:
            [endPC := pc].

anyway, I trust you :)




>
>>
>>
>>>  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
>>>
>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>>
>
>
> --
> best,
> Eliot
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120427/b3dcdfd5/attachment.htm


More information about the Vm-dev mailing list