[concurrency-interest] Implicit parallelism

Brian Goetz brian at briangoetz.com
Fri Aug 23 12:43:21 EDT 2013


For what its worth, we've made the follwing choice in the JDK libraries: 
No Implicit Parallelism.  We can make parallelism unobtrusive, but we 
won't be making it implicit.

Of course, other library writers can make their own choices.

On 8/10/2013 2:45 PM, Gustav Åkesson wrote:
> Hi guys,
>
> My discussion here concerns implicit parallelism. Let's say we have the
> following setup:
>
> @Immutable
> public class Integer
> {
>    ...
> }
>
> @Immutable
> public class ImmutableArrayList
> {
>     ...
> }
>
> I'm looking for a way so that the parallelism would be introduced
> without hard-coding anything related to parallelism (i.e. not stating
> anything like .parallel or .par on the collection). Only thing needed
> would be something annotation-ish which tells the execution environment
> that this datastructure with elements is inherently thread-safe. Then
> the execution could determine if it would be beneficial to do so. For
> instance, for a structure with e.g. five elements, then it would not,
> but for millions of elements, it would most likely be. Perhaps it could
> even find some kind of sweet-spot of number of elements in which the
> parallel overhead exceeds the benefits.
>
> Let's say we wish to sum all the integers in an ImmutableArrayList
> (setup below), would it be possible for the compiler (javac, scalac or
> what have you) and JVM to conspire and decide "hey, let's run this in
> parallel since it doesn't violate application semantics and it can/will
> be faster"? Is there any research in this area in regards to the JVM?
>
>
> Best Regards,
>
> Gustav Åkesson
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>


More information about the Concurrency-interest mailing list