RFR: 8149733: AArch64: refactor char_array_equals/byte_array_equals/string_equals
Aleksey Shipilev
aleksey.shipilev at oracle.com
Fri Feb 19 12:36:18 UTC 2016
Hi Hui,
On 02/19/2016 03:13 PM, Hui Shi wrote:
> webrev: http://cr.openjdk.java.net/~hshi/8149733/webrev/
> <http://cr.openjdk.java.net/%7Ehshi/8149733/webrev/>
Not savvy with AArch64 assembly, but it does not look bad.
My other comments are superficial:
* Desperately needs spell-checking: "implenetaions", "implemenation",
"eqauls", "comapre"
* Inconsistent naming, e.g. "... = wordSize/step_size;"
* "if (is_string_equal == false) {"
* "if (exact_log >0 )"
* Shouldn't be:
4533 ldrw(cnt1, Address(ary1, length_offset));
4534 ldrw(tmp2, Address(ary2, length_offset));
4535 cmp(cnt1, tmp2);
spelled like:
4533 ldrw(cnt1, Address(ary1, length_offset));
4534 ldrw(cnt2, Address(ary2, length_offset));
4535 cmp(cnt1, cnt2);
* Would be nice to keep the comments like "// 0-7 bytes left, cnt1 =
#bytes left - 4"
* Why TAIL01 block is predicated on (step_size == 1) now?
> Test case: http://cr.openjdk.java.net/~hshi/8149733/TestArrayEqual.java
> <http://cr.openjdk.java.net/%7Ehshi/8149733/TestArrayEqual.java>
I think you should really, really, really use JMH for these benchmarks:
http://openjdk.java.net/projects/code-tools/jmh/
It would also provide you an easy access to generated code profiling,
with -prof perfasm. It is usually pretty clear from that output if your
generated code needs even more tuneups.
Cheers,
-Aleksey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160219/20d5aca2/signature.asc>
More information about the hotspot-compiler-dev
mailing list