Generators built on virtual threads?

[Daniel Avery]

For fun, I was experimenting to see what an API for python/JS-esque
'generators' could look like, if it were built on top of virtual threads.

project link: https://github.com/davery22/java-generator-experiment

(Forgive that I called virtual threads "Java coroutines" in the readme. It
just occurred to me that they are similar to Kotlin coroutines, but without
the red-blue coloring issue. I am interested if people would characterize
calling them "coroutines" as fair, misleading, or just wrong.)

I did a very rough performance test in Main.java, ie just printing out
elapsed time for a process that has a generator yield the numbers from 0 to
1000000, and sums them in the main thread. I compared to a python
implementation in test.py. On my machine, my java implementation runs about
100x slower than my python implementation. If I change the java
implementation to use a newSingleThreadExecutor, it runs about 20% faster.

(Specifically, when I run Main.java, it prints an elapsed time of around 10
sec. When I run python3 test.py, it prints an elapsed time of
around 0.1-0.2 sec.)

I am familiar enough with the difference in mechanism between java
(threads) and python (continuations) that this wasn't very surprising. (I
would have been astounded if the execution times were comparable.) But, I
still tried to prove to myself that the slowness was coming from
context-switching/thread-scheduling overhead. My implementation relies on a
synchronization mechanism I called PingPong, that provides the blocking
next/yield methods. I tried a couple other (hacky) implementations of
PingPong to try to verify where the slowness was coming from, which I
discuss in the readme.

My questions are:

Can we confirm that the execution time I am observing is expected?
Are generators a reasonable use case for virtual threads?
Will it ever be possible to implement generators efficiently in Java? (eg
is there room to reduce the context-switching overhead of virtual threads,
or, is there a possibility of exposing a more efficient primitive to build
on top of in the future (eg continuations?))

Thanks,
Daniel