RFR 8199843 : Optimize Integer/Long.highestOneBit()
aph at redhat.com
Sat Mar 24 11:13:13 UTC 2018
On 03/20/2018 05:20 PM, Ivan Gerasimov wrote:
> I tried to run it, but the numbers are non-distinguishable for non-zero
> 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?
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
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.
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.
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the core-libs-dev