Clement, Thanks for the update. Given the way the code is structured, it is a bit hard to work on catching the error: it's refactoring-based, so it prepares a set of refactorings, then applies them in one go. So, once you reach the error, you are very far from the point where you decided to produce the code. I have a working solution for now; from what you tell me, those limits will be raised in the near future and I don't have to worry too much about that. Thanks, Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Clément Bera [bera.clement@gmail.com] Envoyé : mardi 10 juin 2014 15:52 à : Pharo Development List Objet : Re: [Pharo-dev] Pharo compilation limits 2014-06-10 14:32 GMT+02:00 GOUBIER Thierry <thierry.goubier@cea.fr<mailto:thierry.goubier@cea.fr>>: Hi Clement, I'm hitting the maximum jump size limit. The method is around 10000 characters long, with a sequence of ifTrue: ifFalse: Hello, For now, this issue is hard to solve. The maximum length of a jump is 1024 instructions (cf bytecode table here: http://clementbera.wordpress.com/2013/09/23/squeakv3plusclosure-bytecode-set... ). The problem of computing the maximum bytecode length of a sequence form a parse tree is that each AST nodes may generate bytecodes of a variable length. In addition, control flow optimizations are done in Opal after the AST, therefore a block node may generate bytecodes of very different sizes. Lastly, we will change the bytecode set in a few months (partly to solve the issue you have) and your bytecode length assumptions will not be valid any more. I think the best way is to catch the error while compiling and override the error behavior. Right now a generic error is raised but it can be fixed. Look at: IRBytecodeGenerator>>jumpForward: , jumpBackward: , jump:if: Replace all the error signals by something like: self error: 'forward jump too big' ====>>> JumpTooBigCompilationError new info: specificInfosFromCompilerToTipSmaCCOnHowToGenerateWorkingCode; signal. Then you can catch it for your compilations. [ "compilation code" ] on: JumpTooBigCompilationError do: [ :ex | "exception handling code" ]. For example: [ Smalltalk compiler source: 'foo ^ nil'; class: Object; failBlock: [^ nil]; compile ] on: JumpTooBigCompilationError do: [ :ex | SmaCC new regenerateMethodBasedOn: ex info ]. However, this issue will be solved in Pharo 4 in a few months. The maximum number of instructions a jump can handle will be increased from 1024 to around 32000. If this is still not enough for you, tell us then we'll patch the compiler backend and the VM front end to work with more important instruction size. Clement Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org<mailto:pharo-dev-bounces@lists.pharo.org>] de la part de Clément Bera [bera.clement@gmail.com<mailto:bera.clement@gmail.com>] Envoyé : mardi 10 juin 2014 08:15 à : Pharo Development List Objet : Re: [Pharo-dev] Pharo compilation limits 2014-06-10 2:23 GMT+02:00 GOUBIER Thierry <thierry.goubier@cea.fr<mailto:thierry.goubier@cea.fr>>: Hi all, anybody would have a way to determine the maximum length / maximum complexity of a method in a Pharo out of a parse tree (or whether if the parse tree is over the limit)? There are many different issues: maximum number of literals, maximum jump size, maximum number of temporaries. Can you precise what problem do you have ? What errors are raised ? The code SmaCC generates easily hit compiler limits (methods too long or too complex), and I have difficulties changing the code generation approach. For Pharo 4, we are implementing a new compiler back end that will remove some of those limits. I have a problem with code generation too and we are solving it. Clément Thanks, Thierry