Repository navigation
Conversation
3cf9063 to
fd01cfb
Compare
| dependencies { | ||
| implementation project(":micrometer-core") | ||
| // implementation("io.micrometer:micrometer-core:1.12.4") | ||
| implementation project(":micrometer-test") |
There was a problem hiding this comment.
This dependency was causing a weird ClassNotFoundException when running jcstress from IntelliJ, but it is only here for the @Issue annotation. We do not do any processing of the annotation, so I'm not sure there's any more value of it being an actual annotation vs a comment - I've commented it out where it was used in this module.
| @Benchmark | ||
| @Group("contended") | ||
| @GroupThreads(1) | ||
| public KeyValues contendedRead() { |
There was a problem hiding this comment.
The contended group will share the threads configured for the benchmark in proportion to the specified @GroupThreads. So in this current setup there will be two execution groups for contended, each with 2 threads, one thread reading and one thread writing concurrently.
fd01cfb to
a6b2eb1
Compare
This avoids the issues with concurrent reads and writes of the keyvalues on the Context. Reverts the previous change to KeyValues as it is not needed with CHM.
a6b2eb1 to
d057a34
Compare
This scenario produced a NPE before the change from using a LinkedHashMap to ConcurrentHashMap. See gh-5739
|
I added a jcstress test for concurrent get/remove on a keyvalue (503f2e9), as this scenario was producing the NPE reported in the linked issue. |
|
And sharing benchmark results from my machine (MBP M1). There was not much of a noticeable difference and at the level of nanoseconds, the run-to-run results can vary as much as the differences here. With these changes using ConcurrentHashMap: Before these changes (1.14.1) using LinkedHashMap: |
See #4356 and micrometer-metrics/tracing#898.