6 messages in org.mozilla.lists.dev-tech-js-engine-rhinoRe: IllegalArgumentException: out of ...
FromSent OnAttachments
William StrathearnNov 20, 2007 11:38 pm 
William StrathearnNov 20, 2007 11:57 pm 
Norris BoydNov 21, 2007 6:05 am 
William StrathearnNov 21, 2007 9:31 am 
William StrathearnNov 21, 2007 4:53 pm 
Attila SzegediNov 22, 2007 12:31 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: IllegalArgumentException: out of range index in 1_6R6 not 1_7R1Actions...
From:Attila Szegedi (szeg@gmail.com)
Date:Nov 22, 2007 12:31:37 am
List:org.mozilla.lists.dev-tech-js-engine-rhino

I remember speaking with Charlie Nutter and Tom Enebo at a conference in October in Denmark -- they were writing the JRuby bytecode compiler just then (I mean, literally, they were sitting in the hotel lobby with their laptops and writing the code). They had a problem of what to do with a huge standard ruby test file that was basically one huge method that easily exceeded the 64K[*] limit and asked what do we do in Rhino with it. I told them we do nothing -- we fail to compile them. I think they ended up implementing some mechanism for automatically breaking down such a method into multiple methods, with a top-level method invoking the broken down pieces in order. I actually have no idea whether they did it in the end, but we definitely discussed it.

I know it's not trivial -- i.e. find a big enough basic block with no abrupt control flows (i.e. break from a loop or a return), preferably one that doesn't access many local variables so you needn't pass too many arguments and return values to and from, and then extract it into a separate method.

OTOH, I can understand how nobody wishes to tackle this as it doesn't occur too often, huge functions are a discouraged practice anyway, and in those rare cases when it happens, people can usually break them down by hand.

Attila.

--

[*] BTW, it's not a 65K limit - 65536 bytes would be 64K. Actually, the limit is 65535 bytes, making it a 64K - 1 byte, or 63,999K limit. This was a public service announcement from the Nitpicking Smartpants Association. :-)

On 2007.11.22., at 1:53, William Strathearn wrote:

Norris was right. This ended up being a problem with the shear size of the script, though not any individual function. The un-minimized version had input delimiters that was permitting separate loading calls to Rhino, bypassing the 65K JVM limit. The minimized version was missing those delimiters and as a whole, was larger than 65K. Once the delimiters were added, my Rhino pre-processor was able to split it effectively and load all chunks into Rhino without problem. Thanks!

On Nov 21, 9:31 am, William Strathearn <bill@gmail.com> wrote:

I don't think it has much to do with the actual size of the script or any particular method inside. The un-minimized script, which is about twice as large in raw bytes and with equivalent complexity, passes through 1.6r6 just fine.

I was hoping to fix whatever was wonky about my minimized JavaScript rather than upgrading to pre-release 1.7 since I don't really have easy control over the server that I'm running the script on.

On Nov 21, 6:05 am, Norris Boyd <norr@gmail.com> wrote:

One change that went in since 1.6R6 was released is a fix forhttps://bugzilla.mozilla.org/show_bug.cgi?id=393848.

I'm assuming that you're writing because just using the pre-released 1.7 is not sufficient for your needs. If that's the case, you could try patching in the changes for that bug (there's a listing of the versions of the changed files at the bottom of the bug report) and see if that fixes the problem. Other than that I'd say wait for the release of 1.7.

--Norris