Java 21 virtual threads

[eivanov89]

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

[bpkroth]

Can you please separate out the switch to java 21?

[bpkroth]

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

[eivanov89]

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

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

[bpkroth]

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

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

[eivanov89]

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]

@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]

@bpkroth sure, pushed the rebased branch.

[bpkroth]

@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]

@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]

@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]

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