RFR: 8307483: New micros for j.u.c.LockSupport

[David Holmes]

On Mon, 8 May 2023 10:01:49 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Same as we saw with `isAlive` before: `LockSupport.park` implicitly provides a compiler barrier. This `done` should be at least "opaque" to carry the same effect.
>
> Yes, `park()` and `unpark()` having release and acquire semantics is not documented [here](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/concurrent/locks/LockSupport.html#park()), and the documentation for `LockSupport` explicitly says "Reliable usage requires the use of volatile (or atomic) variables to control when to park or unpark. Orderings of calls to these methods are maintained with respect to volatile variable accesses, but not necessarily non-volatile variable accesses."

Irrespective of park/unpark barriers, the JIT should have hoisted `done` and rewritten as:

if (!done) {
  while(true) {
    ...
  }
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1188051993