RVM
  1. RVM
  2. RVM-294

JikesRVM fails to build using a Classpath VM

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      ia32-linux
    • Testcase included:
      yes
    • Number of attachments :
      1

      Description

      Building JikesRVM with either JamVM or CACAO and GNU Classpath currently fails due to a difference in the VMRuntime classes. JikesRVM's version is public, while the Classpath copy is package-private.

      gen-interface:
      [java] java.lang.ExceptionInInitializerError
      [java] at org.jikesrvm.ia32.VM_OutOfLineMachineCode.generateThreadSwitchInstructions(VM_OutOfLineMachineCode.java:342)
      [java] at org.jikesrvm.ia32.VM_OutOfLineMachineCode.init(VM_OutOfLineMachineCode.java:55)
      [java] at org.jikesrvm.VM.init(VM.java:2216)
      [java] at org.jikesrvm.VM.initForTool(VM.java:107)
      [java] at org.jikesrvm.VM.initForTool(VM.java:95)
      [java] at org.jikesrvm.tools.header_gen.GenerateInterfaceDeclarations.main(GenerateInterfaceDeclarations.java:162)
      [java] Caused by: java.lang.IllegalAccessException: class is not accessible
      [java] at org.jikesrvm.runtime.VM_Entrypoints.<clinit>(VM_Entrypoints.java:78)
      [java] at org.jikesrvm.ia32.VM_OutOfLineMachineCode.generateThreadSwitchInstructions(VM_OutOfLineMachineCode.java:342)
      [java] ...5 more

      The line in question is:

      public static final VM_Field gcLockField = getField(java.lang.VMRuntime.class, "gcLock", int.class);

      I don't know if this is new or not, but we could build earlier. Trying to put this line in a separate file to test causes the compile to fail because VMRuntime is private:

      javac -cp target/prototype_x86_64-linux/jksvm.jar:target/prototype_x86_64-linux/rvmrt.jar Test.java
      Test.java:7: java.lang.VMRuntime is not public in java.lang; cannot be accessed from outside package
      System.out.println(getField(java.lang.VMRuntime.class, "gcLock", int.class));
      ^
      1 error

      Using the jars as the bootclasspath works but the test still fails.

      java org/jikesrvm/runtime/Test
      java.lang.IllegalAccessException: class is not accessible
      at org.jikesrvm.runtime.Test.main(Test.java:9)

      1. Test.java
        0.2 kB
        Andrew John Hughes

        Activity

        Hide
        Andrew John Hughes added a comment -
        Show
        Andrew John Hughes added a comment - Filed in Classpath as well: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33731
        Hide
        Andrew John Hughes added a comment -

        Using the string version of getField means this now fails with a non-existant "java.lang.VMRuntime" Error.

        Show
        Andrew John Hughes added a comment - Using the string version of getField means this now fails with a non-existant "java.lang.VMRuntime" Error.
        Hide
        Ian Rogers added a comment -

        That's odd.. does the string need to be formatted as "Ljava/lang/VMRuntime;" ?

        Show
        Ian Rogers added a comment - That's odd.. does the string need to be formatted as "Ljava/lang/VMRuntime;" ?
        Hide
        Andrew John Hughes added a comment -

        Thanks Ian. You were right, the string does need to use the type name. However, this works only up until it hangs building the bootimage:

        build-bootimage-writer:
        [mkdir] Created dir: /home/gandalf/projects/java/classpath/jikesrvm.jamvm/target/prototype_x86_64-linux/bootimage-writer
        [javac] Compiling 7 source files to /home/gandalf/projects/java/classpath/jikesrvm.jamvm/target/prototype_x86_64-linux/bootimage-writer

        gen-primordial-list:

        build-bootimage:
        [echo] Building bootimage. Output redirected to : /home/gandalf/projects/java/classpath/jikesrvm.jamvm/target/prototype_x86_64-linux/BootImageWriterOutput.txt
        [echo] MMTk properties = /home/gandalf/projects/java/classpath/jikesrvm.jamvm/build/mmtk/default.properties

        Show
        Andrew John Hughes added a comment - Thanks Ian. You were right, the string does need to use the type name. However, this works only up until it hangs building the bootimage: build-bootimage-writer: [mkdir] Created dir: /home/gandalf/projects/java/classpath/jikesrvm.jamvm/target/prototype_x86_64-linux/bootimage-writer [javac] Compiling 7 source files to /home/gandalf/projects/java/classpath/jikesrvm.jamvm/target/prototype_x86_64-linux/bootimage-writer gen-primordial-list: build-bootimage: [echo] Building bootimage. Output redirected to : /home/gandalf/projects/java/classpath/jikesrvm.jamvm/target/prototype_x86_64-linux/BootImageWriterOutput.txt [echo] MMTk properties = /home/gandalf/projects/java/classpath/jikesrvm.jamvm/build/mmtk/default.properties
        Hide
        Ian Rogers added a comment -

        That's odd, wonder if boot image writing is stressing parts of the VMs not stressed before. In particular the recent change to make the Intel assembler typed means we're hitting a lot of enumeration code now. There are some verbosity flags for the boot image writer. Some can be configured using ant (iirc - you'll need to look at the build.xml to work out what they are) and some others can be configured by toggling them in the boot image writer code itself. The output is off course all redirected into the target/prototype_x86_64-linux/BootImageWriterOutput.txt file so you'll need to look there to see where boot image writing got up to before it crashed. Is there any output in that file currently? Redirecting output the way we do tends to mask seeing errors Thanks for looking into this.

        Show
        Ian Rogers added a comment - That's odd, wonder if boot image writing is stressing parts of the VMs not stressed before. In particular the recent change to make the Intel assembler typed means we're hitting a lot of enumeration code now. There are some verbosity flags for the boot image writer. Some can be configured using ant (iirc - you'll need to look at the build.xml to work out what they are) and some others can be configured by toggling them in the boot image writer code itself. The output is off course all redirected into the target/prototype_x86_64-linux/BootImageWriterOutput.txt file so you'll need to look there to see where boot image writing got up to before it crashed. Is there any output in that file currently? Redirecting output the way we do tends to mask seeing errors Thanks for looking into this.
        Hide
        Andrew John Hughes added a comment -

        I think this is the stalling thread, seems to never wake up:

        [java] "pool-1-thread-1" 0xccba90 priority: 5 tid: 0x42804960 id: 6 state: RUNNABLE (6)
        [java] at java.lang.VMThread.sleep(Native method)
        [java] at java.lang.Thread.sleep(Thread.java:902)
        [java] at java.lang.Thread.sleep(Thread.java:866)
        [java] at org.jikesrvm.classloader.VM_Array.instantiate(VM_Array.java:481)
        [java] at org.jikesrvm.tools.bootImageWriter.BootImageWorker.run(BootImageWorker.java:44)
        [java] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:679)
        [java] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:704)
        [java] at java.lang.Thread.run(Thread.java:743)

        Show
        Andrew John Hughes added a comment - I think this is the stalling thread, seems to never wake up: [java] "pool-1-thread-1" 0xccba90 priority: 5 tid: 0x42804960 id: 6 state: RUNNABLE (6) [java] at java.lang.VMThread.sleep(Native method) [java] at java.lang.Thread.sleep(Thread.java:902) [java] at java.lang.Thread.sleep(Thread.java:866) [java] at org.jikesrvm.classloader.VM_Array.instantiate(VM_Array.java:481) [java] at org.jikesrvm.tools.bootImageWriter.BootImageWorker.run(BootImageWorker.java:44) [java] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:679) [java] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:704) [java] at java.lang.Thread.run(Thread.java:743)
        Hide
        Andrew John Hughes added a comment -

        Log ends with:

        BootImageWriter: instantiating
        BootImageWriter: compiling with 1 threads

        Show
        Andrew John Hughes added a comment - Log ends with: BootImageWriter: instantiating BootImageWriter: compiling with 1 threads
        Hide
        Ian Rogers added a comment -

        Hi Andrew, the sleep is there to stop a race when building multithreaded iirc. Previously we used to die during booting if a class was being instantiated in parallel to an array trying to be instantiated of that class. It looks like this may be a case where the class is never getting instantiated, in which case it'd be interesting to know what class we were struggling upon. We probably need some extra debug to understand this. Sorry for not having looked into the problem deeply.

        Show
        Ian Rogers added a comment - Hi Andrew, the sleep is there to stop a race when building multithreaded iirc. Previously we used to die during booting if a class was being instantiated in parallel to an array trying to be instantiated of that class. It looks like this may be a case where the class is never getting instantiated, in which case it'd be interesting to know what class we were struggling upon. We probably need some extra debug to understand this. Sorry for not having looked into the problem deeply.
        David Grove made changes -
        Field Original Value New Value
        Fix Version/s 1000 [ 14184 ]
        David Grove made changes -
        Fix Version/s 3.0 [ 13530 ]
        Fix Version/s 1000 [ 14184 ]
        Ian Rogers made changes -
        Component/s Runtime: Class Library: GNU Classpath [ 13375 ]
        Component/s Runtime: Class Library [ 12830 ]
        Hide
        Ian Rogers added a comment -

        The gcLock, original cause of this bug, is now held in a different class (java.lang.VMCommonClassLibrarySupport.GCLock) and may have resolved this issue. Andrew could you test?

        Show
        Ian Rogers added a comment - The gcLock, original cause of this bug, is now held in a different class (java.lang.VMCommonClassLibrarySupport.GCLock) and may have resolved this issue. Andrew could you test?
        Ian Rogers made changes -
        Assignee Andrew John Hughes [ gnu_andrew ]
        Hide
        Andrew John Hughes added a comment -

        Moving to 3.0.1 as I don't have time to try and replicate this right now.

        Building with a Classpath VM needs a simulated JDK layout:

        bin/java
        bin/javah
        bin/apt
        jre/lib/rt.jar
        lib/tools.jar

        Note the need for apt, which means tools.jar must be from Sun's langtools and not Classpath. You can then use this layout for JAVA_HOME.

        Show
        Andrew John Hughes added a comment - Moving to 3.0.1 as I don't have time to try and replicate this right now. Building with a Classpath VM needs a simulated JDK layout: bin/java bin/javah bin/apt jre/lib/rt.jar lib/tools.jar Note the need for apt, which means tools.jar must be from Sun's langtools and not Classpath. You can then use this layout for JAVA_HOME.
        Andrew John Hughes made changes -
        Fix Version/s 3.0.1 [ 14378 ]
        Fix Version/s 3.0 [ 13530 ]
        Hide
        David Grove added a comment -

        Initial triage for 3.0.1 release; suggesting postponing to 3.0.2; move back to 3.0.1 if you disagree.

        Show
        David Grove added a comment - Initial triage for 3.0.1 release; suggesting postponing to 3.0.2; move back to 3.0.1 if you disagree.
        David Grove made changes -
        Fix Version/s 3.0.1 [ 14378 ]
        Fix Version/s 3.0.2 [ 14620 ]
        Hide
        David Grove added a comment -

        Defer to 3.1.1

        Show
        David Grove added a comment - Defer to 3.1.1
        David Grove made changes -
        Fix Version/s 3.1.0 [ 14620 ]
        Fix Version/s 3.1.1 [ 14900 ]
        Hide
        David Grove added a comment -

        bulk defer open issues to 3.1.2

        Show
        David Grove added a comment - bulk defer open issues to 3.1.2
        David Grove made changes -
        Fix Version/s 3.1.2 [ 16568 ]
        Fix Version/s 3.1.1 [ 14900 ]
        Hide
        David Grove added a comment -

        A lot has changed since 2007. Issue made obsolete by OpenJDK.

        Show
        David Grove added a comment - A lot has changed since 2007. Issue made obsolete by OpenJDK.
        David Grove made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 3.1.2 [ 16568 ]
        Resolution Won't Fix [ 2 ]
        Hide
        David Grove added a comment -

        bulk close of all resolved issues in preparation for 3.1.3 release.

        Show
        David Grove added a comment - bulk close of all resolved issues in preparation for 3.1.3 release.
        David Grove made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Andrew John Hughes
            Reporter:
            Andrew John Hughes
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: