Closed
Description
After the changes in the Recycler, Recycler$LocalPool.release often appear in heavy load scenarios even for cases where the buffer is not escaping the event loop it has reused it.
The orginal Recycler implementation was very complex and with some wider effects on GC, hence I still think it was the right move, but according to the profiling data the JCTools offering (based on a atomic CAS) is still too much costy.
I suggest to record some information re the event loop where the allocation first happen and use a (event loop)-local stack/queue where short-circuit the buffer recycling.
In short:
- allocation happen from event loop X: always use the event-loop-local pool first. If empty, use the "shared" one using the JCTools q (using relaxed poll, pretty cheap)
- if release happen on the same originating event loop, there's no need to use any atomic construct and can release it to the event-loop-local pool (if not full? I'm open to suggestions here) or fall-back to the shared one, based on some policy.
It's not nice to have 2 separate structures, but the benefit from common usages should be significant
Activity