RFR: 8213415: BitMap::word_index_round_up overflow problems
Thomas Schatzl
thomas.schatzl at oracle.com
Wed Nov 27 11:11:13 UTC 2019
Hi again,
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.
Thanks,
Thomas
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>
>>> 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/
>>
>
> lgtm.
>
> Thanks,
> Thomas
More information about the hotspot-dev
mailing list