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.las...@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.hol...@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.las...@oracle.com >>>>>> <mailto:james.las...@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@openjdk.java.net >>>>>> <mailto:core-libs-dev@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 >>>> >>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >
