On Thu, 11 Jul 2024 21:08:20 GMT, Kevin Walls <kev...@openjdk.org> wrote:

> Short version:
> Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp"
> 
> Make additional typo fixes and tidyups while here, it's just shocking.
> 
> TestDescription.java contains the test definition, so the "requires" goes 
> there, with a comment.
> 
> Updates to from001.java are typos and clarifications, and a changed loop with 
> a poll on a queue rather than block forever.

Longer version:

When the test fails, it is monitoring the old gen of either Parallel, Serial, 
or ZGC (Generational) collector, and is running with -Xcomp.

In the HotSpot Event log of the failure, Java heap is completely stable, but 
usage may drop off in the last collection.

The "eatMemory" call is not working?  More likely it has done its work, and the 
-Xcomp throws off the timing, such that no Notification ever appears.  The call 
to retrieve the data from the queue sleeps forever, until the test harness 
times it out.

We could play games with eatMemory: have it work harder, consume more memory, 
work for longer, pause before starting... But this is a chasing game with goals 
that are hard to monitor and may well need future changes.

Also tried a version that tolerates the failure: just don't fail if the 
Notification data is not available.  This works, and it's fine if it skips one 
in some large number of runs (not that I can reproduce that), but the problem 
is there's no way of finding out if it starts skipping it all the time.

Overall it seems better to not run this test with -Xcomp.

I'm keeping the reading of the queue changed to poll with a timeout, which was 
used to test tolerating the Notification never arriving.  It keeps down the max 
time needed if it fails.  The Notification usually happens immediately, and 
being stuck in a long delay is unnecessary.  Without Xcomp, the test should 
take a few seconds overall, so at a minute without a Notification it should 
give up and fail.

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

PR Comment: https://git.openjdk.org/jdk/pull/20146#issuecomment-2223952615

Reply via email to