OpenJDK Project Loom - lightweight threads for Java

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenJDK Project Loom - lightweight threads for Java

dholmes
This should be of interest to the followers of this mailing list.

http://mail.openjdk.java.net/pipermail/discuss/2017-September/004390.html

http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html

David
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK Project Loom - lightweight threads for Java

thurstonn
Love it.

BTW, for those with institutional memory, isn't that what "green threads"
more or less were meant to be, back in the earlier days of Java?  Before my
time, and I never used them . . .



--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK Project Loom - lightweight threads for Java

Ariel Weisberg-2
Hi,

I am very excited for this. This is the #1 ergonomic enhancement for me.

Ariel

On Wed, Oct 25, 2017, at 01:31 PM, thurstonn wrote:

> Love it.
>
> BTW, for those with institutional memory, isn't that what "green threads"
> more or less were meant to be, back in the earlier days of Java?  Before
> my
> time, and I never used them . . .
>
>
>
> --
> Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK Project Loom - lightweight threads for Java

Andrig Miller
In reply to this post by thurstonn


On Wed, Oct 25, 2017 at 11:31 AM, thurstonn <[hidden email]> wrote:
Love it.

BTW, for those with institutional memory, isn't that what "green threads"
more or less were meant to be, back in the earlier days of Java?  Before my
time, and I never used them . . .

​If memory serves me correctly, green threads were only present for platforms that didn't have threads in their kernel.

Andy



--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK Project Loom - lightweight threads for Java

Joshua Bloch
This is very similar in spirit to the "many-to-few" threading model that was popular in the '90s. You can read about it in Butenhof's Programming with POSIX Threads (Addison-Wesley, 1997), §5.6.3. The concept pretty much died on the vine when kernel threads got faster and cheaper, but everything old is new again.

BTW, I believe that by far the most important thing this project could do for the average Java programmer is to provide yield iterators, à la C#. Writing your own iterator is difficult, and writing one for collections whose traversal is inherently recursive is extremely difficult: you have to translate the recursive algorithm into an iterative one by maintaining an explicit stack instead of using the thread's stack. Giving people yield iterators makes it trivial to write iterators. This should be a tier 1 use case: If a proposed solution can't handle it, the solution should be repaired or discarded.

Josh

On Wed, Oct 25, 2017 at 11:42 AM, Andrig Miller <[hidden email]> wrote:


On Wed, Oct 25, 2017 at 11:31 AM, thurstonn <[hidden email]> wrote:
Love it.

BTW, for those with institutional memory, isn't that what "green threads"
more or less were meant to be, back in the earlier days of Java?  Before my
time, and I never used them . . .

​If memory serves me correctly, green threads were only present for platforms that didn't have threads in their kernel.

Andy



--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK Project Loom - lightweight threads for Java

thurstonn
Joshua Bloch wrote
> This is very similar in spirit to the "many-to-few" threading model that
> was popular in the '90s. You can read about it in Butenhof's *Programming
> with POSIX Threads (Addison-Wesley, 1997)*, §5.6.3. The concept pretty
> much
> died on the vine when kernel threads got faster and cheaper, but
> everything
> old is new again.

Uh, Erlang




--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK Project Loom - lightweight threads for Java

Andrig Miller
In reply to this post by Joshua Bloch


On Wed, Oct 25, 2017 at 1:34 PM, Joshua Bloch <[hidden email]> wrote:
This is very similar in spirit to the "many-to-few" threading model that was popular in the '90s. You can read about it in Butenhof's Programming with POSIX Threads (Addison-Wesley, 1997), §5.6.3. The concept pretty much died on the vine when kernel threads got faster and cheaper, but everything old is new again.

​Solaris had a M-to-N threading model, at least at one point, but I'm not sure if they kept that in the latest versions.

Andy

BTW, I believe that by far the most important thing this project could do for the average Java programmer is to provide yield iterators, à la C#. Writing your own iterator is difficult, and writing one for collections whose traversal is inherently recursive is extremely difficult: you have to translate the recursive algorithm into an iterative one by maintaining an explicit stack instead of using the thread's stack. Giving people yield iterators makes it trivial to write iterators. This should be a tier 1 use case: If a proposed solution can't handle it, the solution should be repaired or discarded.

Josh

On Wed, Oct 25, 2017 at 11:42 AM, Andrig Miller <[hidden email]> wrote:


On Wed, Oct 25, 2017 at 11:31 AM, thurstonn <[hidden email]> wrote:
Love it.

BTW, for those with institutional memory, isn't that what "green threads"
more or less were meant to be, back in the earlier days of Java?  Before my
time, and I never used them . . .

​If memory serves me correctly, green threads were only present for platforms that didn't have threads in their kernel.

Andy



--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest





--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK Project Loom - lightweight threads for Java

Dávid Karnok
In reply to this post by thurstonn
I'm a bit worried about the performance implications in exchange for the promise of imperative looking code.

For example, having a bounded blocking queue suspend on being full/empty. If the producer runs too fast, it gets suspended all the time with what it seems to be quite a lot of state to be saved and restored in a thread-safe manner. Similarly, a fast running consumer would get suspended all the time.


2017-10-25 21:40 GMT+02:00 thurstonn <[hidden email]>:
Joshua Bloch wrote
> This is very similar in spirit to the "many-to-few" threading model that
> was popular in the '90s. You can read about it in Butenhof's *Programming
> with POSIX Threads (Addison-Wesley, 1997)*, §5.6.3. The concept pretty
> much
> died on the vine when kernel threads got faster and cheaper, but
> everything
> old is new again.

Uh, Erlang




--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Best regards,
David Karnok

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

OpenJDK Project Loom - threads are not ideal mental tool

