RFR: 8261445: Use memory_order_relaxed for os::random().

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

RFR: 8261445: Use memory_order_relaxed for os::random().

Andrew Haley-2
os::random() is used a lot (once for every class) during HotSpot initialization, and it defaults to using a compare-and-swap operation with memory_order_conservative. We don't need that: it should be memory_order_relaxed.

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

Commit messages:
 - Stage

Changes: https://git.openjdk.java.net/jdk/pull/2484/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2484&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261445
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2484.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2484/head:pull/2484

PR: https://git.openjdk.java.net/jdk/pull/2484
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261445: Use memory_order_relaxed for os::random().

Andrew Dinn-2
On Tue, 9 Feb 2021 14:49:12 GMT, Andrew Haley <[hidden email]> wrote:

> os::random() is used a lot (once for every class) during HotSpot initialization, and it defaults to using a compare-and-swap operation with memory_order_conservative. We don't need that: it should be memory_order_relaxed.

Looks good.

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

Marked as reviewed by adinn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2484
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261445: Use memory_order_relaxed for os::random().

Erik Österlund-3
In reply to this post by Andrew Haley-2
On Tue, 9 Feb 2021 14:49:12 GMT, Andrew Haley <[hidden email]> wrote:

> os::random() is used a lot (once for every class) during HotSpot initialization, and it defaults to using a compare-and-swap operation with memory_order_conservative. We don't need that: it should be memory_order_relaxed.

Marked as reviewed by eosterlund (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2484
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261445: Use memory_order_relaxed for os::random().

Aleksey Shipilev-5
In reply to this post by Andrew Haley-2
On Tue, 9 Feb 2021 14:49:12 GMT, Andrew Haley <[hidden email]> wrote:

> os::random() is used a lot (once for every class) during HotSpot initialization, and it defaults to using a compare-and-swap operation with memory_order_conservative. We don't need that: it should be memory_order_relaxed.

It seems superficially fine, given unsynchronized read of `_rand_seed` prior to that. But I have to wonder if in absence of any memory ordering semantics, this loop is guaranteed to terminate? That is, can't a sufficiently hostile optimizer reduce it to the CAS loop that always expects a constant "oldval" seed?

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

PR: https://git.openjdk.java.net/jdk/pull/2484
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261445: Use memory_order_relaxed for os::random().

Aleksey Shipilev-5
On Tue, 9 Feb 2021 18:22:36 GMT, Aleksey Shipilev <[hidden email]> wrote:

>> os::random() is used a lot (once for every class) during HotSpot initialization, and it defaults to using a compare-and-swap operation with memory_order_conservative. We don't need that: it should be memory_order_relaxed.
>
> It seems superficially fine, given unsynchronized read of `_rand_seed` prior to that. But I have to wonder if in absence of any memory ordering semantics, this loop is guaranteed to terminate? That is, can't a sufficiently hostile optimizer reduce it to the CAS loop that always expects a constant "oldval" seed?

...and yes, it seems to (borderline imperceptibly) improve startup :)

 Performance counter stats for 'taskset -c 13 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs):

             23.27 msec task-clock                #    0.940 CPUs utilized            ( +-  0.01% )
        85,860,247      cycles                    #    3.690 GHz                      ( +-  0.01% )
        80,060,520      instructions              #    0.93  insn per cycle           ( +-  0.00% )

        0.02476574 +- 0.00000328 seconds time elapsed  ( +-  0.01% )

 Performance counter stats for 'taskset -c 13 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs):

             23.22 msec task-clock                #    0.940 CPUs utilized            ( +-  0.01% )
        85,659,272      cycles                    #    3.689 GHz                      ( +-  0.01% )
        80,063,528      instructions              #    0.93  insn per cycle           ( +-  0.00% )

        0.02471087 +- 0.00000271 seconds time elapsed  ( +-  0.01% )

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

PR: https://git.openjdk.java.net/jdk/pull/2484
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261445: Use memory_order_relaxed for os::random().

Martin Doerr
In reply to this post by Andrew Haley-2
On Tue, 9 Feb 2021 14:49:12 GMT, Andrew Haley <[hidden email]> wrote:

> os::random() is used a lot (once for every class) during HotSpot initialization, and it defaults to using a compare-and-swap operation with memory_order_conservative. We don't need that: it should be memory_order_relaxed.

Looks like a nice improvement!

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

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2484
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261445: Use memory_order_relaxed for os::random().

Martin Doerr
In reply to this post by Aleksey Shipilev-5
On Tue, 9 Feb 2021 18:22:36 GMT, Aleksey Shipilev <[hidden email]> wrote:

>
>
> It seems superficially fine, given unsynchronized read of `_rand_seed` prior to that. But I have to wonder if in absence of any memory ordering semantics, this loop is guaranteed to terminate? That is, can't a sufficiently hostile optimizer reduce it to the CAS loop that always expects a constant "oldval" seed?

I can't see any problem here. `_rand_seed` is volatile so the compiler must preserve all accesses to it. And all processors I'm aware of are single-copy atomic which means that all accesses to the same memory location are ordered.

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

PR: https://git.openjdk.java.net/jdk/pull/2484
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261445: Use memory_order_relaxed for os::random().

David Holmes-2
In reply to this post by Andrew Haley-2
On Tue, 9 Feb 2021 14:49:12 GMT, Andrew Haley <[hidden email]> wrote:

> os::random() is used a lot (once for every class) during HotSpot initialization, and it defaults to using a compare-and-swap operation with memory_order_conservative. We don't need that: it should be memory_order_relaxed.

This seems fine to me too.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2484
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261445: Use memory_order_relaxed for os::random().

Aleksey Shipilev-5
On Tue, 9 Feb 2021 22:25:14 GMT, David Holmes <[hidden email]> wrote:

>> os::random() is used a lot (once for every class) during HotSpot initialization, and it defaults to using a compare-and-swap operation with memory_order_conservative. We don't need that: it should be memory_order_relaxed.
>
> This seems fine to me too.
>
> Thanks,
> David

> > It seems superficially fine, given unsynchronized read of `_rand_seed` prior to that. But I have to wonder if in absence of any memory ordering semantics, this loop is guaranteed to terminate? That is, can't a sufficiently hostile optimizer reduce it to the CAS loop that always expects a constant "oldval" seed?
>
> I can't see any problem here. `_rand_seed` is volatile so the compiler must preserve all accesses to it. And all processors I'm aware of are single-copy atomic which means that all accesses to the same memory location are ordered.

Yes, that looks fine. If we match the C++11 semantics of `relaxed`, we still maintain the single modification order of the variable. I would suggest we load `_rand_seed` with `Atomic::load(&_rand_seed)` as a good style, though.

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

PR: https://git.openjdk.java.net/jdk/pull/2484