Re: RFR: 8286163: micro-optimize Instant.plusSeconds

[lennartfricke]

On Wed, 4 May 2022 20:27:04 GMT, lennartfricke  wrote:

> Provide micro-benchmark for comparison

The speedup is roughly 1.6.

-

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

Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v4]

[Shruthi]

> Removing the Duplicate keys present in XSLTErrorResources.java and 
> XPATHErrorResources.java
> 
> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097

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

  Add last modified tag

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8318/files
  - new: https://git.openjdk.java.net/jdk/pull/8318/files/c294a150..ef9d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8318&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8318&range=02-03

  Stats: 11 lines in 11 files changed: 8 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8318.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8318/head:pull/8318

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

Re: RFR: 8238373: Punctuation should be same in jlink help usage on Japanese language [v2]

[KIRIYAMA Takuya]

On Wed, 27 Apr 2022 16:42:23 GMT, Naoto Sato  wrote:

> Looks fine to me. Nit: please modify the copyright years for `javap` 
> properties files, as you modified the base (`javap.properties`) file.

I’m sorry for the late reply.  
Thank you for your advice. I modified the copyright years for all files.

-

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

Re: RFR: 8238373: Punctuation should be same in jlink help usage on Japanese language [v2]

[KIRIYAMA Takuya]

> When showing help for the jlink command in a Japanese locale, delimiters of 
> option's aliases are a mixture of "," and \u3001. Delimiter should be unified 
> to ",".
> As the same, there is a inconsistency of delimiters in the jar command help 
> in a Japanese locale, and "," should be used.
> Similarly, the javap command help uses space as delimiters other than the 
> module option in all locales. This inconsistency should also be corrected.
> 
> Would you please review this fix?

KIRIYAMA Takuya has updated the pull request incrementally with one additional 
commit since the last revision:

  8238373: Punctuation should be same in jlink help usage on Japanese language

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8417/files
  - new: https://git.openjdk.java.net/jdk/pull/8417/files/5163b9df..c881ec75

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8417&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8417&range=00-01

  Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8417.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8417/head:pull/8417

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

Re: RFR: 8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out

[Alan Bateman]

On Sun, 8 May 2022 21:57:20 GMT, Leonid Mesnik  wrote:

> …resulting in failure to produce a stack when a test times out

Marked as reviewed by alanb (Reviewer).

-

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

Re: RFR: JDK-8286347: incorrect use of `{@link}`

[Jonathan Gibbons]

On Sat, 7 May 2022 01:27:57 GMT, Joe Darcy  wrote:

> Looks fine in and of itself, but not sure how it will interact with the 
> (presumed) integration of JEP 424: "Foreign Function & Memory API (Preview)" 
> which will at least move the file, if not otherwise modify it.

I assume the changes are small and localized enough to not trigger any 
significant conflict.

-

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

Re: RFR: 8286163: micro-optimize Instant.plusSeconds

[Claes Redestad]

On Fri, 6 May 2022 22:02:58 GMT, Stephen Colebourne  
wrote:

> Seems reasonable to me. plus(long, long) already has this optimisation.

If it already had this optimization then why change anything? I think you're 
referring to the check for `0` to return `this` then that is something 
`plusSeconds` will need to retain for parity. The optimization here appears to 
be the avoiding of added arithmetic for dealing with nanoseconds. And though it 
bothers me that the JIT doesn't optimize this better (given that the nanosecond 
parameter to `plus(long, long)` is a constant zero) the patch does seem 
reasonable.

-

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

Re: RFR: 8286163: micro-optimize Instant.plusSeconds

[Claes Redestad]

On Wed, 4 May 2022 20:27:04 GMT, lennartfricke  wrote:

> Provide micro-benchmark for comparison

Marked as reviewed by redestad (Reviewer).

-

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

Re: RFR: 8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out

[David Holmes]

On Sun, 8 May 2022 21:57:20 GMT, Leonid Mesnik  wrote:

> …resulting in failure to produce a stack when a test times out

Looks good.

Thanks,
David

-

Marked as reviewed by dholmes (Reviewer).

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

RFR: 8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out

[Leonid Mesnik]

…resulting in failure to produce a stack when a test times out

-

Commit messages:
 - 8284550: test failure_handler is not properly invoking jhsdb jstack, 
resulting in failure to produce a stack when a test times out

