RFR: 8213415: BitMap::word_index_round_up overflow problems

[Stefan Karlsson]

On 2019-11-29 21:37, Kim Barrett wrote:
>> On Nov 29, 2019, at 3:03 AM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>>
>> Side note, I was interested in using smaller types because long term I would like to have a BitMap class in cases where I today use little hand written bitmaps. As it is now, BitMap has a pointer and a size, which makes it a 16byte structure on 64 bit, which is rather fat. The indirection is also often unwanted. I would like to have a BitMap class which contains directly the data as member(s), e.g. one where it just has a 16bit word or, maybe, an array of multiple words. That would make this structure a lot smaller and better suited to be included in space sensitive structures.
> There was some discussion here in Oracle about this sort of thing a
> while ago. Looking back over that discussion, I don't think we got
> very far with a statically sized bitmap, just some handwaving. I think
> the interest is there, but ideas (and time to persue them!) are
> needed.

FWIW, see the usage of BitMapView in zLiveMap.hpp and zLiveMap.inline.hpp.

The bitmap backing is a single word inside ZLiveMap:
   BitMap::bm_word_t _segment_live_bits;

and the size is constant:
   static const size_t nsegments = 64;

The views are created with:
inline BitMapView ZLiveMap::segment_live_bits() {
   return BitMapView(&_segment_live_bits, nsegments);
}

and then used with:
inline bool ZLiveMap::is_segment_live(BitMap::idx_t segment) const {
   return segment_live_bits().par_at(segment);
}

All this gets inlined as expected.

It doesn't support sizes less than a word, but it does support arrays of 
multiple words.

StefanK