RFR: 8213415: BitMap::word_index_round_up overflow problems

Kim Barrett kim.barrett at oracle.com
Wed Nov 27 00:39:49 UTC 2019


> On Jun 11, 2019, at 12:42 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
>> On Jun 10, 2019, at 9:14 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> new webrevs:
>> full: http://cr.openjdk.java.net/~kbarrett/8213415/open.01/
>> incr: http://cr.openjdk.java.net/~kbarrett/8213415/open.01.inc/
> 
> Stefan and I have been talking about this offline.  We have some ideas for further changes in
> a slightly different direction, so no point in anyone else reviewing the open.01 changes right now
> (or maybe ever).

Finally returning to this.  Stefan Karlsson and Thomas Shatzl had some
offline feedback on earlier versions that led to some rethinking and
rework.  This included an attempt to be a little more consistent with
nomenclature.  There are still some lingering naming issues, which
might be worth fixing some other time.

The basic approach hasn't changed though.  From the original RFR:

Constructing a BitMap now ensures the size is such that rounding it up
to a word boundary won't overflow.  This is the new max_size_in_bits()
value. This lets us add some asserts and otherwise tidy things up in
some places by making use of that information.

This engendered some changes to ParallelGC's ParMarkBitMap.  It no
longer uses the obsolete BitMap::word_align_up, instead having its own
internal helper for aligning range ends that knows about invariants in
ParMarkBitMap.

CR:
https://bugs.openjdk.java.net/browse/JDK-8213415

New webrev:
http://cr.openjdk.java.net/~kbarrett/8213415/open.03/
(No incremental webrev; it wouldn't help that much for BitMap changes,
and there have been several intervening months since the last one.)

Testing:
mach5 tier1-5



More information about the hotspot-dev mailing list