RFR: 8155043: BitMap set operations assume clear bits beyond unaligned end

Stefan Karlsson stefan.karlsson at oracle.com
Fri Aug 5 13:27:02 UTC 2016


Hi Kim,

This looks mostly good to me. I have a few comments inlined:

On 2016-08-05 00:02, Kim Barrett wrote:
> Please review this change to the BitMap set operations to avoid
> depending on or modifying bits beyond the size of the BitMap when the
> size is not word aligned.  This change also adds some unit tests for
> these operations.
>
> In addition:
>
> - Changed set_from to use Copy::disjoint_words.  For other set
> operations, use a consistent iteration idiom for all.
>
> - In the set_xxx_with_result operations, eliminated conditionals in
> the accumulation of the result.

I guess this was done for performance reasons? Have you measured and 
seen any gains with this? The generated code becomes significantly 
larger when using the or/xor combination in your patch.

>
> - Removed unused BitMap::set_intersection_at_offset, rather than
> writing tests for it.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8155043
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8155043/webrev.00/

Some minor comments/suggestions that you might want to consider:

==========
http://cr.openjdk.java.net/~kbarrett/8155043/webrev.00/src/share/vm/utilities/bitMap.cpp.frames.html

There are a few places where the tail calculations are slightly 
different compared to the calculations of the aligned part. Would it be 
good to use the same bitwise operations, just to get consistency between 
the two parts?

For example, in BitMap::contains we have

408 bm_word_t value = dest_map[index];
409 if (value != (value | other_map[index])) return false;

vs

414 return (rest == 0) || tail_of_set(~dest_map[limit] & 
other_map[limit], rest) == 0;

We could replace 408-409 with 'if (~dest_map[limit] & other_map[limit]) 
== 0) return false'.

----------
I find that the introduction of the 'bm_word_t orig' variable just makes 
the code extra noisy, and would have preferred the calculations without it.

----------

The new code has a few functions named *_of_set. The terminology "set" 
is previously not used in the BitMap file, so I'm a bit reluctant to 
introduce it. Could we get rid of it by renaming the functions:
   tail_of_set -> tail_of_map
   merge_tail_of_set -> merge_tail_of_map

or maybe:
   tail_of_set -> tail_bits
   merge_tail_of_set -> merge_tail_bits

==========
http://cr.openjdk.java.net/~kbarrett/8155043/webrev.00/test/native/utilities/test_bitMap_setops.cpp.html

The file tests more than the set operations, so maybe the _setops suffix 
should be dropped?

----------
Some of the tests restore the previous bitmap value after all checks, 
but some don't. It would probably be good to make that more consistent.

----------
class BitMapMemory {
...
private:
   idx_t _words;
   bm_word_t* _memory;
};

Most of the classes in the HotSpot have the members at the top of the class.

----------
static bm_word_t make_even_bits() {
   bm_word_t result = 1;
   while (true) {
     bm_word_t next = (result << 2) | 1;
     if (next == result) return result;
     result = next;
   }
}

I'd prefer if you moved down the return statement to a separate line and 
add braces.

----------

Thanks,
StefanK

>
> Testing:
> RBT runtime and gc nightly.
>



More information about the hotspot-dev mailing list