Single Thread Continuation

[Robert Engels]

I don’t believe any of those statements are true. Even if the language supported generators directly - they are still subject to gc. The JVM needs a way to release the generator and it’s backing resources. If it did that directly - like a destructor - when it goes out of scope it still wouldn’t be able to release the other resources. 

When you use virtual threads the framework is doing everything that would need to happen to implement generators directly - and just as efficiently. Virtual threads are continuations. 

Only the most basic of generators can be implemented without other JVM resources and library calls - and there are easier ways to do the simple generators (streams, etc). 

You understanding of how OOM and GC works is not correct. 

My implementation does not require a queue (unless you consider a handoff variable a queue) or exceptions. 

I think you’ll find the implementation I shared to be very efficient - and it was a super quick effort. An atomic CAS and LockSupport would make it even more so - but any complex generator will dominate the performance over the handoff infrastructure. 

> On Jul 4, 2023, at 9:59 AM, Attila Kelemen <attila.kelemen85 at gmail.com> wrote:
> 
> 
>> 
>> 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/64d35710/attachment.htm>