Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10
    • Component/s: hotspot
    • Labels:
      None
    • Subcomponent:
    • Resolved In Build:
      b21
    • CPU:
      generic
    • OS:
      generic

      Description

      BitMap presently has

      get_next_one_offset(idx_t)
      get_next_one_offset(idx_t, idx_t)
      get_next_one_offset_inline(idx_t, idx_t)
      get_next_one_offset_inline_aligned_right(idx_t, idx_t)

      get_next_zero_offset(idx_t)
      get_next_zero_offset(idx_t, idx_t)
      get_next_zero_offset_inline(idx_t, idx_t)
      // no inline_aligned_right because no callers

      The one-argument get_next_{zero,one}_offset functions are simple inline wrappers for calling the corresponding two-argument function with the bitmap's size() as the second argument. No issues there.

      The two-argument get_next_{zero,one}_offset functions are commented in BitMap.hpp as being not-inline, but are declared inline in BitMap.inline.hpp. And many (most?) callers are performance sensitive. There are probably no callers that truly need a non-inline call; there are probably some that don't care.

      The only direct outside callers of the _inline suffixed are a few functions in ParallelGC. So all other BitMap searchers are using the unsuffixed variants, even where performance critical.

      The API would be made less confusing by dropping the _inline suffixes and removing the pre-existing non-suffixed two-argument variants.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                kbarrett Kim Barrett
                Reporter:
                kbarrett Kim Barrett
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: