On Wed, 21 Oct 2020 20:04:54 GMT, Chris Plummer <cjplum...@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
