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

[Richard Reingruber]

On Thu, 22 Oct 2020 07:57:32 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>>> The new LinkedListOfLongArrays is created by renaming LinkedList to
>>> LinkedListOfLongArrays. The new LinkedList is a list node without payload, so it
>>> is smaller than a LinkedListOfLongArrays node. I try to fill the last free
>>> blocks with these. But yeah, this won't make that much of a difference.
>> 
>> Ok. However, since you can't reproduce the initial problem it's hard to say if this will fix it. You would need to remove it from the problem list with this PR and see what happens.
>> 
>> Earlier you said:
>> 
>>> 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).
>> 
>> So I suppose in that case it's ok if this one test case allows for no OOME just as long as other test cases still require it.
>
>> Earlier you said:
>> 
>> > 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).
>> 
>> So I suppose in that case it's ok if this one test case allows for no OOME just as long as other test cases still require it.
> 
> With that I wanted to state that the probability to get the OOME is not too bad
> for meaningful testing. It should be the same for the 3 test cases.
> 
> What about repeating a test case if the expected OOME is not raised and let it
> fail after 10x retries?

You mentioned the possibility that the OOME is not thrown because it is another thread that consumes all memory than the one calling forceEarlyReturn() which is supposed to fail with OOME. TLAB could be an issue then. In general GC could have a heuristic in place to raise OOME in greedy threads when another thread would still be able to allocate successfully. I think I could change the debugger part to call consumeAllMemory() in the debuggee. This should be executed in the same jdwp agent thread as the later forceEarlyReturn.

But honestly I don't think it is worth it and I cannot even test if it fixes the issues. I'd prefer to skip the 3 test cases if running with ZGC. Please let me know what you prefer.

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

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