2

Following up on this question: there is a 64kb bytecode limit on Java methods.

What benefit does this provide to the compiler? GCC will happily compile multi-megabyte C methods -- what's the reasoning behind this design decision? Is it just, as suggested in this question, to limit poor programming practices, since 64kb methods are massive? Or is there some specific benefit to the limit being 64kb rather than some other number?

Community
  • 1
  • 1
Patrick Collins
  • 10,306
  • 5
  • 30
  • 69
  • 1
    Aside from anything else, it means that any location in the method can always be addressed using 2 bytes... that could be useful in terms of jump locations, try/catch areas etc. – Jon Skeet May 29 '14 at 16:41
  • I suspect it's the same reason that PC-DOS had a 640kb limit. – kdgregory May 29 '14 at 18:55
  • @JonSkeet - interestingly, there's a `goto_w` instruction that uses a 4-byte offset. – kdgregory May 29 '14 at 18:55
  • 1
    @kdgregory: Very interesting. There's a note about that within the JVM spec, in fact: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.goto_w – Jon Skeet May 29 '14 at 18:57

1 Answers1

9

Offsets in the method bytecode are 2 bytes long (called "u2" in the class file format specification). The maximum offset that can be expressed with u2 is 64kB.

The offsets appear in the actual instructions, such as the if* bytecodes, that are followed by two bytes containing the offset delta of the branch. Also, other class file attributes like the StackMapTable, LocalVariableTable, Exceptions and others contain offsets into the bytecode.

If offsets were u4, then methods could be longer, but all class files would also be larger. It's a trade-off.

Ingo Kegel
  • 46,523
  • 10
  • 71
  • 102