6 ms·

"Virtual threads" are fibers? When you say they aren't cooperative, you mean there's JVM infrastructure that actually pre-empts a fiber?

by haxen 6y ago

pron 6y ago
> "Virtual threads" are fibers? Yes, but we found that the name "virtual thread" works better. For one, these fibres are actually an implementation of java.lang.Thread, so it's the same abstraction; for another, when people hear "fibres" they sometimes compare it to other implementations of fibres that are implemented very differently, and that causes confusion. > When you say they aren't cooperative, you mean there's JVM infrastructure that actually pre-empts a fiber? First, I mean that they don't require any explicit yields. Sometimes people confuse "preemptive" with "time-sliced preemption", so I'd rather just say "non-cooperative". Second, there is a capability to forcefully preempt a virtual thread even if it's in some computation loop, but that's up to a chosen scheduler, and the scheduler isn't part of the JVM. You can supply your own scheduler, written in Java, and you'll be able to choose to preempt a runaway thread. Currently, this capability is not exposed, but it will be eventually. See http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h...
- haxen 6y ago
  > I mean that they don't require any explicit yields. So in this sense, are Kotlin coroutines also non-cooperative? They don't explicitly yield, but do have a mandatory API to use for "blocking" calls.
  - pron 6y ago
    They do explicitly yield, although not with an explicit keyword or call, but with an explicit type. I guess you could say that the "await" is inferred by the compiler, but it's there. That's not the case with virtual threads, which behave more like Go's goroutines or Erlang's processes.
    - nahuel0x 6y ago
      Can a Loom scheduler kill a virtual thread in an arbitrary execution point (like Erlang process but unlike goroutines)?
      - haxen 6y ago
        http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.html#forced-preemption http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.h... Yes it can and actually it's quite low-hanging fruit on the JVM. GC safepoints are already there, you just have hook into the mechanism.
        pron 6y ago
        True, but it heavily depends on what you mean by "can." Doing it safely in Java is a problem, as Java code does not protect from shared state. So I would say it's "sort-of, but not really, as it would be very dangerous unless you know exactly what the thread is doing." On the other hand, if the question is, if Erlang were implemented on the Java platform using virtual threads as processes, would code be able to kill a process arbitrarily, then the answer would be yes.
        nahuel0x 6y ago
        It can be useful for killing a clojure virtual thread who only uses shared memory by reading thread-safe persistent data structures and writes only to clojure atoms/STM (besides his unshared local state). If this is possible, then Loom + clojure can be a better model than erlang for some usages. Myriads of linked actors but with the added feature of shared memory for global views (see Rich Hickey criticism of the actor model) and optimized message passing (you don't need to copy messages if you have a global GC and they are clj persistent data structures). But external killing of a linked actor/vthread -one of erlang usually ignored secret sauces- is fundamental, if not, you need adhoc mechanisms like Go cancellation contexts who IMHO adds a lot of error prone accidental complexity. Think usages beyond supervisors/fault-tolerance like killing obsolete requests/computation or speculative execution.

"Virtual threads" are fibers? When you say they aren't cooperative, you mean there's JVM infrastructure that actually pre-empts a fiber?

by haxen 6y ago

"Virtual threads" are fibers? When you say they aren't cooperative, you mean there's JVM infrastructure that actually pre-empts a fiber?

pron 6y ago

> "Virtual threads" are fibers? Yes, but we found that the name "virtual thread" works better. For one, these fibres are actually an implementation of java.lang.Thread, so it's the same abstraction; for another, when people hear "fibres" they sometimes compare it to other implementations of fibres that are implemented very differently, and that causes confusion. > When you say they aren't cooperative, you mean there's JVM infrastructure that actually pre-empts a fiber? First, I mean that they don't require any explicit yields. Sometimes people confuse "preemptive" with "time-sliced preemption", so I'd rather just say "non-cooperative". Second, there is a capability to forcefully preempt a virtual thread even if it's in some computation loop, but that's up to a chosen scheduler, and the scheduler isn't part of the JVM. You can supply your own scheduler, written in Java, and you'll be able to choose to preempt a runaway thread. Currently, this capability is not exposed, but it will be eventually. See http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h...

haxen 6y ago
> I mean that they don't require any explicit yields. So in this sense, are Kotlin coroutines also non-cooperative? They don't explicitly yield, but do have a mandatory API to use for "blocking" calls.
- pron 6y ago
  They do explicitly yield, although not with an explicit keyword or call, but with an explicit type. I guess you could say that the "await" is inferred by the compiler, but it's there. That's not the case with virtual threads, which behave more like Go's goroutines or Erlang's processes.
  - nahuel0x 6y ago
    Can a Loom scheduler kill a virtual thread in an arbitrary execution point (like Erlang process but unlike goroutines)?
    - haxen 6y ago
      http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.html#forced-preemption http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.h... Yes it can and actually it's quite low-hanging fruit on the JVM. GC safepoints are already there, you just have hook into the mechanism.
      - pron 6y ago
        True, but it heavily depends on what you mean by "can." Doing it safely in Java is a problem, as Java code does not protect from shared state. So I would say it's "sort-of, but not really, as it would be very dangerous unless you know exactly what the thread is doing." On the other hand, if the question is, if Erlang were implemented on the Java platform using virtual threads as processes, would code be able to kill a process arbitrarily, then the answer would be yes.
        nahuel0x 6y ago
        It can be useful for killing a clojure virtual thread who only uses shared memory by reading thread-safe persistent data structures and writes only to clojure atoms/STM (besides his unshared local state). If this is possible, then Loom + clojure can be a better model than erlang for some usages. Myriads of linked actors but with the added feature of shared memory for global views (see Rich Hickey criticism of the actor model) and optimized message passing (you don't need to copy messages if you have a global GC and they are clj persistent data structures). But external killing of a linked actor/vthread -one of erlang usually ignored secret sauces- is fundamental, if not, you need adhoc mechanisms like Go cancellation contexts who IMHO adds a lot of error prone accidental complexity. Think usages beyond supervisors/fault-tolerance like killing obsolete requests/computation or speculative execution.