Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4641955

Javac can produce class files too large to validate or meet the JVM spec

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: P4 P4
    • None
    • 1.3.1
    • tools
    • x86
    • windows_2000



      Name: gm110360 Date: 02/22/2002


      FULL PRODUCT VERSION :
      java version "1.3.1_01"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
      Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)

      FULL OPERATING SYSTEM VERSION :

      Windows2000

      ADDITIONAL OPERATING SYSTEMS :

      Solaris too.



      A DESCRIPTION OF THE PROBLEM :
      if you make a method that is too big ( more than 65536
      bytes ), it will produce the class file, and javap will be
      able to decompile the class file, but the VM will give me
      an error about the method being too big.

      This is of course, only an issue when I have generated
      code. I have to fudge my generator to try not to produce
      methods that are so large they do this.

      I'm sure you are aware of this, but it could at least tell
      me it can't compile, or pull some weird stack thing to try
      to fix the problem, instead of just making an invalid class
      file.

      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      1. Make a class file that has 64536 instructions in a
      single method
      2. Compile it with Javac
      3. Watch it break if you try to run the class in the VM

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      At the very least, it should give me an error message
      instead of pretending like it made a valid class file.
      Optimally ( while I'm shooting the moon ), figure out a way
      to break up the method and play with the call stack so as
      not have an issue. Or just lift the restriction of 65535
      on future JVM releases.

      ERROR MESSAGES/STACK TRACES THAT OCCUR :
      Exception in thread "main" java.lang.ClassFormatError: test (Code of a method lo
      nger than 65535 bytes)
              at java.lang.ClassLoader.defineClass0(Native Method)
              at java.lang.ClassLoader.defineClass(Unknown Source)
              at java.security.SecureClassLoader.defineClass(Unknown Source)
              at java.net.URLClassLoader.defineClass(Unknown Source)
              at java.net.URLClassLoader.access$100(Unknown Source)
              at java.net.URLClassLoader$1.run(Unknown Source)
              at java.security.AccessController.doPrivileged(Native Method)
              at java.net.URLClassLoader.findClass(Unknown Source)
              at java.lang.ClassLoader.loadClass(Unknown Source)
              at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
              at java.lang.ClassLoader.loadClass(Unknown Source)
              at java.lang.ClassLoader.loadClassInternal(Unknown Source)

      This bug can be reproduced always.

      ---------- BEGIN SOURCE ----------
      public class test
      {
      public static void main( String args[] )
      {
      if ( args > 0 ) System.exit( 1 );
      // ... repeated 65536 times ( it's not that hard, only 16 cut/pastes )
      }
      }
      ---------- END SOURCE ----------

      CUSTOMER WORKAROUND :
      There is no work around I know of, other than don't write
      big methods.
      (Review ID: 143163)
      ======================================================================

            gafter Neal Gafter (Inactive)
            gmanwanisunw Girish Manwani (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: