On Fri, 14 May 2021 22:04:05 GMT, Daniel D. Daugherty <dcu...@openjdk.org>
wrote:
>> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java
>> line 329:
>>
>>> 327: // - releases threadLock
>>> 328: //
>>> 329: if (getName().equals("blocker")) {
>>
>> Bit of a nit here, but is there a reason not to just create separate Thread
>> subclasses for each of the 3 types of threads you are handling here? Or just
>> make these each separate static methods of the main class and use the
>> instantiate the Thread class with a lambda.
>
> This new test is a variation of a 20 year old test that I recently ported to
> JVM/TI
> and integrated. 20 years ago, it was much simpler to write the test this way.
> I could create a separate Thread subclass for each "role", but I'd rather not
> do that since it will no longer be easy to compare this test to its siblings.
>
> As for lambdas, I know absolutely zero about writing lambda code.
Ok. I get it about lambdas, but they can be useful for simplifying thread tasks
without creating a subclass. Here are a few examples, but no need for you to
replicate any them:
// create thread with specified method as the "run" method
Thread t = new Thread(this::testMethod);
t.start();
// create thread with the specified code block as the "run" method
Thread t1 = new Thread(() -> {
synchronized (lock1) {
System.out.println("Thread in sync section 1: "
+ Thread.currentThread().getName());
test1();
}
// create a static Runnable object using a lambda and use it as the
Runnable for a new Thread
static final Runnable CONSUMER = () -> {
remove(QUEUE);
};
...
Thread t = new Thread(CONSUMER);
-------------
PR: https://git.openjdk.java.net/jdk/pull/3478
