Fwd: RFR: JDK-8249258 java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 15)

[David Holmes]

On 15/07/2020 5:35 am, Roger Riggs wrote:
> Looks good.
> 
> Though it does seem like the VM should have been able to reclaim enough 
> memory between tests to not need to throw OOME.

I'd have to agree with that - something seems strange here.

The first OOME in OOM1 is not actually Java heap exhaustion, but 
"Requested array size exceeds VM limit", so it could in theory consume 
sufficient Java heap that the "repeat" in OOM2 actually exhausts the 
heap. But that isn't what we see - the unexpected OOME is in OOM3. 
Before OOM2 runs out of memory the GC should have reclaimed everything 
from OOM1. Similarly before OOM3 runs out of memory the GC should have 
reclaimed everything from OOM2 - which should make it impossible for the 
same "repeat" call to hit an OOME in OOM3. Unless the test is being run 
concurrrently in the same VM as other tests?

Cheers,
David

> 
> Thanks, Roger
> 
> 
> On 7/14/20 2:23 PM, Daniel D. Daugherty wrote:
>> On 7/14/20 2:09 PM, Jim Laskey wrote:
>>> Adding Daniel
>>>
>>>> Begin forwarded message:
>>>>
>>>> *From: *Jim Laskey <james.laskey at oracle.com 
>>>> <mailto:james.laskey at oracle.com>>
>>>> *Subject: **RFR: JDK-8249258 
>>>> java/util/StringJoiner/StringJoinerTest.java failed due to OOM (JDK 
>>>> 15)*
>>>> *Date: *July 14, 2020 at 2:01:09 PM ADT
>>>> *To: *core-libs-dev <core-libs-dev at openjdk.java.net 
>>>> <mailto:core-libs-dev at openjdk.java.net>>
>>>>
>>>> The test was failing on a newly added mac mini. I've reduced the 
>>>> memory stress by introducing a shared maximum sized string. I don't 
>>>> recommend reducing the 4G memory requirement -- multiple new large 
>>>> objects are constructed in the tests hoping to create an OOM.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8249258
>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8249258/webrev-01
>>
>> test/jdk/java/util/StringJoiner/StringJoinerTest.java
>>     No comments on the changes.
>>
>> This should make it less likely to cause an OOM in an unexpected place.
>> Thanks for fixing this so quickly.
>>
>> Thumbs up. Don't know if your team updates copyrights as you
>> touch files, but if you do, then this one needs it...
>>
>> Dan
>>
>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>