-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8270317: Large Allocation in CipherSuite #4783
Conversation
👋 Welcome back cverghese! A progress list of the required criteria for merging this PR into |
@cliveverghese The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
Hi Clive Verghese, The performance improve is impressive to me. Would you mind have an additional benchmark for the throughput (@BenchmarkMode(Mode.Throughput))? I guess the throughput should be good as well. Thanks! |
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.
The benchmark you provided looks a bit odd... In variant 1 best and worst cases differ by 3 ns, and in variant 2 they differ by 45 ns. The algorithm is supposed to be the same, so... Where does the difference come from?
maps_id.put(cs.id, cs); | ||
maps_name.put(cs.name, cs); | ||
for (String alias : cs.aliases) { | ||
maps_name.put(alias, cs); |
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.
A minor concern here. HashMap can't have duplicate keys. what if there are duplicated names/aliases?
Even it's not the case now, CipherSuite is subject to change in the future and I think it is a good opportunity to detect key duplication here. Currently, it's silently overwritten. This may introduce inconsistent behavior for nameOf.
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 could be potentially stored in immutable collections which might be slightly more compact + they throw when they encounter duplicate keys
- change base type to Map
- copy ciphers array into Map.Entry array
- maps_id = Map.ofEntries(entries) // + handle IAE
similar for the name map but with a list in between.
there might be a JDK internal shortcut to get to new ImmutableCollections.MapN<>(flatArray) right away without the Map.Entry step - I am sure a reviewer will chime in if there is.
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.
Thank you for the feedback. I have updated to use ImmutableMap. However, I had to use copyOf(Map)
method instead.
It would not check for duplicate values. Would it make more sense to add a test case to check for duplicates instead?. If so I can add that, else i'll check for duplicate while creating the map.
Sure, I'll add the Throughput mode and run the benchmarks.
I'll rerun the benchmarks with larger iterations and investigate a bit further to understand this difference. Thank you for point it out. |
Updated Benchmarks in Throughput mode Current
ArrayList
Hashmap
I am currently looking into the JFR profiles to identify why there is a difference in benchmarks with regards the different cipher suits in the current version vs the arraylist. |
Thank you very much for the update.
I guess the garbage collection plays a role here. |
Yes, from the JFR profiles it looks like this could be from the GC. |
private static final Map<Integer, CipherSuite> maps_id; | ||
private static final Map<String, CipherSuite> maps_name; | ||
private static final CipherSuite[] ciphers = CipherSuite.values(); |
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.
Generally, Java follows camel-case syntax for names. It would be good to keep the coding style consistent and use instinctive names. I may use names like "cipherSuiteIds", "cipherSuiteNames" and "cipherSuites" for the above three fields.
if (cs.id == id) { | ||
return cs.name; | ||
} | ||
String name = maps_id.get(id).name; |
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 guess get() may return null. It may be safe to check the return value of get():
CipherSuite cipherSuite = cipherSuiteIds.get(id);
if (cipherSuite != null) {
return cipherSuite.name;
}
} | ||
|
||
return "UNKNOWN-CIPHER-SUITE(" + Utilities.byte16HexString(id) + ")"; | ||
} | ||
|
||
static Collection<CipherSuite> allowedCipherSuites() { | ||
Collection<CipherSuite> cipherSuites = new LinkedList<>(); | ||
for (CipherSuite cs : CipherSuite.values()) { | ||
for (CipherSuite cs : ciphers) { |
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 may worthy of a static class field for the allowed cipher suites.
@@ -940,7 +942,7 @@ static String nameOf(int id) { | |||
|
|||
static Collection<CipherSuite> defaultCipherSuites() { | |||
Collection<CipherSuite> cipherSuites = new LinkedList<>(); | |||
for (CipherSuite cs : CipherSuite.values()) { | |||
for (CipherSuite cs : ciphers) { |
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 may worthy of a static class field for the default cipher suites.
for (CipherSuite cs : CipherSuite.values()) { | ||
for (CipherSuite cs : ciphers) { |
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.
If there is a static allowed cipher suite list, the logic here could be simplified to use the allowed cipher suite list. Then, the "ciphers" class filed may be not needed any longer.
Hi @XueleiFan, Thank you for the feedback. I have update the pull requests addressing your comments. |
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.
Looks good to me. Thank you!
Map<String, CipherSuite> names = new HashMap<>(); | ||
List<CipherSuite> allowedCS = new ArrayList<>(); | ||
List<CipherSuite> defaultCS = new ArrayList<>(); | ||
for(CipherSuite cs : CipherSuite.values()) { |
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 may add blank lines before and after the for-loop block.
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.
Than you @XueleiFan for approving the PR.
I have added the blank lines before and after the PR.
@cliveverghese This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 145 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@XueleiFan, @simonis) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
} else { | ||
// values() is ordered, remaining cipher suites are | ||
// not supported. | ||
for (CipherSuite cs : allowedCipherSuites) { |
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.
We can avoid this loop; look up the cipher by name first (cs = nameOf(name)
), then check for supported protocols.
Other than that, LGTM.
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.
Thank you for the feedback. I have updated the loop accordingly.
break; | ||
} | ||
CipherSuite cs; | ||
if ((cs = cipherSuiteNames.get(name)) != null && !cs.supportedProtocols.isEmpty()) { |
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.
Nice update! I appreciate if you could avoid lines longer than 80 characters, since they’re not handled well by many terminals and tools (See Java Code Conventions).
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.
Thank you @XueleiFan, Updated the length of the line.
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.
Thank you for the update. This PR looks good to me, and I have no further comment.
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 change looks good to me except the vary minor fact that the test has no newline at the end of the file. I wonder why jcheck hasn't caught this issue. If I remember right it did it in the old Mercurial version.
I'd appreciate if you could fix that as well before integrating (and no need for a new review from my side). I'll sponsor the change one you integrate.
Thanks for this nice improvement!
/integrate |
@cliveverghese |
/sponsor |
Going to push as commit e627cae.
Your commit was automatically rebased without conflicts. |
@simonis @cliveverghese Pushed as commit e627cae. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Benchmark results
I have benchmarked 3 cases.
static final array
instead of callingCipherSuite.values
each time.I have picked 4 cipher suite from the start of the list and are roughly 10 positions apart. I have opted to go with HashMap for name and id lookup as they provide a more consistent times and benchmarks are similar for the first few cipher suits in the enum as well.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/4783/head:pull/4783
$ git checkout pull/4783
Update a local copy of the PR:
$ git checkout pull/4783
$ git pull https://git.openjdk.java.net/jdk pull/4783/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 4783
View PR using the GUI difftool:
$ git pr show -t 4783
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/4783.diff