-
-
Notifications
You must be signed in to change notification settings - Fork 15.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Speed up the slow path of FastThreadLocal #5012
Conversation
Before 5dcc0c9
After
|
@@ -39,19 +39,17 @@ | |||
|
|||
static { | |||
for (int i = 0; i < jdkThreadLocals.length; i ++) { | |||
final int num = rand.nextInt(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Modified to put the same data to jdkThreadLocals and fastThreadLocals.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
@windie I don't see any improvements in your posted benchmark output... What I'm missing? |
@normanmaurer Sorry that it's not clear. I copied the two benchmark outputs about the improvement here: Before:
After:
|
@windie oh sorry I miss-read your comment before. Awesome work! |
} | ||
} | ||
|
||
public static void destroy() { | ||
slowThreadLocalMap = null; | ||
slowThreadLocalMap.remove(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@trustin can you comment why you not did this before when implement this ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@normanmaurer It's to prevent slowThreadLocalMap
from being initialized again after its destruction. Otherwise a user can 'resurrect' the destroyed InternalThreadLocalMap
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the user can still call get
to create a new slowThreadLocalMap
after its destruction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, you are right. My memory about this is fading :-)
I guess it's probably to make getIfSet()
return null
when slowThreadLocalMap
is not created yet (or destroyed)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See here
Motivation: The current slow path of FastThreadLocal is much slower than JDK ThreadLocal. See netty#4418 Modifications: - Add FastThreadLocalSlowPathBenchmark for the flow path of FastThreadLocal - Add final to speed up the slow path of FastThreadLocal Result: The slow path of FastThreadLocal is improved.
5dcc0c9
to
50f2a44
Compare
Squashed. |
Motivation:
The current slow path of FastThreadLocal is much slower than JDK ThreadLocal. See #4418
Modifications:
Result:
The slow path of FastThreadLocal is improved.