Changes: https://git.openjdk.java.net/jdk/pull/8588/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8588&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284550
  Stats: 7 lines in 1 file changed: 1 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8588.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8588/head:pull/8588

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

Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character [v6]

[Ichiroh Takiguchi]

On Sat, 7 May 2022 06:50:40 GMT, Ichiroh Takiguchi  
wrote:

>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has 
>> Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Arguments for ProcessBuilder have same kind of issue.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8285517: System.getenv() returns unexpected value if environment variable 
> has non ASCII character

I checked internal data

$ cat StaticPropertyVals.java 
import java.lang.reflect.*;

public class StaticPropertyVals {
  public static void main(String[] args) throws Exception {
Class cls = Class.forName("jdk.internal.util.StaticProperty");
for (Field fid : cls.getDeclaredFields()) {
  if (Modifier.isStatic(fid.getModifiers())) {
fid.setAccessible(true);
System.out.println(fid.getName() + "=" + fid.get(null));
  }
}
  }
}
$ env LANG=kk_KZ.pt154 LC_ALL=kk_KZ.pt154 java -XshowSettings:properties 
--add-opens=java.base/jdk.internal.util=ALL-UNNAMED StaticPropertyVals 2>&1 | 
egrep -i 'encoding|charset'
WARNING: The encoding of the underlying platform's file system is not 
supported: PT154
file.encoding = UTF-8
native.encoding = PT154
sun.io.unicode.encoding = UnicodeLittle
sun.jnu.encoding = UTF-8
NATIVE_ENCODING=PT154
FILE_ENCODING=UTF-8
SUN_JNU_ENCODING=UTF-8
jnuCharset=UTF-8
$

-

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

Re: RFR: 8286298: Remove unused methods in sun.invoke.util.VerifyType

[Alan Bateman]

On Fri, 6 May 2022 11:32:25 GMT, Claes Redestad  wrote:

> A few untested and unused methods in `VerifyType` which can be removed. 
> (Possibly used by native JSR 292 implementations in JDK 7).

Marked as reviewed by alanb (Reviewer).

-

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

Re: Why does we still need StrictMath?

[Martin Desruisseaux]

Le 08/05/2022 à 14:15, Victor Williams Stafusa da Silva a écrit :


Was that using Java 17+, which included JEP 306 delivered?

No, but my understanding is that JEP 306 does not apply to Math versus 
StrictMath behavior. In my understanding, the strictfp keyword was only 
about the use of extended exponent value set in Pentium 80 bits floating 
point values. It impacts the behavior of arithmetic operations + - * /, 
but my (maybe wrong) understanding is that it does not impact which 
processor instruction is used for implementing Math.sin, cos, etc.


    Martin

Re: Why does we still need StrictMath?

[Victor Williams Stafusa da Silva]

Was that using Java 17+, which included JEP 306 delivered?

Em dom., 8 de mai. de 2022 às 08:10, Martin Desruisseaux <
martin.desruisse...@geomatys.com> escreveu:

> Le 08/05/2022 à 10:56, Andrew Haley a écrit :
>
> > Some targets (x86, in particular) have intrinsics (log, trig) that are
> > faster than StrictMath and also more accurate. StrictMath is not about
> > accuracy, but cross-architecture down-to-the-last bit reproducibility.
> > Whether we still need that reproducibility is, I suppose, something
> > for debate.
> >
> In production code, maybe not. But in test code (e.g. using JUnit), when
> the program does a lot of trigonometric operations (e.g. map
> projections), I have meet cases where a test was successful on a machine
> but failed on another machine. The systematic use of StrictMath in all
> JUnit test code ensure that the difference in behavior is not in the
> test code, so we can focus our debugging effort on the main code.
>
>  Martin
>
>
>

Re: Why does we still need StrictMath?

[Victor Williams Stafusa da Silva]

Sure, there are the x86 intrinsics. But since JEP 306 was delivered, is
this still valid? The Motivation section of the JEP 306 seems to imply that
this is not the case anymore. Of course, I could just be grossly
misunderstanding what is/was JEP 306 and/or to which depth it meant by
"restore always-strict floating-point semantics", but I don't think that I
am the only one out there.

Em dom., 8 de mai. de 2022 às 05:56, Andrew Haley <
aph-o...@littlepinkcloud.com> escreveu:

