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

Make BitMap accessors more memory ordering friendly

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Fixed
    • Icon: P4 P4
    • 14
    • 14
    • hotspot
    • None
    • gc
    • b23

      Today, the par_set_bit API of BitMap has the following semantics:

      On failure: Sometimes acquiring, sometimes not, depending on the nature of the failure, so you kind of have to assume it's relaxed. This is apparently an optimization for architectures that care about acquire doing something. It's assumed nobody would ever need ordering on failures.

      On success: FENCE FENCE FENCE FENCE FENCE!!! Not ideal on the same hardware that above mentioned optimization tried to help. Perhaps the same machines could use relaxing this a bit too.

      Similarly, the only exposed getter has relaxed semantics. So anyone that needs acquire semantics has to roll a separate getter performing the relaxed load and gluing on an acquiring fence.

      I propose the BitMap exposes an atomic_memory_order aware API so that users can choose their favourite ordering for their needs. However, I do not intend to expose IRIW-consistent getters (requiring a full fence on loads for non-multiple copy atomic machines), because I can't see any algorithm needing that ever, and the cost is significant.

            eosterlund Erik Ă–sterlund
            eosterlund Erik Ă–sterlund
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: