Skip to content

8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable #5068

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

Closed
wants to merge 5 commits into from

Conversation

stsypanov
Copy link
Contributor

@stsypanov stsypanov commented Aug 10, 2021

The code in Integer.decode() and Long.decode() might allocate two instances of Integer/Long for the negative values less than -127:

Integer result;

result = Integer.valueOf(nm.substring(index), radix);
result = negative ? Integer.valueOf(-result.intValue()) : result;

To avoid this we can declare 'result' as int and use Integer.parseInt() method. Same applicable for Long and some other classes.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5068/head:pull/5068
$ git checkout pull/5068

Update a local copy of the PR:
$ git checkout pull/5068
$ git pull https://git.openjdk.java.net/jdk pull/5068/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 5068

View PR using the GUI difftool:
$ git pr show -t 5068

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5068.diff

@bridgekeeper
Copy link

bridgekeeper bot commented Aug 10, 2021

👋 Welcome back stsypanov! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr Pull request is ready for review label Aug 10, 2021
@openjdk
Copy link

openjdk bot commented Aug 10, 2021

@stsypanov The following labels will be automatically applied to this pull request:

  • core-libs
  • security

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added security security-dev@openjdk.org core-libs core-libs-dev@openjdk.org labels Aug 10, 2021
@mlbridge
Copy link

mlbridge bot commented Aug 10, 2021

Webrevs

Copy link
Member

@cl4es cl4es left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine to me.

Could you consider adding microbenchmarks for Integer/Long.decode?

@@ -1447,15 +1447,15 @@ else if (nm.startsWith("0", index) && nm.length() > 1 + index) {
throw new NumberFormatException("Sign character in wrong position");

try {
result = Integer.valueOf(nm.substring(index), radix);
result = negative ? Integer.valueOf(-result.intValue()) : result;
result = parseInt(nm.substring(index), radix);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly a follow-up, but I think using parseInt/-Long(nm, index, nm.length(), radix) could give an additional speed-up in these cases (by avoiding a substring allocation).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! Let me check this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, looks like getting rid of substring() call makes things faster:

before

Benchmark                    (size)  Mode  Cnt   Score   Error  Units
Integers.decode                 500  avgt   15  11.444 ? 0.949  us/op
Integers.parseInt               500  avgt   15   8.669 ? 0.152  us/op
Integers.toStringBig            500  avgt   15  10.295 ? 0.612  us/op
Integers.toStringSmall          500  avgt   15   7.020 ? 0.581  us/op

Benchmark                    (size)  Mode  Cnt   Score   Error  Units
Longs.decode                    500  avgt   15  29.568 ? 9.785  us/op
Longs.repetitiveSubtraction     500  avgt   15   0.820 ? 0.153  us/op
Longs.toStringBig               500  avgt   15  13.418 ? 0.744  us/op
Longs.toStringSmall             500  avgt   15   8.180 ? 0.780  us/op


after

Benchmark                    (size)  Mode  Cnt   Score   Error  Units
Integers.decode                 500  avgt   15   7.377 ? 0.040  us/op
Integers.parseInt               500  avgt   15   8.720 ? 0.230  us/op
Integers.toStringBig            500  avgt   15  10.328 ? 0.266  us/op
Integers.toStringSmall          500  avgt   15   6.913 ? 0.178  us/op

Benchmark                    (size)  Mode  Cnt   Score   Error  Units
Longs.decode                    500  avgt   15   8.373 ? 0.708  us/op
Longs.repetitiveSubtraction     500  avgt   15   0.771 ? 0.003  us/op
Longs.toStringBig               500  avgt   15  13.126 ? 0.079  us/op
Longs.toStringSmall             500  avgt   15   6.915 ? 0.259  us/op

@openjdk
Copy link

openjdk bot commented Aug 10, 2021

⚠️ @stsypanov the full name on your profile does not match the author name in this pull requests' HEAD commit. If this pull request gets integrated then the author name from this pull requests' HEAD commit will be used for the resulting commit. If you wish to push a new commit with a different author name, then please run the following commands in a local repository of your personal fork:

$ git checkout 8267844
$ git commit -c user.name='Preferred Full Name' --allow-empty -m 'Update full name'
$ git push

@openjdk
Copy link

openjdk bot commented Aug 10, 2021

@stsypanov 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:

8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable

Reviewed-by: redestad

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 4 new commits pushed to the master branch:

  • 5350b99: 8272131: PhaseMacroExpand::generate_slow_arraycopy crash when clone null CallProjections.fallthrough_ioproj
  • 1489352: 8271718: Crash when during color transformation the color profile is replaced
  • 2a9acc3: 8272050: typo in MachSpillCopyNode::implementation after JDK-8131362
  • b62e742: 8213714: AttachingConnector/attach/attach001 failed due to "bind failed: Address already in use"

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
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 (@cl4es) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Aug 10, 2021
@mlbridge
Copy link

mlbridge bot commented Aug 10, 2021

Mailing list message from Thomas Lu=c3=9fnig on security-dev:

Hi,

i wonder why all usages of decode should be replaced.
Since Integer.valueOf(text,radix) =
Integer.valueOf(Ineger.parseInt(text,radix))

The double allocation with

result = Integer.valueOf(nm.substring(index), radix);
result = negative ? Integer.valueOf(-result.intValue()) : result;

could be replace with either

int result = Integer.parseInt(nm.substring(index),radix)
result = Integer.valueOf(negative ? -result : result);

or

result = Integer.valueOf(negative
?? ?? -Integer.parseInt(nm.substring(index),radix)
?? ?: Integer.parseInt(nm.substring(index),radix));

this way only one place is changed and the performance of parse is
improved wihtout change it.

Gru? Thomas Lu?nig

On 10.08.2021 19:43:15, ?????? ??????? wrote:

1 similar comment
@mlbridge
Copy link

mlbridge bot commented Aug 10, 2021

Mailing list message from Thomas Lu=c3=9fnig on security-dev:

Hi,

i wonder why all usages of decode should be replaced.
Since Integer.valueOf(text,radix) =
Integer.valueOf(Ineger.parseInt(text,radix))

The double allocation with

result = Integer.valueOf(nm.substring(index), radix);
result = negative ? Integer.valueOf(-result.intValue()) : result;

could be replace with either

int result = Integer.parseInt(nm.substring(index),radix)
result = Integer.valueOf(negative ? -result : result);

or

result = Integer.valueOf(negative
?? ?? -Integer.parseInt(nm.substring(index),radix)
?? ?: Integer.parseInt(nm.substring(index),radix));

this way only one place is changed and the performance of parse is
improved wihtout change it.

Gru? Thomas Lu?nig

On 10.08.2021 19:43:15, ?????? ??????? wrote:

Copy link
Member

@cl4es cl4es left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

@stsypanov
Copy link
Contributor Author

/integrate

@openjdk openjdk bot added the sponsor Pull request is ready to be sponsored label Aug 11, 2021
@openjdk
Copy link

openjdk bot commented Aug 11, 2021

@stsypanov
Your change (at version 7486b13) is now ready to be sponsored by a Committer.

@cl4es
Copy link
Member

cl4es commented Aug 12, 2021

/sponsor

@openjdk
Copy link

openjdk bot commented Aug 12, 2021

Going to push as commit b29fbad.
Since your change was applied there have been 22 commits pushed to the master branch:

  • d38b314: 8272332: --with-harfbuzz=system doesn't add -lharfbuzz after JDK-8255790
  • a15b659: 8271732: Regression in StringBuilder.charAt bounds checking
  • ec2fc38: 8272120: Avoid looking for standard encodings in "java." modules
  • bd27bb9: 8272345: macos doesn't check os::set_boot_path() result
  • 44f137f: 8271170: Add unit test for what jpackage app launcher puts in the environment
  • cd2dbe5: 8272328: java.library.path is not set properly by Windows jpackage app launcher
  • 9faab40: 8272330: C2: Cleanup profile counter scaling
  • 75a0642: 8272335: runtime/cds/appcds/MoveJDKTest.java doesn't check exit codes
  • 9ba8a12: 8269774: doclint reports missing javadoc comments for JavaFX properties if the docs are on the property method
  • ec8d3ba: 8271159: [REDO] JDK-8249634 doclint should report implicit constructor as missing javadoc comments
  • ... and 12 more: https://git.openjdk.java.net/jdk/compare/66d1faa7847b645f20ab2e966adf0a523e3ffeb2...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot closed this Aug 12, 2021
@openjdk openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Aug 12, 2021
@openjdk
Copy link

openjdk bot commented Aug 12, 2021

@cl4es @stsypanov Pushed as commit b29fbad.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@SkateScout
Copy link

SkateScout commented Aug 12, 2021

Hi,
i check Long.java line 1301...1311 and i am not sure if this code is really good.

  1. If negative is false the whole part ends with two times the same substring and this implies the same error.
  2. If negative is true and we get an error than we can throw the error without an second parse step or we can use the substring from the first round.
  3. Also as mentioned above the parseLong(text,radix) should be changed to parseLong(seq, beginIndex, endIndex, radix)
    this would avoid at least in the positive case the substring at all.
  4. The same points are with Integer as well.
    try {
    result = parseLong(nm.substring(index), radix);
    result = negative ? -result : result;
    } catch (NumberFormatException e) {
    // If number is Long.MIN_VALUE, we'll end up here. The next line
    // handles this case, and causes any genuine format error to be
    // rethrown.
    String constant = negative ? ("-" + nm.substring(index))
    : nm.substring(index);
    result = parseLong(constant, radix);
    }

@stsypanov stsypanov deleted the 8267844 branch August 13, 2021 06:24
@cl4es
Copy link
Member

cl4es commented Aug 13, 2021

Hi,
i check Long.java line 1301...1311 and i am not sure if this code is really good.

1. If negative  is false the whole part ends with two times the same substring and this implies the same error.

2. If negative is true and we get an error than we can throw the error without an second parse step or we can use the substring from the first round.

3. Also as mentioned above the parseLong(text,radix) should be changed to parseLong(seq, beginIndex, endIndex, radix)
   this would avoid at least in the positive case the substring at all.

4. The same points are with Integer as well.
   try {
   result = parseLong(nm.substring(index), radix);
   result = negative ? -result : result;
   } catch (NumberFormatException e) {
   // If number is Long.MIN_VALUE, we'll end up here. The next line
   // handles this case, and causes any genuine format error to be
   // rethrown.
   String constant = negative ? ("-" + nm.substring(index))
   : nm.substring(index);
   result = parseLong(constant, radix);
   }

The pre-existing logic here is iffy, but I think it is correct.

For Integer: If negative is true, then parsing "2147483648" (Integer.MAX_VALUE + 1) would throw, be reparsed as "-2147483648" and then be accepted as Integer.MIN_VALUE. This is the only case that should be non-exceptional, but it should also be exceedingly rare in practice. For negative values it improves the error messages a bit to add the "-" and reparse.

Improving the catch clauses with parseLong(CharSequence, int, int, int) and adding an if (!negative) throw e case to the catch could theoretically improve performance of parsing the MIN_VALUE edge case and repeated decoding of malformed positive numbers, but these are rare or exceptional cases where we should favor simplicity over optimal performance

@SkateScout
Copy link

OK even if we keep out the edge case in the try block the "parseLong(nm.substring(index), radix)" could be replaced as already mentioned with parseLong(nm. index, nm.length(), radix)
and in the catch block the idea to throw an "nice" error can be misleading.
since -02147483648 for example would become -2147483648 because the radix is 8.
Since per Radix only one String is possible to get through would if not be faster and more clear to check (compare) if it is the matching string and return the correct value else throw the error. This is also easy to read and even if is on the edge avoid substring , concationation and reparsing.

@cl4es
Copy link
Member

cl4es commented Aug 13, 2021

OK even if we keep out the edge case in the try block the "parseLong(nm.substring(index), radix)" could be replaced as already mentioned with parseLong(nm. index, nm.length(), radix)

I think it already was: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Long.java#L1287

and in the catch block the idea to throw an "nice" error can be misleading.
since -02147483648 for example would become -2147483648 because the radix is 8.

Yes, it's slightly misleading that the radix specifier gets cropped out, but the error message does include the radix information so it's not a bug technically:

jshell> Integer.decode("-01234567890123");
|  Exception java.lang.NumberFormatException: For input string: "-1234567890123" under radix 8

Since per Radix only one String is possible to get through would if not be faster and more clear to check (compare) if it is the matching string and return the correct value else throw the error. This is also easy to read and even if is on the edge avoid substring , concationation and reparsing.

It might be a bit faster for that one non-exceptional accepted input, sure. It could also incur a cost on the fast path due increasing the weight of the code. You'd need to carefully measure that the added logic and checks doesn't cause any trouble elsewhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core-libs core-libs-dev@openjdk.org integrated Pull request has been integrated security security-dev@openjdk.org
Development

Successfully merging this pull request may close these issues.

3 participants