[9] RFR (S): 8058293: Bit set computation in MHs.findFirstDupOrDrop/findFirstDrop is broken
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} Thanks! Best regards, Vladimir Ivanov
On Sep 15, 2014, at 9:48 AM, Vladimir Ivanov <vladimir.x.ivanov@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
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@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
participants (2)
-
John Rose
-
Vladimir Ivanov