The reason people say functional languages are better for parallel processing is due to the fact that they usually avoid mutable state. Mutable state is the "root of all evil" in the context of parallel processing, because its easy to run into race conditions, to which the solutions tend to involve a lot of locking and synching mechanisms, as you mentioned, which cause runtime overhead and a lot of extra design complexity.

Avoiding the need for synchronization and locking mechanisms, or in short, mutable state, is what makes a program more efficient and effective for parallel processing. In other words, if your solution in Java does not use mutable state (at least not within objects shared between threads), converting it to a functional language like Scala or Clojure would not yield any benefits in term of the multithreading capacity (although there are certainly other factors involved, which are not in the scope of this discussion).

So to aswer your question more directly: If a solution in Scala is more efficient in parallel processing than one in Java, it is not because of the way the code is compiled or run through the JVM, but instead because the Java solution is using mutable state, either causing race conditions or adding the overhead of synchronization in order to avoid them.

The reason people say functional languages are better for parallel processing is due to the fact that they usually avoid mutable state. Mutable state is the "root of all evil" in the context of parallel processing; they make it really easy to run into race conditions when they are shared between concurrent processes. The solution to the race conditions then involve locking and synching mechanisms, as you mentioned, which cause runtime overhead, as the processes wait for one another to make use of the shared resource, and greater design complexity, as all of these concepts tend to be deeply nested within such applications.

When you avoid mutable state, the need for synchronization and locking mechanisms disappears along with it. Because functional languages usually avoid mutable state, they are naturally more efficient and effective for parallel processing - you won't have the runtime overhead of shared resources, and you won't have the added design complexity that usually follows.

However, this is all incidental. If your solution in Java also avoids mutable state (specifically shared between threads), converting it to a functional language like Scala or Clojure would not yield any benefits in terms of the concurrent efficiency, because the original solution is already free of the overhead caused by the locking and synching mechanisms.

TL;DR: If a solution in Scala is more efficient in parallel processing than one in Java, it is not because of the way the code is compiled or run through the JVM, but instead because the Java solution is sharing mutable state between threads, either causing race conditions or adding the overhead of synchronization in order to avoid them.