Hi,
Sometimes (and also today) after formatting and saving a method, an Error is thrown. Following a chunk of PharoDebug.log TIA Davide --------------------- THERE_BE_DRAGONS_HERE Error: genJumpLong: distance index 1043 is out of range -1024 to 1023 7 December 2016 4:21:53.0426 pm VM: Mac OS - intel - 1096 - CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Sep 30 2016 StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Sep 30 2016 https://github.com/pharo-project/pharo-vm.git Commit: 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200 By: GitHub <[hidden email]> Jenkins build #603 Image: Pharo5.0 [Latest update: #50763] OpalEncoderForV3PlusClosures(Object)>>error: Receiver: an OpalEncoderForV3PlusClosures Arguments and temporary variables: aString: 'genJumpLong: distance index 1043 is out of range -1024 to 1023' Receiver's instance variables: stream: an IRBytecodeGenerator position: nil rootNode: nil blockExtentsToLocals: nil OpalEncoderForV3PlusClosures(OpalBytecodeEncoder)>>outOfRangeError:index:range:to: Receiver: an OpalEncoderForV3PlusClosures Arguments and temporary variables: string: 'distance' index: 1043 rangeStart: -1024 rangeEnd: 1023 Receiver's instance variables: stream: an IRBytecodeGenerator position: nil rootNode: nil blockExtentsToLocals: nil OpalEncoderForV3PlusClosures(OpalEncoderForV3)>>genJumpLong: Receiver: an OpalEncoderForV3PlusClosures Arguments and temporary variables: distance: 1043 Receiver's instance variables: stream: an IRBytecodeGenerator position: nil rootNode: nil blockExtentsToLocals: nil OpalEncoderForV3PlusClosures(OpalEncoderForV3)>>genJump: Receiver: an OpalEncoderForV3PlusClosures Arguments and temporary variables: distance: 1043 Receiver's instance variables: stream: an IRBytecodeGenerator position: nil rootNode: nil blockExtentsToLocals: nil -- View this message in context: http://forum.world.st/genJumpLong-distance-index-1043-is-out-of-range-1024-to-1023-tp4926103.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. |
Hello,
The current bytecode limited the size of jumps. This means that you will get this error if your mehthods are so complex that they require a jump too large. Solution: refactor to simplify. We should improve the error message to explain that. (this will not happen anymore when the new bytecode set gets adopted).
|
In reply to this post by Pharo Smalltalk Developers mailing list
Hi, This will be fixed by using the alternative bytecode set, likely in the next few weeks in Pharo 6 alpha/beta. Basically control flow messages (ifTrue:, to:do:, etc.) cannot have too many statements in their blocks (ifTrue: argument, to:do: second arguments, etc) or the compiler can't compile them due to bytecode set encoding limitation. The new bytecode set is encoded differently and allows such code to be compiled. As a temporary solution, you need to split your code in multiple methods to lower the number of statements inside blocks inside control flow messages. Sorry for the annoyance. We're working on integrating a solution and we believe that this will be integrated in Pharo 6 in the next few weeks. Regards, Clement On Wed, Dec 7, 2016 at 4:14 PM, Davide Varvello via Pharo-dev <[hidden email]> wrote:
|
In reply to this post by Marcus Denker-4
On Wed, Dec 7, 2016 at 9:52 AM, Marcus Denker <[hidden email]> wrote:
Forgive me being pedantic, but it will simply be much less likely. The limit is raised to +/- 32k bytes, but one can still construct methods that will hit these limits.
_,,,^..^,,,_ best, Eliot |
On Wed, 2016-12-07 at 11:10 -0800, Eliot Miranda wrote:
> > > On Wed, Dec 7, 2016 at 9:52 AM, Marcus Denker <[hidden email] > > wrote: > > Hello, > > > > The current bytecode limited the size of jumps. > > > > This means that you will get this error if your mehthods are so > > complex that they > > require a jump too large. > > > > Solution: refactor to simplify. > > > > We should improve the error message to explain that. > > > > (this will not happen anymore when the new bytecode set gets > > adopted). > > > > Forgive me being pedantic, but it will simply be much less likely. > The limit is raised to +/- 32k bytes, but one can still construct > methods that will hit these limits. What prevents you to generate what - if I remember correctly - was called jump island? i.e, generate jump to another jump. This was/is used a lot on PA-RISCs (I might we wrong, I have not seen an alive PA-RISC machine for ages now) Jan > > > > On 7 Dec 2016, at 12:14, Davide Varvello via Pharo-dev <pharo-dev > > > @lists.pharo.org> wrote: > > > > > > > > > From: Davide Varvello <[hidden email]> > > > Subject: genJumpLong: distance index 1043 is out of range -1024 > > > to 1023 > > > Date: 7 December 2016 at 12:14:35 GMT-3 > > > To: [hidden email] > > > > > > > > > Hi, > > > > > > Sometimes (and also today) after formatting and saving a method, > > > an Error is > > > thrown. > > > Following a chunk of PharoDebug.log > > > > > > TIA > > > Davide > > > > > > > > > --------------------- > > > THERE_BE_DRAGONS_HERE > > > Error: genJumpLong: distance index 1043 is out of range -1024 to > > > 1023 > > > 7 December 2016 4:21:53.0426 pm > > > > > > VM: Mac OS - intel - 1096 - CoInterpreter > > > VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: > > > 16138eb3-2390-40f5-a6c8-15f0494936f8 Sep 30 2016 > > > StackToRegisterMappingCogit VMMaker.oscog- > > > HolgerHansPeterFreyther.1880 uuid: > > > 16138eb3-2390-40f5-a6c8-15f0494936f8 Sep 30 2016 > > > https://github.com/pharo-project/pharo-vm.git Commit: > > > 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 > > > 08:40:43 +0200 By: > > > GitHub <[hidden email]> Jenkins build #603 > > > > > > Image: Pharo5.0 [Latest update: #50763] > > > > > > OpalEncoderForV3PlusClosures(Object)>>error: > > > Receiver: an OpalEncoderForV3PlusClosures > > > Arguments and temporary variables: > > > aString: 'genJumpLong: distance index 1043 is > > > out of range -1024 to 1023' > > > Receiver's instance variables: > > > stream: an IRBytecodeGenerator > > > position: nil > > > rootNode: nil > > > blockExtentsToLocals: nil > > > > > > > > > OpalEncoderForV3PlusClosures(OpalBytecodeEncoder)>>outOfRangeErro > > > r:index:range:to: > > > Receiver: an OpalEncoderForV3PlusClosures > > > Arguments and temporary variables: > > > string: 'distance' > > > index: 1043 > > > rangeStart: -1024 > > > rangeEnd: 1023 > > > Receiver's instance variables: > > > stream: an IRBytecodeGenerator > > > position: nil > > > rootNode: nil > > > blockExtentsToLocals: nil > > > > > > > > > OpalEncoderForV3PlusClosures(OpalEncoderForV3)>>genJumpLong: > > > Receiver: an OpalEncoderForV3PlusClosures > > > Arguments and temporary variables: > > > distance: 1043 > > > Receiver's instance variables: > > > stream: an IRBytecodeGenerator > > > position: nil > > > rootNode: nil > > > blockExtentsToLocals: nil > > > > > > > > > OpalEncoderForV3PlusClosures(OpalEncoderForV3)>>genJump: > > > Receiver: an OpalEncoderForV3PlusClosures > > > Arguments and temporary variables: > > > distance: 1043 > > > Receiver's instance variables: > > > stream: an IRBytecodeGenerator > > > position: nil > > > rootNode: nil > > > blockExtentsToLocals: nil > > > > > > > > > > > > -- > > > View this message in context: http://forum.world.st/genJumpLong-d > > > istance-index-1043-is-out-of-range-1024-to-1023-tp4926103.html > > > Sent from the Pharo Smalltalk Developers mailing list archive at > > > Nabble.com. > > > > > > > > > > > > > > > > > -- > _,,,^..^,,,_ > best, Eliot |
On Wed, Dec 7, 2016 at 11:26 AM, Jan Vrany <[hidden email]> wrote: On Wed, 2016-12-07 at 11:10 -0800, Eliot Miranda wrote: Naïvely nothing. But the island must be jumped around. The JIT does assume well-formed control graphics (stacks balanced, no jumps into the middle of basic blocks) so its possible that a jump island could break the VM. I *think* it'll be OK in the RegisterAllocatingCogit because it has stronger merge logic would would allow it to adjust the stack correctly when encountering the island after an unconditional branch around it. One tricky thing about islands is that inserting one can cause another branch to exceed its limits and hence require an island. So it introduces a loop in the backend until a fixed point is reached. IMO, the new byte code, and avoiding very long methods, is preferable to implementing islands :-)
_,,,^..^,,,_ best, Eliot |
In reply to this post by Clément Béra
Thanks clement for your steady push in that direction. On Wed, 07 Dec 2016 19:17:26 +0100, Clément Bera <[hidden email]> wrote:
-- Using Opera's mail client: http://www.opera.com/mail/ |
In reply to this post by Clément Béra
Thanks guys,
The forum.world.st didn't send me your replies and only now I'm aware of your replies. Thanks again Davide
|
Free forum by Nabble | Edit this page |