-
Notifications
You must be signed in to change notification settings - Fork 170
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
Use AtomicLongFieldUpdater in StepLong, StepDouble, and AtomicDouble #1158
Conversation
@@ -124,4 +127,9 @@ public void max(double v) { | |||
@Override public double doubleValue() { | |||
return get(); | |||
} | |||
|
|||
@Override | |||
public String toString() { |
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.
Added a toString
implementation to match the behavior of AtomicLong
/ AtomicInteger
1ce7e11
to
e1fdb84
Compare
Use AtomicLongFieldUpdater to shrink the footprint of StepLong, StepDouble, and AtomicDouble.
e1fdb84
to
645a878
Compare
Will need to do some testing on this, probably won't have time this week. |
Since the |
The common operations are now available directly on the StepLong/StepDouble.
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.
I think this should be good. Throughput reduction seems fairly minimal. Do you mind doing a sanity check of the commit I pushed to use the updater pattern for the current field on StepLong and StepDouble?
Looks good to me. |
Use AtomicLongFieldUpdater to shrink the footprint of StepLong, StepDouble, and AtomicDouble.
From a heapdump for a typical app, we see tens of thousands of instances of these classes:
StepLong: 21,751 instances
StepDouble: 29,233 instances
AtomicDouble 31,822 instances
Getting rid of the object reference to an AtomicLong shrinks the allocation footprint and avoids the extra pointer chasing. Note that StepLong and StepDouble still have a field
current
that is an AtomicLong / AtomicDouble; it can't be inlined into a volatile field without breaking backwards compatibility since it is exposed via thegetCurrent
method.