Does the JVM have the ability to detect opportunities for parallelization?

I think the current guarantees of the Java memory model make it quite hard to do much, if any, automatic parallelization at the compiler or VM level. The Java language has no semantics to guarantee that any data structure is even effectively immutable, or that any particular statement is pure and free of side-effects, so the compiler would have to figure these out automatically in order to parallelize. Some elementary opportunities would be possible to infer in the compiler, but the general case would be left to the runtime, since dynamic loading and binding could introduce new mutations that didn't exist at compile-time.

Consider the following code:

for (int i = 0; i < array.length; i++) {
    array[i] = expensiveComputation(array[i]);
}

It would be trivial to parallelize, if is a pure function, whose output depends only on its argument, and if we could guarantee that wouldn't be changed during the loop (actually we're changing it, setting , but in this particular case is always called first so it's okay here - assuming that is local and not referenced from anywhere else).expensiveComputationarrayarray[i]=...expensiveComputation(array[i])array

Furthermore, if we change the loop like this:

for (int i = 0; i < array.length; i++) {
    array[i] = expensiveComputation(array, i);
    // expensiveComputation has the whole array at its disposal!
    // It could read or write values anywhere in it!
}

then parallelization is not trivial any more even if is pure and doesn't alter its argument, because the parallel threads would be changing the contents of while others are reading it! The parallelizer would have to figure out which parts of the array is referring to under various conditions, and synchronize accordingly.expensiveComputationarrayexpensiveComputation

Perhaps it wouldn't be outright impossible to detect all mutations and side-effects that may be going on and take those into account when parallelizing, but it would be very hard, for sure, probably infeasible in practice. This is why parallelization, and figuring out that everything still works correctly, is the programmer's headache in Java.

Functional languages (e.g. Clojure on JVM) are a hot answer to this topic. Pure, side-effect-free functions together with persistent ("effectively immutable") data structures potentially allow implicit or almost implicit parallelization. Let's double each element of an array:

(map #(* 2 %) [1 2 3 4 5])
(pmap #(* 2 %) [1 2 3 4 5])  ; The same thing, done in parallel.

This is transparent because of 2 things:

1. The function is pure: it takes a value in and gives a value out, and that's it. It doesn't change anything, and its output depends only on its argument.#(* 2 %)
2. The vector is immutable: no matter who's looking at it, or when, it's the same.[1 2 3 4 5]

It's possible to make pure functions in Java, but 2), immutability, is the Achilles' heel here. There are no immutable arrays in Java. To be pedant, nothing is immutable in Java because even fields can be changed using reflection. Therefore no guarantees can be made that the output (or input!) of a computation wouldn't be changed by parallelization -> so automatic parallelization is generally infeasible.final

The dumb "doubling elements" example extends to arbitrarily complex processing, thanks to immutability:

(defn expensivefunction [v x]
  (/ (reduce * v) x))


(let [v [1 2 3 4 5]]
  (map (partial expensivefunction v) v)) ; pmap would work equally well here!