> Under certain load, MemoryCache operations take a substantial fraction of the > time needed to complete SSL handshakes. This series of patches improves > performance characteristics of MemoryCache, at the cost of a functional > change: expired entries are no longer guaranteed to be removed before live > ones. Unused entries are still removed before used ones, and cache > performance no longer depends on its capacity. > > First patch in the series contains a benchmark that can be run with `make > test TEST="micro:CacheBench"`. > Baseline results before any MemoryCache changes: > Benchmark (size) (timeout) Mode Cnt Score Error Units > CacheBench.put 20480 86400 avgt 25 83.653 ? 6.269 us/op > CacheBench.put 20480 0 avgt 25 0.107 ? 0.001 us/op > CacheBench.put 204800 86400 avgt 25 2057.781 ? 35.942 us/op > CacheBench.put 204800 0 avgt 25 0.108 ? 0.001 us/op > there's a nonlinear performance drop between 20480 and 204800 entries, > probably attributable to CPU cache thrashing. Beyond 204800 entries the cache > scales more linearly. > > Benchmark results after the 2nd and 3rd patches are pretty similar, so I'll > only copy one: > Benchmark (size) (timeout) Mode Cnt Score Error Units > CacheBench.put 20480 86400 avgt 25 0.146 ? 0.002 us/op > CacheBench.put 20480 0 avgt 25 0.108 ? 0.002 us/op > CacheBench.put 204800 86400 avgt 25 0.150 ? 0.001 us/op > CacheBench.put 204800 0 avgt 25 0.106 ? 0.001 us/op > The third patch improves worst-case times on a mostly idle cache by > scattering removal of expired entries over multiple `put` calls. It does not > affect performance of an overloaded cache. > > The 4th patch removes all code that clears cached values before handing them > over to the GC. [This > comment](https://github.com/openjdk/jdk/commit/5859a0320334bfb6b46b62eb16b4c387641f4a2a#diff-c6bd583a97fbc4f471621fee7eab37c63718cdb6932ce357fa403cfda4b32b6fL346) > stated that clearing values was supposed to be a GC performance > optimization. It wasn't. Benchmark results after that commit: > Benchmark (size) (timeout) Mode Cnt Score Error Units > CacheBench.put 20480 86400 avgt 25 0.113 ? 0.001 us/op > CacheBench.put 20480 0 avgt 25 0.075 ? 0.002 us/op > CacheBench.put 204800 86400 avgt 25 0.116 ? 0.001 us/op > CacheBench.put 204800 0 avgt 25 0.072 ? 0.001 us/op > I wasn't expecting that much of an improvement, and don't know how to explain > it. > > The 40ns difference between cache with and without a timeout can be > attributed to 2 `System.currentTimeMillis()` calls; they were pretty slow on > my VM.
djelinski has updated the pull request incrementally with two additional commits since the last revision: - Avoid unproductive cache scans - Revert Cache changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2255/files - new: https://git.openjdk.java.net/jdk/pull/2255/files/c7b064f0..f9bc386a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2255&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2255&range=03-04 Stats: 96 lines in 1 file changed: 59 ins; 3 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/2255.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2255/head:pull/2255 PR: https://git.openjdk.java.net/jdk/pull/2255