JikesRVM fails to build using a Classpath VM

Filed in Classpath as well: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33731

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

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

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

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.

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)

Log ends with:

BootImageWriter: instantiating
BootImageWriter: compiling with 1 threads

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.

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?

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.

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

Defer to 3.1.1

bulk defer open issues to 3.1.2

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

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