RFR: 8213415: BitMap::word_index_round_up overflow problems

[Kim Barrett]

> 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.

> Oh sure. This was just the first draft. My idea was - if only for test reasons - to use a class type which wraps around a numeric and defines +/- operations and assignments. I wonder though whether there is a simpler way to make the compiler complain about assignments between word- and bit indices.

Yes, some sort of lightweight wrapper class, or perhaps a C++11 enum
class without any named enumerators, just the type safety.  I have some
followup tidying up I want to do after this change; maybe I’ll add this to
my list.

> But even with the same underlying typedef, using different types for word- and bit indexes would make the code more readable and clearer.

Perhaps, though I worry that it might give a false sense of security.