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

Cleanup BitMap search API

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Fixed
    • P4
    • 10
    • None
    • hotspot
    • None
    • b21
    • generic
    • 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

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

              Dates

                Created:
                Updated:
                Resolved: