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