RFR: 8213415: BitMap::word_index_round_up overflow problems
thomas.schatzl at oracle.com
Wed Nov 27 11:11:13 UTC 2019
one thing I forgot: there is a merge error with StefanK's latest
changes about includes for atomic/orderAccess.hpp in bitMap.inline?.hpp.
I do not need a re-review for that.
On 27.11.19 12:09, Thomas Schatzl wrote:
> Hi Kim,
> On 27.11.19 01:39, Kim Barrett wrote:
>>> On Jun 11, 2019, at 12:42 PM, Kim Barrett <kim.barrett at oracle.com>
>>>> On Jun 10, 2019, at 9:14 PM, Kim Barrett <kim.barrett at oracle.com>
>>>> 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
>> New webrev:
More information about the hotspot-dev