Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8222034

Thread-SMR functions should be updated to remove work around

    Details

    • Subcomponent:
    • Resolved In Build:
      b17
    • CPU:
      generic
    • OS:
      generic

      Description

      On 4/5/19 12:01 PM, Daniel D. Daugherty wrote:
      > On 4/5/19 8:37 AM, Doerr, Martin wrote:
      >> Hi everybody,
      >>
      >>> I think was fixed with:
      >>> 8202080: Introduce ordering semantics for Atomic::add/inc and other RMW atomics
      >>> You should get a leading sync and trailing one with the default conservative
      >>> model and thus get proper memory ordering.
      >>> Martin, I'm I correct?
      >> Exactly. Thanks for pointing this out. PPC uses the strongest possible ordering semantics with memory_order_conservative (default parameter).
      >> I've seen that comment about PPC in "void ThreadsList::inc_nested_handle_cnt()". This function could get replaced.
      >
      > Okay so we need a new bug to update these two Thread-SMR functions:
      >
      > src/hotspot/share/runtime/threadSMR.cpp:
      >
      > void ThreadsList::dec_nested_handle_cnt() {
      > // The decrement needs to be MO_ACQ_REL. At the moment, the Atomic::dec
      > // backend on PPC does not yet conform to these requirements. Therefore
      > // the decrement is simulated with an Atomic::sub(1, &addr).
      > // Without this MO_ACQ_REL Atomic::dec simulation, the nested SMR mechanism
      > // is not generally safe to use.
      > Atomic::sub(1, &_nested_handle_cnt);
      > }
      >
      > void ThreadsList::inc_nested_handle_cnt() {
      > // The increment needs to be MO_SEQ_CST. At the moment, the Atomic::inc
      > // backend on PPC does not yet conform to these requirements. Therefore
      > // the increment is simulated with a load phi; cas phi + 1; loop.
      > // Without this MO_SEQ_CST Atomic::inc simulation, the nested SMR mechanism
      > // is not generally safe to use.
      > intx sample = OrderAccess::load_acquire(&_nested_handle_cnt);
      > for (;;) {
      > if (Atomic::cmpxchg(sample + 1, &_nested_handle_cnt, sample) == sample) {
      > return;
      > } else {
      > sample = OrderAccess::load_acquire(&_nested_handle_cnt);
      > }
      > }
      > }
      >
      > I'll file a new bug, loop in Robbin, Erik O and Martin, and make
      > sure we're all in agreement. Once we decide that Thread-SMR's
      > functions look like, I'll adapt my Async Monitor Deflation
      > functions...
      >
      > Dan

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                dcubed Daniel Daugherty
                Reporter:
                dcubed Daniel Daugherty
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: