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

Java 21 virtual threads #398

Closed
wants to merge 1 commit into from

Conversation

eivanov89
Copy link

@eivanov89 eivanov89 commented Nov 26, 2023

This patch adds an option "vt" to use virtual threads instead of real OS threads (#395).

@bpkroth
Copy link
Collaborator

bpkroth commented Dec 1, 2023

Can you please separate out the switch to java 21?

@bpkroth
Copy link
Collaborator

bpkroth commented Dec 1, 2023

Looks like this needs to come after #399 as well.

@eivanov89
Copy link
Author

eivanov89 commented Dec 4, 2023

Looks like this needs to come after #399 as well.

I'm sorry, that is my fault. I've just pushed clean branch now.

pom.xml Outdated Show resolved Hide resolved
@bpkroth bpkroth mentioned this pull request Dec 7, 2023
bpkroth added a commit that referenced this pull request Dec 13, 2023
Separates a conversion to Java 21 from #398 and also handles errors
encountered in #369.
@@ -87,6 +87,11 @@ public static void main(String[] args) throws Exception {
intervalMonitor = Integer.parseInt(argsLine.getOptionValue("im"));
}

Boolean useVirtualThreads = false;
if (argsLine.hasOption("vt")) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you add a long form --virtual-threads option as well?

Please also make sure the --help output is updated.

Copy link
Author

@eivanov89 eivanov89 Dec 14, 2023

Choose a reason for hiding this comment

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

Ouch, I forgot to add the option at all. Done now:

usage: benchbase
...
 -vt,--virtual-threads <arg>    Use virtual threads instead of real
                                threads

@bpkroth
Copy link
Collaborator

bpkroth commented Dec 14, 2023

@eivanov89 #416 and others made a bunch of changes to the repo at large. Can you please rebase against and updated main and resolve the conflicts?

If you're using the devcontainer for development, you'll probably want to rebuild it too.

@eivanov89
Copy link
Author

@bpkroth sure, pushed the rebased branch.

@bpkroth
Copy link
Collaborator

bpkroth commented Dec 15, 2023

@bpkroth sure, pushed the rebased branch.

Looks like it's still got conflicts listed.

Also, can you please think about a way to add tests for this feature?

@eivanov89
Copy link
Author

@bpkroth sure, pushed the rebased branch.

Looks like it's still got conflicts listed.

I'm sorry for this. Forgot that my main is fork's main :) This time, did the proper rebase.

Also, can you please think about a way to add tests for this feature?

Unfortunately I don't have enough time to work on this further. Also, the feature depends on DB client implementation. For example, I use postgres + c3p0 patch + vthreads. There was a deadlock:

  • we get session for each TPC-C transaction.
  • c3p0 has a session pool limited in size
  • session holders do network I/O. And network I/O frees carrier thread until virtual thread is ready to execute
  • when there're no sessions available, c3p0 calls Object.wait(), which blocks carrier thread
  • benchbase ended in situation, when all carrier threads are blocked by Object.wait()

Your vanilla postgres impl should work though. I fixed our version by adding a sessions semaphore (waiting on it doesn't block carrier thread), so that c3p0 never calls Object.wait(). I'll check if I can bring patch with c3p0 and the semaphore. c3p0 looks like a very useful addition.

@bpkroth
Copy link
Collaborator

bpkroth commented Dec 15, 2023

@bpkroth sure, pushed the rebased branch.

Looks like it's still got conflicts listed.

I'm sorry for this. Forgot that my main is fork's main :) This time, did the proper rebase.

Also, can you please think about a way to add tests for this feature?

Unfortunately I don't have enough time to work on this further. Also, the feature depends on DB client implementation. For example, I use postgres + c3p0 patch + vthreads. There was a deadlock:

  • we get session for each TPC-C transaction.
  • c3p0 has a session pool limited in size
  • session holders do network I/O. And network I/O frees carrier thread until virtual thread is ready to execute
  • when there're no sessions available, c3p0 calls Object.wait(), which blocks carrier thread
  • benchbase ended in situation, when all carrier threads are blocked by Object.wait()

Your vanilla postgres impl should work though. I fixed our version by adding a sessions semaphore (waiting on it doesn't block carrier thread), so that c3p0 never calls Object.wait(). I'll check if I can bring patch with c3p0 and the semaphore. c3p0 looks like a very useful addition.

Sounds good. We're happy to take a PR for both, but it's always good to have a test associated with new features to make sure we continue to support them in the future and they don't break existing functionality.

@eivanov89 eivanov89 closed this Feb 6, 2024
@eivanov89
Copy link
Author

I had missed the point, that there are a lot of synchronized inside the benchmark, which should be rewritten at first.

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.

Consider using Java >= 21 to allow usage of virtual threads
2 participants