date:20210722

On Fri, 23 Jul 2021 03:37:44 GMT, Jaikiran Pai  wrote:

> Can I please get a review for this change which fixes the typo noted in 
> https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked 
> fine and the generated javadoc looks fine.

Thank you for the review, Iris.

-

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

Integrated: 8271147: java/nio/file/Path.java javadoc typo

On Fri, 23 Jul 2021 03:37:44 GMT, Jaikiran Pai  wrote:

> Can I please get a review for this change which fixes the typo noted in 
> https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked 
> fine and the generated javadoc looks fine.

This pull request has now been integrated.

Changeset: 8156ff60
Author:Jaikiran Pai 
URL:   
https://git.openjdk.java.net/jdk/commit/8156ff609b27316f31ba89d9eb8ca752f4027c2b
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod

8271147: java/nio/file/Path.java javadoc typo

Reviewed-by: iris

-

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

Re: RFR: 8271147: java/nio/file/Path.java javadoc typo

2021-07-22 Thread Iris Clark

On Fri, 23 Jul 2021 03:37:44 GMT, Jaikiran Pai  wrote:

> Can I please get a review for this change which fixes the typo noted in 
> https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked 
> fine and the generated javadoc looks fine.

Marked as reviewed by iris (Reviewer).

-

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

RFR: 8271147: java/nio/file/Path.java javadoc typo

Can I please get a review for this change which fixes the typo noted in 
https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked fine 
and the generated javadoc looks fine.

-

Commit messages:
 - 8271147: java/nio/file/Path.java javadoc typo

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

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

Integrated: Merge jdk17

2021-07-22 Thread Jesper Wilhelmsson

On Fri, 23 Jul 2021 00:28:53 GMT, Jesper Wilhelmsson  
wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 9935440e
Author:Jesper Wilhelmsson 
URL:   
https://git.openjdk.java.net/jdk/commit/9935440eded25b041ea3e73cfa8ac0d95bbd66c6
Stats: 268 lines in 20 files changed: 178 ins; 43 del; 47 mod

Merge

-

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

RFR: Merge jdk17

2021-07-22 Thread Jesper Wilhelmsson

Forwardport JDK 17 -> JDK 18

-

Commit messages:
 - Merge
 - 8271162: runtime/StackTrace/LargeClassTest.java can be run in driver mode
 - 8271158: runtime/handshake/HandshakeTimeoutTest.java test doesn't check exit 
code
 - 8271169: runtime/Safepoint/TestAbortVMOnSafepointTimeout.java can be run in 
driver mode
 - 8271160: runtime/jni/checked/TestCheckedJniExceptionCheck.java doesn't set 
-Djava.library.path
 - 8271155: Wrong path separator in env variable
 - 8270916: Update java.lang.annotation.Target for changes in JLS 9.6.4.1
 - 8271094: runtime/duplAttributes/DuplAttributesTest.java doesn't check exit 
code
 - 8271093: remove deadcode from runtime/Thread/TestThreadDumpSMRInfo.java test
 - 8270085: Suspend during block transition may deadlock if lock held
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/a7d30123...b6b24fa0

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

Changes: https://git.openjdk.java.net/jdk/pull/4883/files
  Stats: 268 lines in 20 files changed: 178 ins; 43 del; 47 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4883.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4883/head:pull/4883

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

Re: [jdk17] RFR: 8271155: Wrong path separator in env variable

On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk  wrote:

> Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' 
> dir to env variable in jpackage app launcher.

There is no unit test covering this area. I'll file follow up CR to add one in 
JDK18.

-

PR: https://git.openjdk.java.net/jdk17/pull/271

[jdk17] Integrated: 8271155: Wrong path separator in env variable

On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk  wrote:

> Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' 
> dir to env variable in jpackage app launcher.

This pull request has now been integrated.

Changeset: 7165b3f1
Author:Alexey Semenyuk 
URL:   
https://git.openjdk.java.net/jdk17/commit/7165b3f105621398d7673253b6324e97ba0d2eee
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod

8271155: Wrong path separator in env variable

Reviewed-by: herrick, kcr, iris, almatvee

-

PR: https://git.openjdk.java.net/jdk17/pull/271

