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

Improve performance of execute under contention by using flat combiners #91

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

franz1981
Copy link
Contributor

This is a kind of POC to improve performance of execute under heavy contention without modifying the original algorithm and assumptions.

@carterkozak @dmlloyd Feel free to both test and ask on the Zulipchat channel!!!

@carterkozak
Copy link
Contributor

I'm having a busy week, but I'm planning to read through this when I have time!

idleCount++;
}
return idleCount;
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can extract this IdleStrategy to a singleton and avoid allocation cost.

static IdleStrategy yield(int maxSpins) {
return idleCount -> {
if (idleCount < maxSpins) {
idleCount++;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these use onSpinWait? I think they'd need to move into the org.jboss.threads package for access.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think these factory methods are used, should they be?

int result;
result = tryExecute(realRunnable);
final int result;
try (TryExecuteTask tryExecuteTask = POOLED_COMBINER_TASKS.get().on(this, realRunnable)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if something like #81 would allow us to avoid this threadlocal in favor of a couple additional references on an existing object?

@carterkozak
Copy link
Contributor

I still don't fully understand the implementation, I'll need to stare at the code a bit longer.
My benchmark results are all over the place, I think there must be something wrong on my end, or possibly a race that can result in excessive link traversal, but it doesn't happen every run.

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

Successfully merging this pull request may close these issues.

None yet

2 participants