> On 5/8/22 06:54, Victor Williams Stafusa da Silva wrote:
> > If StrictMath is still needed and could produce different results than
> > Math in some modern hardware, then by the javadocs, it seems to imply
> that
> > Math should always delegate to StrictMath and never the other way around.
> > Why is it not always the case? I think that the answer is simply because
> > the StrictMath class was largely left unchanged and that delegating in
> one
> > way or in the other could then produce a difference when the strictfp
> > modifier was there, but is there a better reason than that?
>
> Some targets (x86, in particular) have intrinsics (log, trig) that
> are faster than StrictMath and also more accurate. StrictMath is not
> about accuracy, but cross-architecture down-to-the-last bit
> reproducibility.
> Whether we still need that reproducibility is, I suppose, something for
> debate.
>
> --
> 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: 8286294 : ForkJoinPool.commonPool().close() spins [v5]

[Doug Lea]

> Changes ForkJoinPool.close spec and code to trap close as a no-op if called 
> on common pool

Doug Lea has updated the pull request incrementally with one additional commit 
since the last revision:

  Test improvements

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8577/files
  - new: https://git.openjdk.java.net/jdk/pull/8577/files/9a0d27f4..4d421ec3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8577&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8577&range=03-04

  Stats: 30 lines in 2 files changed: 11 ins; 4 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8577/head:pull/8577

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

Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v4]

[Doug Lea]

On Sun, 8 May 2022 01:51:17 GMT, Martin Buchholz  wrote:

>> Doug Lea has updated the pull request incrementally with three additional 
>> commits since the last revision:
>> 
>>  - Accommodate restrictive SecurityManagers
>>  - merge with loom updates
>>Merge remote-tracking branch 'refs/remotes/origin/JDK-8286294' into 
>> JDK-8286294
>>  - Fix testLazySubmit; enable suite
>
> Here's a suggested strengthening of testCloseCommonPool:
> 
> - close should have "no effect", not just "not terminate".
> - the submitted task will be run by the pool ... eventually  (which suggests 
> that closing the common pool maybe should quiesce the pool before returning)
> -  I might merge this with testCommonPoolShutDown
> 
> /**
>  * Implicitly closing common pool using try-with-resources has no effect.
>  */
> public void testCloseCommonPool() {
> ForkJoinTask f = new FibAction(8);
> ForkJoinPool pool;
> try (ForkJoinPool p = pool = ForkJoinPool.commonPool()) {
> p.execute(f);
> }
> 
> assertFalse(pool.isShutdown());
> assertFalse(pool.isTerminating());
> assertFalse(pool.isTerminated());
> 
> String prop = System.getProperty(
> "java.util.concurrent.ForkJoinPool.common.parallelism");
> if (! "0".equals(prop)) {
> f.join();
> checkCompletedNormally(f);
> }
> }

@Martin-Buchholz thanks for test improvements. I'm leaving further FJP tweaks 
for some other time to avoid possibility of problems after already merging with 
loom commit

-

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

Re: Why does we still need StrictMath?

[Martin Desruisseaux]

Le 08/05/2022 à 10:56, Andrew Haley a écrit :

Some targets (x86, in particular) have intrinsics (log, trig) that are 
faster than StrictMath and also more accurate. StrictMath is not about 
accuracy, but cross-architecture down-to-the-last bit reproducibility. 
Whether we still need that reproducibility is, I suppose, something 
for debate.


In production code, maybe not. But in test code (e.g. using JUnit), when 
the program does a lot of trigonometric operations (e.g. map 
projections), I have meet cases where a test was successful on a machine 
but failed on another machine. The systematic use of StrictMath in all 
JUnit test code ensure that the difference in behavior is not in the 
test code, so we can focus our debugging effort on the main code.


    Martin

Re: Why does we still need StrictMath?

[Andrew Haley]

On 5/8/22 06:54, Victor Williams Stafusa da Silva wrote:

If StrictMath is still needed and could produce different results than
Math in some modern hardware, then by the javadocs, it seems to imply that
Math should always delegate to StrictMath and never the other way around.
Why is it not always the case? I think that the answer is simply because
the StrictMath class was largely left unchanged and that delegating in one
way or in the other could then produce a difference when the strictfp
modifier was there, but is there a better reason than that?


Some targets (x86, in particular) have intrinsics (log, trig) that
are faster than StrictMath and also more accurate. StrictMath is not
about accuracy, but cross-architecture down-to-the-last bit reproducibility.
Whether we still need that reproducibility is, I suppose, something for
debate.

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