<div dir="ltr"><div dir="ltr">Robert Engels <<a href="mailto:rengels@ix.netcom.com">rengels@ix.netcom.com</a>> ezt írta (időpont: 2023. júl. 5., Sze, 0:48):<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">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. </div><div dir="ltr"><br></div></div></blockquote><div><br></div><div>It is not about being subject to GC or not. My claim is the following: With JVM implementation, it could be that:</div><div><br></div><div>Iterator is unreachable -> Continuation is unreachable -> Generator is unreachable</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><br></div><div dir="ltr">You understanding of how OOM and GC works is not correct. </div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><br></div><div dir="ltr">My implementation does not require a queue (unless you consider a handoff variable a queue) or exceptions. </div><div dir="ltr"><br></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">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. </div><div dir="ltr"></div><blockquote type="cite"><div dir="ltr"><br></div></blockquote></div></blockquote><div><br></div><div>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).</div><div><br></div><div>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.</div></div></div>