Alexei Kaigorodov
In reply to this post by dholmes
From Loom Proposals:

This is a sad case of a good and natural abstraction being abandoned in
favor of a less natural one [asynchronous task], which is overall worse in
many respects, merely because of the runtime performance characteristics of
the abstraction.

Well, "natural" may have at least two meanings. First, natural for the
brains of human beings, and natural from mathematical point of view, and
that meanings do not always agree. Say, Roman digits are more natural for
low-skilled persons than Hindu–Arabic numerals, while the last is more
natural mathematically. And being more natural mathematically always results
in being more performant. Can you imagine a computer working in Roman
numerals? Its cost and performance?

So, if an abstraction is less performant, it should be examined against
mathematical naturality. The main drawback of thread is, of course, the size
of stack memory, and the proposed project is going to fix it. But there are
other performance problems, which the project is not going to solve.
Consider a program for copying a file:

for (;;) {
   buff = input.read();
   if (buff == null) break;
   output.write(buff);
}

Reading and writing of each buffer is done sequentially (which is natural
for human brain), while they could be done in parallel. But expressing this
parallelism using threads would make thread-based program as complex as
asynchronous implementation.

The program representation which allows maximal parallelism is a dataflow
graph. A thread represents a sequence in that graph, usually a cycle. Of
course, each graph can be represented as a set of sequences (threads), but
the thread representation has (at least) two problems. First is that
elements of the sequence are executed sequentially, as pointed above.
Second, decomposition of the graph into threads can be done in many
variants. And the variant chosen by a programmer could be suboptimal, or
become sо during the evolution of the program.

So in order to support both brain and mathematics naturalities, I'd propose
to develop following tools:
 - a compiler from thread  representation to asynchronous (dataflow)
representation
 - graphical editor and debugger who works with graph representation
 - a decompiler to convert graph representation into thread representation,
which accepts user's advices how to split graph into threads.






--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK Project Loom - threads are not ideal mental tool

Ron Pressler-2
Hi. I wrote the Loom proposal.

Concurrency and parallelism are very different things. Concurrency is the problem of scheduling multiple _competing_ domain problems (e.g., servicing a transaction request from a user) onto some bounded set of computational resources; parallelism is the problem of optimally employing a set of computational resource to _cooperate_ on solving a single domain problem. Project Loom is first and foremost concerned with addressing the first (concurrency) and not the second (for which Java streams are likely a better solution). Concurrency is an important problem that is worth addressing, as motivated by the issues expressed in the beginning of the proposal; parallelism is simply not within the scope of this particular project. Having said that, the availability of delimited continuations may assist parallelism as well, and they can certainly help implementing dataflow graphs — those, however, will be left to third-parties, at least in the initial delivery of Project Loom.

Ron


On October 26, 2017 at 4:52:06 PM, Alexei Kaigorodov ([hidden email]) wrote:

From Loom Proposals:

This is a sad case of a good and natural abstraction being abandoned in
favor of a less natural one [asynchronous task], which is overall worse in
many respects, merely because of the runtime performance characteristics of
the abstraction.

Well, "natural" may have at least two meanings. First, natural for the
brains of human beings, and natural from mathematical point of view, and
that meanings do not always agree. Say, Roman digits are more natural for
low-skilled persons than Hindu–Arabic numerals, while the last is more
natural mathematically. And being more natural mathematically always results
in being more performant. Can you imagine a computer working in Roman
numerals? Its cost and performance?

So, if an abstraction is less performant, it should be examined against
mathematical naturality. The main drawback of thread is, of course, the size
of stack memory, and the proposed project is going to fix it. But there are
other performance problems, which the project is not going to solve.
Consider a program for copying a file:

for (;;) {
buff = input.read();
if (buff == null) break;
output.write(buff);
}

Reading and writing of each buffer is done sequentially (which is natural
for human brain), while they could be done in parallel. But expressing this
parallelism using threads would make thread-based program as complex as
asynchronous implementation.

The program representation which allows maximal parallelism is a dataflow
graph. A thread represents a sequence in that graph, usually a cycle. Of
course, each graph can be represented as a set of sequences (threads), but
the thread representation has (at least) two problems. First is that
elements of the sequence are executed sequentially, as pointed above.
Second, decomposition of the graph into threads can be done in many
variants. And the variant chosen by a programmer could be suboptimal, or
become sо during the evolution of the program.

So in order to support both brain and mathematics naturalities, I'd propose
to develop following tools:
- a compiler from thread representation to asynchronous (dataflow)
representation
- graphical editor and debugger who works with graph representation
- a decompiler to convert graph representation into thread representation,
which accepts user's advices how to split graph into threads.






--
Sent from: https://urldefense.proofpoint.com/v2/url?u=http-3A__jsr166-2Dconcurrency.10961.n7.nabble.com_&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=-kUDHxC1IVB_ypN88uP5I0zEdrgC5UAi06w1pnrnunw&m=PweXYYVC_WnNu_wy-6J-6huh6rsBxDKguogCD-V57eU&s=lzVWOXrM-0mON4FCZKKZokTu-SdHL0UUNRU5VmVnYtU&e=
_______________________________________________
Concurrency-interest mailing list
[hidden email]
https://urldefense.proofpoint.com/v2/url?u=http-3A__cs.oswego.edu_mailman_listinfo_concurrency-2Dinterest&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=-kUDHxC1IVB_ypN88uP5I0zEdrgC5UAi06w1pnrnunw&m=PweXYYVC_WnNu_wy-6J-6huh6rsBxDKguogCD-V57eU&s=O-EwZSIf6TwIoY3qXtXFmLMe8V2_aZjkzwpGVmzLEqQ&e=

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest