From rriggs at openjdk.java.net Mon May 2 14:34:53 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 2 May 2022 14:34:53 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() [v7] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 23:12:43 GMT, Brian Burkhalter wrote: >> Please consider this patch which would improve the performance of >> `FileChannel.transferTo()` on macOS and Windows. > > Brian Burkhalter 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 ten additional commits since the last revision: > > - 8274112: Cleanup based on reviewer comments > - Merge > - 8274112: Revert all changes except mapped transfer threshold > - 8274112: Remove native read-write copy; add threshold for mapped copy; use Linux copy_file_range() for direct copy if available > - Merge > - 8274112: Make transferTo0() static; remove check for null FileDescriptor > - 8274112: Modify transfer_read_write() not to throw if read or write fails > - 8274112: Refactor to use transferToFileChannel() > - 8274112: (fc) Tune FileChannel.transferTo() Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5623 From lancea at openjdk.java.net Mon May 2 14:40:57 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 2 May 2022 14:40:57 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() [v7] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 23:12:43 GMT, Brian Burkhalter wrote: >> Please consider this patch which would improve the performance of >> `FileChannel.transferTo()` on macOS and Windows. > > Brian Burkhalter 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 ten additional commits since the last revision: > > - 8274112: Cleanup based on reviewer comments > - Merge > - 8274112: Revert all changes except mapped transfer threshold > - 8274112: Remove native read-write copy; add threshold for mapped copy; use Linux copy_file_range() for direct copy if available > - Merge > - 8274112: Make transferTo0() static; remove check for null FileDescriptor > - 8274112: Modify transfer_read_write() not to throw if read or write fails > - 8274112: Refactor to use transferToFileChannel() > - 8274112: (fc) Tune FileChannel.transferTo() Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From bpb at openjdk.java.net Mon May 2 18:06:02 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 2 May 2022 18:06:02 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 00:14:29 GMT, Tyler Steele wrote: > PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. > > This PR makes the following changes: > - Sets the initial interval to 1 second regardless of the period. > - Change the default period to 1 second. > > All tests in `test/jdk/java/nio/file/WatchService` passing. Do you have any performance measurements to share? Note that the sensitivity can be set as shown in the [SensitivityModifier](https://github.com/openjdk/jdk/blob/41de506ed6c9dc0331c2b6ae99c11623df05f34a/test/jdk/java/nio/file/WatchService/SensitivityModifier.java) test. ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Mon May 2 19:19:29 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Mon, 2 May 2022 19:19:29 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService In-Reply-To: References: Message-ID: On Mon, 2 May 2022 18:02:33 GMT, Brian Burkhalter wrote: > Do you have any performance measurements to share? Nothing terribly rigorous, but the testing I did during development went from a 11.5 sec average down to about 1.5 seconds. Which is more or less what I expected when dropping a 10 second wait ;-) ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Mon May 2 19:19:31 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Mon, 2 May 2022 19:19:31 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 00:14:29 GMT, Tyler Steele wrote: > PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. > > This PR makes the following changes: > - Sets the initial interval to 1 second regardless of the period. > - Change the default period to 1 second. > > All tests in `test/jdk/java/nio/file/WatchService` passing. @AlanBateman Is there a guide to choosing which label is appropriate for a given change? I haven't been able to find one. ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From bpb at openjdk.java.net Mon May 2 19:49:23 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 2 May 2022 19:49:23 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService In-Reply-To: References: Message-ID: <2Q1_R5Y9m-ZOiIGbnDFYMdm5TkPqnngy9GKGjJXPiX0=.17e660e9-f12e-4156-8de2-096fe49a9a32@github.com> On Mon, 2 May 2022 19:17:11 GMT, Tyler Steele wrote: > @AlanBateman Is there a guide to choosing which label is appropriate for a given change? I haven't been able to find one. I think the problem was that the Jira issue had no subcomponent listed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From bpb at openjdk.java.net Mon May 2 19:49:23 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 2 May 2022 19:49:23 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService In-Reply-To: References: Message-ID: On Mon, 2 May 2022 19:15:18 GMT, Tyler Steele wrote: > > Do you have any performance measurements to share? > > Nothing terribly rigorous, but the testing I did during development went from a 11.5 sec average down to about 1.5 seconds. Which is more or less what I expected when dropping a 10 second wait ;-) > > > Note that the sensitivity can be set as shown in the [SensitivityModifier](https://github.com/openjdk/jdk/blob/41de506ed6c9dc0331c2b6ae99c11623df05f34a/test/jdk/java/nio/file/WatchService/SensitivityModifier.java) test. > > ?? Thanks for the link. I noticed it could be changed, but 10s still feels way too long for a default value. Could you perhaps test it with something a bit less aggressive than 1s, perhaps 5s? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From bpb at openjdk.java.net Mon May 2 19:59:23 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 2 May 2022 19:59:23 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 00:14:29 GMT, Tyler Steele wrote: > PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. > > This PR makes the following changes: > - Sets the initial interval to 1 second regardless of the period. > - Change the default period to 1 second. > > All tests in `test/jdk/java/nio/file/WatchService` passing. src/java.base/share/classes/sun/nio/fs/PollingWatchService.java line 118: > 116: > 117: // Extended modifiers may be used to specify the sensitivity level > 118: int sensitivity = 1; Perhaps a (static final) constant such as `DEFAULT_SENSITIVITY` should be defined and used here and at line 311? src/java.base/share/classes/sun/nio/fs/PollingWatchService.java line 311: > 309: Runnable thunk = new Runnable() { public void run() { poll(); }}; > 310: this.poller = scheduledExecutor > 311: .scheduleAtFixedRate(thunk, 1 /*init wait*/, period, TimeUnit.SECONDS); Maybe delete this `/*init wait*/` embedded comment and change the comment at line 308 to something like ```// create the periodic task with initialDelay set to the default sensitivity```? (The hard-coded 1 would of course be changed to the new constant.) ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Mon May 2 20:46:31 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Mon, 2 May 2022 20:46:31 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v2] In-Reply-To: References: Message-ID: > PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. > > This PR makes the following changes: > - Sets the initial interval to 1 second regardless of the period. > - Change the default period to 1 second. > > All tests in `test/jdk/java/nio/file/WatchService` passing. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Adds static constants for hard-coded values ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8479/files - new: https://git.openjdk.java.net/jdk/pull/8479/files/8f829ae1..cb65c8b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8479&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8479&range=00-01 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8479/head:pull/8479 PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Mon May 2 20:56:04 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Mon, 2 May 2022 20:56:04 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v3] In-Reply-To: References: Message-ID: > PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. > > This PR makes the following changes: > - Sets the initial interval to 1 second regardless of the period. > - Change the default period to 1 second. > > All tests in `test/jdk/java/nio/file/WatchService` passing. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Adds suggested changes to comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8479/files - new: https://git.openjdk.java.net/jdk/pull/8479/files/cb65c8b8..c538030b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8479&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8479&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8479/head:pull/8479 PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Mon May 2 20:56:05 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Mon, 2 May 2022 20:56:05 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v3] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 19:54:07 GMT, Brian Burkhalter wrote: >> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: >> >> Adds suggested changes to comment > > src/java.base/share/classes/sun/nio/fs/PollingWatchService.java line 118: > >> 116: >> 117: // Extended modifiers may be used to specify the sensitivity level >> 118: int sensitivity = 1; > > Perhaps a (static final) constant such as `DEFAULT_SENSITIVITY` should be defined and used here and at line 311? Agreed :-) > src/java.base/share/classes/sun/nio/fs/PollingWatchService.java line 311: > >> 309: Runnable thunk = new Runnable() { public void run() { poll(); }}; >> 310: this.poller = scheduledExecutor >> 311: .scheduleAtFixedRate(thunk, 1 /*init wait*/, period, TimeUnit.SECONDS); > > Maybe delete this `/*init wait*/` embedded comment and change the comment at line 308 to something like > ```// create the periodic task with initialDelay set to the default sensitivity```? (The hard-coded 1 would of course be changed to the new constant.) Good suggestion. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From bpb at openjdk.java.net Mon May 2 21:07:32 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 2 May 2022 21:07:32 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v3] In-Reply-To: References: Message-ID: <7kHnLnRaRcaXktCx3KL2Ex-1VbArMPth7hb039F0xNU=.90bf8a06-bda7-420b-a697-ae96e42a646a@github.com> On Mon, 2 May 2022 20:56:04 GMT, Tyler Steele wrote: >> PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. >> >> This PR makes the following changes: >> - Sets the initial interval to 1 second regardless of the period. >> - Change the default period to 1 second. >> >> All tests in `test/jdk/java/nio/file/WatchService` passing. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Adds suggested changes to comment src/java.base/share/classes/sun/nio/fs/PollingWatchService.java line 313: > 311: this.events = events; > 312: > 313: // create the periodic task with initialDelay set to the default sensitivity I don't think "default sensitivity" is apt any more; perhaps "specified constant" instead? ```// create the periodic task with initialDelay set to the specified constant``` ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Mon May 2 21:19:23 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Mon, 2 May 2022 21:19:23 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService In-Reply-To: References: Message-ID: On Mon, 2 May 2022 19:45:51 GMT, Brian Burkhalter wrote: > Could you perhaps test it with something a bit less aggressive than 1s, perhaps 5s? Thanks. Are you meaning to suggest a different default value? I recognize that my choice of 1s is arbitrary, and can change it if desired. My thinking is that 1s is quite long to a computer, and shouldn't cause too much additional load. In addition, anything more than 2s or so is a pretty long time for a 21st century human to wait. So either 1 or 2 seconds should be the sweet spot. Testing with initial interval of 5s yields 6.44s with my development test. ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Mon May 2 21:24:13 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Mon, 2 May 2022 21:24:13 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v4] In-Reply-To: References: Message-ID: > PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. > > This PR makes the following changes: > - Sets the initial interval to 1 second regardless of the period. > - Change the default period to 1 second. > > All tests in `test/jdk/java/nio/file/WatchService` passing. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: modifies comment as requested ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8479/files - new: https://git.openjdk.java.net/jdk/pull/8479/files/c538030b..fc6a65d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8479&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8479&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8479/head:pull/8479 PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Mon May 2 21:24:14 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Mon, 2 May 2022 21:24:14 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v3] In-Reply-To: <7kHnLnRaRcaXktCx3KL2Ex-1VbArMPth7hb039F0xNU=.90bf8a06-bda7-420b-a697-ae96e42a646a@github.com> References: <7kHnLnRaRcaXktCx3KL2Ex-1VbArMPth7hb039F0xNU=.90bf8a06-bda7-420b-a697-ae96e42a646a@github.com> Message-ID: On Mon, 2 May 2022 21:03:50 GMT, Brian Burkhalter wrote: >> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: >> >> Adds suggested changes to comment > > src/java.base/share/classes/sun/nio/fs/PollingWatchService.java line 313: > >> 311: this.events = events; >> 312: >> 313: // create the periodic task with initialDelay set to the default sensitivity > > I don't think "default sensitivity" is apt any more; perhaps "specified constant" instead? > ```// create the periodic task with initialDelay set to the specified constant``` ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From bpb at openjdk.java.net Mon May 2 22:01:18 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 2 May 2022 22:01:18 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService In-Reply-To: References: Message-ID: On Mon, 2 May 2022 21:16:06 GMT, Tyler Steele wrote: > > Could you perhaps test it with something a bit less aggressive than 1s, perhaps 5s? Thanks. > > Are you meaning to suggest a different default value? I recognize that my choice of 1s is arbitrary, and can change it if desired. My thinking is that 1s is quite long to a computer, and shouldn't cause too much additional load. In addition, anything more than 2s or so is a pretty long time for a 21st century human to wait. So either 1 or 2 seconds should be the sweet spot. > > Testing with initial interval of 5s yields 6.44s with my development test. Yes, I was thinking of a different default value. Subjectively 6.44s does seem rather slow however. I know this is hard to measure in any kind of rigorous way, and the current 10s is really bad. I think the concern would be if there were many simultaneous watch services with frequent polling causing an overall performance degradation. ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Mon May 2 22:34:23 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Mon, 2 May 2022 22:34:23 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v4] In-Reply-To: References: Message-ID: <_CyNf1G4piZEsMf5kf60EISKF03RzNg9yZk8z4cRqyQ=.15edb813-c203-433e-9316-ae50eaa1031e@github.com> On Mon, 2 May 2022 21:24:13 GMT, Tyler Steele wrote: >> PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. >> >> This PR makes the following changes: >> - Sets the initial interval to 1 second regardless of the period. >> - Change the default period to 1 second. >> >> All tests in `test/jdk/java/nio/file/WatchService` passing. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > modifies comment as requested I agree it is good to consider whether or not the design makes it easy to load up so many changes that performance degrades. But I think we're well clear of that point even with 1s. I think it helps that [scheduleAtFixedRate](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/ScheduledExecutorService.html#scheduleAtFixedRate(java.lang.Runnable,long,long,java.util.concurrent.TimeUnit)) guarantees that the tasks will not run concurrently and [Watchable](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Watchable.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind%5B%5D,java.nio.file.WatchEvent.Modifier...)) specifies that the key should only be created if one doesn't already exist. If a user were to register enough unique Watchable objects to degrade the performance of their system, I am hopeful that the reason for the slow down would be clear to them. An alternative would be to keep the initial wait at 1s and increase the default polling interval to 2s. ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From bpb at openjdk.java.net Tue May 3 00:37:34 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 3 May 2022 00:37:34 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v7] In-Reply-To: References: Message-ID: > Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). Brian Burkhalter 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 eight additional commits since the last revision: - 8057113: trailing dot yields empty string extension; add test - Merge - 8057113: String getExtension(String defaultExtension) to Optional getExtension() and other changes - 8057113: Clean up trailing whitespace - 8057113: Implement reviewer suggestions for replaceExtension() - 8057113: Add hasExtension() and replaceExtension() - 8057113: Fix variable name in @return verbiage - 8057113: (fs) Path should have a method to obtain the filename extension ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8066/files - new: https://git.openjdk.java.net/jdk/pull/8066/files/8ed8b1b2..e5240f1c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8066&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8066&range=05-06 Stats: 206499 lines in 3275 files changed: 147275 ins; 14843 del; 44381 mod Patch: https://git.openjdk.java.net/jdk/pull/8066.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8066/head:pull/8066 PR: https://git.openjdk.java.net/jdk/pull/8066 From bpb at openjdk.java.net Tue May 3 00:37:37 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 3 May 2022 00:37:37 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v6] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 22:14:30 GMT, Brian Burkhalter wrote: >> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8057113: String getExtension(String defaultExtension) to Optional getExtension() and other changes Commit e5240f1c10023b447a8eac91fc188dea033c9616 re-specifies `getExtension()` to return `Optional.of("")` for cases where the string representation of the `Path` has a dot (`'.'`) at the last index and `Optional.empty()` was formerly returned. A test is also added. ------------- PR: https://git.openjdk.java.net/jdk/pull/8066 From bpb at openjdk.java.net Tue May 3 00:50:21 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 3 May 2022 00:50:21 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v4] In-Reply-To: <_CyNf1G4piZEsMf5kf60EISKF03RzNg9yZk8z4cRqyQ=.15edb813-c203-433e-9316-ae50eaa1031e@github.com> References: <_CyNf1G4piZEsMf5kf60EISKF03RzNg9yZk8z4cRqyQ=.15edb813-c203-433e-9316-ae50eaa1031e@github.com> Message-ID: <0J_St3KB-VxNZDsyuAQ7F30jD4tQPXHlizmwg5QnKhE=.4734b92d-2522-4969-9378-a308c765de58@github.com> On Mon, 2 May 2022 22:30:51 GMT, Tyler Steele wrote: > An alternative would be to keep the initial wait at 1s and increase the default polling interval to 2s. That might be better. A more ideal way to fix this would be to implement something on top of `inotify()`, `kqueue()`, or whatever similar native system mechanism exists on AIX. ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From mbaesken at openjdk.java.net Tue May 3 07:04:56 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 3 May 2022 07:04:56 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v2] In-Reply-To: References: Message-ID: > Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : > https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt > Macros for Conditional Declarations > "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." > > However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: set _WIN32_WINNT=0x0601 centrally in flags-cflags.m4 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8428/files - new: https://git.openjdk.java.net/jdk/pull/8428/files/aef2486f..dff223c5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=00-01 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8428.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8428/head:pull/8428 PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Tue May 3 07:10:58 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 3 May 2022 07:10:58 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: > Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : > https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt > Macros for Conditional Declarations > "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." > > However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust Copyright year in wepoll.c ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8428/files - new: https://git.openjdk.java.net/jdk/pull/8428/files/dff223c5..23b63c5b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8428.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8428/head:pull/8428 PR: https://git.openjdk.java.net/jdk/pull/8428 From alanb at openjdk.java.net Tue May 3 08:24:13 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 3 May 2022 08:24:13 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v4] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 21:24:13 GMT, Tyler Steele wrote: >> PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. >> >> This PR makes the following changes: >> - Sets the initial interval to 1 second regardless of the period. >> - Change the default period to 1 second. >> >> All tests in `test/jdk/java/nio/file/WatchService` passing. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > modifies comment as requested src/java.base/share/classes/sun/nio/fs/PollingWatchService.java line 253: > 251: private class PollingWatchKey extends AbstractWatchKey { > 252: > 253: private static final int POLLING_INIT_DELAY = 1; Can you move this up to the top of the file so it's with DEFAULT_POLLING_INTERVAL? I thin both will need a short one line comment. I'm not sure about changing it to 1s as it may lead to complaints from macOS users with programs that monitor directories with a large number of files. The right thing is of course to include a native implementation for that platform, some day :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From alanb at openjdk.java.net Tue May 3 08:27:22 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 3 May 2022 08:27:22 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: <61bijpgV4Ieny4ue1laoZWoKzJH7nFLWlaF0ZE1fUJM=.a8a96cc5-ad9e-4e87-b45f-9d92a77731b0@github.com> On Thu, 28 Apr 2022 07:13:24 GMT, Matthias Baesken wrote: >> src/java.base/windows/native/libnio/ch/wepoll.c line 159: >> >>> 157: >>> 158: #undef _WIN32_WINNT >>> 159: #define _WIN32_WINNT 0x0601 >> >> This is 3rd party code and would prefer not change it if possible. > > Hi Alan, I agree (thats why I did not change the define in harfbuzz, but I missed that wepoll.c is 3rd party code as well). I assume you can revert the update to the copyright header in the latest version as there aren't any changes to this source file now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mcimadamore at openjdk.java.net Tue May 3 10:09:36 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 3 May 2022 10:09:36 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v36] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Tweak support for Linker lookup Improve javadoc of SymbolLookup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/d1fcf012..dc309e8b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=35 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=34-35 Stats: 159 lines in 14 files changed: 96 ins; 8 del; 55 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Tue May 3 10:09:38 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 3 May 2022 10:09:38 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v35] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 08:15:32 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Tweak Addressable javadoc We've tweaked the support for looking up symbols in the standard libraries - `CLinker` used to implement `SymbolLookup`, now `CLinker` returns a "default lookup" instead. We've also greatly improved the javadoc of `SymbolLookup` - many thanks to Alex for the help! New javadoc here: http://cr.openjdk.java.net/~mcimadamore/8282191/v3/javadoc/java.base/module-summary.html ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Tue May 3 10:40:02 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 3 May 2022 10:40:02 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Tweak support for Linker lookup Improve javadoc of SymbolLookup - Tweak Addressable javadoc - Downcall and upcall tests use wrong layout which is missing some trailing padding - Simplify libraryLookup impl - Address CSR comments - Merge branch 'master' into foreign-preview - Add ValueLayout changes - Tweak support for array element var handle - ... and 47 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...41d055ab ------------- Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=36 Stats: 65464 lines in 367 files changed: 43470 ins; 19432 del; 2562 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From erikj at openjdk.java.net Tue May 3 13:17:21 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 3 May 2022 13:17:21 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Copyright year in wepoll.c If we define this centrally using compiler flags, then we should not also update each location in the source. Those need to either be removed or left alone. In the cases where the source definition is guarded with an ifndef and there is a comment explaining why a particular version of windows is required, keeping it around could make sense. But on the other hand, since those defines are overridden using flags, they are likely to bit rot over time so we might as well just remove all of them. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From dholmes at openjdk.java.net Tue May 3 13:31:12 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 3 May 2022 13:31:12 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Copyright year in wepoll.c I agree with Erik - the source locations need to be modified to not define it. If we want to keep a record perhaps add an assertion that the value is what was expected? I still feel we have a disconnect between this and an actual check for what the build and runtime platform version is ... and it isn't at all clear how someone using an API only in a later Windows version, and so setting _WIN32_WINNT to a higher value, will know that this is defined down in the build files ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From duke at openjdk.java.net Tue May 3 13:51:09 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 3 May 2022 13:51:09 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v5] In-Reply-To: References: Message-ID: > PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. > > This PR makes the following changes: > - Sets the initial interval to 1 second regardless of the period. > - Change the default period to 1 second. > > All tests in `test/jdk/java/nio/file/WatchService` passing. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Requested changes - Move constants to top of file - Change default polling interval 1 -> 2 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8479/files - new: https://git.openjdk.java.net/jdk/pull/8479/files/fc6a65d7..696e1ee5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8479&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8479&range=03-04 Stats: 11 lines in 1 file changed: 6 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8479/head:pull/8479 PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Tue May 3 13:56:49 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 3 May 2022 13:56:49 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v6] In-Reply-To: References: Message-ID: <8eLw1Iu7tFxNnj49fdcwVEefnr1HKD_K6CB1LlGU_ls=.d158e6ef-f2cf-4850-9164-7b09f406e69a@github.com> > PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. > > This PR makes the following changes: > - Sets the initial interval to 1 second regardless of the period. > - Change the default period to 1 second. > > All tests in `test/jdk/java/nio/file/WatchService` passing. Tyler Steele 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: Change default polling interval 1 -> 2 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8479/files - new: https://git.openjdk.java.net/jdk/pull/8479/files/696e1ee5..65eb8f12 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8479&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8479&range=04-05 Stats: 11 lines in 1 file changed: 5 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8479/head:pull/8479 PR: https://git.openjdk.java.net/jdk/pull/8479 From mbaesken at openjdk.java.net Tue May 3 14:00:21 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 3 May 2022 14:00:21 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: <61bijpgV4Ieny4ue1laoZWoKzJH7nFLWlaF0ZE1fUJM=.a8a96cc5-ad9e-4e87-b45f-9d92a77731b0@github.com> References: <61bijpgV4Ieny4ue1laoZWoKzJH7nFLWlaF0ZE1fUJM=.a8a96cc5-ad9e-4e87-b45f-9d92a77731b0@github.com> Message-ID: <09w3bQ6aE-0lywGwhamYkRZeizTLHpYID7C5dzyuzTc=.44290269-9308-4969-ac52-2f0423883b2b@github.com> On Tue, 3 May 2022 08:23:52 GMT, Alan Bateman wrote: >> Hi Alan, I agree (thats why I did not change the define in harfbuzz, but I missed that wepoll.c is 3rd party code as well). > > I assume you can revert the update to the copyright header in the latest version as there aren't any changes to this source file now. Yes sure I did it . ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From duke at openjdk.java.net Tue May 3 14:03:17 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 3 May 2022 14:03:17 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v7] In-Reply-To: References: Message-ID: <8rfGwpVSdJbBLvMqmwU1ubnrNUyhAMWc2jOZaNG6Md0=.a3fd5967-d608-47aa-8665-762dbea28ec5@github.com> > PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. > > This PR makes the following changes: > - Sets the initial interval to 1 second regardless of the period. > - Change the default period to 1 second. > > All tests in `test/jdk/java/nio/file/WatchService` passing. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Adds comments to polling thread constant values ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8479/files - new: https://git.openjdk.java.net/jdk/pull/8479/files/65eb8f12..6328307a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8479&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8479&range=05-06 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8479/head:pull/8479 PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Tue May 3 14:03:18 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 3 May 2022 14:03:18 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v4] In-Reply-To: <0J_St3KB-VxNZDsyuAQ7F30jD4tQPXHlizmwg5QnKhE=.4734b92d-2522-4969-9378-a308c765de58@github.com> References: <_CyNf1G4piZEsMf5kf60EISKF03RzNg9yZk8z4cRqyQ=.15edb813-c203-433e-9316-ae50eaa1031e@github.com> <0J_St3KB-VxNZDsyuAQ7F30jD4tQPXHlizmwg5QnKhE=.4734b92d-2522-4969-9378-a308c765de58@github.com> Message-ID: On Tue, 3 May 2022 00:46:37 GMT, Brian Burkhalter wrote: > > An alternative would be to keep the initial wait at 1s and increase the default polling interval to 2s. > > That might be better. I made this change. > A more ideal way to fix this would be to implement something on top of `inotify()`, `kqueue()`, or whatever similar native system mechanism exists on AIX. Agreed. I have adding an implementation on top of AIX Event Infrastructure on my to-do list, but this easy fix that will address my current problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Tue May 3 14:08:15 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 3 May 2022 14:08:15 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v4] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 08:20:26 GMT, Alan Bateman wrote: > Can you move this up to the top of the file so it's with DEFAULT_POLLING_INTERVAL? I thin both will need a short one line comment. The constants are used in different objects, so I'm not sure there is a sensible way to to do this. A constant reference to a private object might be a way, but that felt like too much indirection. > I'm not sure about changing it to 1s as it may lead to complaints from macOS users with programs that monitor directories with a large number of files. The right thing is of course to include a native implementation for that platform, some day :-) Changed to 2s interval between subsequent polls since there have been a few concerns about this :-). I also agree that a native implementation would be far superior. ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From rriggs at openjdk.java.net Tue May 3 14:52:23 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 3 May 2022 14:52:23 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v7] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 00:37:34 GMT, Brian Burkhalter wrote: >> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). > > Brian Burkhalter 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 eight additional commits since the last revision: > > - 8057113: trailing dot yields empty string extension; add test > - Merge > - 8057113: String getExtension(String defaultExtension) to Optional getExtension() and other changes > - 8057113: Clean up trailing whitespace > - 8057113: Implement reviewer suggestions for replaceExtension() > - 8057113: Add hasExtension() and replaceExtension() > - 8057113: Fix variable name in @return verbiage > - 8057113: (fs) Path should have a method to obtain the filename extension src/java.base/share/classes/java/nio/file/Path.java line 276: > 274: * else > 275: * Optional.empty(); > 276: * } Maybe clearer as: if (lastDot <= 0) return Option.empty(); return lastDot == name.length() -1 ? optional.of("") : optional.of(name.substring(lastDot + 1)); I think the update for a file name with a final dot having an empty extension works well. src/java.base/share/classes/java/nio/file/Path.java line 280: > 278: * @return an {@code Optional} which either contains the file name of > 279: * this path, or is {@link Optional#empty empty} if the extension > 280: * is indeterminate Can it say "not found"; indeterminate sounds non-deterministic but the algorithm is. src/java.base/share/classes/java/nio/file/Path.java line 328: > 326: String thisExtension = getExtension().orElse(null); > 327: if (thisExtension == null) > 328: return Optional.empty(); Maybe keep around the Optional holding the extension to return if it is empty or matches; saving creating a new one. ------------- PR: https://git.openjdk.java.net/jdk/pull/8066 From bpb at openjdk.java.net Tue May 3 16:31:12 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 3 May 2022 16:31:12 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v7] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 14:29:43 GMT, Roger Riggs wrote: > Maybe keep around the Optional holding the extension to return if it is empty or matches; saving creating a new one. I don't understand this comment. I think that this could be done in the implementation classes but I do not see how to do it here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8066 From rriggs at openjdk.java.net Tue May 3 16:45:29 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 3 May 2022 16:45:29 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v7] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 16:28:14 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/nio/file/Path.java line 328: >> >>> 326: String thisExtension = getExtension().orElse(null); >>> 327: if (thisExtension == null) >>> 328: return Optional.empty(); >> >> Maybe keep around the Optional holding the extension to return if it is empty or matches; saving creating a new one. > >> Maybe keep around the Optional holding the extension to return if it is empty or matches; saving creating a new one. > > I don't understand this comment. I think that this could be done in the implementation classes but I do not see how to do it here. Something like: default Optional hasExtension(String ext, String... extensions) { requireNonNull(ext); Optional extension = getExtension(); String thisExtension = null; if (extension.isEmpty() || (thisExtension = extension.get()).equals(ext)) return extension; ... ------------- PR: https://git.openjdk.java.net/jdk/pull/8066 From bpb at openjdk.java.net Tue May 3 17:08:25 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 3 May 2022 17:08:25 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v7] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 16:41:30 GMT, Roger Riggs wrote: >>> Maybe keep around the Optional holding the extension to return if it is empty or matches; saving creating a new one. >> >> I don't understand this comment. I think that this could be done in the implementation classes but I do not see how to do it here. > > Something like: > > default Optional hasExtension(String ext, String... extensions) { > requireNonNull(ext); > Optional extension = getExtension(); > String thisExtension = null; > if (extension.isEmpty() || (thisExtension = extension.get()).equals(ext)) > return extension; > ... I see. That is good. This is what I had thought of: --- a/src/java.base/unix/classes/sun/nio/fs/UnixPath.java +++ b/src/java.base/unix/classes/sun/nio/fs/UnixPath.java + private volatile Optional theExtension = null; + + @Override + public Optional getExtension() { + if (theExtension == null) { + theExtension = Path.super.getExtension(); + } + return theExtension; + } ------------- PR: https://git.openjdk.java.net/jdk/pull/8066 From bpb at openjdk.java.net Tue May 3 17:32:04 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 3 May 2022 17:32:04 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v8] In-Reply-To: References: Message-ID: > Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8057113: Fix getExtension() commcents; improve hasExtension() implementation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8066/files - new: https://git.openjdk.java.net/jdk/pull/8066/files/e5240f1c..3d537a31 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8066&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8066&range=06-07 Stats: 21 lines in 1 file changed: 4 ins; 7 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/8066.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8066/head:pull/8066 PR: https://git.openjdk.java.net/jdk/pull/8066 From mbaesken at openjdk.java.net Wed May 4 07:37:14 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 07:37:14 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Copyright year in wepoll.c Interesting fact : we run now into this compile error : d:\a\jdk\jdk\jdk\src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp(1262): error C2065: 'NCRYPT_CIPHER_KEY_BLOB': undeclared identifier d:\a\jdk\jdk\jdk\src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp(1280): error C2065: 'NCRYPT_PROTECTED_KEY_BLOB': undeclared identifier Reason seems that already for some time ( at least OpenJDK 11 (!) ) we have an implicit minimum requirement of Windows 8 / Windows 2012 APIs for this code, so enforcing Win 7 is too old : https://docs.microsoft.com/en-us/windows/win32/api/ncrypt/nf-ncrypt-ncryptexportkey NCRYPT_PROTECTED_KEY_BLOB Export a protected key in a NCRYPT_KEY_BLOB_HEADER structure. Windows 8 and Windows Server 2012: Support for this value begins. NCRYPT_CIPHER_KEY_BLOB Export a cipher key in a NCRYPT_KEY_BLOB_HEADER structure. Windows 8 and Windows Server 2012: Support for this value begins. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Wed May 4 07:42:14 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 07:42:14 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: <9KE3CEXRqW4z5bQgy9E5ydrFvcxY4LgV9zA-KGRH09M=.e21bbecb-5e37-4887-9a74-7e4227c70c07@github.com> On Tue, 3 May 2022 13:27:41 GMT, David Holmes wrote: > I agree with Erik - the source locations need to be modified to not define it. If we want to keep a record perhaps add an assertion that the value is what was expected? > > I still feel we have a disconnect between this and an actual check for what the build and runtime platform version is ... > > and it isn't at all clear how someone using an API only in a later Windows version, and so setting _WIN32_WINNT to a higher value, will know that this is defined down in the build files ? Hi David, I agree the other locations as long as they are not 3rd party code should be cleaned up. Someone using an API that is only available in later Windows versions would get a redefinition warning as long as no undefine is done. But we have to set _WIN32_WINNT anyway to a higher value (windows8, I think that's 0x0602) to compile src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp . ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Wed May 4 08:00:08 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 08:00:08 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: Message-ID: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> > Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : > https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt > Macros for Conditional Declarations > "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." > > However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust API level to Windows 8 for security.cpp and do some cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8428/files - new: https://git.openjdk.java.net/jdk/pull/8428/files/23b63c5b..721528c4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=02-03 Stats: 31 lines in 7 files changed: 1 ins; 26 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8428.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8428/head:pull/8428 PR: https://git.openjdk.java.net/jdk/pull/8428 From dholmes at openjdk.java.net Wed May 4 08:38:24 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 4 May 2022 08:38:24 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup I'm confused. `src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp` doesn't set _WIN32_WINNT so how is that later API being enabled? Does this mean that not setting _WIN32_WINNT means :any API is allowed" ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Wed May 4 09:11:17 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 09:11:17 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:34:43 GMT, David Holmes wrote: > I'm confused. `src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp` doesn't set _WIN32_WINNT so how is that later API being enabled? Does this mean that not setting _WIN32_WINNT means :any API is allowed" ? I found this info here https://stackoverflow.com/questions/37668692/visual-studio-setting-winver-win32-winnt-to-windows-8-on-windows-7 "VS 2012 uses the Windows 8.0 SDK which defaults to _WIN32_WINNT=0x0602 (Windows 8). VS 2013 / 2015 uses the Windows 8.1 SDK which defaults to _WIN32_WINNT=0x0603 (Windows 8.1). If you use VS 2015 and the Windows 10 SDK, it defaults to _WIN32_WINNT=0x0A00 (Windows 10)." So it seems you get some more or less recent default when working with a not too old compiler/SDK. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From bpb at openjdk.java.net Wed May 4 14:37:34 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 4 May 2022 14:37:34 GMT Subject: Integrated: 8274112: (fc) Tune FileChannel.transferTo() In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 01:25:37 GMT, Brian Burkhalter wrote: > Please consider this patch which would improve the performance of > `FileChannel.transferTo()` on macOS and Windows. This pull request has now been integrated. Changeset: 17cc7131 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/17cc7131abf699070dc491e69b21207f01c65cf6 Stats: 122 lines in 3 files changed: 75 ins; 1 del; 46 mod 8274112: (fc) Tune FileChannel.transferTo() Reviewed-by: alanb, lancea, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From duke at openjdk.java.net Wed May 4 14:59:39 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 4 May 2022 14:59:39 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v4] In-Reply-To: <0J_St3KB-VxNZDsyuAQ7F30jD4tQPXHlizmwg5QnKhE=.4734b92d-2522-4969-9378-a308c765de58@github.com> References: <_CyNf1G4piZEsMf5kf60EISKF03RzNg9yZk8z4cRqyQ=.15edb813-c203-433e-9316-ae50eaa1031e@github.com> <0J_St3KB-VxNZDsyuAQ7F30jD4tQPXHlizmwg5QnKhE=.4734b92d-2522-4969-9378-a308c765de58@github.com> Message-ID: On Tue, 3 May 2022 00:46:37 GMT, Brian Burkhalter wrote: >> I agree it is good to consider whether or not the design makes it easy to load up so many changes that performance degrades. But I think we're well clear of that point even with 1s. I think it helps that [scheduleAtFixedRate](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/ScheduledExecutorService.html#scheduleAtFixedRate(java.lang.Runnable,long,long,java.util.concurrent.TimeUnit)) guarantees that the tasks will not run concurrently and [Watchable](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Watchable.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind%5B%5D,java.nio.file.WatchEvent.Modifier...)) specifies that the key should only be created if one doesn't already exist. >> >> If a user were to register enough unique Watchable objects to degrade the performance of their system, I am hopeful that the reason for the slow down would be clear to them. >> >> An alternative would be to keep the initial wait at 1s and increase the default polling interval to 2s. > >> An alternative would be to keep the initial wait at 1s and increase the default polling interval to 2s. > > That might be better. > > A more ideal way to fix this would be to implement something on top of `inotify()`, `kqueue()`, or whatever similar native system mechanism exists on AIX. Thanks for your comments @bplb and @AlanBateman. If you have no further comments, and are happy with the ones I've resolved, please finalize your reviews so that I may merge (I am eager to get this one in so that I can backport it). ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From stuefe at openjdk.java.net Wed May 4 16:17:29 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 4 May 2022 16:17:29 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v7] In-Reply-To: <8rfGwpVSdJbBLvMqmwU1ubnrNUyhAMWc2jOZaNG6Md0=.a3fd5967-d608-47aa-8665-762dbea28ec5@github.com> References: <8rfGwpVSdJbBLvMqmwU1ubnrNUyhAMWc2jOZaNG6Md0=.a3fd5967-d608-47aa-8665-762dbea28ec5@github.com> Message-ID: On Tue, 3 May 2022 14:03:17 GMT, Tyler Steele wrote: >> PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. >> >> This PR makes the following changes: >> - Sets the initial interval to 1 second regardless of the period. >> - Change the default period to 1 second. >> >> All tests in `test/jdk/java/nio/file/WatchService` passing. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Adds comments to polling thread constant values This looks reasonable to me. I agree the default of 2secs is fine for most scenarios. If someone wants to saturate the Watchservice, he will manage to do that, but as Tyler wrote, it is an obvious problem. Cheers, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8479 From bpb at openjdk.java.net Wed May 4 16:25:26 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 4 May 2022 16:25:26 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v7] In-Reply-To: <8rfGwpVSdJbBLvMqmwU1ubnrNUyhAMWc2jOZaNG6Md0=.a3fd5967-d608-47aa-8665-762dbea28ec5@github.com> References: <8rfGwpVSdJbBLvMqmwU1ubnrNUyhAMWc2jOZaNG6Md0=.a3fd5967-d608-47aa-8665-762dbea28ec5@github.com> Message-ID: On Tue, 3 May 2022 14:03:17 GMT, Tyler Steele wrote: >> PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. >> >> This PR makes the following changes: >> - Sets the initial interval to 1 second regardless of the period. >> - Change the default period to 1 second. >> >> All tests in `test/jdk/java/nio/file/WatchService` passing. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Adds comments to polling thread constant values Might be better if both constants were on `PollingWatchService` but this is all right. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Wed May 4 16:25:27 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 4 May 2022 16:25:27 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v7] In-Reply-To: References: <8rfGwpVSdJbBLvMqmwU1ubnrNUyhAMWc2jOZaNG6Md0=.a3fd5967-d608-47aa-8665-762dbea28ec5@github.com> Message-ID: On Wed, 4 May 2022 16:13:44 GMT, Thomas Stuefe wrote: >> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: >> >> Adds comments to polling thread constant values > > This looks reasonable to me. I agree the default of 2secs is fine for most scenarios. If someone wants to saturate the Watchservice, he will manage to do that, but as Tyler wrote, it is an obvious problem. > > Cheers, Thomas Thanks @tstuefe! ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Wed May 4 16:56:40 2022 From: duke at openjdk.java.net (ExE Boss) Date: Wed, 4 May 2022 16:56:40 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 10:40:02 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: > > - Merge branch 'master' into foreign-preview > - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Tweak support for Linker lookup > Improve javadoc of SymbolLookup > - Tweak Addressable javadoc > - Downcall and upcall tests use wrong layout which is missing some trailing padding > - Simplify libraryLookup impl > - Address CSR comments > - Merge branch 'master' into foreign-preview > - Add ValueLayout changes > - Tweak support for array element var handle > - ... and 47 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...41d055ab src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 116: > 114: * Linker nativeLinker = Linker.nativeLinker(); > 115: * SymbolLookup stdlib = nativeLinker.defaultLookup(); > 116: * MemorySegment malloc = stdlib.lookup("malloc"); This?should?be: Suggestion: * Optional malloc = stdlib.lookup("malloc"); or Suggestion: * MemorySegment malloc = stdlib.lookup("malloc").orElseThrow(); src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 153: > 151: static SymbolLookup loaderLookup() { > 152: Class caller = Reflection.getCallerClass(); > 153: ClassLoader loader = Objects.requireNonNull(caller.getClassLoader()); Shouldn?t?this be?changed to?throw `IllegalCallerException` instead?of?throwing `NullPointerException` when?the?`caller`?s `ClassLoader` is?`null`[^1] or?when `caller`?itself is?`null`[^2]? [^1]: This?happens when?`caller` is?on the?bootstrap?classpath. [^2]: This?happens when `SymbolLookup.loaderLookup()` is?called by?native?code and?no?**Java**?code is?on?the?call?stack. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From alanb at openjdk.java.net Wed May 4 16:58:34 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 4 May 2022 16:58:34 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v4] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 14:05:07 GMT, Tyler Steele wrote: >> src/java.base/share/classes/sun/nio/fs/PollingWatchService.java line 253: >> >>> 251: private class PollingWatchKey extends AbstractWatchKey { >>> 252: >>> 253: private static final int POLLING_INIT_DELAY = 1; >> >> Can you move this up to the top of the file so it's with DEFAULT_POLLING_INTERVAL? I thin both will need a short one line comment. >> >> I'm not sure about changing it to 1s as it may lead to complaints from macOS users with programs that monitor directories with a large number of files. The right thing is of course to include a native implementation for that platform, some day :-) > >> Can you move this up to the top of the file so it's with DEFAULT_POLLING_INTERVAL? I thin both will need a short one line comment. > > The constants are used in different objects, so I'm not sure there is a sensible way to to do this. A constant reference to a private object might be a way, but that felt like too much indirection. > >> I'm not sure about changing it to 1s as it may lead to complaints from macOS users with programs that monitor directories with a large number of files. The right thing is of course to include a native implementation for that platform, some day :-) > > Changed to 2s interval between subsequent polls since there have been a few concerns about this :-). I also agree that a native implementation would be far superior. I think it would be cleaner to have both constants declared at the top in PollingWatchService. They are in the same nest so accessibility should not be an issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Wed May 4 17:13:33 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 4 May 2022 17:13:33 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v8] In-Reply-To: References: Message-ID: > PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. > > This PR makes the following changes: > - Sets the initial interval to 1 second regardless of the period. > - Change the default period to 1 second. > > All tests in `test/jdk/java/nio/file/WatchService` passing. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Move polling initial delay to top of WatchService class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8479/files - new: https://git.openjdk.java.net/jdk/pull/8479/files/6328307a..717dfaca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8479&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8479&range=06-07 Stats: 5 lines in 1 file changed: 2 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8479/head:pull/8479 PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Wed May 4 17:18:27 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 4 May 2022 17:18:27 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v4] In-Reply-To: References: Message-ID: <_Aq-ZIg0shynbqZXKHUDw9Uwo_MQgusWnBb05D05mJo=.9f81878f-9a12-4037-8c08-2dfe8e37de17@github.com> On Wed, 4 May 2022 16:54:51 GMT, Alan Bateman wrote: >>> Can you move this up to the top of the file so it's with DEFAULT_POLLING_INTERVAL? I thin both will need a short one line comment. >> >> The constants are used in different objects, so I'm not sure there is a sensible way to to do this. A constant reference to a private object might be a way, but that felt like too much indirection. >> >>> I'm not sure about changing it to 1s as it may lead to complaints from macOS users with programs that monitor directories with a large number of files. The right thing is of course to include a native implementation for that platform, some day :-) >> >> Changed to 2s interval between subsequent polls since there have been a few concerns about this :-). I also agree that a native implementation would be far superior. > > I think it would be cleaner to have both constants declared at the top in PollingWatchService. They are in the same nest so accessibility should not be an issue. My mistake. I was thinking of them as two totally separate classes. I have made this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From duke at openjdk.java.net Wed May 4 17:59:31 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 4 May 2022 17:59:31 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v8] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 17:13:33 GMT, Tyler Steele wrote: >> PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. >> >> This PR makes the following changes: >> - Sets the initial interval to 1 second regardless of the period. >> - Change the default period to 1 second. >> >> All tests in `test/jdk/java/nio/file/WatchService` passing. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Move polling initial delay to top of WatchService class Testing complete. We are (again) ready to... ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From bpb at openjdk.java.net Wed May 4 21:07:14 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 4 May 2022 21:07:14 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v9] In-Reply-To: References: Message-ID: > Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8057113: Remove superfluous new Object[] statements from test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8066/files - new: https://git.openjdk.java.net/jdk/pull/8066/files/3d537a31..629d9916 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8066&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8066&range=07-08 Stats: 41 lines in 1 file changed: 0 ins; 0 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/8066.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8066/head:pull/8066 PR: https://git.openjdk.java.net/jdk/pull/8066 From mcimadamore at openjdk.java.net Wed May 4 23:24:29 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 4 May 2022 23:24:29 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 16:47:28 GMT, ExE Boss wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: >> >> - Merge branch 'master' into foreign-preview >> - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Tweak support for Linker lookup >> Improve javadoc of SymbolLookup >> - Tweak Addressable javadoc >> - Downcall and upcall tests use wrong layout which is missing some trailing padding >> - Simplify libraryLookup impl >> - Address CSR comments >> - Merge branch 'master' into foreign-preview >> - Add ValueLayout changes >> - Tweak support for array element var handle >> - ... and 47 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...41d055ab > > src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 153: > >> 151: static SymbolLookup loaderLookup() { >> 152: Class caller = Reflection.getCallerClass(); >> 153: ClassLoader loader = Objects.requireNonNull(caller.getClassLoader()); > > Shouldn?t?this be?changed to?throw `IllegalCallerException` instead?of?throwing `NullPointerException` when?the?`caller`?s `ClassLoader` is?`null`[^1] or?when `caller`?itself is?`null`[^2]? > > [^1]: This?happens when?`caller` is?on the?bootstrap?classpath. > [^2]: This?happens when `SymbolLookup.loaderLookup()` is?called by?native?code and?no?**Java**?code is?on?the?call?stack. Good points. Regarding `ClassLoader` being null, I think we can still return something using the `BootLoader`'s `NativeLibraries` object - that would allow this method to be called internally. @mlchung Can you please confirm? As for the caller sensitive having no real caller (e.g. because method is called directly from native code), I think we should add a check in `Reflection::ensureNativeAccess`. Few weeks ago I verified that adding such a check does not compromise upcall stub created via the Linker interface (e.g. a Java upcall might require to perform restricted operations - but those operation always happen inside the upcall MH, which is always associated with some class). ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Wed May 4 23:30:35 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 4 May 2022 23:30:35 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v38] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Tweak examples in SymbolLookup javadoc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/41d055ab..853f06b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=37 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=36-37 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Wed May 4 23:32:49 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 4 May 2022 23:32:49 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 23:20:21 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 153: >> >>> 151: static SymbolLookup loaderLookup() { >>> 152: Class caller = Reflection.getCallerClass(); >>> 153: ClassLoader loader = Objects.requireNonNull(caller.getClassLoader()); >> >> Shouldn?t?this be?changed to?throw `IllegalCallerException` instead?of?throwing `NullPointerException` when?the?`caller`?s `ClassLoader` is?`null`[^1] or?when `caller`?itself is?`null`[^2]? >> >> [^1]: This?happens when?`caller` is?on the?bootstrap?classpath. >> [^2]: This?happens when `SymbolLookup.loaderLookup()` is?called by?native?code and?no?**Java**?code is?on?the?call?stack. > > Good points. Regarding `ClassLoader` being null, I think we can still return something using the `BootLoader`'s `NativeLibraries` object - that would allow this method to be called internally. @mlchung Can you please confirm? > > As for the caller sensitive having no real caller (e.g. because method is called directly from native code), I think we should add a check in `Reflection::ensureNativeAccess`. Few weeks ago I verified that adding such a check does not compromise upcall stub created via the Linker interface (e.g. a Java upcall might require to perform restricted operations - but those operation always happen inside the upcall MH, which is always associated with some class). Another option would be to treat calls to `ensureNativeAccess` with `null` caller class as coming from unnamed module. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Wed May 4 23:47:30 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 4 May 2022 23:47:30 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 23:29:53 GMT, Maurizio Cimadamore wrote: >> Good points. Regarding `ClassLoader` being null, I think we can still return something using the `BootLoader`'s `NativeLibraries` object - that would allow this method to be called internally. @mlchung Can you please confirm? >> >> As for the caller sensitive having no real caller (e.g. because method is called directly from native code), I think we should add a check in `Reflection::ensureNativeAccess`. Few weeks ago I verified that adding such a check does not compromise upcall stub created via the Linker interface (e.g. a Java upcall might require to perform restricted operations - but those operation always happen inside the upcall MH, which is always associated with some class). > > Another option would be to treat calls to `ensureNativeAccess` with `null` caller class as coming from unnamed module. Looking deeper, `System::loadLibrary` seems to search the boot loader libraries when invoked with a `null` caller class, so replicating that behavior should be safe. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From duke at openjdk.java.net Thu May 5 04:08:26 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Thu, 5 May 2022 04:08:26 GMT Subject: Integrated: 8285956: (fs) Excessive default poll interval in PollingWatchService In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 00:14:29 GMT, Tyler Steele wrote: > PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. > > This PR makes the following changes: > - Sets the initial interval to 1 second regardless of the period. > - Change the default period to 1 second. > > All tests in `test/jdk/java/nio/file/WatchService` passing. This pull request has now been integrated. Changeset: 1bb4de2e Author: Tyler Steele Committer: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/1bb4de2e2868a539846ec48dd43fd623c2ba69a5 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod 8285956: (fs) Excessive default poll interval in PollingWatchService Reviewed-by: stuefe, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From alanb at openjdk.java.net Thu May 5 05:36:26 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 5 May 2022 05:36:26 GMT Subject: RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v8] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 17:13:33 GMT, Tyler Steele wrote: >> PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance. >> >> This PR makes the following changes: >> - Sets the initial interval to 1 second regardless of the period. >> - Change the default period to 1 second. >> >> All tests in `test/jdk/java/nio/file/WatchService` passing. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Move polling initial delay to top of WatchService class src/java.base/share/classes/sun/nio/fs/PollingWatchService.java line 66: > 64: // Wait between polling thread creation and first poll (seconds) > 65: private static final int POLLING_INIT_DELAY = 1; > 66: // Default time between polls (seconds) Thanks for more the constant. You can insert a blank line between them to make it easier to distinguish and also to keep it consistent with the existing code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8479 From mchung at openjdk.java.net Thu May 5 16:26:37 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 5 May 2022 16:26:37 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 23:44:08 GMT, Maurizio Cimadamore wrote: >> Another option would be to treat calls to `ensureNativeAccess` with `null` caller class as coming from unnamed module. > > Looking deeper, `System::loadLibrary` seems to search the boot loader libraries when invoked with a `null` caller class, so replicating that behavior should be safe. `BootLoader` is what you want in this case - it defines the static methods to access resources, packages etc defined to the boot loader (aka null `ClassLoader`). To find a symbol defined in the native libraries loaded by the boot loader, you can call `BootLoader.getNativeLibraries().find(name)`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mchung at openjdk.java.net Thu May 5 16:42:25 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 5 May 2022 16:42:25 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 16:22:41 GMT, Mandy Chung wrote: >> Looking deeper, `System::loadLibrary` seems to search the boot loader libraries when invoked with a `null` caller class, so replicating that behavior should be safe. > > `BootLoader` is what you want in this case - it defines the static methods to access resources, packages etc defined to the boot loader (aka null `ClassLoader`). > > To find a symbol defined in the native libraries loaded by the boot loader, you can call `BootLoader.getNativeLibraries().find(name)`. When a caller-sensitive method is invoked from a thread attached via JNI, the caller class returned from `Reflection::getCallerClass` is `null`. I would recommend the default to be a class in the unnamed module defined to the system class loader; hence it defaults to the system class loader. This is consistent with JNI `FindClass` when invoked with no caller frame. It's an open issue [1] to revisit the default for `System::load` and `System::loadLibrary` when invoked with null caller class. However, the existing behavior may likely be unchanged because of the compatibility risk. [1] https://bugs.openjdk.java.net/browse/JDK-8281001 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Thu May 5 20:54:53 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 5 May 2022 20:54:53 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v39] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI * Tweak restricted method check to work when there's no caller class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/853f06b8..4d24ffa9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=38 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=37-38 Stats: 22 lines in 2 files changed: 16 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Thu May 5 20:54:55 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 5 May 2022 20:54:55 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: <-zAvw8aE9e94OWQyDLUT3IqPzKJFT3v0x_HQVJObonc=.3370a3b7-e797-439f-8a72-ff6d3ec59be4@github.com> On Thu, 5 May 2022 16:39:08 GMT, Mandy Chung wrote: >> `BootLoader` is what you want in this case - it defines the static methods to access resources, packages etc defined to the boot loader (aka null `ClassLoader`). >> >> To find a symbol defined in the native libraries loaded by the boot loader, you can call `BootLoader.getNativeLibraries().find(name)`. > > When a caller-sensitive method is invoked from a thread attached via JNI, the caller class returned from `Reflection::getCallerClass` is `null`. I would recommend the default to be a class in the unnamed module defined to the system class loader; hence it defaults to the system class loader. This is consistent with JNI `FindClass` when invoked with no caller frame. > > It's an open issue [1] to revisit the default for `System::load` and `System::loadLibrary` when invoked with null caller class. However, the existing behavior may likely be unchanged because of the compatibility risk. > > [1] https://bugs.openjdk.java.net/browse/JDK-8281001 Thanks for the comments. I've pushed a new change which fixes a couple of thing: * first, for `SymbolLookup.loaderLookup`, the system class loader is used when no caller class exists (e.g. when method is called from JNI). If caller class exist but its loader is null (boot loader), we just call ClassLoader::findNative with a `null` loader which will do the right thing (thanks @mlchung for the tips!) * second, the restricted method check in `Reflection::ensureNativeAccess` has been improved to also work in case where caller class is `null`. In such cases, a dummy unnamed module module is used for the check. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mchung at openjdk.java.net Thu May 5 21:34:54 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 5 May 2022 21:34:54 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v39] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 20:54:53 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI > * Tweak restricted method check to work when there's no caller class src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 161: > 159: ClassLoader.getSystemClassLoader(); > 160: MemorySession loaderSession = (loader == null) ? > 161: MemorySession.global() : // boot loader never goes away The other built-in class loaders (`ClassLoaders::appClassLoader` and `ClassLoaders::platformClassLoader` are both instance of `BuiltinClassLoader`) will never be unloaded. Should they use the globel memory session? src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 120: > 118: // if there is no caller class, act as if the call came from an unnamed module > 119: Module module = currentClass != null ? > 120: currentClass.getModule() : Holder.FALLBACK_MODULE; This can be simplified to: Module module = currentClass != null ? currentClass.getModule() : ClassLoader::getSystemClassLoader().getUnnamedModule(); No need to have the Holder class. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From bpb at openjdk.java.net Thu May 5 22:25:52 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 5 May 2022 22:25:52 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v9] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 21:07:14 GMT, Brian Burkhalter wrote: >> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8057113: Remove superfluous new Object[] statements from test The CSR has been updated to reflect the recent revisions of the extension method specifications. ------------- PR: https://git.openjdk.java.net/jdk/pull/8066 From mbaesken at openjdk.java.net Fri May 6 07:36:48 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 6 May 2022 07:36:48 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 09:08:28 GMT, Matthias Baesken wrote: > Does this mean that not setting _WIN32_WINNT means :any API is allowed" ? Hi David , I did one more try with my current setup (VS2017 on a Win10 notebook). I did not set _WIN32_WINNT. My little test program #include #include int main() { #ifdef _WIN32_WINNT printf("_WIN32_WINNT is defined .\n"); #if (_WIN32_WINNT == 0x0600) printf("Vista API setting\n"); #endif #if (_WIN32_WINNT == 0x0601) printf("Win 7 API setting\n"); #endif #if (_WIN32_WINNT == 0x0602) printf("Win 8 API setting\n"); #endif #if (_WIN32_WINNT == 0x0603) printf("Win 8.1 API setting\n"); #endif #if (_WIN32_WINNT == 0x0A00) printf("Win 10 API setting\n"); #endif #endif return 0; } shows me _WIN32_WINNT is defined . Win 10 API setting So I think with our current compilers in use like VS2017 / VS2019 we allow Win10 APIs in most of our code except a few places where we set _WIN32_WINNT and go back to some mixture of older APIs. Not sure if this is a good thing, we could break for example Win 8.1/Win2012 compatibility easily this way. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mcimadamore at openjdk.java.net Fri May 6 08:44:18 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 6 May 2022 08:44:18 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v39] In-Reply-To: References: Message-ID: <388ApXPEDmJfjzRtAEJc2ZgunCC8d6gbBkCsPg5hTlU=.22af8084-2ae4-487b-b6b2-d6c6d9410429@github.com> On Thu, 5 May 2022 21:28:32 GMT, Mandy Chung wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI >> * Tweak restricted method check to work when there's no caller class > > src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 161: > >> 159: ClassLoader.getSystemClassLoader(); >> 160: MemorySession loaderSession = (loader == null) ? >> 161: MemorySession.global() : // boot loader never goes away > > The other built-in class loaders (`ClassLoaders::appClassLoader` and `ClassLoaders::platformClassLoader` are both instance of `BuiltinClassLoader`) will never be unloaded. Should they use the globel memory session? good idea > src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 120: > >> 118: // if there is no caller class, act as if the call came from an unnamed module >> 119: Module module = currentClass != null ? >> 120: currentClass.getModule() : Holder.FALLBACK_MODULE; > > This can be simplified to: > > Module module = currentClass != null ? > currentClass.getModule() : ClassLoader::getSystemClassLoader().getUnnamedModule(); > > > No need to have the Holder class. gah! I missed that :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From dholmes at openjdk.java.net Fri May 6 09:52:47 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 6 May 2022 09:52:47 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup This seems okay to me in this form. I agree that explicitly setting this is better than unknowingly using API's that might not be available on supported platforms. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Fri May 6 09:57:47 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 6 May 2022 09:57:47 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Hi David, thanks for the review ! ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From lancea at openjdk.java.net Fri May 6 10:43:48 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 6 May 2022 10:43:48 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v9] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 21:07:14 GMT, Brian Burkhalter wrote: >> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8057113: Remove superfluous new Object[] statements from test Hi Brian, Looking good overall. Please see the comments below regarding the test test/jdk/java/nio/file/Path/Extensions.java line 38: > 36: * @run testng Extensions > 37: */ > 38: public class Extensions { Can you add a test to exercise the change you made to ZipFS->ZipPath test/jdk/java/nio/file/Path/Extensions.java line 95: > 93: {"video.mp4", of("mp4")}, > 94: {"document.txt", of("txt")}, > 95: }; Should we add a x.zip, y.gzip, and z.jar given they are common? ------------- PR: https://git.openjdk.java.net/jdk/pull/8066 From mcimadamore at openjdk.java.net Fri May 6 11:51:46 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 6 May 2022 11:51:46 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v40] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Add tests for loaderLookup/restricted method corner cases ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/4d24ffa9..b71c4e93 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=39 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=38-39 Stats: 248 lines in 10 files changed: 239 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Fri May 6 11:51:46 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 6 May 2022 11:51:46 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v39] In-Reply-To: <388ApXPEDmJfjzRtAEJc2ZgunCC8d6gbBkCsPg5hTlU=.22af8084-2ae4-487b-b6b2-d6c6d9410429@github.com> References: <388ApXPEDmJfjzRtAEJc2ZgunCC8d6gbBkCsPg5hTlU=.22af8084-2ae4-487b-b6b2-d6c6d9410429@github.com> Message-ID: On Fri, 6 May 2022 08:42:12 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 120: >> >>> 118: // if there is no caller class, act as if the call came from an unnamed module >>> 119: Module module = currentClass != null ? >>> 120: currentClass.getModule() : Holder.FALLBACK_MODULE; >> >> This can be simplified to: >> >> Module module = currentClass != null ? >> currentClass.getModule() : ClassLoader::getSystemClassLoader().getUnnamedModule(); >> >> >> No need to have the Holder class. > > gah! I missed that :-) I've addressed these comments (thanks!) and also added some tests for these corner cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From erikj at openjdk.java.net Fri May 6 12:47:41 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 6 May 2022 12:47:41 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: <5t5qsNQ4XMMB_1ACFCDIKGj1BxBnsmAAq5d4C5z3yQU=.c1c2bb90-57dc-4754-a2cd-56b0e5d58843@github.com> On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From ihse at openjdk.java.net Fri May 6 14:38:50 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 6 May 2022 14:38:50 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Looks good, thanks for doing this cleanup. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8428 From duke at openjdk.java.net Fri May 6 16:00:59 2022 From: duke at openjdk.java.net (ExE Boss) Date: Fri, 6 May 2022 16:00:59 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v40] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 11:51:46 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add tests for loaderLookup/restricted method corner cases src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 116: > 114: // if there is no caller class, act as if the call came from unnamed module of system class loader > 115: Module module = currentClass != null ? > 116: currentClass.getModule() : ClassLoader.getSystemClassLoader().getUnnamedModule(); **Nit:** maybe?add a?line?break Suggestion: currentClass.getModule() : ClassLoader.getSystemClassLoader().getUnnamedModule(); ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Fri May 6 16:48:11 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 6 May 2022 16:48:11 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v41] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/b71c4e93..f823bf84 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=40 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=39-40 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mchung at openjdk.java.net Fri May 6 16:55:12 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 6 May 2022 16:55:12 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v41] In-Reply-To: References: Message-ID: <0liX9cVSEjplWxVgGoM5rN2JZLqN27jSsNxjbucze_o=.fbc3a8fa-acdf-45f4-a717-0fbaa13760d2@github.com> On Fri, 6 May 2022 16:48:11 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Mon May 9 08:26:35 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 9 May 2022 08:26:35 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v42] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits: - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Add tests for loaderLookup/restricted method corner cases - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI * Tweak restricted method check to work when there's no caller class - Tweak examples in SymbolLookup javadoc - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Tweak support for Linker lookup Improve javadoc of SymbolLookup - Tweak Addressable javadoc - Downcall and upcall tests use wrong layout which is missing some trailing padding - ... and 52 more: https://git.openjdk.java.net/jdk/compare/39f4434f...3c88a2ef ------------- Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=41 Stats: 65712 lines in 373 files changed: 43721 ins; 19432 del; 2559 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Mon May 9 17:41:10 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 9 May 2022 17:41:10 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v43] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix crashes in heap segment benchmarks due to misaligned access ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/3c88a2ef..7b774297 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=42 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=41-42 Stats: 41 lines in 2 files changed: 3 ins; 4 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From prr at openjdk.java.net Mon May 9 18:06:54 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 18:06:54 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: <4TPEAEob1ukdLvqdnzddoOBEGrsVfkaQEG5-307Mxjw=.130e42ef-8170-4dcf-bce5-3b69615a6c2a@github.com> On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From duke at openjdk.java.net Mon May 9 18:17:00 2022 From: duke at openjdk.java.net (ExE Boss) Date: Mon, 9 May 2022 18:17:00 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v43] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 17:41:10 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix crashes in heap segment benchmarks due to misaligned access test/micro/org/openjdk/bench/java/lang/foreign/LoopOverPollutedSegments.java line 69: > 67: static final ValueLayout.OfInt JAVA_INT_UNALIGNED = JAVA_INT.withBitAlignment(8); > 68: static final ValueLayout.OfFloat JAVA_FLOAT_UNALIGNED = JAVA_FLOAT.withBitAlignment(8); > 69: static final VarHandle intHandleUnaligned = JAVA_INT_UNALIGNED.arrayElementVarHandle(); To?match `LoopOverNonConstantHeap`, this?should?probably be?named `VH_INT_UNALIGNED`. -------------------------------------------------------------------------------- Maybe?these could?also be?moved?into `org.openjdk.bench.java.lang.foreign.Utils`[^1] [^1]: https://github.com/openjdk/jdk/blob/7b774297b1d04e104a988ea5bd2f2b04c8de3461/test/micro/org/openjdk/bench/java/lang/foreign/Utils.java#L29-L43 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Mon May 9 20:30:09 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 9 May 2022 20:30:09 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v43] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 18:09:51 GMT, ExE Boss wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix crashes in heap segment benchmarks due to misaligned access > > test/micro/org/openjdk/bench/java/lang/foreign/LoopOverPollutedSegments.java line 69: > >> 67: static final ValueLayout.OfInt JAVA_INT_UNALIGNED = JAVA_INT.withBitAlignment(8); >> 68: static final ValueLayout.OfFloat JAVA_FLOAT_UNALIGNED = JAVA_FLOAT.withBitAlignment(8); >> 69: static final VarHandle intHandleUnaligned = JAVA_INT_UNALIGNED.arrayElementVarHandle(); > > To?match `LoopOverNonConstantHeap`, this?should?probably be?named `VH_INT_UNALIGNED`. > > -------------------------------------------------------------------------------- > > Maybe?these could?also be?moved?into `org.openjdk.bench.java.lang.foreign.Utils`[^1] > > [^1]: https://github.com/openjdk/jdk/blob/7b774297b1d04e104a988ea5bd2f2b04c8de3461/test/micro/org/openjdk/bench/java/lang/foreign/Utils.java#L29-L43 I noted other possible cleanups for benchmarks, I'll work on something after we integrate this PR as I'd like to minimize the churn. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From clanger at openjdk.java.net Mon May 9 22:18:11 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 9 May 2022 22:18:11 GMT Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to find root cause Message-ID: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com> After https://bugs.openjdk.java.net/browse/JDK-8251329, javac throws errors when the classpath contains jar files with . or .. in its name. The error message, however, does not help to find the culprit. This could be improved. ------------- Commit messages: - JDK-8286444 Changes: https://git.openjdk.java.net/jdk/pull/8616/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8616&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286444 Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8616.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8616/head:pull/8616 PR: https://git.openjdk.java.net/jdk/pull/8616 From clanger at openjdk.java.net Mon May 9 22:36:51 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 9 May 2022 22:36:51 GMT Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to find root cause In-Reply-To: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com> References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com> Message-ID: On Mon, 9 May 2022 22:10:54 GMT, Christoph Langer wrote: > After https://bugs.openjdk.java.net/browse/JDK-8251329, javac throws errors when the classpath > contains jar files with . or .. in its name. The error message, however, does not help to find > the culprit. This could be improved. @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch? ------------- PR: https://git.openjdk.java.net/jdk/pull/8616 From alanb at openjdk.java.net Tue May 10 05:46:40 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 10 May 2022 05:46:40 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Tue May 10 06:48:40 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 10 May 2022 06:48:40 GMT Subject: Integrated: JDK-8285730: unify _WIN32_WINNT settings In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken wrote: > Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : > https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt > Macros for Conditional Declarations > "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." > > However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). This pull request has now been integrated. Changeset: 4fd79a6a Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/4fd79a6ad2683e4863bd4e311cb01cbc30ebf57f Stats: 33 lines in 7 files changed: 2 ins; 25 del; 6 mod 8285730: unify _WIN32_WINNT settings Reviewed-by: dholmes, erikj, ihse, prr, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From shade at openjdk.java.net Tue May 10 12:10:28 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 10 May 2022 12:10:28 GMT Subject: RFR: 8286473: Drop --enable-preview from Record related tests Message-ID: There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. Additional testing: - [x] Linux x86_64 fastdebug, affected tests still pass - [x] Linux x86_32 fastdebug, affected tests start to pass ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/8626/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8626&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286473 Stats: 28 lines in 3 files changed: 0 ins; 24 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8626.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8626/head:pull/8626 PR: https://git.openjdk.java.net/jdk/pull/8626 From jpai at openjdk.java.net Tue May 10 12:29:44 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 10 May 2022 12:29:44 GMT Subject: RFR: 8286473: Drop --enable-preview from Record related tests In-Reply-To: References: Message-ID: On Tue, 10 May 2022 12:03:09 GMT, Aleksey Shipilev wrote: > There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected tests still pass > - [x] Linux x86_32 fastdebug, affected tests start to pass Hello Aleksey, the `unreflect` test package has just one test and that one uses the `record` feature. So removing the `TEST.properties` for that entire package looks fine. The changes to the other 2 tests look fine too, since like you note, they are just `record` related tests and don't have any other preview feature being tested. I think these two tests would need a copyright year update. ------------- PR: https://git.openjdk.java.net/jdk/pull/8626 From mdoerr at openjdk.java.net Tue May 10 13:55:55 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 10 May 2022 13:55:55 GMT Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to find root cause In-Reply-To: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com> References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com> Message-ID: On Mon, 9 May 2022 22:10:54 GMT, Christoph Langer wrote: > After https://bugs.openjdk.java.net/browse/JDK-8251329, javac throws errors when the classpath > contains jar files with . or .. in its name. The error message, however, does not help to find > the culprit. This could be improved. LGTM. I think this is an important improvement. Developers should not be left alone figuring out which .jar file is responsible for the problem. There is currently no hint at all without this change. (Note: Pre-submit test issues on 32 bit are unrelated.) ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8616 From alanb at openjdk.java.net Tue May 10 14:05:49 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 10 May 2022 14:05:49 GMT Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to find root cause In-Reply-To: References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com> Message-ID: On Mon, 9 May 2022 22:32:57 GMT, Christoph Langer wrote: > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch? It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for that in the String representation). ------------- PR: https://git.openjdk.java.net/jdk/pull/8616 From alanb at openjdk.java.net Tue May 10 14:46:50 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 10 May 2022 14:46:50 GMT Subject: RFR: 8286473: Drop --enable-preview from Record related tests In-Reply-To: References: Message-ID: On Tue, 10 May 2022 12:03:09 GMT, Aleksey Shipilev wrote: > There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected tests still pass > - [x] Linux x86_32 fastdebug, affected tests start to pass test/jdk/java/nio/Buffer/BulkPutBuffer.java line 57: > 55: * @run testng/othervm BulkPutBuffer > 56: */ > 57: public class BulkPutBuffer { You can drop the -source option from these tests too. ------------- PR: https://git.openjdk.java.net/jdk/pull/8626 From shade at openjdk.java.net Tue May 10 14:54:39 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 10 May 2022 14:54:39 GMT Subject: RFR: 8286473: Drop --enable-preview from Record related tests [v2] In-Reply-To: References: Message-ID: > There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected tests still pass > - [x] Linux x86_32 fastdebug, affected tests start to pass Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8626/files - new: https://git.openjdk.java.net/jdk/pull/8626/files/d5f0b1be..626e673a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8626&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8626&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8626.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8626/head:pull/8626 PR: https://git.openjdk.java.net/jdk/pull/8626 From alanb at openjdk.java.net Tue May 10 14:54:40 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 10 May 2022 14:54:40 GMT Subject: RFR: 8286473: Drop --enable-preview from Record related tests [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 14:51:52 GMT, Aleksey Shipilev wrote: >> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug, affected tests still pass >> - [x] Linux x86_32 fastdebug, affected tests start to pass > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8626 From shade at openjdk.java.net Tue May 10 14:54:40 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 10 May 2022 14:54:40 GMT Subject: RFR: 8286473: Drop --enable-preview from Record related tests [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 14:43:06 GMT, Alan Bateman wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > test/jdk/java/nio/Buffer/BulkPutBuffer.java line 57: > >> 55: * @run testng/othervm BulkPutBuffer >> 56: */ >> 57: public class BulkPutBuffer { > > You can drop the -source option from these tests too. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8626 From jpai at openjdk.java.net Tue May 10 15:00:04 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 10 May 2022 15:00:04 GMT Subject: RFR: 8286473: Drop --enable-preview from Record related tests [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 14:54:39 GMT, Aleksey Shipilev wrote: >> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug, affected tests still pass >> - [x] Linux x86_32 fastdebug, affected tests start to pass > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Marked as reviewed by jpai (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8626 From mchung at openjdk.java.net Tue May 10 16:24:41 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 10 May 2022 16:24:41 GMT Subject: RFR: 8286473: Drop --enable-preview from Record related tests [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 14:54:39 GMT, Aleksey Shipilev wrote: >> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug, affected tests still pass >> - [x] Linux x86_32 fastdebug, affected tests start to pass > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8626 From lancea at openjdk.java.net Tue May 10 16:32:43 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 10 May 2022 16:32:43 GMT Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to find root cause In-Reply-To: References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com> Message-ID: On Tue, 10 May 2022 14:02:14 GMT, Alan Bateman wrote: > > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch? > > It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation). I think this would be OK, but would get to get someone from our security team to bless it. It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes ------------- PR: https://git.openjdk.java.net/jdk/pull/8616 From clanger at openjdk.java.net Tue May 10 16:51:37 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 10 May 2022 16:51:37 GMT Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to find root cause In-Reply-To: References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com> Message-ID: <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com> On Tue, 10 May 2022 16:30:01 GMT, Lance Andersen wrote: > > > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch? > > > > > > It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation). > > I think this would be OK, but would get to get someone from our security team to bless it. > > It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes Sounds fair. @LanceAndersen, can you please ask the security team about their ok then and let me know? In case their answer is a yes, I'll work on implementing the suggestion to return the name as String. Shall I maybe do the zipfs change in a different PR then? The more important change in the context of javac is printing out the jar name in javac itself. ------------- PR: https://git.openjdk.java.net/jdk/pull/8616 From alanb at openjdk.java.net Tue May 10 16:54:54 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 10 May 2022 16:54:54 GMT Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to find root cause In-Reply-To: <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com> References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com> <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com> Message-ID: <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com> On Tue, 10 May 2022 16:48:30 GMT, Christoph Langer wrote: > I think this would be OK, but would get to get someone from our security team to bless it. It's print the entry name, I don't think it is leaking the file path to the zip file. ------------- PR: https://git.openjdk.java.net/jdk/pull/8616 From lancea at openjdk.java.net Tue May 10 17:02:47 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 10 May 2022 17:02:47 GMT Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to find root cause In-Reply-To: <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com> References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com> <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com> <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com> Message-ID: On Tue, 10 May 2022 16:51:35 GMT, Alan Bateman wrote: > > I think this would be OK, but would get to get someone from our security team to bless it. > > It's print the entry name, I don't think it is leaking the file path to the zip file. I think you are probably right I am probably being overly cautious ------------- PR: https://git.openjdk.java.net/jdk/pull/8616 From lancea at openjdk.java.net Tue May 10 17:02:47 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 10 May 2022 17:02:47 GMT Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to find root cause In-Reply-To: References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com> Message-ID: On Tue, 10 May 2022 16:30:01 GMT, Lance Andersen wrote: >>> @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch? >> >> It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation). > >> > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch? >> >> It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation). > > I think this would be OK, but would get to get someone from our security team to bless it. > > It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes > > > > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch? > > > > > > > > > It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation). > > > > > > I think this would be OK, but would get to get someone from our security team to bless it. > > It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes > > Sounds fair. @LanceAndersen, can you please ask the security team about their ok then and let me know? In case their answer is a yes, I'll work on implementing the suggestion to return the name as String. Shall I maybe do the zipfs change in a different PR then? The more important change in the context of javac is printing out the jar name in javac itself. Already did ;-) so hopefully they will share their thoughts soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/8616 From lancea at openjdk.java.net Tue May 10 17:02:48 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 10 May 2022 17:02:48 GMT Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to find root cause In-Reply-To: References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com> <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com> <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com> Message-ID: <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com> On Tue, 10 May 2022 16:58:03 GMT, Lance Andersen wrote: >>> I think this would be OK, but would get to get someone from our security team to bless it. >> >> It's print the entry name, I don't think it is leaking the file path to the zip file. > >> > I think this would be OK, but would get to get someone from our security team to bless it. >> >> It's print the entry name, I don't think it is leaking the file path to the zip file. > > I think you are probably right I am probably being overly cautious > > > > > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch? > > > > > > > > > > > > It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation). > > > > > > > > > I think this would be OK, but would get to get someone from our security team to bless it. > > > It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes > > > > > > Sounds fair. @LanceAndersen, can you please ask the security team about their ok then and let me know? In case their answer is a yes, I'll work on implementing the suggestion to return the name as String. Shall I maybe do the zipfs change in a different PR then? The more important change in the context of javac is printing out the jar name in javac itself. > > Already did ;-) so hopefully they will share their thoughts soon. I think it would probably be good for a separate PR for the ZipFS change as it keeps it a bit clearer ------------- PR: https://git.openjdk.java.net/jdk/pull/8616 From mullan at openjdk.java.net Tue May 10 21:30:02 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 10 May 2022 21:30:02 GMT Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to find root cause In-Reply-To: <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com> References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com> <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com> <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com> <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com> Message-ID: On Tue, 10 May 2022 16:59:41 GMT, Lance Andersen wrote: > > > > > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch? > > > > > > > > > > > > It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation). > > > > > > > > > I think this would be OK, but would get to get someone from our security team to bless it. > > > It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes > > > > > > Sounds fair. @LanceAndersen, can you please ask the security team about their ok then and let me know? In case their answer is a yes, I'll work on implementing the suggestion to return the name as String. Shall I maybe do the zipfs change in a different PR then? The more important change in the context of javac is printing out the jar name in javac itself. > > Already did ;-) so hopefully they will share their thoughts soon. It's probably ok, but the bug report is either incomplete or I am missing something. It says "This can be improved to something like: ..." but the same text as is emitted now is used. Can you fix this so I have a better example of what will be included in the message? ------------- PR: https://git.openjdk.java.net/jdk/pull/8616 From mullan at openjdk.java.net Tue May 10 21:33:50 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 10 May 2022 21:33:50 GMT Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to find root cause In-Reply-To: References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com> <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com> <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com> <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com> Message-ID: On Tue, 10 May 2022 21:26:42 GMT, Sean Mullan wrote: > It's probably ok, but the bug report is either incomplete or I am missing something. It says "This can be improved to something like: ..." but the same text as is emitted now is used. Can you fix this so I have a better example of what will be included in the message? The bug report also says "The error message does not give a clue which jar file is causing the problem" but the error message includes the name "invalid.jar" so I am also confused about that. ------------- PR: https://git.openjdk.java.net/jdk/pull/8616 From rriggs at openjdk.java.net Tue May 10 21:38:19 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 10 May 2022 21:38:19 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base Message-ID: PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions >From the CSR: "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." This PR anticipates the warnings and adds explicit casts to replace the implicit casts. In most cases, the cast matches the type of the right-hand side to type of the compound assignment. Since these casts are truncating the value, there might be a different refactoring that avoids the cast but a direct replacement was chosen here. (Advise and suggestions will inform similar updates to other OpenJDK modules). ------------- Commit messages: - 8286378: Address possibly lossy conversions in java.base Changes: https://git.openjdk.java.net/jdk/pull/8642/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286378 Stats: 57 lines in 33 files changed: 1 ins; 3 del; 53 mod Patch: https://git.openjdk.java.net/jdk/pull/8642.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8642/head:pull/8642 PR: https://git.openjdk.java.net/jdk/pull/8642 From naoto at openjdk.java.net Tue May 10 22:02:49 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 10 May 2022 22:02:49 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base In-Reply-To: References: Message-ID: On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs wrote: > PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions > From the CSR: > > "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." > > This PR anticipates the warnings and adds explicit casts to replace the implicit casts. > In most cases, the cast matches the type of the right-hand side to type of the compound assignment. > Since these casts are truncating the value, there might be a different refactoring that avoids the cast > but a direct replacement was chosen here. > > (Advise and suggestions will inform similar updates to other OpenJDK modules). Looks good. Assuming copyright years will be updated. src/java.base/share/classes/java/time/es line 1: > 1: X Looks like a random file was added by accident? ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8642 From xuelei at openjdk.java.net Tue May 10 22:16:47 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 10 May 2022 22:16:47 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base In-Reply-To: References: Message-ID: <7lDCcjqL3nlin4_E8rebEkaoQ96_Tz2jbarFVJVF3PY=.88a6da8e-6f79-4889-88f3-4248037609e1@github.com> On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs wrote: > PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions > From the CSR: > > "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." > > This PR anticipates the warnings and adds explicit casts to replace the implicit casts. > In most cases, the cast matches the type of the right-hand side to type of the compound assignment. > Since these casts are truncating the value, there might be a different refactoring that avoids the cast > but a direct replacement was chosen here. > > (Advise and suggestions will inform similar updates to other OpenJDK modules). The update in security area looks good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8642 From bpb at openjdk.java.net Tue May 10 22:57:49 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 10 May 2022 22:57:49 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base In-Reply-To: References: Message-ID: <7I3Y3hwAO8Sirtab0JkW7SPyjqZlDAhGciKVD47qXOE=.22ddd9bd-1491-4b39-94ed-de1977181c1f@github.com> On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs wrote: > PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions > From the CSR: > > "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." > > This PR anticipates the warnings and adds explicit casts to replace the implicit casts. > In most cases, the cast matches the type of the right-hand side to type of the compound assignment. > Since these casts are truncating the value, there might be a different refactoring that avoids the cast > but a direct replacement was chosen here. > > (Advise and suggestions will inform similar updates to other OpenJDK modules). IO, math, and NIO changes look fine. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8642 From rriggs at openjdk.java.net Tue May 10 23:01:33 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 10 May 2022 23:01:33 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v2] In-Reply-To: References: Message-ID: > PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions > From the CSR: > > "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." > > This PR anticipates the warnings and adds explicit casts to replace the implicit casts. > In most cases, the cast matches the type of the right-hand side to type of the compound assignment. > Since these casts are truncating the value, there might be a different refactoring that avoids the cast > but a direct replacement was chosen here. > > (Advise and suggestions will inform similar updates to other OpenJDK modules). Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: remove stray file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8642/files - new: https://git.openjdk.java.net/jdk/pull/8642/files/e72ce85c..7ff806a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8642.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8642/head:pull/8642 PR: https://git.openjdk.java.net/jdk/pull/8642 From bpb at openjdk.java.net Tue May 10 23:12:19 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 10 May 2022 23:12:19 GMT Subject: RFR: 8274113: (fc) Tune FileChannel.transferFrom() Message-ID: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> This request proposes to change `FileChannel.transferFrom()` to add a fast path on Linux and a threshold for mapped transfers on all platforms. ------------- Commit messages: - 8274113: (fc) Tune FileChannel.transferFrom() Changes: https://git.openjdk.java.net/jdk/pull/8644/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8644&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274113 Stats: 130 lines in 4 files changed: 117 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8644.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8644/head:pull/8644 PR: https://git.openjdk.java.net/jdk/pull/8644 From bpb at openjdk.java.net Tue May 10 23:12:20 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 10 May 2022 23:12:20 GMT Subject: RFR: 8274113: (fc) Tune FileChannel.transferFrom() In-Reply-To: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> References: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> Message-ID: On Tue, 10 May 2022 23:05:19 GMT, Brian Burkhalter wrote: > This request proposes to change `FileChannel.transferFrom()` to add a fast path on Linux and a threshold for mapped transfers on all platforms. To `transferFrom()` a direct transfer path is added by the method `transferFromDirectly()` for the case where the source `ReadableByteChannel` is a `FileChannel`. If a native fast transfer function is available, then it will be used for the transfer between `FileChannel`s. Currently the only such platform function is `copy_file_range()` on Linux. If no such function is available, this path will be attempted only once. This direct path was measured to improve throughput by from 25% to 300%. A threshold is added for all platforms such that a mapped transfer is attempted only when the number of bytes to transfer is greater than the threshold. Below this threshold a read-write copy is performed. The test `Transfers.java` is modified *not* to require that `transferFrom()` return a value equal to its `count` parameter which is not required by the specification: ```Fewer than the requested number of bytes will be transferred [...]``` Instead, `transferFrom()` is called in a loop until the cumulative number of bytes equals the expected value or an error occurs. ------------- PR: https://git.openjdk.java.net/jdk/pull/8644 From bpb at openjdk.java.net Tue May 10 23:32:42 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 10 May 2022 23:32:42 GMT Subject: RFR: 8274113: (fc) Tune FileChannel.transferFrom() [v2] In-Reply-To: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> References: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> Message-ID: <9unAfEurB5qYFqBRl_5_QXRwJMt8vU6kpA9UN9IFy6w=.e05f7afd-1823-4414-9220-8e8fdeab260f@github.com> > This request proposes to change `FileChannel.transferFrom()` to add a fast path on Linux and a threshold for mapped transfers on all platforms. Brian Burkhalter 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: 8274113: (fc) Tune FileChannel.transferFrom() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8644/files - new: https://git.openjdk.java.net/jdk/pull/8644/files/4ea9b945..df436ab8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8644&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8644&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8644.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8644/head:pull/8644 PR: https://git.openjdk.java.net/jdk/pull/8644 From alanb at openjdk.java.net Wed May 11 05:26:39 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 May 2022 05:26:39 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 23:01:33 GMT, Roger Riggs wrote: >> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions >> From the CSR: >> >> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." >> >> This PR anticipates the warnings and adds explicit casts to replace the implicit casts. >> In most cases, the cast matches the type of the right-hand side to type of the compound assignment. >> Since these casts are truncating the value, there might be a different refactoring that avoids the cast >> but a direct replacement was chosen here. >> >> (Advise and suggestions will inform similar updates to other OpenJDK modules). > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > remove stray file src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128: > 126: // timed poll interrupted so need to adjust timeout > 127: long adjust = System.nanoTime() - startTime; > 128: to -= (int)TimeUnit.MILLISECONDS.convert(adjust, TimeUnit.NANOSECONDS); Can we change this `to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);` while we here? src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java line 615: > 613: if (outputStackTop >= elements) { > 614: outputStackTop -= (short)elements; > 615: } else { I think we usually try to avoid changing the ASM code if possible but maybe you have to do this because the compiler option is used for compiling java.base? src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java line 123: > 121: // timed poll interrupted so need to adjust timeout > 122: long adjust = System.nanoTime() - startTime; > 123: to -= (int)TimeUnit.MILLISECONDS.convert(adjust, TimeUnit.NANOSECONDS); This one can also be changed to: `to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);` ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From alanb at openjdk.java.net Wed May 11 05:42:36 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 May 2022 05:42:36 GMT Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to find root cause In-Reply-To: References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com> <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com> <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com> <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com> Message-ID: On Tue, 10 May 2022 21:30:23 GMT, Sean Mullan wrote: > > It's probably ok, but the bug report is either incomplete or I am missing something. It says "This can be improved to something like: ..." but the same text as is emitted now is used. Can you fix this so I have a better example of what will be included in the message? > > The bug report also says "The error message does not give a clue which jar file is causing the problem" but the error message includes the name "invalid.jar" so I am also confused about that. There are two parts to it. In the case of initCEN method, the proposed change is to include the name of the rejected entry in the exception message. This is not the same thing as leaking a file path in the exception message so I don't think we have a concern here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8616 From asotona at openjdk.java.net Wed May 11 08:06:39 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Wed, 11 May 2022 08:06:39 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 23:01:33 GMT, Roger Riggs wrote: >> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions >> From the CSR: >> >> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." >> >> This PR anticipates the warnings and adds explicit casts to replace the implicit casts. >> In most cases, the cast matches the type of the right-hand side to type of the compound assignment. >> Since these casts are truncating the value, there might be a different refactoring that avoids the cast >> but a direct replacement was chosen here. >> >> (Advise and suggestions will inform similar updates to other OpenJDK modules). > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > remove stray file I can confirm this patch clears all warnings from java.base. ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From shade at openjdk.java.net Wed May 11 08:55:46 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 May 2022 08:55:46 GMT Subject: RFR: 8286473: Drop --enable-preview from Record related tests [v2] In-Reply-To: References: Message-ID: <0We5XaRjaSzPrgkyx6CIQwDrxDuNMQZdrT3BSdAHhpk=.2fe2351c-68ee-4bca-a980-4e563b2a6b6e@github.com> On Tue, 10 May 2022 14:54:39 GMT, Aleksey Shipilev wrote: >> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug, affected tests still pass >> - [x] Linux x86_32 fastdebug, affected tests start to pass > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Thanks for reviews. I see GHA are mostly clean, with the usual x86_32 failures. ------------- PR: https://git.openjdk.java.net/jdk/pull/8626 From shade at openjdk.java.net Wed May 11 08:55:47 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 May 2022 08:55:47 GMT Subject: Integrated: 8286473: Drop --enable-preview from Record related tests In-Reply-To: References: Message-ID: On Tue, 10 May 2022 12:03:09 GMT, Aleksey Shipilev wrote: > There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected tests still pass > - [x] Linux x86_32 fastdebug, affected tests start to pass This pull request has now been integrated. Changeset: 73c5e993 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/73c5e993e17f7435553edae79a1e8d70ece5493d Stats: 30 lines in 3 files changed: 0 ins; 24 del; 6 mod 8286473: Drop --enable-preview from Record related tests Reviewed-by: alanb, jpai, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/8626 From mcimadamore at openjdk.java.net Wed May 11 10:39:44 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 11 May 2022 10:39:44 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v44] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits: - Merge branch 'master' into foreign-preview - Fix crashes in heap segment benchmarks due to misaligned access - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Add tests for loaderLookup/restricted method corner cases - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI * Tweak restricted method check to work when there's no caller class - Tweak examples in SymbolLookup javadoc - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Tweak support for Linker lookup Improve javadoc of SymbolLookup - ... and 54 more: https://git.openjdk.java.net/jdk/compare/73c5e993...cdd006e7 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=43 Stats: 65711 lines in 373 files changed: 43720 ins; 19432 del; 2559 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From alanb at openjdk.java.net Wed May 11 13:01:46 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 May 2022 13:01:46 GMT Subject: RFR: 8274113: (fc) Tune FileChannel.transferFrom() [v2] In-Reply-To: <9unAfEurB5qYFqBRl_5_QXRwJMt8vU6kpA9UN9IFy6w=.e05f7afd-1823-4414-9220-8e8fdeab260f@github.com> References: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> <9unAfEurB5qYFqBRl_5_QXRwJMt8vU6kpA9UN9IFy6w=.e05f7afd-1823-4414-9220-8e8fdeab260f@github.com> Message-ID: On Tue, 10 May 2022 23:32:42 GMT, Brian Burkhalter wrote: >> This request proposes to change `FileChannel.transferFrom()` to add a fast path on Linux and a threshold for mapped transfers on all platforms. > > Brian Burkhalter 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: > > 8274113: (fc) Tune FileChannel.transferFrom() src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 541: > 539: // set this to false if we find out later that it doesn't > 540: // > 541: private static volatile boolean transferToSupported = true; At some point we need to invert these to transferXXXNotSupported so that the default is false rather true, maybe we should do it as part of this PR because all usages are changed anyway? src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 66: > 64: { > 65: jlong pageSize = sysconf(_SC_PAGESIZE); > 66: chan_fd = (*env)->GetFieldID(env, clazz, "fd", "Ljava/io/FileDescriptor;"); At some point we need to remove chan_fd, instead map0 should provide the fd. ------------- PR: https://git.openjdk.java.net/jdk/pull/8644 From alanb at openjdk.java.net Wed May 11 13:10:48 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 May 2022 13:10:48 GMT Subject: RFR: 8274113: (fc) Tune FileChannel.transferFrom() [v2] In-Reply-To: <9unAfEurB5qYFqBRl_5_QXRwJMt8vU6kpA9UN9IFy6w=.e05f7afd-1823-4414-9220-8e8fdeab260f@github.com> References: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> <9unAfEurB5qYFqBRl_5_QXRwJMt8vU6kpA9UN9IFy6w=.e05f7afd-1823-4414-9220-8e8fdeab260f@github.com> Message-ID: <4lEMhHyb7zlRtqtADSlH-_nLQHLpz_8c2H19_Gln83s=.99c2cccf-8ed4-47a4-b201-05c7dedc159a@github.com> On Tue, 10 May 2022 23:32:42 GMT, Brian Burkhalter wrote: >> This request proposes to change `FileChannel.transferFrom()` to add a fast path on Linux and a threshold for mapped transfers on all platforms. > > Brian Burkhalter 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: > > 8274113: (fc) Tune FileChannel.transferFrom() Overall I think this looks good. It would be useful to add some performance data to the PR to demonstrate the improvement. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8644 From mullan at openjdk.java.net Wed May 11 14:15:46 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 11 May 2022 14:15:46 GMT Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to find root cause In-Reply-To: References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com> <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com> <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com> <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com> Message-ID: On Wed, 11 May 2022 05:39:42 GMT, Alan Bateman wrote: > > > It's probably ok, but the bug report is either incomplete or I am missing something. It says "This can be improved to something like: ..." but the same text as is emitted now is used. Can you fix this so I have a better example of what will be included in the message? > > > > > > The bug report also says "The error message does not give a clue which jar file is causing the problem" but the error message includes the name "invalid.jar" so I am also confused about that. > > There are two parts to it. In the case of initCEN method, the proposed change is to include the name of the rejected entry in the exception message. This is not the same thing as leaking a file path in the exception message so I don't think we have a concern here. Ok, but @RealCLanger can you address the prior comments I had on the bug report? The error messages (before and after the fix) are the same. ------------- PR: https://git.openjdk.java.net/jdk/pull/8616 From redestad at openjdk.java.net Wed May 11 15:04:21 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 May 2022 15:04:21 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks Message-ID: #8599 would add a new warning. This address the conversions in the microbenchmark component by means of making the types precise or adding explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but the real change is in the template as these are generated. I've run through a subset of the affected benchmarks and verified that the results are either neutral or improve somewhat (seem to be the case in a few of the ByteBuffer micros). ------------- Commit messages: - 8286401: Address possibly lossy conversions in Microbenchmarks Changes: https://git.openjdk.java.net/jdk/pull/8654/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8654&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286401 Stats: 166 lines in 12 files changed: 0 ins; 0 del; 166 mod Patch: https://git.openjdk.java.net/jdk/pull/8654.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8654/head:pull/8654 PR: https://git.openjdk.java.net/jdk/pull/8654 From shade at openjdk.java.net Wed May 11 15:26:45 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 May 2022 15:26:45 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:57:16 GMT, Claes Redestad wrote: > #8599 would add a new warning. This address the conversions in the microbenchmark component by means of making the types precise or adding explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but the real change is in the template as these are generated. > > I've run through a subset of the affected benchmarks and verified that the results are either neutral or improve somewhat (seem to be the case in a few of the ByteBuffer micros). I have questions. Also, copyright dates are not consistently updated in affected files? test/micro/org/openjdk/bench/vm/compiler/PointerBenchmarkFlat.java line 151: > 149: int sum = 0; > 150: for (int i = 0 ; i < ELEM_SIZE ; i++) { > 151: sum += (int)ptr_ptr.get(i).address().toRawLongValue(); Here and later: `toRawLongValue` returns `long`, right? So why don't we change the accumulator and return value to `long`, like we do in other tests? ------------- PR: https://git.openjdk.java.net/jdk/pull/8654 From brian.burkhalter at oracle.com Wed May 11 15:35:57 2022 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 11 May 2022 15:35:57 +0000 Subject: Can JDK-8190546 be re-opened or "how do I delete a file ending with a space on Windows" In-Reply-To: References: Message-ID: Redirect discussion to nio-dev. Brian > On May 11, 2022, at 7:29 AM, Maxim Kartashev wrote: > > Win32 documentation [1] kind of discourages the use of space at the very > end of a file name. Based on that, JDK-8190546 (File.toPath() reject > directory names with trailing space) had been closed a long time ago. I > would like to poll the public on the matter of re-opening the bug. > > There isn't anything new that I can throw in support of allowing JDK to > work with such file names. But the old points can perhaps be re-visited. > AFAIU, the only reason to explicitly forbid that (see > WindowsPathParser.normalize()) was that the parsing is based on Windows > documentation like [1]. That documentation says the following: > "Do not end a file or directory name with a space or a period. Although the > underlying file system may support such names, the Windows shell and user > interface does not" > Indeed, it's hard or even impossible to create such a file using "normal" > windows GUI, but you can use that GUI to delete such a file. In Java, you > can't do either. Working in a cygwin terminal, you can fairly easily create > a file name ending with a space. And when you turn to your Java-based IDE > to delete it, you get an error from the very basic level of NIO that you > can't overrule, which seems to be quite unfortunate. > > If there's any interest in resolving this - or at least not enough > opposition to let it be resolved - I am willing to make the necessary > changes and open a PR. > > References > [1] > https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions > [2] https://bugs.openjdk.java.net/browse/JDK-8190546 From clanger at openjdk.java.net Wed May 11 15:39:11 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Wed, 11 May 2022 15:39:11 GMT Subject: RFR: 8286594: (zipfs) Improvements after JDK-8251329 Message-ID: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com> This augments the ZipException upon rejecting a Zip File containing entry names with "." or ".." elements. It furthermore tries to clean up & compact the logic for detecting "." and ".." and it adds a method IndexNode:nameAsString() to return the node name as a String. ------------- Commit messages: - JDK-8286594 Changes: https://git.openjdk.java.net/jdk/pull/8655/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8655&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286594 Stats: 73 lines in 1 file changed: 31 ins; 38 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8655.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8655/head:pull/8655 PR: https://git.openjdk.java.net/jdk/pull/8655 From redestad at openjdk.java.net Wed May 11 15:50:40 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 May 2022 15:50:40 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks [v2] In-Reply-To: References: Message-ID: > #8599 would add a new warning. This address the conversions in the microbenchmark component by means of making the types precise or adding explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but the real change is in the template as these are generated. > > I've run through a subset of the affected benchmarks and verified that the results are either neutral or improve somewhat (seem to be the case in a few of the ByteBuffer micros). Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Copyrights, consistently use the exact accumulator type ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8654/files - new: https://git.openjdk.java.net/jdk/pull/8654/files/5cba7820..41f37a25 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8654&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8654&range=00-01 Stats: 17 lines in 11 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/8654.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8654/head:pull/8654 PR: https://git.openjdk.java.net/jdk/pull/8654 From shade at openjdk.java.net Wed May 11 15:50:40 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 May 2022 15:50:40 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 15:47:29 GMT, Claes Redestad wrote: >> #8599 would add a new warning. This address the conversions in the microbenchmark component by means of making the types precise or adding explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but the real change is in the template as these are generated. >> >> I've run through a subset of the affected benchmarks and verified that the results are either neutral or improve somewhat (seem to be the case in a few of the ByteBuffer micros). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Copyrights, consistently use the exact accumulator type Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8654 From redestad at openjdk.java.net Wed May 11 15:50:41 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 May 2022 15:50:41 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 15:21:51 GMT, Aleksey Shipilev wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Copyrights, consistently use the exact accumulator type > > test/micro/org/openjdk/bench/vm/compiler/PointerBenchmarkFlat.java line 151: > >> 149: int sum = 0; >> 150: for (int i = 0 ; i < ELEM_SIZE ; i++) { >> 151: sum += (int)ptr_ptr.get(i).address().toRawLongValue(); > > Here and later: `toRawLongValue` returns `long`, right? So why don't we change the accumulator and return value to `long`, like we do in other tests? Yeah, let's be consistent. I have verified that this does not affect the raw scores of these benchmarks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8654 From redestad at openjdk.java.net Wed May 11 16:03:49 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 May 2022 16:03:49 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 15:50:40 GMT, Claes Redestad wrote: >> #8599 would add a new warning. This address the conversions in the microbenchmark component by means of making the types precise or adding explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but the real change is in the template as these are generated. >> >> I've run through a subset of the affected benchmarks and verified that the results are either neutral or improve somewhat (seem to be the case in a few of the ByteBuffer micros). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Copyrights, consistently use the exact accumulator type Thanks for reviewing. I'll let the GHA tests complete and integrate this tomorrow if all is clear. ------------- PR: https://git.openjdk.java.net/jdk/pull/8654 From mkartashev at openjdk.java.net Wed May 11 16:03:54 2022 From: mkartashev at openjdk.java.net (Maxim Kartashev) Date: Wed, 11 May 2022 16:03:54 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup This change seem to have made this group of declarations obsolete: `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link]( https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From ecaspole at openjdk.java.net Wed May 11 16:18:52 2022 From: ecaspole at openjdk.java.net (Eric Caspole) Date: Wed, 11 May 2022 16:18:52 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 15:50:40 GMT, Claes Redestad wrote: >> #8599 would add a new warning. This address the conversions in the microbenchmark component by means of making the types precise or adding explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but the real change is in the template as these are generated. >> >> I've run through a subset of the affected benchmarks and verified that the results are either neutral or improve somewhat (seem to be the case in a few of the ByteBuffer micros). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Copyrights, consistently use the exact accumulator type Looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/8654 From rriggs at openjdk.java.net Wed May 11 16:30:41 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 11 May 2022 16:30:41 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3] In-Reply-To: References: Message-ID: > PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions > From the CSR: > > "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." > > This PR anticipates the warnings and adds explicit casts to replace the implicit casts. > In most cases, the cast matches the type of the right-hand side to type of the compound assignment. > Since these casts are truncating the value, there might be a different refactoring that avoids the cast > but a direct replacement was chosen here. > > (Advise and suggestions will inform similar updates to other OpenJDK modules). Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Updated copyrights Fixed cast style to add a space after cast, (where consistent with file style) Improved code per review comments in PollSelectors. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8642/files - new: https://git.openjdk.java.net/jdk/pull/8642/files/7ff806a5..a6679ce7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=01-02 Stats: 41 lines in 24 files changed: 0 ins; 0 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/8642.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8642/head:pull/8642 PR: https://git.openjdk.java.net/jdk/pull/8642 From ecaspole at openjdk.java.net Wed May 11 16:38:51 2022 From: ecaspole at openjdk.java.net (Eric Caspole) Date: Wed, 11 May 2022 16:38:51 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks [v2] In-Reply-To: References: Message-ID: <6v98y-ilQDIQiWxh_Cq_tiKszBQS8GjJ0oPMlc8W_GI=.59ad3686-d1aa-4b0b-b742-33e83c7fb795@github.com> On Wed, 11 May 2022 15:50:40 GMT, Claes Redestad wrote: >> #8599 would add a new warning. This address the conversions in the microbenchmark component by means of making the types precise or adding explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but the real change is in the template as these are generated. >> >> I've run through a subset of the affected benchmarks and verified that the results are either neutral or improve somewhat (seem to be the case in a few of the ByteBuffer micros). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Copyrights, consistently use the exact accumulator type Looks good, thanks for fixing this. ------------- Marked as reviewed by ecaspole (Committer). PR: https://git.openjdk.java.net/jdk/pull/8654 From shade at openjdk.java.net Wed May 11 16:42:47 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 May 2022 16:42:47 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 16:00:42 GMT, Claes Redestad wrote: > Thanks for reviewing. I'll let the GHA tests complete and integrate this tomorrow if all is clear. I don't think GHA builds any microbenchmarks (because JMH is not enabled there), so there is no point to wait for those. ------------- PR: https://git.openjdk.java.net/jdk/pull/8654 From tsteele at openjdk.java.net Wed May 11 17:02:41 2022 From: tsteele at openjdk.java.net (Tyler Steele) Date: Wed, 11 May 2022 17:02:41 GMT Subject: RFR: 8286540: Build failure caused by missing DefaultPollProvider implementation on AIX Message-ID: This change provides a stub implementation of DefaultPollerProvider on AIX. This is a temporary measure to ensure AIX can still be built while work on a full implementation is under way. ------------- Commit messages: - Fix copyright base year - Adds stub impl for DefaultPollerProvider on AIX Changes: https://git.openjdk.java.net/jdk/pull/8658/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8658&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286540 Stats: 107 lines in 2 files changed: 107 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8658.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8658/head:pull/8658 PR: https://git.openjdk.java.net/jdk/pull/8658 From bpb at openjdk.java.net Wed May 11 17:08:04 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 11 May 2022 17:08:04 GMT Subject: RFR: 8286540: Build failure caused by missing DefaultPollProvider implementation on AIX In-Reply-To: References: Message-ID: On Wed, 11 May 2022 16:52:44 GMT, Tyler Steele wrote: > This change provides a stub implementation of DefaultPollerProvider on AIX. This is a temporary measure to ensure AIX can still be built while work on a full implementation is under way. src/java.base/aix/classes/sun/nio/ch/PollsetPoller.java line 42: > 40: int fdVal() { > 41: // Stub > 42: throw new RuntimeException("Unimplemented on AIX"); I think you'd do better with an [UnsupportedOperationException](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/UnsupportedOperationException.html). ------------- PR: https://git.openjdk.java.net/jdk/pull/8658 From bpb at openjdk.java.net Wed May 11 17:11:46 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 11 May 2022 17:11:46 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs wrote: >> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions >> From the CSR: >> >> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." >> >> This PR anticipates the warnings and adds explicit casts to replace the implicit casts. >> In most cases, the cast matches the type of the right-hand side to type of the compound assignment. >> Since these casts are truncating the value, there might be a different refactoring that avoids the cast >> but a direct replacement was chosen here. >> >> (Advise and suggestions will inform similar updates to other OpenJDK modules). > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyrights > Fixed cast style to add a space after cast, (where consistent with file style) > Improved code per review comments in PollSelectors. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From bpb at openjdk.java.net Wed May 11 17:16:42 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 11 May 2022 17:16:42 GMT Subject: RFR: 8274113: (fc) Tune FileChannel.transferFrom() [v2] In-Reply-To: References: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> <9unAfEurB5qYFqBRl_5_QXRwJMt8vU6kpA9UN9IFy6w=.e05f7afd-1823-4414-9220-8e8fdeab260f@github.com> Message-ID: On Wed, 11 May 2022 12:58:27 GMT, Alan Bateman wrote: >> Brian Burkhalter 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: >> >> 8274113: (fc) Tune FileChannel.transferFrom() > > src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 66: > >> 64: { >> 65: jlong pageSize = sysconf(_SC_PAGESIZE); >> 66: chan_fd = (*env)->GetFieldID(env, clazz, "fd", "Ljava/io/FileDescriptor;"); > > At some point we need to remove chan_fd, instead map0 should provide the fd. I do not understand exactly what is intended here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8644 From tsteele at openjdk.java.net Wed May 11 17:17:27 2022 From: tsteele at openjdk.java.net (Tyler Steele) Date: Wed, 11 May 2022 17:17:27 GMT Subject: RFR: 8286540: Build failure caused by missing DefaultPollProvider implementation on AIX [v2] In-Reply-To: References: Message-ID: > This change provides a stub implementation of DefaultPollerProvider on AIX. This is a temporary measure to ensure AIX can still be built while work on a full implementation is under way. Tyler Steele has updated the pull request incrementally with two additional commits since the last revision: - Readily removes spurious space from pollset poller - Replace RuntimeException with UnsupportedOperationException ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8658/files - new: https://git.openjdk.java.net/jdk/pull/8658/files/6f8ac6d1..64d6e706 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8658&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8658&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8658.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8658/head:pull/8658 PR: https://git.openjdk.java.net/jdk/pull/8658 From alanb at openjdk.java.net Wed May 11 17:17:27 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 May 2022 17:17:27 GMT Subject: RFR: 8286540: Build failure caused by missing DefaultPollProvider implementation on AIX [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 17:13:48 GMT, Tyler Steele wrote: >> This change provides a stub implementation of DefaultPollerProvider on AIX. This is a temporary measure to ensure AIX can still be built while work on a full implementation is under way. > > Tyler Steele has updated the pull request incrementally with two additional commits since the last revision: > > - Readily removes spurious space from pollset poller > - Replace RuntimeException with UnsupportedOperationException src/java.base/aix/classes/sun/nio/ch/PollsetPoller.java line 35: > 33: class PollsetPoller extends Poller { > 34: > 35: PollsetPoller (boolean read) throws IOException { You have a spurious space in "PollsetPoller (", otherwise looks okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/8658 From tsteele at openjdk.java.net Wed May 11 17:17:27 2022 From: tsteele at openjdk.java.net (Tyler Steele) Date: Wed, 11 May 2022 17:17:27 GMT Subject: RFR: 8286540: Build failure caused by missing DefaultPollProvider implementation on AIX [v2] In-Reply-To: References: Message-ID: <54M-jj7xa5aze5MTeTzqyrO_eHbk0lnMktmhoan1EVk=.11706b3b-3b60-4bb8-b5fc-9677b9c3be93@github.com> On Wed, 11 May 2022 17:10:14 GMT, Alan Bateman wrote: >> Tyler Steele has updated the pull request incrementally with two additional commits since the last revision: >> >> - Readily removes spurious space from pollset poller >> - Replace RuntimeException with UnsupportedOperationException > > src/java.base/aix/classes/sun/nio/ch/PollsetPoller.java line 35: > >> 33: class PollsetPoller extends Poller { >> 34: >> 35: PollsetPoller (boolean read) throws IOException { > > You have a spurious space in "PollsetPoller (", otherwise looks okay. Removed. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8658 From tsteele at openjdk.java.net Wed May 11 17:17:28 2022 From: tsteele at openjdk.java.net (Tyler Steele) Date: Wed, 11 May 2022 17:17:28 GMT Subject: RFR: 8286540: Build failure caused by missing DefaultPollProvider implementation on AIX [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 17:04:44 GMT, Brian Burkhalter wrote: >> Tyler Steele has updated the pull request incrementally with two additional commits since the last revision: >> >> - Readily removes spurious space from pollset poller >> - Replace RuntimeException with UnsupportedOperationException > > src/java.base/aix/classes/sun/nio/ch/PollsetPoller.java line 42: > >> 40: int fdVal() { >> 41: // Stub >> 42: throw new RuntimeException("Unimplemented on AIX"); > > I think you'd do better with an [UnsupportedOperationException](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/UnsupportedOperationException.html). Agreed. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8658 From bpb at openjdk.java.net Wed May 11 17:22:43 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 11 May 2022 17:22:43 GMT Subject: RFR: 8286540: Build failure caused by missing DefaultPollProvider implementation on AIX [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 17:17:27 GMT, Tyler Steele wrote: >> This change provides a stub implementation of DefaultPollerProvider on AIX. This is a temporary measure to ensure AIX can still be built while work on a full implementation is under way. > > Tyler Steele has updated the pull request incrementally with two additional commits since the last revision: > > - Readily removes spurious space from pollset poller > - Replace RuntimeException with UnsupportedOperationException +1 ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8658 From alanb at openjdk.java.net Wed May 11 17:22:44 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 May 2022 17:22:44 GMT Subject: RFR: 8286540: Build failure caused by missing DefaultPollProvider implementation on AIX [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 17:17:27 GMT, Tyler Steele wrote: >> This change provides a stub implementation of DefaultPollerProvider on AIX. This is a temporary measure to ensure AIX can still be built while work on a full implementation is under way. > > Tyler Steele has updated the pull request incrementally with two additional commits since the last revision: > > - Readily removes spurious space from pollset poller > - Replace RuntimeException with UnsupportedOperationException Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8658 From bpb at openjdk.java.net Wed May 11 17:24:38 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 11 May 2022 17:24:38 GMT Subject: RFR: 8274113: (fc) Tune FileChannel.transferFrom() [v3] In-Reply-To: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> References: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> Message-ID: > This request proposes to change `FileChannel.transferFrom()` to add a fast path on Linux and a threshold for mapped transfers on all platforms. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8274113: Invert transferXXXSupported ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8644/files - new: https://git.openjdk.java.net/jdk/pull/8644/files/df436ab8..6ec90b91 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8644&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8644&range=01-02 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8644.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8644/head:pull/8644 PR: https://git.openjdk.java.net/jdk/pull/8644 From bpb at openjdk.java.net Wed May 11 17:24:40 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 11 May 2022 17:24:40 GMT Subject: RFR: 8274113: (fc) Tune FileChannel.transferFrom() [v2] In-Reply-To: References: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> <9unAfEurB5qYFqBRl_5_QXRwJMt8vU6kpA9UN9IFy6w=.e05f7afd-1823-4414-9220-8e8fdeab260f@github.com> Message-ID: On Wed, 11 May 2022 12:56:40 GMT, Alan Bateman wrote: >> Brian Burkhalter 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: >> >> 8274113: (fc) Tune FileChannel.transferFrom() > > src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 541: > >> 539: // set this to false if we find out later that it doesn't >> 540: // >> 541: private static volatile boolean transferToSupported = true; > > At some point we need to invert these to transferXXXNotSupported so that the default is false rather true, maybe we should do it as part of this PR because all usages are changed anyway? Fixed in commit 6ec90b9116c88fdcc6fd64a7ba8ba30a4d32ca86. ------------- PR: https://git.openjdk.java.net/jdk/pull/8644 From bpb at openjdk.java.net Wed May 11 17:37:45 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 11 May 2022 17:37:45 GMT Subject: RFR: 8274113: (fc) Tune FileChannel.transferFrom() [v2] In-Reply-To: <4lEMhHyb7zlRtqtADSlH-_nLQHLpz_8c2H19_Gln83s=.99c2cccf-8ed4-47a4-b201-05c7dedc159a@github.com> References: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> <9unAfEurB5qYFqBRl_5_QXRwJMt8vU6kpA9UN9IFy6w=.e05f7afd-1823-4414-9220-8e8fdeab260f@github.com> <4lEMhHyb7zlRtqtADSlH-_nLQHLpz_8c2H19_Gln83s=.99c2cccf-8ed4-47a4-b201-05c7dedc159a@github.com> Message-ID: On Wed, 11 May 2022 13:07:21 GMT, Alan Bateman wrote: > Overall I think this looks good. It would be useful to add some performance data to the PR to demonstrate the improvement. Throughput on macOS showing the change due to the mapped transfer threshold: Before (mapped transfer) Benchmark (length) Mode Cnt Score Error Units TransferFrom.transferFrom 8000 thrpt 10 83171.694 ? 394.409 ops/s TransferFrom.transferFrom 12000 thrpt 10 78985.812 ? 405.395 ops/s TransferFrom.transferFrom 14000 thrpt 10 74194.782 ? 387.265 ops/s TransferFrom.transferFrom 16000 thrpt 10 74117.711 ? 301.495 ops/s TransferFrom.transferFrom 17000 thrpt 10 70074.672 ? 562.279 ops/s TransferFrom.transferFrom 18000 thrpt 10 69862.113 ? 348.783 ops/s TransferFrom.transferFrom 19000 thrpt 10 69742.800 ? 264.864 ops/s TransferFrom.transferFrom 20000 thrpt 10 69017.441 ? 208.591 ops/s TransferFrom.transferFrom 22000 thrpt 10 65326.088 ? 281.195 ops/s TransferFrom.transferFrom 24000 thrpt 10 64996.134 ? 254.554 ops/s After (read-write transfer up to 16K length) Benchmark (length) Mode Cnt Score Error Units TransferFrom.transferFrom 8000 thrpt 10 178033.028 ? 1048.081 ops/s TransferFrom.transferFrom 12000 thrpt 10 99595.963 ? 1044.993 ops/s TransferFrom.transferFrom 14000 thrpt 10 97869.683 ? 548.820 ops/s TransferFrom.transferFrom 16000 thrpt 10 94392.964 ? 827.057 ops/s TransferFrom.transferFrom 17000 thrpt 10 67670.339 ? 735.683 ops/s TransferFrom.transferFrom 18000 thrpt 10 68161.273 ? 384.360 ops/s TransferFrom.transferFrom 19000 thrpt 10 68453.820 ? 632.199 ops/s TransferFrom.transferFrom 20000 thrpt 10 68701.903 ? 1042.648 ops/s TransferFrom.transferFrom 22000 thrpt 10 65713.451 ? 497.990 ops/s TransferFrom.transferFrom 24000 thrpt 10 66525.251 ? 1017.672 ops/s The threshold could probably be a little higher but is left at 16K for consistency with `transferTo()`. Throughput on Linux showing the change due to direct transfer: Before (mapped transfer) Benchmark (length) Mode Cnt Score Error Units TransferFrom.transferFrom 16384 thrpt 5 95885.876 ? 1153.982 ops/s TransferFrom.transferFrom 131072 thrpt 5 30699.784 ? 653.334 ops/s TransferFrom.transferFrom 1000000 thrpt 5 6840.268 ? 162.586 ops/s After (copy_file_range()) Benchmark (length) Mode Cnt Score Error Units TransferFrom.transferFrom 16384 thrpt 5 236198.847 ? 2070.598 ops/s TransferFrom.transferFrom 131072 thrpt 5 59197.335 ? 1596.413 ops/s TransferFrom.transferFrom 1000000 thrpt 5 8135.444 ? 758.260 ops/s ------------- PR: https://git.openjdk.java.net/jdk/pull/8644 From tsteele at openjdk.java.net Wed May 11 18:53:54 2022 From: tsteele at openjdk.java.net (Tyler Steele) Date: Wed, 11 May 2022 18:53:54 GMT Subject: Integrated: 8286540: Build failure caused by missing DefaultPollerProvider implementation on AIX In-Reply-To: References: Message-ID: On Wed, 11 May 2022 16:52:44 GMT, Tyler Steele wrote: > This change provides a stub implementation of DefaultPollerProvider on AIX. This is a temporary measure to ensure AIX can still be built while work on a full implementation is under way. This pull request has now been integrated. Changeset: 46a775af Author: Tyler Steele Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/46a775af11bce4bc780b5f85e0cd2f648dee1d03 Stats: 107 lines in 2 files changed: 107 ins; 0 del; 0 mod 8286540: Build failure caused by missing DefaultPollerProvider implementation on AIX Reviewed-by: bpb, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8658 From alanb at openjdk.java.net Wed May 11 19:10:45 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 May 2022 19:10:45 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs wrote: >> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions >> From the CSR: >> >> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." >> >> This PR anticipates the warnings and adds explicit casts to replace the implicit casts. >> In most cases, the cast matches the type of the right-hand side to type of the compound assignment. >> Since these casts are truncating the value, there might be a different refactoring that avoids the cast >> but a direct replacement was chosen here. >> >> (Advise and suggestions will inform similar updates to other OpenJDK modules). > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyrights > Fixed cast style to add a space after cast, (where consistent with file style) > Improved code per review comments in PollSelectors. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From lancea at openjdk.java.net Wed May 11 19:23:50 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 11 May 2022 19:23:50 GMT Subject: RFR: 8286594: (zipfs) Improvements after JDK-8251329 In-Reply-To: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com> References: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com> Message-ID: <-CY8VrgET0umvXMyeB9s7y_b9qsON3_mTD5IDtHiuyU=.aeeb6720-a674-42c5-bd6a-be864d9e2021@github.com> On Wed, 11 May 2022 15:32:38 GMT, Christoph Langer wrote: > This augments the ZipException upon rejecting a Zip File containing entry names with "." or ".." elements. > > It furthermore tries to clean up & compact the logic for detecting "." and ".." and it adds a method IndexNode::nameAsString to return the node name as a String. Looks good Christoph. Thank you for separating this out from the other PR ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8655 From redestad at openjdk.java.net Wed May 11 20:54:50 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 May 2022 20:54:50 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 16:39:18 GMT, Aleksey Shipilev wrote: > > Thanks for reviewing. I'll let the GHA tests complete and integrate this tomorrow if all is clear. > > I don't think GHA builds any microbenchmarks (because JMH is not enabled there), so there is no point to wait for those. Good to know, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8654 From redestad at openjdk.java.net Wed May 11 20:54:53 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 May 2022 20:54:53 GMT Subject: Integrated: 8286401: Address possibly lossy conversions in Microbenchmarks In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:57:16 GMT, Claes Redestad wrote: > #8599 would add a new warning. This address the conversions in the microbenchmark component by means of making the types precise or adding explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but the real change is in the template as these are generated. > > I've run through a subset of the affected benchmarks and verified that the results are either neutral or improve somewhat (seem to be the case in a few of the ByteBuffer micros). This pull request has now been integrated. Changeset: 1586bf86 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/1586bf862b6faa6477630fad2e62b198771ad187 Stats: 179 lines in 13 files changed: 0 ins; 0 del; 179 mod 8286401: Address possibly lossy conversions in Microbenchmarks Reviewed-by: shade, ecaspole ------------- PR: https://git.openjdk.java.net/jdk/pull/8654 From dholmes at openjdk.java.net Thu May 12 04:28:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 May 2022 04:28:43 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 11 May 2022 16:00:32 GMT, Maxim Kartashev wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> adjust API level to Windows 8 for security.cpp and do some cleanup > > This change seem to have made this group of declarations obsolete: > `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link]( > https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself. @mkartashev all references to WINVER in the AWT code seem obsolete. Possibly most of the IS_WINxxx usages could also be replaced. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Thu May 12 07:31:50 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 12 May 2022 07:31:50 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 11 May 2022 16:00:32 GMT, Maxim Kartashev wrote: > This change seem to have made this group of declarations obsolete: `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link](https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself. Hi Maxim, no plans from me, so feel free to do further cleanups. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From alanb at openjdk.java.net Thu May 12 09:15:58 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 12 May 2022 09:15:58 GMT Subject: RFR: 8274113: (fc) Tune FileChannel.transferFrom() [v3] In-Reply-To: References: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> Message-ID: On Wed, 11 May 2022 17:24:38 GMT, Brian Burkhalter wrote: >> This request proposes to change `FileChannel.transferFrom()` to add a fast path on Linux and a threshold for mapped transfers on all platforms. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274113: Invert transferXXXSupported src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 541: > 539: // set this to true if we find out later that it doesn't > 540: // > 541: private static volatile boolean transferToNotSupported = false; The motive for inverting these flags was to avoid the volatile write, so you can drop "= false" from both flags now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8644 From alanb at openjdk.java.net Thu May 12 09:16:02 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 12 May 2022 09:16:02 GMT Subject: RFR: 8274113: (fc) Tune FileChannel.transferFrom() [v2] In-Reply-To: References: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> <9unAfEurB5qYFqBRl_5_QXRwJMt8vU6kpA9UN9IFy6w=.e05f7afd-1823-4414-9220-8e8fdeab260f@github.com> Message-ID: <2dYN0LECAHO2nKocgF0RO-sbjDKZXfk_WoOro9aFRIk=.a1faae5e-2548-48a1-bbdb-f7d3f882692a@github.com> On Wed, 11 May 2022 17:13:13 GMT, Brian Burkhalter wrote: >> src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 66: >> >>> 64: { >>> 65: jlong pageSize = sysconf(_SC_PAGESIZE); >>> 66: chan_fd = (*env)->GetFieldID(env, clazz, "fd", "Ljava/io/FileDescriptor;"); >> >> At some point we need to remove chan_fd, instead map0 should provide the fd. > > I do not understand exactly what is intended here. I'd like to see chan_fd removed. To do that would require changing map0 to take a file descriptor. For another PR of course. ------------- PR: https://git.openjdk.java.net/jdk/pull/8644 From mkartashev at openjdk.java.net Thu May 12 11:00:49 2022 From: mkartashev at openjdk.java.net (Maxim Kartashev) Date: Thu, 12 May 2022 11:00:49 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Thu, 12 May 2022 04:25:24 GMT, David Holmes wrote: >> This change seem to have made this group of declarations obsolete: >> `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link]( >> https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself. > > @mkartashev all references to WINVER in the AWT code seem obsolete. Possibly most of the IS_WINxxx usages could also be replaced. @dholmes-ora @MBaesken Thank you! Filed [JDK-8286634](https://bugs.openjdk.java.net/browse/JDK-8286634). ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From weijun at openjdk.java.net Thu May 12 14:18:59 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 12 May 2022 14:18:59 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: References: Message-ID: <_iORn6NU_sX0ffx8xSNHkigSlplyKN58kEJ7pIcxhUo=.79b191fd-edde-40d7-a28c-e6bc82a8e28a@github.com> On Thu, 10 Mar 2022 08:52:17 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8282662: Revert dubious changes in MethodType src/java.base/share/classes/sun/security/validator/EndEntityChecker.java line 119: > 117: // TLS key exchange algorithms requiring keyEncipherment key usage > 118: private static final Collection KU_SERVER_ENCRYPTION = > 119: Arrays.asList("RSA"); I understand that you haven't modified the `KU_SERVER_KEY_AGREEMENT` on line 122 because it has 4 elements. However, these 2 nearby lines using different styles look a little strange to me. Why restrict the number to 0, 1, and 2? If we have defined methods with up to 9 arguments, does that mean the new type is suitable for 9 elements? ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From mullan at openjdk.java.net Thu May 12 15:11:02 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 12 May 2022 15:11:02 GMT Subject: RFR: 8286594: (zipfs) Improvements after JDK-8251329 In-Reply-To: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com> References: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com> Message-ID: <_uQj3PWsPqeX42kZya_w-wVyE0Ir8LGVY1fVJdOx97o=.491ece42-760d-4644-82ba-54f220a518b8@github.com> On Wed, 11 May 2022 15:32:38 GMT, Christoph Langer wrote: > This augments the ZipException upon rejecting a Zip File containing entry names with "." or ".." elements. > > It furthermore tries to clean up & compact the logic for detecting "." and ".." and it adds a method IndexNode::nameAsString to return the node name as a String. A more descriptive title for the bug report would be helpful. ------------- PR: https://git.openjdk.java.net/jdk/pull/8655 From bpb at openjdk.java.net Thu May 12 15:40:50 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 May 2022 15:40:50 GMT Subject: RFR: 8274113: (fc) Tune FileChannel.transferFrom() [v4] In-Reply-To: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> References: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> Message-ID: > This request proposes to change `FileChannel.transferFrom()` to add a fast path on Linux and a threshold for mapped transfers on all platforms. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8274113: Remove volatile write of false to transferXXXNotSupported ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8644/files - new: https://git.openjdk.java.net/jdk/pull/8644/files/6ec90b91..1ebecd1d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8644&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8644&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8644.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8644/head:pull/8644 PR: https://git.openjdk.java.net/jdk/pull/8644 From bpb at openjdk.java.net Thu May 12 15:40:53 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 May 2022 15:40:53 GMT Subject: RFR: 8274113: (fc) Tune FileChannel.transferFrom() [v3] In-Reply-To: References: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> Message-ID: On Thu, 12 May 2022 09:12:17 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274113: Invert transferXXXSupported > > src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 541: > >> 539: // set this to true if we find out later that it doesn't >> 540: // >> 541: private static volatile boolean transferToNotSupported = false; > > The motive for inverting these flags was to avoid the volatile write, so you can drop "= false" from both flags now. Resolved by commit 1ebecd1d07ae6a30a24377df21dd69b364d69d80. ------------- PR: https://git.openjdk.java.net/jdk/pull/8644 From mcimadamore at openjdk.java.net Thu May 12 15:45:01 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 12 May 2022 15:45:01 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: - Merge branch 'master' into foreign-preview - Merge branch 'master' into foreign-preview - Fix crashes in heap segment benchmarks due to misaligned access - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Add tests for loaderLookup/restricted method corner cases - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI * Tweak restricted method check to work when there's no caller class - Tweak examples in SymbolLookup javadoc - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b ------------- Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=44 Stats: 65711 lines in 373 files changed: 43720 ins; 19432 del; 2559 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Thu May 12 15:51:00 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 12 May 2022 15:51:00 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 08:29:52 GMT, Guoxiong Li wrote: >>> Remind: please use the command `/jep JEP-424` [1] to mark this PR. >>> >>> [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep >> >> Question: I'm willing to try it out. If something goes wrong - would a `jep unneeded` be enough to "unstuck" this PR? > >> would a jep unneeded be enough to "unstuck" this PR? > > Yes if no bug. Conceptually, the `/jep unneeded` will behave as no jep command. @lgxbslgx - JEP has been targeted, but the JEP action seems to be blocking this - what should we do? ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From alanb at openjdk.java.net Thu May 12 16:07:01 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 12 May 2022 16:07:01 GMT Subject: RFR: 8274113: (fc) Tune FileChannel.transferFrom() [v4] In-Reply-To: References: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> Message-ID: On Thu, 12 May 2022 15:40:50 GMT, Brian Burkhalter wrote: >> This request proposes to change `FileChannel.transferFrom()` to add a fast path on Linux and a threshold for mapped transfers on all platforms. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274113: Remove volatile write of false to transferXXXNotSupported Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8644 From mcimadamore at openjdk.java.net Thu May 12 16:21:59 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 12 May 2022 16:21:59 GMT Subject: Integrated: 8282191: Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 This pull request has now been integrated. Changeset: 2c5d1362 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/2c5d136260fa717afa374db8b923b7c886d069b7 Stats: 65711 lines in 373 files changed: 43720 ins; 19432 del; 2559 mod 8282191: Implementation of Foreign Function & Memory API (Preview) Reviewed-by: erikj, jvernee, psandoz, dholmes, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From rriggs at openjdk.java.net Thu May 12 16:54:48 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 12 May 2022 16:54:48 GMT Subject: Integrated: 8286378: Address possibly lossy conversions in java.base In-Reply-To: References: Message-ID: On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs wrote: > PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions > From the CSR: > > "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." > > This PR anticipates the warnings and adds explicit casts to replace the implicit casts. > In most cases, the cast matches the type of the right-hand side to type of the compound assignment. > Since these casts are truncating the value, there might be a different refactoring that avoids the cast > but a direct replacement was chosen here. > > (Advise and suggestions will inform similar updates to other OpenJDK modules). This pull request has now been integrated. Changeset: 17c52789 Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/17c52789b79a4ccd65308f90c4e02c1732b206be Stats: 71 lines in 32 files changed: 0 ins; 3 del; 68 mod 8286378: Address possibly lossy conversions in java.base Reviewed-by: naoto, xuelei, bpb, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From bpb at openjdk.java.net Thu May 12 18:52:54 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 May 2022 18:52:54 GMT Subject: RFR: 8274113: (fc) Tune FileChannel.transferFrom() [v2] In-Reply-To: <2dYN0LECAHO2nKocgF0RO-sbjDKZXfk_WoOro9aFRIk=.a1faae5e-2548-48a1-bbdb-f7d3f882692a@github.com> References: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> <9unAfEurB5qYFqBRl_5_QXRwJMt8vU6kpA9UN9IFy6w=.e05f7afd-1823-4414-9220-8e8fdeab260f@github.com> <2dYN0LECAHO2nKocgF0RO-sbjDKZXfk_WoOro9aFRIk=.a1faae5e-2548-48a1-bbdb-f7d3f882692a@github.com> Message-ID: On Thu, 12 May 2022 09:13:41 GMT, Alan Bateman wrote: >> I do not understand exactly what is intended here. > > I'd like to see chan_fd removed. To do that would require changing map0 to take a file descriptor. For another PR of course. https://bugs.openjdk.java.net/browse/JDK-8286671 ------------- PR: https://git.openjdk.java.net/jdk/pull/8644 From bpb at openjdk.java.net Thu May 12 18:52:56 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 May 2022 18:52:56 GMT Subject: Integrated: 8274113: (fc) Tune FileChannel.transferFrom() In-Reply-To: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> References: <2PXACKKiP8dDx4xFthsDBM55ZbymjOc7nIADl_qnYZo=.a97ac22d-efbb-4cf5-92fe-e275fe2b1fbb@github.com> Message-ID: <07p-ElusdJbpC1tcJSLFS51BvbdE-f3PaJi_02js3D0=.3d41c230-f903-44db-b532-a437858ee90a@github.com> On Tue, 10 May 2022 23:05:19 GMT, Brian Burkhalter wrote: > This request proposes to change `FileChannel.transferFrom()` to add a fast path on Linux and a threshold for mapped transfers on all platforms. This pull request has now been integrated. Changeset: 986d87dc Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/986d87dcc0b5d23828d7390be0a61756be1aae6f Stats: 132 lines in 4 files changed: 117 ins; 0 del; 15 mod 8274113: (fc) Tune FileChannel.transferFrom() Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8644 From bpb at openjdk.java.net Thu May 12 19:23:05 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 May 2022 19:23:05 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows Message-ID: Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. ------------- Commit messages: - 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows Changes: https://git.openjdk.java.net/jdk/pull/8686/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8686&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286637 Stats: 75 lines in 2 files changed: 73 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8686.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8686/head:pull/8686 PR: https://git.openjdk.java.net/jdk/pull/8686 From uschindler at openjdk.java.net Thu May 12 20:25:55 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Thu, 12 May 2022 20:25:55 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows In-Reply-To: References: Message-ID: On Thu, 12 May 2022 19:15:23 GMT, Brian Burkhalter wrote: > Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. Marked as reviewed by uschindler (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From jvernee at openjdk.java.net Thu May 12 20:58:50 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 20:58:50 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows In-Reply-To: References: Message-ID: On Thu, 12 May 2022 19:15:23 GMT, Brian Burkhalter wrote: > Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. test/jdk/java/nio/channels/FileChannel/LargeMapTest.java line 25: > 23: > 24: import jdk.incubator.foreign.MemorySegment; > 25: import jdk.incubator.foreign.ResourceScope; Note that the JEP has just been integrated as well, so this package no longer exists. It should be `java.lang.foreign` now. `ResourceScope` was renamed to `MemorySession`, `newSharedScope` should now be `openShared`, and the test will need `@enablePreview` as well. (I think that's all that's needed) ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From bpb at openjdk.java.net Thu May 12 20:58:50 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 May 2022 20:58:50 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows In-Reply-To: References: Message-ID: On Thu, 12 May 2022 20:49:35 GMT, Jorn Vernee wrote: >> Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. > > test/jdk/java/nio/channels/FileChannel/LargeMapTest.java line 25: > >> 23: >> 24: import jdk.incubator.foreign.MemorySegment; >> 25: import jdk.incubator.foreign.ResourceScope; > > Note that the JEP has just been integrated as well, so this package no longer exists. It should be `java.lang.foreign` now. `ResourceScope` was renamed to `MemorySession`, `newSharedScope` should now be `openShared`, and the test will need `@enablePreview` as well. > > (I think that's all that's needed) Thanks: I was not current on that. ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From mcimadamore at openjdk.java.net Thu May 12 20:58:52 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 12 May 2022 20:58:52 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows In-Reply-To: References: Message-ID: On Thu, 12 May 2022 19:15:23 GMT, Brian Burkhalter wrote: > Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. test/jdk/java/nio/channels/FileChannel/LargeMapTest.java line 64: > 62: MemorySegment mappedMemorySegment = MemorySegment.mapFile(p, 0, > 63: p.toFile().length(), FileChannel.MapMode.READ_WRITE, > 64: ResourceScope.newSharedScope()); Note that I've integrated JEP 424. As a result, you will need to update this test in the following ways: * replace `jdk.incubator.foreign` with `java.lang.foreign` * add @enablePreview to the test * replace `ResourceScope` with `MemorySession` * the `map` method for segments has moved into `FileChannel`, for constistency In addition, I think it would be better to use `MemorySession.openImplicit()` as session/scope parameter, since we don't want to call close explicitly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From mcimadamore at openjdk.java.net Thu May 12 20:58:53 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 12 May 2022 20:58:53 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows In-Reply-To: References: Message-ID: On Thu, 12 May 2022 20:52:20 GMT, Maurizio Cimadamore wrote: >> Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. > > test/jdk/java/nio/channels/FileChannel/LargeMapTest.java line 64: > >> 62: MemorySegment mappedMemorySegment = MemorySegment.mapFile(p, 0, >> 63: p.toFile().length(), FileChannel.MapMode.READ_WRITE, >> 64: ResourceScope.newSharedScope()); > > Note that I've integrated JEP 424. As a result, you will need to update this test in the following ways: > > * replace `jdk.incubator.foreign` with `java.lang.foreign` > * add @enablePreview to the test > * replace `ResourceScope` with `MemorySession` > * the `map` method for segments has moved into `FileChannel`, for constistency > > In addition, I think it would be better to use `MemorySession.openImplicit()` as session/scope parameter, since we don't want to call close explicitly. Would it be worth running the test on all platforms, rather than on windows only? And should we test other size combinations and offsets? For instance, Windows has some tricky code to split size and offset of the mapping - the test in this PR checks that the size is split correctly, but it doesn't check the mapping offset (which the test sets to 0). Would be interesting perhaps to add a case which creates the mapping of a 8G file at offset 3G and then starts iterating. ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From clanger at openjdk.java.net Thu May 12 22:08:50 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 12 May 2022 22:08:50 GMT Subject: RFR: 8286594: (zipfs) Mention paths with dot elements in ZipException and cleanups In-Reply-To: <_uQj3PWsPqeX42kZya_w-wVyE0Ir8LGVY1fVJdOx97o=.491ece42-760d-4644-82ba-54f220a518b8@github.com> References: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com> <_uQj3PWsPqeX42kZya_w-wVyE0Ir8LGVY1fVJdOx97o=.491ece42-760d-4644-82ba-54f220a518b8@github.com> Message-ID: <7C-ClU-gLSbuuqyONkNC-Vrko3TQFb5nvAYxFXndzfM=.0ffd1c59-d271-4346-a1be-6b9212730e7c@github.com> On Thu, 12 May 2022 15:07:29 GMT, Sean Mullan wrote: > A more descriptive title for the bug report would be helpful. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8655 From bpb at openjdk.java.net Thu May 12 22:32:07 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 May 2022 22:32:07 GMT Subject: RFR: 8286677: [BACKOUT] (fc) Tune FileChannel.transferFrom() Message-ID: <5Z2AvcXny8elhBye8TFVaFG3f_Iv5gF_nUdQ7VPhkhI=.5eec7501-d337-4cbc-8f8f-3cd7d8068f8a@github.com> This reverts commit 986d87dcc0b5d23828d7390be0a61756be1aae6f. ------------- Commit messages: - 8286677: [BACKOUT] (fc) Tune FileChannel.transferFrom() Changes: https://git.openjdk.java.net/jdk/pull/8688/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8688&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286677 Stats: 132 lines in 4 files changed: 0 ins; 117 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8688.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8688/head:pull/8688 PR: https://git.openjdk.java.net/jdk/pull/8688 From dholmes at openjdk.java.net Thu May 12 22:34:00 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 May 2022 22:34:00 GMT Subject: RFR: 8286677: [BACKOUT] (fc) Tune FileChannel.transferFrom() In-Reply-To: <5Z2AvcXny8elhBye8TFVaFG3f_Iv5gF_nUdQ7VPhkhI=.5eec7501-d337-4cbc-8f8f-3cd7d8068f8a@github.com> References: <5Z2AvcXny8elhBye8TFVaFG3f_Iv5gF_nUdQ7VPhkhI=.5eec7501-d337-4cbc-8f8f-3cd7d8068f8a@github.com> Message-ID: <9hFH56Btwp7JAba4_sABfudrgdvQll7f3cfwJaaF3RM=.04069eb7-679d-4c8e-9064-25e7be35bf87@github.com> On Thu, 12 May 2022 22:13:39 GMT, Brian Burkhalter wrote: > This reverts commit 986d87dcc0b5d23828d7390be0a61756be1aae6f. This looks like an accurate backout of the changes. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8688 From mikael at openjdk.java.net Thu May 12 22:34:01 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 12 May 2022 22:34:01 GMT Subject: RFR: 8286677: [BACKOUT] (fc) Tune FileChannel.transferFrom() In-Reply-To: <5Z2AvcXny8elhBye8TFVaFG3f_Iv5gF_nUdQ7VPhkhI=.5eec7501-d337-4cbc-8f8f-3cd7d8068f8a@github.com> References: <5Z2AvcXny8elhBye8TFVaFG3f_Iv5gF_nUdQ7VPhkhI=.5eec7501-d337-4cbc-8f8f-3cd7d8068f8a@github.com> Message-ID: <1jDwv6rwD17YUxDRLK8Q8t3tSULq-13cTlX-0lc1l84=.d68c5997-7526-4e66-be02-d76a1f16064f@github.com> On Thu, 12 May 2022 22:13:39 GMT, Brian Burkhalter wrote: > This reverts commit 986d87dcc0b5d23828d7390be0a61756be1aae6f. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8688 From bpb at openjdk.java.net Thu May 12 22:40:42 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 May 2022 22:40:42 GMT Subject: Integrated: 8286677: [BACKOUT] (fc) Tune FileChannel.transferFrom() In-Reply-To: <5Z2AvcXny8elhBye8TFVaFG3f_Iv5gF_nUdQ7VPhkhI=.5eec7501-d337-4cbc-8f8f-3cd7d8068f8a@github.com> References: <5Z2AvcXny8elhBye8TFVaFG3f_Iv5gF_nUdQ7VPhkhI=.5eec7501-d337-4cbc-8f8f-3cd7d8068f8a@github.com> Message-ID: On Thu, 12 May 2022 22:13:39 GMT, Brian Burkhalter wrote: > This reverts commit 986d87dcc0b5d23828d7390be0a61756be1aae6f. This pull request has now been integrated. Changeset: 369611ea Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/369611ea3484d33707f89e306437405ce19ce328 Stats: 132 lines in 4 files changed: 0 ins; 117 del; 15 mod 8286677: [BACKOUT] (fc) Tune FileChannel.transferFrom() Reviewed-by: dholmes, mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/8688 From bpb at openjdk.java.net Thu May 12 23:27:30 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 May 2022 23:27:30 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v2] In-Reply-To: References: Message-ID: > Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. Brian Burkhalter 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 four additional commits since the last revision: - 8286671: Update test pursuant to JEP 424 integration - Merge - 8286637: Update test with try-with-resources and to print less - 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8686/files - new: https://git.openjdk.java.net/jdk/pull/8686/files/95f7a0ae..b5c3b0d9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8686&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8686&range=00-01 Stats: 977 lines in 30 files changed: 128 ins; 584 del; 265 mod Patch: https://git.openjdk.java.net/jdk/pull/8686.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8686/head:pull/8686 PR: https://git.openjdk.java.net/jdk/pull/8686 From bpb at openjdk.java.net Thu May 12 23:27:31 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 May 2022 23:27:31 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v2] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 20:51:07 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/channels/FileChannel/LargeMapTest.java line 25: >> >>> 23: >>> 24: import jdk.incubator.foreign.MemorySegment; >>> 25: import jdk.incubator.foreign.ResourceScope; >> >> Note that the JEP has just been integrated as well, so this package no longer exists. It should be `java.lang.foreign` now. `ResourceScope` was renamed to `MemorySession`, `newSharedScope` should now be `openShared`, and the test will need `@enablePreview` as well. >> >> (I think that's all that's needed) > > Thanks: I was not current on that. Fixed by commit b5c3b0d9c25d3fcdee88f3e4f2b36c26e0de3d17. ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From bpb at openjdk.java.net Thu May 12 23:27:31 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 May 2022 23:27:31 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v2] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 20:55:47 GMT, Maurizio Cimadamore wrote: >> test/jdk/java/nio/channels/FileChannel/LargeMapTest.java line 64: >> >>> 62: MemorySegment mappedMemorySegment = MemorySegment.mapFile(p, 0, >>> 63: p.toFile().length(), FileChannel.MapMode.READ_WRITE, >>> 64: ResourceScope.newSharedScope()); >> >> Note that I've integrated JEP 424. As a result, you will need to update this test in the following ways: >> >> * replace `jdk.incubator.foreign` with `java.lang.foreign` >> * add @enablePreview to the test >> * replace `ResourceScope` with `MemorySession` >> * the `map` method for segments has moved into `FileChannel`, for constistency >> >> In addition, I think it would be better to use `MemorySession.openImplicit()` as session/scope parameter, since we don't want to call close explicitly. > > Would it be worth running the test on all platforms, rather than on windows only? And should we test other size combinations and offsets? For instance, Windows has some tricky code to split size and offset of the mapping - the test in this PR checks that the size is split correctly, but it doesn't check the mapping offset (which the test sets to 0). > > Would be interesting perhaps to add a case which creates the mapping of a 8G file at offset 3G and then starts iterating. > Note that I've integrated JEP 424. As a result, you will need to update this test in the following ways: > > * replace `jdk.incubator.foreign` with `java.lang.foreign` > > * add @enablePreview to the test > > * replace `ResourceScope` with `MemorySession` > > * the `map` method for segments has moved into `FileChannel`, for constistency > > > In addition, I think it would be better to use `MemorySession.openImplicit()` as session/scope parameter, since we don't want to call close explicitly. Fixed by commit b5c3b0d9c25d3fcdee88f3e4f2b36c26e0de3d17. ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From bpb at openjdk.java.net Thu May 12 23:42:10 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 May 2022 23:42:10 GMT Subject: RFR: 8286671: (fc) Modify sun.nio.ch.FileChannelImpl.map0() to accept a FileDescriptor parameter Message-ID: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> Add a `FileDescriptor` as the first parameter of `map0()` and remove from the corresponding native code the use of `fd_chan`. ------------- Commit messages: - 8286671: (fc) Modify sun.nio.ch.FileChannelImpl.map0() to accept a FileDescriptor parameter Changes: https://git.openjdk.java.net/jdk/pull/8689/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8689&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286671 Stats: 14 lines in 3 files changed: 1 ins; 8 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8689.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8689/head:pull/8689 PR: https://git.openjdk.java.net/jdk/pull/8689 From duke at openjdk.java.net Fri May 13 04:44:38 2022 From: duke at openjdk.java.net (ExE Boss) Date: Fri, 13 May 2022 04:44:38 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs wrote: >> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions >> From the CSR: >> >> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." >> >> This PR anticipates the warnings and adds explicit casts to replace the implicit casts. >> In most cases, the cast matches the type of the right-hand side to type of the compound assignment. >> Since these casts are truncating the value, there might be a different refactoring that avoids the cast >> but a direct replacement was chosen here. >> >> (Advise and suggestions will inform similar updates to other OpenJDK modules). > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyrights > Fixed cast style to add a space after cast, (where consistent with file style) > Improved code per review comments in PollSelectors. src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128: > 126: // timed poll interrupted so need to adjust timeout > 127: long adjust = System.nanoTime() - startTime; > 128: to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust); This?will?now always?assign a?negative?number to?`to`. -------------------------------------------------------------------------------- `=-`?is?not a?compound?assignment, it?s?negation followed?by a?normal?assignment. ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From alanb at openjdk.java.net Fri May 13 05:56:40 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 13 May 2022 05:56:40 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 04:41:03 GMT, ExE Boss wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated copyrights >> Fixed cast style to add a space after cast, (where consistent with file style) >> Improved code per review comments in PollSelectors. > > src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128: > >> 126: // timed poll interrupted so need to adjust timeout >> 127: long adjust = System.nanoTime() - startTime; >> 128: to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust); > > This?will?now always?assign a?negative?number to?`to`. > > -------------------------------------------------------------------------------- > > `=-`?is?not a?compound?assignment, it?s?negation followed?by a?normal?assignment. Well spotted, I don't think that change was intentionally. ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From duke at openjdk.java.net Fri May 13 06:30:47 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 13 May 2022 06:30:47 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: <_iORn6NU_sX0ffx8xSNHkigSlplyKN58kEJ7pIcxhUo=.79b191fd-edde-40d7-a28c-e6bc82a8e28a@github.com> References: <_iORn6NU_sX0ffx8xSNHkigSlplyKN58kEJ7pIcxhUo=.79b191fd-edde-40d7-a28c-e6bc82a8e28a@github.com> Message-ID: On Thu, 12 May 2022 14:14:38 GMT, Weijun Wang wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282662: Revert dubious changes in MethodType > > src/java.base/share/classes/sun/security/validator/EndEntityChecker.java line 119: > >> 117: // TLS key exchange algorithms requiring keyEncipherment key usage >> 118: private static final Collection KU_SERVER_ENCRYPTION = >> 119: Arrays.asList("RSA"); > > I understand that you haven't modified the `KU_SERVER_KEY_AGREEMENT` on line 122 because it has 4 elements. However, these 2 nearby lines using different styles look a little strange to me. Why restrict the number to 0, 1, and 2? If we have defined methods with up to 9 arguments, does that mean the new type is suitable for 9 elements? The reason is that for the cases of length 0, 1, 2 we don't create underlying array as we do for larger number of elements. In other words when we replace `Arrays.asList()` with `List.of()` we win only for 0, 1 and 2 elements. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From jpai at openjdk.java.net Fri May 13 06:50:50 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 13 May 2022 06:50:50 GMT Subject: RFR: 8286671: (fc) Modify sun.nio.ch.FileChannelImpl.map0() to accept a FileDescriptor parameter In-Reply-To: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> References: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> Message-ID: On Thu, 12 May 2022 23:34:35 GMT, Brian Burkhalter wrote: > Add a `FileDescriptor` as the first parameter of `map0()` and remove from the corresponding native code the use of `fd_chan`. src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 54: > 52: > 53: JNIEXPORT jlong JNICALL > 54: Java_sun_nio_ch_FileChannelImpl_initIDs(JNIEnv *env, jclass clazz) Hello Brian, now that this function doesn't initialize ids, should it instead be renamed to something else? Also the corresponding `initIDs` method on the Java side? And perhaps remove this comment from `FileChannelImpl.java`: // Caches fieldIDs private static native long initIDs(); ------------- PR: https://git.openjdk.java.net/jdk/pull/8689 From jpai at openjdk.java.net Fri May 13 06:57:58 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 13 May 2022 06:57:58 GMT Subject: RFR: 8286671: (fc) Modify sun.nio.ch.FileChannelImpl.map0() to accept a FileDescriptor parameter In-Reply-To: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> References: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> Message-ID: <_T6Fh8dIJGBoqUL32-aH_uMZGg29BpcZnYm30fvh7MY=.1687d8b6-7b9b-4043-98ed-e2bfcdb401fa@github.com> On Thu, 12 May 2022 23:34:35 GMT, Brian Burkhalter wrote: > Add a `FileDescriptor` as the first parameter of `map0()` and remove from the corresponding native code the use of `fd_chan`. The copyright year on the Windows variant of `FileChannelImpl.c` will need an update. src/java.base/windows/native/libnio/ch/FileChannelImpl.c line 41: > 39: /************************************************************** > 40: * static method to store field ID's in initializers > 41: * and retrieve the allocation granularity Should we remove the "to store field ID's in initializers" part from this comment? ------------- PR: https://git.openjdk.java.net/jdk/pull/8689 From alanb at openjdk.java.net Fri May 13 07:05:45 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 13 May 2022 07:05:45 GMT Subject: RFR: 8286671: (fc) Modify sun.nio.ch.FileChannelImpl.map0() to accept a FileDescriptor parameter In-Reply-To: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> References: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> Message-ID: <5JzsUJ-R2nJlAjdULKgxQ4yRTznp2Wde3JxcIQ-f33E=.2d700fc5-c5e1-4fca-baab-8c07902fadc1@github.com> On Thu, 12 May 2022 23:34:35 GMT, Brian Burkhalter wrote: > Add a `FileDescriptor` as the first parameter of `map0()` and remove from the corresponding native code the use of `fd_chan`. Thanks for doing this cleanup, it removes a long standing inconsistency. I agree with Jai on removing the obsolete/confusion comment and I assume you'll do that before integrating. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8689 From uschindler at openjdk.java.net Fri May 13 08:13:47 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Fri, 13 May 2022 08:13:47 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v2] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 23:27:30 GMT, Brian Burkhalter wrote: >> Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. > > Brian Burkhalter 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 four additional commits since the last revision: > > - 8286671: Update test pursuant to JEP 424 integration > - Merge > - 8286637: Update test with try-with-resources and to print less > - 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows Approve the most recent version. ------------- Marked as reviewed by uschindler (Author). PR: https://git.openjdk.java.net/jdk/pull/8686 From jpai at openjdk.java.net Fri May 13 08:19:00 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 13 May 2022 08:19:00 GMT Subject: RFR: 8286689: (se) Adjusting to select timeout after EINTR messed up after JDK-8286378 Message-ID: <4G5lcsBFhWmA3z2mP-b9292fH_twCeAj34dYxzTEwEE=.cdb9ccae-7764-4233-bd6f-64cb8be05e91@github.com> Can I please get a review which fixes a recent unintentional change that went in as part of https://github.com/openjdk/jdk/pull/8642? The issue was caught here https://github.com/openjdk/jdk/pull/8642/files#r871994710 after the change was integrated. ------------- Commit messages: - 8286689: (se) Adjusting to select timeout after EINTR messed up after JDK-8286378 Changes: https://git.openjdk.java.net/jdk/pull/8693/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8693&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286689 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8693.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8693/head:pull/8693 PR: https://git.openjdk.java.net/jdk/pull/8693 From alanb at openjdk.java.net Fri May 13 08:24:59 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 13 May 2022 08:24:59 GMT Subject: RFR: 8286689: (se) Adjusting to select timeout after EINTR messed up after JDK-8286378 In-Reply-To: <4G5lcsBFhWmA3z2mP-b9292fH_twCeAj34dYxzTEwEE=.cdb9ccae-7764-4233-bd6f-64cb8be05e91@github.com> References: <4G5lcsBFhWmA3z2mP-b9292fH_twCeAj34dYxzTEwEE=.cdb9ccae-7764-4233-bd6f-64cb8be05e91@github.com> Message-ID: On Fri, 13 May 2022 08:13:35 GMT, Jaikiran Pai wrote: > Can I please get a review which fixes a recent unintentional change that went in as part of https://github.com/openjdk/jdk/pull/8642? The issue was caught here https://github.com/openjdk/jdk/pull/8642/files#r871994710 after the change was integrated. Thanks for jumping on this, can we update KQueueSelectImpl.doSelect too, this was missed by JDK-8286378, I assume because the test with the new compiler option was only done on one platform. ------------- PR: https://git.openjdk.java.net/jdk/pull/8693 From uschindler at openjdk.java.net Fri May 13 08:37:17 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Fri, 13 May 2022 08:37:17 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 15:45:01 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: > > - Merge branch 'master' into foreign-preview > - Merge branch 'master' into foreign-preview > - Fix crashes in heap segment benchmarks due to misaligned access > - Merge branch 'master' into foreign-preview > - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Add tests for loaderLookup/restricted method corner cases > - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI > * Tweak restricted method check to work when there's no caller class > - Tweak examples in SymbolLookup javadoc > - Merge branch 'master' into foreign-preview > - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b Some late comments and suggestions to fix inconsistencies and wrong javadocs. src/java.base/share/classes/java/nio/channels/FileChannel.java line 1045: > 1043: * > 1044: * @throws UnsupportedOperationException > 1045: * If an unsupported map mode is specified. I think this should mention that UOE is also throws if the filesystem implementation does not support memory mapping. This may happen for filesystems like jrtfs or custom wrapper filesystems that do not implement the method below. As this is already merged, should I open a PR fixing the docs or open an issue? src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1164: > 1162: } > 1163: if (unmapper != null) { > 1164: AbstractMemorySegmentImpl segment = new MappedMemorySegmentImpl(unmapper.address(), unmapper, size, When reviewing the method for MappedByteBuffer: I think to make this consistent the "old" method should also use `address()` which applies the pagePosition. Currently it is confusing: - New code returning `MemorySegment` uses `unmapper.address()` - Old code returning `MappedByteBuffer` uses `unmapper.address + unmapper.pagePosition` (fields) Should I open an issue or a PR to fix this (because this is already merged)? See the mailing list posts: - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016981.html - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016990.html ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From uschindler at openjdk.java.net Fri May 13 08:37:18 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Fri, 13 May 2022 08:37:18 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 08:25:01 GMT, Uwe Schindler wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: >> >> - Merge branch 'master' into foreign-preview >> - Merge branch 'master' into foreign-preview >> - Fix crashes in heap segment benchmarks due to misaligned access >> - Merge branch 'master' into foreign-preview >> - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Add tests for loaderLookup/restricted method corner cases >> - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI >> * Tweak restricted method check to work when there's no caller class >> - Tweak examples in SymbolLookup javadoc >> - Merge branch 'master' into foreign-preview >> - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b > > src/java.base/share/classes/java/nio/channels/FileChannel.java line 1045: > >> 1043: * >> 1044: * @throws UnsupportedOperationException >> 1045: * If an unsupported map mode is specified. > > I think this should mention that UOE is also throws if the filesystem implementation does not support memory mapping. This may happen for filesystems like jrtfs or custom wrapper filesystems that do not implement the method below. > > As this is already merged, should I open a PR fixing the docs or open an issue? This change here also closes [JDK-8259034](https://bugs.openjdk.java.net/browse/JDK-8259034) ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From jpai at openjdk.java.net Fri May 13 08:38:41 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 13 May 2022 08:38:41 GMT Subject: RFR: 8286689: (se) Adjusting to select timeout after EINTR messed up after JDK-8286378 In-Reply-To: <4G5lcsBFhWmA3z2mP-b9292fH_twCeAj34dYxzTEwEE=.cdb9ccae-7764-4233-bd6f-64cb8be05e91@github.com> References: <4G5lcsBFhWmA3z2mP-b9292fH_twCeAj34dYxzTEwEE=.cdb9ccae-7764-4233-bd6f-64cb8be05e91@github.com> Message-ID: On Fri, 13 May 2022 08:13:35 GMT, Jaikiran Pai wrote: > Can I please get a review which fixes a recent unintentional change that went in as part of https://github.com/openjdk/jdk/pull/8642? The issue was caught here https://github.com/openjdk/jdk/pull/8642/files#r871994710 after the change was integrated. Hello Alan, > can we update KQueueSelectImpl.doSelect too, this was missed by JDK-8286378, I assume because the test with the new compiler option was only done on one platform. In the case of `KQueueSelectorImpl.doSelect()`, the `to` is already a `long`, unlike in these 2 classes where it's an `int`. The `to` then gets passed to `KQueue.poll(...)` which expects a `long` timeout unlike in the above 2 classes where the `to` gets passed to methods which expect an `int` timeout. I believe that was the reason the compiler didn't complain in case of `KQueueSelectorImpl`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8693 From dfuchs at openjdk.java.net Fri May 13 08:42:50 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 13 May 2022 08:42:50 GMT Subject: RFR: 8286689: (se) Adjusting to select timeout after EINTR messed up after JDK-8286378 In-Reply-To: <4G5lcsBFhWmA3z2mP-b9292fH_twCeAj34dYxzTEwEE=.cdb9ccae-7764-4233-bd6f-64cb8be05e91@github.com> References: <4G5lcsBFhWmA3z2mP-b9292fH_twCeAj34dYxzTEwEE=.cdb9ccae-7764-4233-bd6f-64cb8be05e91@github.com> Message-ID: <_xhxUxQcIMKisGWzLXDb7SNIXD5ZlvKkNAmYKN64YKQ=.9b221d04-8927-4929-a979-93329e0d4b59@github.com> On Fri, 13 May 2022 08:13:35 GMT, Jaikiran Pai wrote: > Can I please get a review which fixes a recent unintentional change that went in as part of https://github.com/openjdk/jdk/pull/8642? The issue was caught here https://github.com/openjdk/jdk/pull/8642/files#r871994710 after the change was integrated. LGTM. I double checked and this seems the only two cases where the `=-` typo crept in. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8693 From alanb at openjdk.java.net Fri May 13 08:42:51 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 13 May 2022 08:42:51 GMT Subject: RFR: 8286689: (se) Adjusting to select timeout after EINTR messed up after JDK-8286378 In-Reply-To: References: <4G5lcsBFhWmA3z2mP-b9292fH_twCeAj34dYxzTEwEE=.cdb9ccae-7764-4233-bd6f-64cb8be05e91@github.com> Message-ID: On Fri, 13 May 2022 08:35:25 GMT, Jaikiran Pai wrote: > In the case of `KQueueSelectorImpl.doSelect()`, the `to` is already a `long`, unlike in these 2 classes where it's an `int`. The `to` then gets passed to `KQueue.poll(...)` which expects a `long` timeout unlike in the above 2 classes where the `to` gets passed to methods which expect an `int` timeout. I believe that was the reason the compiler didn't complain in case of `KQueueSelectorImpl`. Ah yes, I forgot it was a long here. Thanks for checking. However, part of my comment is that there is an inconsistency because KQueueSelectImpl.doSelect wasn't changed to use toMillis. We can create a separate PR to make these consistent if you don't want to include it here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8693 From jpai at openjdk.java.net Fri May 13 08:51:35 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 13 May 2022 08:51:35 GMT Subject: RFR: 8286689: (se) Adjusting to select timeout after EINTR messed up after JDK-8286378 In-Reply-To: References: <4G5lcsBFhWmA3z2mP-b9292fH_twCeAj34dYxzTEwEE=.cdb9ccae-7764-4233-bd6f-64cb8be05e91@github.com> Message-ID: On Fri, 13 May 2022 08:39:48 GMT, Alan Bateman wrote: > However, part of my comment is that there is an inconsistency because KQueueSelectImpl.doSelect wasn't changed to use toMillis. You are right. I was focusing too much on the casting and the LHS, that I didn't notice this API usage. I have now updated the PR to use `toMillis`. I ran a local build on my macOS to make sure this doesn't break anything obvious. Build went fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/8693 From jpai at openjdk.java.net Fri May 13 08:51:35 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 13 May 2022 08:51:35 GMT Subject: RFR: 8286689: (se) Adjusting to select timeout after EINTR messed up after JDK-8286378 [v2] In-Reply-To: <4G5lcsBFhWmA3z2mP-b9292fH_twCeAj34dYxzTEwEE=.cdb9ccae-7764-4233-bd6f-64cb8be05e91@github.com> References: <4G5lcsBFhWmA3z2mP-b9292fH_twCeAj34dYxzTEwEE=.cdb9ccae-7764-4233-bd6f-64cb8be05e91@github.com> Message-ID: > Can I please get a review which fixes a recent unintentional change that went in as part of https://github.com/openjdk/jdk/pull/8642? The issue was caught here https://github.com/openjdk/jdk/pull/8642/files#r871994710 after the change was integrated. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Alan's suggestion - use TimeUnit#toMillis API ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8693/files - new: https://git.openjdk.java.net/jdk/pull/8693/files/560b531f..cadf7e30 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8693&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8693&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8693.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8693/head:pull/8693 PR: https://git.openjdk.java.net/jdk/pull/8693 From alanb at openjdk.java.net Fri May 13 09:19:40 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 13 May 2022 09:19:40 GMT Subject: RFR: 8286689: (se) Adjusting to select timeout after EINTR messed up after JDK-8286378 [v2] In-Reply-To: References: <4G5lcsBFhWmA3z2mP-b9292fH_twCeAj34dYxzTEwEE=.cdb9ccae-7764-4233-bd6f-64cb8be05e91@github.com> Message-ID: On Fri, 13 May 2022 08:51:35 GMT, Jaikiran Pai wrote: >> Can I please get a review which fixes a recent unintentional change that went in as part of https://github.com/openjdk/jdk/pull/8642? The issue was caught here https://github.com/openjdk/jdk/pull/8642/files#r871994710 after the change was integrated. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Alan's suggestion - use TimeUnit#toMillis API Thanks for this. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8693 From mcimadamore at openjdk.java.net Fri May 13 09:48:02 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 13 May 2022 09:48:02 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 08:33:11 GMT, Uwe Schindler wrote: >> src/java.base/share/classes/java/nio/channels/FileChannel.java line 1045: >> >>> 1043: * >>> 1044: * @throws UnsupportedOperationException >>> 1045: * If an unsupported map mode is specified. >> >> I think this should mention that UOE is also throws if the filesystem implementation does not support memory mapping. This may happen for filesystems like jrtfs or custom wrapper filesystems that do not implement the method below. >> >> As this is already merged, should I open a PR fixing the docs or open an issue? > > This change here also closes [JDK-8259034](https://bugs.openjdk.java.net/browse/JDK-8259034) @uschindler - the issue you mention with respect lack of UOE for wrong file system applies to BB as well. I suggest filing an issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Fri May 13 09:48:08 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 13 May 2022 09:48:08 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com> On Fri, 13 May 2022 08:29:13 GMT, Uwe Schindler wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: >> >> - Merge branch 'master' into foreign-preview >> - Merge branch 'master' into foreign-preview >> - Fix crashes in heap segment benchmarks due to misaligned access >> - Merge branch 'master' into foreign-preview >> - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Add tests for loaderLookup/restricted method corner cases >> - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI >> * Tweak restricted method check to work when there's no caller class >> - Tweak examples in SymbolLookup javadoc >> - Merge branch 'master' into foreign-preview >> - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b > > src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1164: > >> 1162: } >> 1163: if (unmapper != null) { >> 1164: AbstractMemorySegmentImpl segment = new MappedMemorySegmentImpl(unmapper.address(), unmapper, size, > > When reviewing the method for MappedByteBuffer: I think to make this consistent the "old" method should also use `address()` which applies the pagePosition. Currently it is confusing: > - New code returning `MemorySegment` uses `unmapper.address()` > - Old code returning `MappedByteBuffer` uses `unmapper.address + unmapper.pagePosition` (fields) > > Should I open an issue or a PR to fix this (because this is already merged)? > > See the mailing list posts: > - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016981.html > - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016990.html Please file an RFE. I suspect that there will be more little improvements and consolidation like this we'll want to make to this code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From uschindler at openjdk.java.net Fri May 13 11:06:12 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Fri, 13 May 2022 11:06:12 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com> References: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com> Message-ID: <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com> On Fri, 13 May 2022 09:43:55 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1164: >> >>> 1162: } >>> 1163: if (unmapper != null) { >>> 1164: AbstractMemorySegmentImpl segment = new MappedMemorySegmentImpl(unmapper.address(), unmapper, size, >> >> When reviewing the method for MappedByteBuffer: I think to make this consistent the "old" method should also use `address()` which applies the pagePosition. Currently it is confusing: >> - New code returning `MemorySegment` uses `unmapper.address()` >> - Old code returning `MappedByteBuffer` uses `unmapper.address + unmapper.pagePosition` (fields) >> >> Should I open an issue or a PR to fix this (because this is already merged)? >> >> See the mailing list posts: >> - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016981.html >> - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016990.html > > Please file an RFE. I suspect that there will be more little improvements and consolidation like this we'll want to make to this code. RFE = issue? ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From jpai at openjdk.java.net Fri May 13 11:08:42 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 13 May 2022 11:08:42 GMT Subject: RFR: 8286689: (se) Adjusting to select timeout after EINTR messed up after JDK-8286378 [v2] In-Reply-To: References: <4G5lcsBFhWmA3z2mP-b9292fH_twCeAj34dYxzTEwEE=.cdb9ccae-7764-4233-bd6f-64cb8be05e91@github.com> Message-ID: On Fri, 13 May 2022 08:51:35 GMT, Jaikiran Pai wrote: >> Can I please get a review which fixes a recent unintentional change that went in as part of https://github.com/openjdk/jdk/pull/8642? The issue was caught here https://github.com/openjdk/jdk/pull/8642/files#r871994710 after the change was integrated. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Alan's suggestion - use TimeUnit#toMillis API Thank you Alan and Daniel for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/8693 From jpai at openjdk.java.net Fri May 13 11:13:50 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 13 May 2022 11:13:50 GMT Subject: Integrated: 8286689: (se) Adjusting to select timeout after EINTR messed up after JDK-8286378 In-Reply-To: <4G5lcsBFhWmA3z2mP-b9292fH_twCeAj34dYxzTEwEE=.cdb9ccae-7764-4233-bd6f-64cb8be05e91@github.com> References: <4G5lcsBFhWmA3z2mP-b9292fH_twCeAj34dYxzTEwEE=.cdb9ccae-7764-4233-bd6f-64cb8be05e91@github.com> Message-ID: On Fri, 13 May 2022 08:13:35 GMT, Jaikiran Pai wrote: > Can I please get a review which fixes a recent unintentional change that went in as part of https://github.com/openjdk/jdk/pull/8642? The issue was caught here https://github.com/openjdk/jdk/pull/8642/files#r871994710 after the change was integrated. This pull request has now been integrated. Changeset: 0be1f3e1 Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/0be1f3e1b0f4ac515a86e9f8e1999dc090b1bdd2 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8286689: (se) Adjusting to select timeout after EINTR messed up after JDK-8286378 Reviewed-by: dfuchs, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8693 From ihse at openjdk.java.net Fri May 13 11:15:48 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 11:15:48 GMT Subject: RFR: 8285485: Fix typos in corelibs In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 16:18:15 GMT, Naoto Sato wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188: >> >>> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757 >>> 187: >>> 188: main.plugin.category=\u7C7B\u522B >> >> what's this? > > Removing the trailing space? A similar one is in the `ja` resource bundle. This happens as a combination of jcheck not enforcing eol space checks on .properties files, and my editor being set to always remove space at eol. ------------- PR: https://git.openjdk.java.net/jdk/pull/8364 From duke at openjdk.java.net Fri May 13 11:19:51 2022 From: duke at openjdk.java.net (ExE Boss) Date: Fri, 13 May 2022 11:19:51 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: References: Message-ID: <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com> On Thu, 10 Mar 2022 08:52:17 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8282662: Revert dubious changes in MethodType src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 727: > 725: MethodVisitor mv = cw.visitMethod(accessFlags, > 726: method.getName(), desc, null, > 727: typeNames(List.of(exceptionTypes))); Since?`exceptionTypes` is?an?array, it?might be?better to?keep?using `Arrays.asList`, or?add an?overload for?`typeNames` that?works on?class?arrays. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From ihse at openjdk.java.net Fri May 13 11:29:46 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 11:29:46 GMT Subject: RFR: 8285485: Fix typos in corelibs In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 16:50:30 GMT, Pavel Rappo wrote: >> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos. >> >> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). >> >> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. > > src/java.se/share/data/jdwp/jdwp.spec line 47: > >> 45: "Returns reference types for all the classes loaded by the target VM " >> 46: "which match the given signature. " >> 47: "Multiple reference types will be returned if two or more class " > > This file's name scares me. The fact that there's no "serviceability" label on this PR adds to this feeling. I would ask around if I were you. I'll revert all changes in this file. I don't want it to hold up the entire PR. We can revisit it later, with serviceability. > src/java.sql.rowset/share/classes/com/sun/rowset/JoinRowSetImpl.java line 636: > >> 634: // to be INNER JOIN'ED to form a new rowset >> 635: // Compare table1.MatchColumn1.value1 == { table2.MatchColumn2.value1 >> 636: // ... up to table2.MatchColumn2.valueN } > > Curious: it is not some established string representation, is it? You mean writing "upto" instead of "up to"? No, it's just incorrect, and a somewhat common typo. ------------- PR: https://git.openjdk.java.net/jdk/pull/8364 From ihse at openjdk.java.net Fri May 13 11:35:14 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 11:35:14 GMT Subject: RFR: 8285485: Fix typos in corelibs In-Reply-To: References: Message-ID: <7kx-jUmt6rUlKn4ca0EfM7oN2HSyM8wtxdENSuL5X-Y=.639d9012-93bf-455e-9a73-6a69412af948@github.com> On Wed, 27 Apr 2022 15:45:12 GMT, Roger Riggs wrote: >> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos. >> >> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). >> >> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. > > src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEventReaderImpl.java line 140: > >> 138: } else if(type == XMLEvent.START_ELEMENT) { >> 139: throw new XMLStreamException( >> 140: "elementGetText() function expects text only element but START_ELEMENT was encountered.", event.getLocation()); > > Should we be fixing typos in third party software; it can easily get wiped out in an update. No, we should not. Such changes ideally should be brought upstream, but I can't be bothered. :-( I'm reverting all changes in this file. Are there any more files that are 3rd party in this fix? I have no way to tell. ------------- PR: https://git.openjdk.java.net/jdk/pull/8364 From ihse at openjdk.java.net Fri May 13 11:35:19 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 11:35:19 GMT Subject: RFR: 8285485: Fix typos in corelibs In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 17:11:34 GMT, Pavel Rappo wrote: >> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos. >> >> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). >> >> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. > > src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLDOMWriterImpl.java line 238: > >> 236: >> 237: /** >> 238: * Creates a DOM Attribute @see org.w3c.dom.Node and associates it with the current DOM element @see org.w3c.dom.Node. > > Not that it matters in this PR, but I think I should mention that `@see` tags do not work like that. (No action needed from you.) Yeah. There's a lot of crappy code hanging around. :( Feel free to open a bug on checking incorrect usage of `@see` tags in the JDK. I'm sure you'll find more cases than those. > src/java.xml/share/classes/javax/xml/transform/Transformer.java line 127: > >> 125: * namespace URI in curly braces ({}). >> 126: * @param value The value object. This can be any valid Java object. It is >> 127: * up to the processor to provide the proper object coersion or to simply > > That made me pause: some systems have the notion of _type coercion_; but your change looks right. I also had to read this a couple of time, and check the source. ------------- PR: https://git.openjdk.java.net/jdk/pull/8364 From ihse at openjdk.java.net Fri May 13 11:38:34 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 11:38:34 GMT Subject: RFR: 8285485: Fix typos in corelibs [v2] In-Reply-To: References: Message-ID: > I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos. > > I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). > > The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fixes comments in review: * Reverting changes in jdwp.spec * Fix "is occurs" * Stop providing "Syncchronication" providers :-) * Fix fEncoder reduplication. * Revert changes in XMLEventReaderImpl.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8364/files - new: https://git.openjdk.java.net/jdk/pull/8364/files/d4266e0a..b6c00de9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8364&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8364&range=00-01 Stats: 13 lines in 6 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8364.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8364/head:pull/8364 PR: https://git.openjdk.java.net/jdk/pull/8364 From ihse at openjdk.java.net Fri May 13 11:45:14 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 11:45:14 GMT Subject: RFR: 8285485: Fix typos in corelibs [v3] In-Reply-To: References: Message-ID: <_jkOOYf10_iUXfeN5cffFD7H9WCXQRZVVyfx1kGckS4=.60a50101-35a5-408b-950c-6ebd23c453b4@github.com> > I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos. > > I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). > > The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. Magnus Ihse Bursie 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: - Merge branch 'master' into typos-in-corelibs - Fixes comments in review: * Reverting changes in jdwp.spec * Fix "is occurs" * Stop providing "Syncchronication" providers :-) * Fix fEncoder reduplication. * Revert changes in XMLEventReaderImpl.java - Pass #2 core - Pass #1 core - Pass #2 misc - Pass #1 misc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8364/files - new: https://git.openjdk.java.net/jdk/pull/8364/files/b6c00de9..8bc35edb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8364&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8364&range=01-02 Stats: 228368 lines in 2830 files changed: 173822 ins; 38520 del; 16026 mod Patch: https://git.openjdk.java.net/jdk/pull/8364.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8364/head:pull/8364 PR: https://git.openjdk.java.net/jdk/pull/8364 From ihse at openjdk.java.net Fri May 13 11:45:15 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 11:45:15 GMT Subject: RFR: 8285485: Fix typos in corelibs [v3] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 15:50:20 GMT, Roger Riggs wrote: >> Magnus Ihse Bursie 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: >> >> - Merge branch 'master' into typos-in-corelibs >> - Fixes comments in review: >> >> * Reverting changes in jdwp.spec >> * Fix "is occurs" >> * Stop providing "Syncchronication" providers :-) >> * Fix fEncoder reduplication. >> * Revert changes in XMLEventReaderImpl.java >> - Pass #2 core >> - Pass #1 core >> - Pass #2 misc >> - Pass #1 misc > > Since you've changed some code; you need to run tests for tiers 1-3. > > (Note that even for trivial changes, hundreds of OpenJDK developers are notified and distracted; be considerate of other developers). I believe I have addressed all feedback in the review, with the possible exception of 3rd party source. @RogerRiggs Are there more 3rd party files I have inadvertently modified, apart from `XMLEventReaderImpl.java`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8364 From mcimadamore at openjdk.java.net Fri May 13 12:03:01 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 13 May 2022 12:03:01 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com> References: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com> <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com> Message-ID: On Fri, 13 May 2022 11:01:09 GMT, Uwe Schindler wrote: > RFE = issue? issue, with type RFE (request for enhancement) ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From uschindler at openjdk.java.net Fri May 13 12:19:15 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Fri, 13 May 2022 12:19:15 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com> <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com> Message-ID: On Fri, 13 May 2022 11:59:12 GMT, Maurizio Cimadamore wrote: >> RFE = issue? > >> RFE = issue? > > issue, with type RFE (request for enhancement) See: https://bugs.openjdk.java.net/browse/JDK-8286734 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From duke at openjdk.java.net Fri May 13 12:23:03 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 13 May 2022 12:23:03 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com> References: <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com> Message-ID: On Fri, 13 May 2022 11:14:29 GMT, ExE Boss wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282662: Revert dubious changes in MethodType > > src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 727: > >> 725: MethodVisitor mv = cw.visitMethod(accessFlags, >> 726: method.getName(), desc, null, >> 727: typeNames(List.of(exceptionTypes))); > > Since?`exceptionTypes` is?an?array, it?might be?better to?keep?using `Arrays.asList`, or?add an?overload for?`typeNames` that?works on?class?arrays. Usually a method declares either no exception, or a couple of them. In the first case `List.of()` doesn't allocate, in the second it allocates an object with 1-2 fields but without an array, so `List.of()` is likely to be more memory-saving ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From duke at openjdk.java.net Fri May 13 12:23:04 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 13 May 2022 12:23:04 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: References: <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com> Message-ID: <8kThIsE5ikFJ_V3Y9ixYKlNcuMPg77ci974Q63wCH_Y=.69d3e25a-4091-4e9d-9da5-18054148744c@github.com> On Fri, 13 May 2022 12:19:08 GMT, ?????? ??????? wrote: >> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 727: >> >>> 725: MethodVisitor mv = cw.visitMethod(accessFlags, >>> 726: method.getName(), desc, null, >>> 727: typeNames(List.of(exceptionTypes))); >> >> Since?`exceptionTypes` is?an?array, it?might be?better to?keep?using `Arrays.asList`, or?add an?overload for?`typeNames` that?works on?class?arrays. > > Usually a method declares either no exception, or a couple of them. In the first case `List.of()` doesn't allocate, in the second it allocates an object with 1-2 fields but without an array, so `List.of()` is likely to be more memory-saving Usually a method declares either no exception, or a couple of them. In the first case `List.of()` doesn't allocate, in the second it allocates an object with 1-2 fields but without an array, so `List.of()` is likely to be more memory-saving ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From uschindler at openjdk.java.net Fri May 13 12:29:09 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Fri, 13 May 2022 12:29:09 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: <_qJfbHWbWDSXgHQx9PRP2YDQ7cLkC41BmxL_osQIRhs=.dd01fb6e-e671-4bb4-8332-9c9d337abaf9@github.com> On Fri, 13 May 2022 09:42:44 GMT, Maurizio Cimadamore wrote: >> This change here also closes [JDK-8259034](https://bugs.openjdk.java.net/browse/JDK-8259034) > > @uschindler - the issue you mention with respect lack of UOE for wrong file system applies to BB as well. I suggest filing an issue. See https://bugs.openjdk.java.net/browse/JDK-8286735 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Fri May 13 12:43:27 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 13 May 2022 12:43:27 GMT Subject: RFR: 8286715: Generalize MemorySegment::ofBuffer Message-ID: This patch makes MemorySegment::ofBuffer more general, by allowing clients to pass *any* `Buffer` instance, not just `ByteBuffer`. This allows us to match expressiveness of JNI API, where JNI clients can obtain the address of any direct buffer instance, using the `GetDirectBufferAddress` function. We thought about also providing a more general way to view a segment as a buffer (e.g. asIntBuffer) but doing that doesn't seem worth it: direct buffers can only created form `ByteBuffer`. So, to create a direct `IntBuffer`, clients have to first create a direct `ByteBuffer` then to view that buffer as an `IntBuffer`. In other words, `IntBuffer` and friends are not first-class citizens in the `Buffer` API. As such it would not be possible to map many memory segments into an `IntBuffer`; in fact, the only segment we could safely map into an `IntBuffer` would be an _heap_ segment backed by an `int[]`. As such it doesn't seem worth adding a lot of API surface (in terms of additional overloads) for such a corner case. ------------- Commit messages: - Tweak javadoc - Merge branch 'foreign-preview' into generalize_ofbuffer - Merge branch 'master' into foreign-preview - Merge branch 'master' into foreign-preview - Merge branch 'master' into foreign-preview - Fix crashes in heap segment benchmarks due to misaligned access - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java - Initial push - Add tests for loaderLookup/restricted method corner cases - ... and 59 more: https://git.openjdk.java.net/jdk/compare/11fa03f3...02494e2f Changes: https://git.openjdk.java.net/jdk/pull/8701/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8701&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286715 Stats: 95 lines in 8 files changed: 55 ins; 1 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/8701.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8701/head:pull/8701 PR: https://git.openjdk.java.net/jdk/pull/8701 From mcimadamore at openjdk.java.net Fri May 13 12:43:28 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 13 May 2022 12:43:28 GMT Subject: RFR: 8286715: Generalize MemorySegment::ofBuffer In-Reply-To: References: Message-ID: On Fri, 13 May 2022 12:33:10 GMT, Maurizio Cimadamore wrote: > This patch makes MemorySegment::ofBuffer more general, by allowing clients to pass *any* `Buffer` instance, not just `ByteBuffer`. > This allows us to match expressiveness of JNI API, where JNI clients can obtain the address of any direct buffer instance, using the `GetDirectBufferAddress` function. > > We thought about also providing a more general way to view a segment as a buffer (e.g. asIntBuffer) but doing that doesn't seem worth it: direct buffers can only created form `ByteBuffer`. > So, to create a direct `IntBuffer`, clients have to first create a direct `ByteBuffer` then to view that buffer as an `IntBuffer`. > > In other words, `IntBuffer` and friends are not first-class citizens in the `Buffer` API. As such it would not be possible to map many memory segments into an `IntBuffer`; in fact, the only segment we could safely map into an `IntBuffer` would be an _heap_ segment backed by an `int[]`. As such it doesn't seem worth adding a lot of API surface (in terms of additional overloads) for such a corner case. src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 88: > 86: * if it is associated with a confined session, it can only be accessed by the thread which owns the memory session. > 87: *

> 88: * Heap segments are always associated with the {@linkplain MemorySession#global() global} memory session. I've tweaked this text, as I realized the old version was erroneously suggesting that all buffer segments were backed by a global session. src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 577: > 575: } > 576: > 577: private static int getScaleFactor(Buffer buffer) { Note: for each buffer kind, there are three possible cases. Consider `IntBuffer`: an `IntBuffer` can be backed by: * `byte[]`, if it's a byte buffer view * `int[]`, if it's allocated with `IntBuffer.allocate`, or `IntBuffer.wrap` * null, if it comes from a direct byte buffer viewed as an `IntBuffer` As such, the buffer kind (IntBuffer vs. LongBuffer) determines the buffer element size, and therefore how much the buffer position and size should be scaled. But to check whether we need to create a heap vs. off-heap vs. mapped segment, or to check _which_ kind of heap segment we need, we need to look into the buffer base object, since there can be multiple options for any single buffer type. ------------- PR: https://git.openjdk.java.net/jdk/pull/8701 From duke at openjdk.java.net Fri May 13 13:41:48 2022 From: duke at openjdk.java.net (ExE Boss) Date: Fri, 13 May 2022 13:41:48 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: <8kThIsE5ikFJ_V3Y9ixYKlNcuMPg77ci974Q63wCH_Y=.69d3e25a-4091-4e9d-9da5-18054148744c@github.com> References: <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com> <8kThIsE5ikFJ_V3Y9ixYKlNcuMPg77ci974Q63wCH_Y=.69d3e25a-4091-4e9d-9da5-18054148744c@github.com> Message-ID: On Fri, 13 May 2022 12:19:25 GMT, ?????? ??????? wrote: >> Usually a method declares either no exception, or a couple of them. In the first case `List.of()` doesn't allocate, in the second it allocates an object with 1-2 fields but without an array, so `List.of()` is likely to be more memory-saving > > Usually a method declares either no exception, or a couple of them. In the first case `List.of()` doesn't allocate, in the second it allocates an object with 1-2 fields but without an array, so `List.of()` is likely to be more memory-saving Even?in the?no?exceptions?case, the?`exceptionTypes`?array still?has to?be?allocated/copied by?`Method.getExceptionTypes()`[^1] when?the?`ProxyMethod`?constructor[^2] is?invoked. So?if?anything, the?`List.of(?)`?call should?be?moved into?the?`ProxyMethod`?constructor. And?maybe the?call to?`Method.getExceptionTypes()` should?be?changed to?`Method.getSharedExceptionTypes()`[^3]. [^1]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/Method.java#L340-L343 [^2]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#L710-L714 [^3]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/Method.java#L305-L308 ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From ihse at openjdk.java.net Fri May 13 14:08:31 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 14:08:31 GMT Subject: RFR: 8285485: Fix typos in corelibs [v4] In-Reply-To: References: Message-ID: > I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos. > > I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). > > The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8364/files - new: https://git.openjdk.java.net/jdk/pull/8364/files/8bc35edb..7dc7f653 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8364&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8364&range=02-03 Stats: 86 lines in 86 files changed: 0 ins; 0 del; 86 mod Patch: https://git.openjdk.java.net/jdk/pull/8364.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8364/head:pull/8364 PR: https://git.openjdk.java.net/jdk/pull/8364 From rriggs at openjdk.java.net Fri May 13 14:22:01 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 13 May 2022 14:22:01 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 05:54:15 GMT, Alan Bateman wrote: >> src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128: >> >>> 126: // timed poll interrupted so need to adjust timeout >>> 127: long adjust = System.nanoTime() - startTime; >>> 128: to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust); >> >> This?will?now always?assign a?negative?number to?`to`. >> >> -------------------------------------------------------------------------------- >> >> `=-`?is?not a?compound?assignment, it?s?negation followed?by a?normal?assignment. > > Well spotted, I don't think that change was intentionally. Ouch; Will fix: I took Alan's earlier comment literally: "This one can also be changed to: to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);" ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From duke at openjdk.java.net Fri May 13 14:27:02 2022 From: duke at openjdk.java.net (ExE Boss) Date: Fri, 13 May 2022 14:27:02 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 14:18:04 GMT, Roger Riggs wrote: >> Well spotted, I don't think that change was intentionally. > > Ouch; Will fix: > > I took Alan's earlier comment literally: > > "This one can also be changed to: > > to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);" @RogerRiggs This?already got?fixed by?@jaikiran in?[GH?8693]. [GH?8693]: https://github.com/openjdk/jdk/pull/8693 ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From bpb at openjdk.java.net Fri May 13 14:48:50 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 13 May 2022 14:48:50 GMT Subject: RFR: 8286671: (fc) Modify sun.nio.ch.FileChannelImpl.map0() to accept a FileDescriptor parameter In-Reply-To: References: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> Message-ID: On Fri, 13 May 2022 06:47:47 GMT, Jaikiran Pai wrote: >> Add a `FileDescriptor` as the first parameter of `map0()` and remove from the corresponding native code the use of `fd_chan`. > > src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 54: > >> 52: >> 53: JNIEXPORT jlong JNICALL >> 54: Java_sun_nio_ch_FileChannelImpl_initIDs(JNIEnv *env, jclass clazz) > > Hello Brian, now that this function doesn't initialize ids, should it instead be renamed to something else? Also the corresponding `initIDs` method on the Java side? And perhaps remove this comment from `FileChannelImpl.java`: > > > // Caches fieldIDs > private static native long initIDs(); Yeah I had thought of that as well but shined it on. I'll update before integrating. ------------- PR: https://git.openjdk.java.net/jdk/pull/8689 From jpai at openjdk.java.net Fri May 13 14:57:00 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 13 May 2022 14:57:00 GMT Subject: RFR: 8286671: (fc) Modify sun.nio.ch.FileChannelImpl.map0() to accept a FileDescriptor parameter In-Reply-To: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> References: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> Message-ID: On Thu, 12 May 2022 23:34:35 GMT, Brian Burkhalter wrote: > Add a `FileDescriptor` as the first parameter of `map0()` and remove from the corresponding native code the use of `fd_chan`. Marked as reviewed by jpai (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8689 From bpb at openjdk.java.net Fri May 13 15:45:37 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 13 May 2022 15:45:37 GMT Subject: RFR: 8286671: (fc) Modify sun.nio.ch.FileChannelImpl.map0() to accept a FileDescriptor parameter [v2] In-Reply-To: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> References: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> Message-ID: <4GBtQGlofMRdSAAGFBHQXzjUZc7qs4xQmng6258NHuE=.40071c77-8974-4345-b09e-e4e8e6d81011@github.com> > Add a `FileDescriptor` as the first parameter of `map0()` and remove from the corresponding native code the use of `fd_chan`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8286671: Rename initIDs() to allocationGranularity0() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8689/files - new: https://git.openjdk.java.net/jdk/pull/8689/files/1b022d82..0c707e41 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8689&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8689&range=00-01 Stats: 8 lines in 3 files changed: 0 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8689.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8689/head:pull/8689 PR: https://git.openjdk.java.net/jdk/pull/8689 From bpb at openjdk.java.net Fri May 13 15:45:37 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 13 May 2022 15:45:37 GMT Subject: RFR: 8286671: (fc) Modify sun.nio.ch.FileChannelImpl.map0() to accept a FileDescriptor parameter [v2] In-Reply-To: <5JzsUJ-R2nJlAjdULKgxQ4yRTznp2Wde3JxcIQ-f33E=.2d700fc5-c5e1-4fca-baab-8c07902fadc1@github.com> References: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> <5JzsUJ-R2nJlAjdULKgxQ4yRTznp2Wde3JxcIQ-f33E=.2d700fc5-c5e1-4fca-baab-8c07902fadc1@github.com> Message-ID: On Fri, 13 May 2022 07:02:44 GMT, Alan Bateman wrote: > Thanks for doing this cleanup, it removes a long standing inconsistency. I agree with Jai on removing the obsolete/confusion comment and I assume you'll do that before integrating. Fixed by 0c707e41492a682967f522ce03894f87a133a16f. ------------- PR: https://git.openjdk.java.net/jdk/pull/8689 From bpb at openjdk.java.net Fri May 13 15:45:37 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 13 May 2022 15:45:37 GMT Subject: RFR: 8286671: (fc) Modify sun.nio.ch.FileChannelImpl.map0() to accept a FileDescriptor parameter In-Reply-To: <_T6Fh8dIJGBoqUL32-aH_uMZGg29BpcZnYm30fvh7MY=.1687d8b6-7b9b-4043-98ed-e2bfcdb401fa@github.com> References: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> <_T6Fh8dIJGBoqUL32-aH_uMZGg29BpcZnYm30fvh7MY=.1687d8b6-7b9b-4043-98ed-e2bfcdb401fa@github.com> Message-ID: On Fri, 13 May 2022 06:54:37 GMT, Jaikiran Pai wrote: > The copyright year on the Windows variant of `FileChannelImpl.c` will need an update. Fixed by 0c707e41492a682967f522ce03894f87a133a16f. ------------- PR: https://git.openjdk.java.net/jdk/pull/8689 From bpb at openjdk.java.net Fri May 13 15:45:38 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 13 May 2022 15:45:38 GMT Subject: RFR: 8286671: (fc) Modify sun.nio.ch.FileChannelImpl.map0() to accept a FileDescriptor parameter [v2] In-Reply-To: References: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> Message-ID: On Fri, 13 May 2022 14:45:35 GMT, Brian Burkhalter wrote: >> src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 54: >> >>> 52: >>> 53: JNIEXPORT jlong JNICALL >>> 54: Java_sun_nio_ch_FileChannelImpl_initIDs(JNIEnv *env, jclass clazz) >> >> Hello Brian, now that this function doesn't initialize ids, should it instead be renamed to something else? Also the corresponding `initIDs` method on the Java side? And perhaps remove this comment from `FileChannelImpl.java`: >> >> >> // Caches fieldIDs >> private static native long initIDs(); > > Yeah I had thought of that as well but shined it on. I'll update before integrating. Resolved by 0c707e41492a682967f522ce03894f87a133a16f. ------------- PR: https://git.openjdk.java.net/jdk/pull/8689 From bpb at openjdk.java.net Fri May 13 15:45:38 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 13 May 2022 15:45:38 GMT Subject: RFR: 8286671: (fc) Modify sun.nio.ch.FileChannelImpl.map0() to accept a FileDescriptor parameter [v2] In-Reply-To: <_T6Fh8dIJGBoqUL32-aH_uMZGg29BpcZnYm30fvh7MY=.1687d8b6-7b9b-4043-98ed-e2bfcdb401fa@github.com> References: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> <_T6Fh8dIJGBoqUL32-aH_uMZGg29BpcZnYm30fvh7MY=.1687d8b6-7b9b-4043-98ed-e2bfcdb401fa@github.com> Message-ID: On Fri, 13 May 2022 06:52:17 GMT, Jaikiran Pai wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8286671: Rename initIDs() to allocationGranularity0() > > src/java.base/windows/native/libnio/ch/FileChannelImpl.c line 41: > >> 39: /************************************************************** >> 40: * static method to store field ID's in initializers >> 41: * and retrieve the allocation granularity > > Should we remove the "to store field ID's in initializers" part from this comment? Removed in 0c707e41492a682967f522ce03894f87a133a16f. ------------- PR: https://git.openjdk.java.net/jdk/pull/8689 From duke at openjdk.java.net Fri May 13 17:41:54 2022 From: duke at openjdk.java.net (Markus KARG) Date: Fri, 13 May 2022 17:41:54 GMT Subject: RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v16] In-Reply-To: References: Message-ID: On Sat, 25 Dec 2021 16:10:37 GMT, Markus KARG wrote: >> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel. > > Markus KARG has updated the pull request incrementally with three additional commits since the last revision: > > - separate test class for each large file test > - Base class only contains utilities and helpers > - Renamed AbstractTransferTo to TransferToBase as it is not abstract Please keep this PR open; I will continune work on it soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/6711 From duke at openjdk.java.net Fri May 13 17:41:59 2022 From: duke at openjdk.java.net (Markus KARG) Date: Fri, 13 May 2022 17:41:59 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: Message-ID: <8Dg7c3PUuuiJEPM6wWrl2LqBaagl0tz-jRXynJYA3do=.731b1132-0a19-4579-9dc6-aceaa21c8b8e@github.com> On Sun, 1 Aug 2021 22:01:33 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 updated the pull request incrementally with two additional commits since the last revision: > > - Draft: Eliminated duplicate code using lambda expressions > - Draft: Use blocking mode also for target channel Please keep this PR open; I will continune work on it soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From bpb at openjdk.java.net Fri May 13 17:50:44 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 13 May 2022 17:50:44 GMT Subject: Integrated: 8286671: (fc) Modify sun.nio.ch.FileChannelImpl.map0() to accept a FileDescriptor parameter In-Reply-To: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> References: <__pmZDgorrJynh9Fz6nUg4EtnQ-NC7ZlrV52AbuY_18=.38ceefb0-cd96-4db4-ac5e-c331b840e5fe@github.com> Message-ID: On Thu, 12 May 2022 23:34:35 GMT, Brian Burkhalter wrote: > Add a `FileDescriptor` as the first parameter of `map0()` and remove from the corresponding native code the use of `fd_chan`. This pull request has now been integrated. Changeset: 583a61aa Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/583a61aabbcd1646305323488da4452773248396 Stats: 22 lines in 3 files changed: 1 ins; 9 del; 12 mod 8286671: (fc) Modify sun.nio.ch.FileChannelImpl.map0() to accept a FileDescriptor parameter Reviewed-by: alanb, jpai ------------- PR: https://git.openjdk.java.net/jdk/pull/8689 From mcimadamore at openjdk.java.net Fri May 13 21:45:38 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 13 May 2022 21:45:38 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v2] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 23:27:30 GMT, Brian Burkhalter wrote: >> Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. > > Brian Burkhalter 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 four additional commits since the last revision: > > - 8286671: Update test pursuant to JEP 424 integration > - Merge > - 8286637: Update test with try-with-resources and to print less > - 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows Looks good! ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8686 From jvernee at openjdk.java.net Fri May 13 22:13:56 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 13 May 2022 22:13:56 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v2] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 23:27:30 GMT, Brian Burkhalter wrote: >> Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. > > Brian Burkhalter 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 four additional commits since the last revision: > > - 8286671: Update test pursuant to JEP 424 integration > - Merge > - 8286637: Update test with try-with-resources and to print less > - 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From alanb at openjdk.java.net Sat May 14 08:03:50 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 14 May 2022 08:03:50 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v2] In-Reply-To: References: Message-ID: <5_p1DbpR3_ul_f8Jpe8MaAzFc-kgajlDGoDjyDx0P_0=.eb813efc-b871-412f-aeae-441db1c99259@github.com> On Thu, 12 May 2022 23:27:30 GMT, Brian Burkhalter wrote: >> Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. > > Brian Burkhalter 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 four additional commits since the last revision: > > - 8286671: Update test pursuant to JEP 424 integration > - Merge > - 8286637: Update test with try-with-resources and to print less > - 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows test/jdk/java/nio/channels/FileChannel/LargeMapTest.java line 58: > 56: p.toFile().deleteOnExit(); > 57: try (RandomAccessFile raf = new RandomAccessFile(FILE, "rw");) { > 58: raf.setLength(LENGTH); //~8gb This is FileChannel test so I'm curious why it uses RAF here. I would have expected it to use FileChannel's position(LENGTH) and then write something as the spec is that this doesn't extend, a later write will extend it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From clanger at openjdk.java.net Sat May 14 11:00:54 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Sat, 14 May 2022 11:00:54 GMT Subject: Integrated: 8286594: (zipfs) Mention paths with dot elements in ZipException and cleanups In-Reply-To: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com> References: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com> Message-ID: On Wed, 11 May 2022 15:32:38 GMT, Christoph Langer wrote: > This augments the ZipException upon rejecting a Zip File containing entry names with "." or ".." elements. > > It furthermore tries to clean up & compact the logic for detecting "." and ".." and it adds a method IndexNode::nameAsString to return the node name as a String. This pull request has now been integrated. Changeset: 80cf9f34 Author: Christoph Langer URL: https://git.openjdk.java.net/jdk/commit/80cf9f3464c599fb7860432bf4ed506a3b298d8e Stats: 73 lines in 1 file changed: 31 ins; 38 del; 4 mod 8286594: (zipfs) Mention paths with dot elements in ZipException and cleanups Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/8655 From clanger at openjdk.java.net Sat May 14 11:00:52 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Sat, 14 May 2022 11:00:52 GMT Subject: RFR: 8286594: (zipfs) Mention paths with dot elements in ZipException and cleanups In-Reply-To: <-CY8VrgET0umvXMyeB9s7y_b9qsON3_mTD5IDtHiuyU=.aeeb6720-a674-42c5-bd6a-be864d9e2021@github.com> References: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com> <-CY8VrgET0umvXMyeB9s7y_b9qsON3_mTD5IDtHiuyU=.aeeb6720-a674-42c5-bd6a-be864d9e2021@github.com> Message-ID: On Wed, 11 May 2022 19:20:15 GMT, Lance Andersen wrote: >> This augments the ZipException upon rejecting a Zip File containing entry names with "." or ".." elements. >> >> It furthermore tries to clean up & compact the logic for detecting "." and ".." and it adds a method IndexNode::nameAsString to return the node name as a String. > > Looks good Christoph. Thank you for separating this out from the other PR Thanks @LanceAndersen for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8655 From aturbanov at openjdk.java.net Sun May 15 08:39:13 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Sun, 15 May 2022 08:39:13 GMT Subject: RFR: 8286366: (cs) Charset.put can use putIfAbsent instead of containsKey+put Message-ID: The method `Charset.put(Iterator i, Map m)` could be improved by usage of `Map.putIfAbsent` instead of pair `containsKey`+`put`. This method is called only with `TreeMap` as an argument and `TreeMap` has an effective implementation of `putIfAbsent` which avoid traversal Tree twice. According to [JDK-8176894](https://bugs.openjdk.java.net/browse/JDK-8176894) usage of `TreeMap.putIfAbsent` could improve performance by 40%-100% compared with previous approach. ------------- Commit messages: - [PATCH] Avoid redundant TreeMap.containsKey call in Charset.put Changes: https://git.openjdk.java.net/jdk/pull/8480/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8480&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286366 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8480.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8480/head:pull/8480 PR: https://git.openjdk.java.net/jdk/pull/8480 From alanb at openjdk.java.net Sun May 15 08:39:14 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 15 May 2022 08:39:14 GMT Subject: RFR: 8286366: (cs) Charset.put can use putIfAbsent instead of containsKey+put In-Reply-To: References: Message-ID: <0Zf2FViZwzH0BaGNM_EcoGL7tWk8WNgqdMPulv_IBW4=.b566f97a-7cb3-4975-8f37-8e524b0a93b5@github.com> On Sat, 30 Apr 2022 08:27:10 GMT, Andrey Turbanov wrote: > The method `Charset.put(Iterator i, Map m)` could be improved by usage of `Map.putIfAbsent` instead of pair `containsKey`+`put`. This method is called only with `TreeMap` as an argument and `TreeMap` has an effective implementation of `putIfAbsent` which avoid traversal Tree twice. > According to [JDK-8176894](https://bugs.openjdk.java.net/browse/JDK-8176894) usage of `TreeMap.putIfAbsent` could improve performance by 40%-100% compared with previous approach. src/java.base/share/classes/java/nio/charset/Charset.java line 569: > 567: while (i.hasNext()) { > 568: Charset cs = i.next(); > 569: m.putIfAbsent(cs.name(), cs); Yes, that would be a nicer. I've created JDK-8286366 for this. It could be changed to use for-each while you are there. ------------- PR: https://git.openjdk.java.net/jdk/pull/8480 From aturbanov at openjdk.java.net Sun May 15 10:26:43 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Sun, 15 May 2022 10:26:43 GMT Subject: RFR: 8286366: (cs) Charset.put can use putIfAbsent instead of containsKey+put In-Reply-To: <0Zf2FViZwzH0BaGNM_EcoGL7tWk8WNgqdMPulv_IBW4=.b566f97a-7cb3-4975-8f37-8e524b0a93b5@github.com> References: <0Zf2FViZwzH0BaGNM_EcoGL7tWk8WNgqdMPulv_IBW4=.b566f97a-7cb3-4975-8f37-8e524b0a93b5@github.com> Message-ID: On Sun, 8 May 2022 15:11:20 GMT, Alan Bateman wrote: > It could be changed to use for-each while you are there. Not sure I get the idea. Do you mean something like this: i.forEachRemaining(new Consumer() { @Override public void accept(Charset cs) { m.putIfAbsent(cs.name(), cs); } }); ------------- PR: https://git.openjdk.java.net/jdk/pull/8480 From aturbanov at openjdk.java.net Sun May 15 10:31:20 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Sun, 15 May 2022 10:31:20 GMT Subject: RFR: 8285519: Change usages of TimeUnit.convert to TimeUnit.toXXX [v2] In-Reply-To: References: Message-ID: <-HXGIdvip8kNCtVfJk4nceMYxRjst0UkmuVkvWXEtr8=.9e0636d1-8ade-4052-8f05-a42def897bed@github.com> > TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster. > Compared via JMH benchmark: 150ns -> 125ns/op >

> Benchamark adapted from http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java > > > @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS) > @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS) > @Fork(1) > @State(Scope.Thread) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class TimeUnitBench { > > static final int SIZE = TimeUnit.values().length * 10; > > @Param({"0", "1", "2", "3", "4", "5", "6", "-1"}) > int bias; > > TimeUnit[] mod; > > @Setup > public void setup() { > mod = new TimeUnit[SIZE]; > > TimeUnit[] vals = TimeUnit.values(); > for (int c = 0; c < SIZE; c++) { > if (bias == -1) { > // megamorphic > mod[c] = vals[c % vals.length]; > } else { > mod[c] = vals[bias]; > } > } > > Random r = new Random(); > for (int c = 0; c < 10000; c++) { > int i = r.nextInt(); > for (int o = 0; o < vals.length; o++) { > if (vals[o].toNanos(i) != TimeUnit.NANOSECONDS.convert(i, vals[o])) > throw new IllegalStateException("switch " + o); > } > } > } > > @Benchmark > public void const_convert(Blackhole bh) { > for (TimeUnit tu : mod) { > bh.consume(do_convert(tu)); > } > } > > @Benchmark > public void value_convert(Blackhole bh) { > for (TimeUnit tu : mod) { > bh.consume(do_convert(tu, 1L)); > } > } > > @Benchmark > public void const_toNanos(Blackhole bh) { > for (TimeUnit tu : mod) { > bh.consume(do_toNanos(tu)); > } > } > > @Benchmark > public void value_toNanos(Blackhole bh) { > for (TimeUnit tu : mod) { > bh.consume(do_toNanos(tu, 1L)); > } > } > > @CompilerControl(CompilerControl.Mode.DONT_INLINE) > private long do_toNanos(TimeUnit tu) { > return tu.toNanos(1L); > } > > @CompilerControl(CompilerControl.Mode.DONT_INLINE) > private long do_toNanos(TimeUnit tu, long value) { > return tu.toNanos(value); > } > > @CompilerControl(CompilerControl.Mode.DONT_INLINE) > private long do_convert(TimeUnit tu) { > return TimeUnit.NANOSECONDS.convert(1L, tu); > } > > @CompilerControl(CompilerControl.Mode.DONT_INLINE) > private long do_convert(TimeUnit tu, long value) { > return TimeUnit.NANOSECONDS.convert(value, tu); > } > } > > Results: > > Benchmark (bias) Mode Cnt Score Error Units > TimeUnitBench.const_convert 0 avgt 5 151,856 ? 28,595 ns/op > TimeUnitBench.const_convert 1 avgt 5 150,720 ? 23,863 ns/op > TimeUnitBench.const_convert 2 avgt 5 151,432 ? 23,184 ns/op > TimeUnitBench.const_convert 3 avgt 5 150,959 ? 24,726 ns/op > TimeUnitBench.const_convert 4 avgt 5 150,966 ? 25,280 ns/op > TimeUnitBench.const_convert 5 avgt 5 150,976 ? 25,542 ns/op > TimeUnitBench.const_convert 6 avgt 5 151,118 ? 25,254 ns/op > TimeUnitBench.const_convert -1 avgt 5 152,673 ? 29,861 ns/op > TimeUnitBench.const_toNanos 0 avgt 5 121,296 ? 25,236 ns/op > TimeUnitBench.const_toNanos 1 avgt 5 121,707 ? 25,364 ns/op > TimeUnitBench.const_toNanos 2 avgt 5 121,736 ? 25,726 ns/op > TimeUnitBench.const_toNanos 3 avgt 5 121,822 ? 25,491 ns/op > TimeUnitBench.const_toNanos 4 avgt 5 121,867 ? 26,090 ns/op > TimeUnitBench.const_toNanos 5 avgt 5 121,927 ? 25,611 ns/op > TimeUnitBench.const_toNanos 6 avgt 5 121,821 ? 25,843 ns/op > TimeUnitBench.const_toNanos -1 avgt 5 121,923 ? 25,206 ns/op > TimeUnitBench.value_convert 0 avgt 5 150,525 ? 25,439 ns/op > TimeUnitBench.value_convert 1 avgt 5 151,098 ? 24,024 ns/op > TimeUnitBench.value_convert 2 avgt 5 151,259 ? 25,381 ns/op > TimeUnitBench.value_convert 3 avgt 5 151,030 ? 25,548 ns/op > TimeUnitBench.value_convert 4 avgt 5 151,290 ? 25,998 ns/op > TimeUnitBench.value_convert 5 avgt 5 151,006 ? 25,448 ns/op > TimeUnitBench.value_convert 6 avgt 5 150,945 ? 25,314 ns/op > TimeUnitBench.value_convert -1 avgt 5 151,186 ? 25,814 ns/op > TimeUnitBench.value_toNanos 0 avgt 5 121,556 ? 25,745 ns/op > TimeUnitBench.value_toNanos 1 avgt 5 123,410 ? 22,323 ns/op > TimeUnitBench.value_toNanos 2 avgt 5 125,452 ? 26,575 ns/op > TimeUnitBench.value_toNanos 3 avgt 5 125,297 ? 26,204 ns/op > TimeUnitBench.value_toNanos 4 avgt 5 125,357 ? 26,085 ns/op > TimeUnitBench.value_toNanos 5 avgt 5 125,165 ? 26,185 ns/op > TimeUnitBench.value_toNanos 6 avgt 5 125,536 ? 25,487 ns/op > TimeUnitBench.value_toNanos -1 avgt 5 125,460 ? 25,063 ns/op > > >
Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge remote-tracking branch 'origin/master' into Use_direct_TimeUnit.toSome_instead_of_TimeUnit.convert # Conflicts: # src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java # src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java - [PATCH] Simplify TimeUnit.convert calls to TimeUnit.toSomething instead ------------- Changes: https://git.openjdk.java.net/jdk/pull/8376/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8376&range=01 Stats: 24 lines in 4 files changed: 2 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/8376.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8376/head:pull/8376 PR: https://git.openjdk.java.net/jdk/pull/8376 From alanb at openjdk.java.net Sun May 15 13:52:47 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 15 May 2022 13:52:47 GMT Subject: RFR: 8286366: (cs) Charset.put can use putIfAbsent instead of containsKey+put In-Reply-To: References: <0Zf2FViZwzH0BaGNM_EcoGL7tWk8WNgqdMPulv_IBW4=.b566f97a-7cb3-4975-8f37-8e524b0a93b5@github.com> Message-ID: On Sun, 15 May 2022 10:23:11 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/java/nio/charset/Charset.java line 569: >> >>> 567: while (i.hasNext()) { >>> 568: Charset cs = i.next(); >>> 569: m.putIfAbsent(cs.name(), cs); >> >> Yes, that would be a nicer. I've created JDK-8286366 for this. It could be changed to use for-each while you are there. > >> It could be changed to use for-each while you are there. > > Not sure I get the idea. > Do you mean something like this: > > i.forEachRemaining(new Consumer() { > @Override > public void accept(Charset cs) { > m.putIfAbsent(cs.name(), cs); > } > }); Sorry for the confusion, I thought I was looking at an Iterable at the time. ------------- PR: https://git.openjdk.java.net/jdk/pull/8480 From duke at openjdk.java.net Mon May 16 15:32:41 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 16 May 2022 15:32:41 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: References: <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com> <8kThIsE5ikFJ_V3Y9ixYKlNcuMPg77ci974Q63wCH_Y=.69d3e25a-4091-4e9d-9da5-18054148744c@github.com> Message-ID: On Fri, 13 May 2022 13:36:52 GMT, ExE Boss wrote: > So if anything, the List.of(?) call should be moved into the ProxyMethod constructor. And maybe the call to Method.getExceptionTypes() should be changed to Method.getSharedExceptionTypes() Makes sense. Do you want me to do this within this PR (this would be a deviation from ticket's target), or it's better to create another one? ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From bpb at openjdk.java.net Mon May 16 16:03:46 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 16 May 2022 16:03:46 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v3] In-Reply-To: References: Message-ID: > Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8286671: Replace use of RandomAccessFile with FileChannel ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8686/files - new: https://git.openjdk.java.net/jdk/pull/8686/files/b5c3b0d9..c689423d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8686&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8686&range=01-02 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8686.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8686/head:pull/8686 PR: https://git.openjdk.java.net/jdk/pull/8686 From jvernee at openjdk.java.net Mon May 16 16:36:35 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 16 May 2022 16:36:35 GMT Subject: RFR: 8286715: Generalize MemorySegment::ofBuffer In-Reply-To: References: Message-ID: On Fri, 13 May 2022 12:33:10 GMT, Maurizio Cimadamore wrote: > This patch makes MemorySegment::ofBuffer more general, by allowing clients to pass *any* `Buffer` instance, not just `ByteBuffer`. > This allows us to match expressiveness of JNI API, where JNI clients can obtain the address of any direct buffer instance, using the `GetDirectBufferAddress` function. > > We thought about also providing a more general way to view a segment as a buffer (e.g. asIntBuffer) but doing that doesn't seem worth it: direct buffers can only created form `ByteBuffer`. > So, to create a direct `IntBuffer`, clients have to first create a direct `ByteBuffer` then to view that buffer as an `IntBuffer`. > > In other words, `IntBuffer` and friends are not first-class citizens in the `Buffer` API. As such it would not be possible to map many memory segments into an `IntBuffer`; in fact, the only segment we could safely map into an `IntBuffer` would be an _heap_ segment backed by an `int[]`. As such it doesn't seem worth adding a lot of API surface (in terms of additional overloads) for such a corner case. Marked as reviewed by jvernee (Reviewer). src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 572: > 570: return new NativeMemorySegmentImpl(bbAddress + (pos << scaleFactor), size << scaleFactor, modes, bufferSession); > 571: } else { > 572: // we can ignore scale factor here, a mapped buffer is always a byte buffer, so scaleFactor == 1. Suggestion: // we can ignore scale factor here, a mapped buffer is always a byte buffer, so scaleFactor == 0. ------------- PR: https://git.openjdk.java.net/jdk/pull/8701 From bpb at openjdk.java.net Mon May 16 18:21:20 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 16 May 2022 18:21:20 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v4] In-Reply-To: References: Message-ID: <83zdDv2C73wB3MY-OHnDOCpW9QNHPhk3Nh9BKzJIThw=.74278170-f374-450b-9444-62b876ba429e@github.com> > Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. Brian Burkhalter 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: 8286671: Replace use of RandomAccessFile with FileChannel ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8686/files - new: https://git.openjdk.java.net/jdk/pull/8686/files/c689423d..0ec8134f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8686&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8686&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8686.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8686/head:pull/8686 PR: https://git.openjdk.java.net/jdk/pull/8686 From bpb at openjdk.java.net Mon May 16 18:29:36 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 16 May 2022 18:29:36 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v2] In-Reply-To: <5_p1DbpR3_ul_f8Jpe8MaAzFc-kgajlDGoDjyDx0P_0=.eb813efc-b871-412f-aeae-441db1c99259@github.com> References: <5_p1DbpR3_ul_f8Jpe8MaAzFc-kgajlDGoDjyDx0P_0=.eb813efc-b871-412f-aeae-441db1c99259@github.com> Message-ID: On Sat, 14 May 2022 07:59:59 GMT, Alan Bateman wrote: >> Brian Burkhalter 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 four additional commits since the last revision: >> >> - 8286671: Update test pursuant to JEP 424 integration >> - Merge >> - 8286637: Update test with try-with-resources and to print less >> - 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows > > test/jdk/java/nio/channels/FileChannel/LargeMapTest.java line 58: > >> 56: p.toFile().deleteOnExit(); >> 57: try (RandomAccessFile raf = new RandomAccessFile(FILE, "rw");) { >> 58: raf.setLength(LENGTH); //~8gb > > This is FileChannel test so I'm curious why it uses RAF here. I would have expected it to use FileChannel's position(LENGTH) and then write something as the spec is that this doesn't extend, a later write will extend it. Fixed by 0ec8134febd4595ed091741ff1bdc45622b6a17d. ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From alanb at openjdk.java.net Mon May 16 18:45:36 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 16 May 2022 18:45:36 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v4] In-Reply-To: <83zdDv2C73wB3MY-OHnDOCpW9QNHPhk3Nh9BKzJIThw=.74278170-f374-450b-9444-62b876ba429e@github.com> References: <83zdDv2C73wB3MY-OHnDOCpW9QNHPhk3Nh9BKzJIThw=.74278170-f374-450b-9444-62b876ba429e@github.com> Message-ID: On Mon, 16 May 2022 18:21:20 GMT, Brian Burkhalter wrote: >> Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. > > Brian Burkhalter 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: > > 8286671: Replace use of RandomAccessFile with FileChannel Marked as reviewed by alanb (Reviewer). test/jdk/java/nio/channels/FileChannel/LargeMapTest.java line 38: > 36: * @enablePreview > 37: * @bug 8286637 > 38: * @requires os.family == "windows" What was the conclusion on whether this test should run everywhere? test/jdk/java/nio/channels/FileChannel/LargeMapTest.java line 56: > 54: Path p = Path.of(FILE); > 55: p.toFile().deleteOnExit(); > 56: try (FileChannel fc = FileChannel.open(p, CREATE, WRITE);) { spurious semicolon has snuck in here ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From bpb at openjdk.java.net Mon May 16 20:21:56 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 16 May 2022 20:21:56 GMT Subject: RFR: 8286763: [REDO] (fc) Tune FileChannel.transferFrom() Message-ID: Re-do the fix for [JDK-8274113](https://bugs.openjdk.java.net/browse/JDK-8274113) which was reverted by [JDK-8286677.](https://bugs.openjdk.java.net/browse/JDK-8286677) ------------- Commit messages: - 8286763: [REDO] (fc) Tune FileChannel.transferFrom() Changes: https://git.openjdk.java.net/jdk/pull/8733/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8733&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286763 Stats: 131 lines in 4 files changed: 117 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/8733.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8733/head:pull/8733 PR: https://git.openjdk.java.net/jdk/pull/8733 From bpb at openjdk.java.net Mon May 16 20:21:58 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 16 May 2022 20:21:58 GMT Subject: RFR: 8286763: [REDO] (fc) Tune FileChannel.transferFrom() In-Reply-To: References: Message-ID: On Mon, 16 May 2022 20:14:07 GMT, Brian Burkhalter wrote: > Re-do the fix for [JDK-8274113](https://bugs.openjdk.java.net/browse/JDK-8274113) which was reverted by [JDK-8286677.](https://bugs.openjdk.java.net/browse/JDK-8286677) The problem was found to be that [copy_file_range(2)](https://man7.org/linux/man-pages/man2/copy_file_range.2.html) failed with `EBADF` due to the target having been opened with the `O_APPEND` flag set. This error occurred on Linux 5.4.17-2102.206.1.el8uek.aarch64 (aarch64) but not on Linux 5.11.0-49-generic (amd64) which we conjecture is due to the restriction having been relaxed in the newer version of the kernel. The change with respect to #8644 is to return `IOS_UNSUPPORTED_CASE` from `transferFrom0()` for an `EBADF` error rather than throwing an `IOException`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8733 From mcimadamore at openjdk.java.net Mon May 16 20:56:26 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 16 May 2022 20:56:26 GMT Subject: RFR: 8286715: Generalize MemorySegment::ofBuffer [v2] In-Reply-To: References: Message-ID: > This patch makes MemorySegment::ofBuffer more general, by allowing clients to pass *any* `Buffer` instance, not just `ByteBuffer`. > This allows us to match expressiveness of JNI API, where JNI clients can obtain the address of any direct buffer instance, using the `GetDirectBufferAddress` function. > > We thought about also providing a more general way to view a segment as a buffer (e.g. asIntBuffer) but doing that doesn't seem worth it: direct buffers can only created form `ByteBuffer`. > So, to create a direct `IntBuffer`, clients have to first create a direct `ByteBuffer` then to view that buffer as an `IntBuffer`. > > In other words, `IntBuffer` and friends are not first-class citizens in the `Buffer` API. As such it would not be possible to map many memory segments into an `IntBuffer`; in fact, the only segment we could safely map into an `IntBuffer` would be an _heap_ segment backed by an `int[]`. As such it doesn't seem worth adding a lot of API surface (in terms of additional overloads) for such a corner case. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java Co-authored-by: Jorn Vernee ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8701/files - new: https://git.openjdk.java.net/jdk/pull/8701/files/02494e2f..b6629787 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8701&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8701&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8701.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8701/head:pull/8701 PR: https://git.openjdk.java.net/jdk/pull/8701 From bpb at openjdk.java.net Tue May 17 01:20:02 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 17 May 2022 01:20:02 GMT Subject: RFR: 8286735: (fc) FileChannel#map should document behavior when using custom file systems Message-ID: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com> Clarify when the `map()` methods of `java.nio.channels.FileChannel` throw an `UnsupportedOperationException`. ------------- Commit messages: - 8286735: (fc) FileChannel#map should document behavior when using custom file systems Changes: https://git.openjdk.java.net/jdk/pull/8739/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8739&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286735 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8739.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8739/head:pull/8739 PR: https://git.openjdk.java.net/jdk/pull/8739 From bpb at openjdk.java.net Tue May 17 03:18:09 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 17 May 2022 03:18:09 GMT Subject: RFR: 8286734: (fc) FileChannelImpl#map() cleanup after merge of Foreign Function & Memory API Message-ID: <-Beph8kGAC2-Pi7pKwspCAjgv7nX9jEZdqBM44G5ZSk=.91ffcd24-da6b-431d-a0dd-f20327c7f9b8@github.com> Make `map()` methods more consistent. ------------- Commit messages: - 8286734: (fc) FileChannelImpl#map() cleanup after merge of Foreign Function & Memory API Changes: https://git.openjdk.java.net/jdk/pull/8741/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8741&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286734 Stats: 12 lines in 1 file changed: 4 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8741.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8741/head:pull/8741 PR: https://git.openjdk.java.net/jdk/pull/8741 From alanb at openjdk.java.net Tue May 17 06:52:33 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 17 May 2022 06:52:33 GMT Subject: RFR: 8286763: [REDO] (fc) Tune FileChannel.transferFrom() In-Reply-To: References: Message-ID: On Mon, 16 May 2022 20:14:07 GMT, Brian Burkhalter wrote: > Re-do the fix for [JDK-8274113](https://bugs.openjdk.java.net/browse/JDK-8274113) which was reverted by [JDK-8286677.](https://bugs.openjdk.java.net/browse/JDK-8286677) src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 281: > 279: if ((errno == EBADF || errno == EINVAL || errno == EXDEV) && > 280: ((ssize_t)count >= 0)) > 281: return IOS_UNSUPPORTED_CASE; I don't think you can return IOS_UNSUPPORTED_CASE for the these cases because it will disable the use of copy_file_range for the everyone and all channels. So I think we'll need to think through whether the append and overlap cases where we checked first or return IOS_UNSUPPORTED_CASE does not disable it for everyone. I think the former is probably better. ------------- PR: https://git.openjdk.java.net/jdk/pull/8733 From alanb at openjdk.java.net Tue May 17 06:53:49 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 17 May 2022 06:53:49 GMT Subject: RFR: 8286366: (cs) Charset.put can use putIfAbsent instead of containsKey+put In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 08:27:10 GMT, Andrey Turbanov wrote: > The method `Charset.put(Iterator i, Map m)` could be improved by usage of `Map.putIfAbsent` instead of pair `containsKey`+`put`. This method is called only with `TreeMap` as an argument and `TreeMap` has an effective implementation of `putIfAbsent` which avoid traversal Tree twice. > According to [JDK-8176894](https://bugs.openjdk.java.net/browse/JDK-8176894) usage of `TreeMap.putIfAbsent` could improve performance by 40%-100% compared with previous approach. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8480 From alanb at openjdk.java.net Tue May 17 07:04:45 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 17 May 2022 07:04:45 GMT Subject: RFR: 8286735: (fc) FileChannel#map should document behavior when using custom file systems In-Reply-To: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com> References: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com> Message-ID: <0sa6lSeQvaoQVLrJLVpWCXSRpLJ5QGO8x7mqfDm55cU=.f48afa50-b4ef-44d9-8c1c-157ff1ef5bbf@github.com> On Tue, 17 May 2022 01:12:55 GMT, Brian Burkhalter wrote: > Clarify when the `map()` methods of `java.nio.channels.FileChannel` throw an `UnsupportedOperationException`. I think this feature request will require a lot more discussion on what the right level of optionality is. If a custom file system provider does not support all features (file locking, memory-mapped files, ..) then FileSystemProvider::newFileChannel should throw UOE. ------------- Changes requested by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8739 From ihse at openjdk.java.net Tue May 17 12:14:52 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 17 May 2022 12:14:52 GMT Subject: Integrated: 8285485: Fix typos in corelibs In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 15:08:51 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos. > > I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). > > The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. This pull request has now been integrated. Changeset: e68024c2 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/e68024c2d28d634ebfde7f2fdcc35f5d7b07d704 Stats: 295 lines in 101 files changed: 0 ins; 0 del; 295 mod 8285485: Fix typos in corelibs Reviewed-by: jpai, sundar, naoto, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/8364 From bpb at openjdk.java.net Tue May 17 15:26:11 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 17 May 2022 15:26:11 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v4] In-Reply-To: References: <83zdDv2C73wB3MY-OHnDOCpW9QNHPhk3Nh9BKzJIThw=.74278170-f374-450b-9444-62b876ba429e@github.com> Message-ID: On Mon, 16 May 2022 18:42:04 GMT, Alan Bateman wrote: >> Brian Burkhalter 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: >> >> 8286671: Replace use of RandomAccessFile with FileChannel > > test/jdk/java/nio/channels/FileChannel/LargeMapTest.java line 38: > >> 36: * @enablePreview >> 37: * @bug 8286637 >> 38: * @requires os.family == "windows" > > What was the conclusion on whether this test should run everywhere? There wasn't one exactly. I am currently testing on all main platforms with 20 repeats. If that succeeds perhaps it should be allowed to run on all. ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From bpb at openjdk.java.net Tue May 17 15:31:55 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 17 May 2022 15:31:55 GMT Subject: RFR: 8286763: [REDO] (fc) Tune FileChannel.transferFrom() In-Reply-To: References: Message-ID: On Tue, 17 May 2022 06:49:47 GMT, Alan Bateman wrote: >> Re-do the fix for [JDK-8274113](https://bugs.openjdk.java.net/browse/JDK-8274113) which was reverted by [JDK-8286677.](https://bugs.openjdk.java.net/browse/JDK-8286677) > > src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 281: > >> 279: if ((errno == EBADF || errno == EINVAL || errno == EXDEV) && >> 280: ((ssize_t)count >= 0)) >> 281: return IOS_UNSUPPORTED_CASE; > > I don't think you can return IOS_UNSUPPORTED_CASE for the these cases because it will disable the use of copy_file_range for the everyone and all channels. So I think we'll need to think through whether the append and overlap cases where we checked first or return IOS_UNSUPPORTED_CASE does not disable it for everyone. I think the former is probably better. Isn't it that returning `IOS_UNSUPPORTED` would disable it for everyone? I thought that `IOS_UNSUPPORTED_CASE` allows it to be tried again. Of course one could check for append or overlap in the Java layer instead. I actually had it that way initially for the overlap case but removed it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8733 From alanb at openjdk.java.net Tue May 17 15:38:48 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 17 May 2022 15:38:48 GMT Subject: RFR: 8286763: [REDO] (fc) Tune FileChannel.transferFrom() In-Reply-To: References: Message-ID: On Tue, 17 May 2022 15:29:52 GMT, Brian Burkhalter wrote: > Isn't it that returning `IOS_UNSUPPORTED` would disable it for everyone? I thought that `IOS_UNSUPPORTED_CASE` allows it to be tried again. Of course one could check for append or overlap in the Java layer instead. I actually had it that way initially for the overlap case but removed it. Oh I see, it's only IOS_UNSUPPORTED that disables it. With IOS_UNSUPPORTED_CASE then you may retry it again. ------------- PR: https://git.openjdk.java.net/jdk/pull/8733 From alanb at openjdk.java.net Tue May 17 15:39:48 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 17 May 2022 15:39:48 GMT Subject: RFR: 8286734: (fc) FileChannelImpl#map() cleanup after merge of Foreign Function & Memory API In-Reply-To: <-Beph8kGAC2-Pi7pKwspCAjgv7nX9jEZdqBM44G5ZSk=.91ffcd24-da6b-431d-a0dd-f20327c7f9b8@github.com> References: <-Beph8kGAC2-Pi7pKwspCAjgv7nX9jEZdqBM44G5ZSk=.91ffcd24-da6b-431d-a0dd-f20327c7f9b8@github.com> Message-ID: On Tue, 17 May 2022 03:11:10 GMT, Brian Burkhalter wrote: > Make `map()` methods more consistent. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8741 From bpb at openjdk.java.net Tue May 17 15:46:54 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 17 May 2022 15:46:54 GMT Subject: RFR: 8286763: [REDO] (fc) Tune FileChannel.transferFrom() In-Reply-To: References: Message-ID: On Tue, 17 May 2022 15:34:50 GMT, Alan Bateman wrote: >> Isn't it that returning `IOS_UNSUPPORTED` would disable it for everyone? I thought that `IOS_UNSUPPORTED_CASE` allows it to be tried again. Of course one could check for append or overlap in the Java layer instead. I actually had it that way initially for the overlap case but removed it. > >> Isn't it that returning `IOS_UNSUPPORTED` would disable it for everyone? I thought that `IOS_UNSUPPORTED_CASE` allows it to be tried again. Of course one could check for append or overlap in the Java layer instead. I actually had it that way initially for the overlap case but removed it. > > Oh I see, it's only IOS_UNSUPPORTED that disables it. With IOS_UNSUPPORTED_CASE then you may retry it again. Correct. It is IOS_UNSUPPORTED for example if the copy_file_range function pointer is NULL (not available via dlsym()). Then of course one can do nothing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8733 From bpb at openjdk.java.net Tue May 17 16:08:46 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 17 May 2022 16:08:46 GMT Subject: RFR: 8286735: (fc) FileChannel#map should document behavior when using custom file systems In-Reply-To: <0sa6lSeQvaoQVLrJLVpWCXSRpLJ5QGO8x7mqfDm55cU=.f48afa50-b4ef-44d9-8c1c-157ff1ef5bbf@github.com> References: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com> <0sa6lSeQvaoQVLrJLVpWCXSRpLJ5QGO8x7mqfDm55cU=.f48afa50-b4ef-44d9-8c1c-157ff1ef5bbf@github.com> Message-ID: On Tue, 17 May 2022 07:01:53 GMT, Alan Bateman wrote: > I think this feature request will require a lot more discussion on what the right level of optionality is. If a custom file system provider does not support all features (file locking, memory-mapped files, ..) then FileSystemProvider::newFileChannel should throw UOE. I wonder whether for the immediate purpose for which this issue was filed the changes to the `@throws UnsupportedOperationException` clauses should be removed and only the new `@implSpec` retained? ------------- PR: https://git.openjdk.java.net/jdk/pull/8739 From bpb at openjdk.java.net Tue May 17 16:30:56 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 17 May 2022 16:30:56 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v4] In-Reply-To: References: <83zdDv2C73wB3MY-OHnDOCpW9QNHPhk3Nh9BKzJIThw=.74278170-f374-450b-9444-62b876ba429e@github.com> Message-ID: On Tue, 17 May 2022 15:23:00 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/channels/FileChannel/LargeMapTest.java line 38: >> >>> 36: * @enablePreview >>> 37: * @bug 8286637 >>> 38: * @requires os.family == "windows" >> >> What was the conclusion on whether this test should run everywhere? > > There wasn't one exactly. I am currently testing on all main platforms with 20 repeats. If that succeeds perhaps it should be allowed to run on all. 20 test repeats passed on all main platforms in the CI. ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From alanb at openjdk.java.net Tue May 17 17:27:54 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 17 May 2022 17:27:54 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v4] In-Reply-To: References: <83zdDv2C73wB3MY-OHnDOCpW9QNHPhk3Nh9BKzJIThw=.74278170-f374-450b-9444-62b876ba429e@github.com> Message-ID: On Tue, 17 May 2022 16:27:14 GMT, Brian Burkhalter wrote: >> There wasn't one exactly. I am currently testing on all main platforms with 20 repeats. If that succeeds perhaps it should be allowed to run on all. > > 20 test repeats passed on all main platforms in the CI. Good. You might want to check the execution times in case the test needs to run with /timeout set to some large value. I think we've had to do that a few other tests that create multi GB files. ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From bpb at openjdk.java.net Tue May 17 17:53:46 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 17 May 2022 17:53:46 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v4] In-Reply-To: References: <83zdDv2C73wB3MY-OHnDOCpW9QNHPhk3Nh9BKzJIThw=.74278170-f374-450b-9444-62b876ba429e@github.com> Message-ID: On Tue, 17 May 2022 17:24:06 GMT, Alan Bateman wrote: >> 20 test repeats passed on all main platforms in the CI. > > Good. You might want to check the execution times in case the test needs to run with /timeout set to some large value. I think we've had to do that a few other tests that create multi GB files. Longest elapsed execution time that I see in the 20-repeat test was on a Mac Mini: 23.351 seconds. ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From bpb at openjdk.java.net Tue May 17 19:46:49 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 17 May 2022 19:46:49 GMT Subject: Integrated: 8286734: (fc) FileChannelImpl#map() cleanup after merge of Foreign Function & Memory API In-Reply-To: <-Beph8kGAC2-Pi7pKwspCAjgv7nX9jEZdqBM44G5ZSk=.91ffcd24-da6b-431d-a0dd-f20327c7f9b8@github.com> References: <-Beph8kGAC2-Pi7pKwspCAjgv7nX9jEZdqBM44G5ZSk=.91ffcd24-da6b-431d-a0dd-f20327c7f9b8@github.com> Message-ID: On Tue, 17 May 2022 03:11:10 GMT, Brian Burkhalter wrote: > Make `map()` methods more consistent. This pull request has now been integrated. Changeset: 5bea4611 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/5bea46110c3ec9c6c17c00b13d1578cb2981ce51 Stats: 12 lines in 1 file changed: 4 ins; 0 del; 8 mod 8286734: (fc) FileChannelImpl#map() cleanup after merge of Foreign Function & Memory API Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8741 From bpb at openjdk.java.net Wed May 18 00:15:45 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 18 May 2022 00:15:45 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v5] In-Reply-To: References: Message-ID: > Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8286671: Allow test to run on all platforms ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8686/files - new: https://git.openjdk.java.net/jdk/pull/8686/files/0ec8134f..7f3536ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8686&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8686&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8686.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8686/head:pull/8686 PR: https://git.openjdk.java.net/jdk/pull/8686 From alanb at openjdk.java.net Wed May 18 07:06:00 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 18 May 2022 07:06:00 GMT Subject: RFR: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows [v5] In-Reply-To: References: Message-ID: <1ylmKzX4njVSzxJXX6BHin699CO9sM_YMK1ryJFrpeE=.0db823a9-e643-4051-99b2-3f003ad1851d@github.com> On Wed, 18 May 2022 00:15:45 GMT, Brian Burkhalter wrote: >> Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8286671: Allow test to run on all platforms Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From alanb at openjdk.java.net Wed May 18 07:25:55 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 18 May 2022 07:25:55 GMT Subject: RFR: 8286735: (fc) FileChannel#map should document behavior when using custom file systems In-Reply-To: References: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com> <0sa6lSeQvaoQVLrJLVpWCXSRpLJ5QGO8x7mqfDm55cU=.f48afa50-b4ef-44d9-8c1c-157ff1ef5bbf@github.com> Message-ID: <-jNs7Dxb5SJCHEF7yMruKsYyOqx8ikTRMCma-XP6f58=.72fb3643-8d43-4f75-b501-c0f5bf214b3a@github.com> On Tue, 17 May 2022 16:05:37 GMT, Brian Burkhalter wrote: > > I think this feature request will require a lot more discussion on what the right level of optionality is. If a custom file system provider does not support all features (file locking, memory-mapped files, ..) then FileSystemProvider::newFileChannel should throw UOE. > > I wonder whether for the immediate purpose for which this issue was filed the changes to the `@throws UnsupportedOperationException` clauses should be removed and only the new `@implSpec` retained? JDK-8286735 is a request for finer grain optionality. It cannot be evaluated in isolation because there will be others that will want file locking, or positional read/write to be optional too. The long standing position on this topic is that custom file system providers are not required to support FileChannel (FileSystemProvider::newFileChannel can throw UOE) so I think we have to be cautious about changing this because it would make FileChannel unusable - if you give me a reference to a FileChannel then I couldn't rely on anything if every feature were optional. The change that adds an implSpec to the new FileChannel.map is okay but it's probably a separate JBS issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/8739 From duke at openjdk.java.net Wed May 18 08:46:08 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 18 May 2022 08:46:08 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v4] In-Reply-To: References: Message-ID: <3DlU-JyFxA4D-e10Rh5qdEpsb3dbPMtfKrdqEHTbWkM=.a7ae971e-908c-495d-b7b4-8f833839fd7d@github.com> > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null ?????? ??????? 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: - 8282662: Revert ProxyGenerator - 8282662: Revert ProxyGenerator - 8282662: Revert dubious changes in MethodType - 8282662: Revert dubious changes - 8282662: Use List/Set.of() factory methods to save memory ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7729/files - new: https://git.openjdk.java.net/jdk/pull/7729/files/e765c42a..87c6623b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=02-03 Stats: 575367 lines in 7617 files changed: 421069 ins; 87224 del; 67074 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729 From duke at openjdk.java.net Wed May 18 08:46:09 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 18 May 2022 08:46:09 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: References: <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com> <8kThIsE5ikFJ_V3Y9ixYKlNcuMPg77ci974Q63wCH_Y=.69d3e25a-4091-4e9d-9da5-18054148744c@github.com> Message-ID: On Mon, 16 May 2022 15:29:38 GMT, ?????? ??????? wrote: >> Even?in the?no?exceptions?case, the?`exceptionTypes`?array still?has to?be?allocated/copied by?`Method.getExceptionTypes()`[^1] when?the?`ProxyMethod`?constructor[^2] is?invoked. >> >> So?if?anything, the?`List.of(?)`?call should?be?moved into?the?`ProxyMethod`?constructor. >> And?maybe the?call to?`Method.getExceptionTypes()` should?be?changed to?`Method.getSharedExceptionTypes()`[^3]. >> >> [^1]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/Method.java#L340-L343 >> [^2]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#L710-L714 >> [^3]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/Method.java#L305-L308 > >> So if anything, the List.of(?) call should be moved into the ProxyMethod constructor. And maybe the call to Method.getExceptionTypes() should be changed to Method.getSharedExceptionTypes() > > Makes sense. Do you want me to do this within this PR (this would be a deviation from ticket's target), or it's better to create another one? Ok, I've reverted `ProxyGenerator` and will include the changes into another PR ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From aivanov at openjdk.java.net Wed May 18 13:34:24 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 18 May 2022 13:34:24 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base Message-ID: Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? Also, I fixed a couple of spelling mistakes. ------------- Commit messages: - 8284191: Replace usages of 'the an' in hotspot and java.base - 8284191: Replace usages of 'the an' in hotspot and java.base - 8284191: Replace usages of 'the an' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - ... and 13 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...c7e73658 Changes: https://git.openjdk.java.net/jdk/pull/8768/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284191 Stats: 202 lines in 162 files changed: 0 ins; 11 del; 191 mod Patch: https://git.openjdk.java.net/jdk/pull/8768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768 PR: https://git.openjdk.java.net/jdk/pull/8768 From lancea at openjdk.java.net Wed May 18 14:42:53 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 18 May 2022 14:42:53 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From duke at openjdk.java.net Wed May 18 14:48:16 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 18 May 2022 14:48:16 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v5] In-Reply-To: References: Message-ID: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - 8282662: Revert wrong copyright year change - 8282662: Revert ProxyGenerator - 8282662: Revert ProxyGenerator - 8282662: Revert dubious changes in MethodType - 8282662: Revert dubious changes - 8282662: Use List/Set.of() factory methods to save memory ------------- Changes: https://git.openjdk.java.net/jdk/pull/7729/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=04 Stats: 12 lines in 4 files changed: 1 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729 From bpb at openjdk.java.net Wed May 18 14:53:05 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 18 May 2022 14:53:05 GMT Subject: Integrated: 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows In-Reply-To: References: Message-ID: <3u-095acL68lHZYaITZqgEqHiu9tTd4C9X1d079jawQ=.b35d72ee-9801-4d5f-a5c4-c3f583132247@github.com> On Thu, 12 May 2022 19:15:23 GMT, Brian Burkhalter wrote: > Cast the last parameter `dwNumberOfBytesToMap` of `MapViewOfFile()` to a `SIZE_T`, not a `DWORD`, to avoid truncation. This pull request has now been integrated. Changeset: e934a2c7 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/e934a2c752266847f4ea88c207a2fc2a8e743ff1 Stats: 80 lines in 2 files changed: 79 ins; 0 del; 1 mod 8286637: (fc) Memory mapped regions bigger than 2GB do not work correctly on Windows Reviewed-by: uschindler, mcimadamore, jvernee, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8686 From bpb at openjdk.java.net Wed May 18 15:09:06 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 18 May 2022 15:09:06 GMT Subject: RFR: 8286763: [REDO] (fc) Tune FileChannel.transferFrom() In-Reply-To: References: Message-ID: On Tue, 17 May 2022 15:43:07 GMT, Brian Burkhalter wrote: >>> Isn't it that returning `IOS_UNSUPPORTED` would disable it for everyone? I thought that `IOS_UNSUPPORTED_CASE` allows it to be tried again. Of course one could check for append or overlap in the Java layer instead. I actually had it that way initially for the overlap case but removed it. >> >> Oh I see, it's only IOS_UNSUPPORTED that disables it. With IOS_UNSUPPORTED_CASE then you may retry it again. > > Correct. It is IOS_UNSUPPORTED for example if the copy_file_range function pointer is NULL (not available via dlsym()). Then of course one can do nothing. I don?t think there is much else to do here unless we want to add append and range overlap checks for `transferFromDirectly()` in the Java layer. As empirically it appears that `copy_file_range()` sometimes succeeds in these cases, it seems better just to allow the system call to fail and fall back to the memory-mapped copy. Adding the checks in the Java layer might preclude some cases where the system call would actually succeed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8733 From wetmore at openjdk.java.net Wed May 18 15:15:56 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 18 May 2022 15:15:56 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. Looked at - java.base/.../sun/security - jdk.crypto.* - test/*/com/sun/crypto/provider - test/*/java/lang/SecurityManager - test/*/java/security - test/*/krb5 - test/*/jarsigner and those look fine. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8768 From bpb at openjdk.java.net Wed May 18 15:18:33 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 18 May 2022 15:18:33 GMT Subject: RFR: 8286735: (fc) FileChannel#map should document behavior when using custom file systems In-Reply-To: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com> References: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com> Message-ID: On Tue, 17 May 2022 01:12:55 GMT, Brian Burkhalter wrote: > Clarify when the `map()` methods of `java.nio.channels.FileChannel` throw an `UnsupportedOperationException`. Perhaps the submitter of this issue (@uschindler) could clarify the intent and modify or split this issue as needed? ------------- PR: https://git.openjdk.java.net/jdk/pull/8739 From alanb at openjdk.java.net Wed May 18 15:46:51 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 18 May 2022 15:46:51 GMT Subject: RFR: 8286763: [REDO] (fc) Tune FileChannel.transferFrom() In-Reply-To: References: Message-ID: <3XLYFuTAXH13hxqY9JsB0FmCCuEAj0cttVL4-rZ4ZmM=.5ac95e03-a237-41fe-af4e-5cde20c4197b@github.com> On Wed, 18 May 2022 15:05:04 GMT, Brian Burkhalter wrote: >> Correct. It is IOS_UNSUPPORTED for example if the copy_file_range function pointer is NULL (not available via dlsym()). Then of course one can do nothing. > > I don?t think there is much else to do here unless we want to add append and range overlap checks for `transferFromDirectly()` in the Java layer. As empirically it appears that `copy_file_range()` sometimes succeeds in these cases, it seems better just to allow the system call to fail and fall back to the memory-mapped copy. Adding the checks in the Java layer might preclude some cases where the system call would actually succeed. Okay, let's go with this. ------------- PR: https://git.openjdk.java.net/jdk/pull/8733 From alanb at openjdk.java.net Wed May 18 15:46:50 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 18 May 2022 15:46:50 GMT Subject: RFR: 8286763: [REDO] (fc) Tune FileChannel.transferFrom() In-Reply-To: References: Message-ID: On Mon, 16 May 2022 20:14:07 GMT, Brian Burkhalter wrote: > Re-do the fix for [JDK-8274113](https://bugs.openjdk.java.net/browse/JDK-8274113) which was reverted by [JDK-8286677.](https://bugs.openjdk.java.net/browse/JDK-8286677) Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8733 From bpb at openjdk.java.net Wed May 18 15:58:55 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 18 May 2022 15:58:55 GMT Subject: Integrated: 8286763: [REDO] (fc) Tune FileChannel.transferFrom() In-Reply-To: References: Message-ID: <8UaIkm9ffLkDwSLa3lkTz3g56MQFoZzQxE1wTBsxLno=.e094e3f6-482a-478e-94d2-a5ca937676c9@github.com> On Mon, 16 May 2022 20:14:07 GMT, Brian Burkhalter wrote: > Re-do the fix for [JDK-8274113](https://bugs.openjdk.java.net/browse/JDK-8274113) which was reverted by [JDK-8286677.](https://bugs.openjdk.java.net/browse/JDK-8286677) This pull request has now been integrated. Changeset: d8b0b32f Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/d8b0b32f9f4049aa678809aa068978e3a4e29457 Stats: 131 lines in 4 files changed: 117 ins; 0 del; 14 mod 8286763: [REDO] (fc) Tune FileChannel.transferFrom() Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8733 From naoto at openjdk.java.net Wed May 18 16:18:58 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 18 May 2022 16:18:58 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: <4eXpe5pmBsvw8u6fJlzd9BWsnY74LiyjTqQhQ88uxoc=.6182985a-f751-4d55-b9d0-bc605d7636da@github.com> On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. LGTM for i18n changes. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8768 From uschindler at openjdk.java.net Wed May 18 16:34:50 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Wed, 18 May 2022 16:34:50 GMT Subject: RFR: 8286735: (fc) FileChannel#map should document behavior when using custom file systems In-Reply-To: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com> References: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com> Message-ID: On Tue, 17 May 2022 01:12:55 GMT, Brian Burkhalter wrote: > Clarify when the `map()` methods of `java.nio.channels.FileChannel` throw an `UnsupportedOperationException`. Hi, sorry if this issue may have caused more friction than intended originally. Actually this is indeed two issues intermixed, that's my fault. The basic issue after merging Panama into main branch is the following and that was what I stumbled on from the beginning: Filesystems developed for JDK 8 to JDK 18 may return their own implementation of FileChannel. We do this in Lucene during our testing to catch bugs - thats all fine! We subclass FileChannel and implement the abstract methods, often just delegating (e.g. we emulate some windows behaviour in our testing on top of Linux - think of - just as example - differences regarding the issue that you cannot delete files while still open or similar). For that we just create a custom Filesystem that wraps all native FileChannel (and other APIs) to add some "bad behaviour" (like we all know form windows). Thats all fine and works great - util the new method added in JDK 19 (although it is `@Preview` feature - I know about that): If you create a wrapper filesystem and just wrap, the whole thing breaks with JDK 19. You won't of course not implement the new method added for Panama. When you the have code calling the new code to get a mmapped `MemorySegment` from a `FileChannel`, it thows `UnsupportedOperationException` (because the code was compiled for JDK 17 where the new method doid not exist). Of course that's expected with JDK 19, but it is not documented like that! That was the issue we have seen. Very simple. This was the reason why I opened the issue: In JDK 19, if you create your own FileSystem hat returns a FileChannel for a file and that FileChannel does not know that there's a new method in JDK 19. The Javadocs are just wrong in that case stating "If an unsupported map mode is specified." If you want to split the issue and just fix the issue for the new metod added in JDK 19: Let's just do it. The current Javadocs are wrong, because the default implementation also thorws UOE (because mmapping a file as MemorySegment) is not supported by a FileChannel by default (unless supported). Because I know that often custom Filesystems do not support mameory mapping I was suggesting to add that javadoc also to the legacy `MappedByteBuffer` code. If that's not wanted remove that. It was just a good meants suggestion to change the spec if you already do it for 19. That's all. Does this sound OK to you? ------------- PR: https://git.openjdk.java.net/jdk/pull/8739 From uschindler at openjdk.java.net Wed May 18 16:40:38 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Wed, 18 May 2022 16:40:38 GMT Subject: RFR: 8286735: (fc) FileChannel#map should document behavior when using custom file systems In-Reply-To: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com> References: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com> Message-ID: On Tue, 17 May 2022 01:12:55 GMT, Brian Burkhalter wrote: > Clarify when the `map()` methods of `java.nio.channels.FileChannel` throw an `UnsupportedOperationException`. src/java.base/share/classes/java/nio/channels/FileChannel.java line 962: > 960: * > 961: * @throws UnsupportedOperationException > 962: * If an unsupported map mode is specified, or if the implementation If you don't agree that the spec should be changed for the old API spec, let's remove that statement and only fix the new method's documentation. ------------- PR: https://git.openjdk.java.net/jdk/pull/8739 From iris at openjdk.java.net Wed May 18 16:59:50 2022 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 18 May 2022 16:59:50 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From aturbanov at openjdk.java.net Wed May 18 17:47:40 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 18 May 2022 17:47:40 GMT Subject: Integrated: 8286366: (cs) Charset.put can use putIfAbsent instead of containsKey+put In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 08:27:10 GMT, Andrey Turbanov wrote: > The method `Charset.put(Iterator i, Map m)` could be improved by usage of `Map.putIfAbsent` instead of pair `containsKey`+`put`. This method is called only with `TreeMap` as an argument and `TreeMap` has an effective implementation of `putIfAbsent` which avoid traversal Tree twice. > According to [JDK-8176894](https://bugs.openjdk.java.net/browse/JDK-8176894) usage of `TreeMap.putIfAbsent` could improve performance by 40%-100% compared with previous approach. This pull request has now been integrated. Changeset: 6b9c1521 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/6b9c15211efd0eb35e4ac8edf84c61bb8825a027 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8286366: (cs) Charset.put can use putIfAbsent instead of containsKey+put Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8480 From bpb at openjdk.java.net Wed May 18 20:56:38 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 18 May 2022 20:56:38 GMT Subject: RFR: 8286735: (fc) FileChannel#map should document behavior when using custom file systems In-Reply-To: References: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com> Message-ID: On Wed, 18 May 2022 16:37:18 GMT, Uwe Schindler wrote: > If you don't agree that the spec should be changed for the old API spec, let's remove that statement and only fix the new method's documentation. If we were to add the proposed `@implSpec`, then I don't think the `@throws UnsupportedOperationException` verbiage for `map(MapMode, long, long, MemorySession)` would need to be tweaked as the UOE is always thrown. If that would be acceptable, then perhaps the present issue could be revised and another separate issue created to address the optionality concerns that Alan raised, if that is something which it is desirable to investigate separately. ------------- PR: https://git.openjdk.java.net/jdk/pull/8739 From kevinw at openjdk.java.net Thu May 19 08:43:45 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 08:43:45 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. src/jdk.sctp/share/classes/com/sun/nio/sctp/ShutdownNotification.java line 28: > 26: > 27: /** > 28: * Notification emitted when a peers shutdowns the association. Maybe: "...when a peer shuts down an association." (could be "shuts down the association" if there is only ever one, but using "an" looks safe) ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From kevinw at openjdk.java.net Thu May 19 08:50:49 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 08:50:49 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348: > 346: > 347: /** > 348: * Returns the single non-abstract {@link Method} visible from I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many. ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From kevinw at openjdk.java.net Thu May 19 09:02:49 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 09:02:49 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. src/hotspot/share/opto/graphKit.cpp line 3626: > 3624: // The optional arguments are for specialized use by intrinsics: > 3625: // - If 'extra_slow_test' if not null is an extra condition for the slow-path. > 3626: // - If 'return_size_val', report the total object size to the caller. "reports the total" ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From kevinw at openjdk.java.net Thu May 19 09:09:50 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 09:09:50 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. src/hotspot/share/interpreter/bytecodeUtils.cpp line 186: > 184: static const int _max_cause_detail = 5; > 185: > 186: // Merges the stack the given bci with the given stack. If there "...the stack at the given bci..." ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From kevinw at openjdk.java.net Thu May 19 09:27:55 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 09:27:55 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: <02e6mwqZ3ihNyJb4lBK-5WeIGMfiLMj3I8LpJPv4i8o=.3c56077b-54f0-4c4e-b031-5a000b9ea887@github.com> On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. src/hotspot/share/cds/filemap.cpp line 1914: > 1912: > 1913: // the current value of the pointers to be patched must be within this > 1914: // range (i.e., must be between the requested base address, and the of the current archive). "the of the" ? Maybe "..and the address of the current archive", or maybe it was a typo for "and that of the current archive". ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From kevinw at openjdk.java.net Thu May 19 09:35:42 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 09:35:42 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com> On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 84: > 82: > 83: /** > 84: * Create a Zip file that will result in an Zip64 Extra (EXT) header "result in a Zip64..." test/jdk/sun/security/tools/jarsigner/OldSig.java line 32: > 30: /* > 31: * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily > 32: * formatted individual sections in addition the main attributes tested "in addition to the..." ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From kevinw at openjdk.java.net Thu May 19 09:41:57 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 09:41:57 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. OK. I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews. test/jdk/java/net/InterfaceAddress/Equals.java line 81: > 79: /** > 80: * Returns an InterfaceAddress instance with its fields set the values > 81: * specificed. probably a typo for "set to the values specified." ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.java.net/jdk/pull/8768 From mkartashev at openjdk.java.net Thu May 19 13:19:15 2022 From: mkartashev at openjdk.java.net (Maxim Kartashev) Date: Thu, 19 May 2022 13:19:15 GMT Subject: RFR: 8190546: File.toPath() reject directory names with trailing space Message-ID: [JDK-8190546](https://bugs.openjdk.java.net/browse/JDK-8190546) is currently closed as will-not-fix with a reference to Win32 documentation [1] that kind of discourages the use of space at the very end of a file name. That documentation says the following: > Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not Indeed, it's hard or even impossible to create such a file using the "normal" windows GUI, but you can use that GUI to _delete_ such a file. In Java, you can't do either. I'm proposing to lift this restriction primarily based on our user's requests and one or two use cases that seem legitimate. Working in a cygwin terminal, you can fairly easily create a file name ending with a space. And when you turn to your Java-based IDE to delete it, you get an error from the very basic level of NIO that you can't overrule, which seems to be quite unfortunate. Another source of files legitimately ending with a space would be any Unix filesystem accessed from a Windows Java application (be that a local `\\wsl$` or a NFS mounted from a remote machine). If you are interested in moving forward with the issue, please review the PR. Thank you! References [1] https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions ------------- Commit messages: - 8190546: File.toPath() reject directory names with trailing space Changes: https://git.openjdk.java.net/jdk/pull/8788/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8788&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8190546 Stats: 78 lines in 3 files changed: 65 ins; 10 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8788.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8788/head:pull/8788 PR: https://git.openjdk.java.net/jdk/pull/8788 From alanb at openjdk.java.net Thu May 19 13:31:45 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 19 May 2022 13:31:45 GMT Subject: RFR: 8190546: File.toPath() reject directory names with trailing space In-Reply-To: References: Message-ID: On Thu, 19 May 2022 13:11:11 GMT, Maxim Kartashev wrote: > [JDK-8190546](https://bugs.openjdk.java.net/browse/JDK-8190546) is currently closed as will-not-fix with a reference to Win32 documentation [1] that kind of discourages the use of space at the very end of a file name. That documentation says the following: > >> Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not > > > Indeed, it's hard or even impossible to create such a file using the "normal" windows GUI, but you can use that GUI to _delete_ such a file. In Java, you can't do either. > > I'm proposing to lift this restriction primarily based on our user's requests and one or two use cases that seem legitimate. > > Working in a cygwin terminal, you can fairly easily create a file name ending with a space. And when you turn to your Java-based IDE to delete it, you get an error from the very basic level of NIO that you can't overrule, which seems to be quite unfortunate. Another source of files legitimately ending with a space would be any Unix filesystem accessed from a Windows Java application (be that a local `\\wsl$` or a NFS mounted from a remote machine). > > If you are interested in moving forward with the issue, please review the PR. Thank you! > > References > [1] https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions The rejecting of file paths with tailing paths is intentional and important for security reasons. ------------- Changes requested by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8788 From uschindler at openjdk.java.net Thu May 19 14:06:49 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Thu, 19 May 2022 14:06:49 GMT Subject: RFR: 8286735: (fc) FileChannel#map should document behavior when using custom file systems In-Reply-To: References: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com> Message-ID: On Wed, 18 May 2022 20:53:26 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/nio/channels/FileChannel.java line 962: >> >>> 960: * >>> 961: * @throws UnsupportedOperationException >>> 962: * If an unsupported map mode is specified, or if the implementation >> >> If you don't agree that the spec should be changed for the old API spec, let's remove that statement and only fix the new method's documentation. > >> If you don't agree that the spec should be changed for the old API spec, let's remove that statement and only fix the new method's documentation. > > If we were to add the proposed `@implSpec`, then I don't think the `@throws UnsupportedOperationException` verbiage for `map(MapMode, long, long, MemorySession)` would need to be tweaked as the UOE is always thrown. If that would be acceptable, then perhaps the present issue could be revised and another separate issue created to address the optionality concerns that Alan raised, if that is something which it is desirable to investigate separately. I havo no strong preference where the information about this implemnation detail is written down. I agree to change the original issue and add a new one about optionality. ------------- PR: https://git.openjdk.java.net/jdk/pull/8739 From mkartashev at openjdk.java.net Thu May 19 14:31:47 2022 From: mkartashev at openjdk.java.net (Maxim Kartashev) Date: Thu, 19 May 2022 14:31:47 GMT Subject: RFR: 8190546: File.toPath() reject directory names with trailing space In-Reply-To: References: Message-ID: On Thu, 19 May 2022 13:28:50 GMT, Alan Bateman wrote: > The rejecting of file paths with tailing paths is intentional and important for security reasons. OK, but can you be more specific, please? Or some security bugs are involved, which you are not at liberty to discuss? ------------- PR: https://git.openjdk.java.net/jdk/pull/8788 From xuelei at openjdk.java.net Thu May 19 14:58:48 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 19 May 2022 14:58:48 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. The security/crypto parts look good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8768 From xuelei at openjdk.java.net Thu May 19 14:58:49 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 19 May 2022 14:58:49 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com> References: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com> Message-ID: On Thu, 19 May 2022 09:31:07 GMT, Kevin Walls wrote: >> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? >> >> Also, I fixed a couple of spelling mistakes. > > test/jdk/sun/security/tools/jarsigner/OldSig.java line 32: > >> 30: /* >> 31: * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily >> 32: * formatted individual sections in addition the main attributes tested > > "in addition to the..." +1. ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From aivanov at openjdk.java.net Thu May 19 18:54:04 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 19 May 2022 18:54:04 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base [v2] In-Reply-To: References: Message-ID: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision: - ...set to the values... - ...will result in a Zip64 Extra (EXT) header - ...in addition to the main attributes... - ...and the address of the current archive - Merges the stack at the given bci... - Returns a single ... - ...when a peer shuts down an association. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8768/files - new: https://git.openjdk.java.net/jdk/pull/8768/files/c7e73658..0669cdc1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=00-01 Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768 PR: https://git.openjdk.java.net/jdk/pull/8768 From aivanov at openjdk.java.net Thu May 19 18:59:57 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 19 May 2022 18:59:57 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base [v2] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 08:47:47 GMT, Kevin Walls wrote: >> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision: >> >> - ...set to the values... >> - ...will result in a Zip64 Extra (EXT) header >> - ...in addition to the main attributes... >> - ...and the address of the current archive >> - Merges the stack at the given bci... >> - Returns a single ... >> - ...when a peer shuts down an association. > > src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348: > >> 346: >> 347: /** >> 348: * Returns the single non-abstract {@link Method} visible from > > I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many. I've accepted it, yet I'm still unsure whether ?a? or ?the?? ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From aivanov at openjdk.java.net Thu May 19 19:06:56 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 19 May 2022 19:06:56 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base [v2] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 09:38:40 GMT, Kevin Walls wrote: >> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision: >> >> - ...set to the values... >> - ...will result in a Zip64 Extra (EXT) header >> - ...in addition to the main attributes... >> - ...and the address of the current archive >> - Merges the stack at the given bci... >> - Returns a single ... >> - ...when a peer shuts down an association. > > OK. I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews. Thank you @kevinjwalls for your suggestions. I've incorporated them. ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From mcimadamore at openjdk.java.net Mon May 23 08:47:57 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 23 May 2022 08:47:57 GMT Subject: Integrated: 8286715: Generalize MemorySegment::ofBuffer In-Reply-To: References: Message-ID: On Fri, 13 May 2022 12:33:10 GMT, Maurizio Cimadamore wrote: > This patch makes MemorySegment::ofBuffer more general, by allowing clients to pass *any* `Buffer` instance, not just `ByteBuffer`. > This allows us to match expressiveness of JNI API, where JNI clients can obtain the address of any direct buffer instance, using the `GetDirectBufferAddress` function. > > We thought about also providing a more general way to view a segment as a buffer (e.g. asIntBuffer) but doing that doesn't seem worth it: direct buffers can only created form `ByteBuffer`. > So, to create a direct `IntBuffer`, clients have to first create a direct `ByteBuffer` then to view that buffer as an `IntBuffer`. > > In other words, `IntBuffer` and friends are not first-class citizens in the `Buffer` API. As such it would not be possible to map many memory segments into an `IntBuffer`; in fact, the only segment we could safely map into an `IntBuffer` would be an _heap_ segment backed by an `int[]`. As such it doesn't seem worth adding a lot of API surface (in terms of additional overloads) for such a corner case. This pull request has now been integrated. Changeset: 89a1d055 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/89a1d055d93ad57bcec7c1accb3f53b4c30f594d Stats: 95 lines in 8 files changed: 55 ins; 1 del; 39 mod 8286715: Generalize MemorySegment::ofBuffer Reviewed-by: jvernee ------------- PR: https://git.openjdk.java.net/jdk/pull/8701 From mcimadamore at openjdk.java.net Mon May 23 10:18:23 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 23 May 2022 10:18:23 GMT Subject: RFR: 8287154: java/nio/channels/FileChannel/LargeMapTest.java does not compile Message-ID: The patch pushed as part of https://git.openjdk.java.net/jdk/pull/8701 conflicts with a test added as part of PR https://github.com/openjdk/jdk/pull/8686. That is, the test introduced in the latter patch depends on `MemorySegment.ofByteBuffer` which has been renamed to `ofBuffer` as part of the former patch. ------------- Commit messages: - Fix FileChannelTest to use new `MemorySegment::ofBuffer` API Changes: https://git.openjdk.java.net/jdk/pull/8839/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8839&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287154 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8839.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8839/head:pull/8839 PR: https://git.openjdk.java.net/jdk/pull/8839 From alanb at openjdk.java.net Mon May 23 10:18:24 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 23 May 2022 10:18:24 GMT Subject: RFR: 8287154: java/nio/channels/FileChannel/LargeMapTest.java does not compile In-Reply-To: References: Message-ID: On Mon, 23 May 2022 10:10:15 GMT, Maurizio Cimadamore wrote: > The patch pushed as part of https://git.openjdk.java.net/jdk/pull/8701 conflicts with a test added as part of PR https://github.com/openjdk/jdk/pull/8686. > > That is, the test introduced in the latter patch depends on `MemorySegment.ofByteBuffer` which has been renamed to `ofBuffer` as part of the former patch. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8839 From jvernee at openjdk.java.net Mon May 23 10:18:24 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 May 2022 10:18:24 GMT Subject: RFR: 8287154: java/nio/channels/FileChannel/LargeMapTest.java does not compile In-Reply-To: References: Message-ID: On Mon, 23 May 2022 10:10:15 GMT, Maurizio Cimadamore wrote: > The patch pushed as part of https://git.openjdk.java.net/jdk/pull/8701 conflicts with a test added as part of PR https://github.com/openjdk/jdk/pull/8686. > > That is, the test introduced in the latter patch depends on `MemorySegment.ofByteBuffer` which has been renamed to `ofBuffer` as part of the former patch. Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8839 From mcimadamore at openjdk.java.net Mon May 23 10:22:55 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 23 May 2022 10:22:55 GMT Subject: Integrated: 8287154: java/nio/channels/FileChannel/LargeMapTest.java does not compile In-Reply-To: References: Message-ID: On Mon, 23 May 2022 10:10:15 GMT, Maurizio Cimadamore wrote: > The patch pushed as part of https://git.openjdk.java.net/jdk/pull/8701 conflicts with a test added as part of PR https://github.com/openjdk/jdk/pull/8686. > > That is, the test introduced in the latter patch depends on `MemorySegment.ofByteBuffer` which has been renamed to `ofBuffer` as part of the former patch. This pull request has now been integrated. Changeset: 81f128b9 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/81f128b9031e2c04859d323378b64e3f2625bf20 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8287154: java/nio/channels/FileChannel/LargeMapTest.java does not compile Reviewed-by: alanb, jvernee ------------- PR: https://git.openjdk.java.net/jdk/pull/8839 From lancea at openjdk.java.net Mon May 23 19:54:58 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 23 May 2022 19:54:58 GMT Subject: RFR: 8287162: (zipfs) Performance regression related to support for POSIX file permissions Message-ID: Hi all, This PR addresses the performance issue that is described in JDK-8287162. With this fix, the ZipFileSystem methods: initOwner, initGroup, and initPermissions will not be invoked unless enablePosixFileAttributes=true. Mach5 tiers1-3 are currently running and have not encountered any issues. ------------- Commit messages: - Only invoke initOwner, initGroup, and initPermissions when supportsPosix is true Changes: https://git.openjdk.java.net/jdk/pull/8854/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8854&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287162 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8854.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8854/head:pull/8854 PR: https://git.openjdk.java.net/jdk/pull/8854 From aivanov at openjdk.java.net Mon May 23 20:06:57 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 23 May 2022 20:06:57 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base [v3] In-Reply-To: References: Message-ID: <3E93xe0v68L9AHsT3c5D58_5OdaSDEGtdg5ih7TTkfk=.45bed80f-be56-49e8-9dfb-a7fa70b9ea23@github.com> > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Update copyright to 2022 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8768/files - new: https://git.openjdk.java.net/jdk/pull/8768/files/0669cdc1..fa2caaec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01-02 Stats: 102 lines in 102 files changed: 0 ins; 0 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/8768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768 PR: https://git.openjdk.java.net/jdk/pull/8768 From jpai at openjdk.java.net Tue May 24 01:33:02 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 24 May 2022 01:33:02 GMT Subject: RFR: 8287162: (zipfs) Performance regression related to support for POSIX file permissions In-Reply-To: References: Message-ID: On Mon, 23 May 2022 19:47:33 GMT, Lance Andersen wrote: > Hi all, > > This PR addresses the performance issue that is described in JDK-8287162. > > With this fix, the ZipFileSystem methods: initOwner, initGroup, and initPermissions will not be invoked unless enablePosixFileAttributes=true. > > Mach5 tiers1-3 are currently running and have not encountered any issues. Marked as reviewed by jpai (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8854 From alanb at openjdk.java.net Tue May 24 05:19:42 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 24 May 2022 05:19:42 GMT Subject: RFR: 8287162: (zipfs) Performance regression related to support for POSIX file permissions In-Reply-To: References: Message-ID: On Mon, 23 May 2022 19:47:33 GMT, Lance Andersen wrote: > Hi all, > > This PR addresses the performance issue that is described in JDK-8287162. > > With this fix, the ZipFileSystem methods: initOwner, initGroup, and initPermissions will not be invoked unless enablePosixFileAttributes=true. > > Mach5 tiers1-3 are currently running and have not encountered any issues. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8854 From clanger at openjdk.java.net Tue May 24 06:57:39 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 24 May 2022 06:57:39 GMT Subject: RFR: 8287162: (zipfs) Performance regression related to support for POSIX file permissions In-Reply-To: References: Message-ID: On Mon, 23 May 2022 19:47:33 GMT, Lance Andersen wrote: > Hi all, > > This PR addresses the performance issue that is described in JDK-8287162. > > With this fix, the ZipFileSystem methods: initOwner, initGroup, and initPermissions will not be invoked unless enablePosixFileAttributes=true. > > Mach5 tiers1-3 are currently running and have not encountered any issues. Marked as reviewed by clanger (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8854 From mcimadamore at openjdk.java.net Tue May 24 09:36:31 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 24 May 2022 09:36:31 GMT Subject: RFR: 8287206: Use WrongThreadException for confinement errors Message-ID: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors. ------------- Commit messages: - Merge branch 'master' into wrong_thread_ex - Initial push Changes: https://git.openjdk.java.net/jdk/pull/8865/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8865&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287206 Stats: 254 lines in 12 files changed: 150 ins; 1 del; 103 mod Patch: https://git.openjdk.java.net/jdk/pull/8865.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8865/head:pull/8865 PR: https://git.openjdk.java.net/jdk/pull/8865 From mcimadamore at openjdk.java.net Tue May 24 09:36:31 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 24 May 2022 09:36:31 GMT Subject: RFR: 8287206: Use WrongThreadException for confinement errors In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> Message-ID: On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore wrote: > This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors. javadoc: http://cr.openjdk.java.net/~mcimadamore/8287206/v1/javadoc/java.base/module-summary.html specdiff: http://cr.openjdk.java.net/~mcimadamore/8287206/v1/specdiff_out/overview-summary.html ------------- PR: https://git.openjdk.java.net/jdk/pull/8865 From alanb at openjdk.java.net Tue May 24 09:38:42 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 24 May 2022 09:38:42 GMT Subject: RFR: 8287206: Use WrongThreadException for confinement errors In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> Message-ID: On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore wrote: > This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8865 From aivanov at openjdk.java.net Tue May 24 11:28:50 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 24 May 2022 11:28:50 GMT Subject: Integrated: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. This pull request has now been integrated. Changeset: e0d361ce Author: Alexey Ivanov URL: https://git.openjdk.java.net/jdk/commit/e0d361cea91d3dd1450aece73f660b4abb7ce5fa Stats: 303 lines in 162 files changed: 0 ins; 11 del; 292 mod 8284191: Replace usages of 'a the' in hotspot and java.base Reviewed-by: lancea, wetmore, naoto, iris, kevinw, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From lancea at openjdk.java.net Tue May 24 15:59:55 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 24 May 2022 15:59:55 GMT Subject: Integrated: 8287162: (zipfs) Performance regression related to support for POSIX file permissions In-Reply-To: References: Message-ID: On Mon, 23 May 2022 19:47:33 GMT, Lance Andersen wrote: > Hi all, > > This PR addresses the performance issue that is described in JDK-8287162. > > With this fix, the ZipFileSystem methods: initOwner, initGroup, and initPermissions will not be invoked unless enablePosixFileAttributes=true. > > Mach5 tiers1-3 are currently running and have not encountered any issues. This pull request has now been integrated. Changeset: a10c5597 Author: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/a10c5597d93c4402bafdbb570437aac052b10027 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8287162: (zipfs) Performance regression related to support for POSIX file permissions Reviewed-by: jpai, alanb, clanger ------------- PR: https://git.openjdk.java.net/jdk/pull/8854 From darcy at openjdk.java.net Tue May 24 16:06:06 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 24 May 2022 16:06:06 GMT Subject: RFR: 8287206: Use WrongThreadException for confinement errors In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> Message-ID: On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore wrote: > This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8865 From mchung at openjdk.java.net Tue May 24 19:01:57 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 24 May 2022 19:01:57 GMT Subject: RFR: 8287206: Use WrongThreadException for confinement errors In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> Message-ID: On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore wrote: > This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8865 From bpb at openjdk.java.net Tue May 24 21:36:38 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 24 May 2022 21:36:38 GMT Subject: RFR: 8287263: java/nio/channels/FileChannel/LargeMapTest.java times out on Windows Message-ID: Double the timeout to avoid spurious failures. ------------- Commit messages: - 8287263: java/nio/channels/FileChannel/LargeMapTest.java times out on Windows Changes: https://git.openjdk.java.net/jdk/pull/8875/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8875&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287263 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8875/head:pull/8875 PR: https://git.openjdk.java.net/jdk/pull/8875 From bpb at openjdk.java.net Tue May 24 22:04:48 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 24 May 2022 22:04:48 GMT Subject: RFR: 8287263: java/nio/channels/FileChannel/LargeMapTest.java times out on Windows [v2] In-Reply-To: References: Message-ID: > Double the timeout to avoid spurious failures. Brian Burkhalter 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: 8287263: java/nio/channels/FileChannel/LargeMapTest.java times out on Windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8875/files - new: https://git.openjdk.java.net/jdk/pull/8875/files/f59f4c91..330d5583 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8875&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8875&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8875/head:pull/8875 PR: https://git.openjdk.java.net/jdk/pull/8875 From lancea at openjdk.java.net Tue May 24 23:06:57 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 24 May 2022 23:06:57 GMT Subject: RFR: 8287263: java/nio/channels/FileChannel/LargeMapTest.java times out on Windows [v2] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 22:04:48 GMT, Brian Burkhalter wrote: >> Double the timeout to avoid spurious failures. > > Brian Burkhalter 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: > > 8287263: java/nio/channels/FileChannel/LargeMapTest.java times out on Windows Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8875 From bpb at openjdk.java.net Wed May 25 02:14:47 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 25 May 2022 02:14:47 GMT Subject: Integrated: 8287263: java/nio/channels/FileChannel/LargeMapTest.java times out on Windows In-Reply-To: References: Message-ID: <-Ij-iqMWi2mx4RnO-iFQKaV2_eMpE3QMDQh9MpGFGCs=.53e944e2-e87f-4246-a64c-97588ec89c09@github.com> On Tue, 24 May 2022 21:29:51 GMT, Brian Burkhalter wrote: > Double the timeout to avoid spurious failures. This pull request has now been integrated. Changeset: 742644e2 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/742644e291039e4f2f30cf80718669c06da5809c Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod 8287263: java/nio/channels/FileChannel/LargeMapTest.java times out on Windows Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/8875 From mcimadamore at openjdk.java.net Wed May 25 09:55:03 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 25 May 2022 09:55:03 GMT Subject: Integrated: 8287206: Use WrongThreadException for confinement errors In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> Message-ID: On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore wrote: > This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors. This pull request has now been integrated. Changeset: e1f140d2 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/e1f140d270cc666d26b888a0a25ca7b02e1239af Stats: 254 lines in 12 files changed: 150 ins; 1 del; 103 mod 8287206: Use WrongThreadException for confinement errors Reviewed-by: alanb, darcy, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/8865 From uschindler at openjdk.java.net Wed May 25 10:09:01 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Wed, 25 May 2022 10:09:01 GMT Subject: RFR: 8287206: Use WrongThreadException for confinement errors In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> Message-ID: On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore wrote: > This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors. I have seen this PR now: Would it be also a good idea to replace the `IllegalStateException` for already closed `MemorySession` by some special exception? In Lucene we catch `IllegalStateException` in our IO layer and check if message contains "closed", example: - https://github.com/apache/lucene/blob/d182134bf88a44bf76ebd1c1d40b225ecdca1f4b/lucene/core/src/java/org/apache/lucene/store/MemorySegmentIndexInput.java#L137 (catch) - https://github.com/apache/lucene/blob/d182134bf88a44bf76ebd1c1d40b225ecdca1f4b/lucene/core/src/java/org/apache/lucene/store/MemorySegmentIndexInput.java#L93-L103 (that's the hack) The check using `ex.getMessage().contains("closed")` feels bad, especially if it may be translated to a locale. ------------- PR: https://git.openjdk.java.net/jdk/pull/8865 From uschindler at openjdk.java.net Wed May 25 10:11:24 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Wed, 25 May 2022 10:11:24 GMT Subject: RFR: 8287206: Use WrongThreadException for confinement errors In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> Message-ID: On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore wrote: > This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors. Thinking more about it: `IllegalStateException` is fine for a closed `MemorySession`. If used by wrong thread the exception was indeed confusing. Now that the abiguity is gone, I can change our (Lucene) code and just transform every ISE to an already closed in our code. I just wanted to bring up that issue here. PR is here: https://github.com/apache/lucene/pull/912 ------------- PR: https://git.openjdk.java.net/jdk/pull/8865 From mcimadamore at openjdk.java.net Wed May 25 10:18:55 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 25 May 2022 10:18:55 GMT Subject: RFR: 8287206: Use WrongThreadException for confinement errors In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> Message-ID: <3fiLF2goGBXqo6BqFntFkt-Nbtdq7cLpaMsjEftJ95I=.6e708ab4-9524-455b-9585-84e43ccbcf09@github.com> On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore wrote: > This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors. > Thinking more about it: `IllegalStateException` is fine for a closed `MemorySession`. If used by wrong thread the exception was indeed confusing. Now that the abiguity is gone, I can change our (Lucene) code and just transform every ISE to an already closed in our code. I just wanted to bring up that issue here. > > PR is here: [apache/lucene#912](https://github.com/apache/lucene/pull/912) I've been thinking something similar. I'd suggest to keep the API as is, and maybe revise it at a later point if lack of a specific exception for the "already closed" case proves to be too cumbersome to workaround. ------------- PR: https://git.openjdk.java.net/jdk/pull/8865 From mcimadamore at openjdk.java.net Wed May 25 10:22:49 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 25 May 2022 10:22:49 GMT Subject: RFR: 8287206: Use WrongThreadException for confinement errors In-Reply-To: <3fiLF2goGBXqo6BqFntFkt-Nbtdq7cLpaMsjEftJ95I=.6e708ab4-9524-455b-9585-84e43ccbcf09@github.com> References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> <3fiLF2goGBXqo6BqFntFkt-Nbtdq7cLpaMsjEftJ95I=.6e708ab4-9524-455b-9585-84e43ccbcf09@github.com> Message-ID: On Wed, 25 May 2022 10:16:54 GMT, Maurizio Cimadamore wrote: > > Thinking more about it: `IllegalStateException` is fine for a closed `MemorySession`. If used by wrong thread the exception was indeed confusing. Now that the abiguity is gone, I can change our (Lucene) code and just transform every ISE to an already closed in our code. I just wanted to bring up that issue here. > > PR is here: [apache/lucene#912](https://github.com/apache/lucene/pull/912) > > I've been thinking something similar. I'd suggest to keep the API as is, and maybe revise it at a later point if lack of a specific exception for the "already closed" case proves to be too cumbersome to workaround. Basically, with this patch you only get ISE if you are accessing _in a moment in time_ when you are not supposed to. Similarly, when calling `close`, you get ISE if you are closing a segment that is in a bad state (e.g. already closed, or temporarily locked by some native call). This feels consistent. The confinement exception was the confounding factor, I think, and a lot of checks against the exception message came from there. ------------- PR: https://git.openjdk.java.net/jdk/pull/8865 From uschindler at openjdk.java.net Wed May 25 17:51:14 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Wed, 25 May 2022 17:51:14 GMT Subject: RFR: 8287206: Use WrongThreadException for confinement errors In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com> Message-ID: On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore wrote: > This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors. I changed the PR on our side, `IllegalStateException` is fine, if you catch it as close as possible to the code calling varhandles and so on (which is the case for Lucene). Thanks for this PR, makes life much easier! ------------- PR: https://git.openjdk.java.net/jdk/pull/8865 From bpb at openjdk.java.net Wed May 25 18:07:23 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 25 May 2022 18:07:23 GMT Subject: RFR: 8286709: (fc) FileChannel/FileChannelImpl cleanup Message-ID: Clean up some verbiage and code, mostly spaces and line breaks. ------------- Commit messages: - 8286709: (fc) FileChannel/FileChannelImpl cleanup Changes: https://git.openjdk.java.net/jdk/pull/8889/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8889&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286709 Stats: 65 lines in 2 files changed: 12 ins; 8 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/8889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8889/head:pull/8889 PR: https://git.openjdk.java.net/jdk/pull/8889 From bpb at openjdk.java.net Wed May 25 23:16:21 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 25 May 2022 23:16:21 GMT Subject: RFR: 8287003: InputStreamReader::read() can return zero despite writing a char in the buffer Message-ID: If only a leftover `char` remains in the stream, do not add `-1` to the return value in `lockedRead()`. ------------- Commit messages: - 8287003: InputStreamReader::read() can return zero despite writing a char in the buffer Changes: https://git.openjdk.java.net/jdk/pull/8895/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8895&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287003 Stats: 33 lines in 2 files changed: 24 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8895.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8895/head:pull/8895 PR: https://git.openjdk.java.net/jdk/pull/8895 From alanb at openjdk.java.net Thu May 26 06:45:28 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 26 May 2022 06:45:28 GMT Subject: RFR: 8286709: (fc) FileChannel/FileChannelImpl cleanup In-Reply-To: References: Message-ID: On Wed, 25 May 2022 18:01:00 GMT, Brian Burkhalter wrote: > Clean up some verbiage and code, mostly spaces and line breaks. src/java.base/share/classes/java/nio/channels/FileChannel.java line 1054: > 1052: public MemorySegment map(MapMode mode, long offset, long size, > 1053: MemorySession session) > 1054: throws IOException { Thanks for fixing up the formatting issues. For this one then you could put MemorySession parameter on the previous line if you want. Also have "throws IOException {" indent by 4 looks a bit odd here. It can be indented by 8 or put the "{" on the next line like the other methods in this area. ------------- PR: https://git.openjdk.java.net/jdk/pull/8889 From bpb at openjdk.java.net Thu May 26 16:00:23 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 26 May 2022 16:00:23 GMT Subject: RFR: 8286709: (fc) FileChannel/FileChannelImpl cleanup [v2] In-Reply-To: References: Message-ID: > Clean up some verbiage and code, mostly spaces and line breaks. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8286709: Clean up the cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8889/files - new: https://git.openjdk.java.net/jdk/pull/8889/files/cfff8883..ab19acc6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8889&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8889&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8889/head:pull/8889 PR: https://git.openjdk.java.net/jdk/pull/8889 From bpb at openjdk.java.net Thu May 26 16:00:23 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 26 May 2022 16:00:23 GMT Subject: RFR: 8286709: (fc) FileChannel/FileChannelImpl cleanup [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 06:42:27 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8286709: Clean up the cleanup > > src/java.base/share/classes/java/nio/channels/FileChannel.java line 1054: > >> 1052: public MemorySegment map(MapMode mode, long offset, long size, >> 1053: MemorySession session) >> 1054: throws IOException { > > Thanks for fixing up the formatting issues. For this one then you could put MemorySession parameter on the previous line if you want. Also have "throws IOException {" indent by 4 looks a bit odd here. It can be indented by 8 or put the "{" on the next line like the other methods in this area. Fixed by ab19acc6174636475ab15ef7ff403782f5493926. ------------- PR: https://git.openjdk.java.net/jdk/pull/8889 From alanb at openjdk.java.net Thu May 26 16:09:44 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 26 May 2022 16:09:44 GMT Subject: RFR: 8286709: (fc) FileChannel/FileChannelImpl cleanup [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 16:00:23 GMT, Brian Burkhalter wrote: >> Clean up some verbiage and code, mostly spaces and line breaks. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8286709: Clean up the cleanup Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8889 From bpb at openjdk.java.net Thu May 26 18:04:40 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 26 May 2022 18:04:40 GMT Subject: Integrated: 8286709: (fc) FileChannel/FileChannelImpl cleanup In-Reply-To: References: Message-ID: On Wed, 25 May 2022 18:01:00 GMT, Brian Burkhalter wrote: > Clean up some verbiage and code, mostly spaces and line breaks. This pull request has now been integrated. Changeset: 7cb368b3 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/7cb368b34df97614f0d208b8b0b93aa714a49282 Stats: 65 lines in 2 files changed: 12 ins; 8 del; 45 mod 8286709: (fc) FileChannel/FileChannelImpl cleanup Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8889 From duke at openjdk.java.net Thu May 26 20:06:17 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 26 May 2022 20:06:17 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v6] In-Reply-To: References: Message-ID: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - 8282662: Revert wrong copyright year change - 8282662: Revert ProxyGenerator - 8282662: Revert ProxyGenerator - 8282662: Revert dubious changes in MethodType - 8282662: Revert dubious changes - 8282662: Use List/Set.of() factory methods to save memory ------------- Changes: https://git.openjdk.java.net/jdk/pull/7729/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=05 Stats: 12 lines in 4 files changed: 1 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729 From bpb at openjdk.java.net Thu May 26 23:11:12 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 26 May 2022 23:11:12 GMT Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux Message-ID: Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`). ------------- Commit messages: - 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux Changes: https://git.openjdk.java.net/jdk/pull/8909/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8909&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287237 Stats: 51 lines in 2 files changed: 37 ins; 2 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/8909.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8909/head:pull/8909 PR: https://git.openjdk.java.net/jdk/pull/8909 From jpai at openjdk.java.net Fri May 27 12:17:16 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 27 May 2022 12:17:16 GMT Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux In-Reply-To: References: Message-ID: On Thu, 26 May 2022 23:03:05 GMT, Brian Burkhalter wrote: > Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`). src/java.base/share/classes/sun/net/www/MimeTable.java line 164: > 162: public MimeEntry findByFileName(String fname) { > 163: // attempt to find the entry with the fragment component removed > 164: MimeEntry entry = findByFileName(fname, true); I think we might need a check here first to see if the `fname` contains `#` and if it does, only then call the `findByFileName` with `true`. Without that check, with the change in this PR, it's now possible that the `findByFileName` will get called twice (once with `true` and once with `false`) for the case where the filename doesn't have a `#` and whose extension isn't in the MimeTable. src/java.base/share/classes/sun/net/www/MimeTable.java line 183: > 181: * @return the MIME entry associated with the file name > 182: */ > 183: public MimeEntry findByFileName(String fname, boolean removeFragment) { Hello Brian, Perhaps this new method can be made `private` (and maybe even `static`)? ------------- PR: https://git.openjdk.java.net/jdk/pull/8909 From jpai at openjdk.java.net Fri May 27 12:23:46 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 27 May 2022 12:23:46 GMT Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux In-Reply-To: References: Message-ID: On Thu, 26 May 2022 23:03:05 GMT, Brian Burkhalter wrote: > Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`). src/java.base/share/classes/sun/net/www/MimeTable.java line 196: > 194: > 195: String ext = ""; > 196: if (i != -1 && fname.charAt(i) == '.') Nit - the existing method currently uses a `{` even for single line conditionals. Should we do the same for the new `if` blocks introduced in this PR and enclose them within `{` `}`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8909 From jpai at openjdk.java.net Fri May 27 12:27:45 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 27 May 2022 12:27:45 GMT Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux In-Reply-To: References: Message-ID: <9XbooopnuEtUralKt5CI16Sx_UBWvtlWZQzQqO65oCk=.0599bc3c-81d8-405a-bdef-ea794f2885a1@github.com> On Thu, 26 May 2022 23:03:05 GMT, Brian Burkhalter wrote: > Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`). test/jdk/java/nio/file/Files/probeContentType/Basic.java line 197: > 195: String contentType = Files.probeContentType(pathWithFragement); > 196: if (contentType == null || !contentType.equals("image/png")) { > 197: System.out.printf("For %s expected \"png\" but got %s%n", Should this instead use `System.err`, since the rest of the test uses that for printing these failures when incrementing the failure count. ------------- PR: https://git.openjdk.java.net/jdk/pull/8909 From jpai at openjdk.java.net Fri May 27 13:06:40 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 27 May 2022 13:06:40 GMT Subject: RFR: 8287003: InputStreamReader::read() can return zero despite writing a char in the buffer In-Reply-To: References: Message-ID: On Wed, 25 May 2022 23:08:38 GMT, Brian Burkhalter wrote: > If only a leftover `char` remains in the stream, do not add `-1` to the return value in `lockedRead()`. Looks fine to me. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8895 From rriggs at openjdk.java.net Fri May 27 13:31:38 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 27 May 2022 13:31:38 GMT Subject: RFR: 8287003: InputStreamReader::read() can return zero despite writing a char in the buffer In-Reply-To: References: Message-ID: On Wed, 25 May 2022 23:08:38 GMT, Brian Burkhalter wrote: > If only a leftover `char` remains in the stream, do not add `-1` to the return value in `lockedRead()`. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8895 From bpb at openjdk.java.net Fri May 27 15:26:43 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 27 May 2022 15:26:43 GMT Subject: Integrated: 8287003: InputStreamReader::read() can return zero despite writing a char in the buffer In-Reply-To: References: Message-ID: On Wed, 25 May 2022 23:08:38 GMT, Brian Burkhalter wrote: > If only a leftover `char` remains in the stream, do not add `-1` to the return value in `lockedRead()`. This pull request has now been integrated. Changeset: 6520843f Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/6520843f86f638fe4d1e5b3358fab5799daca654 Stats: 33 lines in 2 files changed: 24 ins; 1 del; 8 mod 8287003: InputStreamReader::read() can return zero despite writing a char in the buffer Reviewed-by: jpai, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/8895 From bpb at openjdk.java.net Fri May 27 19:09:05 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 27 May 2022 19:09:05 GMT Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux [v2] In-Reply-To: References: Message-ID: > Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`). Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8287237: Refactor and clean up ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8909/files - new: https://git.openjdk.java.net/jdk/pull/8909/files/64801e1b..eab33e80 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8909&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8909&range=00-01 Stats: 53 lines in 2 files changed: 19 ins; 12 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/8909.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8909/head:pull/8909 PR: https://git.openjdk.java.net/jdk/pull/8909 From bpb at openjdk.java.net Fri May 27 19:09:08 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 27 May 2022 19:09:08 GMT Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux [v2] In-Reply-To: References: Message-ID: <3s_0L36MSYzmK3T4utQztJkaHWDN6jZ_-fpXjLPlDAk=.aaf1e716-9d06-4155-8e22-2761bc5bb579@github.com> On Fri, 27 May 2022 12:15:07 GMT, Jaikiran Pai wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8287237: Refactor and clean up > > src/java.base/share/classes/sun/net/www/MimeTable.java line 164: > >> 162: public MimeEntry findByFileName(String fname) { >> 163: // attempt to find the entry with the fragment component removed >> 164: MimeEntry entry = findByFileName(fname, true); > > I think we might need a check here first to see if the `fname` contains `#` and if it does, only then call the `findByFileName` with `true`. Without that check, with the change in this PR, it's now possible that the `findByFileName` will get called twice (once with `true` and once with `false`) for the case where the filename doesn't have a `#` and whose extension isn't in the MimeTable. Methods refactored in eab33e8000ea730c57c918dbf291af23bacbd059. > src/java.base/share/classes/sun/net/www/MimeTable.java line 183: > >> 181: * @return the MIME entry associated with the file name >> 182: */ >> 183: public MimeEntry findByFileName(String fname, boolean removeFragment) { > > Hello Brian, > > Perhaps this new method can be made `private` (and maybe even `static`)? Private yes, static no. Refactored in eab33e8000ea730c57c918dbf291af23bacbd059. > test/jdk/java/nio/file/Files/probeContentType/Basic.java line 197: > >> 195: String contentType = Files.probeContentType(pathWithFragement); >> 196: if (contentType == null || !contentType.equals("image/png")) { >> 197: System.out.printf("For %s expected \"png\" but got %s%n", > > Should this instead use `System.err`, since the rest of the test uses that for printing these failures when incrementing the failure count. Yes, it should have used `System.err`; fixed in eab33e8000ea730c57c918dbf291af23bacbd059. ------------- PR: https://git.openjdk.java.net/jdk/pull/8909 From jpai at openjdk.java.net Sat May 28 14:42:29 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 28 May 2022 14:42:29 GMT Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux [v2] In-Reply-To: References: Message-ID: On Fri, 27 May 2022 19:09:05 GMT, Brian Burkhalter wrote: >> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`). > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8287237: Refactor and clean up src/java.base/share/classes/sun/net/www/MimeTable.java line 188: > 186: int hashIndex = fname.lastIndexOf(HASH_MARK); > 187: if (hashIndex > 0) { > 188: String ext = getFileExtension(fname.substring(0, hashIndex - 1)); Hello Brian, I think there's a bug here. Not introduced by this PR but even in the current master. I think that `fname.substring(0, hashIndex -1)` call should actually be `fname.substring(0, hashIndex)`. For example, in its current form, if `fname` is `a.png#foo` then `fname.substring(...)` here will return `a.pn` instead of `a.png`. It looks like we don't have a test for that case. ------------- PR: https://git.openjdk.java.net/jdk/pull/8909 From shade at openjdk.java.net Mon May 30 14:40:15 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 30 May 2022 14:40:15 GMT Subject: RFR: 8287526: java/nio/channels/FileChannel/LargeMapTest.java fails on 32-bit systems Message-ID: $ CONF=linux-x86-server-fastdebug make images run-test TEST=java/nio/channels/FileChannel/LargeMapTest.java STDOUT: 32 i386 19-internal STDERR: java.io.IOException: Map failed at java.base/sun.nio.ch.FileChannelImpl.mapInternal(FileChannelImpl.java:1322) at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1221) at LargeMapTest.main(LargeMapTest.java:66) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:1585) Caused by: java.lang.OutOfMemoryError: Map failed at java.base/sun.nio.ch.FileChannelImpl.map0(Native Method) at java.base/sun.nio.ch.FileChannelImpl.mapInternal(FileChannelImpl.java:1319) ... 6 more I think we cannot assume we would be able to map >4G on 32-bit system. Currently obscured by [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137), would manifest again after [JDK-8287520](https://bugs.openjdk.java.net/browse/JDK-8287520). Additional testing: - [x] Linux x86_64 fastdebug, still passes - [x] Linux x86_32 fastdebug, still skipped, even after taking off the problem list ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/8948/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8948&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287526 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8948.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8948/head:pull/8948 PR: https://git.openjdk.java.net/jdk/pull/8948 From alanb at openjdk.java.net Mon May 30 14:43:35 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 30 May 2022 14:43:35 GMT Subject: RFR: 8287526: java/nio/channels/FileChannel/LargeMapTest.java fails on 32-bit systems In-Reply-To: References: Message-ID: On Mon, 30 May 2022 14:30:44 GMT, Aleksey Shipilev wrote: > $ CONF=linux-x86-server-fastdebug make images run-test TEST=java/nio/channels/FileChannel/LargeMapTest.java > > STDOUT: > 32 > i386 > 19-internal > STDERR: > java.io.IOException: Map failed > at java.base/sun.nio.ch.FileChannelImpl.mapInternal(FileChannelImpl.java:1322) > at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1221) > at LargeMapTest.main(LargeMapTest.java:66) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:1585) > Caused by: java.lang.OutOfMemoryError: Map failed > at java.base/sun.nio.ch.FileChannelImpl.map0(Native Method) > at java.base/sun.nio.ch.FileChannelImpl.mapInternal(FileChannelImpl.java:1319) > ... 6 more > > > I think we cannot assume we would be able to map >4G on 32-bit system. > > Currently obscured by [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137), would manifest again after [JDK-8287520](https://bugs.openjdk.java.net/browse/JDK-8287520). > > Additional testing: > - [x] Linux x86_64 fastdebug, still passes > - [x] Linux x86_32 fastdebug, still skipped, even after taking off the problem list Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8948 From stuefe at openjdk.java.net Mon May 30 15:05:45 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 30 May 2022 15:05:45 GMT Subject: RFR: 8287526: java/nio/channels/FileChannel/LargeMapTest.java fails on 32-bit systems In-Reply-To: References: Message-ID: On Mon, 30 May 2022 14:30:44 GMT, Aleksey Shipilev wrote: > $ CONF=linux-x86-server-fastdebug make images run-test TEST=java/nio/channels/FileChannel/LargeMapTest.java > > STDOUT: > 32 > i386 > 19-internal > STDERR: > java.io.IOException: Map failed > at java.base/sun.nio.ch.FileChannelImpl.mapInternal(FileChannelImpl.java:1322) > at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1221) > at LargeMapTest.main(LargeMapTest.java:66) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:1585) > Caused by: java.lang.OutOfMemoryError: Map failed > at java.base/sun.nio.ch.FileChannelImpl.map0(Native Method) > at java.base/sun.nio.ch.FileChannelImpl.mapInternal(FileChannelImpl.java:1319) > ... 6 more > > > I think we cannot assume we would be able to map >4G on 32-bit system. > > Currently obscured by [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137), would manifest again after [JDK-8287520](https://bugs.openjdk.java.net/browse/JDK-8287520). > > Additional testing: > - [x] Linux x86_64 fastdebug, still passes > - [x] Linux x86_32 fastdebug, still skipped, even after taking off the problem list +1 ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8948 From duke at openjdk.java.net Tue May 31 07:40:56 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 31 May 2022 07:40:56 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v7] In-Reply-To: References: Message-ID: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - 8282662: Revert wrong copyright year change - 8282662: Revert ProxyGenerator - 8282662: Revert ProxyGenerator - 8282662: Revert dubious changes in MethodType - 8282662: Revert dubious changes - 8282662: Use List/Set.of() factory methods to save memory ------------- Changes: https://git.openjdk.java.net/jdk/pull/7729/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=06 Stats: 12 lines in 4 files changed: 1 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729 From redestad at openjdk.java.net Tue May 31 09:40:27 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 31 May 2022 09:40:27 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v7] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 07:40:56 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - 8282662: Revert wrong copyright year change > - 8282662: Revert ProxyGenerator > - 8282662: Revert ProxyGenerator > - 8282662: Revert dubious changes in MethodType > - 8282662: Revert dubious changes > - 8282662: Use List/Set.of() factory methods to save memory Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From rriggs at openjdk.java.net Tue May 31 13:13:47 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 31 May 2022 13:13:47 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v7] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 07:40:56 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? 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: > > - 8282662: Revert wrong copyright year change > - 8282662: Revert ProxyGenerator > - 8282662: Revert ProxyGenerator > - 8282662: Revert dubious changes in MethodType > - 8282662: Revert dubious changes > - 8282662: Use List/Set.of() factory methods to save memory Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From shade at openjdk.java.net Tue May 31 13:52:32 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 31 May 2022 13:52:32 GMT Subject: RFR: 8287526: java/nio/channels/FileChannel/LargeMapTest.java fails on 32-bit systems In-Reply-To: References: Message-ID: On Mon, 30 May 2022 14:30:44 GMT, Aleksey Shipilev wrote: > $ CONF=linux-x86-server-fastdebug make images run-test TEST=java/nio/channels/FileChannel/LargeMapTest.java > > STDOUT: > 32 > i386 > 19-internal > STDERR: > java.io.IOException: Map failed > at java.base/sun.nio.ch.FileChannelImpl.mapInternal(FileChannelImpl.java:1322) > at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1221) > at LargeMapTest.main(LargeMapTest.java:66) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:1585) > Caused by: java.lang.OutOfMemoryError: Map failed > at java.base/sun.nio.ch.FileChannelImpl.map0(Native Method) > at java.base/sun.nio.ch.FileChannelImpl.mapInternal(FileChannelImpl.java:1319) > ... 6 more > > > I think we cannot assume we would be able to map >4G on 32-bit system. > > Currently obscured by [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137), would manifest again after [JDK-8287520](https://bugs.openjdk.java.net/browse/JDK-8287520). > > Additional testing: > - [x] Linux x86_64 fastdebug, still passes > - [x] Linux x86_32 fastdebug, still skipped, even after taking off the problem list Thanks for reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/8948 From shade at openjdk.java.net Tue May 31 13:52:33 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 31 May 2022 13:52:33 GMT Subject: Integrated: 8287526: java/nio/channels/FileChannel/LargeMapTest.java fails on 32-bit systems In-Reply-To: References: Message-ID: On Mon, 30 May 2022 14:30:44 GMT, Aleksey Shipilev wrote: > $ CONF=linux-x86-server-fastdebug make images run-test TEST=java/nio/channels/FileChannel/LargeMapTest.java > > STDOUT: > 32 > i386 > 19-internal > STDERR: > java.io.IOException: Map failed > at java.base/sun.nio.ch.FileChannelImpl.mapInternal(FileChannelImpl.java:1322) > at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1221) > at LargeMapTest.main(LargeMapTest.java:66) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:1585) > Caused by: java.lang.OutOfMemoryError: Map failed > at java.base/sun.nio.ch.FileChannelImpl.map0(Native Method) > at java.base/sun.nio.ch.FileChannelImpl.mapInternal(FileChannelImpl.java:1319) > ... 6 more > > > I think we cannot assume we would be able to map >4G on 32-bit system. > > Currently obscured by [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137), would manifest again after [JDK-8287520](https://bugs.openjdk.java.net/browse/JDK-8287520). > > Additional testing: > - [x] Linux x86_64 fastdebug, still passes > - [x] Linux x86_32 fastdebug, still skipped, even after taking off the problem list This pull request has now been integrated. Changeset: 1b44f6c4 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/1b44f6c483cfb2c8c2f304281654b56fda967719 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8287526: java/nio/channels/FileChannel/LargeMapTest.java fails on 32-bit systems Reviewed-by: alanb, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8948 From Alan.Bateman at oracle.com Tue May 31 15:00:21 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 31 May 2022 16:00:21 +0100 Subject: CancelledKeyException during channel registration In-Reply-To: <1fd841e5-54ab-366e-5d60-d373ee825c1b@amazon.co.uk> References: <1fd841e5-54ab-366e-5d60-d373ee825c1b@amazon.co.uk> Message-ID: Moving to the nio-dev list. Registration is not an atomic operation. The channel is registered (this creates the selection key) and then the key's interest set is changed. If I read your test case correctly, it is cancelling the key before the key's interest set is changed and this leads to the CancelledKeyException. Yes, I agree this may be surprising. Can you submit a bug for this? -Alan On 31/05/2022 11:38, Gillespie, Oli wrote: > Hi, > > I noticed this surprising (to me) behaviour, and wonder whether it's > expected or could be considered a bug. I'm not an expert in this area > so apologies if this is trivial. > > When registering a SocketChannel with a Selector for the first time, > it's possible to get a CancelledKeyException even though this is the > first register call. > > Exception in thread "main" java.nio.channels.CancelledKeyException > ??? at > java.base/sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:75) > ??? at > java.base/sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:104) > ??? at java.base/sun.nio.ch.SelectorImpl.register(SelectorImpl.java:222) > ??? at > java.base/java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:236) > ??? at > java.base/java.nio.channels.SelectableChannel.register(SelectableChannel.java:260) > ??? at KeyCancelled.main(KeyCancelled.java:20) > > The javadoc states: > > @throws? CancelledKeyException > ??? If this channel is currently registered with the given selector > ????? but the corresponding key has already been cancelled > > However in this case the channel is _not_ registered, as shown by > SocketChannel.isRegistered() returning false. > > This following sequence triggers this issue: > > 1. Thread 1 starts SelectableChannel.register > 2. A new SelectionKey becomes visible via Selector.keys() > 3. Thread 2 iterates Selector.keys() and calls SelectorKey.cancel() > 4. Thread 1 (still in the register() invocation) finds that the key is > cancelled and throws CancelledKeyException > > Below is a small reproducer which usually exhibits this issue: > > import java.nio.channels.SelectionKey; > import java.nio.channels.Selector; > import java.nio.channels.SocketChannel; > > public class KeyCancelled { > ??? public static void main(String[] args) throws Exception { > ??????? Selector s = Selector.open(); > > ??????? new Thread(() -> { > ??????????? for (int i = 0; i < 100_000; i++) { > ??????????????? s.keys().forEach(SelectionKey::cancel); > ??????????? } > ??????? }).start(); > > ??????? for (int i = 0; i < 10_000; i++) { > ??????????? SocketChannel c = s.provider().openSocketChannel(); > ??????????? c.configureBlocking(false); > ??????????? // Sometimes this throws CancelledKeyException, because > the key is cancelled by > ??????????? // the other thread part-way through the register call. > ??????????? c.register(s, SelectionKey.OP_READ); > ??????????? // c.isRegistered() is false here after the exceptional case > ??????? } > ??? } > } > > So, is this expected, a bug, or a gap in documentation? > > Many thanks, > > Oli > > > > Amazon Development Centre (London) Ltd. Registered in England and > Wales with registration number 04543232 with its registered office at > 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom. > > From bpb at openjdk.java.net Tue May 31 16:45:32 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 31 May 2022 16:45:32 GMT Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux [v2] In-Reply-To: References: Message-ID: On Sat, 28 May 2022 14:39:16 GMT, Jaikiran Pai wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8287237: Refactor and clean up > > src/java.base/share/classes/sun/net/www/MimeTable.java line 188: > >> 186: int hashIndex = fname.lastIndexOf(HASH_MARK); >> 187: if (hashIndex > 0) { >> 188: String ext = getFileExtension(fname.substring(0, hashIndex - 1)); > > Hello Brian, I think there's a bug here. Not introduced by this PR but even in the current master. I think that `fname.substring(0, hashIndex -1)` call should actually be `fname.substring(0, hashIndex)`. For example, in its current form, if `fname` is `a.png#foo` then `fname.substring(...)` here will return `a.pn` instead of `a.png`. It looks like we don't have a test for that case. I agree. I saw that myself. As nothing seems broken I did not want to touch it but I will investigate. > src/java.base/share/classes/sun/net/www/MimeTable.java line 196: > >> 194: >> 195: String ext = ""; >> 196: if (i != -1 && fname.charAt(i) == '.') > > Nit - the existing method currently uses a `{` even for single line conditionals. Should we do the same for the new `if` blocks introduced in this PR and enclose them within `{` `}`? Fixed in eab33e8000ea730c57c918dbf291af23bacbd059. ------------- PR: https://git.openjdk.java.net/jdk/pull/8909 From bpb at openjdk.java.net Tue May 31 18:13:35 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 31 May 2022 18:13:35 GMT Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux [v3] In-Reply-To: References: Message-ID: > Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`). Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8287237: Correct off-by-one endIndex passed to String.substring() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8909/files - new: https://git.openjdk.java.net/jdk/pull/8909/files/eab33e80..7c877f9e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8909&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8909&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8909.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8909/head:pull/8909 PR: https://git.openjdk.java.net/jdk/pull/8909 From bpb at openjdk.java.net Tue May 31 18:13:36 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 31 May 2022 18:13:36 GMT Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux [v2] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 16:41:57 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/sun/net/www/MimeTable.java line 188: >> >>> 186: int hashIndex = fname.lastIndexOf(HASH_MARK); >>> 187: if (hashIndex > 0) { >>> 188: String ext = getFileExtension(fname.substring(0, hashIndex - 1)); >> >> Hello Brian, I think there's a bug here. Not introduced by this PR but even in the current master. I think that `fname.substring(0, hashIndex -1)` call should actually be `fname.substring(0, hashIndex)`. For example, in its current form, if `fname` is `a.png#foo` then `fname.substring(...)` here will return `a.pn` instead of `a.png`. It looks like we don't have a test for that case. > > I agree. I saw that myself. As nothing seems broken I did not want to touch it but I will investigate. This was probably never caught because all our Linux machines seem to have `/etc/mime.types`. Fixed by 7c877f9ee2a0788849bac4d64a4ab4c89cbc9e0c. ------------- PR: https://git.openjdk.java.net/jdk/pull/8909 From bpb at openjdk.java.net Tue May 31 18:29:30 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 31 May 2022 18:29:30 GMT Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux [v4] In-Reply-To: References: Message-ID: > Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`). Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8287237: Simplify code a bit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8909/files - new: https://git.openjdk.java.net/jdk/pull/8909/files/7c877f9e..b9eb7bbb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8909&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8909&range=02-03 Stats: 12 lines in 1 file changed: 0 ins; 4 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8909.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8909/head:pull/8909 PR: https://git.openjdk.java.net/jdk/pull/8909 From duke at openjdk.java.net Tue May 31 19:30:07 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 31 May 2022 19:30:07 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v8] In-Reply-To: References: Message-ID: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - 8282662: Revert wrong copyright year change - 8282662: Revert ProxyGenerator - 8282662: Revert ProxyGenerator - 8282662: Revert dubious changes in MethodType - 8282662: Revert dubious changes - 8282662: Use List/Set.of() factory methods to save memory ------------- Changes: https://git.openjdk.java.net/jdk/pull/7729/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=07 Stats: 13 lines in 5 files changed: 1 ins; 2 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729 From rriggs at openjdk.java.net Tue May 31 19:31:42 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 31 May 2022 19:31:42 GMT Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux [v4] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 18:29:30 GMT, Brian Burkhalter wrote: >> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`). > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8287237: Simplify code a bit LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8909 From rriggs at openjdk.java.net Tue May 31 19:36:44 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 31 May 2022 19:36:44 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v8] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 19:30:07 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - 8282662: Revert wrong copyright year change > - 8282662: Revert ProxyGenerator > - 8282662: Revert ProxyGenerator > - 8282662: Revert dubious changes in MethodType > - 8282662: Revert dubious changes > - 8282662: Use List/Set.of() factory methods to save memory Why the force push? They are discouraged, making it harder to review. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From duke at openjdk.java.net Tue May 31 21:01:59 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 31 May 2022 21:01:59 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v8] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 19:33:15 GMT, Roger Riggs wrote: >> ?????? ??????? 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: >> >> - 8282662: Revert wrong copyright year change >> - 8282662: Revert ProxyGenerator >> - 8282662: Revert ProxyGenerator >> - 8282662: Revert dubious changes in MethodType >> - 8282662: Revert dubious changes >> - 8282662: Use List/Set.of() factory methods to save memory > > Why the force push? They are discouraged, making it harder to review. @RogerRiggs I've rebased my changes onto master to incorporate the latest changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From rriggs at openjdk.java.net Tue May 31 21:07:50 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 31 May 2022 21:07:50 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v8] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 19:30:07 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - 8282662: Revert wrong copyright year change > - 8282662: Revert ProxyGenerator > - 8282662: Revert ProxyGenerator > - 8282662: Revert dubious changes in MethodType > - 8282662: Revert dubious changes > - 8282662: Use List/Set.of() factory methods to save memory Merging is preferable, it doesn't disturb the history. Usually an explicit merge is not necessary; Skara will indicate when an automatic merge is needed due to conflicts. If you want to run your own tests then use a merge, not rebase. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From aturbanov at openjdk.java.net Tue May 31 21:08:22 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Tue, 31 May 2022 21:08:22 GMT Subject: RFR: 8287602: (fs) Avoid redundant HashMap.containsKey call in MimeTypesFileTypeDetector.putIfAbsent Message-ID: Only non-null values are put into `Map mimeTypeMap`. It means, we can replace `containsKey`+`put` calls with single `putIfAbsent` call. It makes code a bit cleaner and faster. https://github.com/openjdk/jdk/blob/3d2d039538b906cedd9188ed94b7ba55c275ff7f/src/java.base/unix/classes/sun/nio/fs/MimeTypesFileTypeDetector.java#L189-L196 ------------- Commit messages: - [PATCH] Avoid redundant HashMap.containsKey call in MimeTypesFileTypeDetector.putIfAbsent - [PATCH] Avoid redundant HashMap.containsKey call in MimeTypesFileTypeDetector.putIfAbsent Changes: https://git.openjdk.java.net/jdk/pull/8941/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8941&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287602 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8941.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8941/head:pull/8941 PR: https://git.openjdk.java.net/jdk/pull/8941 From alanb at openjdk.java.net Tue May 31 21:08:24 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 31 May 2022 21:08:24 GMT Subject: RFR: 8287602: (fs) Avoid redundant HashMap.containsKey call in MimeTypesFileTypeDetector.putIfAbsent In-Reply-To: References: Message-ID: On Sun, 29 May 2022 20:41:04 GMT, Andrey Turbanov wrote: > Only non-null values are put into `Map mimeTypeMap`. It means, we can replace `containsKey`+`put` calls with single `putIfAbsent` call. It makes code a bit cleaner and faster. > > https://github.com/openjdk/jdk/blob/3d2d039538b906cedd9188ed94b7ba55c275ff7f/src/java.base/unix/classes/sun/nio/fs/MimeTypesFileTypeDetector.java#L189-L196 src/java.base/unix/classes/sun/nio/fs/MimeTypesFileTypeDetector.java line 191: > 189: private void putIfAbsent(String key, String value) { > 190: if (key != null && !key.isEmpty() && > 191: value != null && !value.isEmpty()) The change looks okay. While you there then it would be okay to combine these two lines into one to avoid the unusual formatting. ------------- PR: https://git.openjdk.java.net/jdk/pull/8941 From aturbanov at openjdk.java.net Tue May 31 21:08:25 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Tue, 31 May 2022 21:08:25 GMT Subject: RFR: 8287602: (fs) Avoid redundant HashMap.containsKey call in MimeTypesFileTypeDetector.putIfAbsent In-Reply-To: References: Message-ID: <0oVgDubRizBKQWMw_agQDsfm4BdVDTb-IXkrO4i710A=.ccf95732-455b-4958-bf37-56e6b010f0a7@github.com> On Tue, 31 May 2022 13:14:42 GMT, Alan Bateman wrote: >> Only non-null values are put into `Map mimeTypeMap`. It means, we can replace `containsKey`+`put` calls with single `putIfAbsent` call. It makes code a bit cleaner and faster. >> >> https://github.com/openjdk/jdk/blob/3d2d039538b906cedd9188ed94b7ba55c275ff7f/src/java.base/unix/classes/sun/nio/fs/MimeTypesFileTypeDetector.java#L189-L196 > > src/java.base/unix/classes/sun/nio/fs/MimeTypesFileTypeDetector.java line 191: > >> 189: private void putIfAbsent(String key, String value) { >> 190: if (key != null && !key.isEmpty() && >> 191: value != null && !value.isEmpty()) > > The change looks okay. While you there then it would be okay to combine these two lines into one to avoid the unusual formatting. Done. Also I did remove redundant null checks. Method `putIfAbsent` is called in 2 places and in both places, parameters are guaranteed to be non-null. ------------- PR: https://git.openjdk.java.net/jdk/pull/8941 From bpb at openjdk.java.net Tue May 31 22:04:32 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 31 May 2022 22:04:32 GMT Subject: RFR: 8287602: (fs) Avoid redundant HashMap.containsKey call in MimeTypesFileTypeDetector.putIfAbsent In-Reply-To: References: Message-ID: On Sun, 29 May 2022 20:41:04 GMT, Andrey Turbanov wrote: > Only non-null values are put into `Map mimeTypeMap`. It means, we can replace `containsKey`+`put` calls with single `putIfAbsent` call. It makes code a bit cleaner and faster. > > https://github.com/openjdk/jdk/blob/3d2d039538b906cedd9188ed94b7ba55c275ff7f/src/java.base/unix/classes/sun/nio/fs/MimeTypesFileTypeDetector.java#L189-L196 Looks right. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8941