Skip to content
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

FixedSizeStripedLongCounter padding isn't too much? #333

Open
franz1981 opened this issue Jan 15, 2021 · 2 comments
Open

FixedSizeStripedLongCounter padding isn't too much? #333

franz1981 opened this issue Jan 15, 2021 · 2 comments
Labels

Comments

@franz1981
Copy link
Collaborator

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?

@nitsanw
Copy link
Contributor

nitsanw commented Feb 8, 2021

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.

@franz1981
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants