RFR(xs): 8241581: Add BitMap::count_one_bits variant for arbitrary lengths

[Thomas Stüfe]

On Wed, Mar 25, 2020 at 2:14 PM Claes Redestad <claes.redestad at oracle.com>
wrote:

> Hi,
>
> On 2020-03-25 13:35, Thomas Stüfe wrote:
> > Greetings,
> >
> > could I have reviews for this small enhancement please:
> >
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8241581
> > Webrev:
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/bitmap-arbitrary-range-popcount/webrev.00/webrev/
>
> looks reasonable.
>
> Thanks!


> >
> > This adds the ability to call BitMap::count_one_bits on an arbitrary bit
> > region, not just on the whole BitMap. I need this for the new Metaspace
> > prototype.
> >
> > Note that while it would be cool to use platform dependent popcnt
> > instructions here, that is not the goal of this fix. This just expands on
> > the existing implementation of BitMap::count_one_bits() using the
> algorithm
> > in population:count.hpp.
>
> Yeah, H/W-enabled popcnt would be great, and population_count.hpp
> intends to be the place to add that similarly to what's been done for
> other intrinsics such as count_leading_zeros.
>
> However, on x86 we compile for a H/W target that doesn't guarantee
> popcnt exists.. so intrinsics like gcc's __builtin_popcount are likely
> to emit something similar to what's currently in population_count.hpp.
> And last I checked that turned out to be a pessimization in the places
> where we do 32-bit population counts (C2!).
>

I noticed this too when playing around with the builtin. Seems to depend on
the march setting we use. Anything below nehalem does not use popcnt.


> >
> > It comes with quite thorough gtests. I ran the gtests on little and big
> > endian machines and all is well. Submit tests also ran through.
>
> Good!
>
> /Claes
>

Thank you!

..Thomas