Let PoolThreadCache work even if allocation and deallocation Thread a… #3833
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@trustin please review. @nmittler @ejona86 @louiscryan this should also be interesting for grpc :) |
| } | ||
| maxUnusedCached = size / 2; | ||
| this.size = powerOfTwo(size); | ||
| queue = new MpscArrayQueue<Entry<T>>(this.size); |
There was a problem hiding this comment.
What happens when Unsafe is unavailable?
|
How about making the new classes package-private and adding the factory methods to |
|
@trustin good point let me address both comments |
|
@trustin addressed comments... please check |
| } | ||
| maxUnusedCached = size / 2; | ||
| this.size = powerOfTwo(size); | ||
| queue = PlatformDependent.newFixedMpscQueue(this.size); |
There was a problem hiding this comment.
Not really a gain, but maybe this is shorter:
queue = PlatformDependent.newFixedMpscQueue(this.size = powerOfTwo(size));
There was a problem hiding this comment.
just leave it as it is :)
|
LGTM. Please consider to take care of #3835 :-) |
|
@normanmaurer Sure! |
|
@netkins build |
…re different Motivation: PoolThreadCache did only cache allocations if the allocation and deallocation Thread were the same. This is not optimal as often people write from differen thread then the actual EventLoop thread. Modification: - Add MpscArrayQueue which was forked from jctools and lightly modified. - Use MpscArrayQueue for caches and always add buffer back to the cache that belongs to the allocation thread. Result: ThreadPoolCache is now also usable and so gives performance improvements when allocation and deallocation thread are different. Performance when using same thread for allocation and deallocation is noticable worse then before.
normanmaurer
force-pushed
the
pool_cache_mpsc
branch
from
7aa472e
to
02cc322
Compare
fengjiachun
pushed a commit
to fengjiachun/Jupiter
that referenced
this pull request
Nov 2, 2015
业务线程alloc, 结果被在netty4中 却被IO线程release掉的, 这导致pooledBuf前边那层基于threadLocal的cache出了些问题(就是业务线程alloc时不断的cache不命中, 因为release时归还到别的线程的cache中了) netty/netty#3833 norman的改法是: pooledBuf中绑定cache, 谁alloc的就rlease给谁, 这就又导致release时可能引起多个线程的竞争条件(比如可能存在这样的场景:线程1线程2都要release到线程3的cache中), norman用一个MPSC队列解决的这个竞争(MPSC就是多生产者单消费者), 这个队列倒是很有意思, 感兴趣参考jctools https://github.com/JCTools/JCTools
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…re different
Motivation:
PoolThreadCache did only cache allocations if the allocation and deallocation Thread were the same. This is not optimal as often people write from differen thread then the actual EventLoop thread.
Modification:
Result:
ThreadPoolCache is now also usable and so gives performance improvements when allocation and deallocation thread are different.
Performance when using same thread for allocation and deallocation is noticable worse then before.