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

[Jim Laskey]

Thomas explained: That large objects are never moved (outstanding issue) So, it's possible to fragment the -Xmx4g such that a 2G object can't be allocated,

> On Jul 15, 2020, at 8:55 AM, Jim Laskey <james.laskey at oracle.com> wrote:
> 
> Since the MAX_STRING is 2Gbytes, I wonder if those strings are allocated on the side per se and are subject to the platforms VM whims.
> 
>> On Jul 14, 2020, at 8:36 PM, David Holmes <David.Holmes at oracle.com> wrote:
>> 
>> 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
>>>> 
>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>