Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

65535 bytes method code limit?

318 views
Skip to first unread message

aloha.kakuikanu

unread,
Mar 1, 2007, 4:24:13 PM3/1/07
to
I'm getting:

"The code of method mTokens() is exceeding the 65535 bytes limit"

The method is antlr generated, so I struggle to find any workaround.
Perhaps I'm missing some magic JVM parameter setting? Aren't 16 bit
integers relics of the past century?

Chris Uppal

unread,
Mar 1, 2007, 5:04:29 PM3/1/07
to
aloha.kakuikanu wrote:

It's a hard limit in Java, I'm afraid. No way around it (with current versions
of Java) because it's a limit of the classfile format itself, rather than a
limit of the Java compiler, or of the JVM.

(Actually, the limit in the classfile is rather more complicated than that, and
you can, structurally, have more than 64K bytes of bytecode per method, but
there are various auxiliary structures in the classfile which do have a 64K
limits.)

-- chris

Florian Weimer

unread,
Mar 2, 2007, 7:45:31 AM3/2/07
to
* aloha kakuikanu:

> I'm getting:
>
> "The code of method mTokens() is exceeding the 65535 bytes limit"
>
> The method is antlr generated, so I struggle to find any workaround.
> Perhaps I'm missing some magic JVM parameter setting?

Anything that compiles to class files in a straightforward way will
hit this limit, as Chris explained.

There are basically two workarounds: Use a compiler that synthesizes
additional classes to work around the limit (I don't know if one
exists), or a compiler that does not compile to class files, such as
an earlier GCJ version. The latter approach might work if your
intention is to get the code running. (Nowadays, GCJ uses class files
as well.)

Roedy Green

unread,
May 25, 2007, 4:35:05 AM5/25/07
to
On 1 Mar 2007 13:24:13 -0800, "aloha.kakuikanu"
<aloha.k...@yahoo.com> wrote, quoted or indirectly quoted someone
who said :

>Perhaps I'm missing some magic JVM parameter setting? Aren't 16 bit
>integers relics of the past century?

Nope. Using 32 bit addressing would double the size of a class file.
It is rare to blow the limit unless you are mechanically generating
code.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

glen herrmannsfeldt

unread,
May 31, 2007, 5:48:57 PM5/31/07
to
Roedy Green wrote:
> On 1 Mar 2007 13:24:13 -0800, "aloha.kakuikanu"
> <aloha.k...@yahoo.com> wrote, quoted or indirectly quoted someone

>>Perhaps I'm missing some magic JVM parameter setting? Aren't 16 bit


>>integers relics of the past century?

> Nope. Using 32 bit addressing would double the size of a class file.
> It is rare to blow the limit unless you are mechanically generating
> code.

If you used an escape or prefix code for larger addresses it wouldn't
double the size. I believe that might have been part of the
design, but was never (as far as I know) implemented. Yes, it is
exactly mechanically generated code that needs this.

(The IBM z/OS system only allows code below the 2GB bar. There
has been discussion on the need for this restriction, but again
it is only machine generated code that is likely to cause problems.)

-- glen

0 new messages