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.da...@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...@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 >>>> */ >>>> >>>> >>>> >>>> >
