4 ms·

I am lost here. the non-goal mentioned here are actually worth taking as goals to be fulfilled so that every other language and library ecosystem which runs on

I am lost here. the non-goal mentioned here are actually worth taking as goals to be fulfilled so that every other language and library ecosystem which runs on JVM will get benefited. Non-Goals:- It is not a goal to change the existing implementation of platform threads, that represent Operating System (OS) threads. It is not a goal to automatically convert existing thread construction to virtual threads. It is not a goal to change the Java Memory Model. It is not a goal to add new inter-thread communication mechanisms. It is not a goal to offer a new data-parallelism construct in addition to parallel streams.

truth_seeker 5y ago
Its impossible say anything unfamiliar thing on HN, all kinds of morons are active all the time on HN to donwvote. ;) keep it up.
- kaba0 5y ago
  I did not downvote, but I guess you got those mostly because it was more of a statement on your part instead of a genuine question.
vincnetas 5y ago
backwards compatibility?
invalidname 5y ago
Those all make sense: - Native threads are great. They have a lot of uses, why touch them - Automatic conversion will break a lot of stuff and eliminate some of the benefits of native threads. Being able to use an API/implementation that is *almost* the same is a huge beneift - The memory model is a completely separate thing that Java worked on for decades. You don't want to touch that and you don't need to - Inter-thread communication is a separate thing. There's no reason to go after that. Same is true for the data parallelism stuff. The focus should be on hitting the 98% of what matters and getting it out without breaking everything we already have.
- jsmith45 5y ago
  While automatic conversion might be off the table, any library that expects (or allows) the caller to supply the ThreadFactory used to created thread will should make switching over pretty easy. Just construct the factory with `Thread.ofVirtual().factory()`, and provide it to the library. And if it is code you own, spawning threads, then switching over should be a pretty mechanical process. On the memory model: I'd argue that technically the memory model would be implicitly updated to treat these virtual threads the same as classic threads. Which is a very minor update. Beyond that, in order to maintain that memory model, the implementation will need to ensure proper barriers are used on pausing and resuming virtual threads, so that a virtual thread resumed on a different physical core is guaranteed to see any of its previous writes (as would be expected within a "single thread").
Twisol 5y ago
> It is not a goal to change the existing implementation of platform threads, that represent Operating System (OS) threads. > It is not a goal to automatically convert existing thread construction to virtual threads. Key word: automatically. If you want an OS thread, you should be able to get one. But if you simply spawn a task into a virtual thread, that task should behave basically the same as in a platform thread, but with less context switching overhead (and less strict claiming of OS resources). The locus of choice is at whichever part of the code constructs the threads to begin with; if you change it to use virtual threads, you shouldn't have to change anything else. > It is not a goal to change the Java Memory Model. Was there something you wanted changed? I've heard that OCaml's memory model is pretty stellar, but I don't know much about it myself, and I think a memory model is a sufficiently fundamental thing that changing it might cause backcompat issues -- but it depends on the change you'd like to see. > It is not a goal to add new inter-thread communication mechanisms. Is there something new you'd like to see? Supposedly, the existing inter-thread communication mechanisms will work just as well for virtual threads. > It is not a goal to offer a new data-parallelism construct in addition to parallel streams. Virtual threads are explicitly task-parallelism constructs, so this makes sense. Maybe you would build data-parallel constructs on top of them, but it's not something the JVM would be directly responsible for here.
elygre 5y ago
Non-goals does not mean that they are bad goals, only that this particular project will not try to reach them. It’s a good way to manage expectations and scope creep.

truth_seeker 5y ago

Its impossible say anything unfamiliar thing on HN, all kinds of morons are active all the time on HN to donwvote. ;) keep it up.

kaba0 5y ago
I did not downvote, but I guess you got those mostly because it was more of a statement on your part instead of a genuine question.

vincnetas 5y ago

backwards compatibility?

invalidname 5y ago

Those all make sense: - Native threads are great. They have a lot of uses, why touch them - Automatic conversion will break a lot of stuff and eliminate some of the benefits of native threads. Being able to use an API/implementation that is *almost* the same is a huge beneift - The memory model is a completely separate thing that Java worked on for decades. You don't want to touch that and you don't need to - Inter-thread communication is a separate thing. There's no reason to go after that. Same is true for the data parallelism stuff. The focus should be on hitting the 98% of what matters and getting it out without breaking everything we already have.

jsmith45 5y ago
While automatic conversion might be off the table, any library that expects (or allows) the caller to supply the ThreadFactory used to created thread will should make switching over pretty easy. Just construct the factory with `Thread.ofVirtual().factory()`, and provide it to the library. And if it is code you own, spawning threads, then switching over should be a pretty mechanical process. On the memory model: I'd argue that technically the memory model would be implicitly updated to treat these virtual threads the same as classic threads. Which is a very minor update. Beyond that, in order to maintain that memory model, the implementation will need to ensure proper barriers are used on pausing and resuming virtual threads, so that a virtual thread resumed on a different physical core is guaranteed to see any of its previous writes (as would be expected within a "single thread").

Twisol 5y ago

> It is not a goal to change the existing implementation of platform threads, that represent Operating System (OS) threads. > It is not a goal to automatically convert existing thread construction to virtual threads. Key word: automatically. If you want an OS thread, you should be able to get one. But if you simply spawn a task into a virtual thread, that task should behave basically the same as in a platform thread, but with less context switching overhead (and less strict claiming of OS resources). The locus of choice is at whichever part of the code constructs the threads to begin with; if you change it to use virtual threads, you shouldn't have to change anything else. > It is not a goal to change the Java Memory Model. Was there something you wanted changed? I've heard that OCaml's memory model is pretty stellar, but I don't know much about it myself, and I think a memory model is a sufficiently fundamental thing that changing it might cause backcompat issues -- but it depends on the change you'd like to see. > It is not a goal to add new inter-thread communication mechanisms. Is there something new you'd like to see? Supposedly, the existing inter-thread communication mechanisms will work just as well for virtual threads. > It is not a goal to offer a new data-parallelism construct in addition to parallel streams. Virtual threads are explicitly task-parallelism constructs, so this makes sense. Maybe you would build data-parallel constructs on top of them, but it's not something the JVM would be directly responsible for here.

elygre 5y ago

Non-goals does not mean that they are bad goals, only that this particular project will not try to reach them. It’s a good way to manage expectations and scope creep.