RVM

If I run manually with either 1 or 2 virtual processors, dacapo anltr passes reliably with a ppc64-aix prototype build.

If I run with processors=all, then I get 100% reproduction of the failure we're seeing on the nightly tests on antlr, which has the appended stack dump.

Excalibur is a 4-way smp machine. (so all == 4).

In the interest of getting a little more testing done on AIX, I'm going to hack excaliburs config to only use 2 processors for now while I continue to poke at this. If we can run with 2 processors, then this isn't a critical regression, just a bug we need to work out. On the plus side, it's 100% repeatable in a prototype build.

[excalibur:/u/dgrove/rvmRoot] ./dist/prototype_ppc64-aix/rvm -X:processors=all -jar /homes/excalibur/jikesrvm/benchmarks/dacapo/dacapo-2006-10.jar antlr
java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException
at java.lang.reflect.Constructor.newInstance(Constructor.java:130)
at dacapo.TestHarness.runBenchmark(TestHarness.java:268)
at dacapo.TestHarness.main(TestHarness.java:240)
at Harness.main(Harness.java:5)
Caused by: java.io.FileNotFoundException: ./scratch/antlr/CommonTokenTypes.txt
at java.io.FileOutputStream.<init>(FileOutputStream.java:172)
at java.io.FileOutputStream.<init>(FileOutputStream.java:129)
at dacapo.Benchmark.unpackZipStream(Benchmark.java:490)
at dacapo.Benchmark.unpackZipFileResource(Benchmark.java:470)
at dacapo.Benchmark.prepare(Benchmark.java:159)
at dacapo.antlr.AntlrHarness.prepare(AntlrHarness.java:26)
at dacapo.Benchmark.<init>(Benchmark.java:151)
at dacapo.antlr.AntlrHarness.<init>(AntlrHarness.java:22)
at <invisible method>(Unknown Source:0)
at org.jikesrvm.runtime.VM_Reflection.invoke(VM_Reflection.java:132)
at org.jikesrvm.runtime.VM_Reflection.invoke(VM_Reflection.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:128)
...3 more
Caused by: java.io.IOException: Error 0
at <invisible method>(Unknown Source:0)
at org.jikesrvm.runtime.VM_Reflection.invoke(VM_Reflection.java:132)
at org.jikesrvm.runtime.VM_Reflection.invoke(VM_Reflection.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:128)
at org.jikesrvm.jni.VM_JNIFunctions.ThrowNew(VM_JNIFunctions.java:289)
at gnu.java.nio.VMChannel.open(VMChannel.java:0)
at gnu.java.nio.VMChannel.openFile(VMChannel.java:747)
at gnu.java.nio.FileChannelImpl.<init>(FileChannelImpl.java:151)
at gnu.java.nio.FileChannelImpl.create(FileChannelImpl.java:141)
at java.io.FileOutputStream.<init>(FileOutputStream.java:164)
...14 more

We're still seeing this stacktrace on all the failing DaCapo runs on ppc64-aix (even with 2 virtual processors), even in prototype images.

It doesn't seem to be appearing on ppc32-aix, so it might be fruitful to look at 32 vs. 64 bit code relating to IO operations (alignment assumptions? classpath native code?).

Sigh. Pushing ppc64 problems off to 2.9.3; don't think we're going to be able to nail these in 2.9.2 time frame.

ppc32-aix working nicely again. ppc64-aix still has issues, but tracking under separate bug.

reopening so I can modify fix target to 3.0