Hi, Daniel

On 9/16/19 3:40 AM, Daniel Fuchs wrote:

However I have some doubts about the the logging benchmark.

Is the benchmark run in a single thread? If not then
there doesn't seem any guarantee that each call to publish()
will be immediately followed by a call to reset(), but instead,
if you have two threads, you could see things like:

T1: publish();
T2: publish();   => T1 record would be lost here
T1: reset();
T2: reset();     => reset() would return null here

Well-spotted.
JMH defaults to using 1 worker thread, but can be configured to use more. I tried with '-t max' (8 threads on my machine), and the benchmark NPE'd, as you predicted.

I've updated the benchmark to use a separate handler (and Logger) per-thread, and it can now run w/ '-t max'. Single-thread scores are within a few % of the original test. I also added "Logging" to the benchmark names to make it easier to select both in JMH using a simple regex.

http://cr.openjdk.java.net/~bchristi/8221623/webrev09-loggerPerThread/

Though really, since logging is no longer using Throwable to examine the call stack, maybe it makes more sense to move the logging benchmarks to their own file under:

test/micro/org/openjdk/bench/java/util/logging/

?

Thanks,
-Brent

On 13/09/2019 23:07, Brent Christian wrote:
Hi,

Please review these StackWalker and Throwable benchmarks for addition into the JDK microbenchmarks.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8221623
Webrev:
http://cr.openjdk.java.net/~bchristi/8221623/webrev07/

The StackWalker benchmarks use StackWalker's forEach(), walk(), and Options to measure retrieval of various types of information from the call stack.

The Throwable benchmarks do corresponding exercises; there are also a couple of Logging benchmarks.

A JMH @Param is used to test a variety of call stack depths.


In the future, we might consider a benchmark for Reflection.getCallerClass().  (It is more involved today to benchmark that method than at the time these benchmarks were originally written, so that one's commented out.) See JDK-8230976.

Thanks,
-Brent

1. https://bugs.openjdk.java.net/browse/JDK-8230976


Reply via email to