RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown

[Daniel D.Daugherty]

On Wed, 21 Oct 2020 20:04:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> 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.

@reinrich - when your reviewers have agreed to a fix, please remove the
ProblemListing that I did via: https://github.com/openjdk/jdk/pull/787

-------------

PR: https://git.openjdk.java.net/jdk/pull/775