RFR: 8254623: gc/g1/TestHumongousConcurrentStartUndo.java still fails sometimes
Thomas Schatzl
tschatzl at openjdk.java.net
Tue Oct 13 16:25:20 UTC 2020
On Tue, 13 Oct 2020 11:33:14 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> can I have reviews for this change of the gc/g1/TestHumongousConcurrentStartUndo.java test to make it even more
> resilient to timing?
>
> Previously the test tried to create a stable initial condition by performing a full gc before that test step, but the
> problem is about when the first concurrent mark happens while building up the large set of humongous object kept alive:
> if it happens too early, and the concurrent undo operation takes too long, the next concurrent start will just be
> another undo because the large set of humongous objects will already be unreferenced and may as well cause a concurrent
> undo and not a concurrent mark. The solution I came up with is that *after* creating all the humongous objects of the
> large set trigger an extra concurrent mark (and wait for its completion). That one (or some before) must have been a
> concurrent mark because at least at that point the heap must have been occupied by more than the IHOP value. Testing:
> 2k iterations on failing platform (always aarch64-linux) without issues. Thanks,
> Thomas
I will look into that code, but I need triggering of concurrent mark via humongous object allocation specifically.
-------------
PR: https://git.openjdk.java.net/jdk/pull/632
More information about the hotspot-gc-dev
mailing list