Turn off optional optimisations.

  BugBear

'fraid not.  The limit is built into the classfile format, and won't change
until that changes

There was some hope of that happening in 1.5, but it didn't materialise.  As
far as I can tell, despite the fact that the classfile format will change in
1.6, none of the changes will remove the limits on the lengths of compiled
methods (or related limits).

   -- chris

On Wed, 10 May 2006 13:58:36 +0200, Thomas Richter
<thor@math.TU-Berlin.DE> wrote, quoted or indirectly quoted someone
who said :

If you code is too large, the problem is the JVM byte code addressing
can't span the method.  You need to do something to make the generated
code shorter or to split it up.  See what you could pull off with some
anonymous classes.  I would disassemble the code to see if you can see
any patterns you might encapsulate or code that is inlining
excessively long.

see http://mindprod.com/jgloss/disassembler.html

The fact is your code generator is violating a requirement of the target
language.

My suspicion is that the method-size limit exists in order to facilitate
one or a few of the runtime target platforms, but that's neither here
nor there.  It's a language spec and your code generator is violating
it, and the compiler is rejecting it as it would any other fatal error.

What are you doing?  Setting up a static array from a data structure
that represents an image, or something like that?

For the record, I think the 64K limitation is stupid, and it makes me
wonder if we're shackled with JVM support for 16-bit address registers
somewhere.

I'm told that you can have larger than 64K methods by eliminating try
and synchronized blocks, and compiling without line number information.

This is not the only 16-bit limitation in the classfile format; there
are actually quite a few.  But where nobody is likely to have 65536
local variable in scope, or to put 256 parameters on a method call stack
(or 128 longs!), or to name a field with more than 65535 characters, we
certainly have seen 65536+ byte methods, at least from data definition
blocks.

Do you actually have a procedural method that gets this limit?  Sounds
like your source material is pretty nasty itself.

The problem is, I'm guessing, single methods generating  bytecode that's too
long.  If you look at the generated Java, you might find patterns that lend
themselves to a mechanical fix for this, so that you could post-process the
generated Java instead of changing the generator.  If you could recognize
long stretches that share a fairly small set of  local variables with the
rest of the code, it should be straightforward to move them to private
methods.

I've actually worked with a real-life example of this, a YACC compiler that
generated switches too large for the C++ compiler we were using.  In that
case, we had the YACC source and could modify it, but a post-processor would
have worked equally well.  The fix was to change

   switch (i)
   {
       case 1: ...
       case 2:...
       ...
       case 10000:...
   }

to

   if (i < 1000)
   {
       case 1:...
       ...
       case 999:...
   }
   else if (i < 2000)
   {
       ...
   }
   etc.

VerifyError yes.
Check with the copy and paste detector and see how much code that will
save you. Then see if you can't get the simple source and then the
other languages compilation to deal with it. Used to get these all the
time with Jasper (tomcat) and tags that were in the service method and
not in their own module/method.

John Gagon