Java 6 and JSP: Codesize Woes

Upgrading to Java 6 spells trouble for JSP compilers: the new bytecode verifier does not allow jsr and ret instructions previously used for generating try/finally-blocks. Instead, finally clauses are inlined on all “exit paths” of a try clause.

Why is this relevant for JSP pages? A JSP page is compiled into one large method, which is usually wrapped with a large try block including a non-trivial finally block for cleanup routines, e.g. for tag reuse. Looking at a reasonably complex JSP page with many tags reveals many exit paths from the try block, meaning that the finally block will be inlined hundreds, if not thousands of times for a single JSP page.

Memory-size issues aside, that still would be a rather cosmetic issue. Here’s the problem: even modern JVMs do have a 64k limit on methods and blocks. While no sane coder should ever hit this limit, this is a serious problem for generated code. It was quite easy to hit this limit before JDK6, and the new compiler makes it even easier.

As a workaround, it seems that setting both source and target to 1.4 (or 1.5) with “-target 1.4 -source 1.4” reverts to the old compiler behaviour, meaning that finally blocks won’t always be inlined and code size decreases. Where to set this parameter depends on the JSP container, in OC4J, for example, it is set in the the java-compiler entry in server.xml. There’s also a bug entry in Sun’s Bug Database.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: