RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown
Chris Plummer
cjplummer at openjdk.java.net
Wed Oct 21 20:07:09 UTC 2020
On Wed, 21 Oct 2020 10:21:05 GMT, Richard Reingruber <rrich at openjdk.org> wrote:
>> If the test does not throw OOME, has it actually tested anything in that case? My concern with any test that allows for what is suppose to be an occasional failure it that it will not detect if something breaks and causes that failure to happen every time, often rendering the test useless.
>
>> If the test does not throw OOME, has it actually tested anything in that
>> case?
>
> If an OOME is expected then it has tested object reallocation in frames affected
> by PopFrame/ForceEarlyReturn.
>
> But there are runs where OOME is not expected. I added a new commit which skips
> the test cases then.
>
>> My concern with any test that allows for what is suppose to be an
>> occasional failure it that it will not detect if something breaks and causes
>> that failure to happen every time, often rendering the test useless.
>
> I can follow that concern. My problem is that I cannot reproduce the
> failure. Note also that the OOME is successfully generated during object
> reallocation a couple of times before (search "run args" in attachments
> to the JBS issue).
>
> I'd think the approach to prove the OOME during the PopFrame/ForceEarlyReturn
> [1] is relatively reliable knowing how smart GCs try to be with avoiding it.
>
> I've tried to make it even more reliable with a second commit in this pr.
>
> Would that be ok? Maybe you would know a better way?
>
> Thanks, Richard.
>
> [1] https://github.com/openjdk/jdk/blob/7e2640432bf4fb5115c2ff694c09937234e6d1c5/test/jdk/com/sun/jdi/EATests.java#L1089
I'm not following how the introduction of LinkedListOfLongArrays is making the OOME even more reliable. Can you please elaborate?
Is consumeAllMemory() being called from a different thread than the one doing the forceEarlyReturn? If so, you might be running into an issue because the tlab still has available memory to allocate.
-------------
PR: https://git.openjdk.java.net/jdk/pull/775
More information about the serviceability-dev
mailing list