[Vm-dev] Re: Cog Crash in allocateOpcodesbytecodes

Eliot Miranda eliot.miranda at gmail.com
Sun Apr 29 01:52:57 UTC 2012 

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

>
>
>
> 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 :)
>

The first return beyond the furthest continuation is the end of the method.
 The furthest continuation is the furthest forward we've seen a branch.  If
we see a return beyond all branches that return must be the end of the
method.

e.g.
    expr ifTrue: [^foo] ifFalse: [self bar]. ^self

the first ^foo is not the end of the method because there's a branch around
it from the expr test to the start of [self bar].  But the last ^self is
the end because there's no branch past it.


>
>
>
>
>>
>>>
>>>
>>>>  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
>
>
>


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

More information about the Vm-dev mailing list