Uploaded image for project: 'JikesRVM'
  1. JikesRVM
  2. RVM-47

DaCapo regressions on AIX/PPC

    Details

      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.

        Attachments

          Issue Links

            Activity

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

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

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

            reopening so I can modify fix target to 3.0

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

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: