Single Thread Continuation

[Attila Kelemen]

>
>
> There is no need to for specific generator support in Java when you have
> cheap virtual threads.
>
>
 I don't think this statement is valid.

1. The JVM can implement generators more efficiently. It doesn't need the
extra queue that a custom implementation does.

2. It is not obvious in a custom implementation when the generator is
unreachable for the GC, because it will only become unreferenced after you
detect it via the weak/phantom reference. So, a custom implementation
behaves differently in an OOM situation, where in a custom implementation
the JVM will throw an OOM error, even if there would be enough memory after
reclaiming the generator (and whatever it retains), while that might not be
the case for a JVM provided implementation.

3. For many generators not requiring a close, you don't need to exit the
loop, which you can only do with an exception, but rather you can just
abruptly stop executing the thread (something you can't do safely, but the
JVM could). It is not obvious from your implementation, but in a general
implementation (I have provided mine for reference [1], note that I'm using
my own queue implementation which I didn't include in the gist) you will
need an exception to exit the loop which might be undesirable.

4. Even if we don't care about the above, your statement still does not
hold, because by your reasoning no collection implementation is required as
well, since you could implement it yourself. The generators however are
very useful in a lot of cases, and are well justified to have an
implementation in the JDK. Especially since there are a lot of subtleties
that can go wrong, there is no need to force the community to create a lot
of different implementations with their own separate bugs or strange
behaviour.

side note: About the "buffered queue", I don't think a core generator
utility would be a good place for this. It is possible to implement such a
thing on the top of a simple handoff queue (or equivalent) generator.

[1]: https://gist.github.com/kelemen/f01321cece0898e5d448a8b1217ec075

ps.: The linked implementation requires JDK 21. It doesn't work on JDK 20,
because `ReferenceQueue.remove` seems to never return (or at least, there
are circumstances when it never does) on a VT in JDK 20 (but does on a
normal thread).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230704/a0e04f69/attachment-0001.htm>