On Thu, 22 Oct 2020 07:57:32 GMT, Richard Reingruber <rr...@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

Reply via email to