Our great sponsors
-
async-profiler
Discontinued Sampling CPU and HEAP profiler for Java featuring AsyncGetCallTrace + perf_events [Moved to: https://github.com/async-profiler/async-profiler] (by jvm-profiling-tools)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Time: 14010, Passes: 10000, count: 78498, Valid: true Time: 14208, Passes: 10000, count: 78498, Valid: true Time: 14111, Passes: 10000, count: 78498, Valid: true Time: 13869, Passes: 10000, count: 78498, Valid: true Time: 14119, Passes: 10000, count: 78498, Valid: true Time: 13916, Passes: 10000, count: 78498, Valid: true Time: 13903, Passes: 10000, count: 78498, Valid: true Time: 13890, Passes: 10000, count: 78498, Valid: true Time: 14024, Passes: 10000, count: 78498, Valid: true Time: 13924, Passes: 10000, count: 78498, Valid: true Time: 14180, Passes: 10000, count: 78498, Valid: true Time: 13980, Passes: 10000, count: 78498, Valid: true Time: 13825, Passes: 10000, count: 78498, Valid: true Time: 13800, Passes: 10000, count: 78498, Valid: true Time: 14041, Passes: 10000, count: 78498, Valid: true Time: 13941, Passes: 10000, count: 78498, Valid: true
Running on: JDK 11.0.8 on Windows, with somewhat old Intel Core i7-3740QM
[1] https://github.com/PEZ/ghost-chase-condition/tree/master/tes...
Also, running it under a profiler (I recommend async-profiler[1]) should give you a good idea of where the slowdown occurs which might help you pin it down further.
[1] https://github.com/jvm-profiling-tools/async-profiler
This issue isn't directly related to BitSet. I have observed the same thing in my programming language interpreter that runs on the JVM (well, it's written in Kotlin multiplatform so it runs on JS and Natively as well).
I start the interpreter and measue the time it takes to all all then numbers below 1000000000.
The first time I run it after starting the interpreter it always takes 1.4 seconds (within 0.1 second precision). The second time I measure the time it takes 1.7, and for every invocation following that it takes 2 seconds.
If I stop the interpreter and try again, I get exactly the same result.
I have not been able to explain this behaviour. This is on OpenJDK 11 by the way.
If anyone wants to test this, just run the interpreter from here: https://github.com/lokedhs/array
To run the benchmark, type the following command in the UI:
time:measureTime { +/⍳1000000000 }
To maximize I$ hit rate you'd actually want to disable loop alignment to not inflate code size with padding.
Here's an example of unstable benchmark performance caused by the lack of loop alignment in .NET's JIT: https://github.com/dotnet/runtime/issues/43227