Java floating point and StrictMath improvement?

[A Z]

To core-libs-dev@openjdk.java.net,


float and double should be mutually enhanced or

defaultedly changed, to uphold the following three

properties:


1) Base ten arithmetic on float and double, via operators.

2) Base Ten elementary function calls, like

those made on java.lang.StrictMath,

on double or float values.

3) Base ten Comparison operators. ==, !=, >, <, >=,<=.



Martin has said:


'It is inherently, mathematically *impossible* to emulate decimal

behaviour with binary IEEE 754 arithmetic. That's why Java also

offers java.math.BigDecimal, a decimal floating-point library

implemented in software.'


Then don't use IEEE 754 alone! Or, have a dual mode, with an

active alternative. There are binary alternatives, particularly

that include the likes of SSE, that in fact can.


The only standards necessary, and really, the 'authoritative standard',

are those prevalent in mathematics itself. Base 10 arithmetic, algebra,

elementary functions, range limited real values.


BigDecimal, BigInteger, and https://github.com/eobermuhlner big-math,

with its calculator class, take up more room in memory than necessary.

They are slower, and they do not allow for the use of operators.

Worse yet, they are not immediately reified in the rest of the language,

ie all class and interface libraries.


Raffaello has said:

'Exact representation of 0.1 using base 2 is mathematically impossible,

no matter the language (it is a periodic number in base 2).'


Consideration of the article:

https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf


Which is admittedly older, but still accurate, indicates otherwise.


I contend that within an upper and lower range, that it is possible.

While C++ can't use the immediate ==, !=, >,<,>=,<= operators

immediately accurately, Java has.


Using 32 or 64 bit buffers, and an SSE or similar buffer, and the

right algorithms, unto limited range, you can have as much of

a range representation as required for float or double, even

though you ultimately don't have 'exact' representation.


Bernd Eckenfels has said:

'The need to round floating point numbers for commercial math

(and the risk involved in doing so) is nothing new, it predates

the IEEE standard and should be subject for even basic comp

sci curriculums all over the world.'


That is true, but it is the case that range termination

of decimal values, by means of truncation, is more accurate

than this. By any processing of rounding, you start gaining

inaccuracy, which can grow and grow and overpopulate the

entire number. In Computer Programming, you can need range

continuous range accuracy. Such as with 2D and 3D processing.

The present Java approach is slower and a waste of memory.


Given all this, and given that humans, and representations

of the real world rely on base 10 first, shouldn't the 3

properties I outlined at the beginning of my post be

at least mutually, compatibly, instituted in Java,

if not defaultedly?

Re: RFR: JDK-8283234: Improve @jls usage in java.base

[Iris Clark]

On Wed, 16 Mar 2022 03:03:23 GMT, Joe Darcy  wrote:

> Checking the java.bases sources revealed a number of other instances where 
> conceptual links into the JLS (or JVMS) could be upgraded to actual links.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7834

Integrated: 8253495: CDS generates non-deterministic output

[Ioi Lam]

On Tue, 8 Mar 2022 19:11:02 GMT, Ioi Lam  wrote:

> This patch makes the result of "java -Xshare:dump" deterministic:
> - Disabled new Java threads from launching. This is harmless. See comments in 
> jvm.cpp
> - Fixed a problem in hashtable ordering in heapShared.cpp
> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random 
> bits. Added code to zero it.
> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in 
> make/scripts/compare.sh
> 
> Note:  $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. 
> This will be fixed in 
> [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828).
> 
> Testing under way:
> - tier1~tier5
> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, 
> windows-x86-cmp-baseline,  etc).

This pull request has now been integrated.

Changeset: de4f04cb
Author:Ioi Lam 
URL:   
https://git.openjdk.java.net/jdk/commit/de4f04cb71a26ce03b96460cb8d1c1e28cd1ed38
Stats: 100 lines in 15 files changed: 69 ins; 9 del; 22 mod

8253495: CDS generates non-deterministic output

Reviewed-by: erikj, kbarrett, ccheung, ihse

-

PR: https://git.openjdk.java.net/jdk/pull/7748

RFR: JDK-8283234: Improve @jls usage in java.base

[Joe Darcy]

Checking the java.bases sources revealed a number of other instances where 
conceptual links into the JLS (or JVMS) could be upgraded to actual links.

-

Commit messages:
 - JDK-8283234: Improve @jls usage in java.base

Changes: https://git.openjdk.java.net/jdk/pull/7834/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7834=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283234
  Stats: 21 lines in 5 files changed: 0 ins; 0 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7834.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7834/head:pull/7834

PR: https://git.openjdk.java.net/jdk/pull/7834

Re: RFR: 8279598: Provide adapter from RandomGenerator to Random [v18]

[Stuart Marks]

On Tue, 15 Mar 2022 23:18:24 GMT, Yasser Bazzi  wrote:

>> Hi, could i get a review on this implementation proposed by Stuart Marks, i 
>> decided to use the 
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html
>>  interface to create the default method `asRandom()` that wraps around the 
>> newer algorithms to be used on classes that do not accept the new interface.
>> 
>> Some things to note as proposed by the bug report, the protected method 
>> next(int bits) is not overrided and setSeed() method if left blank up to 
>> discussion on what to do with it.
>> 
>> Small test done on 
>> https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4
>
> Yasser Bazzi has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Fix SplittableRandomTest.

Marked as reviewed by smarks (Reviewer).

OK, thanks. I've moved the CSR to the "finalized" where it's awaiting approval. 
Shouldn't be more than a day or two.

-

PR: https://git.openjdk.java.net/jdk/pull/7001

Integrated: JDK-8283230: Improve @jls usage in ElementType

[Joe Darcy]

On Wed, 16 Mar 2022 00:33:57 GMT, Joe Darcy  wrote:

> Improve some semantic links into JLS with actual links.

This pull request has now been integrated.

Changeset: 4df24c5d
Author:Joe Darcy 
URL:   
https://git.openjdk.java.net/jdk/commit/4df24c5df38eeacc73097f71383916e9a0933839
Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8283230: Improve @jls usage in ElementType

Reviewed-by: jjg, iris

-

PR: https://git.openjdk.java.net/jdk/pull/7831

Java float, double, StrictMath correction?

[A Z]

To core-libs-dev@openjdk.java.net,


float and double should be mutually enhanced or

defaultedly changed, to uphold the following three

properties:


1) Base ten arithmetic on float and double, via operators.

2) Base Ten elementary function calls, like

those made on java.lang.StrictMath,

on double or float values.

3) Base ten Comparison operators. ==, !=, >, <, >=,<=.



Martin has said:


'It is inherently, mathematically *impossible* to emulate decimal

behaviour with binary IEEE 754 arithmetic. That's why Java also

offers java.math.BigDecimal, a decimal floating-point library

implemented in software.'


Then don't use IEEE 754 alone! Or, have a dual mode, with an

active alternative. There are binary alternatives, particularly

that include the likes of SSE, that in fact can.


The only standards necessary, and really, the 'authoritative standard',

are those prevalent in mathematics itself. Base 10 arithmetic, algebra,

elementary functions, range limited real values.


BigDecimal, BigInteger, and https://github.com/eobermuhlner big-math,

with its calculator class, take up more room in memory than necessary.

They are slower, and they do not allow for the use of operators.

Worse yet, they are not immediately reified in the rest of the language,

ie all class and interface libraries.


Raffaello has said:

'Exact representation of 0.1 using base 2 is mathematically impossible,

no matter the language (it is a periodic number in base 2).'


Consideration of the article:

https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf


Which is admittedly older, but still accurate, indicates otherwise.


I contend that within an upper and lower range, that it is possible.

While C++ can't use the immediate ==, !=, >,<,>=,<= operators

immediately accurately, Java has.


Using 32 or 64 bit buffers, and an SSE or similar buffer, and the

right algorithms, unto limited range, you can have as much of

a range representation as required for float or double, even

though you ultimately don't have 'exact' representation.


Bernd Eckenfels has said:

'The need to round floating point numbers for commercial math

(and the risk involved in doing so) is nothing new, it predates

the IEEE standard and should be subject for even basic comp

sci curriculums all over the world.'


That is true, but it is the case that range termination

of decimal values, by means of truncation, is more accurate

than this. By any processing of rounding, you start gaining

inaccuracy, which can grow and grow and overpopulate the

entire number. In Computer Programming, you can need range

continuous range accuracy. Such as with 2D and 3D processing.

The present Java approach is slower and a waste of memory.


Given all this, and given that humans, and representations

of the real world rely on base 10 first, shouldn't the 3

properties I outlined at the beginning of my post be

at least mutually, compatibly, instituted in Java,

if not defaultedly?

Re: RFR: JDK-8283230: Improve @jls usage in ElementType

[Iris Clark]

On Wed, 16 Mar 2022 00:33:57 GMT, Joe Darcy  wrote:

> Improve some semantic links into JLS with actual links.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7831

Re: RFR: JDK-8283230: Improve @jls usage in ElementType

[Jonathan Gibbons]

On Wed, 16 Mar 2022 00:33:57 GMT, Joe Darcy  wrote:

> Improve some semantic links into JLS with actual links.

Marked as reviewed by jjg (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7831

RFR: JDK-8283230: Improve @jls usage in ElementType

[Joe Darcy]

Improve some semantic links into JLS with actual links.

-

Commit messages:
 - JDK-8283230: Improve @jls usage in ElementType

Changes: https://git.openjdk.java.net/jdk/pull/7831/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7831=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283230
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7831.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7831/head:pull/7831

PR: https://git.openjdk.java.net/jdk/pull/7831

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v6]

[Valerie Peng]

On Tue, 15 Mar 2022 20:51:25 GMT, Valerie Peng  wrote:

