Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v5]
On Thu, 29 Oct 2020 15:34:58 GMT, Vladimir Kozlov wrote: > Good Thanks for reviewing. Will integrate beginning of next week. - PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v5]
On Thu, 29 Oct 2020 14:53:54 GMT, Richard Reingruber wrote: >> The following test cases try to provoke VMOutOfMemoryException during object >> reallocation because of JVMTI PopFrame / ForceEarlyReturn: >> >> EAPopFrameNotInlinedReallocFailure >> EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure >> EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure >> >> For ZGC (so far) this is not 100% reliable. >> >> Just ignoring the runs where the expected OOME was not raised was not >> accepted. >> >> Summary of the now accepted solution: >> >> - The 3 problematic test cases are skipped if ZGC is selected. >> >> - They are also skipped if no OOME during object reallocation can be >> expected because allocations are not eliminated. >> >> - In consumeAllMemory, as a last step, empty LinkedList nodes are created >> without long array to fill up small blocks of free memory. >> >> - EATests.java is removed from the problem list for ZGC. > > Richard Reingruber has updated the pull request incrementally with one > additional commit since the last revision: > > Replaced vm.jvmci with vm.graal.enabled in @requires clause. Good - Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v5]
> The following test cases try to provoke VMOutOfMemoryException during object > reallocation because of JVMTI PopFrame / ForceEarlyReturn: > > EAPopFrameNotInlinedReallocFailure > EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure > EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure > > For ZGC (so far) this is not 100% reliable. > > Just ignoring the runs where the expected OOME was not raised was not > accepted. > > Summary of the now accepted solution: > > - The 3 problematic test cases are skipped if ZGC is selected. > > - They are also skipped if no OOME during object reallocation can be expected > because allocations are not eliminated. > > - In consumeAllMemory, as a last step, empty LinkedList nodes are created > without long array to fill up small blocks of free memory. > > - EATests.java is removed from the problem list for ZGC. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Replaced vm.jvmci with vm.graal.enabled in @requires clause. - Changes: - all: https://git.openjdk.java.net/jdk/pull/775/files - new: https://git.openjdk.java.net/jdk/pull/775/files/4676f1da..4e878e8e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=775=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=775=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/775.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/775/head:pull/775 PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v4]
On Wed, 28 Oct 2020 20:13:15 GMT, Vladimir Kozlov wrote: > > > Please change @requires for testing with Graal to `vm.graal.enabled` instead > of `vm.jvmci` Sure. I've done that now. - PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v4]
On Tue, 27 Oct 2020 10:16:29 GMT, Richard Reingruber wrote: >> The following test cases try to provoke VMOutOfMemoryException during object >> reallocation because of JVMTI PopFrame / ForceEarlyReturn: >> >> EAPopFrameNotInlinedReallocFailure >> EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure >> EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure >> >> For ZGC (so far) this is not 100% reliable. >> >> Just ignoring the runs where the expected OOME was not raised was not >> accepted. >> >> Summary of the now accepted solution: >> >> - The 3 problematic test cases are skipped if ZGC is selected. >> >> - They are also skipped if no OOME during object reallocation can be >> expected because allocations are not eliminated. >> >> - In consumeAllMemory, as a last step, empty LinkedList nodes are created >> without long array to fill up small blocks of free memory. >> >> - EATests.java is removed from the problem list for ZGC. > > Richard Reingruber has updated the pull request incrementally with one > additional commit since the last revision: > > Whitespace/indentation clean-up. Please change @requires for testing with Graal to `vm.graal.enabled` instead of `vm.jvmci` - Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v4]
> The following test cases try to provoke VMOutOfMemoryException during object > reallocation because of JVMTI PopFrame / ForceEarlyReturn: > > EAPopFrameNotInlinedReallocFailure > EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure > EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure > > For ZGC (so far) this is not 100% reliable. > > Just ignoring the runs where the expected OOME was not raised was not > accepted. > > Summary of the now accepted solution: > > - The 3 problematic test cases are skipped if ZGC is selected. > > - They are also skipped if no OOME during object reallocation can be expected > because allocations are not eliminated. > > - In consumeAllMemory, as a last step, empty LinkedList nodes are created > without long array to fill up small blocks of free memory. > > - EATests.java is removed from the problem list for ZGC. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Whitespace/indentation clean-up. - Changes: - all: https://git.openjdk.java.net/jdk/pull/775/files - new: https://git.openjdk.java.net/jdk/pull/775/files/33ceb741..4676f1da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=775=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=775=02-03 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/775.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/775/head:pull/775 PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v3]
On Tue, 27 Oct 2020 00:52:20 GMT, Serguei Spitsyn wrote:
>> Richard Reingruber has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains four
>> additional commits since the last revision:
>>
>> - Skip test cases expecting OOMEs if running with ZGC.
>> - Merge branch 'master' into JDK-8255072-eatests-oom-not-thrown
>> - Make OOME more reliable and skip test cases if it is not expected because
>> scalar replacement is disabled
>> - 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected
>> VMOutOfMemoryException is not thrown
>
> Hi Richard,
> It looks good to me.
> One nit:
> public static final boolean DoEscapeAnalysis =
> unbox(WB.getBooleanVMFlag("DoEscapeAnalysis"), UseJVMCICompiler);
> public static final boolean EliminateAllocations =
> unbox(WB.getBooleanVMFlag("EliminateAllocations"), UseJVMCICompiler); // read
> by debugger
> public static final boolean DeoptimizeObjectsALot =
> WB.getBooleanVMFlag("DeoptimizeObjectsALot"); // read by
> debugger
> public static final long BiasedLockingBulkRebiasThreshold =
> WB.getIntxVMFlag("BiasedLockingBulkRebiasThreshold");
> public static final long BiasedLockingBulkRevokeThreshold =
> WB.getIntxVMFlag("BiasedLockingBulkRevokeThreshold");
> +public static final boolean ZGCIsSelected= GC.Z.isSelected();
> There are unneeded spaces before '=' sign.
>
> Thanks,
> Serguei
Hi Serguei,
thanks for reviewing. I'll remove the whitespace.
I'm able now to reproduce the issue but only with ZGC. So far my attempts(*) to
reliably get the OOME during ForceEarlyReturn/PopFrame because of object
reallocation failed though. So I'm still in favour of the current solution
which is: skip the 3 problematic testcases if ZGC is selected in the target vm.
I'm still open for suggestions also though. I'll wait a few more days and then
I'll integrate.
Thanks, Richard.
(*) I tried:
- disable TLAB
- call WhiteBox.fullGC() in consumeAllMemory() before the last round of
allocations.
- Check if the memory can be allocated by the thread doing the
PopFrame/ForceEarlyReturn. com.sun.jdi.ThreadReference::invokeMethod() cannot
be used. A target thread has to be specified and the jdwp threads are not
visible through jdi. Only a dedicated native test JVMTI agent can consume all
memory and then do the PopFrame/ForceEarlyReturn.
-
PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v3]
On Thu, 22 Oct 2020 20:35:29 GMT, Richard Reingruber wrote:
>> The following test cases try to provoke VMOutOfMemoryException during object
>> reallocation because of JVMTI PopFrame / ForceEarlyReturn:
>>
>> EAPopFrameNotInlinedReallocFailure
>> EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure
>> EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure
>>
>> For ZGC (so far) this is not 100% reliable.
>>
>> Just ignoring the runs where the expected OOME was not raised was not
>> accepted.
>>
>> Summary of the now accepted solution:
>>
>> - The 3 problematic test cases are skipped if ZGC is selected.
>>
>> - They are also skipped if no OOME during object reallocation can be
>> expected because allocations are not eliminated.
>>
>> - In consumeAllMemory, as a last step, empty LinkedList nodes are created
>> without long array to fill up small blocks of free memory.
>>
>> - EATests.java is removed from the problem list for ZGC.
>
> Richard Reingruber has updated the pull request with a new target base due to
> a merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by the merge/rebase. The pull request contains four additional
> commits since the last revision:
>
> - Skip test cases expecting OOMEs if running with ZGC.
> - Merge branch 'master' into JDK-8255072-eatests-oom-not-thrown
> - Make OOME more reliable and skip test cases if it is not expected because
> scalar replacement is disabled
> - 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected
> VMOutOfMemoryException is not thrown
Hi Richard,
It looks good to me.
One nit:
public static final boolean DoEscapeAnalysis =
unbox(WB.getBooleanVMFlag("DoEscapeAnalysis"), UseJVMCICompiler);
public static final boolean EliminateAllocations =
unbox(WB.getBooleanVMFlag("EliminateAllocations"), UseJVMCICompiler); // read
by debugger
public static final boolean DeoptimizeObjectsALot =
WB.getBooleanVMFlag("DeoptimizeObjectsALot"); // read by
debugger
public static final long BiasedLockingBulkRebiasThreshold =
WB.getIntxVMFlag("BiasedLockingBulkRebiasThreshold");
public static final long BiasedLockingBulkRevokeThreshold =
WB.getIntxVMFlag("BiasedLockingBulkRevokeThreshold");
+public static final boolean ZGCIsSelected= GC.Z.isSelected();
There are unneeded spaces before '=' sign.
Thanks,
Serguei
-
Marked as reviewed by sspitsyn (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v3]
On Fri, 23 Oct 2020 08:15:34 GMT, Chris Plummer wrote: >>> >>> >>> Looks good. >> >> Thank you. I'll wait for a second review assuming it's required. > >> Thank you. I'll wait for a second review assuming it's required. > > You might want to add the compiler and/or gc teams to the review Following @plummercj advice to add compiler/gc teams. - PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v3]
On Fri, 23 Oct 2020 08:00:49 GMT, Richard Reingruber wrote: > Thank you. I'll wait for a second review assuming it's required. You might want to add the compiler and/or gc teams to the review - PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v3]
On Thu, 22 Oct 2020 23:06:10 GMT, Chris Plummer wrote: > > > Looks good. Thank you. I'll wait for a second review assuming it's required. - PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v3]
On Thu, 22 Oct 2020 20:35:29 GMT, Richard Reingruber wrote: >> The following test cases try to provoke VMOutOfMemoryException during object >> reallocation: >> >> EAPopFrameNotInlinedReallocFailure >> EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure >> EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure >> >> This is not 100% reliable therefore it should not be treated as test failure >> if no oom was raised. > > Richard Reingruber has updated the pull request with a new target base due to > a merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains four additional > commits since the last revision: > > - Skip test cases expecting OOMEs if running with ZGC. > - Merge branch 'master' into JDK-8255072-eatests-oom-not-thrown > - Make OOME more reliable and skip test cases if it is not expected because > scalar replacement is disabled > - 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected > VMOutOfMemoryException is not thrown Looks good. - Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown
On Thu, 22 Oct 2020 14:29:28 GMT, Chris Plummer wrote: >> 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. > >> 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. > > That's one option if this only happens with ZGC. You also mentioned doing > retries. I would only suggest that if you think you can limit the chances of > the OOME not happening to be so unlikely that we are no likely to ever see it > happen. With the last commit the combined change is - The 3 problematic test cases are skipped if ZGC is selected. - They are also skipped if no OOME during object reallocation can be expected because allocations are not eliminated. - In consumeAllMemory, as a last step, empty LinkedList nodes are created without long array to fill up small blocks of free memory. - EATests.java is removed from the problem list for ZGC. - PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v3]
> The following test cases try to provoke VMOutOfMemoryException during object > reallocation: > > EAPopFrameNotInlinedReallocFailure > EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure > EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure > > This is not 100% reliable therefore it should not be treated as test failure > if no oom was raised. Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Skip test cases expecting OOMEs if running with ZGC. - Merge branch 'master' into JDK-8255072-eatests-oom-not-thrown - Make OOME more reliable and skip test cases if it is not expected because scalar replacement is disabled - 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown - Changes: - all: https://git.openjdk.java.net/jdk/pull/775/files - new: https://git.openjdk.java.net/jdk/pull/775/files/4196a421..33ceb741 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=775=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=775=01-02 Stats: 28553 lines in 409 files changed: 23836 ins; 3073 del; 1644 mod Patch: https://git.openjdk.java.net/jdk/pull/775.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/775/head:pull/775 PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown
On Thu, 22 Oct 2020 13:07:32 GMT, Richard Reingruber wrote: > 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. That's one option if this only happens with ZGC. You also mentioned doing retries. I would only suggest that if you think you can limit the chances of the OOME not happening to be so unlikely that we are no likely to ever see it happen. - PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown
On Thu, 22 Oct 2020 07:57:32 GMT, Richard Reingruber 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
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown
On Thu, 22 Oct 2020 05:06:43 GMT, Chris Plummer wrote: > 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? - PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown
On Wed, 21 Oct 2020 21:38:08 GMT, Richard Reingruber 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. - PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown
On Wed, 21 Oct 2020 21:38:08 GMT, Richard Reingruber 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
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown
On Wed, 21 Oct 2020 20:04:54 GMT, Chris Plummer wrote: > > > 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. - PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown
On Wed, 21 Oct 2020 20:04:54 GMT, Chris Plummer 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
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown
On Wed, 21 Oct 2020 10:21:05 GMT, Richard Reingruber 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
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown
On Tue, 20 Oct 2020 22:45:45 GMT, Chris Plummer 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 - PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v2]
> The following test cases try to provoke VMOutOfMemoryException during object > reallocation: > > EAPopFrameNotInlinedReallocFailure > EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure > EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure > > This is not 100% reliable therefore it should not be treated as test failure > if no oom was raised. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Make OOME more reliable and skip test cases if it is not expected because scalar replacement is disabled - Changes: - all: https://git.openjdk.java.net/jdk/pull/775/files - new: https://git.openjdk.java.net/jdk/pull/775/files/16f9782d..4196a421 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=775=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=775=00-01 Stats: 37 lines in 1 file changed: 25 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/775.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/775/head:pull/775 PR: https://git.openjdk.java.net/jdk/pull/775
Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown
On Tue, 20 Oct 2020 21:53:10 GMT, Richard Reingruber wrote: > The following test cases try to provoke VMOutOfMemoryException during object > reallocation: > > EAPopFrameNotInlinedReallocFailure > EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure > EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure > > This is not 100% reliable therefore it should not be treated as test failure > if no oom was raised. 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. - PR: https://git.openjdk.java.net/jdk/pull/775
