Single Thread Continuation

[Attila Kelemen]

Robert Engels <rengels at ix.netcom.com> ezt írta (időpont: 2023. júl. 5.,
Sze, 0:48):

> 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.
>
>
It is not about being subject to GC or not. My claim is the following: With
JVM implementation, it could be that:

Iterator is unreachable -> Continuation is unreachable -> Generator is
unreachable

The point is that in custom VT based implementation the JVM cannot know
this, because a code will have to terminate the generator loop first, while
the JVM doesn't have to (similarly as done in Kotlin, if I'm not mistaken).
Potentially delaying the cleanup of some VT related resources is not that
big of a deal. Delaying the unreachability of the generator might be.


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

Can you clarify what exactly you are referring to? My claim is that, if the
generator retains a large object (like a large array), then in a VM based
implementation the JVM can see that the generator is unreachable, if the
iterator is unreachable. Thus, in case it needs a lot of memory, it can
conclude that there is no need for OOM. In a custom VT bsed case, there is
no such chance, because it can't possibly know that the generator will soon
be unreachable.


>
> My implementation does not require a queue (unless you consider a handoff
> variable a queue) or exceptions.
>
>
Yes, I'm referring to that. You yourself called that a "hand-off queue" as
well. It doesn't matter how you implement it, it is still a queue.


> 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.
>
>
>
It is very efficient given your possibilities, but the JVM could do better,
because it doesn't need a queue. In fact, it can just immediately change
the context on the same carrier thread in `Iterator.next`, and doesn't even
need to involve the queue for VT (let alone the extra queue a
custom implementation needs atop of that).

As for the "super quick effort". Maybe, but your implementation is far from
complete, as there are a lot of additional things to deal with in the
general case (when you are not just inlining a simple counting loop),
obviously needs some cleanup, and also any implementation that is used in
serious code would require extensive testing. All of those are non-trivial
effort, and there is a lot of chance for bugs, and there would be no point
in forcing many-many people to go through that, when the JDK could just
provide a good and efficient implementation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230705/053ee76f/attachment.htm>