RFR 8199843 : Optimize Integer/Long.highestOneBit()

Ivan Gerasimov ivan.gerasimov at oracle.com
Mon Mar 26 21:26:04 UTC 2018

Thank you Andrew for looking into this!

On 3/24/18 4:13 AM, Andrew Haley wrote:
> On 03/20/2018 05:20 PM, Ivan Gerasimov wrote:
>> I tried to run it, but the numbers are non-distinguishable for non-zero
>> arguments.
>> And my variant performs slightly better with zero argument.
>> So, I think it's reasonable to keep the variant with the ternary operator.
> I am suspicious of this argument.  Did you look at the generated code?
> I get
>     cbnz	w10, 0x000003ffa8202384
>     mov	w0, wzr
> for the zero test and
>     cbz	w10, 0x000003ffa81d228c
>     clz	w11, w10
>     orr	w10, wzr, #0x80000000
>     lsr	w0, w10, w11    ;*iushr
> for 42.
> The branch at the start of both versions goes to a deoptimize trap.
> We don't want deoptimize traps if we can avoid them, so the branchless
> version is better IMO.
This looks persuasive, so let's go ahead with the branchless variant!

With kind regards,

> I think your benchmark is of questionable validity because it always
> uses the same value.  This is unlikely in real code.  I think the
> versions should be benchmarked with a *varying* argument.

With kind regards,
Ivan Gerasimov

More information about the core-libs-dev mailing list