RFR: JDK-8240340: java/lang/management/ThreadMXBean/Locks.java is buggy
David Holmes
david.holmes at oracle.com
Thu Mar 5 01:50:11 UTC 2020
Hi Alex,
On 5/03/2020 10:30 am, Alex Menkov wrote:
> Hi all,
>
> please review the fix for
> https://bugs.openjdk.java.net/browse/JDK-8240340
> webrev:
> http://cr.openjdk.java.net/~amenkov/jdk15/ThreadMXBean_Locks_test/webrev/
>
> changes:
> - assertThreadState method: don't re-read thread state throwing
> exception (as we got weird error like "Thread WaitingThread is at
> WAITING state but is expected to be in Thread.State = WAITING");
> - added proper test shutdown on error (made all threads "daemon",
> interrupt waiting thread if CheckerThread throws exception);
> - if CheckerThread detects error, propagate the exception to main thread;
The test changes seem fine.
> - fixed LockFreeLogger class - it should work for logging from several
> threads, but it doesn't. I prefer to simplify it just to keep
> ConcurrentLinkedQueue<String>.
> LockFreeLogger is also used by ThreadMXBeanStateTest test, but only by a
> single thread.
I don't understand your changes here as you've completely changed the
intended design of the logger. The original accumulates log entries
per-thread and then spits them all out (though I'm not clear on the
exact ordering - I don't how to read that stream stuff). The new code
just creates a single queue of log records interleaving entries from
different threads. The simple logger may be all that is needed but it
seems quite different to the intent of the original.
Thanks,
David
> --alex
More information about the serviceability-dev
mailing list