You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I see that there are no direct fields that are going to be modified between the 2 layers of padding of the counters....it's necessary?
Just loading the load[] field probably isn't enough to justify the heavy padding around it, until the long[] won't be inlined in the owner class, wdyt?
The text was updated successfully, but these errors were encountered:
The padding is there to protect the loaded field from contention induced by unfortunate placing next to fast updating memory locations. Is that important enough? not sure.
The padding is there to protect the loaded field from contention induced by unfortunate placing next to fast updating memory locations. Is that important enough? not sure.
In this case maybe would worth to drop it, if we assume that on a monitoring framework we would like to create several counters and some of the motivation of using FixedSizeStripedLongCounter vs LongAdder could be the memory footprint: we need some user feedback on this :D
I see that there are no direct fields that are going to be modified between the 2 layers of padding of the counters....it's necessary?
Just loading the load[] field probably isn't enough to justify the heavy padding around it, until the long[] won't be inlined in the owner class, wdyt?
The text was updated successfully, but these errors were encountered: