Performance optimization in CloseableThreadContext.closeMap()

[jengebr]

Description

Excess work is performed in CloseableThreadContext.closeMap() that shows up as a production hotspot in our client-facing, latency-sensitive application. Specifically, the use of multiple calls to ThreadContext.remove() and ThreadContext.put() causes multiple copy-and-modify operations in the underlying ThreadContextMap. The attached java files compare the performance of the original code vs. a modification that groups keys by remove vs. replace, and makes zero or one calls to ThreadContext.remove() and ThreadContext.put().

On my system, tests with thread locals disabled (Constants.ENABLE_THREADLOCALS == false) show a 40% improvement:

Done with old in 521
Done with old in 535
Done with old in 537
Done with old in 516
Done with old in 516
Done with new in 284
Done with new in 285
Done with new in 284
Done with new in 301
Done with new in 292

With thread locals enabled (Constants.ENABLE_THREADLOCALS == true) show a 20% improvement:

Done with old in 386
Done with old in 388
Done with old in 386
Done with old in 389
Done with old in 408
Done with new in 308
Done with new in 309
Done with new in 307
Done with new in 307
Done with new in 313

The impact of the thread locals flag is because of the different implementations of ThreadContextMap. However, both cases demonstrate substantial improvement.

Configuration

Version: 2.20

Operating system: Affects all - tested on Linux and Windows

JDK: Tested on OpenJDK 8 and OpenJDK 17

Logs

CloseableThreadContextSpeedTest.java.txt

Reproduction

See attached file.

[ppkarwasz]

@jengebr, can you submit a PR?

[jengebr]

As requested: #2296

Hope I got the details right....

[vy]

Fixed in #2296.