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

[Stefan Johansson]

On 2017-04-02 00:47, Kim Barrett wrote:
>> 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).
I agree, I also think this works now :) Following exactly how the 
different cutoffs work is still not obvious, but I have no good simple 
idea how to improve it either.
> 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/
>
Reviewed,
StefanJ