>> It's been several years since we increased the default key sizes. Before 
>> shifting to PQC, NSA replaced its Suite B cryptography recommendations with 
>> the Commercial National Security Algorithm Suite which suggests:
>> 
>> - SHA-384 for secure hashing
>> - AES-256 for symmetric encryption
>> - RSA with 3072 bit keys for digital signatures and for key exchange
>> - Diffie Hellman (DH) with 3072 bit keys for key exchange
>> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures 
>> (ECDSA)
>> 
>> So, this proposed changes made the suggested key size and algorithm changes. 
>> The changes are mostly in keytool, jarsigner and their regression tests, so 
>> @wangweij Could you please take a look?
>> 
>> Thanks!
>
> Valerie Peng has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Removed NPE from the catch statement.

Could you please please review CSR at: 
https://bugs.openjdk.java.net/browse/JDK-8282995
Thanks!

-

PR: https://git.openjdk.java.net/jdk/pull/7652

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]

[Weijun Wang]

On Tue, 15 Mar 2022 20:44:20 GMT, Valerie Peng  wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java
>>  line 122:
>> 
>>> 120: default -> {
>>> 121: throw new ProviderException
>>> 122: ("Unrecognized algorithm for checking key 
>>> size");
>> 
>> If it's an unknown key algorithm, is it possible we just ignore it and keep 
>> using `minKeyLen` and `maxKeyLen`?
>
> Well, instead of ignore unknown key algorithm, perhaps safer to throw 
> Exception so it can be caught and handled during develop time. 
> P11KeyPairGenerator class is only used for known algorithms which it is 
> registered for, so probably ok to go either way. I'd prefer to play it safe 
> and force a review of this block of code when new algorithm is added.

OK.

-

PR: https://git.openjdk.java.net/jdk/pull/7652

Re: RFR: 8257733: Move module-specific data from make to respective module [v6]

[Magnus Ihse Bursie]

On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie  wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. 
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by 
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by 
>> make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after 
>> all, "source code" for that module that is "compiler" into resulting 
>> deliverables, for that module. (But the "source code" language is not Java 
>> or C, but typically a highly domain specific language or data format, and 
>> the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. 
>> When such data is changed, most of the time build-dev (or the new build 
>> label) is involved, even though this has nothing to do with the build. While 
>> this is annoying, a worse problem is if the actual team that needs to review 
>> the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to 
> a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - Merge tag 'jdk-19+13' into shuffle-data-reborn
>
>Added tag jdk-19+13 for changeset 5df2a057
>  - Move characterdata templates to share/classes/java/lang.
>  - Update comment refering to "make" dir
>  - Move new symbols to jdk.compiler
>  - Merge branch 'master' into shuffle-data
>  - Move macosxicons from share to macosx
>  - Move to share/data, and move jdwp.spec to java.se
>  - Update references in test
>  - ... and 2 more: 
> https://git.openjdk.java.net/jdk/compare/83d77186...598f740f

I have carefully reviewed all PR comments, and the changes I made in response 
to them. I believe I have resolved all requests from reviewers. What remained 
to do was to create an informational JEP about the new source structure, and 
file some follow-up issues.

I have now created and submitted a new informational JEP ("JDK Source 
Structure"), available at https://bugs.openjdk.java.net/browse/JDK-8283227. 
When creating this JEP, it felt increasingly silly to just copy and extend the 
part about src/$MODULE from JEP 201, so I extended it to cover a relevant 
overview of the entire JDK source base structure. I actually think this JEP has 
a good merit on its own, notwithstanding it being a reviewer requirement for 
this PR.

I have also filed follow up issues for the non-standard jdk.hotspot.agent `doc` 
and `test` directories (https://bugs.openjdk.java.net/browse/JDK-8283197 and 
https://bugs.openjdk.java.net/browse/JDK-8283198, respectively).

I have filed a follow up issue for continued efforts to clean up 
charsetmapping, https://bugs.openjdk.java.net/browse/JDK-8283228.

There were two open questions:

 * should jdwp.spec belong to specs directory instead of data
 * should bin/idea.sh be changed to exclude data

but they sounded so exploratory that I decided not to open JBS issues for them.

@wangweij  @naotoj  @prrace  @erikj79 @jonathan-gibbons  You have all approved 
this PR at an older revision. Can you please reconfirm that your approval 
stands for the latest revision? (Sorry for the mass ping)

-

PR: https://git.openjdk.java.net/jdk/pull/1611

Re: RFR: 8257733: Move module-specific data from make to respective module [v5]

[Magnus Ihse Bursie]

On Mon, 18 Jan 2021 13:47:20 GMT, Magnus Ihse Bursie  wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. 
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by 
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by 
>> make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after 
>> all, "source code" for that module that is "compiler" into resulting 
>> deliverables, for that module. (But the "source code" language is not Java 
>> or C, but typically a highly domain specific language or data format, and 
>> the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. 
>> When such data is changed, most of the time build-dev (or the new build 
>> label) is involved, even though this has nothing to do with the build. While 
>> this is annoying, a worse problem is if the actual team that needs to review 
>> the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Move characterdata templates to share/classes/java/lang.

This PR was almost ready to merge, but unfortunately got closed about a year 
ago when I disappeared on medical leave. :-( I've been putting off coming back 
to to this, worried that the merge conflicts would be bad. But no! Git handled 
the merge fantastically well; the default merge mode even realized that new 
files in a directory which had been moved elsewhere should probably also be 
moved to the same place. I was pleasantly surprised how easy this was. 

Nevertheless, I have carefully studied the automatic merge for any signs or 
mistakes. I only found one: a single renamed file (blacklist -> blocked) that 
it failed to match.

So I believe this PR is back in the same integrateable state that it was when I 
left it.

-

PR: https://git.openjdk.java.net/jdk/pull/1611

Re: RFR: 8257733: Move module-specific data from make to respective module [v6]

[Magnus Ihse Bursie]

> A lot (but not all) of the data in make/data is tied to a specific module. 
> For instance, the publicsuffixlist is used by java.base, and fontconfig by 
> java.desktop. (A few directories, like mainmanifest, is *actually* used by 
> make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after 
> all, "source code" for that module that is "compiler" into resulting 
> deliverables, for that module. (But the "source code" language is not Java or 
> C, but typically a highly domain specific language or data format, and the 
> "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. 
> When such data is changed, most of the time build-dev (or the new build 
> label) is involved, even though this has nothing to do with the build. While 
> this is annoying, a worse problem is if the actual team that needs to review 
> the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into shuffle-data-reborn
 - Fix merge
 - Merge tag 'jdk-19+13' into shuffle-data-reborn
   
   Added tag jdk-19+13 for changeset 5df2a057
 - Move characterdata templates to share/classes/java/lang.
 - Update comment refering to "make" dir
 - Move new symbols to jdk.compiler
 - Merge branch 'master' into shuffle-data
 - Move macosxicons from share to macosx
 - Move to share/data, and move jdwp.spec to java.se
 - Update references in test
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f

-

Changes: https://git.openjdk.java.net/jdk/pull/1611/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1611=05
  Stats: 85 lines in 1695 files changed: 4 ins; 1 del; 80 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611

Re: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v3]

[Claes Redestad]

On Wed, 9 Mar 2022 08:33:36 GMT, Xin Liu  wrote:

>> If AbstractStringBuilder only grow, the inflated value which has been 
>> encoded in UTF16 can't be compressed. 
>> toString() can skip compression in this case. This can save an 
>> ArrayAllocation in StringUTF16::compress().
>> 
>> java.io.BufferedRead::readLine() is a case that StringBuilder grows only. 
>> 
>> In microbench, we expect to see that allocation/op reduces 20%.  The initial 
>> capacity of StringBuilder is S in bytes. When it encounters the 1st 
>> character that can't be encoded in LATIN1, it inflates and allocate a new 
>> array of 2*S. `toString()` will try to compress that value so it need to 
>> allocate S bytes. The last step allocates 2*S bytes because it has to copy 
>> the string.  so it requires to allocate 5 * S bytes in total.  By skipping 
>> the failed compression, it only allocates 4 * S bytes.  that's 20%. In real 
>> execution, we observe 16% allocation reduction, tracked by JMH GC profiler 
>> `gc.alloc.rate.norm `.  I think it's because HotSpot can't track all 
>> allocations. 
>> 
>> Not only allocation drops, the runtime performance(ns/op) also increases 
>> from 3.34% to 18.91%. 
>> 
>> Before: 
>> 
>> $$make test 
>> TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars"
>>  MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm 
>> $HOME/Devel/jdk_baseline/bin/java" 
>> 
>> Benchmark   
>> (MIXED_SIZE)  Mode  Cnt Score Error   Units
>> StringBuilders.toStringWithMixedChars
>> 128  avgt   15   649.846 ±  76.291   ns/op
>> StringBuilders.toStringWithMixedChars:·gc.alloc.rate 
>> 128  avgt   15   872.855 ± 128.259  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.alloc.rate.norm
>> 128  avgt   15   880.121 ±   0.050B/op
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Eden_Space
>> 128  avgt   15   707.730 ± 194.421  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Eden_Space.norm   
>> 128  avgt   15   706.602 ±  94.504B/op
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Survivor_Space
>> 128  avgt   15 0.001 ±   0.002  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Survivor_Space.norm   
>> 128  avgt   15 0.001 ±   0.001B/op
>> StringBuilders.toStringWithMixedChars:·gc.count  
>> 128  avgt   15   113.000counts
>> StringBuilders.toStringWithMixedChars:·gc.time   
>> 128  avgt   1585.000ms
>> StringBuilders.toStringWithMixedChars
>> 256  avgt   15  1316.652 ± 112.771   ns/op
>> StringBuilders.toStringWithMixedChars:·gc.alloc.rate 
>> 256  avgt   15   800.864 ±  76.869  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.alloc.rate.norm
>> 256  avgt   15  1648.288 ±   0.162B/op
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Eden_Space
>> 256  avgt   15   599.736 ± 174.001  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Eden_Space.norm   
>> 256  avgt   15  1229.669 ± 318.518B/op
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Survivor_Space
>> 256  avgt   15 0.001 ±   0.001  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Survivor_Space.norm   
>> 256  avgt   15 0.001 ±   0.002B/op
>> StringBuilders.toStringWithMixedChars:·gc.count  
>> 256  avgt   15   133.000counts
>> StringBuilders.toStringWithMixedChars:·gc.time   
>> 256  avgt   1592.000ms
>> StringBuilders.toStringWithMixedChars
>>1024  avgt   15  5204.303 ± 418.115   ns/op
>> StringBuilders.toStringWithMixedChars:·gc.alloc.rate 
>>1024  avgt   15   768.730 ±  72.945  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.alloc.rate.norm
>>1024  avgt   15  6256.844 ±   0.358B/op
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Eden_Space
>>1024  avgt   15   655.852 ± 121.602  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Eden_Space.norm   
>>1024  avgt   15  5315.265 ± 578.878B/op
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Survivor_Space
>>1024  avgt   15 0.002 ±   0.002  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Survivor_Space.norm   
>>1024  avgt   15 0.014 ±   0.011B/op
>> StringBuilders.toStringWithMixedChars:·gc.count  
>>1024  avgt   1596.000counts
>> StringBuilders.toStringWithMixedChars:·gc.time   

Re: RFR: 8253495: CDS generates non-deterministic output [v8]

[Calvin Cheung]

On Tue, 15 Mar 2022 17:08:27 GMT, Ioi Lam  wrote:

>> This patch makes the result of "java -Xshare:dump" deterministic:
>> - Disabled new Java threads from launching. This is harmless. See comments 
>> in jvm.cpp
>> - Fixed a problem in hashtable ordering in heapShared.cpp
>> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random 
>> bits. Added code to zero it.
>> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in 
>> make/scripts/compare.sh
>> 
>> Note:  $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. 
>> This will be fixed in 
>> [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828).
>> 
>> Testing under way:
>> - tier1~tier5
>> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, 
>> windows-x86-cmp-baseline,  etc).
>
> Ioi Lam has updated the pull request incrementally with one additional commit 
> since the last revision:
> 
>   Avoid memset twice in os::malloc(); added comments about 
> NMTPreInit::handle_malloc vs DumpSharedSpaces

Marked as reviewed by ccheung (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7748

Re: RFR: 8279598: Provide adapter from RandomGenerator to Random [v17]

[Yasser Bazzi]

On Sat, 12 Mar 2022 01:26:24 GMT, Yasser Bazzi  wrote:

>> Hi, could i get a review on this implementation proposed by Stuart Marks, i 
>> decided to use the 
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html
>>  interface to create the default method `asRandom()` that wraps around the 
>> newer algorithms to be used on classes that do not accept the new interface.
>> 
>> Some things to note as proposed by the bug report, the protected method 
>> next(int bits) is not overrided and setSeed() method if left blank up to 
>> discussion on what to do with it.
>> 
>> Small test done on 
>> https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4
>
> Yasser Bazzi has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   make changes proposed

Merge done

-

PR: https://git.openjdk.java.net/jdk/pull/7001

Re: RFR: 8279598: Provide adapter from RandomGenerator to Random [v18]

[Yasser Bazzi]

> Hi, could i get a review on this implementation proposed by Stuart Marks, i 
> decided to use the 
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html
>  interface to create the default method `asRandom()` that wraps around the 
> newer algorithms to be used on classes that do not accept the new interface.
> 
> Some things to note as proposed by the bug report, the protected method 
> next(int bits) is not overrided and setSeed() method if left blank up to 
> discussion on what to do with it.
> 
> Small test done on 
> https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4

Yasser Bazzi has updated the pull request incrementally with one additional 
commit since the last revision:

  Fix SplittableRandomTest.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7001/files
  - new: https://git.openjdk.java.net/jdk/pull/7001/files/53c651f1..406e2bc8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7001=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7001=16-17

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7001.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001

PR: https://git.openjdk.java.net/jdk/pull/7001

RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0

[Tyler Steele]

As described in the linked issue, NullClassBytesTest fails due an 
OutOfMemoryError produced on AIX when the test calls defineClass with a byte 
array of size of 0. The native implementation of defineClass then calls  malloc 
with a size of 0. On AIX malloc(0) returns NULL, while on other platforms it 
return a valid address. When NULL is produced by malloc for this reason, 
ClassLoader.c incorrectly interprets this as a failure due to a lack of memory.

This PR modifies ClassLoader.c to produce an OutOfMemoryError only when `errno 
== ENOMEM` and to produce a ClassFormatError with the message "ClassLoader 
internal allocation failure" in all other cases (in which malloc returns NULL). 

In addition, I performed some minor tidy-up work in ClassLoader.c by changing 
instances of `return 0` to `return NULL`, and `if (some_ptr == 0)` to `if 
(some_ptr == NULL)`. This was done to improve the clarity of the code in 
ClassLoader.c, but didn't feel worthy of opening a separate issue.

### Alternatives

It would be possible to address this failure by modifying the test to accept 
the OutOfMemoryError on AIX. I thought it was a better solution to modify 
ClassLoader.c to produce an OutOfMemoryError only when the system is actually 
out of memory.

### Testing

This change has been tested on AIX and Linux/x86.

-

Commit messages:
 - Extract memory error logic to helper procedure
 - Updates copyright year and adds bug-id to test
 - Addresses NullClassBytesTest Failure

Changes: https://git.openjdk.java.net/jdk/pull/7829/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7829=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283225
  Stats: 43 lines in 2 files changed: 20 ins; 0 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7829.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7829/head:pull/7829

PR: https://git.openjdk.java.net/jdk/pull/7829

Re: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2

[Mikael Vidstedt]

On Fri, 11 Mar 2022 23:38:10 GMT, Mikael Vidstedt  wrote:

> Background, from JBS:
> 
> src/java.base/share/native/libverify/check_code.c: In function 
> 'read_all_code': 
> src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may 
> be used uninitialized [-Werror=maybe-uninitialized] 
>   942 | check_and_push(context, lengths, VM_MALLOC_BLK); 
>   | ^~~ 
> src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 
> 2 of type 'const void *' to 'check_and_push' declared here 
>  4145 | static void check_and_push(context_type *context, const void *ptr, 
> int kind) 
>   | ^~ 
> 
> 
> Because the second argument of check_and_push is "const void*" GCC assumes 
> that the malloc:ed data, which has not yet been initialized, will not be/can 
> not be modified later which in turn suggests it may be used without ever 
> being initialized. 
> 
> The same general issue was addressed in 
> [JDK-8266168](https://bugs.openjdk.java.net/browse/JDK-8266168), presumably 
> for GCC 11.1.
> 
> 
> Details:
> 
> Instead of sprinkling more calloc calls around or using pragmas/gcc 
> attributes I chose to change the check_and_push function to take a 
> (non-const) void* argument, and provide a new wrapper function 
> `check_and_push_const` which handles the const argument case. For the 
> (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a 
> const conversion.
> 
> To avoid having multiple ways of solving the same problem I also chose to 
> revert the change made in JDK-8266168, reverting the calloc back to a malloc 
> call.
> 
> Testing:
> 
> tier1 + builds-tier{2,3,4,5}

Adding hotspot-runtime to get some more eyes on this.

-

PR: https://git.openjdk.java.net/jdk/pull/7794

Re: RFR: JDK-8282008: Incorrect handling of quoted arguments in ProcessBuilder [v2]

[Roger Riggs]

> Quoting related changes in https://bugs.openjdk.java.net/browse/JDK-8250568 
> modified the way that
> process builder recognized argument strings, causing some arguments to be 
> doubly quoted and malformed.
> 
> ProcessBuilder encodes command arguments in two ways, a looser legacy encoding
> and stricter encoding that prevents quotes from being misinterpreted.
> The system property jdk.lang.Process.allowAmbiguousCommands controls which is 
> in effect.
> 
> When the property is "true" or not set, arguments are inserted into the 
> Windows command line
> with minimal changes.  Arguments containing space or tab are quoted to 
> prevent them being split.
> Arguments that start and end with double-quote are left alone.
> Some executables interpret a backslash before the final quote as an escape; 
> if the argument 
> contains first and last quotes, backslashes are ignored.
> 
> When the allowAmbigousCommands property is `false`, care is taken to ensure 
> that
> the final quote of an argument is the closing quote for the argument and is 
> not
> interpreted as a literal quote by a preceding quote (or an odd number of 
> quotes).
> 
> The PR includes a test matrix of the cases where an argument with spaces and 
> a final backslash
> is passed with each combination of `allowAmbiguousCommands = true and false`,
> launched executable, java, .cmd, and .vbs and when the argument is surrounded 
> with double-quotes.
> 
> The priority for allowAmbiguousCommands = false is that no argument is split 
> or joined to another argument.
> In some cases, backslashes are doubled to prevent a double-quote from being 
> interpreted incorrectly.
> The trailing backslash in an argument occurs rarely exception when the 
> argument is a directory.
> In that case, the addition of trailing backslashes is benign when the string 
> is used as a filesystem path.
> 
> See also PR#7504, for background and a proposal.

Roger Riggs has updated the pull request incrementally with one additional 
commit since the last revision:

  Refactored ArgCheck test to be more readable and easier to maintain and 
backport

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7709/files
  - new: https://git.openjdk.java.net/jdk/pull/7709/files/a194e439..7db92baf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7709=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7709=00-01

  Stats: 164 lines in 1 file changed: 37 ins; 42 del; 85 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7709.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7709/head:pull/7709

PR: https://git.openjdk.java.net/jdk/pull/7709

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v6]

[Valerie Peng]

> It's been several years since we increased the default key sizes. Before 
> shifting to PQC, NSA replaced its Suite B cryptography recommendations with 
> the Commercial National Security Algorithm Suite which suggests:
> 
> - SHA-384 for secure hashing
> - AES-256 for symmetric encryption
> - RSA with 3072 bit keys for digital signatures and for key exchange
> - Diffie Hellman (DH) with 3072 bit keys for key exchange
> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures 
> (ECDSA)
> 
> So, this proposed changes made the suggested key size and algorithm changes. 
> The changes are mostly in keytool, jarsigner and their regression tests, so 
> @wangweij Could you please take a look?
> 
> Thanks!

Valerie Peng has updated the pull request incrementally with one additional 
commit since the last revision:

  Removed NPE from the catch statement.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7652/files
  - new: https://git.openjdk.java.net/jdk/pull/7652/files/48f562ab..c8ae1655

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7652.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652

PR: https://git.openjdk.java.net/jdk/pull/7652

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]

[Valerie Peng]

On Mon, 14 Mar 2022 21:24:15 GMT, Weijun Wang  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Update again and undo DSA changes
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java
>  line 122:
> 
>> 120: default -> {
>> 121: throw new ProviderException
>> 122: ("Unrecognized algorithm for checking key 
>> size");
> 
> If it's an unknown key algorithm, is it possible we just ignore it and keep 
> using `minKeyLen` and `maxKeyLen`?

Well, instead of ignore unknown key algorithm, perhaps safer to throw Exception 
so it can be caught and handled during develop time. P11KeyPairGenerator class 
is only used for known algorithms which it is registered for, so probably ok to 
go either way. I'd prefer to play it safe and force a review of this block of 
code when new algorithm is added.

-

PR: https://git.openjdk.java.net/jdk/pull/7652

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]

[Valerie Peng]

On Mon, 14 Mar 2022 21:18:56 GMT, Weijun Wang  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Update again and undo DSA changes
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java
>  line 101:
> 
>> 99: // set default key sizes and apply our own algorithm-specific 
>> limits
>> 100: // override lower limit to disallow unsecure keys being 
>> generated
>> 101: // override upper limit to deter DOS attack
> 
> Not a P11 expert, but I assume `algorithm` here is already guaranteed to be 
> in uppercase?

Yes, for P11KeyPairGenerator, its algorithm values are all in uppercase. I 
verified it with an existing regression test.

-

PR: https://git.openjdk.java.net/jdk/pull/7652

Re: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v3]

[Xin Liu]

On Wed, 9 Mar 2022 08:33:36 GMT, Xin Liu  wrote:

>> If AbstractStringBuilder only grow, the inflated value which has been 
>> encoded in UTF16 can't be compressed. 
>> toString() can skip compression in this case. This can save an 
>> ArrayAllocation in StringUTF16::compress().
>> 
>> java.io.BufferedRead::readLine() is a case that StringBuilder grows only. 
>> 
>> In microbench, we expect to see that allocation/op reduces 20%.  The initial 
>> capacity of StringBuilder is S in bytes. When it encounters the 1st 
>> character that can't be encoded in LATIN1, it inflates and allocate a new 
>> array of 2*S. `toString()` will try to compress that value so it need to 
>> allocate S bytes. The last step allocates 2*S bytes because it has to copy 
>> the string.  so it requires to allocate 5 * S bytes in total.  By skipping 
>> the failed compression, it only allocates 4 * S bytes.  that's 20%. In real 
>> execution, we observe 16% allocation reduction, tracked by JMH GC profiler 
>> `gc.alloc.rate.norm `.  I think it's because HotSpot can't track all 
>> allocations. 
>> 
>> Not only allocation drops, the runtime performance(ns/op) also increases 
>> from 3.34% to 18.91%. 
>> 
>> Before: 
>> 
>> $$make test 
>> TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars"
>>  MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm 
>> $HOME/Devel/jdk_baseline/bin/java" 
>> 
>> Benchmark   
>> (MIXED_SIZE)  Mode  Cnt Score Error   Units
>> StringBuilders.toStringWithMixedChars
>> 128  avgt   15   649.846 ±  76.291   ns/op
>> StringBuilders.toStringWithMixedChars:·gc.alloc.rate 
>> 128  avgt   15   872.855 ± 128.259  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.alloc.rate.norm
>> 128  avgt   15   880.121 ±   0.050B/op
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Eden_Space
>> 128  avgt   15   707.730 ± 194.421  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Eden_Space.norm   
>> 128  avgt   15   706.602 ±  94.504B/op
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Survivor_Space
>> 128  avgt   15 0.001 ±   0.002  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Survivor_Space.norm   
>> 128  avgt   15 0.001 ±   0.001B/op
>> StringBuilders.toStringWithMixedChars:·gc.count  
>> 128  avgt   15   113.000counts
>> StringBuilders.toStringWithMixedChars:·gc.time   
>> 128  avgt   1585.000ms
>> StringBuilders.toStringWithMixedChars
>> 256  avgt   15  1316.652 ± 112.771   ns/op
>> StringBuilders.toStringWithMixedChars:·gc.alloc.rate 
>> 256  avgt   15   800.864 ±  76.869  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.alloc.rate.norm
>> 256  avgt   15  1648.288 ±   0.162B/op
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Eden_Space
>> 256  avgt   15   599.736 ± 174.001  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Eden_Space.norm   
>> 256  avgt   15  1229.669 ± 318.518B/op
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Survivor_Space
>> 256  avgt   15 0.001 ±   0.001  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Survivor_Space.norm   
>> 256  avgt   15 0.001 ±   0.002B/op
>> StringBuilders.toStringWithMixedChars:·gc.count  
>> 256  avgt   15   133.000counts
>> StringBuilders.toStringWithMixedChars:·gc.time   
>> 256  avgt   1592.000ms
>> StringBuilders.toStringWithMixedChars
>>1024  avgt   15  5204.303 ± 418.115   ns/op
>> StringBuilders.toStringWithMixedChars:·gc.alloc.rate 
>>1024  avgt   15   768.730 ±  72.945  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.alloc.rate.norm
>>1024  avgt   15  6256.844 ±   0.358B/op
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Eden_Space
>>1024  avgt   15   655.852 ± 121.602  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Eden_Space.norm   
>>1024  avgt   15  5315.265 ± 578.878B/op
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Survivor_Space
>>1024  avgt   15 0.002 ±   0.002  MB/sec
>> StringBuilders.toStringWithMixedChars:·gc.churn.G1_Survivor_Space.norm   
>>1024  avgt   15 0.014 ±   0.011B/op
>> StringBuilders.toStringWithMixedChars:·gc.count  
>>1024  avgt   1596.000counts
>> StringBuilders.toStringWithMixedChars:·gc.time   

Integrated: 8283075: Bad IllegalArgumentException message for out of range rank from ClassDesc.arrayType(int)

[Joe Darcy]

On Mon, 14 Mar 2022 19:56:17 GMT, Joe Darcy  wrote:

> Improving the exception messages for out-of-supported-range array types.
> 
> I'll update copyrights before pushing.

This pull request has now been integrated.

Changeset: 32f8437d
Author:Joe Darcy 
URL:   
https://git.openjdk.java.net/jdk/commit/32f8437d85a003914d5ca35bdddebdc732ab222d
Stats: 35 lines in 2 files changed: 28 ins; 0 del; 7 mod

8283075: Bad IllegalArgumentException message for out of range rank from 
ClassDesc.arrayType(int)

Reviewed-by: vromero, alanb

-

PR: https://git.openjdk.java.net/jdk/pull/7812

Re: RFR: 8283075: Bad IllegalArgumentException message for out of range rank from ClassDesc.arrayType(int) [v2]

[liach]

On Tue, 15 Mar 2022 17:09:03 GMT, Joe Darcy  wrote:

>> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 185:
>> 
>>> 183: netRank = Math.addExact(currentDepth, rank);
>>> 184: if (netRank > 
>>> ConstantUtils.MAX_ARRAY_TYPE_DESC_DIMENSIONS) {
>>> 185: throw new IllegalArgumentException("rank: " + netRank +
>> 
>> This doesn’t need to use [Math.addExact](currentDepth, 
>> rank), as currentDepth will always 
>> be in [0, 255], and rank here is confined to [1, 
>> 231-1], so it’s possible to check for netRank 
>>  0 and use 
>> [Integer.toUnsignedString](netRank) (or 
>> [Integer.toUnsignedLong](netRank) and let 
>> [StringConcatFactory] deal with it):
>> 
>> Suggestion:
>> 
>> netRank = currentDepth + rank;
>> if (netRank > ConstantUtils.MAX_ARRAY_TYPE_DESC_DIMENSIONS || 
>> netRank < 0) {
>> throw new IllegalArgumentException("rank: " + 
>> Integer.toUnsignedLong(netRank) +
>> 
>> 
>> [Integer.toUnsignedLong]: 
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Integer.html#toUnsignedLong(int)
>> [Integer.toUnsignedString]: 
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Integer.html#toUnsignedString(int)
>> [Math.addExact]: 
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Math.html#addExact(int,int)
>> [StringConcatFactory]: 
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/StringConcatFactory.html
>
> Hmm. In this context, I think using addExact is clearer regarding the 
> intention of the check. Thanks.

Notice the overflow case is already handled by the `ArithmeticException` caught 
in the larger try block.

-

PR: https://git.openjdk.java.net/jdk/pull/7812

Re: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2]

[Joe Darcy]

On Tue, 15 Mar 2022 13:49:34 GMT, ExE Boss  wrote:

>> Joe Darcy has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 185:
> 
>> 183: netRank = Math.addExact(currentDepth, rank);
>> 184: if (netRank > ConstantUtils.MAX_ARRAY_TYPE_DESC_DIMENSIONS) 
>> {
>> 185: throw new IllegalArgumentException("rank: " + netRank +
> 
> This doesn’t need to use [Math.addExact](currentDepth, 
> rank), as currentDepth will always 
> be in [0, 255], and rank here is confined to [1, 
> 231-1], so it’s possible to check for netRank 
>  0 and use 
> [Integer.toUnsignedString](netRank) (or 
> [Integer.toUnsignedLong](netRank) and let 
> [StringConcatFactory] deal with it):
> 
> Suggestion:
> 
> netRank = currentDepth + rank;
> if (netRank > ConstantUtils.MAX_ARRAY_TYPE_DESC_DIMENSIONS || 
> netRank < 0) {
> throw new IllegalArgumentException("rank: " + 
> Integer.toUnsignedLong(netRank) +
> 
> 
> [Integer.toUnsignedLong]: 
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Integer.html#toUnsignedLong(int)
> [Integer.toUnsignedString]: 
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Integer.html#toUnsignedString(int)
> [Math.addExact]: 
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Math.html#addExact(int,int)
> [StringConcatFactory]: 
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/StringConcatFactory.html

Hmm. In this context, I think using addExact is clearer regarding the intention 
of the check. Thanks.

-

PR: https://git.openjdk.java.net/jdk/pull/7812

Re: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2]

[Joe Darcy]

On Tue, 15 Mar 2022 13:50:03 GMT, ExE Boss  wrote:

>> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 179:
>> 
>>> 177: int netRank;
>>> 178: if (rank <= 0) {
>>> 179: throw new IllegalArgumentException("rank " + rank + "is 
>>> not a positive value");
>> 
>> There's a space missing in the IAE message after the rank number. For 
>> example, if rank == 0, the message would be: "rank 0is not positive value" 
>> ...
>
> Suggestion:
> 
> throw new IllegalArgumentException("rank " + rank + " is not a 
> positive value");

Good catch; will fix before pushing.

-

PR: https://git.openjdk.java.net/jdk/pull/7812

Re: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v3]

[Joe Darcy]

> Improving the exception messages for out-of-supported-range array types.
> 
> I'll update copyrights before pushing.

Joe Darcy has updated the pull request with a new target base due to a merge or 
a rebase. The incremental webrev excludes the unrelated changes brought in by 
the merge/rebase. The pull request contains six additional commits since the 
last revision:

 - Update copyright and fix typo.
 - Merge branch 'master' into JDK-8283075
 - Respond to review feedback.
 - Appease jcheck
 - Update @bug line of test
 - JDK-8283075: Bad `IllegalArgumentException` message when calling 
`ClassDesc.arrayType(int)` which results in a rank > 255

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7812/files
  - new: https://git.openjdk.java.net/jdk/pull/7812/files/1723d710..514a57a1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7812=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7812=01-02

  Stats: 1594 lines in 67 files changed: 1085 ins; 268 del; 241 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7812.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7812/head:pull/7812

PR: https://git.openjdk.java.net/jdk/pull/7812

Re: RFR: 8253495: CDS generates non-deterministic output [v8]

[Ioi Lam]

> This patch makes the result of "java -Xshare:dump" deterministic:
> - Disabled new Java threads from launching. This is harmless. See comments in 
> jvm.cpp
> - Fixed a problem in hashtable ordering in heapShared.cpp
> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random 
> bits. Added code to zero it.
> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in 
> make/scripts/compare.sh
> 
> Note:  $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. 
> This will be fixed in 
> [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828).
> 
> Testing under way:
> - tier1~tier5
> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, 
> windows-x86-cmp-baseline,  etc).

Ioi Lam has updated the pull request incrementally with one additional commit 
since the last revision:

  Avoid memset twice in os::malloc(); added comments about 
NMTPreInit::handle_malloc vs DumpSharedSpaces

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7748/files
  - new: https://git.openjdk.java.net/jdk/pull/7748/files/cd934f3c..f202bcbf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7748=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7748=06-07

  Stats: 7 lines in 1 file changed: 5 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7748.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7748/head:pull/7748

PR: https://git.openjdk.java.net/jdk/pull/7748

Integrated: JDK-8283124: Add constant for tau to Math and StrictMath

[Joe Darcy]

On Mon, 14 Mar 2022 20:52:39 GMT, Joe Darcy  wrote:

> Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a very 
> common value in mathematical formulas, it is helpful to give it a distinct 
> constant.
> 
> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283136

This pull request has now been integrated.

Changeset: 05a83e03
Author:Joe Darcy 
URL:   
https://git.openjdk.java.net/jdk/commit/05a83e03ca35b4885b48bb0e7d188baf8f7d9d7f
Stats: 29 lines in 2 files changed: 26 ins; 0 del; 3 mod

8283124: Add constant for tau to Math and StrictMath

Reviewed-by: bpb, iris

-

PR: https://git.openjdk.java.net/jdk/pull/7813

Re: RFR: JDK-8283124: Add constant for tau to Math and StrictMath [v3]

[Joe Darcy]

> Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a very 
> common value in mathematical formulas, it is helpful to give it a distinct 
> constant.
> 
> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283136

Joe Darcy has updated the pull request with a new target base due to a merge or 
a rebase. The incremental webrev excludes the unrelated changes brought in by 
the merge/rebase. The pull request contains three additional commits since the 
last revision:

 - Merge branch 'master' into JDK-8283124
 - Set value with 2.0 * PI.
 - JDK-8283124: Add constant for tau to Math and StrictMath

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7813/files
  - new: https://git.openjdk.java.net/jdk/pull/7813/files/0fae656a..0cd1f61e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7813=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7813=01-02

  Stats: 1563 lines in 66 files changed: 1059 ins; 268 del; 236 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7813.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7813/head:pull/7813

PR: https://git.openjdk.java.net/jdk/pull/7813

Re: RFR: 8279598: Provide adapter from RandomGenerator to Random [v17]

[Stuart Marks]

On Sat, 12 Mar 2022 01:26:24 GMT, Yasser Bazzi  wrote:

>> Hi, could i get a review on this implementation proposed by Stuart Marks, i 
>> decided to use the 
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html
>>  interface to create the default method `asRandom()` that wraps around the 
>> newer algorithms to be used on classes that do not accept the new interface.
>> 
>> Some things to note as proposed by the bug report, the protected method 
>> next(int bits) is not overrided and setSeed() method if left blank up to 
>> discussion on what to do with it.
>> 
>> Small test done on 
>> https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4
>
> Yasser Bazzi has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   make changes proposed

OK, I ran our test suite and found that SplittableRandomTest failed. Please 
merge in the fix from the latest commit on this branch:

https://github.com/stuart-marks/jdk/commits/pull/7001

With this fix in place I get a clean test run.

-

PR: https://git.openjdk.java.net/jdk/pull/7001

Integrated: JDK-8283143: Use minimal-length literals to initialize PI and E constants

[Joe Darcy]

On Tue, 15 Mar 2022 01:36:14 GMT, Joe Darcy  wrote:

> Depending on the range of the number line, a double value has between 15 and 
> 17 digits of decimal precision. The literals used to initialize Math.PI and 
> Math.E have several digits more precision than that maximum.
> 
> That is potentially confusing to readers of the code and the minimum length 
> strings to exactly represent the value in question should be used instead.

This pull request has now been integrated.

Changeset: 671b6efd
Author:Joe Darcy 
URL:   
https://git.openjdk.java.net/jdk/commit/671b6efd6126384c0630d1cd84f53f52995e68d8
Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8283143: Use minimal-length literals to initialize PI and E constants

Reviewed-by: smarks

-

PR: https://git.openjdk.java.net/jdk/pull/7814

Re: RFR: JDK-8283143: Use minimal-length literals to initialize PI and E constants [v2]

[Joe Darcy]

> Depending on the range of the number line, a double value has between 15 and 
> 17 digits of decimal precision. The literals used to initialize Math.PI and 
> Math.E have several digits more precision than that maximum.
> 
> That is potentially confusing to readers of the code and the minimum length 
> strings to exactly represent the value in question should be used instead.

Joe Darcy has updated the pull request incrementally with one additional commit 
since the last revision:

  Update copyright.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7814/files
  - new: https://git.openjdk.java.net/jdk/pull/7814/files/3bf9de9f..f4c0e63e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7814=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7814=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7814.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7814/head:pull/7814

PR: https://git.openjdk.java.net/jdk/pull/7814

Re: Discussion about Java Floating Point?

[Bernd Eckenfels]

Please stop sending mails marked as urgent to a mailing list, you just make a 
fool of yourself.

The need to round floating point numbers for commercial math (and the risk 
involved in doing so) is nothing new, it predates the IEEE standard and should 
be subject for even basic comp sci curriculums all over the world.

(Having said that, automatic precision/rounding for number formats in C++ looks 
neat)

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von A Z 

Gesendet: Dienstag, März 15, 2022 5:24 AM
An: core-libs-dev@openjdk.java.net 
Betreff: Discussion about Java Floating Point?

To core-libs-dev@openjdk.java.net,

In terms of floating point, it seems there are thus
three (3) phenomena that are relevant.

1) Arithmetic on float and double, via operators.
2) Elementary function calls, namely
   those made from java.lang.StrictMath, as it is,
   on double values.
3) Comparison operators.  ==, !=, >, <, >=,<=.

Java floating point successfully has 3) the way required,
even though other languages, particularly C++ , do not
compare their floats and doubles through those comparison
operators.  The point at issue is Java although, so Java is
satisfactory at point 3).

My point of contention is that Java does not have 1) and 2)
operating as they should, even though C++ and other
languages do, in those two areas, namely C++:

Martin has submitted the following:
?The following statement is not entirely true when using finite floating
point precision:

> (?snip?) It is a mathematical fact that, for
> consistent, necessary and even fast term, 10% of 10% must
> always precisely be 1%, and by no means anything else."
/*
#include 

using namespace std;

int main()
{
cout << "Program has started..." << endl;
double a = 0.1D;
double b = 0.1D;
double c = a*b;
cout << endl << c << endl << endl;
float d = 0.1F;
float e = 0.1F;
float f = d*e;
cout << f << endl << endl;
cout << "Program has Finished.";
return 0;
}
*/
/*
Program has started...

0.01

0.01

Program has Finished.
*/

This is actually not fully or finally true, including SSE, SSE algorithm logic 
and further.
The included C++ example of mine above here disproves this.  Even though I do
contextually admit these answers can only work within the range of the
involved types, it is still actually the case that 10% of 10% can and always
precisely be 1%, within the range of the type used, and by no means
anything else.  Because of the laws of decimal arithmetic.

See https://en.wikipedia.org/wiki/Floating-point_arithmetic
and the starting sentence:

'In computing, floating-point arithmetic (FP) is arithmetic using formulaic
representation of real numbers as an approximation to support a
trade-off betwee range and precision.'

However, it simply isn't the case that reduced precision has to exist inside
the range, certainly not any more.  Rationally, one would have to think,
with the present SSE support in ubiquity, and the preimplementation
that is possible and already around elsewhere, that this kind of tradeoff
in floating point isn't any kind of use or advantage any more.

This is part of the issue with Java and the OpenJDK at this time, and I am 
trying
to contend that this should be changed, either at default or in
some mutual compatibility mode.  The other part is java.lang.StrictMath,
since it generates denormal and pronormal values on its own, also.

Raffaello has stated:
To summarize, Java uses IEEE 754 binary arithmetic as by specification,
as do most other languages, including C/C++. It is however fundamentally
wrong to use binary floating-point arithmetic to emulate decimal
behavior. Also, pay attention to the output routines that convert float
and double values to a decimal representation. Usually, C and C++ will
have information loss by default, as in your case.
What we and others are beginning to need to happen, in detailed Java 2D
and 3D (JMonkeyEngine 3.5) projects, and more widely again, is that Java
floating point arithmetic and function behaviour, on float and double,
within their ranges, do need to perfectly match decimal behaviour.

C++ arithmetic, at least, has had no problem using floating point arithmetic,
at least, to emulate decimal behaviour.  I am trying to prove the opposite to
Raffaello's statements, that floating point can and indeed must represent 
decimal behaviour.
Output functions in any language that alter the appearance of the float or 
double
value become irrelevant, because the only relevant factor is the operator 
behaviour
and the innate, representation viewpoint of those float or double values.

In contrast to Raffaelo, we assert that Java SE and OpenJDK floating point must 
be changed
so that it upholds base ten (10) arithmetic, algebra,and elementary functions 
on real value
arguments within the ranges of double and/or float.  Alongside a calculator 
class that upholds
the same.  These are in keeping with the Wikipedia 

Integrated: 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows

[Zhengyu Gu]

On Thu, 10 Mar 2022 18:40:13 GMT, Zhengyu Gu  wrote:

> Please review this small patch that fixes early `CHECK_NULL_RETURN` results 
> not releasing native `jchar` array returned by `GetStringChars()`.

This pull request has now been integrated.

Changeset: 2cddf3f5
Author:Zhengyu Gu 
URL:   
https://git.openjdk.java.net/jdk/commit/2cddf3f5391518ea40796e6c4759047d51b7b312
Stats: 8 lines in 1 file changed: 2 ins; 3 del; 3 mod

8282887: Potential memory leak in 
sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on 
Windows

Reviewed-by: naoto, alanb

-

PR: https://git.openjdk.java.net/jdk/pull/

Re: RFR: 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows

[Zhengyu Gu]

On Thu, 10 Mar 2022 19:46:28 GMT, Naoto Sato  wrote:

>> Please review this small patch that fixes early `CHECK_NULL_RETURN` results 
>> not releasing native `jchar` array returned by `GetStringChars()`.
>
> LGTM.

Thanks, @naotoj @AlanBateman

-

PR: https://git.openjdk.java.net/jdk/pull/

Re: RFR: 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows

[Alan Bateman]

On Thu, 10 Mar 2022 18:40:13 GMT, Zhengyu Gu  wrote:

> Please review this small patch that fixes early `CHECK_NULL_RETURN` results 
> not releasing native `jchar` array returned by `GetStringChars()`.

Marked as reviewed by alanb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/

Re: Behavior change in the jar tool JDK11 vs JDK8.

[Alan Bateman]

On 15/03/2022 13:23, Pasam Soujanya1 wrote:
Yes, jar command fails(exit code is 1) from JDK11 onward when target 
files do not exist while archiving the data.


Can you check JDK 8u? I would expect the exit code to be non-0 with that 
release too, it's just that it leaves behind the file. That's the bug 
that was fixed in JDK 9 via JDK-8174996.


-Alan

Re: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2]

[ExE Boss]

On Mon, 14 Mar 2022 21:27:29 GMT, Joe Darcy  wrote:

>> Improving the exception messages for out-of-supported-range array types.
>> 
>> I'll update copyrights before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Respond to review feedback.

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 185:

> 183: netRank = Math.addExact(currentDepth, rank);
> 184: if (netRank > ConstantUtils.MAX_ARRAY_TYPE_DESC_DIMENSIONS) {
> 185: throw new IllegalArgumentException("rank: " + netRank +

This doesn’t need to use [Math.addExact](currentDepth, 
rank), as currentDepth will always be 
in [0, 255], and rank here is confined to [1, 
231-1], so it’s possible to check for netRank  
0 and use [Integer.toUnsignedString](netRank) 
(or [Integer.toUnsignedLong](netRank) and let 
[StringConcatFactory] deal with it):

Suggestion:

netRank = currentDepth + rank;
if (netRank > ConstantUtils.MAX_ARRAY_TYPE_DESC_DIMENSIONS || 
netRank < 0) {
throw new IllegalArgumentException("rank: " + 
Integer.toUnsignedLong(netRank) +


[Integer.toUnsignedLong]: 
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Integer.html#toUnsignedLong(int)
[Integer.toUnsignedString]: 
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Integer.html#toUnsignedString(int)
[Math.addExact]: 
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Math.html#addExact(int,int)
[StringConcatFactory]: 
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/StringConcatFactory.html

-

PR: https://git.openjdk.java.net/jdk/pull/7812

Re: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2]

[ExE Boss]

On Tue, 15 Mar 2022 07:50:29 GMT, Peter Levart  wrote:

>> Joe Darcy has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 179:
> 
>> 177: int netRank;
>> 178: if (rank <= 0) {
>> 179: throw new IllegalArgumentException("rank " + rank + "is not 
>> a positive value");
> 
> There's a space missing in the IAE message after the rank number. For 
> example, if rank == 0, the message would be: "rank 0is not positive value" ...

Suggestion:

throw new IllegalArgumentException("rank " + rank + " is not a 
positive value");

-

PR: https://git.openjdk.java.net/jdk/pull/7812

Re: RFR: 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows

[Zhengyu Gu]

On Thu, 10 Mar 2022 18:40:13 GMT, Zhengyu Gu  wrote:

> Please review this small patch that fixes early `CHECK_NULL_RETURN` results 
> not releasing native `jchar` array returned by `GetStringChars()`.

Friendly ping. May I have a second review, please!

-

PR: https://git.openjdk.java.net/jdk/pull/

RE: Behavior change in the jar tool JDK11 vs JDK8.

[Pasam Soujanya1]

Yes, jar command fails(exit code is 1) from JDK11 onward when target files do 
not exist while archiving the data.

Please find the below jar execution with JDK11
$ jar -cvf sample.jar nofile.txt
nofile.txt : no such file or directory
added manifest
$ echo $?
1

Could you please share any documentation if exists, with this behavior change. 
We couldn't find it in the release notes of 9,10,11.

Thanks,
Pasam Soujanya.

From: Alan Bateman 
Sent: Tuesday, March 15, 2022 5:39 PM
To: Pasam Soujanya1 
Cc: core-libs-dev@openjdk.java.net 
Subject: [EXTERNAL] Re: Behavior change in the jar tool JDK11 vs JDK8.

On 15/03/2022 11:33, Pasam Soujanya1 wrote: Basically, we have a customer who 
use the jar command to zip up data files generated in a directory, most of the 
time the files don't exist. ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
On 15/03/2022 11:33, Pasam Soujanya1 wrote:
Basically, we have a customer who use the jar command to zip up data files 
generated in a directory, most of the time the files don't exist.

Can you confirm that the jar command is failing, meaning the exit code is 
non-0? The change in JDK 9 to remove the temporay file when jar fails was 
deliberate. Yes, it probably should have had a release note at the time.

-Alan

Re: Should System.exit be controlled by a Scope Local?

[Andrew Haley]

On 3/1/22 18:17, Sean Mullan wrote:

Can you explain in a little more detail as to what the compatibility
issues are with preventing threads in thread pools from calling System.exit?


It is possible, I suppose, that some rather odd programmer is using
a task in a thread pool to exit their program. I know, unlikely, but
we preserve compatibility.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: RFR: JDK-8236128: Allow jpackage create installers for services

[Erik Joelsson]

On Fri, 11 Mar 2022 23:37:06 GMT, Alexey Semenyuk  wrote:

> Implementation of [JDK-8275062: "Allow jpackage create installers for 
> services"](https://bugs.openjdk.java.net/browse/JDK-8275062)
>  CSR

Build change looks good.

-

PR: https://git.openjdk.java.net/jdk/pull/7793

Re: Behavior change in the jar tool JDK11 vs JDK8.

[Alan Bateman]

On 15/03/2022 11:33, Pasam Soujanya1 wrote:
Basically, we have a customer who use the jar command to zip up data 
files generated in a directory, most of the time the files don't exist.


Can you confirm that the jar command is failing, meaning the exit code 
is non-0? The change in JDK 9 to remove the temporay file when jar fails 
was deliberate. Yes, it probably should have had a release note at the time.


-Alan

RE: Behavior change in the jar tool JDK11 vs JDK8.

[Pasam Soujanya1]

Basically, we have a customer who use the jar command to zip up data files 
generated in a directory, most of the time the files don't exist. With JDK11, 
the jar archive is not created, and they see their tests failing. Their tests 
were probably written to suit the JDK8 behavior.

However, if this behavior introduced in JDK9 was intentional, I am good with 
it. Thank you for the advice!

Thanks,
Pasam Soujanya.

From: Alan Bateman 
Sent: Tuesday, March 15, 2022 2:27 PM
To: Pasam Soujanya1 
Cc: core-libs-dev@openjdk.java.net ; 
fo...@univ-mlv.fr 
Subject: [EXTERNAL] Re: Behavior change in the jar tool JDK11 vs JDK8.

On 15/03/2022 08:18, Pasam Soujanya1 wrote: I tried "tar" with a target that 
does not exist, and the tar file got created successfully (with an error 
message about the missing file) and with the exit code 0 (success). Same 
behavior ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
On 15/03/2022 08:18, Pasam Soujanya1 wrote:
I tried "tar" with a target that does not exist, and the tar file got created 
successfully (with an error message about the missing file) and with the exit 
code 0 (success). Same behavior is seen with JDK8 jar too. From JDK11 onward, 
the output jar isn't created and the exit code is 1(failure).

So, to summarise: "jar" from Java 8 seems to be on the lines of "tar".

Do we want to continue with this "jar" behaviour which is not the same as "tar" 
?

The behavior since JDK 9 is to delete the temporary file when there is an 
error. This looks to be the correct behavior. If it were changed back then 
people would complain that jar is leaving files behind when it fails.

I'm curious how you run into this. Is this a script that runs with +e or 
doesn't check the exit status?

-Alan

Re: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v15]

[Claes Redestad]

On Mon, 14 Mar 2022 20:30:51 GMT, Roger Riggs  wrote:

>> Claes Redestad has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Fix copyright year in new test
>
> core libs String.java changes look fine.

Thanks @RogerRiggs 

I intend to push this soon regardless, but would appreciate an explicit review 
of the aarch64 changes from an aarch64 maintainer.

-

PR: https://git.openjdk.java.net/jdk/pull/7231

Re: Discussion about Java Floating Point?

[Martin Desruisseaux]

Hello A.Z.

As Raffaello said, Java arithmetic does not have any more problem than 
C/C++ when using IEEE 754. The "proof" of contrary is only an illusion 
due to the rounding behavior of C/C++ output routines, as demonstrated 
by Raffaello's code. Maybe some C/C++ code use Intel extended precision 
arithmetic (80 bits instead of 64 bits), but it only pushes the problem 
further, it still not an exact representation of decimal numbers. Exact 
representation of 0.1 using base 2 is mathematically impossible, no 
matter the language (it is a periodic number in base 2).


    Regards,

        Martin

Re: Discussion about Java Floating Point?

[Raffaello Giulietti]

Sorry, for some reason a line was missing in the C++ code


#include 

using namespace std;

int main()
{
cout << "Program has started..." << endl;
double a = 0.1D;
double b = 0.1D;
double c = a*b;
double d = 0.01D;
cout << endl << "0.1D*0.1D " << (c == d ? "==" : "!=") << " 0.01D" 
<< endl << endl;

cout << "0.1D*0.1D : ";
cout.precision(30);
cout << c << endl;
cout << "0.01D : ";
cout.precision(30);
cout << d << endl << endl;
cout << "Program has finished." << endl;
return 0;
}



On 3/15/22 11:03, Raffaello Giulietti wrote:

Hi,

Java, as well as most implementations of most languages, including C and 
C++, have adopted the IEEE 754 floating-point standard, first issued in 
1985. The standard specifies the formats, the outcome of operators and 
comparisons up to the last bit.


Try out this C/C++ code (I'm on Linux with gcc)



#include 

using namespace std;

int main()
{
     cout << "Program has started..." << endl;
     double a = 0.1D;
     double b = 0.1D;
     double c = a*b;
     double d = 0.01D;
     cout << endl << "0.1D*0.1D " << (c == d ? "==" : "!=") << " 0.01D" 
<< endl << endl;

     cout.precision(30);
     cout << c << endl;
     cout << "0.01D : ";
     cout.precision(30);
     cout << d << endl << endl;
     cout << "Program has finished." << endl;
     return 0;
}



This is the output I see:



Program has started...

0.1D*0.1D != 0.01D

0.1D*0.1D : 0.010001942890293094
0.01D : 0.012081668171172

Program has finished.



So 0.1D*0.1D != 0.01D, as stated on my previous post. That is, 
expectations on decimal behavior are usually wrong. It is inherently, 
mathematically *impossible* to emulate decimal behavior with binary IEEE 
754 arithmetic. That's why Java also offers java.math.BigDecimal, a 
decimal floating-point library implemented in software.


Also, as suggested in that post, incrementing the precision of the 
output by means of precision(30) as done above, for example, also 
clearly shows where the two values start being different, with 0.1D*0.1D 
being slightly greater than 0.01D.


Note that the precision only directs how many digits appear in the 
decimal output: it doesn't affect the underlying floating-point 
arithmetic at all. The latter follows the spec in full. In fact, all 
operators and comparisons are implemented directly in hardware, not in 
libraries. All CPUs designed in the last couple of decades implement 
IEEE 754.


This shows that the default precision for decimal output in C/C++ is not 
sufficient to expose the difference between the values. You have to set 
a higher precision to see differences.


This also shows the advantage of the default Java conversion routine, as 
opposed to the default precision in C/C++: different values are 
converted to different decimal outcome, without you having to set 
anything, because Java adapts the precision of the output automatically, 
depending on the value.


Finally, while Wikipedia is an exceptional source of information, the 
ultimate authoritative reference are the IEEE 754 spec, the C/C++ specs 
and other languages specs, and their related standard libraries specs.



Greetings
Raffaello


On 3/15/22 05:23, A Z wrote:

To core-libs-dev@openjdk.java.net,

In terms of floating point, it seems there are thus
three (3) phenomena that are relevant.

1) Arithmetic on float and double, via operators.
2) Elementary function calls, namely
    those made from java.lang.StrictMath, as it is,
    on double values.
3) Comparison operators.  ==, !=, >, <, >=,<=.

Java floating point successfully has 3) the way required,
even though other languages, particularly C++ , do not
compare their floats and doubles through those comparison
operators.  The point at issue is Java although, so Java is
satisfactory at point 3).

My point of contention is that Java does not have 1) and 2)
operating as they should, even though C++ and other
languages do, in those two areas, namely C++:

Martin has submitted the following:
?The following statement is not entirely true when using finite floating
point precision:


(?snip?) It is a mathematical fact that, for
consistent, necessary and even fast term, 10% of 10% must
always precisely be 1%, and by no means anything else."

/*
#include 

using namespace std;

int main()
{
 cout << "Program has started..." << endl;
 double a = 0.1D;
 double b = 0.1D;
 double c = a*b;
 cout << endl << c << endl << endl;
 float d = 0.1F;
 float e = 0.1F;
 float f = d*e;
 cout << f << endl << endl;
 cout << "Program has Finished.";
 return 0;
}
*/
/*
Program has started...

0.01

0.01

Program has Finished.
*/

This is actually not fully or finally true, including SSE, SSE 
algorithm logic and further.
The included C++ example of mine above here disproves this.  Even 
though I do

contextually admit these answers can only work within the range of the
involved types, it is 

Re: RFR: JDK-8283143: Use minimal-length literals to initialize PI and E constants

[Raffaello Giulietti]

The new decimal literals have indeed the minimal length required to 
recover the doubles closest to the true mathematical values.


Raffaello



On 3/15/22 02:43, Joe Darcy wrote:

Depending on the range of the number line, a double value has between 15 and 17 
digits of decimal precision. The literals used to initialize Math.PI and Math.E 
have several digits more precision than that maximum.

That is potentially confusing to readers of the code and the minimum length 
strings to exactly represent the value in question should be used instead.

-

Commit messages:
  - JDK-8283143: Use minimal-length literals to initialize PI and E constants

Changes: https://git.openjdk.java.net/jdk/pull/7814/files
  Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7814=00
   Issue: https://bugs.openjdk.java.net/browse/JDK-8283143
   Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
   Patch: https://git.openjdk.java.net/jdk/pull/7814.diff
   Fetch: git fetch https://git.openjdk.java.net/jdk pull/7814/head:pull/7814

PR: https://git.openjdk.java.net/jdk/pull/7814

Re: Discussion about Java Floating Point?

[Raffaello Giulietti]

Hi,

Java, as well as most implementations of most languages, including C and 
C++, have adopted the IEEE 754 floating-point standard, first issued in 
1985. The standard specifies the formats, the outcome of operators and 
comparisons up to the last bit.


Try out this C/C++ code (I'm on Linux with gcc)



#include 

using namespace std;

int main()
{
cout << "Program has started..." << endl;
double a = 0.1D;
double b = 0.1D;
double c = a*b;
double d = 0.01D;
cout << endl << "0.1D*0.1D " << (c == d ? "==" : "!=") << " 0.01D" 
<< endl << endl;

cout.precision(30);
cout << c << endl;
cout << "0.01D : ";
cout.precision(30);
cout << d << endl << endl;
cout << "Program has finished." << endl;
return 0;
}



This is the output I see:



Program has started...

0.1D*0.1D != 0.01D

0.1D*0.1D : 0.010001942890293094
0.01D : 0.012081668171172

Program has finished.



So 0.1D*0.1D != 0.01D, as stated on my previous post. That is, 
expectations on decimal behavior are usually wrong. It is inherently, 
mathematically *impossible* to emulate decimal behavior with binary IEEE 
754 arithmetic. That's why Java also offers java.math.BigDecimal, a 
decimal floating-point library implemented in software.


Also, as suggested in that post, incrementing the precision of the 
output by means of precision(30) as done above, for example, also 
clearly shows where the two values start being different, with 0.1D*0.1D 
being slightly greater than 0.01D.


Note that the precision only directs how many digits appear in the 
decimal output: it doesn't affect the underlying floating-point 
arithmetic at all. The latter follows the spec in full. In fact, all 
operators and comparisons are implemented directly in hardware, not in 
libraries. All CPUs designed in the last couple of decades implement 
IEEE 754.


This shows that the default precision for decimal output in C/C++ is not 
sufficient to expose the difference between the values. You have to set 
a higher precision to see differences.


This also shows the advantage of the default Java conversion routine, as 
opposed to the default precision in C/C++: different values are 
converted to different decimal outcome, without you having to set 
anything, because Java adapts the precision of the output automatically, 
depending on the value.


Finally, while Wikipedia is an exceptional source of information, the 
ultimate authoritative reference are the IEEE 754 spec, the C/C++ specs 
and other languages specs, and their related standard libraries specs.



Greetings
Raffaello


On 3/15/22 05:23, A Z wrote:

To core-libs-dev@openjdk.java.net,

In terms of floating point, it seems there are thus
three (3) phenomena that are relevant.

1) Arithmetic on float and double, via operators.
2) Elementary function calls, namely
those made from java.lang.StrictMath, as it is,
on double values.
3) Comparison operators.  ==, !=, >, <, >=,<=.

Java floating point successfully has 3) the way required,
even though other languages, particularly C++ , do not
compare their floats and doubles through those comparison
operators.  The point at issue is Java although, so Java is
satisfactory at point 3).

My point of contention is that Java does not have 1) and 2)
operating as they should, even though C++ and other
languages do, in those two areas, namely C++:

Martin has submitted the following:
?The following statement is not entirely true when using finite floating
point precision:


(?snip?) It is a mathematical fact that, for
consistent, necessary and even fast term, 10% of 10% must
always precisely be 1%, and by no means anything else."

/*
#include 

using namespace std;

int main()
{
 cout << "Program has started..." << endl;
 double a = 0.1D;
 double b = 0.1D;
 double c = a*b;
 cout << endl << c << endl << endl;
 float d = 0.1F;
 float e = 0.1F;
 float f = d*e;
 cout << f << endl << endl;
 cout << "Program has Finished.";
 return 0;
}
*/
/*
Program has started...

0.01

0.01

Program has Finished.
*/

This is actually not fully or finally true, including SSE, SSE algorithm logic 
and further.
The included C++ example of mine above here disproves this.  Even though I do
contextually admit these answers can only work within the range of the
involved types, it is still actually the case that 10% of 10% can and always
precisely be 1%, within the range of the type used, and by no means
anything else.  Because of the laws of decimal arithmetic.

See https://en.wikipedia.org/wiki/Floating-point_arithmetic
and the starting sentence:

'In computing, floating-point arithmetic (FP) is arithmetic using formulaic
representation of real numbers as an approximation to support a
trade-off betwee range and precision.'

However, it simply isn't the case that reduced precision has to exist inside
the range, certainly not any more.  Rationally, one would have to think,
with the 

Re: RFR: 8253495: CDS generates non-deterministic output [v7]

[Magnus Ihse Bursie]

On Tue, 15 Mar 2022 08:17:24 GMT, Ioi Lam  wrote:

>> This patch makes the result of "java -Xshare:dump" deterministic:
>> - Disabled new Java threads from launching. This is harmless. See comments 
>> in jvm.cpp
>> - Fixed a problem in hashtable ordering in heapShared.cpp
>> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random 
>> bits. Added code to zero it.
>> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in 
>> make/scripts/compare.sh
>> 
>> Note:  $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. 
>> This will be fixed in 
>> [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828).
>> 
>> Testing under way:
>> - tier1~tier5
>> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, 
>> windows-x86-cmp-baseline,  etc).
>
> Ioi Lam has updated the pull request with a new target base due to a merge or 
> a rebase. The incremental webrev excludes the unrelated changes brought in by 
> the merge/rebase. The pull request contains 12 additional commits since the 
> last revision:
> 
>  - fixed copyright
>  - Merge branch 'master' into 
> 8253495-cds-generateds-non-deterministic-output-2
>  - @calvinccheung review: fixed typo
>  - Added helper function CollectedHeap::zap_filler_array_with
>  - @kimbarrett comments
>  - zero GC heap filler arrays
>  - improvement zeroing of alignment gaps
>  - Fixed zero build
>  - Merge branch 'master' into 
> 8253495-cds-generateds-non-deterministic-output-2
>  - fixed test
>  - ... and 2 more: 
> https://git.openjdk.java.net/jdk/compare/1ab17a39...cd934f3c

