You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
(13) |
Apr
(62) |
May
(73) |
Jun
(325) |
Jul
(266) |
Aug
(122) |
Sep
(305) |
Oct
(245) |
Nov
(65) |
Dec
(40) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(41) |
Feb
(100) |
Mar
(201) |
Apr
(302) |
May
(310) |
Jun
(169) |
Jul
(392) |
Aug
(215) |
Sep
(163) |
Oct
(128) |
Nov
(92) |
Dec
(97) |
2009 |
Jan
(90) |
Feb
(219) |
Mar
(66) |
Apr
(90) |
May
(124) |
Jun
(59) |
Jul
(38) |
Aug
(56) |
Sep
(37) |
Oct
(39) |
Nov
(17) |
Dec
(17) |
2010 |
Jan
(7) |
Feb
(6) |
Mar
(11) |
Apr
(27) |
May
(33) |
Jun
(28) |
Jul
(102) |
Aug
(6) |
Sep
(8) |
Oct
(25) |
Nov
(24) |
Dec
(8) |
2011 |
Jan
(15) |
Feb
(8) |
Mar
(8) |
Apr
(13) |
May
(11) |
Jun
(28) |
Jul
(14) |
Aug
(17) |
Sep
(23) |
Oct
(19) |
Nov
(8) |
Dec
(161) |
2012 |
Jan
(33) |
Feb
(63) |
Mar
(24) |
Apr
(21) |
May
(24) |
Jun
(19) |
Jul
(72) |
Aug
(181) |
Sep
(30) |
Oct
(14) |
Nov
(18) |
Dec
(12) |
2013 |
Jan
(64) |
Feb
(142) |
Mar
(23) |
Apr
(33) |
May
(31) |
Jun
(62) |
Jul
(54) |
Aug
(28) |
Sep
(32) |
Oct
(62) |
Nov
(57) |
Dec
(16) |
2014 |
Jan
(24) |
Feb
(11) |
Mar
(20) |
Apr
(19) |
May
(18) |
Jun
(14) |
Jul
(33) |
Aug
(14) |
Sep
(24) |
Oct
(11) |
Nov
(16) |
Dec
(4) |
2015 |
Jan
(44) |
Feb
(58) |
Mar
(89) |
Apr
(149) |
May
(48) |
Jun
(40) |
Jul
(31) |
Aug
(39) |
Sep
(13) |
Oct
(29) |
Nov
(20) |
Dec
(13) |
2016 |
Jan
(28) |
Feb
(44) |
Mar
(27) |
Apr
(7) |
May
(29) |
Jun
(18) |
Jul
(4) |
Aug
(11) |
Sep
(2) |
Oct
(6) |
Nov
(19) |
Dec
(5) |
2017 |
Jan
(5) |
Feb
(1) |
Mar
|
Apr
(11) |
May
(10) |
Jun
(3) |
Jul
(3) |
Aug
(4) |
Sep
|
Oct
(8) |
Nov
(7) |
Dec
(6) |
2018 |
Jan
(7) |
Feb
(12) |
Mar
(3) |
Apr
(12) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(14) |
2019 |
Jan
(1) |
Feb
(4) |
Mar
(11) |
Apr
|
May
(7) |
Jun
(7) |
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2022 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: SourceForge.net <no...@so...> - 2007-05-26 02:16:08
|
Bugs item #1626523, was opened at 2007-01-02 23:12 Message generated for change (Comment added) made by captain5050 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1626523&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: optimizing compiler Group: None Status: Open Resolution: None Priority: 8 Private: No Submitted By: Steve Blackburn (steveb-oss) Assigned to: Nobody/Anonymous (nobody) Summary: static elision of cast check seems broken Initial Comment: See r11258 for a work-around commit. The context of this bug is the introduction of a new layer in the class hierarchy (com.ibm.jikesrvm.ArchitectureSpecific) for all arch specific code. The commit of that work will follow r11258. In OPT_ConvertALUOperations.noncommutative(), I now get a class-cast exception when running _201_compress on the following call to op1.asRegister() (which is a simple cast from OPT_Operand to OPT_RegisterOperand). if (op1.isRegister()) { OPT_DefUse.removeUse(op1.asRegister()); } This seemed like nonsense since the cast was already guarded by an explicit check (!), so I tried the following: if (op1.isRegister()) { if (com.ibm.jikesrvm.VM.VerifyAssertions) com.ibm.jikesrvm.VM._assert(op1 != null); if (com.ibm.jikesrvm.VM.VerifyAssertions) com.ibm.jikesrvm.VM._assert(op1.isRegister()); OPT_DefUse.removeUse(op1.asRegister()); } ...and it failed on the second assertion, which of course is guarded by same test, so should never fail :-) If I force the above code (OPT_ConvertALUOperations.noncommutative()) to be baseline compiled with a @NoOptCompile pragma, it behaves fine. So my guess is that somehow the opt compiler is statically making a false assumption that op1 is a register and when the runtime class cast check or assertion check are done, it turns out that it is not in fact a register. Somehow my messing with the class hierarchy has confused the compiler :-/ ---------------------------------------------------------------------- >Comment By: Ian Rogers (captain5050) Date: 2007-05-26 03:16 Message: Logged In: YES user_id=308843 Originator: NO After removing LIR accumulate instructions the code where this was failing has been removed (so can no longer possibly fail). Its not clear if this was a real bug. Propose closing it unless a specific new test case can be produced. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1626523&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-25 13:21:09
|
Bugs item #1725306, was opened at 2007-05-24 21:34 Message generated for change (Comment added) made by dgrove-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1725306&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: runtime Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Steve Blackburn (steveb-oss) Assigned to: Nobody/Anonymous (nobody) Summary: Eclipse exhausts locks Initial Comment: When running eclipse with a BaseAdaptiveMarkSweep build and a 1G heap, eclipse will fairly often die with the stack trace below (fairly often being about 30% of runs). VM_Lock says we have 2500 locks, so either eclipse generates an insane amount of lock contention, or there is some other problem. To reproduce, do something like: for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19; do echo $i; jikesrvm/dist/BaseAdaptiveMarkSweep_ia32/rvm -Xms1G -Xmx1G -X:processors=2 -X:gc:ignoreSystemGC=true -jar dacapo-2006-10-MR2.jar eclipse; done A variety of manifestations of the bug: 1. Cannot grow lock array greater than maximum possible index -- Stack -- Lorg/jikesrvm/VM; sysFail(Ljava/lang/String;)V at line 1988 Lorg/jikesrvm/scheduler/VM_Lock; growLocks()V at line 441 Lorg/jikesrvm/scheduler/VM_ThinLock; lock(Ljava/lang/Object;Lorg/vmmagic/unboxed/Offset;)V at line 131 Lorg/jikesrvm/scheduler/VM_ThinLock; inlineLock(Ljava/lang/Object;Lorg/vmmagic/unboxed/Offset;)V at line 59 Lorg/eclipse/jdt/internal/core/JavaModelManager; getPerProjectInfo(Lorg/eclipse/core/resources/IProject;Z)Lorg/eclipse/jdt/internal/core/JavaModelManager$PerProjectInfo; at line 1204 Lorg/eclipse/jdt/internal/core/JavaModelManager; getPerProjectInfoCheckExistence(Lorg/eclipse/core/resources/IProject;)Lorg/eclipse/jdt/internal/core/JavaModelManager$PerProjectInfo; at line 1220 2. Exception while running benchmarks!org.eclipse.core.internal.resources.ResourceException: Errors during build. org.eclipse.core.internal.resources.ResourceException: Errors during build. at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:305) <snip snip> at Harness.main(Harness.java:5) Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfoCheckExistence(JavaModelManager.java:1220) at org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo(JavaProject.java:1792) 3. [GC 7 Start 54.28 s 476964KB -> 202432KB 2194.29 ms] at Harness.main(Harness.java:5) Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) at Harness.main(Harness.java:5) Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) 4. [GC 12 Start 89.81 s 318064KB -> 220072KB 2097.20 ms] Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfoCheckExistence(JavaModelManager.java:1220) at org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo(JavaProject.java:1792) at org.eclipse.jdt.internal.core.JavaProject.getOptions(JavaProject.java:1560) ---------------------------------------------------------------------- >Comment By: Dave Grove (dgrove-oss) Date: 2007-05-25 08:21 Message: Logged In: YES user_id=1215435 Originator: NO I agree. Lock index too big is one of the "classic" signs of memory corruption. The status word of an object get's smashed and it just happens that the locking code stumbles across it before anyone else. ---------------------------------------------------------------------- Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-25 02:01 Message: Logged In: YES user_id=1215444 Originator: YES With a bit more verbosity, I see this on failure: [GC 8 Start 68.11 s 656596KB -> 182200KB 2194.25 ms] Lock index out of range! Word: 0x832092f8 index: 51236 locks: 4097 vm internal error at: -- Stack -- Lorg/jikesrvm/VM; sysFail(Ljava/lang/String;)V at line 1988 Lorg/jikesrvm/VM; _assertionFailure(Ljava/lang/String;Ljava/lang/String;)V at line 527 Lorg/jikesrvm/VM; _assert(ZLjava/lang/String;Ljava/lang/String;)V at line 510 Lorg/jikesrvm/VM; _assert(Z)V at line 490 Lorg/jikesrvm/scheduler/VM_ThinLock; getLockIndex(Lorg/vmmagic/unboxed/Word;)I at line 55 Lorg/jikesrvm/scheduler/VM_ThinLock; lock(Ljava/lang/Object;Lorg/vmmagic/unboxed/Offset;)V at line 154 Lorg/jikesrvm/scheduler/VM_ThinLock; inlineLock(Ljava/lang/Object;Lorg/vmmagic/unboxed/Offset;)V at line 84 Lorg/eclipse/jdt/internal/core/JavaModelManager; getPerProjectInfo(Lorg/eclipse/core/resources/IProject;Z)Lorg/eclipse/jdt/internal/core/JavaModelManager$PerProjectInfo; at line 1204 ---------------------------------------------------------------------- Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-25 01:26 Message: Logged In: YES user_id=1215444 Originator: YES Refactoring and assertions added in r12330 seem to suggest some issue with corruption. We see now that the problem is that when getting the lock index, the index is sometimes out of range. However, this same assertion is checked at the time the value is stored and that assertion is never triggered... Forcing VM_ThinkLock.getLockIndex() to be NoOptCompile did not seem to help. Further BaseBase testing continues to run eclipse without failure (many hours now on a fast machine without failure). ---------------------------------------------------------------------- Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-24 21:36 Message: Logged In: YES user_id=1215444 Originator: YES This bug does not appear under BaseBase builds (in fact I have seen no bugs with eclipse under BaseBase, despite a lot of continuous testing in a loop.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1725306&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-25 07:01:39
|
Bugs item #1725306, was opened at 2007-05-25 12:34 Message generated for change (Comment added) made by steveb-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1725306&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: runtime Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Steve Blackburn (steveb-oss) Assigned to: Nobody/Anonymous (nobody) Summary: Eclipse exhausts locks Initial Comment: When running eclipse with a BaseAdaptiveMarkSweep build and a 1G heap, eclipse will fairly often die with the stack trace below (fairly often being about 30% of runs). VM_Lock says we have 2500 locks, so either eclipse generates an insane amount of lock contention, or there is some other problem. To reproduce, do something like: for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19; do echo $i; jikesrvm/dist/BaseAdaptiveMarkSweep_ia32/rvm -Xms1G -Xmx1G -X:processors=2 -X:gc:ignoreSystemGC=true -jar dacapo-2006-10-MR2.jar eclipse; done A variety of manifestations of the bug: 1. Cannot grow lock array greater than maximum possible index -- Stack -- Lorg/jikesrvm/VM; sysFail(Ljava/lang/String;)V at line 1988 Lorg/jikesrvm/scheduler/VM_Lock; growLocks()V at line 441 Lorg/jikesrvm/scheduler/VM_ThinLock; lock(Ljava/lang/Object;Lorg/vmmagic/unboxed/Offset;)V at line 131 Lorg/jikesrvm/scheduler/VM_ThinLock; inlineLock(Ljava/lang/Object;Lorg/vmmagic/unboxed/Offset;)V at line 59 Lorg/eclipse/jdt/internal/core/JavaModelManager; getPerProjectInfo(Lorg/eclipse/core/resources/IProject;Z)Lorg/eclipse/jdt/internal/core/JavaModelManager$PerProjectInfo; at line 1204 Lorg/eclipse/jdt/internal/core/JavaModelManager; getPerProjectInfoCheckExistence(Lorg/eclipse/core/resources/IProject;)Lorg/eclipse/jdt/internal/core/JavaModelManager$PerProjectInfo; at line 1220 2. Exception while running benchmarks!org.eclipse.core.internal.resources.ResourceException: Errors during build. org.eclipse.core.internal.resources.ResourceException: Errors during build. at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:305) <snip snip> at Harness.main(Harness.java:5) Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfoCheckExistence(JavaModelManager.java:1220) at org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo(JavaProject.java:1792) 3. [GC 7 Start 54.28 s 476964KB -> 202432KB 2194.29 ms] at Harness.main(Harness.java:5) Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) at Harness.main(Harness.java:5) Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) 4. [GC 12 Start 89.81 s 318064KB -> 220072KB 2097.20 ms] Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfoCheckExistence(JavaModelManager.java:1220) at org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo(JavaProject.java:1792) at org.eclipse.jdt.internal.core.JavaProject.getOptions(JavaProject.java:1560) ---------------------------------------------------------------------- >Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-25 17:01 Message: Logged In: YES user_id=1215444 Originator: YES With a bit more verbosity, I see this on failure: [GC 8 Start 68.11 s 656596KB -> 182200KB 2194.25 ms] Lock index out of range! Word: 0x832092f8 index: 51236 locks: 4097 vm internal error at: -- Stack -- Lorg/jikesrvm/VM; sysFail(Ljava/lang/String;)V at line 1988 Lorg/jikesrvm/VM; _assertionFailure(Ljava/lang/String;Ljava/lang/String;)V at line 527 Lorg/jikesrvm/VM; _assert(ZLjava/lang/String;Ljava/lang/String;)V at line 510 Lorg/jikesrvm/VM; _assert(Z)V at line 490 Lorg/jikesrvm/scheduler/VM_ThinLock; getLockIndex(Lorg/vmmagic/unboxed/Word;)I at line 55 Lorg/jikesrvm/scheduler/VM_ThinLock; lock(Ljava/lang/Object;Lorg/vmmagic/unboxed/Offset;)V at line 154 Lorg/jikesrvm/scheduler/VM_ThinLock; inlineLock(Ljava/lang/Object;Lorg/vmmagic/unboxed/Offset;)V at line 84 Lorg/eclipse/jdt/internal/core/JavaModelManager; getPerProjectInfo(Lorg/eclipse/core/resources/IProject;Z)Lorg/eclipse/jdt/internal/core/JavaModelManager$PerProjectInfo; at line 1204 ---------------------------------------------------------------------- Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-25 16:26 Message: Logged In: YES user_id=1215444 Originator: YES Refactoring and assertions added in r12330 seem to suggest some issue with corruption. We see now that the problem is that when getting the lock index, the index is sometimes out of range. However, this same assertion is checked at the time the value is stored and that assertion is never triggered... Forcing VM_ThinkLock.getLockIndex() to be NoOptCompile did not seem to help. Further BaseBase testing continues to run eclipse without failure (many hours now on a fast machine without failure). ---------------------------------------------------------------------- Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-25 12:36 Message: Logged In: YES user_id=1215444 Originator: YES This bug does not appear under BaseBase builds (in fact I have seen no bugs with eclipse under BaseBase, despite a lot of continuous testing in a loop.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1725306&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-25 06:26:42
|
Bugs item #1725306, was opened at 2007-05-25 12:34 Message generated for change (Comment added) made by steveb-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1725306&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: runtime Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Steve Blackburn (steveb-oss) Assigned to: Nobody/Anonymous (nobody) Summary: Eclipse exhausts locks Initial Comment: When running eclipse with a BaseAdaptiveMarkSweep build and a 1G heap, eclipse will fairly often die with the stack trace below (fairly often being about 30% of runs). VM_Lock says we have 2500 locks, so either eclipse generates an insane amount of lock contention, or there is some other problem. To reproduce, do something like: for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19; do echo $i; jikesrvm/dist/BaseAdaptiveMarkSweep_ia32/rvm -Xms1G -Xmx1G -X:processors=2 -X:gc:ignoreSystemGC=true -jar dacapo-2006-10-MR2.jar eclipse; done A variety of manifestations of the bug: 1. Cannot grow lock array greater than maximum possible index -- Stack -- Lorg/jikesrvm/VM; sysFail(Ljava/lang/String;)V at line 1988 Lorg/jikesrvm/scheduler/VM_Lock; growLocks()V at line 441 Lorg/jikesrvm/scheduler/VM_ThinLock; lock(Ljava/lang/Object;Lorg/vmmagic/unboxed/Offset;)V at line 131 Lorg/jikesrvm/scheduler/VM_ThinLock; inlineLock(Ljava/lang/Object;Lorg/vmmagic/unboxed/Offset;)V at line 59 Lorg/eclipse/jdt/internal/core/JavaModelManager; getPerProjectInfo(Lorg/eclipse/core/resources/IProject;Z)Lorg/eclipse/jdt/internal/core/JavaModelManager$PerProjectInfo; at line 1204 Lorg/eclipse/jdt/internal/core/JavaModelManager; getPerProjectInfoCheckExistence(Lorg/eclipse/core/resources/IProject;)Lorg/eclipse/jdt/internal/core/JavaModelManager$PerProjectInfo; at line 1220 2. Exception while running benchmarks!org.eclipse.core.internal.resources.ResourceException: Errors during build. org.eclipse.core.internal.resources.ResourceException: Errors during build. at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:305) <snip snip> at Harness.main(Harness.java:5) Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfoCheckExistence(JavaModelManager.java:1220) at org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo(JavaProject.java:1792) 3. [GC 7 Start 54.28 s 476964KB -> 202432KB 2194.29 ms] at Harness.main(Harness.java:5) Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) at Harness.main(Harness.java:5) Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) 4. [GC 12 Start 89.81 s 318064KB -> 220072KB 2097.20 ms] Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfoCheckExistence(JavaModelManager.java:1220) at org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo(JavaProject.java:1792) at org.eclipse.jdt.internal.core.JavaProject.getOptions(JavaProject.java:1560) ---------------------------------------------------------------------- >Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-25 16:26 Message: Logged In: YES user_id=1215444 Originator: YES Refactoring and assertions added in r12330 seem to suggest some issue with corruption. We see now that the problem is that when getting the lock index, the index is sometimes out of range. However, this same assertion is checked at the time the value is stored and that assertion is never triggered... Forcing VM_ThinkLock.getLockIndex() to be NoOptCompile did not seem to help. Further BaseBase testing continues to run eclipse without failure (many hours now on a fast machine without failure). ---------------------------------------------------------------------- Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-25 12:36 Message: Logged In: YES user_id=1215444 Originator: YES This bug does not appear under BaseBase builds (in fact I have seen no bugs with eclipse under BaseBase, despite a lot of continuous testing in a loop.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1725306&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-25 02:36:17
|
Bugs item #1725306, was opened at 2007-05-25 12:34 Message generated for change (Comment added) made by steveb-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1725306&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: runtime Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Steve Blackburn (steveb-oss) Assigned to: Nobody/Anonymous (nobody) Summary: Eclipse exhausts locks Initial Comment: When running eclipse with a BaseAdaptiveMarkSweep build and a 1G heap, eclipse will fairly often die with the stack trace below (fairly often being about 30% of runs). VM_Lock says we have 2500 locks, so either eclipse generates an insane amount of lock contention, or there is some other problem. To reproduce, do something like: for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19; do echo $i; jikesrvm/dist/BaseAdaptiveMarkSweep_ia32/rvm -Xms1G -Xmx1G -X:processors=2 -X:gc:ignoreSystemGC=true -jar dacapo-2006-10-MR2.jar eclipse; done A variety of manifestations of the bug: 1. Cannot grow lock array greater than maximum possible index -- Stack -- Lorg/jikesrvm/VM; sysFail(Ljava/lang/String;)V at line 1988 Lorg/jikesrvm/scheduler/VM_Lock; growLocks()V at line 441 Lorg/jikesrvm/scheduler/VM_ThinLock; lock(Ljava/lang/Object;Lorg/vmmagic/unboxed/Offset;)V at line 131 Lorg/jikesrvm/scheduler/VM_ThinLock; inlineLock(Ljava/lang/Object;Lorg/vmmagic/unboxed/Offset;)V at line 59 Lorg/eclipse/jdt/internal/core/JavaModelManager; getPerProjectInfo(Lorg/eclipse/core/resources/IProject;Z)Lorg/eclipse/jdt/internal/core/JavaModelManager$PerProjectInfo; at line 1204 Lorg/eclipse/jdt/internal/core/JavaModelManager; getPerProjectInfoCheckExistence(Lorg/eclipse/core/resources/IProject;)Lorg/eclipse/jdt/internal/core/JavaModelManager$PerProjectInfo; at line 1220 2. Exception while running benchmarks!org.eclipse.core.internal.resources.ResourceException: Errors during build. org.eclipse.core.internal.resources.ResourceException: Errors during build. at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:305) <snip snip> at Harness.main(Harness.java:5) Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfoCheckExistence(JavaModelManager.java:1220) at org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo(JavaProject.java:1792) 3. [GC 7 Start 54.28 s 476964KB -> 202432KB 2194.29 ms] at Harness.main(Harness.java:5) Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) at Harness.main(Harness.java:5) Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) 4. [GC 12 Start 89.81 s 318064KB -> 220072KB 2097.20 ms] Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfoCheckExistence(JavaModelManager.java:1220) at org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo(JavaProject.java:1792) at org.eclipse.jdt.internal.core.JavaProject.getOptions(JavaProject.java:1560) ---------------------------------------------------------------------- >Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-25 12:36 Message: Logged In: YES user_id=1215444 Originator: YES This bug does not appear under BaseBase builds (in fact I have seen no bugs with eclipse under BaseBase, despite a lot of continuous testing in a loop.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1725306&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-25 02:34:19
|
Bugs item #1725306, was opened at 2007-05-25 12:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1725306&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: runtime Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Steve Blackburn (steveb-oss) Assigned to: Nobody/Anonymous (nobody) Summary: Eclipse exhausts locks Initial Comment: When running eclipse with a BaseAdaptiveMarkSweep build and a 1G heap, eclipse will fairly often die with the stack trace below (fairly often being about 30% of runs). VM_Lock says we have 2500 locks, so either eclipse generates an insane amount of lock contention, or there is some other problem. To reproduce, do something like: for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19; do echo $i; jikesrvm/dist/BaseAdaptiveMarkSweep_ia32/rvm -Xms1G -Xmx1G -X:processors=2 -X:gc:ignoreSystemGC=true -jar dacapo-2006-10-MR2.jar eclipse; done A variety of manifestations of the bug: 1. Cannot grow lock array greater than maximum possible index -- Stack -- Lorg/jikesrvm/VM; sysFail(Ljava/lang/String;)V at line 1988 Lorg/jikesrvm/scheduler/VM_Lock; growLocks()V at line 441 Lorg/jikesrvm/scheduler/VM_ThinLock; lock(Ljava/lang/Object;Lorg/vmmagic/unboxed/Offset;)V at line 131 Lorg/jikesrvm/scheduler/VM_ThinLock; inlineLock(Ljava/lang/Object;Lorg/vmmagic/unboxed/Offset;)V at line 59 Lorg/eclipse/jdt/internal/core/JavaModelManager; getPerProjectInfo(Lorg/eclipse/core/resources/IProject;Z)Lorg/eclipse/jdt/internal/core/JavaModelManager$PerProjectInfo; at line 1204 Lorg/eclipse/jdt/internal/core/JavaModelManager; getPerProjectInfoCheckExistence(Lorg/eclipse/core/resources/IProject;)Lorg/eclipse/jdt/internal/core/JavaModelManager$PerProjectInfo; at line 1220 2. Exception while running benchmarks!org.eclipse.core.internal.resources.ResourceException: Errors during build. org.eclipse.core.internal.resources.ResourceException: Errors during build. at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:305) <snip snip> at Harness.main(Harness.java:5) Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfoCheckExistence(JavaModelManager.java:1220) at org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo(JavaProject.java:1792) 3. [GC 7 Start 54.28 s 476964KB -> 202432KB 2194.29 ms] at Harness.main(Harness.java:5) Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) at Harness.main(Harness.java:5) Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) 4. [GC 12 Start 89.81 s 318064KB -> 220072KB 2097.20 ms] Exception in thread "Java indexing": java.lang.NullPointerException at org.jikesrvm.scheduler.VM_ThinLock.lock(VM_ThinLock.java:133) at org.jikesrvm.scheduler.VM_ThinLock.inlineLock(VM_ThinLock.java:59) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfo(JavaModelManager.java:1204) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfoCheckExistence(JavaModelManager.java:1220) at org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo(JavaProject.java:1792) at org.eclipse.jdt.internal.core.JavaProject.getOptions(JavaProject.java:1560) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1725306&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-24 02:57:07
|
Bugs item #1722506, was opened at 2007-05-21 19:18 Message generated for change (Comment added) made by steveb-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1722506&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries Group: None Status: Open Resolution: None Priority: 8 Private: No Submitted By: Steve Blackburn (steveb-oss) Assigned to: Steve Blackburn (steveb-oss) Summary: dacapo eclipse fails EOF exceptions Initial Comment: Since r11245, which made GNU Classpath 0.93 the default, eclipse reliably fails with a series of EFO exceptions. I've narrowed the problem down and will submit a regression test. ---------------------------------------------------------------------- >Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-24 12:57 Message: Logged In: YES user_id=1215444 Originator: YES I have followed Dave's suggestion and committed a change so that classpath will be patched with the fix below. With this change eclipse now runs to completion. Should we close this bug now, or once we cut to a classpath that does not require patching? ---------------------------------------------------------------------- Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-24 06:56 Message: Logged In: YES user_id=1215444 Originator: YES Sorry Dave for not making that clear. (1) Yes, the bug remains in the classpath cvs head. I am surprised there's been no response to my bug report, it's a pretty brutal bug (truncate files opened with read/write permission). (2) Robin, Daniel and discussed this yesterday. Right now there is no mechanism for doing this in the build scripts, but it should be pretty easy. I meant to follow up and ask if people thought this was OK. If so, one of us can try to do that today. ---------------------------------------------------------------------- Comment By: Dave Grove (dgrove-oss) Date: 2007-05-24 05:29 Message: Logged In: YES user_id=1215435 Originator: NO Two questions: (1) Do we know if this is also a bug in GNU classpath 0.95? If it isn't, then it makes moving up a higher priority item. (2) Even if it isn't fixed in 0.95, seems to me like we should move to 0.95, then apply your patch on the regression machines installed version of classpath 0.95, then enable eclipse. Does that make sense? ---------------------------------------------------------------------- Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-22 14:32 Message: Logged In: YES user_id=1215444 Originator: YES I believe I've nailed it as a Classpath bug and have submitted a bug report. The patch is below. As soon as we pass R1722506, we should re-enable the eclipse tests. --Steve Index: native/jni/java-nio/gnu_java_nio_VMChannel.c =================================================================== RCS file: /sources/classpath/classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c,v retrieving revision 1.17 diff -r1.17 gnu_java_nio_VMChannel.c 1630c1630 < ((nmode == O_RDWR || nmode == O_WRONLY) ? O_TRUNC : 0)) --- > ((nmode == O_WRONLY) ? O_TRUNC : 0)) ---------------------------------------------------------------------- Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-21 20:47 Message: Logged In: YES user_id=1215444 Originator: YES Added a regression test for this tracker item: R1722506 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1722506&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 20:56:24
|
Bugs item #1722506, was opened at 2007-05-21 19:18 Message generated for change (Comment added) made by steveb-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1722506&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries Group: None Status: Open Resolution: None Priority: 8 Private: No Submitted By: Steve Blackburn (steveb-oss) Assigned to: Steve Blackburn (steveb-oss) Summary: dacapo eclipse fails EOF exceptions Initial Comment: Since r11245, which made GNU Classpath 0.93 the default, eclipse reliably fails with a series of EFO exceptions. I've narrowed the problem down and will submit a regression test. ---------------------------------------------------------------------- >Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-24 06:56 Message: Logged In: YES user_id=1215444 Originator: YES Sorry Dave for not making that clear. (1) Yes, the bug remains in the classpath cvs head. I am surprised there's been no response to my bug report, it's a pretty brutal bug (truncate files opened with read/write permission). (2) Robin, Daniel and discussed this yesterday. Right now there is no mechanism for doing this in the build scripts, but it should be pretty easy. I meant to follow up and ask if people thought this was OK. If so, one of us can try to do that today. ---------------------------------------------------------------------- Comment By: Dave Grove (dgrove-oss) Date: 2007-05-24 05:29 Message: Logged In: YES user_id=1215435 Originator: NO Two questions: (1) Do we know if this is also a bug in GNU classpath 0.95? If it isn't, then it makes moving up a higher priority item. (2) Even if it isn't fixed in 0.95, seems to me like we should move to 0.95, then apply your patch on the regression machines installed version of classpath 0.95, then enable eclipse. Does that make sense? ---------------------------------------------------------------------- Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-22 14:32 Message: Logged In: YES user_id=1215444 Originator: YES I believe I've nailed it as a Classpath bug and have submitted a bug report. The patch is below. As soon as we pass R1722506, we should re-enable the eclipse tests. --Steve Index: native/jni/java-nio/gnu_java_nio_VMChannel.c =================================================================== RCS file: /sources/classpath/classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c,v retrieving revision 1.17 diff -r1.17 gnu_java_nio_VMChannel.c 1630c1630 < ((nmode == O_RDWR || nmode == O_WRONLY) ? O_TRUNC : 0)) --- > ((nmode == O_WRONLY) ? O_TRUNC : 0)) ---------------------------------------------------------------------- Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-21 20:47 Message: Logged In: YES user_id=1215444 Originator: YES Added a regression test for this tracker item: R1722506 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1722506&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 19:29:07
|
Bugs item #1722506, was opened at 2007-05-21 04:18 Message generated for change (Comment added) made by dgrove-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1722506&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries Group: None Status: Open Resolution: None Priority: 8 Private: No Submitted By: Steve Blackburn (steveb-oss) Assigned to: Steve Blackburn (steveb-oss) Summary: dacapo eclipse fails EOF exceptions Initial Comment: Since r11245, which made GNU Classpath 0.93 the default, eclipse reliably fails with a series of EFO exceptions. I've narrowed the problem down and will submit a regression test. ---------------------------------------------------------------------- >Comment By: Dave Grove (dgrove-oss) Date: 2007-05-23 14:29 Message: Logged In: YES user_id=1215435 Originator: NO Two questions: (1) Do we know if this is also a bug in GNU classpath 0.95? If it isn't, then it makes moving up a higher priority item. (2) Even if it isn't fixed in 0.95, seems to me like we should move to 0.95, then apply your patch on the regression machines installed version of classpath 0.95, then enable eclipse. Does that make sense? ---------------------------------------------------------------------- Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-21 23:32 Message: Logged In: YES user_id=1215444 Originator: YES I believe I've nailed it as a Classpath bug and have submitted a bug report. The patch is below. As soon as we pass R1722506, we should re-enable the eclipse tests. --Steve Index: native/jni/java-nio/gnu_java_nio_VMChannel.c =================================================================== RCS file: /sources/classpath/classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c,v retrieving revision 1.17 diff -r1.17 gnu_java_nio_VMChannel.c 1630c1630 < ((nmode == O_RDWR || nmode == O_WRONLY) ? O_TRUNC : 0)) --- > ((nmode == O_WRONLY) ? O_TRUNC : 0)) ---------------------------------------------------------------------- Comment By: Steve Blackburn (steveb-oss) Date: 2007-05-21 05:47 Message: Logged In: YES user_id=1215444 Originator: YES Added a regression test for this tracker item: R1722506 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1722506&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 02:35:52
|
Bugs item #1721080, was opened at 2007-05-18 11:46 Message generated for change (Comment added) made by peter_donald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1721080&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Donald (peter_donald) Assigned to: Nobody/Anonymous (nobody) Summary: VM_BaselineGCMapIterator.setupIterator causes a NPE Initial Comment: When forcing very frequent gc's I start to see the following exceptions occurring. Attached is output created when running gcmap-sanity test run. Exception in thread "VM_CollectorThread": java.lang.NullPointerException at org.jikesrvm.classloader.VM_Method.getParameterTypes(VM_Method.java:365) at org.jikesrvm.compilers.baseline.ia32.VM_BaselineGCMapIterator.setupIterator(VM_BaselineGCMapIterator.java:139) at org.jikesrvm.mm.mmtk.ScanThread.setUpFrame(ScanThread.java:371) ... ---------------------------------------------------------------------- >Comment By: Peter Donald (peter_donald) Date: 2007-05-23 12:35 Message: Logged In: YES user_id=1642927 Originator: YES It does not seem to be compiler related so changing category ---------------------------------------------------------------------- Comment By: Peter Donald (peter_donald) Date: 2007-05-18 11:47 Message: Logged In: YES user_id=1642927 Originator: YES File Added: hsqldb-output.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1721080&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 01:42:21
|
Bugs item #1488798, was opened at 2006-05-15 21:41 Message generated for change (Comment added) made by peter_donald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1488798&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: optimizing compiler Group: new Status: Open Resolution: None Priority: 7 Private: No Submitted By: Ian Rogers (captain5050) Assigned to: Ian Rogers (captain5050) >Summary: Leave SSA broken - lack of loop unrolling produces bad gcmap Initial Comment: Since fixing bug 1363830 we can successfully build the Jikes RVM with loop unrolling disabled. However, when running such a build on several benchmarks, it produces the following error: $RVM_ROOT/rvm/bin/rvm SpecApplication -m20 -M20 -a _227_mtrt Will run each benchmark at least 20 times Will run each benchmark at most 20 times Caching Off Speed = 100 Auto run mode ======= _227_mtrt Starting ======= Run 0 start. Total memory=52428800 free memory=42463232 +0 to 99 by 200 +100 to 199 by 200 validRef: REF outside heap, ref = 0x3fe7116b boot 0x47000000->0x56ffffff immortal 0x57000000->0x58ffffff meta 0x59000000->0x5affffff los 0x5b000000->0x64ffffff nursery 0xa1000000->0xafffffff ms 0x65000000->0x96bfffff sanity 0x96c00000->0x98bfffff Invalid ref reported while scanning stack --- METHOD (OPT) Lspec/benchmarks/_205_raytrace/OctNode;.Intersect (Lspec/benchmarks/_205_raytrace/Ray;Lspec/benchmarks/_205_raytrace/Point;F)Lspec/benchmarks/_205_raytrace/OctNode; --- fp = 0x5b6aed9c code base = 0x5b789018 code offset = 0x00001c14 REF=0x3fe7116b (REF OUTSIDE OF HEAP OR NOT MAPPED) -- Stack -- Lorg/mmtk/utility/alloc/BumpPointer; alloc(III)Lorg/vmmagic/unboxed/Address; at line 140 Lorg/mmtk/plan/generational/GenLocal; alloc(IIII)Lorg/vmmagic/unboxed/Address; at line 98 Lorg/mmtk/plan/generational/marksweep/GenMSLocal; alloc(IIII)Lorg/vmmagic/unboxed/Address; at line 97 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/MM_Interface; allocateSpace(Lcom/ibm/JikesRVM/memoryManagers/mmInterface/SelectedPlanLocal;IIIZILorg/vmmagic/unboxed/ObjectReference;)Lorg/vmmagic/unboxed/Address; at line 672 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/MM_Interface; allocateSpace(Lcom/ibm/JikesRVM/memoryManagers/mmInterface/SelectedPlanLocal;IIII)Lorg/vmmagic/unboxed/Address; at line 622 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/MM_Interface; allocateArray(III[Ljava/lang/Object;III)Ljava/lang/Object; at line 601 Lcom/ibm/JikesRVM/VM_Runtime; resolvedNewArray(III[Ljava/lang/Object;III)Ljava/lang/Object; at line 426 Lspec/benchmarks/_205_raytrace/OctNode; Intersect(Lspec/benchmarks/_205_raytrace/Ray;Lspec/benchmarks/_205_raytrace/Point;F)Lspec/benchmarks/_205_raytrace/OctNode; at line 437 Lspec/benchmarks/_205_raytrace/Scene; FindLightBlock(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;F)Z at line 575 Lspec/benchmarks/_205_raytrace/Scene; GetLightColor(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Point;Lspec/benchmarks/_205_raytrace/Vector;Lspec/benchmarks/_205_raytrace/ObjectType;Lspec/benchmarks/_205_raytrace/Color;)V at line 535 Lspec/benchmarks/_205_raytrace/Scene; Shade(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;Lspec/benchmarks/_205_raytrace/Color;FII)V at line 449 Lspec/benchmarks/_205_raytrace/Scene; RenderScene(Lspec/benchmarks/_205_raytrace/Canvas;III)V at line 650 Lspec/benchmarks/_205_raytrace/Runner; run()V at line 133 Lcom/ibm/JikesRVM/VM_Thread; run()V at line 200 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 -- Stack -- Lcom/ibm/JikesRVM/VM_Processor; dispatch(Z)V at line 217 Lcom/ibm/JikesRVM/VM_Thread; morph(Z)V at line 722 Lcom/ibm/JikesRVM/VM_Thread; yield()V at line 618 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/VM_Handshake; requestAndAwaitCompletion(I)V at line 82 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/VM_CollectorThread; collect(Lcom/ibm/JikesRVM/memoryManagers/mmInterface/VM_Handshake;I)V at line 244 Lorg/mmtk/vm/Collection; triggerCollection(I)V at line 133 Lorg/mmtk/plan/generational/Gen; poll(ZLorg/mmtk/policy/Space;)Z at line 193 Lorg/mmtk/policy/Space; acquire(I)Lorg/vmmagic/unboxed/Address; at line 451 Lorg/mmtk/utility/alloc/BumpPointer; allocSlowOnce(IIIZ)Lorg/vmmagic/unboxed/Address; at line 164 Lorg/mmtk/utility/alloc/Allocator; allocSlowBody(IIIZ)Lorg/vmmagic/unboxed/Address; at line 218 Lorg/mmtk/utility/alloc/Allocator; allocSlow(III)Lorg/vmmagic/unboxed/Address; at line 202 Lorg/mmtk/utility/alloc/BumpPointer; alloc(III)Lorg/vmmagic/unboxed/Address; at line 140 Lorg/mmtk/plan/generational/GenLocal; alloc(IIII)Lorg/vmmagic/unboxed/Address; at line 98 Lorg/mmtk/plan/generational/marksweep/GenMSLocal; alloc(IIII)Lorg/vmmagic/unboxed/Address; at line 97 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/MM_Interface; allocateSpace(Lcom/ibm/JikesRVM/memoryManagers/mmInterface/SelectedPlanLocal;IIIZILorg/vmmagic/unboxed/ObjectReference;)Lorg/vmmagic/unboxed/Address; at line 672 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/MM_Interface; allocateSpace(Lcom/ibm/JikesRVM/memoryManagers/mmInterface/SelectedPlanLocal;IIII)Lorg/vmmagic/unboxed/Address; at line 622 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/MM_Interface; allocateArray(III[Ljava/lang/Object;III)Ljava/lang/Object; at line 601 Lcom/ibm/JikesRVM/VM_Runtime; resolvedNewArray(III[Ljava/lang/Object;III)Ljava/lang/Object; at line 426 Lspec/benchmarks/_205_raytrace/OctNode; Intersect(Lspec/benchmarks/_205_raytrace/Ray;Lspec/benchmarks/_205_raytrace/Point;F)Lspec/benchmarks/_205_raytrace/OctNode; at line 437 Lspec/benchmarks/_205_raytrace/Scene; FindLightBlock(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;F)Z at line 575 Lspec/benchmarks/_205_raytrace/Scene; GetLightColor(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Point;Lspec/benchmarks/_205_raytrace/Vector;Lspec/benchmarks/_205_raytrace/ObjectType;Lspec/benchmarks/_205_raytrace/Color;)V at line 535 Lspec/benchmarks/_205_raytrace/Scene; Shade(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;Lspec/benchmarks/_205_raytrace/Color;FII)V at line 449 Lspec/benchmarks/_205_raytrace/Scene; RenderScene(Lspec/benchmarks/_205_raytrace/Canvas;III)V at line 650 Lspec/benchmarks/_205_raytrace/Runner; run()V at line 133 Lcom/ibm/JikesRVM/VM_Thread; run()V at line 200 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 VM_ScanStack: Detected bad GC map; exiting RVM with fatal error -- Stack -- Lorg/mmtk/vm/ScanThread; checkReference(Lorg/vmmagic/unboxed/Address;I)V at line 616 Lorg/mmtk/vm/ScanThread; scanFrameForObjects(I)V at line 400 Lorg/mmtk/vm/ScanThread; scanFrame(I)Lorg/vmmagic/unboxed/Address; at line 320 Lorg/mmtk/vm/ScanThread; scanThreadInternal(Lorg/vmmagic/unboxed/Address;I)V at line 240 Lorg/mmtk/vm/ScanThread; startScan(Lorg/mmtk/plan/TraceLocal;ZLcom/ibm/JikesRVM/VM_Thread;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V at line 200 Lorg/mmtk/vm/ScanThread; scanThread(Lcom/ibm/JikesRVM/VM_Thread;Lorg/mmtk/plan/TraceLocal;ZLorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V at line 166 Lorg/mmtk/vm/ScanThread; scanThread(Lcom/ibm/JikesRVM/VM_Thread;Lorg/mmtk/plan/TraceLocal;Z)V at line 131 Lorg/mmtk/vm/Scanning; computeAllRoots(Lorg/mmtk/plan/TraceLocal;)V at line 236 Lorg/mmtk/plan/StopTheWorldLocal; collectionPhase(IZZ)V at line 102 Lorg/mmtk/plan/generational/GenLocal; collectionPhase(IZZ)V at line 203 Lorg/mmtk/plan/generational/marksweep/GenMSLocal; collectionPhase(IZZ)V at line 230 Lorg/mmtk/plan/SimplePhase; delegatePhase()V at line 170 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/Phase; delegatePhase(I)V at line 148 Lorg/mmtk/plan/ComplexPhase; delegatePhase()V at line 95 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/Phase; delegatePhase(I)V at line 148 Lorg/mmtk/plan/ComplexPhase; delegatePhase()V at line 95 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/StopTheWorldLocal; collect()V at line 57 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/VM_CollectorThread; run()V at line 342 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 As with bug 1363830, this bug is gating the by default enabling of loop versioning, which means we aren't taking advantage of that optimisation. ---------------------------------------------------------------------- >Comment By: Peter Donald (peter_donald) Date: 2007-05-23 11:42 Message: Logged In: YES user_id=1642927 Originator: NO Just noting that "[ 1723869 ] VM_OptMachineCodeMap.generateMCInformation bad gcmap" may be a duplicate of this bug and may give you another data point from which to determine the cause. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2007-05-23 11:33 Message: Logged In: YES user_id=308843 Originator: YES So I've had a go at reproducing this bug with Julian Dolby. Unfortunately the bug has moved from where it was (what looked like a lost copy problem). We could really do with a simple test case. The best way to achieve this is through a binary chop of opt compiled methods. The OptTestHarness is set up to do this. In particular -X:opt:verbose=true will generate OptTestHarness arguments that can be piped into a file and then loaded into the test harness with the -longcommandline argument. Once we've got the IR to pour over both Julian and I are keen to get this bug squashed. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-11-20 09:23 Message: Logged In: YES user_id=308843 Originator: YES This bug also causes the IA32 OPT_AssemblerBase to have a NoInlinePragma on isImmOrLabel. Jikes compilation didn't expose this bug, but ECJ compilation does. Ian ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-08-26 08:17 Message: Logged In: YES user_id=308843 Bug #1543866 where we don't turn static final floats and doubles into constants is related to SSA optimisations, but the phases have nothing to do with float or double constant operands. It seems likely that this bug also exposed bugs when we have simpler IR with more constants. I think this bug is the most severe in at least the optimizing compiler, and I will try to dedicate more time to getting my solution working. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-06-28 19:02 Message: Logged In: YES user_id=308843 Our Leave SSA algorithm suffers from both the "lost copy" problem and a problem where it renames variables that it shouldn't. This is a common floor when deconstructing SSA after aggressive optimisations like GVN - I'm fairly amazed loop unrolling saves us from these problems as well as it does. I've working fixes, but I want to commit something better. This problem will likely only get worse as the sophistication of optimisations increases. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-27 10:19 Message: Logged In: YES user_id=308843 The more I think about it, the more I think the problem is with the liveness analysis. In the liveness analysis we ignore the use operands of phi instructions. We then do a pass where we make all use operands of phis generated (gen) values for the predecessor blocks. This is what this means: bb10: t181 = phi t183 ... t183 = ... if ... goto 12 end10 ... bb12 ... if ... goto 10 end12 bb13 ... = phi t183 ... = phi t181 end13 when liveness analysis is processing bb13 it ignores t183 and t181 as they are phi uses. In bb12 we say that t181 and t183 are generated. We then cons all ins for every BB reachable from bb12 to find out the out registers. This doesn't include t181 and therefore we don't copy or split it to avoid its value being overwritten by making the edge bb12->bb10 critical. Some interesting findings: putting the current bb's gen set in the out set breaks everything, placing the phi uses in the in set doesn't move us beyond the same bug, explicitly catching the edge in question and breaking it fixes everything (as does renaming) however hard coding a method name and basic block numbers isn't a very desirable solution. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-27 09:16 Message: Logged In: YES user_id=308843 This looks wrong, from the liveness analysis debug: *** processing block BB13 # out edges: 2 Basic block BB13 in: BB12, BB8 normal out: BB19, BB14 exceptional out: <none> Next in code order: BB14 Instructions: 83: LABEL13 (Infrequent) -9: phi t189psa(Lcom/ibm/JikesRVM/opt/OPT_LiveSetElement;) = t174psa(Lcom/ibm/Jikes\ RVM/opt/OPT_LiveSetElement;), BB8, t183psa(Lcom/ibm/JikesRVM/opt/OPT_LiveSetElement;), BB12 -9: phi t190psa(Lcom/ibm/JikesRVM/opt/OPT_LiveSetElement;) = t3psa(Lcom/ibm/JikesRV\ M/opt/OPT_LiveSetElement;), BB8, t181psa(Lcom/ibm/JikesRVM/opt/OPT_LiveSetElement;), BB12 84: ref_ifcmp t191psv(GUARD) = t189psa(Lcom/ibm/JikesRVM/opt/OPT_LiveSetElement;,d,p), <n\ ull>, ==, LABEL19, Probability: 0.5 -1: bbend BB13 Before applying transfor function: currentSet: PR(Lcom/ibm/JikesRVM/VM_Processor;) l9psi(I) exceptionBlockSummary: empty --> Computing Gen/Kill for block BB13 Gen: empty Kill: t189psa(Lcom/ibm/JikesRVM/opt/OPT_LiveSetElement;) t190psa(Lcom/ibm/JikesRVM/opt/OPT_LiveSetElement;\ ) t191psv(GUARD) 1st PEI Kill: empty ---> Done computing Gen/Kill for block *** processBlock returning true, currentSet: PR(Lcom/ibm/JikesRVM/VM_Processor;) l9psi(I) This says that t181 and t183 aren't live at the entry to BB13, which clearly uses them both. We also say for BB12 that we generate them. Phis are handled differently in liveness analysis. The back-edge (bb12->bb10) is the one we're incorrectly inserting the move on. We could fix this either through renaming (not sure how) or by splitting the critical edge. All situations where you split on the critical edge are controlled by some control variables. The renaming looks for the situation where t181 would be live on the exit of bb12, and that's computed by looking at the ins of bb13 and bb10. bb13 clealy uses t181 but it doesn't appear in the in set. Confusing.. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-26 00:58 Message: Logged In: YES user_id=308843 In the code we have: label10: t181 = phi ..., t183/BB12 t183 = ref_load t181.next ... bbend10 label11: ... bbend11 label12: ... int_ifcmp .. < .. then goto 12 bbend12 label13: ... = t183 ... = t181 .... however, when removing the phi instruction leave ssa creates a move such that: label10: t181 = phi ..., t183/BB12 t183 = ref_load t181.next ... bbend10 label11: ... bbend11 label12: ... t181 = t183 int_ifcmp .. < .. then goto 12 bbend12 label13: ... = t183 ... = t181 .... ie it should have split the edge from 12 to 10 (that defines t183 = t181). I'm working on understanding why this special case isn't getting caugh, and then working on a proper fix. Ian ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-25 19:58 Message: Logged In: YES user_id=308843 Here's the debug output from leave SSA: scheduleCopies: BB0 (ENTRY) scheduleCopies: BB1 scheduleCopies: BB2 scheduleCopies: BB3 scheduleCopies: BB4 scheduleCopies: BB5 scheduleCopies: BB6 scheduleCopies: BB7 splitting edge: BB7->BB14 dest(r): t193pa sr: t174pa, nameForSR: t174pa not splitting edge: BB7->BB14 dest(r): t194pa sr: t3pa, nameForSR: t3pa scheduleCopies: BB8 splitting edge: BB8->BB13 dest(r): t189pa sr: t174pa, nameForSR: t174pa splitting edge: BB8->BB13 dest(r): t190pa sr: t3pa, nameForSR: t3pa scheduleCopies: BB9 not splitting edge: BB9->BB10 dest(r): t181pa sr: t174pa, nameForSR: t174pa scheduleCopies: BB10 scheduleCopies: BB11 splitting edge: BB11->BB14 dest(r): t193pa sr: t183pa, nameForSR: t183pa not splitting edge: BB11->BB14 dest(r): t194pa sr: t181pa, nameForSR: t181pa scheduleCopies: BB12 splitting edge: BB12->BB13 dest(r): t189pa sr: t183pa, nameForSR: t183pa splitting edge: BB12->BB13 dest(r): t190pa sr: t181pa, nameForSR: t181pa not splitting edge: BB12->BB10 dest(r): t181pa sr: t183pa, nameForSR: t183pa scheduleCopies: BB13 splitting edge: BB13->BB14 dest(r): t193pa sr: t189pa, nameForSR: t189pa not splitting edge: BB13->BB14 dest(r): t194pa sr: t190pa, nameForSR: t190pa scheduleCopies: BB14 scheduleCopies: BB15 scheduleCopies: BB16 scheduleCopies: BB17 scheduleCopies: BB18 scheduleCopies: BB19 performRename: BB0 (ENTRY) performRename: BB1 performRename: BB2 performRename: BB3 performRename: BB4 performRename: BB5 performRename: BB6 performRename: BB7 performRename: BB21 performRename: BB8 performRename: BB22 performRename: BB9 performRename: BB10 performRename: BB11 performRename: BB23 performRename: BB12 performRename: BB24 performRename: BB13 performRename: BB25 performRename: BB14 performRename: BB15 performRename: BB16 performRename: BB17 performRename: BB18 performRename: BB19 ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-25 08:59 Message: Logged In: YES user_id=308843 So we have: while (some condition) { prev = current; current = current.next; } if (some condition) { prev.next = current.next; } In SSA, prev isn't loop carried, so we just need a phi node for current. However, prev must be defined in the loop and we end up with two phi nodes following the loop, one that collects current (t189 in the trace), and the other that collects prev (t190). The phi node to collect prev is collecting the result of the phi node carry current at the top of the loop. Phi node of a phi, erk.. now entering LeaveSSA bug city! On leaving SSA in LIR form (at line 9827 in the trace) we can see that after following the moves, t189/current is equal to t183, unfortunately by following the same moves so it t190/prev. We therefore go on to eliminate t190 and use the register holding current instead and this means we end up with the code to remove an element instead performing "current.next = current.next". So I think it's pretty definite that the bug lies in Leave SSA and the logic which determines how we place moves for phi instructions so that they correctly respect ordering needs pulling in for questioning. Ian ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-25 02:09 Message: Logged In: YES user_id=308843 Other than some null checks GCSE isn't doing much on the problem method. However, disabling GCSE and loop unrolling does create a viable Jikes RVM (which of course just disabling loop unrolling on its own doesn't). Back to staring at the 430 page trace... ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-24 08:55 Message: Logged In: YES user_id=308843 And the real winner is... drum roll.. * Global Common Sub-expression Elimination! * given the trace (already attached) we should be able to work out why GCSE thinks it can get rid of the current to prev copy and fix GCSE. Yay! :-) Time for bed.. boing.. Ian ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-24 08:21 Message: Logged In: YES user_id=308843 >From tracing, it appears that the assignment of "prev.next = current.next" is in fact doing "current.next = current.next". Also, disable write barrier inlining doesn't fix the problem. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-24 07:30 Message: Logged In: YES user_id=308843 Attached is the faulty IR generated in the boot image. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-24 06:54 Message: Logged In: YES user_id=308843 Actually the prev.next = current.next code looks ok. The difference in the IR comes from expanding the write barrier, which is doing less when being executed at runtime. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-24 04:31 Message: Logged In: YES user_id=308843 >From tracing the code in the boot image, the code in OPT_LiveSet.remove(OPT_RegisterOperand item) is not having the code: prev.setNext(current.getNext()) executed when loop unrolling isn't performed. It looks as though the code has been illegally moved. However, the code in the boot image differs from the code produced by the optimization test harness, which doesn't suffer this problem. The explanation should become clear when I look at the print_all_ir output from creating a broken boot image. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-24 01:40 Message: Logged In: YES user_id=308843 Without unrolling the OPT_LiveSet.remove is capable of the following: Prior to removal of t165psa(Lorg/vmmagic/unboxed/Address;) : PR(Lcom/ibm/JikesRVM/VM_Processor;) l0psa(Lorg/vmmagic/unboxed/ObjectReference;) l6psa(Ljava/net/URL;,x,d) t165psa(Ljava/io/File;,p) After removal: PR(Lcom/ibm/JikesRVM/VM_Processor;) l0psa(Lorg/vmmagic/unboxed/ObjectReference;) l6psa(Ljava/net/URL;,x,d) t165psa(Ljava/io/File;,p) (ie its not removing something it should) but only in a subset of cases. For example, only the last case in these 2 examples is broken, although it looks as if the same list is being worked upon: Prior to removal of t349psa(Lorg/vmmagic/unboxed/Address;) : PR(Lcom/ibm/JikesRVM/VM_Processor;) t349psa(Lorg/vmmagic/unboxed/Address;) After removal: PR(Lcom/ibm/JikesRVM/VM_Processor;) Prior to removal of t311psa(Lorg/vmmagic/unboxed/Address;) : PR(Lcom/ibm/JikesRVM/VM_Processor;) l0psa(Lorg/vmmagic/unboxed/ObjectReference;) l6psa(Ljava/net/URL;,x,d) t311psa(Ljava/security/CodeSource;,p) After removal: PR(Lcom/ibm/JikesRVM/VM_Processor;) l0psa(Lorg/vmmagic/unboxed/ObjectReference;) l6psa(Ljava/net/URL;,x,d) t311psa(Ljava/security/CodeSource;,p) ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-24 00:33 Message: Logged In: YES user_id=308843 Having gone through the final assembler (of x86 although the bug effects both) of the non-unrolled com.ibm.JikesRVM.opt.OPT_LiveSet.remove(Lcom/ibm/JikesRVM/opt/ir/OPT_RegisterOperand;)V I can see nothing that is clearly different from the original source. Possibly this could mean that the bug lies elsewhere, such as in the yield point back-edge, or outside of the loop. But this code looks ok to me. Also there seems to be no liveness analysis occuring when the bug happens. So it seems the most likely thing is the bug breaks the liveness analysis which then causes incorrect code generation and the associated problems. As such I should be able to dump the live sets before and after removal and find the specific place that the corruption happens (by diffing the working and non-working results from a development build). Then I should be able to find a case that will break the MIR I have in front of me and expose the bug I can then trace back to the breaking IR stage. That's my theory anyway, I'm not sure if it will work (it's a remarkably trivial loop for things to have gone wrong on). ---------------------------------------------------------------------- Comment By: Dave Grove (dgrove-oss) Date: 2006-05-23 23:29 Message: Logged In: YES user_id=1215435 great. now it's time to either look at the code and see what's wrong, or further narrow by turning optimizations off/on to see if there's a single transform that breaks things. Am I remembering correctly this breaks on both IA32 & PPC? If so, life is easier since you can almost certainly rule out all the MIR stuff as a source of the bug and focus on HIR and LIR stages only. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-23 22:39 Message: Logged In: YES user_id=308843 And the winner is: com.ibm.JikesRVM.opt.OPT_LiveSet.remove(Lcom/ibm/JikesRVM/opt/ir/OPT_RegisterOperand;)V however, my early guess that LICM would be implicated seems not to be the case, as avoiding LICM for this loop doesn't fix the problem. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-23 09:55 Message: Logged In: YES user_id=308843 I binary chopped through all unrolled methods and have come up with OPT_LiveSet.remove (not sure which version). That is, if you disable loop unrolling on everything but OPT_LiveSet.remove then the RVM works. If you don't unroll OPT_LiveSet.remove then it causes the MMTk problems seen in this bug report. Ian ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-22 18:27 Message: Logged In: YES user_id=308843 Some interesting points: * the address 0x3fe7116b that appears in the 1st stack trace is equivalent to the floating point value 1.805219. * the builds that die have opt compiled the runtime system. Prototype builds appear to be less effected. This makes me believe the compiler is failing when building the runtime rather than the particular benchmark. It also makes testing more difficult :-( ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-22 09:45 Message: Logged In: YES user_id=308843 Just a note to myself that the lack of loop unrolling doesn't just effect MMTk. OPT_Compiler failure during compilation of spec.benchmarks._201_compress.Compressor.compress ()V java.lang.NullPointerException at java.lang.Throwable.fillInStackTrace(Throwable.java:109) at java.lang.Throwable.<init>(Throwable.java:53) at java.lang.Exception.<init>(Exception.java:67) at java.lang.RuntimeException.<init>(RuntimeException.java:65) at java.lang.NullPointerException.<init>(NullPointerException.java:70) at com.ibm.JikesRVM.VM_Runtime.deliverHardwareException(VM_Runtime.java:631) at <hardware trap> at com.ibm.JikesRVM.opt.OPT368657 _LICM.checkLoop(OPT_LICM.java:1005) at com.ibm.JikesRVM.opt.OPT_LICM.simplify(OPT_LICM.java:929) at com.ibm.JikesRVM.opt.OPT_LICM.initialize(OPT_LICM.java:860) at com.ibm.JikesRVM.opt.OPT_LICM.perform(OPT_LICM.java:55) at com.ibm.JikesRVM.opt.OPT_CompilerPhase.performPhase(OPT_CompilerPhase.java:129) at com.ibm.JikesRVM.opt.OPT_OptimizationPlanAtomicElement.perform(OPT_OptimizationPlanAtomicElement.java:80) at com.ibm.JikesRVM.opt.OPT_OptimizationPlanCompositeElement.perform(OPT_OptimizationPlanCompositeElement.java:141) at com.ibm.JikesRVM.opt.OPT_OptimizationPlanCompositeElement.perform(OPT_OptimizationPlanCompositeElement.java:141) at com.ibm.JikesRVM.opt.OPT_OptimizationPlanCompositeElement.perform(OPT_OptimizationPlanCompositeElement.java:141) at com.ibm.JikesRVM.opt.OPT_CompilationPlan.execute(OPT_CompilationPlan.java:105) at com.ibm.JikesRVM.opt.OPT_Compiler.compile(OPT_Compiler.java:222) at com.ibm.JikesRVM.VM_RuntimeCompiler.optCompile(VM_RuntimeCompiler.java:377) at com.ibm.JikesRVM.VM_RuntimeCompiler.recompileWithOpt(VM_RuntimeCompiler.java:519) at com.ibm.JikesRVM.adaptive.VM_ControllerPlan.doRecompile(VM_ControllerPlan.java:179) at com.ibm.JikesRVM.adaptive.VM_CompilationThread.run(VM_CompilationThread.java:54) and another example of the MMTk problem: validRef: REF outside heap, ref = 0xffffffff boot 0x31000000->0x40ffffff immortal 0x41000000->0x42ffffff meta 0x43000000->0x44ffffff los 0x45000000->0x4c7fffff nursery 0x75000000->0x7fffffff ms 0x4c800000->0x713fffff sanity 0x71400000->0x733fffff Invalid ref reported while scanning stack --- METHOD (OPT) Lspec/benchmarks/_205_raytrace/IntersectPt;.FindNearestIsect (Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;IILspec/benchmarks/_205_raytrace/OctNode;)Z --- fp = 0x456d1e90 code base = 0x4d37860c code offset = 0x00000288 REF=0xffffffff (REF OUTSIDE OF HEAP OR NOT MAPPED) -- Stack -- Lspec/benchmarks/_205_raytrace/IntersectPt; FindNearestIsect(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;IILspec/benchmarks/_205_raytrace/OctNode;)Z at line 135 Lspec/benchmarks/_205_raytrace/Scene; Shade(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;Lspec/benchmarks/_205_raytrace/Color;FII)V at line 445 Lspec/benchmarks/_205_raytrace/Scene; RenderScene(Lspec/benchmarks/_205_raytrace/Canvas;III)V at line 650 Lspec/benchmarks/_205_raytrace/Runner; run()V at line 133 Lcom/ibm/JikesRVM/VM_Thread; run()V at line 200 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 -- Stack -- Lcom/ibm/JikesRVM/VM_Processor; dispatch(Z)V at line 217 Lcom/ibm/JikesRVM/VM_Thread; morph(Z)V at line 722 Lcom/ibm/JikesRVM/VM_Thread; timerTickYield(I)V at line 544 Lcom/ibm/JikesRVM/VM_Thread; yieldpoint(I)V at line 520 Lcom/ibm/JikesRVM/opt/VM_OptSaveVolatile; OPT_yieldpointFromEpilogue()V at line 47 Lspec/benchmarks/_205_raytrace/OctNode; Intersect(Lspec/benchmarks/_205_raytrace/Ray;Lspec/benchmarks/_205_raytrace/Point;F)Lspec/benchmarks/_205_raytrace/OctNode; at line 434 Lspec/benchmarks/_205_raytrace/IntersectPt; FindNearestIsect(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;IILspec/benchmarks/_205_raytrace/OctNode;)Z at line 135 Lspec/benchmarks/_205_raytrace/Scene; Shade(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;Lspec/benchmarks/_205_raytrace/Color;FII)V at line 445 Lspec/benchmarks/_205_raytrace/Scene; RenderScene(Lspec/benchmarks/_205_raytrace/Canvas;III)V at line 650 Lspec/benchmarks/_205_raytrace/Runner; run()V at line 133 Lcom/ibm/JikesRVM/VM_Thread; run()V at line 200 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 VM_ScanStack: Detected bad GC map; exiting RVM with fatal error -- Stack -- Lorg/mmtk/vm/ScanThread; checkReference(Lorg/vmmagic/unboxed/Address;I)V at line 616 Lorg/mmtk/vm/ScanThread; scanFrameForObjects(I)V at line 400 Lorg/mmtk/vm/ScanThread; scanFrame(I)Lorg/vmmagic/unboxed/Address; at line 320 Lorg/mmtk/vm/ScanThread; scanThreadInternal(Lorg/vmmagic/unboxed/Address;I)V at line 240 Lorg/mmtk/vm/ScanThread; startScan(Lorg/mmtk/plan/TraceLocal;ZLcom/ibm/JikesRVM/VM_Thread;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V at line 200 Lorg/mmtk/vm/ScanThread; scanThread(Lcom/ibm/JikesRVM/VM_Thread;Lorg/mmtk/plan/TraceLocal;ZLorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V at line 166 Lorg/mmtk/vm/ScanThread; scanThread(Lcom/ibm/JikesRVM/VM_Thread;Lorg/mmtk/plan/TraceLocal;Z)V at line 131 Lorg/mmtk/vm/Scanning; computeAllRoots(Lorg/mmtk/plan/TraceLocal;)V at line 236 Lorg/mmtk/plan/StopTheWorldLocal; collectionPhase(IZZ)V at line 102 Lorg/mmtk/plan/generational/GenLocal; collectionPhase(IZZ)V at line 203 Lorg/mmtk/plan/generational/marksweep/GenMSLocal; collectionPhase(IZZ)V at line 230 Lorg/mmtk/plan/SimplePhase; delegatePhase()V at line 170 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/Phase; delegatePhase(I)V at line 148 Lorg/mmtk/plan/ComplexPhase; delegatePhase()V at line 95 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/Phase; delegatePhase(I)V at line 148 Lorg/mmtk/plan/ComplexPhase; delegatePhase()V at line 95 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/StopTheWorldLocal; collect()V at line 57 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/VM_CollectorThread; run()V at line 342 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 (the previous one did have versioning enabled, whereas this doesn't) ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-22 02:50 Message: Logged In: YES user_id=308843 A similar problem occurs with loop unrolling disabled on a PowerPC development build: validRef: REF outside heap, ref = 0x00001ba0 boot 0x31000000->0x40ffffff immortal 0x41000000->0x42ffffff meta 0x43000000->0x44ffffff los 0x45000000->0x4c7fffff nursery 0x75000000->0x7fffffff ms 0x4c800000->0x713fffff sanity 0x71400000->0x733fffff Invalid ref reported while scanning stack --- METHOD (OPT) Lspec/benchmarks/_201_compress/Compressor;.compress ()V --- fp = 0x4534eca8 code base = 0x4cb8a90c code offset = 0x00000100 REF=0x00001ba0 (REF OUTSIDE OF HEAP OR NOT MAPPED) -- Stack -- Lspec/benchmarks/_201_compress/Compressor; compress()V Lspec/benchmarks/_201_compress/Compress; spec_select_action([BII[B)I Lspec/benchmarks/_201_compress/Harness; run_compress([Ljava/lang/String;)Z Lspec/benchmarks/_201_compress/Harness; inst_main([Ljava/lang/String;)J Lspec/benchmarks/_201_compress/Main; runBenchmark([Ljava/lang/String;)J Lspec/benchmarks/_201_compress/Main; harnessMain([Ljava/lang/String;)J Lspec/harness/ProgramRunner; runOnce(Ljava/lang/Object;IJILjava/util/Properties;)Lspec/harness/BenchmarkTime; at line 382 Lspec/harness/ProgramRunner; runBenchmark2()Ljava/util/Properties; at line 306 Lspec/harness/ProgramRunner; runBenchmark()V at line 238 Lspec/harness/ProgramRunner; run()V at line 206 Lspec/harness/RunProgram; run(Ljava/lang/String;ZLjava/util/Properties;Lspec/harness/BenchmarkDone;)V at line 60 LSpecApplication; runBenchmark(Ljava/lang/String;Z)V at line 255 LSpecApplication; main([Ljava/lang/String;)V at line 171 Lcom/ibm/JikesRVM/MainThread; run()V at line 115 Lcom/ibm/JikesRVM/VM_Thread; run()V at line 200 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 -- Stack -- Lcom/ibm/JikesRVM/VM_Processor; dispatch(Z)V at line 217 Lcom/ibm/JikesRVM/VM_Thread; morph(Z)V at line 722 Lcom/ibm/JikesRVM/VM_Thread; timerTickYield(I)V at line 544 Lcom/ibm/JikesRVM/VM_Thread; yieldpoint(I)V at line 520 Lcom/ibm/JikesRVM/opt/VM_OptSaveVolatile; OPT_yieldpointFromBackedge()V at line 57 Lspec/benchmarks/_201_compress/Compressor; compress()V Lspec/benchmarks/_201_compress/Compress; spec_select_action([BII[B)I Lspec/benchmarks/_201_compress/Harness; run_compress([Ljava/lang/String;)Z Lspec/benchmarks/_201_compress/Harness; inst_main([Ljava/lang/String;)J Lspec/benchmarks/_201_compress/Main; runBenchmark([Ljava/lang/String;)J Lspec/benchmarks/_201_compress/Main; harnessMain([Ljava/lang/String;)J Lspec/harness/ProgramRunner; runOnce(Ljava/lang/Object;IJILjava/util/Properties;)Lspec/harness/BenchmarkTime; at line 382 Lspec/harness/ProgramRunner; runBenchmark2()Ljava/util/Properties; at line 306 Lspec/harness/ProgramRunner; runBenchmark()V at line 238 Lspec/harness/ProgramRunner; run()V at line 206 Lspec/harness/RunProgram; run(Ljava/lang/String;ZLjava/util/Properties;Lspec/harness/BenchmarkDone;)V at line 60 LSpecApplication; runBenchmark(Ljava/lang/String;Z)V at line 255 LSpecApplication; main([Ljava/lang/String;)V at line 171 Lcom/ibm/JikesRVM/MainThread; run()V at line 115 Lcom/ibm/JikesRVM/VM_Thread; run()V at line 200 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 VM_ScanStack: Detected bad GC map; exiting RVM with fatal error -- Stack -- Lorg/mmtk/vm/ScanThread; checkReference(Lorg/vmmagic/unboxed/Address;I)V at line 616 Lorg/mmtk/vm/ScanThread; scanFrameForObjects(I)V at line 400 Lorg/mmtk/vm/ScanThread; scanFrame(I)Lorg/vmmagic/unboxed/Address; at line 320 Lorg/mmtk/vm/ScanThread; scanThreadInternal(Lorg/vmmagic/unboxed/Address;I)V at line 240 Lorg/mmtk/vm/ScanThread; startScan(Lorg/mmtk/plan/TraceLocal;ZLcom/ibm/JikesRVM/VM_Thread;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V at line 200 Lorg/mmtk/vm/ScanThread; scanThread(Lcom/ibm/JikesRVM/VM_Thread;Lorg/mmtk/plan/TraceLocal;ZLorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V at line 166 Lorg/mmtk/vm/ScanThread; scanThread(Lcom/ibm/JikesRVM/VM_Thread;Lorg/mmtk/plan/TraceLocal;Z)V at line 131 Lorg/mmtk/vm/Scanning; computeAllRoots(Lorg/mmtk/plan/TraceLocal;)V at line 236 Lorg/mmtk/plan/StopTheWorldLocal; collectionPhase(IZZ)V at line 102 Lorg/mmtk/plan/generational/GenLocal; collectionPhase(IZZ)V at line 203 Lorg/mmtk/plan/generational/marksweep/GenMSLocal; collectionPhase(IZZ)V at line 230 Lorg/mmtk/plan/SimplePhase; delegatePhase()V at line 170 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/Phase; delegatePhase(I)V at line 148 Lorg/mmtk/plan/ComplexPhase; delegatePhase()V at line 95 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/Phase; delegatePhase(I)V at line 148 Lorg/mmtk/plan/ComplexPhase; delegatePhase()V at line 95 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/StopTheWorldLocal; collect()V at line 57 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/VM_CollectorThread; run()V at line 342 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 ---------------------------------------------------------------------- Comment By: Dave Grove (dgrove-oss) Date: 2006-05-18 00:20 Message: Logged In: YES user_id=1215435 I think there are two possible sources of the bug: (1) turning off loop unrolling results in bad code being generated for some piece of the opt compiler that generates/interprets the opt GC maps and/or some piece of MMTk that uses the information. (2) turning off loop unrolling results in a bad GC map being generated for the particular method in mtrt (+ the methods in other benchmarks you mentioned). My instinct is that (1) is a more likely hypothesis. To pursue it, life would be easier if the crash is fairly deterministic. If it is, then you can proceed by enabling/disabling loop unrolling on classes in the bootimage to do a binary search to find the method which is being generated incorrectly. My guess is that it is some method in VM_OptMachineCodeMap or VM_OptGCMap, but it could be almost anywhere where in the opt compiler or MMTk. An initial first check would be to build the bootimage with loop unrolling enabled (normal), but disable it at runtime. If this configuration never exhibits the crash, then the search through the bootimage compiled code seems like the thing to do. If (2) is the problem (it really is a bad GC map that isn't due to bad code gen in the bootimage), then to debug GC maps you set VM_OptMachineCodeMap.DUMP_MAPS to true and dump large ammounts of debug information to get the GC map & associated debug info for the program point (0x00001c14 of that method) and see if it makes sense. This is likely to be quite painful because the method is so big, so hopefully it won't come to this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1488798&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 01:33:47
|
Bugs item #1488798, was opened at 2006-05-15 12:41 Message generated for change (Comment added) made by captain5050 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1488798&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: optimizing compiler Group: new Status: Open Resolution: None Priority: 7 Private: No Submitted By: Ian Rogers (captain5050) Assigned to: Ian Rogers (captain5050) Summary: Leave SSA broken - lack of loop unrolling breaks MMTk Initial Comment: Since fixing bug 1363830 we can successfully build the Jikes RVM with loop unrolling disabled. However, when running such a build on several benchmarks, it produces the following error: $RVM_ROOT/rvm/bin/rvm SpecApplication -m20 -M20 -a _227_mtrt Will run each benchmark at least 20 times Will run each benchmark at most 20 times Caching Off Speed = 100 Auto run mode ======= _227_mtrt Starting ======= Run 0 start. Total memory=52428800 free memory=42463232 +0 to 99 by 200 +100 to 199 by 200 validRef: REF outside heap, ref = 0x3fe7116b boot 0x47000000->0x56ffffff immortal 0x57000000->0x58ffffff meta 0x59000000->0x5affffff los 0x5b000000->0x64ffffff nursery 0xa1000000->0xafffffff ms 0x65000000->0x96bfffff sanity 0x96c00000->0x98bfffff Invalid ref reported while scanning stack --- METHOD (OPT) Lspec/benchmarks/_205_raytrace/OctNode;.Intersect (Lspec/benchmarks/_205_raytrace/Ray;Lspec/benchmarks/_205_raytrace/Point;F)Lspec/benchmarks/_205_raytrace/OctNode; --- fp = 0x5b6aed9c code base = 0x5b789018 code offset = 0x00001c14 REF=0x3fe7116b (REF OUTSIDE OF HEAP OR NOT MAPPED) -- Stack -- Lorg/mmtk/utility/alloc/BumpPointer; alloc(III)Lorg/vmmagic/unboxed/Address; at line 140 Lorg/mmtk/plan/generational/GenLocal; alloc(IIII)Lorg/vmmagic/unboxed/Address; at line 98 Lorg/mmtk/plan/generational/marksweep/GenMSLocal; alloc(IIII)Lorg/vmmagic/unboxed/Address; at line 97 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/MM_Interface; allocateSpace(Lcom/ibm/JikesRVM/memoryManagers/mmInterface/SelectedPlanLocal;IIIZILorg/vmmagic/unboxed/ObjectReference;)Lorg/vmmagic/unboxed/Address; at line 672 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/MM_Interface; allocateSpace(Lcom/ibm/JikesRVM/memoryManagers/mmInterface/SelectedPlanLocal;IIII)Lorg/vmmagic/unboxed/Address; at line 622 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/MM_Interface; allocateArray(III[Ljava/lang/Object;III)Ljava/lang/Object; at line 601 Lcom/ibm/JikesRVM/VM_Runtime; resolvedNewArray(III[Ljava/lang/Object;III)Ljava/lang/Object; at line 426 Lspec/benchmarks/_205_raytrace/OctNode; Intersect(Lspec/benchmarks/_205_raytrace/Ray;Lspec/benchmarks/_205_raytrace/Point;F)Lspec/benchmarks/_205_raytrace/OctNode; at line 437 Lspec/benchmarks/_205_raytrace/Scene; FindLightBlock(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;F)Z at line 575 Lspec/benchmarks/_205_raytrace/Scene; GetLightColor(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Point;Lspec/benchmarks/_205_raytrace/Vector;Lspec/benchmarks/_205_raytrace/ObjectType;Lspec/benchmarks/_205_raytrace/Color;)V at line 535 Lspec/benchmarks/_205_raytrace/Scene; Shade(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;Lspec/benchmarks/_205_raytrace/Color;FII)V at line 449 Lspec/benchmarks/_205_raytrace/Scene; RenderScene(Lspec/benchmarks/_205_raytrace/Canvas;III)V at line 650 Lspec/benchmarks/_205_raytrace/Runner; run()V at line 133 Lcom/ibm/JikesRVM/VM_Thread; run()V at line 200 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 -- Stack -- Lcom/ibm/JikesRVM/VM_Processor; dispatch(Z)V at line 217 Lcom/ibm/JikesRVM/VM_Thread; morph(Z)V at line 722 Lcom/ibm/JikesRVM/VM_Thread; yield()V at line 618 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/VM_Handshake; requestAndAwaitCompletion(I)V at line 82 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/VM_CollectorThread; collect(Lcom/ibm/JikesRVM/memoryManagers/mmInterface/VM_Handshake;I)V at line 244 Lorg/mmtk/vm/Collection; triggerCollection(I)V at line 133 Lorg/mmtk/plan/generational/Gen; poll(ZLorg/mmtk/policy/Space;)Z at line 193 Lorg/mmtk/policy/Space; acquire(I)Lorg/vmmagic/unboxed/Address; at line 451 Lorg/mmtk/utility/alloc/BumpPointer; allocSlowOnce(IIIZ)Lorg/vmmagic/unboxed/Address; at line 164 Lorg/mmtk/utility/alloc/Allocator; allocSlowBody(IIIZ)Lorg/vmmagic/unboxed/Address; at line 218 Lorg/mmtk/utility/alloc/Allocator; allocSlow(III)Lorg/vmmagic/unboxed/Address; at line 202 Lorg/mmtk/utility/alloc/BumpPointer; alloc(III)Lorg/vmmagic/unboxed/Address; at line 140 Lorg/mmtk/plan/generational/GenLocal; alloc(IIII)Lorg/vmmagic/unboxed/Address; at line 98 Lorg/mmtk/plan/generational/marksweep/GenMSLocal; alloc(IIII)Lorg/vmmagic/unboxed/Address; at line 97 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/MM_Interface; allocateSpace(Lcom/ibm/JikesRVM/memoryManagers/mmInterface/SelectedPlanLocal;IIIZILorg/vmmagic/unboxed/ObjectReference;)Lorg/vmmagic/unboxed/Address; at line 672 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/MM_Interface; allocateSpace(Lcom/ibm/JikesRVM/memoryManagers/mmInterface/SelectedPlanLocal;IIII)Lorg/vmmagic/unboxed/Address; at line 622 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/MM_Interface; allocateArray(III[Ljava/lang/Object;III)Ljava/lang/Object; at line 601 Lcom/ibm/JikesRVM/VM_Runtime; resolvedNewArray(III[Ljava/lang/Object;III)Ljava/lang/Object; at line 426 Lspec/benchmarks/_205_raytrace/OctNode; Intersect(Lspec/benchmarks/_205_raytrace/Ray;Lspec/benchmarks/_205_raytrace/Point;F)Lspec/benchmarks/_205_raytrace/OctNode; at line 437 Lspec/benchmarks/_205_raytrace/Scene; FindLightBlock(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;F)Z at line 575 Lspec/benchmarks/_205_raytrace/Scene; GetLightColor(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Point;Lspec/benchmarks/_205_raytrace/Vector;Lspec/benchmarks/_205_raytrace/ObjectType;Lspec/benchmarks/_205_raytrace/Color;)V at line 535 Lspec/benchmarks/_205_raytrace/Scene; Shade(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;Lspec/benchmarks/_205_raytrace/Color;FII)V at line 449 Lspec/benchmarks/_205_raytrace/Scene; RenderScene(Lspec/benchmarks/_205_raytrace/Canvas;III)V at line 650 Lspec/benchmarks/_205_raytrace/Runner; run()V at line 133 Lcom/ibm/JikesRVM/VM_Thread; run()V at line 200 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 VM_ScanStack: Detected bad GC map; exiting RVM with fatal error -- Stack -- Lorg/mmtk/vm/ScanThread; checkReference(Lorg/vmmagic/unboxed/Address;I)V at line 616 Lorg/mmtk/vm/ScanThread; scanFrameForObjects(I)V at line 400 Lorg/mmtk/vm/ScanThread; scanFrame(I)Lorg/vmmagic/unboxed/Address; at line 320 Lorg/mmtk/vm/ScanThread; scanThreadInternal(Lorg/vmmagic/unboxed/Address;I)V at line 240 Lorg/mmtk/vm/ScanThread; startScan(Lorg/mmtk/plan/TraceLocal;ZLcom/ibm/JikesRVM/VM_Thread;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V at line 200 Lorg/mmtk/vm/ScanThread; scanThread(Lcom/ibm/JikesRVM/VM_Thread;Lorg/mmtk/plan/TraceLocal;ZLorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V at line 166 Lorg/mmtk/vm/ScanThread; scanThread(Lcom/ibm/JikesRVM/VM_Thread;Lorg/mmtk/plan/TraceLocal;Z)V at line 131 Lorg/mmtk/vm/Scanning; computeAllRoots(Lorg/mmtk/plan/TraceLocal;)V at line 236 Lorg/mmtk/plan/StopTheWorldLocal; collectionPhase(IZZ)V at line 102 Lorg/mmtk/plan/generational/GenLocal; collectionPhase(IZZ)V at line 203 Lorg/mmtk/plan/generational/marksweep/GenMSLocal; collectionPhase(IZZ)V at line 230 Lorg/mmtk/plan/SimplePhase; delegatePhase()V at line 170 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/Phase; delegatePhase(I)V at line 148 Lorg/mmtk/plan/ComplexPhase; delegatePhase()V at line 95 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/Phase; delegatePhase(I)V at line 148 Lorg/mmtk/plan/ComplexPhase; delegatePhase()V at line 95 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/StopTheWorldLocal; collect()V at line 57 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/VM_CollectorThread; run()V at line 342 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 As with bug 1363830, this bug is gating the by default enabling of loop versioning, which means we aren't taking advantage of that optimisation. ---------------------------------------------------------------------- >Comment By: Ian Rogers (captain5050) Date: 2007-05-23 02:33 Message: Logged In: YES user_id=308843 Originator: YES So I've had a go at reproducing this bug with Julian Dolby. Unfortunately the bug has moved from where it was (what looked like a lost copy problem). We could really do with a simple test case. The best way to achieve this is through a binary chop of opt compiled methods. The OptTestHarness is set up to do this. In particular -X:opt:verbose=true will generate OptTestHarness arguments that can be piped into a file and then loaded into the test harness with the -longcommandline argument. Once we've got the IR to pour over both Julian and I are keen to get this bug squashed. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-11-19 22:23 Message: Logged In: YES user_id=308843 Originator: YES This bug also causes the IA32 OPT_AssemblerBase to have a NoInlinePragma on isImmOrLabel. Jikes compilation didn't expose this bug, but ECJ compilation does. Ian ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-08-25 23:17 Message: Logged In: YES user_id=308843 Bug #1543866 where we don't turn static final floats and doubles into constants is related to SSA optimisations, but the phases have nothing to do with float or double constant operands. It seems likely that this bug also exposed bugs when we have simpler IR with more constants. I think this bug is the most severe in at least the optimizing compiler, and I will try to dedicate more time to getting my solution working. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-06-28 10:02 Message: Logged In: YES user_id=308843 Our Leave SSA algorithm suffers from both the "lost copy" problem and a problem where it renames variables that it shouldn't. This is a common floor when deconstructing SSA after aggressive optimisations like GVN - I'm fairly amazed loop unrolling saves us from these problems as well as it does. I've working fixes, but I want to commit something better. This problem will likely only get worse as the sophistication of optimisations increases. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-27 01:19 Message: Logged In: YES user_id=308843 The more I think about it, the more I think the problem is with the liveness analysis. In the liveness analysis we ignore the use operands of phi instructions. We then do a pass where we make all use operands of phis generated (gen) values for the predecessor blocks. This is what this means: bb10: t181 = phi t183 ... t183 = ... if ... goto 12 end10 ... bb12 ... if ... goto 10 end12 bb13 ... = phi t183 ... = phi t181 end13 when liveness analysis is processing bb13 it ignores t183 and t181 as they are phi uses. In bb12 we say that t181 and t183 are generated. We then cons all ins for every BB reachable from bb12 to find out the out registers. This doesn't include t181 and therefore we don't copy or split it to avoid its value being overwritten by making the edge bb12->bb10 critical. Some interesting findings: putting the current bb's gen set in the out set breaks everything, placing the phi uses in the in set doesn't move us beyond the same bug, explicitly catching the edge in question and breaking it fixes everything (as does renaming) however hard coding a method name and basic block numbers isn't a very desirable solution. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-27 00:16 Message: Logged In: YES user_id=308843 This looks wrong, from the liveness analysis debug: *** processing block BB13 # out edges: 2 Basic block BB13 in: BB12, BB8 normal out: BB19, BB14 exceptional out: <none> Next in code order: BB14 Instructions: 83: LABEL13 (Infrequent) -9: phi t189psa(Lcom/ibm/JikesRVM/opt/OPT_LiveSetElement;) = t174psa(Lcom/ibm/Jikes\ RVM/opt/OPT_LiveSetElement;), BB8, t183psa(Lcom/ibm/JikesRVM/opt/OPT_LiveSetElement;), BB12 -9: phi t190psa(Lcom/ibm/JikesRVM/opt/OPT_LiveSetElement;) = t3psa(Lcom/ibm/JikesRV\ M/opt/OPT_LiveSetElement;), BB8, t181psa(Lcom/ibm/JikesRVM/opt/OPT_LiveSetElement;), BB12 84: ref_ifcmp t191psv(GUARD) = t189psa(Lcom/ibm/JikesRVM/opt/OPT_LiveSetElement;,d,p), <n\ ull>, ==, LABEL19, Probability: 0.5 -1: bbend BB13 Before applying transfor function: currentSet: PR(Lcom/ibm/JikesRVM/VM_Processor;) l9psi(I) exceptionBlockSummary: empty --> Computing Gen/Kill for block BB13 Gen: empty Kill: t189psa(Lcom/ibm/JikesRVM/opt/OPT_LiveSetElement;) t190psa(Lcom/ibm/JikesRVM/opt/OPT_LiveSetElement;\ ) t191psv(GUARD) 1st PEI Kill: empty ---> Done computing Gen/Kill for block *** processBlock returning true, currentSet: PR(Lcom/ibm/JikesRVM/VM_Processor;) l9psi(I) This says that t181 and t183 aren't live at the entry to BB13, which clearly uses them both. We also say for BB12 that we generate them. Phis are handled differently in liveness analysis. The back-edge (bb12->bb10) is the one we're incorrectly inserting the move on. We could fix this either through renaming (not sure how) or by splitting the critical edge. All situations where you split on the critical edge are controlled by some control variables. The renaming looks for the situation where t181 would be live on the exit of bb12, and that's computed by looking at the ins of bb13 and bb10. bb13 clealy uses t181 but it doesn't appear in the in set. Confusing.. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-25 15:58 Message: Logged In: YES user_id=308843 In the code we have: label10: t181 = phi ..., t183/BB12 t183 = ref_load t181.next ... bbend10 label11: ... bbend11 label12: ... int_ifcmp .. < .. then goto 12 bbend12 label13: ... = t183 ... = t181 .... however, when removing the phi instruction leave ssa creates a move such that: label10: t181 = phi ..., t183/BB12 t183 = ref_load t181.next ... bbend10 label11: ... bbend11 label12: ... t181 = t183 int_ifcmp .. < .. then goto 12 bbend12 label13: ... = t183 ... = t181 .... ie it should have split the edge from 12 to 10 (that defines t183 = t181). I'm working on understanding why this special case isn't getting caugh, and then working on a proper fix. Ian ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-25 10:58 Message: Logged In: YES user_id=308843 Here's the debug output from leave SSA: scheduleCopies: BB0 (ENTRY) scheduleCopies: BB1 scheduleCopies: BB2 scheduleCopies: BB3 scheduleCopies: BB4 scheduleCopies: BB5 scheduleCopies: BB6 scheduleCopies: BB7 splitting edge: BB7->BB14 dest(r): t193pa sr: t174pa, nameForSR: t174pa not splitting edge: BB7->BB14 dest(r): t194pa sr: t3pa, nameForSR: t3pa scheduleCopies: BB8 splitting edge: BB8->BB13 dest(r): t189pa sr: t174pa, nameForSR: t174pa splitting edge: BB8->BB13 dest(r): t190pa sr: t3pa, nameForSR: t3pa scheduleCopies: BB9 not splitting edge: BB9->BB10 dest(r): t181pa sr: t174pa, nameForSR: t174pa scheduleCopies: BB10 scheduleCopies: BB11 splitting edge: BB11->BB14 dest(r): t193pa sr: t183pa, nameForSR: t183pa not splitting edge: BB11->BB14 dest(r): t194pa sr: t181pa, nameForSR: t181pa scheduleCopies: BB12 splitting edge: BB12->BB13 dest(r): t189pa sr: t183pa, nameForSR: t183pa splitting edge: BB12->BB13 dest(r): t190pa sr: t181pa, nameForSR: t181pa not splitting edge: BB12->BB10 dest(r): t181pa sr: t183pa, nameForSR: t183pa scheduleCopies: BB13 splitting edge: BB13->BB14 dest(r): t193pa sr: t189pa, nameForSR: t189pa not splitting edge: BB13->BB14 dest(r): t194pa sr: t190pa, nameForSR: t190pa scheduleCopies: BB14 scheduleCopies: BB15 scheduleCopies: BB16 scheduleCopies: BB17 scheduleCopies: BB18 scheduleCopies: BB19 performRename: BB0 (ENTRY) performRename: BB1 performRename: BB2 performRename: BB3 performRename: BB4 performRename: BB5 performRename: BB6 performRename: BB7 performRename: BB21 performRename: BB8 performRename: BB22 performRename: BB9 performRename: BB10 performRename: BB11 performRename: BB23 performRename: BB12 performRename: BB24 performRename: BB13 performRename: BB25 performRename: BB14 performRename: BB15 performRename: BB16 performRename: BB17 performRename: BB18 performRename: BB19 ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-24 23:59 Message: Logged In: YES user_id=308843 So we have: while (some condition) { prev = current; current = current.next; } if (some condition) { prev.next = current.next; } In SSA, prev isn't loop carried, so we just need a phi node for current. However, prev must be defined in the loop and we end up with two phi nodes following the loop, one that collects current (t189 in the trace), and the other that collects prev (t190). The phi node to collect prev is collecting the result of the phi node carry current at the top of the loop. Phi node of a phi, erk.. now entering LeaveSSA bug city! On leaving SSA in LIR form (at line 9827 in the trace) we can see that after following the moves, t189/current is equal to t183, unfortunately by following the same moves so it t190/prev. We therefore go on to eliminate t190 and use the register holding current instead and this means we end up with the code to remove an element instead performing "current.next = current.next". So I think it's pretty definite that the bug lies in Leave SSA and the logic which determines how we place moves for phi instructions so that they correctly respect ordering needs pulling in for questioning. Ian ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-24 17:09 Message: Logged In: YES user_id=308843 Other than some null checks GCSE isn't doing much on the problem method. However, disabling GCSE and loop unrolling does create a viable Jikes RVM (which of course just disabling loop unrolling on its own doesn't). Back to staring at the 430 page trace... ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-23 23:55 Message: Logged In: YES user_id=308843 And the real winner is... drum roll.. * Global Common Sub-expression Elimination! * given the trace (already attached) we should be able to work out why GCSE thinks it can get rid of the current to prev copy and fix GCSE. Yay! :-) Time for bed.. boing.. Ian ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-23 23:21 Message: Logged In: YES user_id=308843 >From tracing, it appears that the assignment of "prev.next = current.next" is in fact doing "current.next = current.next". Also, disable write barrier inlining doesn't fix the problem. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-23 22:30 Message: Logged In: YES user_id=308843 Attached is the faulty IR generated in the boot image. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-23 21:54 Message: Logged In: YES user_id=308843 Actually the prev.next = current.next code looks ok. The difference in the IR comes from expanding the write barrier, which is doing less when being executed at runtime. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-23 19:31 Message: Logged In: YES user_id=308843 >From tracing the code in the boot image, the code in OPT_LiveSet.remove(OPT_RegisterOperand item) is not having the code: prev.setNext(current.getNext()) executed when loop unrolling isn't performed. It looks as though the code has been illegally moved. However, the code in the boot image differs from the code produced by the optimization test harness, which doesn't suffer this problem. The explanation should become clear when I look at the print_all_ir output from creating a broken boot image. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-23 16:40 Message: Logged In: YES user_id=308843 Without unrolling the OPT_LiveSet.remove is capable of the following: Prior to removal of t165psa(Lorg/vmmagic/unboxed/Address;) : PR(Lcom/ibm/JikesRVM/VM_Processor;) l0psa(Lorg/vmmagic/unboxed/ObjectReference;) l6psa(Ljava/net/URL;,x,d) t165psa(Ljava/io/File;,p) After removal: PR(Lcom/ibm/JikesRVM/VM_Processor;) l0psa(Lorg/vmmagic/unboxed/ObjectReference;) l6psa(Ljava/net/URL;,x,d) t165psa(Ljava/io/File;,p) (ie its not removing something it should) but only in a subset of cases. For example, only the last case in these 2 examples is broken, although it looks as if the same list is being worked upon: Prior to removal of t349psa(Lorg/vmmagic/unboxed/Address;) : PR(Lcom/ibm/JikesRVM/VM_Processor;) t349psa(Lorg/vmmagic/unboxed/Address;) After removal: PR(Lcom/ibm/JikesRVM/VM_Processor;) Prior to removal of t311psa(Lorg/vmmagic/unboxed/Address;) : PR(Lcom/ibm/JikesRVM/VM_Processor;) l0psa(Lorg/vmmagic/unboxed/ObjectReference;) l6psa(Ljava/net/URL;,x,d) t311psa(Ljava/security/CodeSource;,p) After removal: PR(Lcom/ibm/JikesRVM/VM_Processor;) l0psa(Lorg/vmmagic/unboxed/ObjectReference;) l6psa(Ljava/net/URL;,x,d) t311psa(Ljava/security/CodeSource;,p) ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-23 15:33 Message: Logged In: YES user_id=308843 Having gone through the final assembler (of x86 although the bug effects both) of the non-unrolled com.ibm.JikesRVM.opt.OPT_LiveSet.remove(Lcom/ibm/JikesRVM/opt/ir/OPT_RegisterOperand;)V I can see nothing that is clearly different from the original source. Possibly this could mean that the bug lies elsewhere, such as in the yield point back-edge, or outside of the loop. But this code looks ok to me. Also there seems to be no liveness analysis occuring when the bug happens. So it seems the most likely thing is the bug breaks the liveness analysis which then causes incorrect code generation and the associated problems. As such I should be able to dump the live sets before and after removal and find the specific place that the corruption happens (by diffing the working and non-working results from a development build). Then I should be able to find a case that will break the MIR I have in front of me and expose the bug I can then trace back to the breaking IR stage. That's my theory anyway, I'm not sure if it will work (it's a remarkably trivial loop for things to have gone wrong on). ---------------------------------------------------------------------- Comment By: Dave Grove (dgrove-oss) Date: 2006-05-23 14:29 Message: Logged In: YES user_id=1215435 great. now it's time to either look at the code and see what's wrong, or further narrow by turning optimizations off/on to see if there's a single transform that breaks things. Am I remembering correctly this breaks on both IA32 & PPC? If so, life is easier since you can almost certainly rule out all the MIR stuff as a source of the bug and focus on HIR and LIR stages only. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-23 13:39 Message: Logged In: YES user_id=308843 And the winner is: com.ibm.JikesRVM.opt.OPT_LiveSet.remove(Lcom/ibm/JikesRVM/opt/ir/OPT_RegisterOperand;)V however, my early guess that LICM would be implicated seems not to be the case, as avoiding LICM for this loop doesn't fix the problem. ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-23 00:55 Message: Logged In: YES user_id=308843 I binary chopped through all unrolled methods and have come up with OPT_LiveSet.remove (not sure which version). That is, if you disable loop unrolling on everything but OPT_LiveSet.remove then the RVM works. If you don't unroll OPT_LiveSet.remove then it causes the MMTk problems seen in this bug report. Ian ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-22 09:27 Message: Logged In: YES user_id=308843 Some interesting points: * the address 0x3fe7116b that appears in the 1st stack trace is equivalent to the floating point value 1.805219. * the builds that die have opt compiled the runtime system. Prototype builds appear to be less effected. This makes me believe the compiler is failing when building the runtime rather than the particular benchmark. It also makes testing more difficult :-( ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-22 00:45 Message: Logged In: YES user_id=308843 Just a note to myself that the lack of loop unrolling doesn't just effect MMTk. OPT_Compiler failure during compilation of spec.benchmarks._201_compress.Compressor.compress ()V java.lang.NullPointerException at java.lang.Throwable.fillInStackTrace(Throwable.java:109) at java.lang.Throwable.<init>(Throwable.java:53) at java.lang.Exception.<init>(Exception.java:67) at java.lang.RuntimeException.<init>(RuntimeException.java:65) at java.lang.NullPointerException.<init>(NullPointerException.java:70) at com.ibm.JikesRVM.VM_Runtime.deliverHardwareException(VM_Runtime.java:631) at <hardware trap> at com.ibm.JikesRVM.opt.OPT368657 _LICM.checkLoop(OPT_LICM.java:1005) at com.ibm.JikesRVM.opt.OPT_LICM.simplify(OPT_LICM.java:929) at com.ibm.JikesRVM.opt.OPT_LICM.initialize(OPT_LICM.java:860) at com.ibm.JikesRVM.opt.OPT_LICM.perform(OPT_LICM.java:55) at com.ibm.JikesRVM.opt.OPT_CompilerPhase.performPhase(OPT_CompilerPhase.java:129) at com.ibm.JikesRVM.opt.OPT_OptimizationPlanAtomicElement.perform(OPT_OptimizationPlanAtomicElement.java:80) at com.ibm.JikesRVM.opt.OPT_OptimizationPlanCompositeElement.perform(OPT_OptimizationPlanCompositeElement.java:141) at com.ibm.JikesRVM.opt.OPT_OptimizationPlanCompositeElement.perform(OPT_OptimizationPlanCompositeElement.java:141) at com.ibm.JikesRVM.opt.OPT_OptimizationPlanCompositeElement.perform(OPT_OptimizationPlanCompositeElement.java:141) at com.ibm.JikesRVM.opt.OPT_CompilationPlan.execute(OPT_CompilationPlan.java:105) at com.ibm.JikesRVM.opt.OPT_Compiler.compile(OPT_Compiler.java:222) at com.ibm.JikesRVM.VM_RuntimeCompiler.optCompile(VM_RuntimeCompiler.java:377) at com.ibm.JikesRVM.VM_RuntimeCompiler.recompileWithOpt(VM_RuntimeCompiler.java:519) at com.ibm.JikesRVM.adaptive.VM_ControllerPlan.doRecompile(VM_ControllerPlan.java:179) at com.ibm.JikesRVM.adaptive.VM_CompilationThread.run(VM_CompilationThread.java:54) and another example of the MMTk problem: validRef: REF outside heap, ref = 0xffffffff boot 0x31000000->0x40ffffff immortal 0x41000000->0x42ffffff meta 0x43000000->0x44ffffff los 0x45000000->0x4c7fffff nursery 0x75000000->0x7fffffff ms 0x4c800000->0x713fffff sanity 0x71400000->0x733fffff Invalid ref reported while scanning stack --- METHOD (OPT) Lspec/benchmarks/_205_raytrace/IntersectPt;.FindNearestIsect (Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;IILspec/benchmarks/_205_raytrace/OctNode;)Z --- fp = 0x456d1e90 code base = 0x4d37860c code offset = 0x00000288 REF=0xffffffff (REF OUTSIDE OF HEAP OR NOT MAPPED) -- Stack -- Lspec/benchmarks/_205_raytrace/IntersectPt; FindNearestIsect(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;IILspec/benchmarks/_205_raytrace/OctNode;)Z at line 135 Lspec/benchmarks/_205_raytrace/Scene; Shade(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;Lspec/benchmarks/_205_raytrace/Color;FII)V at line 445 Lspec/benchmarks/_205_raytrace/Scene; RenderScene(Lspec/benchmarks/_205_raytrace/Canvas;III)V at line 650 Lspec/benchmarks/_205_raytrace/Runner; run()V at line 133 Lcom/ibm/JikesRVM/VM_Thread; run()V at line 200 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 -- Stack -- Lcom/ibm/JikesRVM/VM_Processor; dispatch(Z)V at line 217 Lcom/ibm/JikesRVM/VM_Thread; morph(Z)V at line 722 Lcom/ibm/JikesRVM/VM_Thread; timerTickYield(I)V at line 544 Lcom/ibm/JikesRVM/VM_Thread; yieldpoint(I)V at line 520 Lcom/ibm/JikesRVM/opt/VM_OptSaveVolatile; OPT_yieldpointFromEpilogue()V at line 47 Lspec/benchmarks/_205_raytrace/OctNode; Intersect(Lspec/benchmarks/_205_raytrace/Ray;Lspec/benchmarks/_205_raytrace/Point;F)Lspec/benchmarks/_205_raytrace/OctNode; at line 434 Lspec/benchmarks/_205_raytrace/IntersectPt; FindNearestIsect(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;IILspec/benchmarks/_205_raytrace/OctNode;)Z at line 135 Lspec/benchmarks/_205_raytrace/Scene; Shade(Lspec/benchmarks/_205_raytrace/OctNode;Lspec/benchmarks/_205_raytrace/Ray;Lspec/benchmarks/_205_raytrace/Color;FII)V at line 445 Lspec/benchmarks/_205_raytrace/Scene; RenderScene(Lspec/benchmarks/_205_raytrace/Canvas;III)V at line 650 Lspec/benchmarks/_205_raytrace/Runner; run()V at line 133 Lcom/ibm/JikesRVM/VM_Thread; run()V at line 200 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 VM_ScanStack: Detected bad GC map; exiting RVM with fatal error -- Stack -- Lorg/mmtk/vm/ScanThread; checkReference(Lorg/vmmagic/unboxed/Address;I)V at line 616 Lorg/mmtk/vm/ScanThread; scanFrameForObjects(I)V at line 400 Lorg/mmtk/vm/ScanThread; scanFrame(I)Lorg/vmmagic/unboxed/Address; at line 320 Lorg/mmtk/vm/ScanThread; scanThreadInternal(Lorg/vmmagic/unboxed/Address;I)V at line 240 Lorg/mmtk/vm/ScanThread; startScan(Lorg/mmtk/plan/TraceLocal;ZLcom/ibm/JikesRVM/VM_Thread;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V at line 200 Lorg/mmtk/vm/ScanThread; scanThread(Lcom/ibm/JikesRVM/VM_Thread;Lorg/mmtk/plan/TraceLocal;ZLorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V at line 166 Lorg/mmtk/vm/ScanThread; scanThread(Lcom/ibm/JikesRVM/VM_Thread;Lorg/mmtk/plan/TraceLocal;Z)V at line 131 Lorg/mmtk/vm/Scanning; computeAllRoots(Lorg/mmtk/plan/TraceLocal;)V at line 236 Lorg/mmtk/plan/StopTheWorldLocal; collectionPhase(IZZ)V at line 102 Lorg/mmtk/plan/generational/GenLocal; collectionPhase(IZZ)V at line 203 Lorg/mmtk/plan/generational/marksweep/GenMSLocal; collectionPhase(IZZ)V at line 230 Lorg/mmtk/plan/SimplePhase; delegatePhase()V at line 170 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/Phase; delegatePhase(I)V at line 148 Lorg/mmtk/plan/ComplexPhase; delegatePhase()V at line 95 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/Phase; delegatePhase(I)V at line 148 Lorg/mmtk/plan/ComplexPhase; delegatePhase()V at line 95 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/StopTheWorldLocal; collect()V at line 57 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/VM_CollectorThread; run()V at line 342 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 (the previous one did have versioning enabled, whereas this doesn't) ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-05-21 17:50 Message: Logged In: YES user_id=308843 A similar problem occurs with loop unrolling disabled on a PowerPC development build: validRef: REF outside heap, ref = 0x00001ba0 boot 0x31000000->0x40ffffff immortal 0x41000000->0x42ffffff meta 0x43000000->0x44ffffff los 0x45000000->0x4c7fffff nursery 0x75000000->0x7fffffff ms 0x4c800000->0x713fffff sanity 0x71400000->0x733fffff Invalid ref reported while scanning stack --- METHOD (OPT) Lspec/benchmarks/_201_compress/Compressor;.compress ()V --- fp = 0x4534eca8 code base = 0x4cb8a90c code offset = 0x00000100 REF=0x00001ba0 (REF OUTSIDE OF HEAP OR NOT MAPPED) -- Stack -- Lspec/benchmarks/_201_compress/Compressor; compress()V Lspec/benchmarks/_201_compress/Compress; spec_select_action([BII[B)I Lspec/benchmarks/_201_compress/Harness; run_compress([Ljava/lang/String;)Z Lspec/benchmarks/_201_compress/Harness; inst_main([Ljava/lang/String;)J Lspec/benchmarks/_201_compress/Main; runBenchmark([Ljava/lang/String;)J Lspec/benchmarks/_201_compress/Main; harnessMain([Ljava/lang/String;)J Lspec/harness/ProgramRunner; runOnce(Ljava/lang/Object;IJILjava/util/Properties;)Lspec/harness/BenchmarkTime; at line 382 Lspec/harness/ProgramRunner; runBenchmark2()Ljava/util/Properties; at line 306 Lspec/harness/ProgramRunner; runBenchmark()V at line 238 Lspec/harness/ProgramRunner; run()V at line 206 Lspec/harness/RunProgram; run(Ljava/lang/String;ZLjava/util/Properties;Lspec/harness/BenchmarkDone;)V at line 60 LSpecApplication; runBenchmark(Ljava/lang/String;Z)V at line 255 LSpecApplication; main([Ljava/lang/String;)V at line 171 Lcom/ibm/JikesRVM/MainThread; run()V at line 115 Lcom/ibm/JikesRVM/VM_Thread; run()V at line 200 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 -- Stack -- Lcom/ibm/JikesRVM/VM_Processor; dispatch(Z)V at line 217 Lcom/ibm/JikesRVM/VM_Thread; morph(Z)V at line 722 Lcom/ibm/JikesRVM/VM_Thread; timerTickYield(I)V at line 544 Lcom/ibm/JikesRVM/VM_Thread; yieldpoint(I)V at line 520 Lcom/ibm/JikesRVM/opt/VM_OptSaveVolatile; OPT_yieldpointFromBackedge()V at line 57 Lspec/benchmarks/_201_compress/Compressor; compress()V Lspec/benchmarks/_201_compress/Compress; spec_select_action([BII[B)I Lspec/benchmarks/_201_compress/Harness; run_compress([Ljava/lang/String;)Z Lspec/benchmarks/_201_compress/Harness; inst_main([Ljava/lang/String;)J Lspec/benchmarks/_201_compress/Main; runBenchmark([Ljava/lang/String;)J Lspec/benchmarks/_201_compress/Main; harnessMain([Ljava/lang/String;)J Lspec/harness/ProgramRunner; runOnce(Ljava/lang/Object;IJILjava/util/Properties;)Lspec/harness/BenchmarkTime; at line 382 Lspec/harness/ProgramRunner; runBenchmark2()Ljava/util/Properties; at line 306 Lspec/harness/ProgramRunner; runBenchmark()V at line 238 Lspec/harness/ProgramRunner; run()V at line 206 Lspec/harness/RunProgram; run(Ljava/lang/String;ZLjava/util/Properties;Lspec/harness/BenchmarkDone;)V at line 60 LSpecApplication; runBenchmark(Ljava/lang/String;Z)V at line 255 LSpecApplication; main([Ljava/lang/String;)V at line 171 Lcom/ibm/JikesRVM/MainThread; run()V at line 115 Lcom/ibm/JikesRVM/VM_Thread; run()V at line 200 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 VM_ScanStack: Detected bad GC map; exiting RVM with fatal error -- Stack -- Lorg/mmtk/vm/ScanThread; checkReference(Lorg/vmmagic/unboxed/Address;I)V at line 616 Lorg/mmtk/vm/ScanThread; scanFrameForObjects(I)V at line 400 Lorg/mmtk/vm/ScanThread; scanFrame(I)Lorg/vmmagic/unboxed/Address; at line 320 Lorg/mmtk/vm/ScanThread; scanThreadInternal(Lorg/vmmagic/unboxed/Address;I)V at line 240 Lorg/mmtk/vm/ScanThread; startScan(Lorg/mmtk/plan/TraceLocal;ZLcom/ibm/JikesRVM/VM_Thread;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V at line 200 Lorg/mmtk/vm/ScanThread; scanThread(Lcom/ibm/JikesRVM/VM_Thread;Lorg/mmtk/plan/TraceLocal;ZLorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V at line 166 Lorg/mmtk/vm/ScanThread; scanThread(Lcom/ibm/JikesRVM/VM_Thread;Lorg/mmtk/plan/TraceLocal;Z)V at line 131 Lorg/mmtk/vm/Scanning; computeAllRoots(Lorg/mmtk/plan/TraceLocal;)V at line 236 Lorg/mmtk/plan/StopTheWorldLocal; collectionPhase(IZZ)V at line 102 Lorg/mmtk/plan/generational/GenLocal; collectionPhase(IZZ)V at line 203 Lorg/mmtk/plan/generational/marksweep/GenMSLocal; collectionPhase(IZZ)V at line 230 Lorg/mmtk/plan/SimplePhase; delegatePhase()V at line 170 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/Phase; delegatePhase(I)V at line 148 Lorg/mmtk/plan/ComplexPhase; delegatePhase()V at line 95 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/Phase; delegatePhase(I)V at line 148 Lorg/mmtk/plan/ComplexPhase; delegatePhase()V at line 95 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 162 Lorg/mmtk/plan/StopTheWorldLocal; collect()V at line 57 Lcom/ibm/JikesRVM/memoryManagers/mmInterface/VM_CollectorThread; run()V at line 342 Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 781 ---------------------------------------------------------------------- Comment By: Dave Grove (dgrove-oss) Date: 2006-05-17 15:20 Message: Logged In: YES user_id=1215435 I think there are two possible sources of the bug: (1) turning off loop unrolling results in bad code being generated for some piece of the opt compiler that generates/interprets the opt GC maps and/or some piece of MMTk that uses the information. (2) turning off loop unrolling results in a bad GC map being generated for the particular method in mtrt (+ the methods in other benchmarks you mentioned). My instinct is that (1) is a more likely hypothesis. To pursue it, life would be easier if the crash is fairly deterministic. If it is, then you can proceed by enabling/disabling loop unrolling on classes in the bootimage to do a binary search to find the method which is being generated incorrectly. My guess is that it is some method in VM_OptMachineCodeMap or VM_OptGCMap, but it could be almost anywhere where in the opt compiler or MMTk. An initial first check would be to build the bootimage with loop unrolling enabled (normal), but disable it at runtime. If this configuration never exhibits the crash, then the search through the bootimage compiled code seems like the thing to do. If (2) is the problem (it really is a bad GC map that isn't due to bad code gen in the bootimage), then to debug GC maps you set VM_OptMachineCodeMap.DUMP_MAPS to true and dump large ammounts of debug information to get the GC map & associated debug info for the program point (0x00001c14 of that method) and see if it makes sense. This is likely to be quite painful because the method is so big, so hopefully it won't come to this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1488798&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 01:27:38
|
Bugs item #1147537, was opened at 2004-10-23 00:23 Message generated for change (Comment added) made by peter_donald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1147537&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: baseline compiler Group: confirmed >Status: Closed >Resolution: Out of Date Priority: 8 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Peter Donald (peter_donald) Summary: Incorrect reference maps generated by baseline compiler Initial Comment: A BaseBaseSemiSpace build fails when running jbb2000 with an "Invalid ref while scanning the stack" error. The *only* modifications we made to this were to force GCs at *very* frequent intervals. The version used had cvs timestamp: 2004/07/30 12:09:00 UTC. We've placed a number of data files in http://www.cs.kent.ac.uk/people/staff/cr20/gc-map-bug/ including source code and assembler for jbb2000's JBBmain.main, the full stack and reference map outputs from jbb2000, 3 extracts of this (to save wading through a 1GB+ file), and a summary of the crash. Here's the scenario. The relevant part of JBBmain.main is: try { AsciiReport asciireport = new AsciiReport(s12, s9, flag11); // [1504] astore 37 asciireport.print(s14); } // point 1 catch(Exception _ex) { } Report report; try { report = new Report(flag5, flag11, s12, s9, flag12, s15, s11, flag6, s3); // point 2 } catch(Exception _ex) { ... } catch(InternalError _ex) { ... } catch(UnsatisfiedLinkError _ex) { ... } catch(Error _ex) { System.out.println("Producing html chart in report instead of JPEG; see Users' Guide"); report = new Report(flag5, flag11, s12, s9, flag12, s15, s11, flag10, s3); // point 3 } report.print(s13); try { BufferedReader bufferedreader = new BufferedReader(new FileReader(s14)); // [1735] astore 37 ... At point 1, . The stack slot for asciireport is reported correctly as a reference by the GC map. . The asciireport is at index 37 of the local variable array (i.e. the instruction after the new is astore 37). At point 2, . asciireport is still on the stack but is not reported as a reference. . Note that it is out of scope. . Many GCs follow with the same result. At point 3, . This slot is reported again as a reference. . However, the validRef test fails. . Note that the bufferedreader is now to be held in local variable slot 37 but this address has not been written at the time of the crash. In summary, our new work simply brought this bug to the surface (because it happens that a GC happens at almost every GC point in JBBmain.main). However, it was not the cause of the bug. . The bug lies in the GC map generation for the baseline compiler (the runtime correctly interprets the incorrect reference maps). . There is no jsr in JBBmain.main. . We have observed dynamic bridge frames and lazy compilation methods on the stack (e.g. for AsciiReport.print). Richard Jones (R.E...@ke...) Chris Ryder (cr...@ke...) ---------------------------------------------------------------------- >Comment By: Peter Donald (peter_donald) Date: 2007-05-23 11:27 Message: Logged In: YES user_id=1642927 Originator: NO I am assuming this is fixed as I am unable to reproduce it. ---------------------------------------------------------------------- Comment By: Steven Augart (saugart) Date: 2005-02-25 04:58 Message: Logged In: YES user_id=443064 This report was actually submitted by R.E...@ke...; that information was lost in the move. ---------------------------------------------------------------------- Comment By: Steven Augart (saugart) Date: 2004-12-21 06:17 Message: Bug # 4088 (Invalid ref reported while scanning stack) may be a manifestation of this. ---------------------------------------------------------------------- Comment By: Dave Grove (dgrove-oss) Date: 2004-10-26 19:44 Message: You may have tried this already, but probably the way to proceed is to jury rig a setup where you can cause the baseline compiler to compile the suspect method without actually running SPECjbb. I'd do this by using OptTestHarness (can also be used as a 'Base' test harness, for example: rvm -classpath jbb.jar:jbb_no_precompile.jar:check.jar:reporter.jar OptTestHarness +baseline -method spec.jbb.JBBmain main -). Enable debug in VM_BuildReferenceMaps and make sure that the incorrect GC map is still being computed. Then you could either (1) inject more debugging ouput into VM_BuildReferenceMaps or (2) attempt to reduce the size of the suspect method without losing the incorrect GCMap. I'd probably attempt (2) first just to make life simpler. I'll try to look at this in the background, but can't promise to make too much this week. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1147537&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 01:23:59
|
Bugs item #1147543, was opened at 2004-09-11 01:05 Message generated for change (Comment added) made by peter_donald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1147543&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: documentation Group: confirmed >Status: Closed >Resolution: Out of Date Priority: 7 Private: No Submitted By: Dave Grove (dgrove-oss) >Assigned to: Peter Donald (peter_donald) Summary: Update discussion of Magic to match cvs head Initial Comment: We're in the midst of a major rework of magic in Jikes RVM; update documentation to reflect this fact. ---------------------------------------------------------------------- >Comment By: Peter Donald (peter_donald) Date: 2007-05-23 11:23 Message: Logged In: YES user_id=1642927 Originator: NO Closing this as out of date as the documentation was updated (however it could always use with more updating). ---------------------------------------------------------------------- Comment By: Dave Grove (dgrove-oss) Date: 2004-12-19 07:51 Message: Did enough for the 2.3.4 release. Mainly added a note that we are in the middle of changing lots of stuff. Leaving this open (but unassigned) because we pretty much need to rewrite the entire magic.tex file once the old machanisms are completely gone and we're using org.vmmagic and the new uninterruptibility mechanisms uniformly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1147543&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 01:20:54
|
Bugs item #1723869, was opened at 2007-05-23 10:28 Message generated for change (Comment added) made by peter_donald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1723869&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: optimizing compiler Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Peter Donald (peter_donald) Assigned to: Nobody/Anonymous (nobody) Summary: VM_OptMachineCodeMap.generateMCInformation bad gcmap Initial Comment: The method VM_OptMachineCodeMap.generateMCInformation seems to produce and invalid gc map at O2 level optimization. Note: This is after r12223 where a few of explicit optimizations where moved from O1 to O2 To reproduce you can change the value of "config.bootimage.compiler.args" in "build/configs/gcstress.properties" from "-X:bc:O1" to "-X:bc:O2" and then run the gcmap-sanity test run via something like ant -f test.xml -Dtest-run.name=gcmap-sanity Tests will start failing with output like validRef: TIB outside heap, ref = 0x9d800a24 tib = 0x00000000 Invalid ref reported while scanning stack --- METHOD (OPT) Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap;.generateMCInformation (Lorg/jikesrvm/compilers/opt/ir/OPT_GCIRMap;)Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap; --- fp = 0x6b29fcc4 code base = 0x5b8c1ef4 code offset = 0x00003243 0x6dc2fbf4:REF=0x9d800a24 TIB=0x00000000 STATUS=0x00000000 (INVALID TIB: CLASS NOT ACCESSIBLE) ... Dumping stack starting at frame with bad ref: -- Stack -- Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap; generateMCInformation(Lorg/jikesrvm/compilers/opt/ir/OPT_GCIRMap;)Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap; at line 398 Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap; create(Lorg/jikesrvm/compilers/opt/ir/OPT_IR;I)Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap; at line 99 Lorg/jikesrvm/compilers/opt/VM_OptCompiledMethod; createFinalMCMap(Lorg/jikesrvm/compilers/opt/ir/OPT_IR;I)V at line 438 ... There are a number of sample failures attached. ---------------------------------------------------------------------- >Comment By: Peter Donald (peter_donald) Date: 2007-05-23 11:20 Message: Logged In: YES user_id=1642927 Originator: YES "[ 1488798 ] Leave SSA broken - lack of loop unrolling breaks MMTk" may be a duplicate of this bug but it is difficult to determine without further analysis ---------------------------------------------------------------------- Comment By: Peter Donald (peter_donald) Date: 2007-05-23 11:18 Message: Logged In: YES user_id=1642927 Originator: YES Unfortunately I made an error and ran tests against r12222 but r12223 seems to have fixed it which means the bug was caused by one of the optimizations that was moved from O2 to O3 in r12223 ---------------------------------------------------------------------- Comment By: Peter Donald (peter_donald) Date: 2007-05-23 10:43 Message: Logged In: YES user_id=1642927 Originator: YES Note that 398 seems to be the earliest line number where the bug is expressed. ---------------------------------------------------------------------- Comment By: Peter Donald (peter_donald) Date: 2007-05-23 10:38 Message: Logged In: YES user_id=1642927 Originator: YES File Added: jBYTEmark-output.txt ---------------------------------------------------------------------- Comment By: Peter Donald (peter_donald) Date: 2007-05-23 10:35 Message: Logged In: YES user_id=1642927 Originator: YES File Added: JLex.Main-trimmed.txt.gz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1723869&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 01:18:25
|
Bugs item #1723869, was opened at 2007-05-23 10:28 Message generated for change (Comment added) made by peter_donald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1723869&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: optimizing compiler Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Peter Donald (peter_donald) Assigned to: Nobody/Anonymous (nobody) Summary: VM_OptMachineCodeMap.generateMCInformation bad gcmap Initial Comment: The method VM_OptMachineCodeMap.generateMCInformation seems to produce and invalid gc map at O2 level optimization. Note: This is after r12223 where a few of explicit optimizations where moved from O1 to O2 To reproduce you can change the value of "config.bootimage.compiler.args" in "build/configs/gcstress.properties" from "-X:bc:O1" to "-X:bc:O2" and then run the gcmap-sanity test run via something like ant -f test.xml -Dtest-run.name=gcmap-sanity Tests will start failing with output like validRef: TIB outside heap, ref = 0x9d800a24 tib = 0x00000000 Invalid ref reported while scanning stack --- METHOD (OPT) Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap;.generateMCInformation (Lorg/jikesrvm/compilers/opt/ir/OPT_GCIRMap;)Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap; --- fp = 0x6b29fcc4 code base = 0x5b8c1ef4 code offset = 0x00003243 0x6dc2fbf4:REF=0x9d800a24 TIB=0x00000000 STATUS=0x00000000 (INVALID TIB: CLASS NOT ACCESSIBLE) ... Dumping stack starting at frame with bad ref: -- Stack -- Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap; generateMCInformation(Lorg/jikesrvm/compilers/opt/ir/OPT_GCIRMap;)Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap; at line 398 Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap; create(Lorg/jikesrvm/compilers/opt/ir/OPT_IR;I)Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap; at line 99 Lorg/jikesrvm/compilers/opt/VM_OptCompiledMethod; createFinalMCMap(Lorg/jikesrvm/compilers/opt/ir/OPT_IR;I)V at line 438 ... There are a number of sample failures attached. ---------------------------------------------------------------------- >Comment By: Peter Donald (peter_donald) Date: 2007-05-23 11:18 Message: Logged In: YES user_id=1642927 Originator: YES Unfortunately I made an error and ran tests against r12222 but r12223 seems to have fixed it which means the bug was caused by one of the optimizations that was moved from O2 to O3 in r12223 ---------------------------------------------------------------------- Comment By: Peter Donald (peter_donald) Date: 2007-05-23 10:43 Message: Logged In: YES user_id=1642927 Originator: YES Note that 398 seems to be the earliest line number where the bug is expressed. ---------------------------------------------------------------------- Comment By: Peter Donald (peter_donald) Date: 2007-05-23 10:38 Message: Logged In: YES user_id=1642927 Originator: YES File Added: jBYTEmark-output.txt ---------------------------------------------------------------------- Comment By: Peter Donald (peter_donald) Date: 2007-05-23 10:35 Message: Logged In: YES user_id=1642927 Originator: YES File Added: JLex.Main-trimmed.txt.gz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1723869&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 01:14:40
|
Bugs item #1591798, was opened at 2006-11-07 16:11 Message generated for change (Comment added) made by peter_donald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1591798&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 7 Private: No Submitted By: Robin Garner (rgarner) >Assigned to: Peter Donald (peter_donald) Summary: DaCapo eclipse benchmark fails Initial Comment: Since 4 Nov 2006, the DaCapo Eclipse benchmark has failed consistently with the following stack dump: ===== DaCapo eclipse starting warmup ===== Exception in thread "main": java.lang.NoClassDefFoundError: Could not find the class org.eclipse.jdt.internal.launching.StandardVMType: org.eclipse.jdt.internal.launching.StandardVMType at java.lang.Throwable.fillInStackTrace(Throwable.java:114) at java.lang.Throwable.<init>(Throwable.java:58) at java.lang.Throwable.<init>(Throwable.java:63) at java.lang.Error.<init>(Error.java:81) at java.lang.LinkageError.<init>(LinkageError.java:72) at java.lang.NoClassDefFoundError.<init>(NoClassDefFoundError.java:74) at com.ibm.jikesrvm.classloader.VM_TypeReference.resolveInternal(VM_TypeReference.java:593) at com.ibm.jikesrvm.classloader.VM_TypeReference.resolve(VM_TypeReference.java:578) at com.ibm.jikesrvm.VM_Runtime.unresolvedNewScalar(VM_Runtime.java:280) at dacapo.eclipse.HarnessRunner.validJavaHome(HarnessRunner.java:38) at dacapo.eclipse.HarnessRunner.run(HarnessRunner.java:19) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:226) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:376) at dacapo.eclipse.EclipseHarness.iterate(EclipseHarness.java:35) at dacapo.Benchmark.run(Benchmark.java:121) at dacapo.TestHarness.runBenchmark(TestHarness.java:299) at dacapo.TestHarness.main(TestHarness.java:240) at Harness.main(Harness.java:5) Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.launching.StandardVMType at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:405) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:350) at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:78) at java.lang.ClassLoader.loadClass(ClassLoader.java:294) at com.ibm.jikesrvm.classloader.VM_TypeReference.resolveInternal(VM_TypeReference.java:591) at com.ibm.jikesrvm.classloader.VM_TypeReference.resolve(VM_TypeReference.java:578) at com.ibm.jikesrvm.VM_Runtime.unresolvedNewScalar(VM_Runtime.java:280) at dacapo.eclipse.HarnessRunner.validJavaHome(HarnessRunner.java:38) at dacapo.eclipse.HarnessRunner.run(HarnessRunner.java:19) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:226) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:376) at dacapo.eclipse.EclipseHarness.iterate(EclipseHarness.java:35) at dacapo.Benchmark.run(Benchmark.java:121) at dacapo.TestHarness.runBenchmark(TestHarness.java:299) at dacapo.TestHarness.main(TestHarness.java:240) at Harness.main(Harness.java:5) ---------------------------------------------------------------------- >Comment By: Peter Donald (peter_donald) Date: 2007-05-23 11:14 Message: Logged In: YES user_id=1642927 Originator: NO The failure is covered by "[ 1722506 ] dacapo eclipse fails EOF exceptions" ---------------------------------------------------------------------- Comment By: Robin Garner (rgarner) Date: 2007-03-11 11:39 Message: Logged In: YES user_id=203294 Originator: YES This issue seems to be fixed - Eclipse now fails at a later point. Rather than close this and open a new issue, here's the latest stack dump: /home/robing/tmp/dacapo-nightly-20070309/rvm_trunk/dist/FastAdaptiveGenMS_ia32-linux/rvm -Declipse.java.home=/usr/lib/j2se/1.4 -Xmx512m -Xms512m -jar dacapo-20070309.jar -s default -n 2 -scratch /tmp/24943 eclipse ===== DaCapo eclipse starting warmup ===== <setting up workspace...> <creating projects..............................................................> <running tests at level 0...> <performing build tests...> org.apache.ant (not open) opening cleaning building org.junit (not open) opening cleaning building org.eclipse.osgi (not open) opening cleaning building <performing type hierarchy tests...> Hierarchy: org.eclipse.help.internal HelpPlugin java.io.EOFException at java.lang.Throwable.fillInStackTrace(Throwable.java:106) at java.lang.Throwable.<init>(Throwable.java:50) at java.lang.Exception.<init>(Exception.java:66) at java.io.IOException.<init>(IOException.java:61) at java.io.EOFException.<init>(EOFException.java:63) at java.io.DataInputStream.readFully(DataInputStream.java:285) at java.io.DataInputStream.readInt(DataInputStream.java:320) at org.eclipse.jdt.internal.core.index.DiskIndex.readCategoryTable(DiskIndex.java:555) at org.eclipse.jdt.internal.core.index.DiskIndex.addQueryResults(DiskIndex.java:170) at org.eclipse.jdt.internal.core.index.Index.query(Index.java:118) at org.eclipse.jdt.internal.core.search.matching.SuperTypeReferencePattern.queryIn(SuperTypeReferencePattern.java:234) at org.eclipse.jdt.internal.core.search.matching.InternalSearchPattern.findIndexMatches(InternalSearchPattern.java:75) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.findIndexMatches(MatchLocator.java:307) at org.eclipse.jdt.internal.core.search.PatternSearchJob.search(PatternSearchJob.java:114) at org.eclipse.jdt.internal.core.search.SubTypeSearchJob.search(SubTypeSearchJob.java:37) at org.eclipse.jdt.internal.core.search.PatternSearchJob.execute(PatternSearchJob.java:64) at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob(JobManager.java:261) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.searchAllPossibleSubTypes(IndexBasedHierarchyBuilder.java:493) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.determinePossibleSubTypes(IndexBasedHierarchyBuilder.java:382) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(IndexBasedHierarchyBuilder.java:119) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:320) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:1255) at org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation(CreateTypeHierarchyOperation.java:90) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:718) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:777) at org.eclipse.jdt.internal.core.SourceType.newTypeHierarchy(SourceType.java:716) at dacapo.eclipse.EclipseTypeHierarchyTests.allTypes(EclipseTypeHierarchyTests.java:27) at dacapo.eclipse.EclipseTypeHierarchyTests.doTests(EclipseTypeHierarchyTests.java:14) at dacapo.eclipse.EclipseTests.runtests(EclipseTests.java:100) at dacapo.eclipse.HarnessRunner.run(HarnessRunner.java:21) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:226) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:376) at dacapo.eclipse.EclipseHarness.iterate(EclipseHarness.java:35) at dacapo.Benchmark.run(Benchmark.java:126) at dacapo.TestHarness.runBenchmark(TestHarness.java:301) at dacapo.TestHarness.main(TestHarness.java:242) at Harness.main(Harness.java:5) ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-11-09 03:01 Message: Logged In: YES user_id=308843 Maybe I was reading a partial result. It seems we're now getting a different eclipse regression. Ian ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-11-09 02:39 Message: Logged In: YES user_id=308843 It looks like this is now passing (from your website). We're still failing 2 DaCapo tests, but this seems to be the best result ever? I think we can close the bug anyway (NB I can't close someone else's bug). I've opened up an RFE on the reflection problem that was the cause of it. Thanks, Ian ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-11-08 06:43 Message: Logged In: YES user_id=308843 I've addressed one issue in 10950, hopefully this will resolve the regression. We should probably modify how we perform resolution of classes during reflection to match that of other JVMs. This patch moves us back to the behaviour prior to 10944 - ie we resolve classes when we get their class from their type. Ian ---------------------------------------------------------------------- Comment By: Ian Rogers (captain5050) Date: 2006-11-08 00:19 Message: Logged In: YES user_id=308843 This probably relates to patch #10944 which changed the JTOC layout, but more importantly probably for this bug, changes parts of VM_Type. Principally these are so that we create a java.lang.Class wrapper for a VM_Type when the VM_Type is constructed. This shouldn't be causing this problem so I'm scratching my head looking for the cause. Ian ---------------------------------------------------------------------- Comment By: Robin Garner (rgarner) Date: 2006-11-07 17:18 Message: Logged In: YES user_id=203294 This happens in both uniprocessor and dual processor configurations, and only started happening from the 4th of November. See http://cs.anu.edu.au/people/Robin.Garner/dacapo/regressions/ for logs and history. -- Robin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1591798&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 01:08:46
|
Bugs item #1596724, was opened at 2006-11-15 12:27 Message generated for change (Comment added) made by peter_donald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1596724&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GC Group: None >Status: Closed >Resolution: Duplicate Priority: 8 Private: No Submitted By: Steve Blackburn (steveb-oss) >Assigned to: Peter Donald (peter_donald) Summary: JNI GC map bug Initial Comment: I found this by running FastAdaptiveSemiSpace (svn head) on eclipse: h=100M; rvm -Xms$h -Xmx$h -X:gc:variableSizeHeap=false -X:gc:stressFactor=131072 -jar dacapo-2006-10-RC3.jar eclipse ..... [GC 2839 Start 1463.00 s 24068KB validRef: TIB outside heap, ref = 0x5eaaa340 tib = 0x00000022 Invalid ref reported while scanning stack --- METHOD (JNI) Lcom/ibm/jikesrvm/VM_Process;.exec4 (Ljava/lang/String;[Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;)I --- fp = 0x5b136b3c code base = 0x5f2f7d68 code offset = 0xebfa98eb 0x7c0012f8:REF=0x5eaaa340 TIB=0x00000022 STATUS=0xb8f94985 (INVALID TIB: CLASS NOT ACCESSIBLE) 0x5b136b04 (0x00000000): 0x5b136b3c 0x5b136b08 (0x00000004): 0x4b2a1653 0x5b136b0c (0x00000008): 0x5701b714 0x5b136b10 (0x0000000c): 0x00000008 0x5b136b14 (0x00000010): 0x00000010 0x5b136b18 (0x00000014): 0x0000000c 0x5b136b1c (0x00000018): 0x00000000 0x5b136b20 (0x0000001c): 0x00000000 0x5b136b24 (0x00000020): 0x5701b718 0x5b136b28 (0x00000024): 0x5f2f7e43 0x5b136b2c (0x00000028): 0x00000000 0x5b136b30 (0x0000002c): 0x00000000 0x5b136b34 (0x00000030): 0x470401e8 0x5b136b38 (0x00000034): 0x000033ae Dumping stack starting at frame with bad ref: -- Stack -- Lcom/ibm/jikesrvm/VM_Process; exec4(Ljava/lang/String;[Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;)I Lcom/ibm/jikesrvm/VM_Process; <init>(Ljava/lang/String;[Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;)V at line 60 Ljava/lang/VMRuntime; exec([Ljava/lang/String;[Ljava/lang/String;Ljava/io/File;)Ljava/lang/Process; at line 123 Ljava/lang/Runtime; exec([Ljava/lang/String;[Ljava/lang/String;Ljava/io/File;)Ljava/lang/Process; at line 553 Ljava/lang/Runtime; exec([Ljava/lang/String;)Ljava/lang/Process; at line 505 Lorg/eclipse/jdt/internal/launching/StandardVMType; generateLibraryInfo(Ljava/io/File;Ljava/io/File;)Lorg/eclipse/jdt/internal/launching/LibraryInfo; at line 468 Lorg/eclipse/jdt/internal/launching/StandardVMType; getLibraryInfo(Ljava/io/File;Ljava/io/File;)Lorg/eclipse/jdt/internal/launching/LibraryInfo; at line 119 Lorg/eclipse/jdt/internal/launching/StandardVMType; getDefaultLibraryLocations(Ljava/io/File;)[Lorg/eclipse/jdt/launching/LibraryLocation; at line 264 Lorg/eclipse/jdt/internal/launching/StandardVMType; canDetectDefaultSystemLibraries(Ljava/io/File;Ljava/io/File;)Z at line 137 Lorg/eclipse/jdt/internal/launching/StandardVMType; validateInstallLocation(Ljava/io/File;)Lorg/eclipse/core/runtime/IStatus; at line 434 Ldacapo/eclipse/HarnessRunner; validJavaHome()Z at line 38 Ldacapo/eclipse/HarnessRunner; run(Ljava/lang/Object;)Ljava/lang/Object; at line 19 Lorg/eclipse/core/internal/runtime/PlatformActivator$1; run(Ljava/lang/Object;)Ljava/lang/Object; at line 226 Lorg/eclipse/core/runtime/adaptor/EclipseStarter; run(Ljava/lang/Object;)Ljava/lang/Object; at line 376 Ldacapo/eclipse/EclipseHarness; iterate(Ljava/lang/String;)V at line 35 Ldacapo/Benchmark; run(Ldacapo/Callback;Ljava/lang/String;Z)Z at line 121 Ldacapo/TestHarness; runBenchmark(Ljava/io/File;Ljava/lang/String;Ldacapo/TestHarness;)V at line 263 Ldacapo/TestHarness; main([Ljava/lang/String;)V at line 203 LHarness; main([Ljava/lang/String;)V at line 5 <invisible method> Lcom/ibm/jikesrvm/VM_Reflection; invoke(Lcom/ibm/jikesrvm/classloader/VM_Method;Ljava/lang/Object;[Ljava/lang/Object;Z)Ljava/lang/Object; at line 125 Lcom/ibm/jikesrvm/MainThread; run()V at line 200 Lcom/ibm/jikesrvm/VM_Thread; run()V at line 205 Lcom/ibm/jikesrvm/VM_Thread; startoff()V at line 786 -- Stack -- Lcom/ibm/jikesrvm/VM_Processor; dispatch(Z)V at line 221 Lcom/ibm/jikesrvm/VM_Thread; morph(Z)V at line 727 Lcom/ibm/jikesrvm/VM_Thread; yield()V at line 623 Lcom/ibm/jikesrvm/memorymanagers/mminterface/VM_Handshake; requestAndAwaitCompletion(I)V at line 87 Lcom/ibm/jikesrvm/memorymanagers/mminterface/VM_CollectorThread; collect(Lcom/ibm/jikesrvm/memorymanagers/mminterface/VM_Handshake;I)V at line 248 Lcom/ibm/jikesrvm/mm/mmtk/Collection; triggerCollectionStatic(I)V at line 145 Lcom/ibm/jikesrvm/mm/mmtk/Collection; triggerCollection(I)V at line 125 Lorg/mmtk/plan/semispace/SS; poll(ZLorg/mmtk/policy/Space;)Z at line 178 Lorg/mmtk/policy/Space; acquire(I)Lorg/vmmagic/unboxed/Address; at line 454 Lorg/mmtk/utility/alloc/BumpPointer; allocSlowOnce(IIIZ)Lorg/vmmagic/unboxed/Address; at line 268 Lorg/mmtk/utility/alloc/Allocator; allocSlowInline(IIIZ)Lorg/vmmagic/unboxed/Address; at line 256 Lorg/mmtk/utility/alloc/BumpPointer; allocSlow(Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;IIZ)Lorg/vmmagic/unboxed/Address; at line 179 Lorg/mmtk/utility/alloc/BumpPointer; alloc(IIIZ)Lorg/vmmagic/unboxed/Address; at line 152 Lorg/mmtk/plan/semispace/SSMutator; alloc(IIIII)Lorg/vmmagic/unboxed/Address; at line 86 Lcom/ibm/jikesrvm/memorymanagers/mminterface/MM_Interface; allocateSpace(Lcom/ibm/jikesrvm/memorymanagers/mminterface/SelectedMutatorContext;IIIII)Lorg/vmmagic/unboxed/Address; at line 673 Lcom/ibm/jikesrvm/memorymanagers/mminterface/MM_Interface; allocateArray(III[Ljava/lang/Object;IIII)Ljava/lang/Object; at line 643 Lcom/ibm/jikesrvm/VM_Runtime; resolvedNewArray(III[Ljava/lang/Object;IIII)Ljava/lang/Object; at line 444 Ljava/lang/String; toCharArray()[C at line 1633 Lcom/ibm/jikesrvm/jni/VM_JNIFunctions; GetStringChars(Lcom/ibm/jikesrvm/jni/VM_JNIEnvironment;ILorg/vmmagic/unboxed/Address;)Lorg/vmmagic/unboxed/Address; at line 3769 <native frame> <native frame> Lcom/ibm/jikesrvm/VM_Process; exec4(Ljava/lang/String;[Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;)I Lcom/ibm/jikesrvm/VM_Process; <init>(Ljava/lang/String;[Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;)V at line 60 Ljava/lang/VMRuntime; exec([Ljava/lang/String;[Ljava/lang/String;Ljava/io/File;)Ljava/lang/Process; at line 123 Ljava/lang/Runtime; exec([Ljava/lang/String;[Ljava/lang/String;Ljava/io/File;)Ljava/lang/Process; at line 553 Ljava/lang/Runtime; exec([Ljava/lang/String;)Ljava/lang/Process; at line 505 Lorg/eclipse/jdt/internal/launching/StandardVMType; generateLibraryInfo(Ljava/io/File;Ljava/io/File;)Lorg/eclipse/jdt/internal/launching/LibraryInfo; at line 468 Lorg/eclipse/jdt/internal/launching/StandardVMType; getLibraryInfo(Ljava/io/File;Ljava/io/File;)Lorg/eclipse/jdt/internal/launching/LibraryInfo; at line 119 Lorg/eclipse/jdt/internal/launching/StandardVMType; getDefaultLibraryLocations(Ljava/io/File;)[Lorg/eclipse/jdt/launching/LibraryLocation; at line 264 Lorg/eclipse/jdt/internal/launching/StandardVMType; canDetectDefaultSystemLibraries(Ljava/io/File;Ljava/io/File;)Z at line 137 Lorg/eclipse/jdt/internal/launching/StandardVMType; validateInstallLocation(Ljava/io/File;)Lorg/eclipse/core/runtime/IStatus; at line 434 Ldacapo/eclipse/HarnessRunner; validJavaHome()Z at line 38 Ldacapo/eclipse/HarnessRunner; run(Ljava/lang/Object;)Ljava/lang/Object; at line 19 Lorg/eclipse/core/internal/runtime/PlatformActivator$1; run(Ljava/lang/Object;)Ljava/lang/Object; at line 226 Lorg/eclipse/core/runtime/adaptor/EclipseStarter; run(Ljava/lang/Object;)Ljava/lang/Object; at line 376 Ldacapo/eclipse/EclipseHarness; iterate(Ljava/lang/String;)V at line 35 Ldacapo/Benchmark; run(Ldacapo/Callback;Ljava/lang/String;Z)Z at line 121 Ldacapo/TestHarness; runBenchmark(Ljava/io/File;Ljava/lang/String;Ldacapo/TestHarness;)V at line 263 Ldacapo/TestHarness; main([Ljava/lang/String;)V at line 203 LHarness; main([Ljava/lang/String;)V at line 5 <invisible method> Lcom/ibm/jikesrvm/VM_Reflection; invoke(Lcom/ibm/jikesrvm/classloader/VM_Method;Ljava/lang/Object;[Ljava/lang/Object;Z)Ljava/lang/Object; at line 125 Lcom/ibm/jikesrvm/MainThread; run()V at line 200 Lcom/ibm/jikesrvm/VM_Thread; run()V at line 205 Lcom/ibm/jikesrvm/VM_Thread; startoff()V at line 786 VM_ScanStack: Detected bad GC map; exiting RVM with fatal error -- Stack -- Lcom/ibm/jikesrvm/VM; sysFail(Ljava/lang/String;)V at line 1068 Lcom/ibm/jikesrvm/mm/mmtk/ScanThread; checkReference(Lorg/vmmagic/unboxed/Address;I)V at line 626 Lcom/ibm/jikesrvm/mm/mmtk/ScanThread; scanFrameForObjects(I)V at line 408 Lcom/ibm/jikesrvm/mm/mmtk/ScanThread; scanFrame(I)Lorg/vmmagic/unboxed/Address; at line 329 Lcom/ibm/jikesrvm/mm/mmtk/ScanThread; scanThreadInternal(Lorg/vmmagic/unboxed/Address;I)V at line 244 Lcom/ibm/jikesrvm/mm/mmtk/ScanThread; startScan(Lorg/mmtk/plan/TraceLocal;ZLcom/ibm/jikesrvm/VM_Thread;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V at line 204 Lcom/ibm/jikesrvm/mm/mmtk/ScanThread; scanThread(Lcom/ibm/jikesrvm/VM_Thread;Lorg/mmtk/plan/TraceLocal;ZLorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V at line 170 Lcom/ibm/jikesrvm/mm/mmtk/ScanThread; scanThread(Lcom/ibm/jikesrvm/VM_Thread;Lorg/mmtk/plan/TraceLocal;Z)V at line 135 Lcom/ibm/jikesrvm/mm/mmtk/Scanning; computeAllRoots(Lorg/mmtk/plan/TraceLocal;)V at line 210 Lorg/mmtk/plan/StopTheWorldCollector; collectionPhase(IZ)V at line 89 Lorg/mmtk/plan/semispace/SSCollector; collectionPhase(IZ)V at line 154 Lorg/mmtk/plan/SimplePhase; delegatePhase()V at line 127 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 159 Lorg/mmtk/plan/Phase; delegatePhase(I)V at line 145 Lorg/mmtk/plan/ComplexPhase; delegatePhase()V at line 100 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 159 Lorg/mmtk/plan/Phase; delegatePhase(I)V at line 145 Lorg/mmtk/plan/ComplexPhase; delegatePhase()V at line 100 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 159 Lorg/mmtk/plan/StopTheWorldCollector; collect()V at line 59 Lcom/ibm/jikesrvm/memorymanagers/mminterface/VM_CollectorThread; run()V at line 346 Lcom/ibm/jikesrvm/VM_Thread; startoff()V at line 786 steveb@woodchuck:~$ ---------------------------------------------------------------------- >Comment By: Peter Donald (peter_donald) Date: 2007-05-23 11:08 Message: Logged In: YES user_id=1642927 Originator: NO Closing this bug as it is describing a symptom that is likely to be caused by the same bug as "[ 1723869 ] VM_OptMachineCodeMap.generateMCInformation bad gcmap" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1596724&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 01:06:34
|
Bugs item #1601591, was opened at 2006-11-23 19:23 Message generated for change (Comment added) made by peter_donald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1601591&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: optimizing compiler Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Peter Donald (peter_donald) >Assigned to: Peter Donald (peter_donald) Summary: NPE in ObjectModel.copy Initial Comment: The following exception occurs after optimization is turned on. I am not sure where this bug is located. Attached is the output from one regression test. Exception in thread "MM_CollectorThread": java.lang.NullPointerException at java.lang.Throwable.fillInStackTrace(Throwable.java:107) at java.lang.Throwable.<init>(Throwable.java:51) at java.lang.Exception.<init>(Exception.java:67) at java.lang.RuntimeException.<init>(RuntimeException.java:65) at java.lang.NullPointerException.<init>(NullPointerException.java:70) at com.ibm.jikesrvm.VM_Runtime.deliverHardwareException(VM_Runtime.java:648) at <hardware trap> at com.ibm.jikesrvm.mm.mmtk.ObjectModel.copy(ObjectModel.java:61) at org.mmtk.policy.CopySpace.traceObject(CopySpace.java:266) at org.mmtk.plan.generational.GenMatureTraceLocal.traceObject(GenMatureTraceLocal.java:110) at org.mmtk.plan.generational.marksweep.GenMSMatureTraceLocal.traceObject(GenMSMatureTraceLocal.java:61) at org.mmtk.plan.TraceLocal.traceObject(TraceLocal.java:286) at org.mmtk.plan.TraceLocal.traceObjectLocation(TraceLocal.java:91) at org.mmtk.plan.TraceLocal.traceObjectLocation(TraceLocal.java:106) at org.mmtk.utility.scan.Scan.scanObject(Scan.java:45) at org.mmtk.plan.TraceLocal.scanObject(TraceLocal.java:151) at org.mmtk.plan.TraceLocal.completeTrace(TraceLocal.java:472) at org.mmtk.plan.TraceLocal.startTrace(TraceLocal.java:458) at org.mmtk.plan.generational.marksweep.GenMSCollector.collectionPhase(GenMSCollector.java:135) at org.mmtk.plan.SimplePhase.delegatePhase(SimplePhase.java:127) at org.mmtk.plan.Phase.delegatePhase(Phase.java:159) at org.mmtk.plan.Phase.delegatePhase(Phase.java:145) at org.mmtk.plan.ComplexPhase.delegatePhase(ComplexPhase.java:100) at org.mmtk.plan.Phase.delegatePhase(Phase.java:159) at org.mmtk.plan.Phase.delegatePhase(Phase.java:145) at org.mmtk.plan.ComplexPhase.delegatePhase(ComplexPhase.java:100) at org.mmtk.plan.Phase.delegatePhase(Phase.java:159) at org.mmtk.plan.StopTheWorldCollector.collect(StopTheWorldCollector.java:59) at com.ibm.jikesrvm.memorymanagers.mminterface.MM_CollectorThread.run(MM_CollectorThread.java:326) ---------------------------------------------------------------------- >Comment By: Peter Donald (peter_donald) Date: 2007-05-23 11:06 Message: Logged In: YES user_id=1642927 Originator: YES Bug description too vague and actually describing a symptom of a bad gc map rather than actual bug itself. CLosing now that we can more accurately track down original gc map problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1601591&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 01:04:09
|
Bugs item #1601594, was opened at 2006-11-23 19:30 Message generated for change (Comment added) made by peter_donald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1601594&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Peter Donald (peter_donald) >Assigned to: Peter Donald (peter_donald) Summary: Bad GC map at higher level optimizations Initial Comment: It seems there is more issues with the integration between the optimizing compiler and the GC system. The following is an example of an exception that I get relatively often. I have attached output of one of the harnesses that produces this problem. Dumping stack starting at frame with bad ref: -- Stack -- Ljava/util/logging/LogManager; readConfiguration(Ljava/io/InputStream;)V at line 551 Ljava/util/logging/LogManager; readConfiguration()V at line 532 Ljava/util/logging/LogManager; initLogManager()V at line 203 Ljava/util/logging/LogManager; getLogManager()Ljava/util/logging/LogManager; at line 168 Ljava/util/logging/Logger; getLogger(Ljava/lang/String;Ljava/lang/String;)Ljava/util/logging/Logger; at line 276 Ljava/util/logging/Logger; getLogger(Ljava/lang/String;)Ljava/util/logging/Logger; at line 224 Ljava/util/logging/Logger$1; run()Ljava/lang/Object; at line 91 Ljava/security/AccessController; doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object; at line 96 Ljava/util/logging/Logger; <clinit>()V at line 86 Lcom/ibm/jikesrvm/classloader/VM_Class; initialize()V at line 1852 Lcom/ibm/jikesrvm/VM_Runtime; initializeClassForDynamicLink(Lcom/ibm/jikesrvm/classloader/VM_Class;)V at line 541 Lcom/ibm/jikesrvm/classloader/VM_TableBasedDynamicLinker; resolveMember(Lcom/ibm/jikesrvm/classloader/VM_MemberReference;)I at line 65 Lcom/ibm/jikesrvm/classloader/VM_TableBasedDynamicLinker; resolveMember(I)I at line 54 Lgnu/java/util/jar/JarUtils; <clinit>()V at line 65 Lcom/ibm/jikesrvm/classloader/VM_Class; initialize()V at line 1852 Lcom/ibm/jikesrvm/VM_Runtime; initializeClassForDynamicLink(Lcom/ibm/jikesrvm/classloader/VM_Class;)V at line 541 Lcom/ibm/jikesrvm/classloader/VM_TableBasedDynamicLinker; resolveMember(Lcom/ibm/jikesrvm/classloader/VM_MemberReference;)I at line 65 Lcom/ibm/jikesrvm/opt/VM_OptLinker; resolveDynamicLink(Lcom/ibm/jikesrvm/opt/VM_OptCompiledMethod;Lorg/vmmagic/unboxed/Offset;)V at line 54 Lcom/ibm/jikesrvm/opt/VM_OptSaveVolatile; OPT_resolve()V at line 113 Ljava/util/jar/Manifest; read(Ljava/io/InputStream;)V at line 162 Ljava/util/jar/Manifest; <init>(Ljava/io/InputStream;)V at line 89 Ljava/util/jar/JarFile; readManifest()Ljava/util/jar/Manifest; at line 295 Ljava/util/jar/JarFile; <init>(Ljava/io/File;ZI)V at line 260 Lgnu/java/net/protocol/jar/Connection$JarFileCache; get(Ljava/net/URL;Z)Ljava/util/jar/JarFile; at line 98 Lgnu/java/net/protocol/jar/Connection; connect()V at line 140 Lgnu/java/net/protocol/jar/Connection; getJarFile()Ljava/util/jar/JarFile; at line 169 Lgnu/java/net/loader/JarURLLoader; initialize()V at line 84 Lgnu/java/net/loader/JarURLLoader; <init>(Ljava/net/URLClassLoader;Lgnu/java/net/loader/URLStreamHandlerCache;Ljava/net/URLStreamHandlerFactory;Ljava/net/URL;Ljava/net/URL;)V at line 76 Ljava/net/URLClassLoader; addURLImpl(Ljava/net/URL;)V at line 387 Ljava/net/URLClassLoader; addURL(Ljava/net/URL;)V at line 280 Lcom/ibm/jikesrvm/classloader/ApplicationClassLoader; <init>(Ljava/lang/String;)V at line 81 Lcom/ibm/jikesrvm/classloader/VM_ClassLoader; getApplicationClassLoader()Ljava/lang/ClassLoader; at line 124 Ljava/lang/VMClassLoader; getSystemClassLoader()Ljava/lang/ClassLoader; at line 285 Ljava/lang/ClassLoader$StaticData; <clinit>()V at line 154 Lcom/ibm/jikesrvm/VM; runClassInitializer(Ljava/lang/String;)V at line 496 Lcom/ibm/jikesrvm/VM; finishBooting()V at line 403 Lcom/ibm/jikesrvm/VM; boot()V at line 114 -- Stack -- Lcom/ibm/jikesrvm/VM_Processor; dispatch(Z)V at line 219 Lcom/ibm/jikesrvm/VM_Thread; morph(Z)V at line 721 Lcom/ibm/jikesrvm/VM_Thread; yield()V at line 617 Lcom/ibm/jikesrvm/memorymanagers/mminterface/VM_Handshake; requestAndAwaitCompletion(I)V at line 77 Lcom/ibm/jikesrvm/memorymanagers/mminterface/MM_CollectorThread; collect(Lcom/ibm/jikesrvm/memorymanagers/mminterface/VM_Handshake;I)V at line 228 Lcom/ibm/jikesrvm/mm/mmtk/Collection; triggerCollectionStatic(I)V at line 141 Lcom/ibm/jikesrvm/mm/mmtk/Collection; triggerCollection(I)V at line 121 Lorg/mmtk/plan/generational/Gen; poll(ZLorg/mmtk/policy/Space;)Z at line 226 Lorg/mmtk/policy/Space; acquire(I)Lorg/vmmagic/unboxed/Address; at line 454 Lorg/mmtk/utility/alloc/BumpPointer; allocSlowOnce(IIIZ)Lorg/vmmagic/unboxed/Address; at line 268 Lorg/mmtk/utility/alloc/Allocator; allocSlowInline(IIIZ)Lorg/vmmagic/unboxed/Address; at line 256 Lorg/mmtk/utility/alloc/BumpPointer; allocSlow(Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;IIZ)Lorg/vmmagic/unboxed/Address; at line 179 Lorg/mmtk/utility/alloc/BumpPointer; alloc(IIIZ)Lorg/vmmagic/unboxed/Address; at line 152 Lorg/mmtk/plan/generational/GenMutator; alloc(IIIII)Lorg/vmmagic/unboxed/Address; at line 94 Lorg/mmtk/plan/generational/marksweep/GenMSMutator; alloc(IIIII)Lorg/vmmagic/unboxed/Address; at line 95 Lcom/ibm/jikesrvm/memorymanagers/mminterface/MM_Interface; allocateSpace(Lcom/ibm/jikesrvm/memorymanagers/mminterface/Selected$Mutator;IIIII)Lorg/vmmagic/unboxed/Address; at line 654 Lcom/ibm/jikesrvm/memorymanagers/mminterface/MM_Interface; allocateScalar(I[Ljava/lang/Object;IIII)Ljava/lang/Object; at line 587 Lcom/ibm/jikesrvm/VM_Runtime; resolvedNewScalar(I[Ljava/lang/Object;ZIIII)Ljava/lang/Object; at line 352 Lcom/ibm/jikesrvm/opt/ir/OPT_BasicBlock; getOut()Lcom/ibm/jikesrvm/opt/ir/OPT_BasicBlock$OutEdgeEnum; at line 1764 Lcom/ibm/jikesrvm/opt/OPT_LTDominators; getNextNodes(Lcom/ibm/jikesrvm/opt/ir/OPT_BasicBlock;)Lcom/ibm/jikesrvm/opt/ir/OPT_BasicBlockEnumeration; at line 219 Lcom/ibm/jikesrvm/opt/OPT_LTDominators; DFS(Lcom/ibm/jikesrvm/opt/ir/OPT_BasicBlock;)V at line 283 Lcom/ibm/jikesrvm/opt/OPT_LTDominators; DFS()V at line 177 Lcom/ibm/jikesrvm/opt/OPT_LTDominators; step1()V at line 168 Lcom/ibm/jikesrvm/opt/OPT_LTDominators; analyze(Lcom/ibm/jikesrvm/opt/ir/OPT_IR;)V at line 108 Lcom/ibm/jikesrvm/opt/OPT_LTDominators; perform(Lcom/ibm/jikesrvm/opt/ir/OPT_IR;ZZ)V at line 71 Lcom/ibm/jikesrvm/opt/OPT_DominatorsPhase; perform(Lcom/ibm/jikesrvm/opt/ir/OPT_IR;)V at line 87 Lcom/ibm/jikesrvm/opt/OPT_CompilerPhase; performPhase(Lcom/ibm/jikesrvm/opt/ir/OPT_IR;)V at line 207 Lcom/ibm/jikesrvm/opt/OPT_OptimizationPlanAtomicElement; perform(Lcom/ibm/jikesrvm/opt/ir/OPT_IR;)V at line 87 Lcom/ibm/jikesrvm/opt/OPT_OptimizationPlanCompositeElement; perform(Lcom/ibm/jikesrvm/opt/ir/OPT_IR;)V at line 146 Lcom/ibm/jikesrvm/opt/OPT_OptimizationPlanCompositeElement; perform(Lcom/ibm/jikesrvm/opt/ir/OPT_IR;)V at line 146 Lcom/ibm/jikesrvm/opt/OPT_CompilationPlan; execute()Lcom/ibm/jikesrvm/opt/ir/OPT_IR; at line 110 Lcom/ibm/jikesrvm/opt/OPT_Compiler; compile(Lcom/ibm/jikesrvm/opt/OPT_CompilationPlan;)Lcom/ibm/jikesrvm/VM_CompiledMethod; at line 219 Lcom/ibm/jikesrvm/VM_RuntimeCompiler; optCompile(Lcom/ibm/jikesrvm/classloader/VM_NormalMethod;Lcom/ibm/jikesrvm/opt/OPT_CompilationPlan;)Lcom/ibm/jikesrvm/VM_CompiledMethod; at line 382 Lcom/ibm/jikesrvm/VM_RuntimeCompiler; optCompileWithFallBackInternal(Lcom/ibm/jikesrvm/classloader/VM_NormalMethod;Lcom/ibm/jikesrvm/opt/OPT_CompilationPlan;)Lcom/ibm/jikesrvm/VM_CompiledMethod; at line 453 Lcom/ibm/jikesrvm/VM_RuntimeCompiler; optCompileWithFallBack(Lcom/ibm/jikesrvm/classloader/VM_NormalMethod;Lcom/ibm/jikesrvm/opt/OPT_CompilationPlan;)Lcom/ibm/jikesrvm/VM_CompiledMethod; at line 437 Lcom/ibm/jikesrvm/VM_RuntimeCompiler; compile(Lcom/ibm/jikesrvm/classloader/VM_NormalMethod;)Lcom/ibm/jikesrvm/VM_CompiledMethod; at line 817 Lcom/ibm/jikesrvm/classloader/VM_NormalMethod; genCode()Lcom/ibm/jikesrvm/VM_CompiledMethod; at line 193 Lcom/ibm/jikesrvm/classloader/VM_Method; compile()V at line 612 Lcom/ibm/jikesrvm/VM_DynamicLinker$DL_Helper; compileMethod(Lcom/ibm/jikesrvm/VM_DynamicLink;Lcom/ibm/jikesrvm/classloader/VM_Method;)V at line 128 Lcom/ibm/jikesrvm/VM_DynamicLinker; lazyMethodInvoker()V at line 35 Ljava/util/logging/Logger; resetLogger()V at line 1221 Ljava/util/logging/LogManager; reset()V at line 474 Ljava/util/logging/LogManager; readConfiguration(Ljava/io/InputStream;)V at line 551 Ljava/util/logging/LogManager; readConfiguration()V at line 532 Ljava/util/logging/LogManager; initLogManager()V at line 203 Ljava/util/logging/LogManager; getLogManager()Ljava/util/logging/LogManager; at line 168 Ljava/util/logging/Logger; getLogger(Ljava/lang/String;Ljava/lang/String;)Ljava/util/logging/Logger; at line 276 Ljava/util/logging/Logger; getLogger(Ljava/lang/String;)Ljava/util/logging/Logger; at line 224 Ljava/util/logging/Logger$1; run()Ljava/lang/Object; at line 91 Ljava/security/AccessController; doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object; at line 96 Ljava/util/logging/Logger; <clinit>()V at line 86 Lcom/ibm/jikesrvm/classloader/VM_Class; initialize()V at line 1852 Lcom/ibm/jikesrvm/VM_Runtime; initializeClassForDynamicLink(Lcom/ibm/jikesrvm/classloader/VM_Class;)V at line 541 Lcom/ibm/jikesrvm/classloader/VM_TableBasedDynamicLinker; resolveMember(Lcom/ibm/jikesrvm/classloader/VM_MemberReference;)I at line 65 Lcom/ibm/jikesrvm/classloader/VM_TableBasedDynamicLinker; resolveMember(I)I at line 54 Lgnu/java/util/jar/JarUtils; <clinit>()V at line 65 Lcom/ibm/jikesrvm/classloader/VM_Class; initialize()V at line 1852 Lcom/ibm/jikesrvm/VM_Runtime; initializeClassForDynamicLink(Lcom/ibm/jikesrvm/classloader/VM_Class;)V at line 541 Lcom/ibm/jikesrvm/classloader/VM_TableBasedDynamicLinker; resolveMember(Lcom/ibm/jikesrvm/classloader/VM_MemberReference;)I at line 65 Lcom/ibm/jikesrvm/opt/VM_OptLinker; resolveDynamicLink(Lcom/ibm/jikesrvm/opt/VM_OptCompiledMethod;Lorg/vmmagic/unboxed/Offset;)V at line 54 Lcom/ibm/jikesrvm/opt/VM_OptSaveVolatile; OPT_resolve()V at line 113 Ljava/util/jar/Manifest; read(Ljava/io/InputStream;)V at line 162 Ljava/util/jar/Manifest; <init>(Ljava/io/InputStream;)V at line 89 Ljava/util/jar/JarFile; readManifest()Ljava/util/jar/Manifest; at line 295 Ljava/util/jar/JarFile; <init>(Ljava/io/File;ZI)V at line 260 Lgnu/java/net/protocol/jar/Connection$JarFileCache; get(Ljava/net/URL;Z)Ljava/util/jar/JarFile; at line 98 Lgnu/java/net/protocol/jar/Connection; connect()V at line 140 Lgnu/java/net/protocol/jar/Connection; getJarFile()Ljava/util/jar/JarFile; at line 169 Lgnu/java/net/loader/JarURLLoader; initialize()V at line 84 Lgnu/java/net/loader/JarURLLoader; <init>(Ljava/net/URLClassLoader;Lgnu/java/net/loader/URLStreamHandlerCache;Ljava/net/URLStreamHandlerFactory;Ljava/net/URL;Ljava/net/URL;)V at line 76 Ljava/net/URLClassLoader; addURLImpl(Ljava/net/URL;)V at line 387 Ljava/net/URLClassLoader; addURL(Ljava/net/URL;)V at line 280 Lcom/ibm/jikesrvm/classloader/ApplicationClassLoader; <init>(Ljava/lang/String;)V at line 81 Lcom/ibm/jikesrvm/classloader/VM_ClassLoader; getApplicationClassLoader()Ljava/lang/ClassLoader; at line 124 Ljava/lang/VMClassLoader; getSystemClassLoader()Ljava/lang/ClassLoader; at line 285 Ljava/lang/ClassLoader$StaticData; <clinit>()V at line 154 Lcom/ibm/jikesrvm/VM; runClassInitializer(Ljava/lang/String;)V at line 496 Lcom/ibm/jikesrvm/VM; finishBooting()V at line 403 Lcom/ibm/jikesrvm/VM; boot()V at line 114 VM_ScanStack: Detected bad GC map; exiting RVM with fatal error -- Stack -- Lcom/ibm/jikesrvm/mm/mmtk/ScanThread; checkReference(Lorg/vmmagic/unboxed/Address;I)V at line 621 Lcom/ibm/jikesrvm/mm/mmtk/ScanThread; scanFrameForObjects(I)V at line 403 Lcom/ibm/jikesrvm/mm/mmtk/ScanThread; scanFrame(I)Lorg/vmmagic/unboxed/Address; at line 324 Lcom/ibm/jikesrvm/mm/mmtk/ScanThread; scanThreadInternal(Lorg/vmmagic/unboxed/Address;I)V at line 239 Lcom/ibm/jikesrvm/mm/mmtk/ScanThread; startScan(Lorg/mmtk/plan/TraceLocal;ZLcom/ibm/jikesrvm/VM_Thread;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V at line 199 Lcom/ibm/jikesrvm/mm/mmtk/ScanThread; scanThread(Lcom/ibm/jikesrvm/VM_Thread;Lorg/mmtk/plan/TraceLocal;ZLorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V at line 165 Lcom/ibm/jikesrvm/mm/mmtk/ScanThread; scanThread(Lcom/ibm/jikesrvm/VM_Thread;Lorg/mmtk/plan/TraceLocal;Z)V at line 130 Lcom/ibm/jikesrvm/mm/mmtk/Scanning; computeAllRoots(Lorg/mmtk/plan/TraceLocal;)V at line 209 Lorg/mmtk/plan/StopTheWorldCollector; collectionPhase(IZ)V at line 89 Lorg/mmtk/plan/generational/GenCollector; collectionPhase(IZ)V at line 128 Lorg/mmtk/plan/generational/marksweep/GenMSCollector; collectionPhase(IZ)V at line 155 Lorg/mmtk/plan/SimplePhase; delegatePhase()V at line 127 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 159 Lorg/mmtk/plan/Phase; delegatePhase(I)V at line 145 Lorg/mmtk/plan/ComplexPhase; delegatePhase()V at line 100 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 159 Lorg/mmtk/plan/Phase; delegatePhase(I)V at line 145 Lorg/mmtk/plan/ComplexPhase; delegatePhase()V at line 100 Lorg/mmtk/plan/Phase; delegatePhase(Lorg/mmtk/plan/Phase;)V at line 159 Lorg/mmtk/plan/StopTheWorldCollector; collect()V at line 59 Lcom/ibm/jikesrvm/memorymanagers/mminterface/MM_CollectorThread; run()V at line 326 Lcom/ibm/jikesrvm/VM_Thread; startoff()V at line 765 ---------------------------------------------------------------------- >Comment By: Peter Donald (peter_donald) Date: 2007-05-23 11:04 Message: Logged In: YES user_id=1642927 Originator: YES Report too vague and we have tools to track this down to exact method that caused issue now so closing issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1601594&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 01:01:45
|
Bugs item #1638237, was opened at 2007-01-18 14:31 Message generated for change (Comment added) made by peter_donald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1638237&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Peter Donald (peter_donald) >Assigned to: Peter Donald (peter_donald) Summary: getInstructionOffset: ip is not within compiled code for ... Initial Comment: Error introduced somewhere in the last month or so. ---------------------------------------------------------------------- >Comment By: Peter Donald (peter_donald) Date: 2007-05-23 11:01 Message: Logged In: YES user_id=1642927 Originator: YES Report to vague and issue does not appear to be reproduce in latest run. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1638237&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 01:00:22
|
Bugs item #1603387, was opened at 2006-11-27 09:18 Message generated for change (Comment added) made by peter_donald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1603387&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Peter Donald (peter_donald) >Assigned to: Peter Donald (peter_donald) Summary: GC Warning: Barrier wait has reached Initial Comment: The GC system seems to get into this state in various different profiles. Howevever the result is not deterministic and can be difficult to reproduce. out.Harness.prototype.2proc.xalan.raw: ===== DaCapo xalan starting ===== GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 3.03 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 GC Warning: Barrier wait has reached 6.07 seconds. Called from 3009. myOrder = 0 count is 1 waiting for 2 ---------------------------------------------------------------------- >Comment By: Peter Donald (peter_donald) Date: 2007-05-23 11:00 Message: Logged In: YES user_id=1642927 Originator: YES Closi9ng bug as too vague. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1603387&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 00:58:40
|
Bugs item #1673581, was opened at 2007-03-05 06:50 Message generated for change (Settings changed) made by peter_donald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1673581&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: regression tests Group: None >Status: Closed >Resolution: Fixed Priority: 3 Private: No Submitted By: Dave Grove (dgrove-oss) >Assigned to: Peter Donald (peter_donald) Summary: SPECmark computation in new test scripts Initial Comment: It looks like the computation of the summary metric for SPECjvm98 in the new testing scripts is wrong (unless we speedup by 4x :)). One takes the raw time for each benchmark, use it to divide a reference time to get a score, then takes the geo-mean of the scores to get the final SPECmark. As a reference point, I've attached the old scripts we used to do this computation. ---------------------------------------------------------------------- Comment By: Dave Grove (dgrove-oss) Date: 2007-03-29 04:41 Message: Logged In: YES user_id=1215435 Originator: YES computation looks like it might be ok now. I'll take a look. Also testing issues mailing list :) ---------------------------------------------------------------------- Comment By: Peter Donald (peter_donald) Date: 2007-03-05 13:11 Message: Logged In: YES user_id=1642927 Originator: NO It seems like we were not running the performance tests - instead we were measuring the time for non performance run. Change r11708 may have fixed this as it makes sure performance run occurs. (FWIW we use specmark.reference and parseSPECmark in the new system aswell). ---------------------------------------------------------------------- Comment By: Dave Grove (dgrove-oss) Date: 2007-03-05 06:50 Message: Logged In: YES user_id=1215435 Originator: YES File Added: specmark.reference ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1673581&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 00:57:49
|
Bugs item #1685890, was opened at 2007-03-22 22:06 Message generated for change (Comment added) made by peter_donald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1685890&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: regression tests Group: None >Status: Closed >Resolution: Out of Date Priority: 2 Private: No Submitted By: Dave Grove (dgrove-oss) Assigned to: Nobody/Anonymous (nobody) Summary: regression summary email body not showing in archive Initial Comment: I noticed that the body of the html-based regression summary email doesn't show in the list archives. For example: https://sourceforge.net/mailarchive/forum.php?thread_id=31809329&forum_id=43938 Looking at an older email, https://sourceforge.net/mailarchive/forum.php?thread_id=31327227&forum_id=43938 This seems to be a problem with the html email itself, not something introduced by switching to the ant-based build/test system. Not sure if this is happening because the of something in the mail itself, something in how the mailing list is setup in mailman, or in how SF is archiving the email. May not be incredibly important since we could archive ourselves (along with the failure details) at a regression website, but it might be nice to have them at the SF archive as well. ---------------------------------------------------------------------- >Comment By: Peter Donald (peter_donald) Date: 2007-05-23 10:57 Message: Logged In: YES user_id=1642927 Originator: NO It appears fine in the nabble archives which is where we point our website at so I am going to close this issue ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1685890&group_id=128805 |
From: SourceForge.net <no...@so...> - 2007-05-23 00:43:09
|
Bugs item #1723869, was opened at 2007-05-23 10:28 Message generated for change (Comment added) made by peter_donald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1723869&group_id=128805 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: optimizing compiler Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Peter Donald (peter_donald) Assigned to: Nobody/Anonymous (nobody) Summary: VM_OptMachineCodeMap.generateMCInformation bad gcmap Initial Comment: The method VM_OptMachineCodeMap.generateMCInformation seems to produce and invalid gc map at O2 level optimization. Note: This is after r12223 where a few of explicit optimizations where moved from O1 to O2 To reproduce you can change the value of "config.bootimage.compiler.args" in "build/configs/gcstress.properties" from "-X:bc:O1" to "-X:bc:O2" and then run the gcmap-sanity test run via something like ant -f test.xml -Dtest-run.name=gcmap-sanity Tests will start failing with output like validRef: TIB outside heap, ref = 0x9d800a24 tib = 0x00000000 Invalid ref reported while scanning stack --- METHOD (OPT) Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap;.generateMCInformation (Lorg/jikesrvm/compilers/opt/ir/OPT_GCIRMap;)Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap; --- fp = 0x6b29fcc4 code base = 0x5b8c1ef4 code offset = 0x00003243 0x6dc2fbf4:REF=0x9d800a24 TIB=0x00000000 STATUS=0x00000000 (INVALID TIB: CLASS NOT ACCESSIBLE) ... Dumping stack starting at frame with bad ref: -- Stack -- Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap; generateMCInformation(Lorg/jikesrvm/compilers/opt/ir/OPT_GCIRMap;)Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap; at line 398 Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap; create(Lorg/jikesrvm/compilers/opt/ir/OPT_IR;I)Lorg/jikesrvm/compilers/opt/VM_OptMachineCodeMap; at line 99 Lorg/jikesrvm/compilers/opt/VM_OptCompiledMethod; createFinalMCMap(Lorg/jikesrvm/compilers/opt/ir/OPT_IR;I)V at line 438 ... There are a number of sample failures attached. ---------------------------------------------------------------------- >Comment By: Peter Donald (peter_donald) Date: 2007-05-23 10:43 Message: Logged In: YES user_id=1642927 Originator: YES Note that 398 seems to be the earliest line number where the bug is expressed. ---------------------------------------------------------------------- Comment By: Peter Donald (peter_donald) Date: 2007-05-23 10:38 Message: Logged In: YES user_id=1642927 Originator: YES File Added: jBYTEmark-output.txt ---------------------------------------------------------------------- Comment By: Peter Donald (peter_donald) Date: 2007-05-23 10:35 Message: Logged In: YES user_id=1642927 Originator: YES File Added: JLex.Main-trimmed.txt.gz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=712768&aid=1723869&group_id=128805 |