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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > _______________________________________________ > dev-tech-js-engine-rhino mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
