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

stsypanov · 2021-08-10T13:16:42Z

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

Claes Redestad (@cl4es - Reviewer)

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

The text was updated successfully, but these errors were encountered:

…ere applicable

bridgekeeper · 2021-08-10T13:17:46Z

👋 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 · 2021-08-10T13:21:00Z

@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.

mlbridge · 2021-08-10T13:24:40Z

Webrevs

01: Full - Incremental (7486b13f)
00: Full (a1b993d4)

cl4es

Looks fine to me.

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

cl4es · 2021-08-10T14:57:54Z

src/java.base/share/classes/java/lang/Integer.java

@@ -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);


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).

Good point! Let me check this.

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 · 2021-08-10T14:59:35Z

⚠️ @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 · 2021-08-10T14:59:37Z

@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).

mlbridge · 2021-08-10T19:02:56Z

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:

mlbridge · 2021-08-10T19:02:58Z

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:

cl4es

Nice!

stsypanov · 2021-08-11T07:36:33Z

/integrate

openjdk · 2021-08-11T07:37:32Z

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

cl4es · 2021-08-12T10:02:38Z

/sponsor

openjdk · 2021-08-12T10:03:59Z

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 · 2021-08-12T10:04:13Z

@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 · 2021-08-12T21:26:08Z

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

If negative is false the whole part ends with two times the same substring and this implies the same error.
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.
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.
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);
}

cl4es · 2021-08-13T09:40:02Z

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 · 2021-08-13T13:16:04Z

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 · 2021-08-13T13:44:41Z

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.

stsypanov added 2 commits May 27, 2021

8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() wh…

d359d21

…ere applicable

Merge branch 'master' into 8267844

a1b993d

openjdk bot added the rfr label Aug 10, 2021

openjdk bot added security core-libs labels Aug 10, 2021

cl4es approved these changes Aug 10, 2021

View changes

openjdk bot added the ready label Aug 10, 2021

Merge branch 'master' into 8267844

939dca6

stsypanov added 2 commits Aug 10, 2021

8267844: Rid useless substring when calling Integer/Long.parse*()

c9ce026

8267844: Add benchmarks for Integer/Long.decode()

7486b13

cl4es approved these changes Aug 10, 2021

View changes

openjdk bot added the sponsor label Aug 11, 2021

openjdk bot closed this Aug 12, 2021

openjdk bot added integrated and removed ready rfr sponsor labels Aug 12, 2021

stsypanov deleted the 8267844 branch Aug 13, 2021

openjdk / jdk Public

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

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

stsypanov commented Aug 10, 2021 •

edited by openjdk bot

Loading

bridgekeeper bot commented Aug 10, 2021

openjdk bot commented Aug 10, 2021

mlbridge bot commented Aug 10, 2021 •

edited

Loading

cl4es left a comment

cl4es Aug 10, 2021

stsypanov Aug 10, 2021

stsypanov Aug 10, 2021

openjdk bot commented Aug 10, 2021

openjdk bot commented Aug 10, 2021 •

edited

Loading

mlbridge bot commented Aug 10, 2021

mlbridge bot commented Aug 10, 2021

cl4es left a comment

stsypanov commented Aug 11, 2021

openjdk bot commented Aug 11, 2021

cl4es commented Aug 12, 2021

openjdk bot commented Aug 12, 2021

openjdk bot commented Aug 12, 2021

SkateScout commented Aug 12, 2021 •

edited by bridgekeeper bot

Loading

cl4es commented Aug 13, 2021

SkateScout commented Aug 13, 2021

cl4es commented Aug 13, 2021 •

edited

Loading

openjdk / jdk Public

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

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

Conversation

stsypanov commented Aug 10, 2021 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented Aug 10, 2021

openjdk bot commented Aug 10, 2021

mlbridge bot commented Aug 10, 2021 • edited Loading

Webrevs

cl4es left a comment

cl4es Aug 10, 2021

Choose a reason for hiding this comment

stsypanov Aug 10, 2021

Choose a reason for hiding this comment

stsypanov Aug 10, 2021

Choose a reason for hiding this comment

openjdk bot commented Aug 10, 2021

openjdk bot commented Aug 10, 2021 • edited Loading

mlbridge bot commented Aug 10, 2021

mlbridge bot commented Aug 10, 2021

cl4es left a comment

stsypanov commented Aug 11, 2021

openjdk bot commented Aug 11, 2021

cl4es commented Aug 12, 2021

openjdk bot commented Aug 12, 2021

openjdk bot commented Aug 12, 2021

SkateScout commented Aug 12, 2021 • edited by bridgekeeper bot Loading

cl4es commented Aug 13, 2021

SkateScout commented Aug 13, 2021

cl4es commented Aug 13, 2021 • edited Loading

stsypanov commented Aug 10, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented Aug 10, 2021 •

edited

Loading

openjdk bot commented Aug 10, 2021 •

edited

Loading

SkateScout commented Aug 12, 2021 •

edited by bridgekeeper bot

Loading

cl4es commented Aug 13, 2021 •

edited

Loading