[testbug] RFR: 8195716: BootstrapLoggerTest : Executor still alive

Daniel Fuchs daniel.fuchs at oracle.com
Fri Jan 25 10:33:22 UTC 2019

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

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.fuchs at 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

More information about the core-libs-dev mailing list