RFR 8221623 : Add StackWalker micro benchmarks to jdk repo
Brent Christian
brent.christian at oracle.com
Thu Sep 19 19:08:49 UTC 2019
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
>
More information about the core-libs-dev
mailing list