Try this: - You have a 4G heap. - You allocate some stuff, say 1 byte. - You allocate a 2G object - so there is only 2G - 1, left. Not enough space for another 2G object. - But you do allocate 1 byte. - You have 1 byte, 2G and 1 byte. - You free the original 2G object. - But something allocates 1 byte in it's old space. - Now there is no range that that can accommodate a 2G object. OOM.
> On Jul 15, 2020, at 10:25 AM, David Holmes <david.hol...@oracle.com> wrote: > > On 15/07/2020 10:18 pm, Jim Laskey wrote: >> 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, > > Naively one would expect that whatever memory was consumed by > > String maxString = "*".repeat(MAX_ARRAY_LENGTH); > > in OOM2, would be fully freed and available for use by the same statememt in > OOM3. But without knowing the exact allocation patterns ... > > Cheers, > David > ----- > >>> 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 >>>>>> >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>
