6

I have a parser written in bigloo scheme functional language which I need to compile into a java class. The whole of the parser is written as a single function. Unfortunately this is causing the JVM compiler to throw a "Method too large" warning and later give "far label in localvar" error. Is there any possible way where I can circumvent this error? I read somewhere about a DontCompileHugeMethods option, does it work? Splitting the function doesnt seem to be a viable option to me :( !!

pakore
  • 11,395
  • 12
  • 43
  • 62
Aditya
  • 61
  • 1
  • 2
  • 2
    Instead of asking if `DontCompileHugeMethods` works, why don't you try it yourself? Anyway, having huge methods is a really bad practice. Try to create some helper functions to not only solve the problem, but to make your code more readable and maintenable. – pakore Jul 07 '10 at 08:10
  • Huge methods are bad practice in human-written code, but this seems to concert generated code, right? A generated parser? In that case, see if the parser generator has a command-line option to avoid generating very large methods. – arnt Jun 08 '20 at 11:27

4 Answers4

4

Is there any possible way where I can circumvent this error?

Well, the root cause of this compiler error is that there are hard limits in the format of bytecode files. In this case, the problem is that a single method can consist of at most 65536 bytes of bytecodes. (See the JVM spec).

The only workaround is to split the method.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • In case the redirect for the old http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html link ever dies, a "modern" link for JVM specs is https://docs.oracle.com/javase/specs/ – Shane Bishop Oct 21 '22 at 20:09
1

Quick and Dirty: Assign all your parameters to class variables of the same name (you must rename your parameters) at the beginning of your function and start chopping up your function in pieces and put those pieces in functions. This should guarantee that your function will basically operate with the same semantics.

But, this will not lead to pretty code!

Marc van Kempen
  • 546
  • 2
  • 7
0

Split the method in related operations or splitting utilities separately.

Sid
  • 4,893
  • 14
  • 55
  • 110
  • Well, the case is a bit different here, the method only consists of a single function call. Now this function has a huge parameter list(the whole of the parser actually!!). So I have no clues how to split this!! – Aditya Jul 07 '10 at 08:23
  • You can surely pass the huge list of parameters to other methods, can't you? – Sid Jul 07 '10 at 13:20
0

Well, the case is a bit different here, the method only consists of a single function call. Now this function has a huge parameter list(the whole of the parser actually!!). So I have no clues how to split this!!

The way to split up such a beast could be:

  • define data holder objects for your parameters (put sets of parameters in objects according to the ontology of your data model),
  • build those data holder objects in their own context
  • pass the parameter objects to the function
rsp
  • 23,135
  • 6
  • 55
  • 69