«

Hi folks,

is there some way how to persuade the javac compiler to accept very long
methods? No, don't worry, I'm not writing this kind of mess. The code in
question is the result of a meta-compilation from another language, and
it turned out that this compiler generated a pretty long java code from
a seemingly simple source. Unfortunately, the compilation of the
generated java code then fails with the infamous "code too large" error.

Is there any kind of tweaking that can be done to make this code
acceptable (besides fixing the compiler that generated the java code
in first place, that is.)?

So long,
Thomas

Thomas Richter wrote:
> Hi folks,
>
> is there some way how to persuade the javac compiler to accept very long
> methods? No, don't worry, I'm not writing this kind of mess. The code in
> question is the result of a meta-compilation from another language, and
> it turned out that this compiler generated a pretty long java code from
> a seemingly simple source. Unfortunately, the compilation of the
> generated java code then fails with the infamous "code too large" error.
>
> Is there any kind of tweaking that can be done to make this code
> acceptable (besides fixing the compiler that generated the java code
> in first place, that is.)?

Turn off optional optimisations.

BugBear

Thomas Richter wrote:

> is there some way how to persuade the javac compiler to accept very long
> methods?
> [...]
> Is there any kind of tweaking that can be done to make this code
> acceptable (besides fixing the compiler that generated the java code
> in first place, that is.)?

'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
<> wrote, quoted or indirectly quoted someone
who said :

> Unfortunately, the compilation of the
>generated java code then fails with the infamous "code too large" error.

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

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Thomas Richter wrote:
> Hi folks,
>
> is there some way how to persuade the javac compiler to accept very long
> methods? No, don't worry, I'm not writing this kind of mess. The code in
> question is the result of a meta-compilation from another language, and
> it turned out that this compiler generated a pretty long java code from
> a seemingly simple source.

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.

"Thomas Richter" <> wrote in message
news:...
> Hi folks,
>
> is there some way how to persuade the javac compiler to accept very long
> methods? No, don't worry, I'm not writing this kind of mess. The code in
> question is the result of a meta-compilation from another language, and it
> turned out that this compiler generated a pretty long java code from
> a seemingly simple source. Unfortunately, the compilation of the generated
> java code then fails with the infamous "code too large" error.
>
> Is there any kind of tweaking that can be done to make this code
> acceptable (besides fixing the compiler that generated the java code
> in first place, that is.)?

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.

jmcgill wrote:

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

I've tried it; the verifier rejects it even if it would otherwise be a
structurally valid classfile.

(That was probably tested on 1.5.0, but might have been 1.4.2 -- I forget)

-- chris

On Wed, 10 May 2006 11:38:48 -0700, jmcgill
<> wrote, quoted or indirectly quoted someone
who said :

>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.

It is a side effect of the class file format. They wanted to make it
compact.
See http://mindprod.com/jgloss/javaclassfileformat.html
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

"Roedy Green" < > wrote in
message news:...
> On Wed, 10 May 2006 13:58:36 +0200, Thomas Richter
> <> wrote, quoted or indirectly quoted someone
> who said :
>
>> Unfortunately, the compilation of the
>>generated java code then fails with the infamous "code too large" error.
>
> 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

I don't know how long this method is, but I have a gut instinct that says
way too much functionality is being crammed into a function, which probably
should have its own class with different several different methods.

Times when I have had astronomically large functions, I have always been
doing something stupid.

--
LTP

"Roedy Green" < > wrote in
message news:...
> On Wed, 10 May 2006 11:38:48 -0700, jmcgill
> <> wrote, quoted or indirectly quoted someone
> who said :
>
>>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.
>
> It is a side effect of the class file format. They wanted to make it
> compact.
> See http://mindprod.com/jgloss/javaclassfileformat.html

That link doesn;t work for me, but this one does:

http://mindprod.com/jgloss/javaclassformat.html