JDK 9 RFR of JDK-8161567: Mark java/util/concurrent/forkjoin/FJExceptionTableLeak.java as intermittently failing

[Martin Buchholz]

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 at 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 at 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
>>>>   */
>>>>
>>>>
>>>>
>>>>
>