You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Pavel Pervov (JIRA)" <ji...@apache.org> on 2008/03/17 11:19:25 UTC
[jira] Created: (HARMONY-5612) [drlvm][gc] dacapo fails
intermittently on 32-bit systems
[drlvm][gc] dacapo fails intermittently on 32-bit systems
---------------------------------------------------------
Key: HARMONY-5612
URL: https://issues.apache.org/jira/browse/HARMONY-5612
Project: Harmony
Issue Type: Bug
Components: DRLVM
Environment: x86
Reporter: Pavel Pervov
According to snapshot testing results dacapo intermittently fails on 32-bit architecture (both Windows and Linux).
run:
[exec] Apache Harmony Launcher : (c) Copyright 1991, 2008 The Apache Software Foundation or its licensors, as applicable.
[exec] java version "1.5.0"
[exec] pre-alpha : not complete or compatible
[exec] svn = r636792, (Mar 14 2008), Windows/ia32/msvc 1310, release build
[exec] http://harmony.apache.org
[exec] ===== DaCapo antlr starting =====
[exec] Running antlr on grammar antlr/java.g
[exec] ANTLR Parser Generator Version 2.7.2 1989-2003 jGuru.com
[exec] ===== DaCapo antlr PASSED in 1266 msec =====
[exec] ===== DaCapo bloat starting =====
[exec] Optimized with: EDU.purdue.cs.bloat.optimize.Main -only EDU.purdue.cs.bloat.trans -pre -dce -diva -prop -stack-alloc -peel-loops all -f EDU.purdue.cs.bloat.trans.ValueNumbering .\scratch\optimizedcode
[exec] ===== DaCapo bloat PASSED in 6359 msec =====
[exec] ===== DaCapo chart starting =====
[exec] Done plotting: .\scratch/compress-tgt-ptr-prf-time.pdf
[exec] Done plotting: .\scratch/compress-src-ptr-prf-time.pdf
[exec] Done plotting: .\scratch/compress-dst-ptr-prf-time.pdf
[exec] Done plotting: .\scratch/compress-tgt-mut-prf-time.pdf
[exec] Done plotting: .\scratch/compress-src-mut-prf-time.pdf
[exec] Done plotting: .\scratch/compress-dst-mut-prf-time.pdf
[exec] Done plotting: .\scratch/compress-heap-comp-b.pdf
[exec] Done plotting: .\scratch/compress-heap-comp-a.pdf
[exec] Done plotting: .\scratch/compress-tgt-ptr-inf-time.pdf
[exec] Done plotting: .\scratch/compress-src-ptr-inf-time.pdf
[exec] Done plotting: .\scratch/compress-dst-ptr-inf-time.pdf
[exec] Done plotting: .\scratch/compress-tgt-mut-inf-time.pdf
[exec] Done plotting: .\scratch/compress-src-mut-inf-time.pdf
[exec] Done plotting: .\scratch/compress-dst-mut-inf-time.pdf
[exec] ===== DaCapo chart PASSED in 6656 msec =====
[exec] Out of Memory!
[exec]
[exec]
[exec] This application has requested the Runtime to terminate it in an unusual way.
[exec] Please contact the application's support team for more information.
[exec] Result: 3
[copy] Copying 1 file to C:\cc\cc-suites\build\results\dacapo
[echo] Number of tests: (...........)
[echo] N of runned tests(...)
The execution FAILED with the following exception:
The following error occurred while executing this line:
C:\cc\cc-suites\adaptors\dacapo\adaptor.xml:112: Not all workloads completed successfully
Noticing "Out of Memory!" I tacked the message down to GC_GEN code.
I was able to reproduce the failure on Linux automated snapshot testing host running dacapo by hand.
The steps to reproduce are:
-> login to snapshot testing host
-> export MY_USER_NAME=<your_name>
-> mkdir /export/users/$MY_USER_NAME
-> cd /export/users/$MY_USER_NAME
-> export http_proxy=<proxy_host>:<proxy_port>
-> wget http://people.apache.org/builds/harmony/snapshots/r637385/apache-harmony-jdk-r637385-linux-x86-32-snapshot.tar.gz
-> tar xf http://people.apache.org/builds/harmony/snapshots/r637385/apache-harmony-jdk-r637385-linux-x86-32-snapshot.tar.gz
-> export JAVA_HOME=/export/users/$MY_USER_NAME/harmony-jdk-r637385
-> export PATH=$JAVA_HOME/bin:$PATH
-> mkdir dacapo
-> cd dacapo
-> wget http://switch.dl.sourceforge.net/sourceforge/dacapobench/dacapo-2006-10-MR2.jar
-> jar xf dacapo-2006-10-MR2.jar xalan.jar
-> jar xf dacapo-2006-10-MR2.jar "antlr/*"
-> mkdir test
-> cd test
-> export DACAPO_DIR=/export/users/$MY_USER_NAME/dacapo
-> java -Xbootclasspath/p:$DACAPO_DIR/xalan.jar:$DACAPO_DIR -jar $DACAPO_DIR/dacapo-2006-10-MR2.jar -s small antlr bloat chart eclipse fop hsqldb lusearch luindex pmd xalan jython
The run fails after dacapo.chart (major collection fails). For me it fails 2 out of 3 runs.
I tried to statically analize the code but didn't quite succeed. What I guessed is that some of GC collector threads fail to set their Collector::result field to TRUE (or set it to FALSE for some reason).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5612) [drlvm][gc] dacapo fails
intermittently on 32-bit systems
Posted by "Chen Yang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586242#action_12586242 ]
Chen Yang commented on HARMONY-5612:
------------------------------------
Would you please try the new build? Recent GC check-in should have fixed the problem.
I have tried with the new build and finished 15 runs under Windows XP and 15 Win32 runs under Windows 2003 x64 R2. All finished successfully.
Thanks.
> [drlvm][gc] dacapo fails intermittently on 32-bit systems
> ---------------------------------------------------------
>
> Key: HARMONY-5612
> URL: https://issues.apache.org/jira/browse/HARMONY-5612
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: x86
> Reporter: Pavel Pervov
> Assignee: Xiao-Feng Li
>
> According to snapshot testing results dacapo intermittently fails on 32-bit architecture (both Windows and Linux).
> run:
> [exec] Apache Harmony Launcher : (c) Copyright 1991, 2008 The Apache Software Foundation or its licensors, as applicable.
> [exec] java version "1.5.0"
> [exec] pre-alpha : not complete or compatible
> [exec] svn = r636792, (Mar 14 2008), Windows/ia32/msvc 1310, release build
> [exec] http://harmony.apache.org
> [exec] ===== DaCapo antlr starting =====
> [exec] Running antlr on grammar antlr/java.g
> [exec] ANTLR Parser Generator Version 2.7.2 1989-2003 jGuru.com
> [exec] ===== DaCapo antlr PASSED in 1266 msec =====
> [exec] ===== DaCapo bloat starting =====
> [exec] Optimized with: EDU.purdue.cs.bloat.optimize.Main -only EDU.purdue.cs.bloat.trans -pre -dce -diva -prop -stack-alloc -peel-loops all -f EDU.purdue.cs.bloat.trans.ValueNumbering .\scratch\optimizedcode
> [exec] ===== DaCapo bloat PASSED in 6359 msec =====
> [exec] ===== DaCapo chart starting =====
> [exec] Done plotting: .\scratch/compress-tgt-ptr-prf-time.pdf
> [exec] Done plotting: .\scratch/compress-src-ptr-prf-time.pdf
> [exec] Done plotting: .\scratch/compress-dst-ptr-prf-time.pdf
> [exec] Done plotting: .\scratch/compress-tgt-mut-prf-time.pdf
> [exec] Done plotting: .\scratch/compress-src-mut-prf-time.pdf
> [exec] Done plotting: .\scratch/compress-dst-mut-prf-time.pdf
> [exec] Done plotting: .\scratch/compress-heap-comp-b.pdf
> [exec] Done plotting: .\scratch/compress-heap-comp-a.pdf
> [exec] Done plotting: .\scratch/compress-tgt-ptr-inf-time.pdf
> [exec] Done plotting: .\scratch/compress-src-ptr-inf-time.pdf
> [exec] Done plotting: .\scratch/compress-dst-ptr-inf-time.pdf
> [exec] Done plotting: .\scratch/compress-tgt-mut-inf-time.pdf
> [exec] Done plotting: .\scratch/compress-src-mut-inf-time.pdf
> [exec] Done plotting: .\scratch/compress-dst-mut-inf-time.pdf
> [exec] ===== DaCapo chart PASSED in 6656 msec =====
> [exec] Out of Memory!
> [exec]
> [exec]
> [exec] This application has requested the Runtime to terminate it in an unusual way.
> [exec] Please contact the application's support team for more information.
> [exec] Result: 3
> [copy] Copying 1 file to C:\cc\cc-suites\build\results\dacapo
> [echo] Number of tests: (...........)
> [echo] N of runned tests(...)
> The execution FAILED with the following exception:
> The following error occurred while executing this line:
> C:\cc\cc-suites\adaptors\dacapo\adaptor.xml:112: Not all workloads completed successfully
> Noticing "Out of Memory!" I tacked the message down to GC_GEN code.
> I was able to reproduce the failure on Linux automated snapshot testing host running dacapo by hand.
> The steps to reproduce are:
> -> login to snapshot testing host
> -> export MY_USER_NAME=<your_name>
> -> mkdir /export/users/$MY_USER_NAME
> -> cd /export/users/$MY_USER_NAME
> -> export http_proxy=<proxy_host>:<proxy_port>
> -> wget http://people.apache.org/builds/harmony/snapshots/r637385/apache-harmony-jdk-r637385-linux-x86-32-snapshot.tar.gz
> -> tar xf http://people.apache.org/builds/harmony/snapshots/r637385/apache-harmony-jdk-r637385-linux-x86-32-snapshot.tar.gz
> -> export JAVA_HOME=/export/users/$MY_USER_NAME/harmony-jdk-r637385
> -> export PATH=$JAVA_HOME/bin:$PATH
> -> mkdir dacapo
> -> cd dacapo
> -> wget http://switch.dl.sourceforge.net/sourceforge/dacapobench/dacapo-2006-10-MR2.jar
> -> jar xf dacapo-2006-10-MR2.jar xalan.jar
> -> jar xf dacapo-2006-10-MR2.jar "antlr/*"
> -> mkdir test
> -> cd test
> -> export DACAPO_DIR=/export/users/$MY_USER_NAME/dacapo
> -> java -Xbootclasspath/p:$DACAPO_DIR/xalan.jar:$DACAPO_DIR -jar $DACAPO_DIR/dacapo-2006-10-MR2.jar -s small antlr bloat chart eclipse fop hsqldb lusearch luindex pmd xalan jython
> The run fails after dacapo.chart (major collection fails). For me it fails 2 out of 3 runs.
> I tried to statically analize the code but didn't quite succeed. What I guessed is that some of GC collector threads fail to set their Collector::result field to TRUE (or set it to FALSE for some reason).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HARMONY-5612) [drlvm][gc] dacapo fails
intermittently on 32-bit systems
Posted by "Xiao-Feng Li (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Xiao-Feng Li reassigned HARMONY-5612:
-------------------------------------
Assignee: Xiao-Feng Li
> [drlvm][gc] dacapo fails intermittently on 32-bit systems
> ---------------------------------------------------------
>
> Key: HARMONY-5612
> URL: https://issues.apache.org/jira/browse/HARMONY-5612
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: x86
> Reporter: Pavel Pervov
> Assignee: Xiao-Feng Li
>
> According to snapshot testing results dacapo intermittently fails on 32-bit architecture (both Windows and Linux).
> run:
> [exec] Apache Harmony Launcher : (c) Copyright 1991, 2008 The Apache Software Foundation or its licensors, as applicable.
> [exec] java version "1.5.0"
> [exec] pre-alpha : not complete or compatible
> [exec] svn = r636792, (Mar 14 2008), Windows/ia32/msvc 1310, release build
> [exec] http://harmony.apache.org
> [exec] ===== DaCapo antlr starting =====
> [exec] Running antlr on grammar antlr/java.g
> [exec] ANTLR Parser Generator Version 2.7.2 1989-2003 jGuru.com
> [exec] ===== DaCapo antlr PASSED in 1266 msec =====
> [exec] ===== DaCapo bloat starting =====
> [exec] Optimized with: EDU.purdue.cs.bloat.optimize.Main -only EDU.purdue.cs.bloat.trans -pre -dce -diva -prop -stack-alloc -peel-loops all -f EDU.purdue.cs.bloat.trans.ValueNumbering .\scratch\optimizedcode
> [exec] ===== DaCapo bloat PASSED in 6359 msec =====
> [exec] ===== DaCapo chart starting =====
> [exec] Done plotting: .\scratch/compress-tgt-ptr-prf-time.pdf
> [exec] Done plotting: .\scratch/compress-src-ptr-prf-time.pdf
> [exec] Done plotting: .\scratch/compress-dst-ptr-prf-time.pdf
> [exec] Done plotting: .\scratch/compress-tgt-mut-prf-time.pdf
> [exec] Done plotting: .\scratch/compress-src-mut-prf-time.pdf
> [exec] Done plotting: .\scratch/compress-dst-mut-prf-time.pdf
> [exec] Done plotting: .\scratch/compress-heap-comp-b.pdf
> [exec] Done plotting: .\scratch/compress-heap-comp-a.pdf
> [exec] Done plotting: .\scratch/compress-tgt-ptr-inf-time.pdf
> [exec] Done plotting: .\scratch/compress-src-ptr-inf-time.pdf
> [exec] Done plotting: .\scratch/compress-dst-ptr-inf-time.pdf
> [exec] Done plotting: .\scratch/compress-tgt-mut-inf-time.pdf
> [exec] Done plotting: .\scratch/compress-src-mut-inf-time.pdf
> [exec] Done plotting: .\scratch/compress-dst-mut-inf-time.pdf
> [exec] ===== DaCapo chart PASSED in 6656 msec =====
> [exec] Out of Memory!
> [exec]
> [exec]
> [exec] This application has requested the Runtime to terminate it in an unusual way.
> [exec] Please contact the application's support team for more information.
> [exec] Result: 3
> [copy] Copying 1 file to C:\cc\cc-suites\build\results\dacapo
> [echo] Number of tests: (...........)
> [echo] N of runned tests(...)
> The execution FAILED with the following exception:
> The following error occurred while executing this line:
> C:\cc\cc-suites\adaptors\dacapo\adaptor.xml:112: Not all workloads completed successfully
> Noticing "Out of Memory!" I tacked the message down to GC_GEN code.
> I was able to reproduce the failure on Linux automated snapshot testing host running dacapo by hand.
> The steps to reproduce are:
> -> login to snapshot testing host
> -> export MY_USER_NAME=<your_name>
> -> mkdir /export/users/$MY_USER_NAME
> -> cd /export/users/$MY_USER_NAME
> -> export http_proxy=<proxy_host>:<proxy_port>
> -> wget http://people.apache.org/builds/harmony/snapshots/r637385/apache-harmony-jdk-r637385-linux-x86-32-snapshot.tar.gz
> -> tar xf http://people.apache.org/builds/harmony/snapshots/r637385/apache-harmony-jdk-r637385-linux-x86-32-snapshot.tar.gz
> -> export JAVA_HOME=/export/users/$MY_USER_NAME/harmony-jdk-r637385
> -> export PATH=$JAVA_HOME/bin:$PATH
> -> mkdir dacapo
> -> cd dacapo
> -> wget http://switch.dl.sourceforge.net/sourceforge/dacapobench/dacapo-2006-10-MR2.jar
> -> jar xf dacapo-2006-10-MR2.jar xalan.jar
> -> jar xf dacapo-2006-10-MR2.jar "antlr/*"
> -> mkdir test
> -> cd test
> -> export DACAPO_DIR=/export/users/$MY_USER_NAME/dacapo
> -> java -Xbootclasspath/p:$DACAPO_DIR/xalan.jar:$DACAPO_DIR -jar $DACAPO_DIR/dacapo-2006-10-MR2.jar -s small antlr bloat chart eclipse fop hsqldb lusearch luindex pmd xalan jython
> The run fails after dacapo.chart (major collection fails). For me it fails 2 out of 3 runs.
> I tried to statically analize the code but didn't quite succeed. What I guessed is that some of GC collector threads fail to set their Collector::result field to TRUE (or set it to FALSE for some reason).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.