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

Richard Reingruber rrich at openjdk.java.net
Wed Oct 21 21:44:14 UTC 2020


On Wed, 21 Oct 2020 21:38:08 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> 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.
>
>> 
>> 
>> I'm not following how the introduction of LinkedListOfLongArrays is making the OOME even more reliable. Can you please elaborate?
> 
> 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.
> 
>> 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.
> 
> Yes, the threads are different (well observed :)). As far as I know tlabs are
> retired before gc. I'd expect that they are allocated lazily. So the jdwp agent
> thread that does the forceEarlyReturn should not have a tlab at hand. Certainly
> these are just assumptions. It would be easy to implement the gc interface(*)
> with different heuristics.
> 
> (*) Roman Kennke and Aleksey Shipilev demo'ed implementing the gc interface in a
> FOSDEM talk.

> 
> 
> @reinrich - when your reviewers have agreed to a fix, please remove the
> ProblemListing that I did via: #787

I will. Thanks for doing it.

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

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


More information about the serviceability-dev mailing list