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
