Continuations - Under the Covers

Подписаться 182 тыс.

Просмотров 12 тыс.

50% 1

Presented by Ron Pressler - Architect (Java Platform Group - Oracle) during the JVM Language Summit 2023 (Santa Clara CA).
⎯⎯⎯⎯⎯⎯ Resources ⎯⎯⎯⎯⎯⎯
◦ • The Challenges of Intr...
◦ JEP 444: Virtual Threads ➱ openjdk.org/je...
◦ Repository (several branches) ➱ github.com/ope...
◦ Mailing list ➱ mail.openjdk.o....
◦ More information on Panama ➱ inside.java/ta...
Make sure to check the • JVM Language Summit 2023 playlist.
Tags: #JVMLS #Java #ProjectLoom #OpenJDK

Опубликовано:

7 сен 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 18

@andrybak 5 месяцев назад

audio glitch at 19:39 is a tiny bit frightening

@prdoyle Год назад

Did you consider having the barrier restore more than one frame at a time for large chunks? I imagine you'd want to restore a minimum of N bytes in order to amortize the overhead of the barrier itself.

@Blobjim Год назад

I think he talks about this at 27:48. It looks like they do have a heuristic for thawing an entire StackChunk (multiple/many frames). the main case where they can't is when it's interpreted code. It sounds like it doesn't necessarily need frame-by-frame barriers when you have a StackChunk. 31:12 has a visual demo of it.

@StephenBuergler Год назад

Would it be possible to just like... change the stack pointer over to wherever you had memory allocated to store the continuation stack instead of copying stuff? How does golang work?

@berndeckenfels 11 месяцев назад

Not easily, since the part below the run entry (top of stack) is not in the copy as it can be different

@dobrin.ivanov 5 месяцев назад

I was about to ask the same question :) I'm not familiar with such a low level programming but ChatGPT says for x86 you can do that - changing ESP/RSP. I guess you would only need to take care when your java thread exits but in the video Ron showed some tricks so it could be workarounded?

@lapissea1190 Год назад

Continuations not being a public api is one of the biggest letdowns in the loom project. Opening them up to public would be such a new and unique feature. I'm sure people are creative enough to do some powerful stuff with it like emulating a C# generator function

@prdoyle Год назад

The biggest letdown is that structured concurrency is still in preview. 😃 Seriously, with the pace of improvements in Java the last couple of years, I think we'll see continuations become a public API before too long, and I'm glad they're taking their time to get it right.

@lapissea1190 Год назад

@@prdoyle Really hope so! Although for my personal work, I have been rocking the preview features enabled since java 12 so it is not a too big deal. Got plenty of experience with them already and v threads are basically a stable api now and I would be very surprised if anything changes at this point api wise.

@edmaphis9805 Год назад

From what I've read on the mailing list, they intend on providing a public, safe interface to continuations. They don't now, because improperly using continuations can lock up or crash the JVM and the implementation and API is subject to change. In the meantime, you can access continuations by passing flags to the compiler and interpreter.

@lapissea1190 Год назад

@@edmaphis9805 Oh, I did not realize there were issues with locking up the JVM as a whole. That's a shame. Hopefully they can work it out! Also yeah I am aware you can turn off module restrictions but it's not really something I'd like to do. It feels the same as setting a final field with unsafe. You *can* do it, but should you?

@stcattc Год назад

there is 0 reason not to use preview features in prod. Even if you do an upgrade to a later java version the refactoring cost is minimal if they make a breaking change. No more effort than a major version upgrade of a library. The benefits of using them great out weigh the downsides of a potential breaking change. Especially with the 6 monthly cadence. If you can keep up with regular java upgrades it's a no brainier.

@krellin 9 месяцев назад

Its clever what they do with performance but i straight up compare loom to kotlin coroutines. Sadly loom is basically internal api that we cant make new things with. While with suspended functions we can do whatever new features we need... async/await is not a SDK its something the user can define and implement. Imo they should focus on making loom open in a similar way.

@maruseron 8 месяцев назад

Loom Virtual Threads and Kotlin Coroutines use the same fundamental abstraction (Continuations) - the only difference is that Loom does not provide a public API for defining computations that give up their control back to the caller and can be resumed later. These exist in loom, and are arguably more powerful than Kotlin coroutines - they're just not publicly available yet since they're unstable.

@krellin 8 месяцев назад

@@maruseron nice, but why do you think they are more powerful? kotlin wasnt stable from day 1 either but we have @experimental which exposed would be public api to people who are potentially going to use it and can provide valuable feedback... they changed the public api over time before release.

@maruseron 8 месяцев назад

@@krellin Loom continuations are more powerful because they're stackful. In Kotlin, coroutine suspension can only happen within the context of the coroutine's own call (stack depth wise). In contrast, Loom continuations can be suspended from anywhere in the call stack: you can delegate the yielding to a method call within your continuation, rather than the continuation itself.