On Wed, 21 Oct 2020 10:21:05 GMT, Richard Reingruber <rr...@openjdk.org> wrote:
>> If the test does not throw OOME, has it actually tested anything in that >> case? 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. > >> 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/775
