[9] RFR (S): 8058293: Bit set computation in MHs.findFirstDupOrDrop/findFirstDrop is broken

[Vladimir Ivanov]

Thank you, John.

I did an adhoc test run with BIT_LIMIT=0 set, but I don't think it worth 
a separate parameter in the code.

Best regards,
Vladimir Ivanov

On 9/15/14, 11:44 PM, John Rose wrote:
> On Sep 15, 2014, at 9:48 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
>> https://bugs.openjdk.java.net/browse/JDK-8058293
>> http://cr.openjdk.java.net/~vlivanov/8058293/webrev.00
>>
>> Bit set computation in MHs.findFirstDupOrDrop/findFirstDrop is incorrect due to widening primitive conversions (int -> long) taking place. The fix is to explicitly use long where needed.
>>
>> Also, fixed a case when reorder represents a permutation (zeroPos == newArity).
>>
>> Testing: jck (api/java_lang/invoke), jdk/java/lang/invoke, jdk/java/util/streams w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}
>
> Wow, that's foul.  Thanks for patching it up.  Next time I'll start with "BIT_LIMIT = 31".
>
> Reviewed.
>
> FTR, it's worth exercising the code with BIT_LIMIT = 0, just to stress the slow path.
>
> — John
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>