RFR (S) 8211926: Catastrophic size_t underflow in BitMap::*_large methods

[Kim Barrett]

> On Nov 5, 2018, at 7:15 AM, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> Bug:
>  https://bugs.openjdk.java.net/browse/JDK-8211926
> 
> Fix:
>  http://cr.openjdk.java.net/~shade/8211926/webrev.01/
> 
> Found this while porting some Shenandoah addons to jdk/jdk.
> 
> I took the liberty of homogenizing the internals of those methods to always call "small" path when
> range does not allow us to enter the "large" path. This protects us from accidentally breaking VM
> when asserts are disabled, and makes "large" methods usable as drop-ins for "small" ones.
> 
> Testing: hotspot-tier1, new gtest, jdk-submit (running)
> 
> Thanks,
> -Aleksey

------------------------------------------------------------------------------
src/hotspot/share/utilities/bitMap.cpp
 272   if ((end_full_word < beg_full_word) || (end_full_word - beg_full_word < BitsPerWord)) {

The use of BitsPerWord here at on line 289 seems like a units error.
What does the number of bits in a word have to do with the number of
words that is considered "small"?  I suspect the old value of 32 was
just a heuristic bound (which may or may not have had any measurements
to back it up).

Of course, the assertion error message in the old version of
set_large_range is also confused; the comparison is in words but the
message says bytes.

------------------------------------------------------------------------------