JDK 9 RFR of JDK-8161567: Mark java/util/concurrent/forkjoin/FJExceptionTableLeak.java as intermittently failing
java/util/concurrent/forkjoin/FJExceptionTableLeak.java Test was ever fixed in JDK-8144990, but still failing intermittently as reported in JDK-8151158. This patch is to add back @key intermittent to the test. (and keep it in tier2 till issue resolved.) Please review. bug: https://bugs.openjdk.java.net/browse/JDK-8161567 webrev: http://cr.openjdk.java.net/~amlu/8161567/webrev.00/ Thanks, Amy --- old/test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java 2016-07-18 14:37:25.000000000 +0800 +++ new/test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java 2016-07-18 14:37:25.000000000 +0800 @@ -35,6 +35,7 @@ * @test * @author Doug Lea * @bug 8004138 + * @key intermittent * @summary Check if ForkJoinPool table leaks thrown exceptions. * @run main/othervm -Xmx8m -Djava.util.concurrent.ForkJoinPool.common.parallelism=4 FJExceptionTableLeak */
Like I always say, I'm unhappy with the increased memory requirements. Java programs that used to run in 4m now need more than 8m. Hotspot should be fixed! If this is dependent on the particular GC, maybe there's a way to require not having that gc. I see: ./java/lang/management/MemoryMXBean/LowMemoryTest2.sh:28:# @requires vm.gc=="null" ./java/lang/management/MemoryMXBean/PendingAllGC.sh:29:# @requires vm.gc=="null" ./java/lang/management/MemoryMXBean/MemoryManagementConcMarkSweepGC.sh:29:# @requires vm.gc=="ConcMarkSweep" | vm.gc=="null" ./java/lang/management/MemoryMXBean/MemoryTestAllGC.sh:29:# @requires vm.gc=="Parallel" | vm.gc=="null" ./java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh:29:# @requires vm.gc=="Parallel" | vm.gc=="null" ./java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh:29:# @requires vm.gc=="Serial" | vm.gc=="null" Maybe we can make this test pass in a similar way. Bug reports should be clearer about which VM flags actually cause the failure. On Sun, Jul 17, 2016 at 11:46 PM, Amy Lu <amy.lu@oracle.com> wrote:
java/util/concurrent/forkjoin/FJExceptionTableLeak.java
Test was ever fixed in JDK-8144990, but still failing intermittently as reported in JDK-8151158.
This patch is to add back @key intermittent to the test. (and keep it in tier2 till issue resolved.) Please review.
bug: https://bugs.openjdk.java.net/browse/JDK-8161567 webrev: http://cr.openjdk.java.net/~amlu/8161567/webrev.00/
Thanks, Amy
--- old/test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java 2016-07-18 14:37:25.000000000 +0800 +++ new/test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java 2016-07-18 14:37:25.000000000 +0800 @@ -35,6 +35,7 @@ * @test * @author Doug Lea * @bug 8004138 + * @key intermittent * @summary Check if ForkJoinPool table leaks thrown exceptions. * @run main/othervm -Xmx8m -Djava.util.concurrent.ForkJoinPool.common.parallelism=4 FJExceptionTableLeak */
Hi Martin, On 19/07/2016 12:38 AM, Martin Buchholz wrote:
Like I always say, I'm unhappy with the increased memory requirements. Java programs that used to run in 4m now need more than 8m. Hotspot should be fixed!
I've updated the comments in https://bugs.openjdk.java.net/browse/JDK-8151158 I agree further investigation is needed in this case.
If this is dependent on the particular GC, maybe there's a way to require not having that gc.
GC algorithm itself should not be causing OOME. David -----
I see:
./java/lang/management/MemoryMXBean/LowMemoryTest2.sh:28:# @requires vm.gc=="null" ./java/lang/management/MemoryMXBean/PendingAllGC.sh:29:# @requires vm.gc=="null" ./java/lang/management/MemoryMXBean/MemoryManagementConcMarkSweepGC.sh:29:# @requires vm.gc=="ConcMarkSweep" | vm.gc=="null" ./java/lang/management/MemoryMXBean/MemoryTestAllGC.sh:29:# @requires vm.gc=="Parallel" | vm.gc=="null" ./java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh:29:# @requires vm.gc=="Parallel" | vm.gc=="null" ./java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh:29:# @requires vm.gc=="Serial" | vm.gc=="null"
Maybe we can make this test pass in a similar way.
Bug reports should be clearer about which VM flags actually cause the failure.
On Sun, Jul 17, 2016 at 11:46 PM, Amy Lu <amy.lu@oracle.com> wrote:
java/util/concurrent/forkjoin/FJExceptionTableLeak.java
Test was ever fixed in JDK-8144990, but still failing intermittently as reported in JDK-8151158.
This patch is to add back @key intermittent to the test. (and keep it in tier2 till issue resolved.) Please review.
bug: https://bugs.openjdk.java.net/browse/JDK-8161567 webrev: http://cr.openjdk.java.net/~amlu/8161567/webrev.00/
Thanks, Amy
--- old/test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java 2016-07-18 14:37:25.000000000 +0800 +++ new/test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java 2016-07-18 14:37:25.000000000 +0800 @@ -35,6 +35,7 @@ * @test * @author Doug Lea * @bug 8004138 + * @key intermittent * @summary Check if ForkJoinPool table leaks thrown exceptions. * @run main/othervm -Xmx8m -Djava.util.concurrent.ForkJoinPool.common.parallelism=4 FJExceptionTableLeak */
Hello, While the underlying issues are being investigated, I think it is worthwhile to tag the test as intermittently failing to aid those having to QA any if its failures. Cheers, -Joe On 7/18/2016 4:56 PM, David Holmes wrote:
Hi Martin,
On 19/07/2016 12:38 AM, Martin Buchholz wrote:
Like I always say, I'm unhappy with the increased memory requirements. Java programs that used to run in 4m now need more than 8m. Hotspot should be fixed!
I've updated the comments in
https://bugs.openjdk.java.net/browse/JDK-8151158
I agree further investigation is needed in this case.
If this is dependent on the particular GC, maybe there's a way to require not having that gc.
GC algorithm itself should not be causing OOME.
David -----
I see:
./java/lang/management/MemoryMXBean/LowMemoryTest2.sh:28:# @requires vm.gc=="null" ./java/lang/management/MemoryMXBean/PendingAllGC.sh:29:# @requires vm.gc=="null" ./java/lang/management/MemoryMXBean/MemoryManagementConcMarkSweepGC.sh:29:#
@requires vm.gc=="ConcMarkSweep" | vm.gc=="null" ./java/lang/management/MemoryMXBean/MemoryTestAllGC.sh:29:# @requires vm.gc=="Parallel" | vm.gc=="null" ./java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh:29:# @requires vm.gc=="Parallel" | vm.gc=="null" ./java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh:29:# @requires vm.gc=="Serial" | vm.gc=="null"
Maybe we can make this test pass in a similar way.
Bug reports should be clearer about which VM flags actually cause the failure.
On Sun, Jul 17, 2016 at 11:46 PM, Amy Lu <amy.lu@oracle.com> wrote:
java/util/concurrent/forkjoin/FJExceptionTableLeak.java
Test was ever fixed in JDK-8144990, but still failing intermittently as reported in JDK-8151158.
This patch is to add back @key intermittent to the test. (and keep it in tier2 till issue resolved.) Please review.
bug: https://bugs.openjdk.java.net/browse/JDK-8161567 webrev: http://cr.openjdk.java.net/~amlu/8161567/webrev.00/
Thanks, Amy
--- old/test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java 2016-07-18 14:37:25.000000000 +0800 +++ new/test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java 2016-07-18 14:37:25.000000000 +0800 @@ -35,6 +35,7 @@ * @test * @author Doug Lea * @bug 8004138 + * @key intermittent * @summary Check if ForkJoinPool table leaks thrown exceptions. * @run main/othervm -Xmx8m -Djava.util.concurrent.ForkJoinPool.common.parallelism=4 FJExceptionTableLeak */
Okay, we're all agreed. Amy can demote this test, and I'll try to think hard about how to improve the test, with my newfound insight. On Mon, Jul 18, 2016 at 5:00 PM, Joseph D. Darcy <joe.darcy@oracle.com> wrote:
Hello,
While the underlying issues are being investigated, I think it is worthwhile to tag the test as intermittently failing to aid those having to QA any if its failures.
Cheers,
-Joe
On 7/18/2016 4:56 PM, David Holmes wrote:
Hi Martin,
On 19/07/2016 12:38 AM, Martin Buchholz wrote:
Like I always say, I'm unhappy with the increased memory requirements. Java programs that used to run in 4m now need more than 8m. Hotspot should be fixed!
I've updated the comments in
https://bugs.openjdk.java.net/browse/JDK-8151158
I agree further investigation is needed in this case.
If this is dependent on the particular GC, maybe there's a way to require
not having that gc.
GC algorithm itself should not be causing OOME.
David -----
I see:
./java/lang/management/MemoryMXBean/LowMemoryTest2.sh:28:# @requires vm.gc=="null" ./java/lang/management/MemoryMXBean/PendingAllGC.sh:29:# @requires vm.gc=="null" ./java/lang/management/MemoryMXBean/MemoryManagementConcMarkSweepGC.sh:29:#
@requires vm.gc=="ConcMarkSweep" | vm.gc=="null" ./java/lang/management/MemoryMXBean/MemoryTestAllGC.sh:29:# @requires vm.gc=="Parallel" | vm.gc=="null" ./java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh:29:# @requires vm.gc=="Parallel" | vm.gc=="null" ./java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh:29:# @requires vm.gc=="Serial" | vm.gc=="null"
Maybe we can make this test pass in a similar way.
Bug reports should be clearer about which VM flags actually cause the failure.
On Sun, Jul 17, 2016 at 11:46 PM, Amy Lu <amy.lu@oracle.com> wrote:
java/util/concurrent/forkjoin/FJExceptionTableLeak.java
Test was ever fixed in JDK-8144990, but still failing intermittently as reported in JDK-8151158.
This patch is to add back @key intermittent to the test. (and keep it in tier2 till issue resolved.) Please review.
bug: https://bugs.openjdk.java.net/browse/JDK-8161567 webrev: http://cr.openjdk.java.net/~amlu/8161567/webrev.00/
Thanks, Amy
--- old/test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java 2016-07-18 14:37:25.000000000 +0800 +++ new/test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java 2016-07-18 14:37:25.000000000 +0800 @@ -35,6 +35,7 @@ * @test * @author Doug Lea * @bug 8004138 + * @key intermittent * @summary Check if ForkJoinPool table leaks thrown exceptions. * @run main/othervm -Xmx8m -Djava.util.concurrent.ForkJoinPool.common.parallelism=4 FJExceptionTableLeak */
participants (4)
-
Amy Lu
-
David Holmes
-
Joseph D. Darcy
-
Martin Buchholz