4 ms·

Waiting for project loom [1] [1] https://openjdk.java.net/projects/loom/ https://openjdk.java.net/projects/loom/

jacques_chester 6y ago
I am unreasonably excited by Loom, for two reasons: 1. I cannot wrap my head around library-based reactive systems. I have tried and tried and continue to try. But they're like some of the original Go4 design patterns: they exist to solve the language, not the problem. Loom's promise to make steam-powered linear code behave mostly like a fully-dressed reactive library system is extremely welcome. 2. Structured concurrency. Among the entries on the thick tablet of hatreds of Golang that I carry upon my heart, mystery action at a distance due to go(to) routines appears infrequently but painfully. Like so many Go features they conspire against composability and testability. Structured concurrency looks like an escape from the madness. Please let it be true.
- KptMarchewa 6y ago
  What's the difference in programming model (not implementation) between Loom and goroutines?
  - jacques_chester 6y ago
    Briefly, that a thread cannot escape a scope. All threads must be joined before leaving the scope. Some resources: https://wiki.openjdk.java.net/display/loom/Structured+Concurrency https://wiki.openjdk.java.net/display/loom/Structured+Concur... https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.html#structured-concurrency https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.... https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
    - thu2111 6y ago
      Not exactly. That's the programming rule for structured concurrency which is a very simple bit of logic added on to the ExecutorService class. Loom itself is just about making threads super cheap/fast. You can use new cheap threads in exactly the same way as normal and nothing will complain. You can also use structured concurrency with old threads, and again, nothing will complain. And you don't need Java support for structured concurrency. You could implement it today with some wrapper classes.
      - jacques_chester 6y ago
        No, not exactly. Thus ever the fate of tl;drs. The discussion further down about "scope variables" foreshadows making structured concurrency more strongly, directly supported by the language's runtime: > What about inheritance? Because SVs are immutable, and because structured concurrency also gives us a syntax-confined thread lifetime, SV inheritance fits structured concurrency like a glove
        thu2111 6y ago
        Scoped vars are nice but I never saw anyone claim they're a required part of structured concurrency. They're mostly an optimisation over ThreadLocal.
        jacques_chester 6y ago
        I never said required.
- crudbug 6y ago
  Agreed ! Current reactive code is littered with async/await for every IO function, which feels like they are trying to bolt reactive behavior. Library-based threading model provide the sync thinking with optimized async compute model.
- The_rationalist 6y ago
  What you're waiting for is already available with Kotlin coroutines (which has a very clean API btw) And no reactive streams still are useful for processing collection streams asynchronously and here again kotlin solve it all https://kotlinlang.org/docs/flow.html https://kotlinlang.org/docs/flow.html
  - jacques_chester 6y ago
    I like Kotlin coroutines and I've used them, but they (this argument is controversial) have a function colouring problem. As the JVM adds virtual threads I expect that a rebasing of Kotlin's coroutines will remove that objection. Plus, sometimes, I want to use Java.
    - ta988 6y ago
      Also debugging with them can be quite painful. It is getting better, but I still pull my hair frequently.
- gher-shyu3i 6y ago
  What do you mean by structured concurrency? Do you mean hierarchy management?
  - BenoitP 6y ago
    Sort of. Here is the original proposal often referred to by Loom's architects: https://250bpm.com/blog:71/ https://250bpm.com/blog:71/ Here is what the wiki has to say: https://wiki.openjdk.java.net/display/loom/Structured+Concurrency https://wiki.openjdk.java.net/display/loom/Structured+Concur...
iso1631 6y ago
To me, Loom will always be the latest masterpiece of fantasy storytelling from Lucasfilm's™ Brian Moriarty™
cpleppert 6y ago
Worth keeping in mind that the implementation they have chosen of stack copying from the heap has a larger performance overhead than something like Go which was designed around green threads/fibers/virtual threads/ etc. from the start. If you can keep your stack size very low in each task then this probably won’t be noticeable if you are doing lots of IO which can trigger wakeups. More of a replacement for an async/await state machine for handling a request than something like a goroutine you could use for everything. I have a feeling lots of existing Java libraries and frameworks won’t work well with it. Will be interesting to see how it plays out.
- kaba0 6y ago
  The technical details are way out of my league, but I remember reading that stack copying can be made really cheap somehow? Perhaps due to the JVM having more abstraction below a virtual thread than Go?
  - aardvark179 6y ago
    Many virtual threads won’t have large stacks, and many others will not substantially grow or shrink their stacks between yields. You only need to copy stack frames from the heap as they are needed (so as the stack unwinds) and you only need to copy new stack frames to the heap when a thread yields. With a few other clever tricks this can really reduce the data that has to be copied. We can do these tricks because we know lots of properties of the Java stack, and they give a different set of trade offs to Go’s approach.
    - thu2111 6y ago
      Specifically, the JVM knows there are no pointers into the stack because Java and bytecode cannot express: int a = 1; int *b = &a; Or rather, this construct can occur, but it's always the decision of the JIT compiler to emit such code and it is cooperating with the rest of the runtime.

