Program too big jump offset (Line number not available)

Post here your questions about Actionscript and Java server side extensions development.

Moderators: Lapo, Bax

CB
Posts: 45
Joined: 04 Aug 2006, 11:15

Program too big jump offset (Line number not available)

Postby CB » 08 Jan 2007, 03:26

Uff. Now what.

I've got about 5000 lines of code in my zone extention and I seem to have hit a limit?

How do I get around this limitation?

here's the meesage: Program too complex: too big jump offset (Line number not available).

It's really NOT too complex. I have a few very long but very simple case statements - nothing difficult.
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Postby Lapo » 08 Jan 2007, 07:06

are you using GOTOs in your code? :shock:
Lapo
--
gotoAndPlay()
...addicted to flash games
CB
Posts: 45
Joined: 04 Aug 2006, 11:15

java error?

Postby CB » 10 Jan 2007, 22:18

Is there some limitation to the compiled size of an extention? If there is I seem to have hit it. :shock: https://bugs.eclipse.org/bugs/show_bug.cgi?id=133109

The above link describes exactly what seems to be happening in my extention. I have a long case statement. If I pull out sections (cases) the code runs fine and compiles. If I put them all in it fails with the following error:Program too complex: too big jump offset (Line number not available)

Same thing that seems to happen to the fellow who's made the above post
cevans
Posts: 15
Joined: 02 Jul 2007, 11:00

Postby cevans » 04 Aug 2007, 10:32

Sorry to bump this, but I'm also getting the same error. I have about 5000 lines of code and some very long case statements.

Is there workaround or bug fix for this? It's pretty much brought development to a halt at the moment since I can't add anymore code to the server-side script.
CB
Posts: 45
Joined: 04 Aug 2006, 11:15

5000 line barrier

Postby CB » 04 Aug 2007, 12:22

I found no way around this so ended up re-writing my code - which was probably a good thing as it was fairly bloated - but it seems to me that this is a serious limitation. Now that I don't write 'bloated' code any more what appens when I hit this barrier again?
cevans
Posts: 15
Joined: 02 Jul 2007, 11:00

Postby cevans » 04 Aug 2007, 21:55

One thing I've noticed is that when I comment out a couple of Trace functions, the script compiles. I also added several conditional statements and it still compiled. But as soon as I uncommented a trace, the script wouldn't compile anymore.

This bug is making me very nervous actually. It means there's a glass ceiling on how complex a server-side script can be.

Generally speaking, how did you rewrite your code? I'm thinking about somehow breaking up the large case statements into smaller functions. This is going to be a lot of work though because I'll also have to modify the client quite a bit. I would do this if I knew it solved the problem. But if I'm just delaying the envitable.... I really don't know... My project is already big and expected to get much larger. I would like to know if this bug is being worked on.
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Postby Lapo » 06 Aug 2007, 07:44

Hi,
SmartFoxServer utilizes Rhino, Mozilla's javascript engine, to compile AS code at runtime and execute it.
It is known that there might be a few cases in which the engine fails to compile the code due to very large methods or extremely large scripts.

There can be a number of workarounds:

1- if you get an error like "Invalid method Code length..." you probably have one or more very long method(s) in your code. Try better organizing the code by splitting the big function into multiple functions. This will also help readability and maintainability of your code.

2- if long functions are not the culprit but your script is huge (5k lines or more) you probably need classes. You could move part of your logic into regular Java classes and use them in your script as if they where AS classes.
We explain how to integrate Java in AS in our documentation and provide examples.

3- try assigning more heap memory to the JVM. This can be done with the -Xmx switch. More infos here --> http://edocs.bea.com/wls/docs61/perform/JVMTuning.html

4- as a last resort it is possible to avoid compiling the code at runtime and let it run in "interpreted" mode. This will probably lead to slower execution of the code but, according to Mozilla's website, it seems that these "code limits" issues disappear in "interpreted mode".

This last solution is not available in the current SFS version but if it proves to solve the issue we can quickly provide a patch that allows to change the settings of the Rhino compiler.

hope it helps

p.s. = a few more details about these compiler issues can be found here:
http://www.mozilla.org/rhino/rhino16R1.html
( scroll down a bit until you find this title -> Removal of code complexity limits in the interpreter )
Lapo

--

gotoAndPlay()

...addicted to flash games
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Postby Lapo » 06 Aug 2007, 07:46

One thing I've noticed is that when I comment out a couple of Trace functions

According to the above links, this is probably due to a jump larger than 32k.
In other words the point in you code where the trace is called is more than 32k "away" from where the trace function is defined...
Lapo

--

gotoAndPlay()

...addicted to flash games
cevans
Posts: 15
Joined: 02 Jul 2007, 11:00

Postby cevans » 07 Aug 2007, 07:42

Lapo wrote:
4- as a last resort it is possible to avoid compiling the code at runtime and let it run in "interpreted" mode. This will probably lead to slower execution of the code but, according to Mozilla's website, it seems that these "code limits" issues disappear in "interpreted mode".

This last solution is not available in the current SFS version but if it proves to solve the issue we can quickly provide a patch that allows to change the settings of the Rhino compiler.



I spent the weekend re-organizing my code code so everything is fine now. Though you might want to add the #include directive to the documentation because I had no idea SFS supported it until just this weekend when I was digging randomly in the forum archives. If I had known earlier, it would have made my life a lot easier. :)

The "interpreted mode" might be a nice feature to have, but I don't think you need to provide a patch for it. You can just add it to a standard release. Since I'm using includes now, it's easier to compartmentalize and split things to smaller functions.

I plan to use Java for performance-intensive functions, but I plan to mostly use ActionScript due to its fast development speed even though I miss some OOP features. I just wanted to make sure a large/complex project was possible with mostly Actionscript.
User avatar
mistermind
Posts: 131
Joined: 15 Sep 2007, 01:33
Contact:

Postby mistermind » 21 Dec 2009, 18:54

I know this post is extremely old but for those who eventually have the same problem, here is the real reason for the error:
- Rhino can't handle big chunks of code within one method alone. In my case I had a single function with over a thousand lines of code. Solution:
Split your function into different segments and order the parent function to execute it one by one.
It doesn't really matter if your javascript/actionscript extension is 5k or 10k lines long as you have enough methods to split the code into small function calls.
SELECT * FROM users WHERE clue > 0
0 rows returned.

Return to “Server Side Extension Development”

Who is online

Users browsing this forum: Google [Bot] and 23 guests