RFR: 8213415: BitMap::word_index_round_up overflow problems

Thomas Stüfe thomas.stuefe at gmail.com
Fri Nov 29 18:34:10 UTC 2019

On Fri, Nov 29, 2019 at 6:57 PM Kim Barrett <kim.barrett at oracle.com> wrote:

> > On Nov 29, 2019, at 3:03 AM, Thomas Stüfe <thomas.stuefe at gmail.com>
> wrote:
> >
> > Hi Kim,
> >
> > On Thu, Nov 28, 2019 at 11:01 PM Kim Barrett <kim.barrett at oracle.com>
> wrote:
> > > On Nov 28, 2019, at 7:42 AM, Thomas Stüfe <thomas.stuefe at gmail.com>
> wrote:
> > > So, if I understand this correctly, we need this since we use the same
> type for bit and word indices and since we have a n:1 relationship between
> those two the max. bit index is necessary smaller than <type>_MAX?
> >
> > The point is to avoid overflow of the type used for bit indices when
> > aligning a value up to a multiple of the word size. This doesn't
> > really have anything to do with using the same types for bit indices
> > and word indices, though using different types might affect the
> > details of some of the calculations, and the range for the word type
> > would need to be suitably chosen to accomodate the bit range.
> >
> >
> > I still in the dark. In your current version max_size_in_words() and
> max_size_in_bits() there is an overflow, since both bit- and word indexes
> use the same type. With 64bit I come to: FFFFFFFF.FFFFFFC0 for max word
> index, 3FFFFFF.FFFFFFFF for max bit index. For 64bit types this does not
> matter much, but if we ever were to use smaller types, e.g. uint16_t, it
> would matter. Also, I find it surprising that max bit index is smaller than
> max word index.
> You have the values backward.
> The max bit index is certainly not the smaller, since it is a multiple of
> max word size.
Okay, sorry. My fault.

Thanks, Thomas

More information about the hotspot-dev mailing list