Re: [jdk17] RFR: 8271155: Wrong path separator in env variable

2021-07-22 Thread Alexander Matveev

On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk  wrote:

> Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' 
> dir to env variable in jpackage app launcher.

Marked as reviewed by almatvee (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/271

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

2021-07-22 Thread Ian Graves

On Wed, 21 Jul 2021 20:19:31 GMT, Ian Graves  wrote:

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

Circling back on this. I've worked in the test from Ivan Gerasimov's email back 
when. It includes some additional comparisons to prior approaches to assert 
improvements in error.

-

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

Re: RFR: 8075806: divideExact is missing in java.lang.Math [v6]

> Please consider this proposal to add `divideExact()` methods for integral 
> data types to `java.lang.Math` thereby rounding out "exact" support to all 
> four basic arithmetic operations.

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

  8075806: Add divideExact() to list of tested methods

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4770/files
  - new: https://git.openjdk.java.net/jdk/pull/4770/files/5093a2e8..1dabf117

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

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

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

Re: [jdk17] RFR: 8271155: Wrong path separator in env variable

2021-07-22 Thread Iris Clark

On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk  wrote:

> Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' 
> dir to env variable in jpackage app launcher.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/271

Re: RFR: 8075806: divideExact is missing in java.lang.Math [v5]

On Thu, 22 Jul 2021 19:40:46 GMT, Brian Burkhalter  wrote:

>> Please consider this proposal to add `divideExact()` methods for integral 
>> data types to `java.lang.Math` thereby rounding out "exact" support to all 
>> four basic arithmetic operations.
>
> Brian Burkhalter has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8075806: Clean up division by zero verbiage

Marked as reviewed by darcy (Reviewer).

test/jdk/java/lang/Math/ExactArithTests.java line 135:

> 133: }
> 134: 
> 135: boolean exceptionExpected = false;

Please add "divideExact" to the list of methods tested by 
static void testIntegerExact(int x, int y) 
and similar change for long.

-

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

Integrated: 8211002: test/jdk/java/lang/Math/PowTests.java skips testing for non-corner-case values

On Mon, 12 Jul 2021 19:39:13 GMT, Brian Burkhalter  wrote:

> Please consider this proposal to add some test coverage comparing `Math` and 
> `StrictMath` results of `pow()`.

This pull request has now been integrated.

Changeset: 1362e094
Author:Brian Burkhalter 
URL:   
https://git.openjdk.java.net/jdk/commit/1362e094798d8f1d86a30c96cf93b13c664a0438
Stats: 12 lines in 1 file changed: 11 ins; 0 del; 1 mod

8211002: test/jdk/java/lang/Math/PowTests.java skips testing for 
non-corner-case values

Reviewed-by: darcy

-

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

Re: [jdk17] RFR: 8271155: Wrong path separator in env variable

2021-07-22 Thread Kevin Rushforth

On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk  wrote:

> Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' 
> dir to env variable in jpackage app launcher.

Looks good. Is there a unit test associated with this? If not, do you think one 
would be useful?

-

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk17/pull/271

Re: RFR: 8211002: test/jdk/java/lang/Math/PowTests.java skips testing for non-corner-case values [v2]

On Wed, 14 Jul 2021 16:43:48 GMT, Brian Burkhalter  wrote:

>> Please consider this proposal to add some test coverage comparing `Math` and 
>> `StrictMath` results of `pow()`.
>
> Brian Burkhalter has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8211002: Change so that Tests.testUlpDiff() handles the NaNs and accepts a 
> ulp tolerance of 2

Marked as reviewed by darcy (Reviewer).

-

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

Re: [jdk17] RFR: 8271155: Wrong path separator in env variable

2021-07-22 Thread Andy Herrick

On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk  wrote:

> Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' 
> dir to env variable in jpackage app launcher.

Marked as reviewed by herrick (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/271

[jdk17] Integrated: 8270916: Update java.lang.annotation.Target for changes in JLS 9.6.4.1

On Mon, 19 Jul 2021 21:18:42 GMT, Joe Darcy  wrote:

> Given changes in JLS 9.6.4.1, JDK-8261610 in Java SE 17, the statements about 
> annotation applicability made in java.lang.annotation.Target need to be 
> updated to match.
> 
> Please also review the corresponding CSR: 
> https://bugs.openjdk.java.net/browse/JDK-8270917

This pull request has now been integrated.

Changeset: ecc37b06
Author:Joe Darcy 
URL:   
https://git.openjdk.java.net/jdk17/commit/ecc37b06f283c18ab4aa2b23562843bca14da85d
Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8270916: Update java.lang.annotation.Target for changes in JLS 9.6.4.1

Reviewed-by: bpb, naoto

-

PR: https://git.openjdk.java.net/jdk17/pull/256

Re: [jdk17] RFR: 8270916: Update java.lang.annotation.Target for changes in JLS 9.6.4.1

2021-07-22 Thread Naoto Sato

On Mon, 19 Jul 2021 21:18:42 GMT, Joe Darcy  wrote:

> Given changes in JLS 9.6.4.1, JDK-8261610 in Java SE 17, the statements about 
> annotation applicability made in java.lang.annotation.Target need to be 
> updated to match.
> 
> Please also review the corresponding CSR: 
> https://bugs.openjdk.java.net/browse/JDK-8270917

Marked as reviewed by naoto (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/256

Re: [jdk17] RFR: 8270916: Update java.lang.annotation.Target for changes in JLS 9.6.4.1

On Mon, 19 Jul 2021 21:18:42 GMT, Joe Darcy  wrote:

> Given changes in JLS 9.6.4.1, JDK-8261610 in Java SE 17, the statements about 
> annotation applicability made in java.lang.annotation.Target need to be 
> updated to match.
> 
> Please also review the corresponding CSR: 
> https://bugs.openjdk.java.net/browse/JDK-8270917

Marked as reviewed by bpb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/256

[jdk17] RFR: 8271155: Wrong path separator in env variable

Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' 
dir to env variable in jpackage app launcher.

-

Commit messages:
 - 8271155: Wrong path separator in env variable

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

PR: https://git.openjdk.java.net/jdk17/pull/271

Re: [jdk17] RFR: 8270916: Update java.lang.annotation.Target for changes in JLS 9.6.4.1

On Mon, 19 Jul 2021 21:18:42 GMT, Joe Darcy  wrote:

> Given changes in JLS 9.6.4.1, JDK-8261610 in Java SE 17, the statements about 
> annotation applicability made in java.lang.annotation.Target need to be 
> updated to match.
> 
> Please also review the corresponding CSR: 
> https://bugs.openjdk.java.net/browse/JDK-8270917

CSR now approved.

-

PR: https://git.openjdk.java.net/jdk17/pull/256

Re: RFR: 8211002: test/jdk/java/lang/Math/PowTests.java skips testing for non-corner-case values [v2]

On Wed, 14 Jul 2021 16:43:48 GMT, Brian Burkhalter  wrote:

>> Please consider this proposal to add some test coverage comparing `Math` and 
>> `StrictMath` results of `pow()`.
>
> Brian Burkhalter has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8211002: Change so that Tests.testUlpDiff() handles the NaNs and accepts a 
> ulp tolerance of 2

Ping.

-

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

Re: RFR: 8075806: divideExact is missing in java.lang.Math [v5]

> Please consider this proposal to add `divideExact()` methods for integral 
> data types to `java.lang.Math` thereby rounding out "exact" support to all 
> four basic arithmetic operations.

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

  8075806: Clean up division by zero verbiage

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4770/files
  - new: https://git.openjdk.java.net/jdk/pull/4770/files/328e4188..5093a2e8

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

  Stats: 16 lines in 2 files changed: 4 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4770.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4770/head:pull/4770

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

Integrated: 8268974: GetJREPath() JLI function fails to locate libjava.so if not standard Java launcher is used

On Fri, 18 Jun 2021 22:46:24 GMT, Alexey Semenyuk  wrote:

> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" 
> component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() 
> looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" 
> string and then it looks for "/lib/". But this is wrong order as it should 
> look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then 
> for "/lib/" if called from GetApplicationHome() and for "/lib/" first and 
> then for "/bin/" if called from GetApplicationHomeFromDll().

This pull request has now been integrated.

Changeset: 984003d5
Author:Alexey Semenyuk 
URL:   
https://git.openjdk.java.net/jdk/commit/984003d5c969443abae2d889e92cba30da26e55f
Stats: 65 lines in 2 files changed: 58 ins; 1 del; 6 mod

8268974: GetJREPath() JLI function fails to locate libjava.so if not standard 
Java launcher is used

Reviewed-by: almatvee, herrick, alanb

-

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

Re: [External] : Re: jpackage OS/X JDK-8263157 fix regressed out

There is no corresponding folder on other platforms, so to simplify
packaging "app" directory is used on all platforms.

- Alexey

On 7/22/2021 2:42 PM, Alan Snyder wrote:

Why is a directory named “app” used for dynamic libraries instead of the
conventional directory “Frameworks”?

Alan

On Jul 22, 2021, at 11:04 AM, Michael Hall wrote:

On Jul 22, 2021, at 12:29 PM, Alexey Semenyuk
wrote:

The fix for JDK-8263157 cleared the default value of `java.library.path` system
property and resulted in JDK-8267598 regression. So the fix for JDK-8263157 was
reworked: jpackage doesn't set `java.library.path` system property, but it adds
`app` directory to `DYLD_LIBRARY_PATH` env variable on OSX. OSX JVM startup
code builds the value of `java.library.path` system property from the value of
`DYLD_LIBRARY_PATH` env variable. This way jpackage doesn't interfere with the
default JVM initialization code and also adds `app` directory to
`java.library.path` system property.
As far as I can see it from the log, the value of `java.library.path` contains
`app` dir -
`/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app`. So it
works as expected.
Are you sure the native library is in place?

- Alexey

I missed that it was there somehow, but…

ls outputdir/HalfPipe.app/Contents/app | grep dylib
libAppleScriptEngine.dylib
libBSF4ooRexx.dylib
libfscript.dylib
libhp.dylib
libmacattrs.dylib

Also overriding
-Djava.library.path=$APPDIR
worked. So I didn’t look too closely.
So what am I still missing?
;/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app:/Users/mjh/Library/Java/Extensions:
Inconsistent path separators?

Re: [External] : Re: jpackage OS/X JDK-8263157 fix regressed out

2021-07-22 Thread Michael Hall




> On Jul 22, 2021, at 1:46 PM, Alexey Semenyuk  
> wrote:
> 
> Oh, inconsistent path separators indeed. Good catch! This is the reason it 
> doesn't work as it should.
> Filed https://bugs.openjdk.java.net/browse/JDK-8271155 to track it.
> 
> - Alexey
> 
> 

Thank you.

Re: [External] : Re: jpackage OS/X JDK-8263157 fix regressed out

Oh, inconsistent path separators indeed. Good catch! This is the reason
it doesn't work as it should.

Filed https://bugs.openjdk.java.net/browse/JDK-8271155 to track it.

- Alexey

On 7/22/2021 2:04 PM, Michael Hall wrote:

On Jul 22, 2021, at 12:29 PM, Alexey Semenyuk
wrote:

- Alexey

I missed that it was there somehow, but…

ls outputdir/HalfPipe.app/Contents/app | grep dylib
libAppleScriptEngine.dylib
libBSF4ooRexx.dylib
libfscript.dylib
libhp.dylib
libmacattrs.dylib

Re: jpackage OS/X JDK-8263157 fix regressed out

2021-07-22 Thread Alan Snyder

Why is a directory named “app” used for dynamic libraries instead of the 
conventional directory “Frameworks”?

  Alan



> On Jul 22, 2021, at 11:04 AM, Michael Hall  wrote:
> 
> 
> 
>> On Jul 22, 2021, at 12:29 PM, Alexey Semenyuk  
>> wrote:
>> 
>> The fix for JDK-8263157 cleared the default value of `java.library.path` 
>> system property and resulted in JDK-8267598 regression. So the fix for 
>> JDK-8263157 was reworked: jpackage doesn't set `java.library.path` system 
>> property, but it adds `app` directory to `DYLD_LIBRARY_PATH` env variable on 
>> OSX. OSX JVM startup code builds the value of `java.library.path` system 
>> property from the value of `DYLD_LIBRARY_PATH` env variable. This way 
>> jpackage doesn't interfere with the default JVM initialization code and also 
>> adds `app`  directory to `java.library.path` system property.
>> As far as I can see it from the log, the value of `java.library.path` 
>> contains `app` dir - 
>> `/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app`. So 
>> it works as expected.
>> Are you sure the native library is in place?
>> 
>> - Alexey
>> 
> 
> I missed that it was there somehow, but…
> 
> ls outputdir/HalfPipe.app/Contents/app | grep dylib
> libAppleScriptEngine.dylib
> libBSF4ooRexx.dylib
> libfscript.dylib
> libhp.dylib
> libmacattrs.dylib
> 
> Also overriding 
> -Djava.library.path=$APPDIR
> worked. So I didn’t look too closely. 
> So what am I still missing?
> ;/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app:/Users/mjh/Library/Java/Extensions:
> Inconsistent path separators?

Re: jpackage OS/X JDK-8263157 fix regressed out

2021-07-22 Thread Michael Hall




> On Jul 22, 2021, at 12:29 PM, Alexey Semenyuk  
> wrote:
> 
> The fix for JDK-8263157 cleared the default value of `java.library.path` 
> system property and resulted in JDK-8267598 regression. So the fix for 
> JDK-8263157 was reworked: jpackage doesn't set `java.library.path` system 
> property, but it adds `app` directory to `DYLD_LIBRARY_PATH` env variable on 
> OSX. OSX JVM startup code builds the value of `java.library.path` system 
> property from the value of `DYLD_LIBRARY_PATH` env variable. This way 
> jpackage doesn't interfere with the default JVM initialization code and also 
> adds `app`  directory to `java.library.path` system property.
> As far as I can see it from the log, the value of `java.library.path` 
> contains `app` dir - 
> `/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app`. So 
> it works as expected.
> Are you sure the native library is in place?
> 
> - Alexey
> 

I missed that it was there somehow, but…

ls outputdir/HalfPipe.app/Contents/app | grep dylib
libAppleScriptEngine.dylib
libBSF4ooRexx.dylib
libfscript.dylib
libhp.dylib
libmacattrs.dylib

Also overriding 
-Djava.library.path=$APPDIR
worked. So I didn’t look too closely. 
So what am I still missing?
;/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app:/Users/mjh/Library/Java/Extensions:
Inconsistent path separators?

Re: jpackage OS/X JDK-8263157 fix regressed out

The fix for JDK-8263157 cleared the default value of `java.library.path` 
system property and resulted in JDK-8267598 regression. So the fix for 
JDK-8263157 was reworked: jpackage doesn't set `java.library.path` 
system property, but it adds `app` directory to `DYLD_LIBRARY_PATH` env 
variable on OSX. OSX JVM startup code builds the value of 
`java.library.path` system property from the value of 
`DYLD_LIBRARY_PATH` env variable. This way jpackage doesn't interfere 
with the default JVM initialization code and also adds `app`  directory 
to `java.library.path` system property.
As far as I can see it from the log, the value of `java.library.path` 
contains `app` dir - 
`/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app`. 
So it works as expected.

Are you sure the native library is in place?

- Alexey

On 7/22/2021 10:01 AM, Michael Hall wrote:

JDK-8263157  [macos]: 
java.library.path is being set incorrectly

The fix for this seems to be gone in both current jdk17 and jdk18 releases. 
There is no ‘app’ directory included in java.library.path.

outputdir/HalfPipe.app/Contents/runtime/Contents/Home/bin/java -version
openjdk version "18-ea" 2022-03-15
OpenJDK Runtime Environment (build 18-ea+6-237)
OpenJDK 64-Bit Server VM (build 18-ea+6-237, mixed mode)

outputdir/HalfPipe.app/Contents/MacOS/HalfPipe
Exception in thread "main" java.lang.UnsatisfiedLinkError: no hp in 
java.library.path: 
/opt/ooRexx/lib/ooRexx;/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app:/Users/mjh/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.base/java.lang.Runtime.loadLibrary0(Unknown Source)
at java.base/java.lang.System.loadLibrary(Unknown Source)
at us.hall.hp.common.LoaderLaunchStub.(LoaderLaunchStub.java:35)
Failed to launch JVM

Re: JNI WeakGlobalRefs

2021-07-22 Thread Brian Goetz

You might also consider bringing this to panama-dev, since that will 
eventually be the recommended replacement for most uses of JNI.


On 7/21/2021 6:25 PM, David Holmes wrote:

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: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream [v9]

> Can I please get a review for this proposed fix for the issue reported in 
> https://bugs.openjdk.java.net/browse/JDK-8190753?
> 
> The commit here checks for the size of the zip entry before trying to create 
> a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been 
> included in this commit to reproduce the issue and verify the fix.
> 
> P.S: It's still a bit arguable whether it's a good idea to create the 
> `ByteArrayOutputStream` with an initial size potentially as large as the 
> `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default 
> value. However, I think that can be addressed separately while dealing with 
> https://bugs.openjdk.java.net/browse/JDK-8011146

Jaikiran Pai has updated the pull request incrementally with two additional 
commits since the last revision:

 - remove no longer necessary javadoc comment on test
 - review suggestion - wrap ByteArrayOutputStream instead of extending it

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4607/files
  - new: https://git.openjdk.java.net/jdk/pull/4607/files/c1ec9e12..90101d45

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

  Stats: 72 lines in 2 files changed: 19 ins; 35 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4607.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4607/head:pull/4607

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

Re: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream [v8]


Hello Bernd,

On 22/07/21 8:54 pm, Bernd Eckenfels wrote:

Hello,


So although you can transfer the contents to the file without requiring the 
access
to the byte array, you end up creating a new copy of that array (through the use
of `baos.toByteArray()`)

You can avoid the copy and the additional buffer with baos.writeTo() I think.

try (OutputStream os = Files.newOutputStream(entry.file)) { // maybe append?
 baos.writeTo(os);
}


You are absolutely right. I hadn't noticed ByteArrayOutputStream had 
this writeTo() method. Thank you for this input.


This was the only concern I had when it came to wrapping the 
ByteArrayOutputStream and now with your input it no longer is a concern. 
I have updated this PR to go ahead with the wrapping approach which also 
does away with the necessity of UncheckedIOException. Existing and the 
new tests continue to pass with this change.


-Jaikiran

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v5]

2021-07-22 Thread Severin Gehwolf

On Thu, 22 Jul 2021 12:15:03 GMT, Matthias Baesken  wrote:

>> Matthias Baesken 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 five additional 
>> commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8266490
>>  - Add hotspot tests
>>  - test and small adjustments suggested by Severin
>>  - Adjustments following Severins comments
>>  - JDK-8266490
>
> Hi Severin, thanks for the comments. I added a commit with a number of 
> adjustments 
> 
> src/hotspot/os/linux/cgroupSubsystem_linux.cpp
> adjusted log_info to log_debug
> 
> src/java.base/share/classes/sun/launcher/LauncherHelper.java
> adjusted the output to "Maximum Processes Limit:"
> 
> test/hotspot/jtreg/containers/docker/CheckOperatingSystemMXBean.java
> removed the getPidsMax related line (I think I inserted it while running some 
> tests and forgot previously to remove it)
> 
> test/hotspot/jtreg/containers/docker/TestPids.java
> added testing of "Unlimited"; added  --pids-limit=-1  for  Unlimited procs 
> like you suggested
> 
> test/jdk/jdk/internal/platform/docker/TestPidsLimit.java
> adjusted output; added  --pids-limit=-1  for  Unlimited procs like you 
> suggested

@MBaesken Thanks. We need a solution for 
https://github.com/openjdk/jdk/pull/4518#issuecomment-882637594 though. 
`--pids-limit=-1` doesn't seem to make it unlimited on all container runtimes. 
For example it fails for me here with:


$ docker --version
Docker version 20.10.6, build 370c289

-

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

Re: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream [v8]

2021-07-22 Thread Bernd Eckenfels

Hello,

> So although you can transfer the contents to the file without requiring the 
> access
> to the byte array, you end up creating a new copy of that array (through the 
> use
> of `baos.toByteArray()`)

You can avoid the copy and the additional buffer with baos.writeTo() I think.

try (OutputStream os = Files.newOutputStream(entry.file)) { // maybe append?
baos.writeTo(os);
}
// release the underlying byte array
baos = null;
// append any further data to the file with buffering enabled
tmpFileOS = new BufferedOutputStream(Files.newOutputStream(entry.file, APPEND));


--
http://bernd.eckenfels.net

Von: nio-dev  im Auftrag von Jaikiran Pai 

Gesendet: Thursday, July 22, 2021 2:55:46 PM
An: core-libs-dev@openjdk.java.net ; 
nio-...@openjdk.java.net 
Betreff: Re: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) 
leads to a negative initial size for ByteArrayOutputStream [v8]

On Wed, 21 Jul 2021 04:09:23 GMT, Jaikiran Pai  wrote:

> > > For some context - the new `FileRolloverOutputStream` extends 
> > > `ByteArrayOutputStream` and hence cannot have a `throws IOException` in 
> > > its overridden `write` methods.
> >
> >
> > Have you tried wrapping a BAOS rather than extending, that might allow the 
> > exception wrapping/unwapping to go away.
>
> Hello Alan,
>
> I did experiment with it earlier, before going with the current approach in 
> this PR. The disadvantage, as I see it, with wrapping a 
> `ByteArrayOutputStream` instead of extending it is that when trying to 
> rollover the contents to a file, you don't have access to the (inner 
> protected) byte array of the ByteArrayOutputStream.
>
> The rollover code would then look something like:
>
> ```
> private void transferToFile() throws IOException {
> // create a tempfile
> entry.file = getTempPathForEntry(null);
> // transfer the already written data from the byte array buffer into this 
> tempfile
> try (OutputStream os = new 
> BufferedOutputStream(Files.newOutputStream(entry.file))) {
> new ByteArrayInputStream(baos.toByteArray(), 0, 
> baos.size()).transferTo(os);
> }
> // release the underlying byte array
> baos = null;
> // append any further data to the file with buffering enabled
> tmpFileOS = new BufferedOutputStream(Files.newOutputStream(entry.file, 
> APPEND));
> }
> ```
>
> So although you can transfer the contents to the file without requiring the 
> access to the byte array, you end up creating a new copy of that array 
> (through the use of `baos.toByteArray()`), which can be at most 10MB in size. 
> I thought avoiding a new copy of that (potentially 10MB) array during this 
> transfer would be a good save and hence decided to settle on extending 
> `ByteArrayOutputStream` instead of wrapping it.
>
> The use of `extends` of course now means dealing with the 
> `UncheckedIOException` as done in this PR. But if you think that the array 
> copy isn't a concern and wrapping the `ByteArrayOutputStream` is a better 
> way, then I'll go ahead and update this PR accordingly.

Now that the mailing lists integration seems to be back to normal, just adding 
this dummy comment to bring to attention the latest comments in this PR.

-

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

jpackage OS/X JDK-8263157 fix regressed out

2021-07-22 Thread Michael Hall

JDK-8263157  [macos]: 
java.library.path is being set incorrectly

The fix for this seems to be gone in both current jdk17 and jdk18 releases. 
There is no ‘app’ directory included in java.library.path.

outputdir/HalfPipe.app/Contents/runtime/Contents/Home/bin/java -version
openjdk version "18-ea" 2022-03-15
OpenJDK Runtime Environment (build 18-ea+6-237)
OpenJDK 64-Bit Server VM (build 18-ea+6-237, mixed mode)

outputdir/HalfPipe.app/Contents/MacOS/HalfPipe
Exception in thread "main" java.lang.UnsatisfiedLinkError: no hp in 
java.library.path: 
/opt/ooRexx/lib/ooRexx;/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app:/Users/mjh/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.base/java.lang.Runtime.loadLibrary0(Unknown Source)
at java.base/java.lang.System.loadLibrary(Unknown Source)
at us.hall.hp.common.LoaderLaunchStub.(LoaderLaunchStub.java:35)
Failed to launch JVM

Re: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream [v8]