Build changes look good.

-

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7748

Re: Behavior change in the jar tool JDK11 vs JDK8.

[Alan Bateman]

On 15/03/2022 08:18, Pasam Soujanya1 wrote:
I tried "tar" with a target that does not exist, and the tar file got 
created successfully (with an error message about the missing file) 
and with the exit code 0 (success). Same behavior is seen with JDK8 
jar too. From JDK11 onward, the output jar isn't created and the exit 
code is 1(failure).


So, to summarise: "jar" from Java 8 seems to be on the lines of "tar".

Do we want to continue with this "jar" behaviour which is not the same 
as "tar" ?


The behavior since JDK 9 is to delete the temporary file when there is 
an error. This looks to be the correct behavior. If it were changed back 
then people would complain that jar is leaving files behind when it fails.


I'm curious how you run into this. Is this a script that runs with +e or 
doesn't check the exit status?


-Alan

Re: RFR: 8253495: CDS generates non-deterministic output [v6]

[Ioi Lam]

On Mon, 14 Mar 2022 22:07:24 GMT, Calvin Cheung  wrote:

>> Ioi Lam has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Added helper function CollectedHeap::zap_filler_array_with
>
> test/hotspot/jtreg/runtime/cds/appcds/javaldr/LockDuringDumpAgent.java line 
> 65:
> 
>> 63: if (elapsed >= timeout) {
>> 64: System.out.println("This JVM may decide to not 
>> launch any Java threads during -Xshare:dump.");
>> 65: System.out.println("This is OK because no string 
>> objects be in a locked state during heap dump.");
> 
> Should `no string objects be` be `no string objects could be`?

Thanks for the review. I've fixed the comment as you suggested.

-

PR: https://git.openjdk.java.net/jdk/pull/7748

Re: RFR: 8253495: CDS generates non-deterministic output [v7]

[Ioi Lam]

> This patch makes the result of "java -Xshare:dump" deterministic:
> - Disabled new Java threads from launching. This is harmless. See comments in 
> jvm.cpp
> - Fixed a problem in hashtable ordering in heapShared.cpp
> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random 
> bits. Added code to zero it.
> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in 
> make/scripts/compare.sh
> 
> Note:  $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. 
> This will be fixed in 
> [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828).
> 
> Testing under way:
> - tier1~tier5
> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, 
> windows-x86-cmp-baseline,  etc).

Ioi Lam has updated the pull request with a new target base due to a merge or a 
rebase. The incremental webrev excludes the unrelated changes brought in by the 
merge/rebase. The pull request contains 12 additional commits since the last 
revision:

 - fixed copyright
 - Merge branch 'master' into 8253495-cds-generateds-non-deterministic-output-2
 - @calvinccheung review: fixed typo
 - Added helper function CollectedHeap::zap_filler_array_with
 - @kimbarrett comments
 - zero GC heap filler arrays
 - improvement zeroing of alignment gaps
 - Fixed zero build
 - Merge branch 'master' into 8253495-cds-generateds-non-deterministic-output-2
 - fixed test
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/a6344ded...cd934f3c

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7748/files
  - new: https://git.openjdk.java.net/jdk/pull/7748/files/47e0238a..cd934f3c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7748=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7748=05-06

  Stats: 6804 lines in 210 files changed: 3347 ins; 1802 del; 1655 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7748.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7748/head:pull/7748

PR: https://git.openjdk.java.net/jdk/pull/7748

Re: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2]

[Peter Levart]

On Mon, 14 Mar 2022 21:27:29 GMT, Joe Darcy  wrote:

>> Improving the exception messages for out-of-supported-range array types.
>> 
>> I'll update copyrights before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Respond to review feedback.

Changes requested by plevart (Reviewer).

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 179:

> 177: int netRank;
> 178: if (rank <= 0) {
> 179: throw new IllegalArgumentException("rank " + rank + "is not 
> a positive value");

There's a space missing in the IAE message after the rank number. For example, 
if rank == 0, the message would be: "rank 0is not positive value" ...

-

PR: https://git.openjdk.java.net/jdk/pull/7812

Re: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2]

[Alan Bateman]

On Mon, 14 Mar 2022 21:27:29 GMT, Joe Darcy  wrote:

>> Improving the exception messages for out-of-supported-range array types.
>> 
>> I'll update copyrights before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by alanb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7812