Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v3]

[Markus KARG]

On Fri, 2 Jul 2021 06:20:29 GMT, Markus KARG 
 wrote:

>> This PR-*draft* is **work in progress** and an invitation to discuss a 
>> possible solution for issue 
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not 
>> yet* intended for a final review.
>> 
>> As proposed in JDK-8265891, this PR provides an implementation for 
>> `Channels.newInputStream().transferTo()` which provide superior performance 
>> compared to the current implementation. The changes are:
>> * Prevents transfers through the JVM heap as much as possibly by offloading 
>> to deeper levels via NIO, hence allowing the operating system to optimize 
>> the transfer.
>> * Using more JRE heap in the fallback case when no NIO is possible (still 
>> only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern 
>> hardware / fast I/O devides.
>> 
>> Using JMH I have benchmarked both, the original implementation and this 
>> implementation, and (depending on the used hardware and use case) 
>> performance change was approx. doubled performance. So this PoC proofs that 
>> it makes sense to finalize this work and turn it into an actual OpenJDK 
>> contribution. 
>> 
>> I encourage everybody to discuss this draft:
>> * Are there valid arguments for *not* doing this change?
>> * Is there a *better* way to improve performance of 
>> `Channels.newInputStream().transferTo()`?
>> * How to go on from here: What is missing to get this ready for an actual 
>> review?
>
> Markus KARG has refreshed the contents of this pull request, and previous 
> commits have been removed. The incremental views will show differences 
> compared to the previous content of the PR. The pull request contains one new 
> commit since the last revision:
> 
>   Draft: Renaming i and separating code into several methods
>   
>   Signed-off-by: Markus Karg 

Understood. Work is in progress. Stay tuned.

-

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

Re: [EXTERNAL] Re: jpackage on MacOS - ./Contents/Contents/app/myapp.cfg file not found

[Bruno Borges]

Thanks Andy.

The issue regarding .cfg file not being found is indeed fixed in 17, and solves 
this particular problem I found.

From: core-libs-dev  on behalf of Andy 
Herrick 
Date: Wednesday, July 21, 2021 at 1:57 PM
To: core-libs-dev@openjdk.java.net 
Subject: [EXTERNAL] Re: jpackage on MacOS - ./Contents/Contents/app/myapp.cfg 
file not found
Looks like an instance of: JDK-8260335

 : [macos] Running app
using relative path causes problems (fixed in jdk17 build b09)

you can try builds from 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjdk.java.net%2F17%2Fdata=04%7C01%7Cbruno.borges%40microsoft.com%7C9b29c0dfcd6d45f58cc908d94c8a3229%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637624978703359720%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=pGwCWe9IBiVKhZCVMpFo1OZJLSyFVfQJODpKQ%2B6fby8%3Dreserved=0
 to confirm fix.

/Andy

On 7/21/2021 4:46 PM, Bruno Borges wrote:
> Hi all,
>
> Been trying to use Java 16.0.1 to produce a PKG for the fx2048 [1] game, and 
> the generated app-image comes with a binary launcher that tries to load the 
> .cfg file from the wrong directory.
>
> Anyone seen this problem?
>
> fx2048.app/Contents/MacOS  master -> origin/master ✔  
>   
>   1h59m  java:16.0.1
> $ tree ../../../ -L 4
> ../../../
> └── fx2048.app
>  └── Contents
>  ├── Info.plist
>  ├── MacOS
>  │   └── fx2048
>  ├── PkgInfo
>  ├── Resources
>  │   └── fx2048.icns
>  ├── app
>  │   └── fx2048.cfg
>  └── runtime
>  └── Contents
>
> 7 directories, 5 files
>
> $ ./fx2048
> Error opening 
> "/Users/bruno/myprojects/fx2048/build/installers/fx2048.app/Contents/Contents/app/fx2048.cfg"
>  file: No such file or directory
>
> [1] 
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgithub.com%2Fbrunoborges%2Ffx2048data=04%7C01%7Cbruno.borges%40microsoft.com%7C9b29c0dfcd6d45f58cc908d94c8a3229%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637624978703359720%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=t8txGpyO7cA9TuIY%2FcsPt4zXN2WmRrsTwJD7rQaC4%2F4%3Dreserved=0

JNI WeakGlobalRefs

[Hans Boehm]

Is this an appropriate list to discuss JNI?

I'm concerned that the current semantics of JNI WeakGlobalRefs are still
dangerous in a very subtle way that is hidden in the spec. The current
(14+) spec says:

“Weak global references are related to Java phantom references
(java.lang.ref.PhantomReference). A weak global reference to a specific
object is treated as a phantom reference referring to that object when
determining whether the object is phantom reachable (see java.lang.ref).
---> Such a weak global reference will become functionally equivalent to
NULL at the same time as a PhantomReference referring to that same object
would be cleared by the garbage collector. <---”

(This was the result of JDK-8220617, and is IMO a large improvement over
the prior version, but ...)

Consider what happens if I have a WeakGlobalRef W that refers to a Java
object A which, possibly indirectly, relies on an object F, where F is
finalizable, i.e.

W - - -> A -> ... -> F

Assume that F becomes invalid once it is finalized, e.g. because the
finalizer deallocates a native object that F relies on. This seems to be a
very common case. We are then exposed to the following scenario:

0) At some point, there are no longer any other references to A or F.
1) F is enqueued for finalization.
2) W is dereferenced by Thread 1, yielding a strong reference to A and
transitively to F.
3) F is finalized.
4) Thread 1 uses A and F, accessing F, which is no longer valid.
5) Crash, or possibly memory corruption followed by a later crash elsewhere.

(3) and (4) actually race, so there is some synchronization effort and cost
required to prevent F from corrupting memory. Commonly the implementer of W
will have no idea that F even exists.

I believe that typically there is no way to prevent this scenario, unless
the developer adding W actually knows how every class that A could possibly
rely on, including those in the Java standard library, are implemented.

This is reminiscent of finalizer ordering issues. But it seems to be worse,
in that there isn't even a semi-plausible workaround.

I believe all of this is exactly the reason PhantomReference.get() always
returns null, while WeakReference provides significantly different
semantics, and WeakReferences are enqueued when an object is enqueued for
finalization.

The situation improves, but the problem doesn't fully disappear, in a
hypothetical world without finalizers. It's still possible to use
WeakGlobalRef to get a strong reference to A after a WeakReference to A has
been cleared and enqueued. I think the problem does go away if all cleanup
code were to use PhantomReference-based Cleaners.

AFAICT, backward-compatibility aside, the obvious solution here is to have
WeakGlobalRefs behave like WeakReferences. My impression is that this would
fix significantly more broken clients than it would break correct ones, so
it is arguably still a viable option.

There is a case in which the current semantics are actually the desired
ones, namely when implementing, say, a String intern table. In this case
it's important the reference not be cleared even if the referent is, at
some point, only reachable via a finalizer. But this use case again relies
on the programmer knowing that no part of the referent is invalidated by a
finalizer. That's a reasonable assumption for the
Java-implementation-provided String intern table. But I'm not sure it's
reasonable for any user-written code.

There seem to be two ways forward here:

1) Make WeakGlobalRefs behave like WeakReferences instead of
PhantomReferences, or
2) Add strong warnings to the spec that basically suggest using a strong
GlobalRef to a WeakReference instead.

Has there been prior discussion of this? Are there reasonable use cases for
the current semantics? Is there something else that I'm overlooking? If
not, what's the best way forward here?

(I found some discussion from JDK-8220617, including a message I posted.
Unfortunately, it seems to me that all of us overlooked this issue?)

Hans

Re: RFR: 8199594: Add doc describing how (?x) ignores spaces in character classes [v3]

[Ian Graves]

> 8199594: Add doc describing how (?x) ignores spaces in character classes

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

  Rewording repetitive phrase

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4618/files
  - new: https://git.openjdk.java.net/jdk/pull/4618/files/11bafe80..521cddca

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

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

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

Re: RFR: 8199594: Add doc describing how (?x) ignores spaces in character classes [v2]

[Ian Graves]

On Wed, 21 Jul 2021 21:30:01 GMT, Lance Andersen  wrote:

>> Ian Graves has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   delete errant line
>
> src/java.base/share/classes/java/util/regex/Pattern.java line 758:
> 
>> 756:  *group just as in Perl.  
>> 757:  *
>> 758:  * In Perl, free-spacing mode (which is called 
>> comments
> 
> Looks good overall, one suggestion is to perhaps re-phrase the opening of the 
> paragraph as the preceding  paragraph also starts with "In-Perl".

Good idea. Re-worded to "Free-spacing mode in Perl (called comments..."

-

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

Integrated: Merge jdk17

[Jesper Wilhelmsson]

On Wed, 21 Jul 2021 23:52:53 GMT, Jesper Wilhelmsson  
wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: c36755de
Author:Jesper Wilhelmsson 
URL:   
https://git.openjdk.java.net/jdk/commit/c36755dedf1a0d7ce0aeadd401e0c70ff84185e7
Stats: 517 lines in 33 files changed: 403 ins; 34 del; 80 mod

Merge

-

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

Re: RFR: Merge jdk17 [v2]

[Jesper Wilhelmsson]

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains 282 commits:

 - Merge
 - 8271015: Split cds/SharedBaseAddress.java test into smaller parts
   
   Reviewed-by: ccheung, minqi
 - 8271014: Refactor HeapShared::is_archived_object()
   
   Reviewed-by: ccheung, minqi
 - 8270949: Make dynamically generated classes with the class file version of 
the current release
   
   Reviewed-by: alanb
 - 8269849: 
vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java failed 
with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced 
objects"
   
   Reviewed-by: kbarrett
 - 8270991: G1 Full GC always performs heap verification after JDK-8269295
   
   Reviewed-by: iwalulya, kbarrett
 - 8270820: remove unused stiFileTableIndex from SDE.c
   
   Reviewed-by: cjplummer, sspitsyn
 - 8270147: Increase stride size allowing unrolling more loops
   
   Reviewed-by: kvn, iveresov
 - 8270803: Reduce CDS API verbosity
   
   Reviewed-by: minqi, ccheung
 - 8269933: test/jdk/javax/net/ssl/compatibility/JdkInfo incorrect verification 
of protocol and cipher support
   
   Reviewed-by: xuelei, rhalade
 - ... and 272 more: 
https://git.openjdk.java.net/jdk/compare/89f7998a...025eaefb

-

Changes: https://git.openjdk.java.net/jdk/pull/4863/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4863=01
  Stats: 55988 lines in 1158 files changed: 26162 ins; 25130 del; 4696 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4863/head:pull/4863

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

jpackage on MacOS - ./Contents/Contents/app/myapp.cfg file not found

[Bruno Borges]

Hi all,

Been trying to use Java 16.0.1 to produce a PKG for the fx2048 [1] game, and 
the generated app-image comes with a binary launcher that tries to load the 
.cfg file from the wrong directory.

Anyone seen this problem?

fx2048.app/Contents/MacOS  master -> origin/master ✔

  1h59m  java:16.0.1
$ tree ../../../ -L 4
../../../
└── fx2048.app
└── Contents
├── Info.plist
├── MacOS
│   └── fx2048
├── PkgInfo
├── Resources
│   └── fx2048.icns
├── app
│   └── fx2048.cfg
└── runtime
└── Contents

7 directories, 5 files

$ ./fx2048
Error opening 
"/Users/bruno/myprojects/fx2048/build/installers/fx2048.app/Contents/Contents/app/fx2048.cfg"
 file: No such file or directory

[1] http://github.com/brunoborges/fx2048

RFR: Merge jdk17

[Jesper Wilhelmsson]

Forwardport JDK 17 -> JDK 18

-

Commit messages:
 - Merge
 - 8266347: assert(Dependencies::is_concrete_root_method(fm, ctxk) == 
Dependencies::is_concrete_method(m, ctxk)) failed: mismatch
 - 8264066: Enhance compiler validation
 - 8265201: JarFile.getInputStream not validating invalid signed jars
 - 8258432: Improve File Transfers
 - 8264079: Improve abstractions
 - 8262380: Enhance XML processing passes
 - 8262967: Improve Zip file support
 - 8264460: Improve NTLM support
 - 8256491: Better HTTP transport
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/0790f04d...025eaefb

The webrevs contain the adjustments done while merging with regards to each 
parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk=4863=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk=4863=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4863/files
  Stats: 517 lines in 33 files changed: 403 ins; 34 del; 80 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4863/head:pull/4863

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

Re: JNI WeakGlobalRefs

[David Holmes]

Hi Hans,

On 22/07/2021 7:54 am, Hans Boehm wrote:

Is this an appropriate list to discuss JNI?


No - hotspot-dev (to get runtime and GC folk) is the place to discuss JNI.

Thanks,
David


I'm concerned that the current semantics of JNI WeakGlobalRefs are still
dangerous in a very subtle way that is hidden in the spec. The current
(14+) spec says:

“Weak global references are related to Java phantom references
(java.lang.ref.PhantomReference). A weak global reference to a specific
object is treated as a phantom reference referring to that object when
determining whether the object is phantom reachable (see java.lang.ref).
---> Such a weak global reference will become functionally equivalent to
NULL at the same time as a PhantomReference referring to that same object
would be cleared by the garbage collector. <---”

(This was the result of JDK-8220617, and is IMO a large improvement over
the prior version, but ...)

Consider what happens if I have a WeakGlobalRef W that refers to a Java
object A which, possibly indirectly, relies on an object F, where F is
finalizable, i.e.

W - - -> A -> ... -> F

Assume that F becomes invalid once it is finalized, e.g. because the
finalizer deallocates a native object that F relies on. This seems to be a
very common case. We are then exposed to the following scenario:

0) At some point, there are no longer any other references to A or F.
1) F is enqueued for finalization.
2) W is dereferenced by Thread 1, yielding a strong reference to A and
transitively to F.
3) F is finalized.
4) Thread 1 uses A and F, accessing F, which is no longer valid.
5) Crash, or possibly memory corruption followed by a later crash elsewhere.

(3) and (4) actually race, so there is some synchronization effort and cost
required to prevent F from corrupting memory. Commonly the implementer of W
will have no idea that F even exists.

I believe that typically there is no way to prevent this scenario, unless
the developer adding W actually knows how every class that A could possibly
rely on, including those in the Java standard library, are implemented.

This is reminiscent of finalizer ordering issues. But it seems to be worse,
in that there isn't even a semi-plausible workaround.

I believe all of this is exactly the reason PhantomReference.get() always
returns null, while WeakReference provides significantly different
semantics, and WeakReferences are enqueued when an object is enqueued for
finalization.

The situation improves, but the problem doesn't fully disappear, in a
hypothetical world without finalizers. It's still possible to use
WeakGlobalRef to get a strong reference to A after a WeakReference to A has
been cleared and enqueued. I think the problem does go away if all cleanup
code were to use PhantomReference-based Cleaners.

AFAICT, backward-compatibility aside, the obvious solution here is to have
WeakGlobalRefs behave like WeakReferences. My impression is that this would
fix significantly more broken clients than it would break correct ones, so
it is arguably still a viable option.

There is a case in which the current semantics are actually the desired
ones, namely when implementing, say, a String intern table. In this case
it's important the reference not be cleared even if the referent is, at
some point, only reachable via a finalizer. But this use case again relies
on the programmer knowing that no part of the referent is invalidated by a
finalizer. That's a reasonable assumption for the
Java-implementation-provided String intern table. But I'm not sure it's
reasonable for any user-written code.

There seem to be two ways forward here:

1) Make WeakGlobalRefs behave like WeakReferences instead of
PhantomReferences, or
2) Add strong warnings to the spec that basically suggest using a strong
GlobalRef to a WeakReference instead.

Has there been prior discussion of this? Are there reasonable use cases for
the current semantics? Is there something else that I'm overlooking? If
not, what's the best way forward here?

(I found some discussion from JDK-8220617, including a message I posted.
Unfortunately, it seems to me that all of us overlooked this issue?)

Hans

Re: jpackage on MacOS - ./Contents/Contents/app/myapp.cfg file not found

[Michael Hall]

> On Jul 21, 2021, at 3:57 PM, Andy Herrick  wrote:
> 
> Looks like an instance of: JDK-8260335 
>  : [macos] Running app 
> using relative path causes problems (fixed in jdk17 build b09)
> 
> you can try builds from https://jdk.java.net/17/ to confirm fix.
> 
> /Andy
> 
> On 7/21/2021 4:46 PM, Bruno Borges wrote:
>> Hi all,
>> 
>> Been trying to use Java 16.0.1 to produce a PKG for the fx2048 [1] game, and 
>> the generated app-image comes with a binary launcher that tries to load the 
>> .cfg file from the wrong directory.
>> 
>> 
>> ├── PkgInfo

Somewhat off-topic. I hadn't noticed that PkgInfo was included on my 
applications? It used to have creator/type OSType’s needed for AppleEvent’s to 
work properly but since creator/type are pretty much out of use I thought 
PkgInfo was too?

Re: RFR: 8199594: Add doc describing how (?x) ignores spaces in character classes [v2]

[Ian Graves]

On Wed, 21 Jul 2021 20:22:04 GMT, Pavel Rappo  wrote:

>> Ian Graves has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   delete errant line
>
> src/java.base/share/classes/java/util/regex/Pattern.java line 833:
> 
>> 831:  *  Comments mode can also be enabled via the embedded flag
>> 832:  * expression{@code (?x)}.
>> 833:  *
> 
> Nit: is this extra line necessary?

Nope! Deleted.

-

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

Re: RFR: 8199594: Add doc describing how (?x) ignores spaces in character classes [v2]

[Lance Andersen]

On Wed, 21 Jul 2021 21:25:18 GMT, Ian Graves  wrote:

>> 8199594: Add doc describing how (?x) ignores spaces in character classes
>
> Ian Graves has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   delete errant line

src/java.base/share/classes/java/util/regex/Pattern.java line 758:

> 756:  *group just as in Perl.  
> 757:  *
> 758:  * In Perl, free-spacing mode (which is called 
> comments

Looks good overall, one suggestion is to perhaps re-phrase the opening of the 
paragraph as the preceding  paragraph also starts with "In-Perl".

-

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

Re: RFR: 8199594: Add doc describing how (?x) ignores spaces in character classes [v2]

[Ian Graves]

> 8199594: Add doc describing how (?x) ignores spaces in character classes

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

  delete errant line

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4618/files
  - new: https://git.openjdk.java.net/jdk/pull/4618/files/07ea6f0f..11bafe80

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

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

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

Re: jpackage on MacOS - ./Contents/Contents/app/myapp.cfg file not found

[Andy Herrick]

Looks like an instance of: JDK-8260335 
 : [macos] Running app 
using relative path causes problems (fixed in jdk17 build b09)


you can try builds from https://jdk.java.net/17/ to confirm fix.

/Andy

On 7/21/2021 4:46 PM, Bruno Borges wrote:

Hi all,

Been trying to use Java 16.0.1 to produce a PKG for the fx2048 [1] game, and 
the generated app-image comes with a binary launcher that tries to load the 
.cfg file from the wrong directory.

Anyone seen this problem?

fx2048.app/Contents/MacOS  master -> origin/master ✔
   
   1h59m  java:16.0.1
$ tree ../../../ -L 4
../../../
└── fx2048.app
 └── Contents
 ├── Info.plist
 ├── MacOS
 │   └── fx2048
 ├── PkgInfo
 ├── Resources
 │   └── fx2048.icns
 ├── app
 │   └── fx2048.cfg
 └── runtime
 └── Contents

7 directories, 5 files

$ ./fx2048
Error opening 
"/Users/bruno/myprojects/fx2048/build/installers/fx2048.app/Contents/Contents/app/fx2048.cfg"
 file: No such file or directory

[1] http://github.com/brunoborges/fx2048

Re: RFR: 8199594: Add doc describing how (?x) ignores spaces in character classes

[Iris Clark]

On Mon, 28 Jun 2021 20:50:42 GMT, Ian Graves  wrote:

> 8199594: Add doc describing how (?x) ignores spaces in character classes

Changes match corresponding, approved CSR.

-

Marked as reviewed by iris (Reviewer).

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

Re: RFR: 8199594: Add doc describing how (?x) ignores spaces in character classes

[Naoto Sato]

On Mon, 28 Jun 2021 20:50:42 GMT, Ian Graves  wrote:

> 8199594: Add doc describing how (?x) ignores spaces in character classes

Marked as reviewed by naoto (Reviewer).

-

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

Re: RFR: 8199594: Add doc describing how (?x) ignores spaces in character classes

[Joe Darcy]

On Mon, 28 Jun 2021 20:50:42 GMT, Ian Graves  wrote:

> 8199594: Add doc describing how (?x) ignores spaces in character classes

Marked as reviewed by darcy (Reviewer).

-

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

Re: RFR: 8199594: Add doc describing how (?x) ignores spaces in character classes

[Pavel Rappo]

On Mon, 28 Jun 2021 20:50:42 GMT, Ian Graves  wrote:

> 8199594: Add doc describing how (?x) ignores spaces in character classes

src/java.base/share/classes/java/util/regex/Pattern.java line 833:

> 831:  *  Comments mode can also be enabled via the embedded flag
> 832:  * expression{@code (?x)}.
> 833:  *

Nit: is this extra line necessary?

-

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

Re: RFR: 8214761: Bug in parallel Kahan summation implementation [v2]

[Ian Graves]

> 8214761: Bug in parallel Kahan summation implementation

Ian Graves has updated the pull request incrementally with three additional 
commits since the last revision:

 - Updates with more test coverage
 - stashing
 - Stashing

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4674/files
  - new: https://git.openjdk.java.net/jdk/pull/4674/files/d7fc3948..10b8dcda

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

  Stats: 216 lines in 4 files changed: 213 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4674.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4674/head:pull/4674

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