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.iva...@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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
