Cog Crash in allocateOpcodesbytecodes
Locked
Cog Crash in allocateOpcodesbytecodes
 
|
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? 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 |
Re: Cog Crash in allocateOpcodesbytecodes
|
|
BTW...I did an image as you like Eliot, it crashes from startup :)
https://gforge.inria.fr/frs/download.php/30652/PharoKernel-1.4-crash.zip Cheers On Thu, Apr 26, 2012 at 10:42 PM, Mariano Martinez Peck <[hidden email]> 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: -- Mariano http://marianopeck.wordpress.com |
Re: Cog Crash in allocateOpcodesbytecodes
|
|
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? thanks!
-- Mariano http://marianopeck.wordpress.com |
Re: Cog Crash in allocateOpcodesbytecodes
|
|
In reply to this post by Mariano Martinez Peck
On Thu, Apr 26, 2012 at 2:48 PM, Mariano Martinez Peck <[hidden email]> wrote:
That's exactly it. Could you send me the source and the symbolic for the pharoLogoContents method? i.e. symbolic is e.g. (Object >> # printOn:) symbolic. I want to see why the method has so many bytecodes. Then I can think about how to implement a sensible limit on the number of bytecodes.
best, Eliot |
Re: Cog Crash in allocateOpcodesbytecodes
|
|
In reply to this post by Mariano Martinez Peck
On Thu, Apr 26, 2012 at 3:26 PM, Mariano Martinez Peck <[hidden email]> wrote:
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 and b) 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?
best, Eliot |
Re: Cog Crash in allocateOpcodesbytecodes
|
|
In reply to this post by Mariano Martinez Peck
On Thu, Apr 26, 2012 at 3:26 PM, Mariano Martinez Peck <[hidden email]> wrote:
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?
best, Eliot |
Re: Cog Crash in allocateOpcodesbytecodes
|
|
On Fri, Apr 27, 2012 at 2:00 AM, Eliot Miranda <[hidden email]> wrote:
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. Cheers
-- Mariano http://marianopeck.wordpress.com |
Re: Cog Crash in allocateOpcodesbytecodes
|
|
On Fri, Apr 27, 2012 at 1:33 AM, Mariano Martinez Peck <[hidden email]> wrote:
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.
best, Eliot |
Re: Cog Crash in allocateOpcodesbytecodes
|
|
On Fri, Apr 27, 2012 at 7:34 PM, Eliot Miranda <[hidden email]> wrote:
but how do you determinate the end pc ?
-- Mariano http://marianopeck.wordpress.com |
Re: Cog Crash in allocateOpcodesbytecodes
|
|
On Fri, Apr 27, 2012 at 10:51 AM, Mariano Martinez Peck <[hidden email]> wrote:
Scan the bytecodes. See Cogit>scanMethod.
best, Eliot |
Re: Cog Crash in allocateOpcodesbytecodes
|
|
In reply to this post by Eliot Miranda-2
damn you overquoters..! :) > > 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. > yes. i think this is right way to do it. if method size is less than 1kb, then do wild guess, and if it larger, then do the scan. -- Best regards, Igor Stasenko. |
Re: Cog Crash in allocateOpcodesbytecodes
|
|
In reply to this post by Eliot Miranda-2
On Fri, Apr 27, 2012 at 8:01 PM, Eliot Miranda <[hidden email]> wrote:
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 :)
-- Mariano http://marianopeck.wordpress.com |
Re: Cog Crash in allocateOpcodesbytecodes
|
|
On Fri, Apr 27, 2012 at 11:28 AM, Mariano Martinez Peck <[hidden email]> wrote:
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.
best, Eliot |
Re: Cog Crash in allocateOpcodesbytecodes
|
|
ahhh got it now :) Thanks Eliot for the explanation. Now I also understand why you call it "scan" hahaha.
-- Mariano http://marianopeck.wordpress.com |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |