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
