Hi Martin,
On 24/01/2019 18:19, Martin Buchholz wrote:
I don't understand your test, but:
typo: bootsrap
Thanks! Fixed.
Consider copying in gcAwait from a concurrency test, e.g.
ArrayBlockingQueue/WhiteBox.java:229: static void
gcAwait(BooleanSupplier s) {
Interesting. The main difference would be waiting for
the GC to run finalization hooks. This is a nice trick.
I hadn't seen it before.
I'm not sure this is strictly needed in the case of
this test though, but I will keep that in mind in case
this test (or some of the other logging tests that try
to check that resources/loggers are correctly released)
are seen failing again.
Maybe then a global pass on all these test would be
warranted.
Thanks for the pointer! It is good food for thoughts :-)
best regards,
-- daniel
On Thu, Jan 24, 2019 at 8:17 AM Daniel Fuchs <daniel.fu...@oracle.com> wrote:
Hi,
Please find below another test fix for:
8195716: BootstrapLoggerTest : Executor still alive
https://bugs.openjdk.java.net/browse/JDK-8195716
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8195716/webrev.00/
This test has been seen failing intermittently with -Xcomp
and some other combination of options.
The reason for the failure has baffled me until I recently
noticed that the name of the executor's thread the test was
joining in the end, didn't match the name of the executor
thread that was still alive.
Presumably the test is taking longer to execute, which allows
the first executor thread timeout to expire, letting the executor
release its thread and then later create a new one on demand.
The fix is therefore simple (if a bit cumbersome): I changed
the test to join any executor thread that is still found
alive at the end, and then to wait for all of them to be GC'ed,
instead of waiting on the single thread found at the beginning.
I believe that should fix the issue.
best regards,
-- daniel
