5 ms·
> So having virtual threads and "raw" threads under the same class has pros and cons, IMO. That's one way to think about it. Another is that Java never gives y
by pron 6y ago
> So having virtual threads and "raw" threads under the same class has pros and cons, IMO.
That's one way to think about it. Another is that Java never gives you "OS threads" it always gives you Java threads, an abstraction with multiple possible implementations. One implementation is no more real or raw than the other (in fact, you could even theoretically make virtual threads the carriers for other virtual threads -- a thread is a thread, after all -- but we explicitly blocked that because it's not useful). There is no real difference between that and ArrayList and LinkedList both implementing the same List interface. They're both just as real, but they have different footprint and performance (the class hierarchy for threads is slightly different, but for uninteresting technical reasons).
> Or do you still disagree?
I still disagree. That network call might take 1ms, and that bit fiddling might trigger a GC collection that takes 10 times that or more. Moreover, neither Kotlin nor C# mark long subroutines with a different colour, and they don't even mark blocking calls with a different colour, just the flavour of them that's to be used with coroutines. The real reason that colour is necessary is because of the way the feature is implemented.
Originally, that colour meant to signify something else: nondeterminism in mostly-deterministic languages like Haskell, and it is also important in JavaScript. Trying to retroactively find a useful meaning for it in Java is an excuse.
- ragnese 6y agoFair point about the abstraction level of a Java thread vs an OS thread. In light of both things you just wrote, let me ask you this: why does Java give us any choice on thread implementation? Why not have everything be a green thread from now on? If Java threads are not OS threads, can be paused for any amount of time, and there's no reason that network calls or db calls or file IO should be treated any differently, then I'm not sure why the old Java Threads shouldn't be deprecated. Can you shine some light on that? After Loom drops, when would I ever want something other than a green thread?
- pron 6y agoThe first part of the answer is the same as that for a similar question we've been asked about LinkedList: we don't deprecate things that are heavily used, however useless or superseded by something else, unless they are very harmful. Deprecation in Java does not mean "unrecommended" but "absolutely do not use this if you want your program to continue working on future versions." Not only is it a compile-time warning, but JDK tooling even checks for uses of deprecated APIs in binaries and warns about them. Ideally, deprecated usages should break people's builds. In other words, deprecation is a big deal and not taken lightly. We might need another standardised term for "unrecommended" or "superseded". The second part of the answer is that there are still good uses cases for heavyweight threads, that are backed by one OS thread. For example, as carriers for virtual threads or parallel streams, i.e. as approximations of CPU cores, and also for cases where FFI is used for IO or some other native interaction. This is very rare in Java, but very rare could mean "used only in tens of thousands of programs rather than tens of millions".
- Cojen 6y agoAre virtual threads preemptable? If not, then one use for OS threads is when running a bunch of compute intensive tasks and you don't want worry about stalling everything else. I suppose in that case you could just use a separate executor for those expensive tasks. I wonder how many devs will spawn tasks using the default executor and then wonder why things aren't working out so well? Will there be tooling to help identify such issues?
- pron 6y ago> Are virtual threads preemptable? Yes, but the preemption operation is not currently publicly exposed. We're considering whether and how to expose it. > I wonder how many devs will spawn tasks using the default executor and then wonder why things aren't working out so well? Will there be tooling to help identify such issues? What those issues would actually be, in practice, is still unclear, hence our reluctance to expose forced preemption. People rely on OS time-sharing (what you call preemption) inside applications far less than they think. No scheduling algorithm can make a program that requires more processing resources than available to run well.
- ragnese 6y ago> The second part of the answer is that there are still good uses cases for heavyweight threads, that are backed by one OS thread. Hold the phone. Didn't you just say a few comments up that I shouldn't think of a "Java thread" like an "OS thread"? If I use a Thread, today, how do I know if it's corresponding to an OS thread? I understand that it will, theoretically, depend on the platform on which the JVM is running. But on a non-exotic platform (x86/ARM Windows, Linux, macOs, Android, etc), does one Java Thread map to one OS Thread or not?
- pron 6y agoI meant that a Java thread, like the List interface, is an abstraction with multiple implementations for you to choose from. In OpenJDK (i.e. the Oracle implementation of Java) today, a Java thread is implemented as a wrapper of an OS thread; I believe OpenJ9, the IBM implementation, does the same. But the Java specification does not require it. Loom might change the specification to require it, or leave the implementation of "platform threads" (i.e. non-virtual threads) up to the specific Java implementation.