RVM
  1. RVM
  2. RVM-47

DaCapo regressions on AIX/PPC

    Details

    • Number of attachments :
      0

      Description

      Many of the DaCapo benchmarks were running correctly on AIX/PPC in 2.9.0.

      They have regressed. This must be fixed before 2.9.1 is released.

        Issue Links

          Activity

          Hide
          David Grove added a comment -

          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

          Show
          David Grove added a comment - 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
          Hide
          David Grove added a comment -

          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?).

          Show
          David Grove added a comment - 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?).
          Hide
          David Grove added a comment -

          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.

          Show
          David Grove added a comment - 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.
          Hide
          David Grove added a comment -

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

          Show
          David Grove added a comment - ppc32-aix working nicely again. ppc64-aix still has issues, but tracking under separate bug.
          Hide
          David Grove added a comment -

          reopening so I can modify fix target to 3.0

          Show
          David Grove added a comment - reopening so I can modify fix target to 3.0

            People

            • Assignee:
              David Grove
              Reporter:
              David Grove
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: