8268231: Aarch64: Use ldp in intrinsics for String.compareTo #4722
+66
−67
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,96 @@ | ||
| /* | ||
| * Copyright (c) 2021, Huawei Technologies Co. Ltd. All rights reserved. | ||
| * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. | ||
| * | ||
| * This code is free software; you can redistribute it and/or modify it | ||
| * under the terms of the GNU General Public License version 2 only, as | ||
| * published by the Free Software Foundation. | ||
| * | ||
| * This code is distributed in the hope that it will be useful, but WITHOUT | ||
| * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or | ||
| * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License | ||
| * version 2 for more details (a copy is included in the LICENSE file that | ||
| * accompanied this code). | ||
| * | ||
| * You should have received a copy of the GNU General Public License version | ||
| * 2 along with this work; if not, write to the Free Software Foundation, | ||
| * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. | ||
| * | ||
| * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA | ||
| * or visit www.oracle.com if you need additional information or have any | ||
| * questions. | ||
| */ | ||
| package org.openjdk.bench.java.lang; | ||
|
|
||
| import org.openjdk.jmh.annotations.*; | ||
| import java.util.concurrent.TimeUnit; | ||
|
|
||
| /* | ||
| * This benchmark naively explores String::compare performance | ||
| */ | ||
| @BenchmarkMode(Mode.AverageTime) | ||
| @OutputTimeUnit(TimeUnit.MICROSECONDS) | ||
| @State(Scope.Benchmark) | ||
| public class StringCompare { | ||
| @Param({"256"}) | ||
| int size; | ||
|
|
||
| @Param({"7", "15", "31", "47", "63", "127", "255"}) | ||
| int diff_pos; | ||
|
|
||
|
|
||
| private String str1; | ||
| private String str2; | ||
|
|
||
| @Setup(Level.Trial) | ||
| public void init() { | ||
| str1 = newString(size, 'c', diff_pos, '1'); | ||
| str2 = newString(size, 'c', diff_pos, '2'); | ||
| } | ||
|
|
||
| public String newString(int length, char charToFill, int diff_pos, char diff_char) { | ||
| if (length > 0) { | ||
| char[] array = new char[length]; | ||
| for (int i = 0; i < length; i++) { | ||
| array[i] = charToFill; | ||
| } | ||
| array[diff_pos] = diff_char; | ||
| return new String(array); | ||
| } | ||
| return ""; | ||
| } | ||
|
|
||
| @Benchmark | ||
| @CompilerControl(CompilerControl.Mode.DONT_INLINE) | ||
| public int compareLLDiffStrings() { | ||
| int result = 0; | ||
| for (int i = 0; i < 1000; i++) { | ||
| result ^= str1.compareTo(str2); | ||
| } | ||
| return result; | ||
| } | ||
|
|
||
| @Benchmark | ||
| @Fork(jvmArgsAppend = {"-XX:-CompactStrings"}) | ||
| @CompilerControl(CompilerControl.Mode.DONT_INLINE) | ||
| public int compareUUDiffStrings() { | ||
| int result = 0; | ||
| for (int i = 0; i < 1000; i++) { | ||
| result ^= str1.compareTo(str2); | ||
| } | ||
| return result; | ||
| } | ||
|
|
||
| @Benchmark | ||
| @CompilerControl(CompilerControl.Mode.DONT_INLINE) | ||
| @Fork(jvmArgsAppend = {"-XX:-CompactStrings", "-XX:-UseCompressedClassPointers"}) | ||
| public int compareUUDiffStringsTurnOffCCP() { | ||
| int result = 0; | ||
| for (int i = 0; i < 1000; i++) { | ||
| result ^= str1.compareTo(str2); | ||
| } | ||
| return result; | ||
| } | ||
|
|
||
| } | ||
|
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This breaks the Windows AArch64 build:
https://github.com/Wanghuang-Huawei/jdk/runs/3260986937
Should probably be left as
MAX2.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I'll fix it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's fine. I don't think it'll affect any real programs, so it's rather pointless. I don't know if that's any reason not to approve it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Andrew, can you help us to approve this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with Andrew Haley that this patch is not going to make an improvement for anything but a very small number of applications. Processing of strings over a few 10s of bytes is rare. On the other hand the doesn't seem to cause any performance drop for the much more common case of processing short strings. so it does no harm. Also, the new and old code are much the same in terms of complexity so that is no reason to prefer one over the other. The only real concern I have is that any change involves the risk of error and the ratio of cases that might benefit to cases that might suffer from an error is very low. I don't think that's a reason to avoid pushing this patch upstream but it does suggest that we should not backport it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, thanks. That seems like a sensible compromise.