10 RFR: 8169039: Add unit tests for BitMap search operations

[Kim Barrett]

> On Mar 22, 2017, at 10:44 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
> 
> Hi Kim,
> 
> On 2017-02-18 06:58, Kim Barrett wrote:
>> Please review this change to add a native unit test for BitMap search
>> operations, e.g. get_next_{zero,one}_offset and variants.
>> 
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8169039
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8169039/hotspot.00/
>> 
> 
> StefanJ and I reviewed this patch.

Thanks for looking at this.

> There seems to be a bug in the fourth nested for-loop in test_search_ranges:

Well spotted.

When I added comments to these cutoffs (as requested, and I really
should have done that in the first place), I realized the situation is
even worse than you surmised.  I think I've corrected things now, and
added sufficient comments to help future readers (including me! It's
been a while since I originally wrote this test).

As you surmised, these bits are for limiting the search space, to
speed up the test.  Each of the (now 3) cuttoffs speeds up the test by
roughly a factor of 2; without any the test takes > 1sec on my desktop
machine, with them it takes < 120ms.  It's probably possible to
tighten up the cuttoff heuristics to further improve that, but they
add enough complication already that I'm wondering if they are worth
the trouble.

> This code:
> […]
> was non-obvious to us. Could it be rewritten using functions with describing names? For example:

Added compute_expected() helper.

New webrevs:
full: http://cr.openjdk.java.net/~kbarrett/8169039/hotspot.01/
incr: http://cr.openjdk.java.net/~kbarrett/8169039/hotspot.01.inc/