I am unreasonably excited by Loom, for two reasons: 1. I cannot wrap my head around library-based reactive systems. I have tried and tried and continue to try. But they're like some of the original Go4 design patterns: they exist to solve the language, not the problem. Loom's promise to make steam-powered linear code behave mostly like a fully-dressed reactive library system is extremely welcome. 2. Structured concurrency. Among the entries on the thick tablet of hatreds of Golang that I carry upon my heart, mystery action at a distance due to go(to) routines appears infrequently but painfully. Like so many Go features they conspire against composability and testability. Structured concurrency looks like an escape from the madness. Please let it be true.

KptMarchewa 6y ago
What's the difference in programming model (not implementation) between Loom and goroutines?
- jacques_chester 6y ago
  Briefly, that a thread cannot escape a scope. All threads must be joined before leaving the scope. Some resources: https://wiki.openjdk.java.net/display/loom/Structured+Concurrency https://wiki.openjdk.java.net/display/loom/Structured+Concur... https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.html#structured-concurrency https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.... https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
  - thu2111 6y ago
    Not exactly. That's the programming rule for structured concurrency which is a very simple bit of logic added on to the ExecutorService class. Loom itself is just about making threads super cheap/fast. You can use new cheap threads in exactly the same way as normal and nothing will complain. You can also use structured concurrency with old threads, and again, nothing will complain. And you don't need Java support for structured concurrency. You could implement it today with some wrapper classes.
    - jacques_chester 6y ago
      No, not exactly. Thus ever the fate of tl;drs. The discussion further down about "scope variables" foreshadows making structured concurrency more strongly, directly supported by the language's runtime: > What about inheritance? Because SVs are immutable, and because structured concurrency also gives us a syntax-confined thread lifetime, SV inheritance fits structured concurrency like a glove
      - thu2111 6y ago
        Scoped vars are nice but I never saw anyone claim they're a required part of structured concurrency. They're mostly an optimisation over ThreadLocal.
        jacques_chester 6y ago
        I never said required.
crudbug 6y ago
Agreed ! Current reactive code is littered with async/await for every IO function, which feels like they are trying to bolt reactive behavior. Library-based threading model provide the sync thinking with optimized async compute model.
The_rationalist 6y ago
What you're waiting for is already available with Kotlin coroutines (which has a very clean API btw) And no reactive streams still are useful for processing collection streams asynchronously and here again kotlin solve it all https://kotlinlang.org/docs/flow.html https://kotlinlang.org/docs/flow.html
- jacques_chester 6y ago
  I like Kotlin coroutines and I've used them, but they (this argument is controversial) have a function colouring problem. As the JVM adds virtual threads I expect that a rebasing of Kotlin's coroutines will remove that objection. Plus, sometimes, I want to use Java.
  - ta988 6y ago
    Also debugging with them can be quite painful. It is getting better, but I still pull my hair frequently.
gher-shyu3i 6y ago
What do you mean by structured concurrency? Do you mean hierarchy management?
- BenoitP 6y ago
  Sort of. Here is the original proposal often referred to by Loom's architects: https://250bpm.com/blog:71/ https://250bpm.com/blog:71/ Here is what the wiki has to say: https://wiki.openjdk.java.net/display/loom/Structured+Concurrency https://wiki.openjdk.java.net/display/loom/Structured+Concur...

iso1631 6y ago

To me, Loom will always be the latest masterpiece of fantasy storytelling from Lucasfilm's™ Brian Moriarty™

cpleppert 6y ago

Worth keeping in mind that the implementation they have chosen of stack copying from the heap has a larger performance overhead than something like Go which was designed around green threads/fibers/virtual threads/ etc. from the start. If you can keep your stack size very low in each task then this probably won’t be noticeable if you are doing lots of IO which can trigger wakeups. More of a replacement for an async/await state machine for handling a request than something like a goroutine you could use for everything. I have a feeling lots of existing Java libraries and frameworks won’t work well with it. Will be interesting to see how it plays out.

kaba0 6y ago
The technical details are way out of my league, but I remember reading that stack copying can be made really cheap somehow? Perhaps due to the JVM having more abstraction below a virtual thread than Go?
- aardvark179 6y ago
  Many virtual threads won’t have large stacks, and many others will not substantially grow or shrink their stacks between yields. You only need to copy stack frames from the heap as they are needed (so as the stack unwinds) and you only need to copy new stack frames to the heap when a thread yields. With a few other clever tricks this can really reduce the data that has to be copied. We can do these tricks because we know lots of properties of the Java stack, and they give a different set of trade offs to Go’s approach.
  - thu2111 6y ago
    Specifically, the JVM knows there are no pointers into the stack because Java and bytecode cannot express: int a = 1; int *b = &a; Or rather, this construct can occur, but it's always the decision of the JIT compiler to emit such code and it is cooperating with the rest of the runtime.