From stuefe at openjdk.java.net Sun Aug 1 04:04:42 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 1 Aug 2021 04:04:42 GMT Subject: RFR: JDK-8256844: Make NMT late-initializable In-Reply-To: References: Message-ID: <76rgHvkDeWusTPBrU5QdYwCO2mXQB7fWdfSbhXJNzPo=.3af5326a-4300-4bf1-ae24-465575bf56d3@github.com> On Thu, 29 Jul 2021 06:33:38 GMT, David Holmes wrote: >> Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing, cleans them up and makes them sideeffect-free. >> >> --------- >> >> NMT continues to be an extremely useful tool for SAP to tackle memory problems in the JVM. >> >> However, NMT is of limited use due to the following restrictions: >> >> - NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible. >> - Worse, if that custom launcher links the libjvm *statically* there is just no way to activate NMT at all. This is the reason NMT cannot be used in the `gtestlauncher`. >> - Related to that is that we cannot pass NMT options via `JAVA_TOOL_OPTIONS` and `-XX:Flags=`. >> - The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff. >> >> The reason for all this is that NMT initialization happens very early, on the first call to `os::malloc()`. And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments. >> >> The current solution is to pass NMT arguments via a specially prepared environment variable: `NMT_LEVEL_=`. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher. >> >> All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. `java` itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand. >> >> And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., `JAVA_TOOL_OPTIONS`. >> >> ------ >> >> This patch fixes these shortcomings by making NMT late-initializable: it can now be initialized after normal VM argument parsing, like all other parts of the VM. This greatly simplifies NMT initialization and makes it work automagically for every third party launcher, as well as within our gtests. >> >> The glaring problem with late-initializing NMT is the NMT malloc headers. If we rule out just always having them (unacceptable in terms of memory overhead), there is no safe way to determine, in os::free(), if an allocation came from before or after NMT initialization ran, and therefore what to do with its malloc headers. For a more extensive explanation, please see the comment block `nmtPreInit.hpp` and the discussion with @kimbarrett and @zhengyu123 in the JBS comment section. >> >> The heart of this patch is a new way to track early, pre-NMT-init allocations. These are tracked via a lookup table. This was a suggestion by Kim and it worked out well. >> >> Changes in detail: >> >> - pre-NMT-init handling: >> - the new files `nmtPreInit.hpp/cpp` take case of NMT pre-init handling. They contain a small global lookup table managing C-heap blocks allocated in the pre-NMT-init phase. >> - `os::malloc()/os::realloc()/os::free()` defer to this code before doing anything else. >> - Please see the extensive comment block at the start of `nmtPreinit.hpp` explaining the details. >> >> - Changes to NMT: >> - Before, NMT initialization was spread over two phases, `initialize()` and `late_initialize()`. Those were merged into one and simplified - there is only one initialization now which happens after argument parsing. >> - Minor changes were needed for the `NMT_TrackingLevel` enum - to simplify code, I changed NMT_unknown to be numerically 0. A new comment block in `nmtCommon.hpp` now clearly specifies what's what, including allowed level state transitions. >> - New utility functions to translate tracking level from/to strings added to `NMTUtil` >> - NMT has never been able to handle virtual memory allocations before initialization, which is fine since os::reserve_memory() is not called before VM parses arguments. We now assert that. >> - All code outside the VM handling NMT initialization (eg. libjli) has been removed, as has the code testing it. >> >> - Gtests: >> - Some existing gtests had to be modified: before, they all changed global state (turning NMT on/off) before testing. This is not allowed anymore, to keep NMT simple. Also, this pattern disturbed other tests. >> - The new way to test is to passively check whether NMT has been switched on or off, and do tests accordingly: if on, full tests, if off, test just what makes sense in off-state. That does not disturb neighboring tests, gives us actually better coverage all around. >> - It is now possible to start the gtestlauncher with NMT on! Which additionally gives us good coverage. >> - To actually do gtests with NMT - since it's disabled by default - we now run NMT-enabled gtests as part of the hotspot jtreg NMT wrapper. This pattern we have done for a number of other facitilites, see all the tests in test/hotspot/jtreg/gtest.. . It works very well. >> - Finally, a new gtest has been written to test the NMT preinit lookup map in isolation, placed in `gtest/nmt/test_nmtpreinitmap.cpp`. >> >> - jtreg: >> - A new test has been added, `runtime/NMT/NMTInitializationTest.java`, testing NMT initialization in the face of many many VM arguments. >> >> ------------- >> >> Tests: >> - ran manually all new tests on 64-bit and 32-bit Linux >> - GHAs >> - The patch has been active in SAPs test systems for a while now. > > src/java.base/share/native/libjli/java.c line 807: > >> 805: */ >> 806: static void >> 807: SetJvmEnvironment(int argc, char **argv) { > > This doesn't seem to do anything any more. Thanks for this hint. This brought me to JDK-8186483, which can probably get rolled back now entirely. ------------- PR: https://git.openjdk.java.net/jdk/pull/4874 From github.com+1701815+mkarg at openjdk.java.net Sun Aug 1 07:51:37 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sun, 1 Aug 2021 07:51:37 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v11] In-Reply-To: References: Message-ID: > 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 one additional commit since the last revision: [Draft] Using blocking lock to prevent concurrently switching into non-blocking mode ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4263/files - new: https://git.openjdk.java.net/jdk/pull/4263/files/8e2889fd..f4485d5b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=09-10 Stats: 16 lines in 1 file changed: 8 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4263.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4263/head:pull/4263 PR: https://git.openjdk.java.net/jdk/pull/4263 From github.com+1701815+mkarg at openjdk.java.net Sun Aug 1 07:51:37 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sun, 1 Aug 2021 07:51:37 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v6] In-Reply-To: References: <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com> Message-ID: On Sat, 31 Jul 2021 21:20:28 GMT, Markus KARG wrote: > I suspect the eventually patch will need have to make use of the blockingLock to prevent the underlying channels from being changed to non-blocking during the transfer. The blocking lock now is used since https://github.com/openjdk/jdk/pull/4263/commits/f4485d5b6a3b5c471feff5642dfef0fc747d3fac to prevent this. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From github.com+1701815+mkarg at openjdk.java.net Sun Aug 1 08:02:48 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sun, 1 Aug 2021 08:02:48 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v6] In-Reply-To: References: <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com> Message-ID: On Sun, 1 Aug 2021 07:46:36 GMT, Markus KARG wrote: >>> I need to look at it closely but I suspect this introduces a potential overflow. Also if output stream is backed by a SocketChannel configured non-blocking then FC::transferTo may return 0 so I assume there is a potential infinite loop there too. I suspect the eventually patch will need have to make use of the blockingLock to prevent the underlying channels from being changed to non-blocking during the transfer. >> >> I need to confess that my NIO knowledge is not deep enough to follow you closely, so I trust on your advice how to go on from here. > >> I suspect the eventually patch will need have to make use of the blockingLock to prevent the underlying channels from being changed to non-blocking during the transfer. > > The blocking lock now is used since https://github.com/openjdk/jdk/pull/4263/commits/f4485d5b6a3b5c471feff5642dfef0fc747d3fac to prevent this. > Also can you can check that IllegalBlockingModeException is thrown for the case ch is a SelectableChannel configured non-blocking and the destination is a FileChannel? Do we really only have to check this in the particular case of `FileChannel` destinations? And don't we have to assert blocking mode for *destination* channels, too (just like `ChannelOutputStream::writeFully` does)? As this results in an 2:2 matrix of possibilities (src is selectable nor not, dst is selectable or not) it might be easier to do *only the blocking checks* in `transferTo` but let it call something like `transferFromSelectableToNonSelectable` in turn *or* to wrap *each* implementation of `transferTo` in a wrapper like `executeInBlockingMode((src, dst) -> transferTo(src, dst))`...? ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From stuefe at openjdk.java.net Sun Aug 1 08:17:08 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 1 Aug 2021 08:17:08 GMT Subject: RFR: JDK-8256844: Make NMT late-initializable [v2] In-Reply-To: References: Message-ID: > Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing, cleans them up and makes them sideeffect-free. > > --------- > > NMT continues to be an extremely useful tool for SAP to tackle memory problems in the JVM. > > However, NMT is of limited use due to the following restrictions: > > - NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible. > - Worse, if that custom launcher links the libjvm *statically* there is just no way to activate NMT at all. This is the reason NMT cannot be used in the `gtestlauncher`. > - Related to that is that we cannot pass NMT options via `JAVA_TOOL_OPTIONS` and `-XX:Flags=`. > - The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff. > > The reason for all this is that NMT initialization happens very early, on the first call to `os::malloc()`. And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments. > > The current solution is to pass NMT arguments via a specially prepared environment variable: `NMT_LEVEL_=`. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher. > > All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. `java` itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand. > > And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., `JAVA_TOOL_OPTIONS`. > > ------ > > This patch fixes these shortcomings by making NMT late-initializable: it can now be initialized after normal VM argument parsing, like all other parts of the VM. This greatly simplifies NMT initialization and makes it work automagically for every third party launcher, as well as within our gtests. > > The glaring problem with late-initializing NMT is the NMT malloc headers. If we rule out just always having them (unacceptable in terms of memory overhead), there is no safe way to determine, in os::free(), if an allocation came from before or after NMT initialization ran, and therefore what to do with its malloc headers. For a more extensive explanation, please see the comment block `nmtPreInit.hpp` and the discussion with @kimbarrett and @zhengyu123 in the JBS comment section. > > The heart of this patch is a new way to track early, pre-NMT-init allocations. These are tracked via a lookup table. This was a suggestion by Kim and it worked out well. > > Changes in detail: > > - pre-NMT-init handling: > - the new files `nmtPreInit.hpp/cpp` take case of NMT pre-init handling. They contain a small global lookup table managing C-heap blocks allocated in the pre-NMT-init phase. > - `os::malloc()/os::realloc()/os::free()` defer to this code before doing anything else. > - Please see the extensive comment block at the start of `nmtPreinit.hpp` explaining the details. > > - Changes to NMT: > - Before, NMT initialization was spread over two phases, `initialize()` and `late_initialize()`. Those were merged into one and simplified - there is only one initialization now which happens after argument parsing. > - Minor changes were needed for the `NMT_TrackingLevel` enum - to simplify code, I changed NMT_unknown to be numerically 0. A new comment block in `nmtCommon.hpp` now clearly specifies what's what, including allowed level state transitions. > - New utility functions to translate tracking level from/to strings added to `NMTUtil` > - NMT has never been able to handle virtual memory allocations before initialization, which is fine since os::reserve_memory() is not called before VM parses arguments. We now assert that. > - All code outside the VM handling NMT initialization (eg. libjli) has been removed, as has the code testing it. > > - Gtests: > - Some existing gtests had to be modified: before, they all changed global state (turning NMT on/off) before testing. This is not allowed anymore, to keep NMT simple. Also, this pattern disturbed other tests. > - The new way to test is to passively check whether NMT has been switched on or off, and do tests accordingly: if on, full tests, if off, test just what makes sense in off-state. That does not disturb neighboring tests, gives us actually better coverage all around. > - It is now possible to start the gtestlauncher with NMT on! Which additionally gives us good coverage. > - To actually do gtests with NMT - since it's disabled by default - we now run NMT-enabled gtests as part of the hotspot jtreg NMT wrapper. This pattern we have done for a number of other facitilites, see all the tests in test/hotspot/jtreg/gtest.. . It works very well. > - Finally, a new gtest has been written to test the NMT preinit lookup map in isolation, placed in `gtest/nmt/test_nmtpreinitmap.cpp`. > > - jtreg: > - A new test has been added, `runtime/NMT/NMTInitializationTest.java`, testing NMT initialization in the face of many many VM arguments. > > ------------- > > Tests: > - ran manually all new tests on 64-bit and 32-bit Linux > - GHAs > - The patch has been active in SAPs test systems for a while now. Thomas Stuefe has updated the pull request incrementally with six additional commits since the last revision: - feedback zhengyu - feeback Coleen/Kim (constness fix) - Feedback David - Add test to test for non-java launcher support of NMT - move all test code to gtest - actually free blocks freed in pre-init phase ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4874/files - new: https://git.openjdk.java.net/jdk/pull/4874/files/42f2ca22..ae56cb4d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4874&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4874&range=00-01 Stats: 358 lines in 11 files changed: 221 ins; 98 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/4874.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4874/head:pull/4874 PR: https://git.openjdk.java.net/jdk/pull/4874 From stuefe at openjdk.java.net Sun Aug 1 08:17:11 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 1 Aug 2021 08:17:11 GMT Subject: RFR: JDK-8256844: Make NMT late-initializable [v2] In-Reply-To: References: Message-ID: <6J59w66r98AVbITAaSPy-YszXATSSQKNwmoUQUqtB_s=.f74958b0-1c21-4462-a75e-27b65f7b9e0f@github.com> On Fri, 30 Jul 2021 20:14:04 GMT, Zhengyu Gu wrote: >> Thomas Stuefe has updated the pull request incrementally with six additional commits since the last revision: >> >> - feedback zhengyu >> - feeback Coleen/Kim (constness fix) >> - Feedback David >> - Add test to test for non-java launcher support of NMT >> - move all test code to gtest >> - actually free blocks freed in pre-init phase > > src/hotspot/share/services/nmtPreInit.hpp line 153: > >> 151: >> 152: static unsigned calculate_hash(const void* p) { >> 153: uintptr_t tmp = p2i(p); > > malloc memory usually is 2-machine word aligned, maybe tmp = tmp >> LP64_ONLY(4) NOT_LP64(3) can result better hash distribution? I thought so too at first, but it is not necessary. The hash function uses all input bits: uintptr_t tmp = p2i(p); unsigned hash = (unsigned)tmp LP64_ONLY( ^ (unsigned)(tmp >> 32)); p2i is lossless since input and result have the same size. Then, - for 32-bit, it does not matter since unsigned is the same size as uintptr_t and we lose no bits - for 64-bit, we xor the upper half of the 64-bit input value into the lower half; again, all input bits count toward the result. We don't gain anything by shifting, we would just exchange the lower 2 bits always being zero against the upper 2 bits always being zero. --- BTW, I experimented with different hash functions, e.g. http://www.concentric.net/~Ttwang/tech/inthash.htm, but did not really get a better distribution. This somewhat mirrors my experiences when I tried to optimize your hash function in the MallocSiteTable. Seems malloc return value is already "random enough". I coupled it with a crooked table size though, made it a prime. ------------- PR: https://git.openjdk.java.net/jdk/pull/4874 From stuefe at openjdk.java.net Sun Aug 1 08:23:39 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 1 Aug 2021 08:23:39 GMT Subject: RFR: JDK-8256844: Make NMT late-initializable [v2] In-Reply-To: References: Message-ID: On Sun, 1 Aug 2021 08:17:08 GMT, Thomas Stuefe wrote: >> Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing, cleans them up and makes them sideeffect-free. >> >> --------- >> >> NMT continues to be an extremely useful tool for SAP to tackle memory problems in the JVM. >> >> However, NMT is of limited use due to the following restrictions: >> >> - NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible. >> - Worse, if that custom launcher links the libjvm *statically* there is just no way to activate NMT at all. This is the reason NMT cannot be used in the `gtestlauncher`. >> - Related to that is that we cannot pass NMT options via `JAVA_TOOL_OPTIONS` and `-XX:Flags=`. >> - The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff. >> >> The reason for all this is that NMT initialization happens very early, on the first call to `os::malloc()`. And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments. >> >> The current solution is to pass NMT arguments via a specially prepared environment variable: `NMT_LEVEL_=`. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher. >> >> All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. `java` itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand. >> >> And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., `JAVA_TOOL_OPTIONS`. >> >> ------ >> >> This patch fixes these shortcomings by making NMT late-initializable: it can now be initialized after normal VM argument parsing, like all other parts of the VM. This greatly simplifies NMT initialization and makes it work automagically for every third party launcher, as well as within our gtests. >> >> The glaring problem with late-initializing NMT is the NMT malloc headers. If we rule out just always having them (unacceptable in terms of memory overhead), there is no safe way to determine, in os::free(), if an allocation came from before or after NMT initialization ran, and therefore what to do with its malloc headers. For a more extensive explanation, please see the comment block `nmtPreInit.hpp` and the discussion with @kimbarrett and @zhengyu123 in the JBS comment section. >> >> The heart of this patch is a new way to track early, pre-NMT-init allocations. These are tracked via a lookup table. This was a suggestion by Kim and it worked out well. >> >> Changes in detail: >> >> - pre-NMT-init handling: >> - the new files `nmtPreInit.hpp/cpp` take case of NMT pre-init handling. They contain a small global lookup table managing C-heap blocks allocated in the pre-NMT-init phase. >> - `os::malloc()/os::realloc()/os::free()` defer to this code before doing anything else. >> - Please see the extensive comment block at the start of `nmtPreinit.hpp` explaining the details. >> >> - Changes to NMT: >> - Before, NMT initialization was spread over two phases, `initialize()` and `late_initialize()`. Those were merged into one and simplified - there is only one initialization now which happens after argument parsing. >> - Minor changes were needed for the `NMT_TrackingLevel` enum - to simplify code, I changed NMT_unknown to be numerically 0. A new comment block in `nmtCommon.hpp` now clearly specifies what's what, including allowed level state transitions. >> - New utility functions to translate tracking level from/to strings added to `NMTUtil` >> - NMT has never been able to handle virtual memory allocations before initialization, which is fine since os::reserve_memory() is not called before VM parses arguments. We now assert that. >> - All code outside the VM handling NMT initialization (eg. libjli) has been removed, as has the code testing it. >> >> - Gtests: >> - Some existing gtests had to be modified: before, they all changed global state (turning NMT on/off) before testing. This is not allowed anymore, to keep NMT simple. Also, this pattern disturbed other tests. >> - The new way to test is to passively check whether NMT has been switched on or off, and do tests accordingly: if on, full tests, if off, test just what makes sense in off-state. That does not disturb neighboring tests, gives us actually better coverage all around. >> - It is now possible to start the gtestlauncher with NMT on! Which additionally gives us good coverage. >> - To actually do gtests with NMT - since it's disabled by default - we now run NMT-enabled gtests as part of the hotspot jtreg NMT wrapper. This pattern we have done for a number of other facitilites, see all the tests in test/hotspot/jtreg/gtest.. . It works very well. >> - Finally, a new gtest has been written to test the NMT preinit lookup map in isolation, placed in `gtest/nmt/test_nmtpreinitmap.cpp`. >> >> - jtreg: >> - A new test has been added, `runtime/NMT/NMTInitializationTest.java`, testing NMT initialization in the face of many many VM arguments. >> >> ------------- >> >> Tests: >> - ran manually all new tests on 64-bit and 32-bit Linux >> - GHAs >> - The patch has been active in SAPs test systems for a while now. > > Thomas Stuefe has updated the pull request incrementally with six additional commits since the last revision: > > - feedback zhengyu > - feeback Coleen/Kim (constness fix) > - Feedback David > - Add test to test for non-java launcher support of NMT > - move all test code to gtest > - actually free blocks freed in pre-init phase Hi Reviewers, thanks for all the feedback! New version: - Found an embarrassing bug where I had forgotten to actually ::free preinit allocations. I went through the motions and all but forgot the final call. This would not have been a big problem, only a few scraps of memory lost, but still. Fixed with https://github.com/openjdk/jdk/pull/4874/commits/e2d40f2fbb6ee09c41c2036d37ce9bf0873ed213 - There is a piece of test code which I originally thought had to reside inside the hotspot but realized it did not. I removed it from the hotspot proper and moved it wholesale into a new gtest. https://github.com/openjdk/jdk/pull/4874/commits/caf76522d9f8fa5ec71e78b681f826de9c28be0f - I added another jtreg test to test that JDK tools can be called with -J-XX:NativeMemoryTracking and that NMT works https://github.com/openjdk/jdk/pull/4874/commits/dc340897d1a5c50af4683943484e4f42478cc7e9 - Resolved @dholmes-ora feedback, including removing more obsolete code from libjli https://github.com/openjdk/jdk/pull/4874/commits/48176dcc2afede91df92121027f4710d2638a41b - Resolved feedback from @coleenp and @kimbarrett , fixing constness issue with `NMTPreInitAllocationTable::find_entry()`. I provided two versions based on const overloading. Changes trickle up the chain, but I think its better now (e.g. const find operation return const pointers) https://github.com/openjdk/jdk/pull/4874/commits/ef24874a5cc30966eecba86ae407ab58ebeeb7a7 - Resolved @zhengyu123 feedback and removed the post-init counters. https://github.com/openjdk/jdk/pull/4874/commits/ae56cb4d0b679452e8846205f4e43c1ccf4a727e Thanks for your review work! ..Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/4874 From github.com+1701815+mkarg at openjdk.java.net Sun Aug 1 08:27:42 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sun, 1 Aug 2021 08:27:42 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v6] In-Reply-To: References: <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com> Message-ID: On Sat, 31 Jul 2021 17:33:50 GMT, Alan Bateman wrote: >>> Also can you can check that IllegalBlockingModeException is thrown for the case ch is a SelectableChannel configured non-blocking and the destination is a FileChannel? >> >> Done in https://github.com/openjdk/jdk/pull/4263/commits/8e2889fd6138d8aa8e308a1cd2aea3546a7c43a7, but honestly I'd kindly like to ask for a brief explanation why this has to be done. What actual bad effect would happen if I do not throw? > >> The modified code found in [4b501b2](https://github.com/openjdk/jdk/commit/4b501b205c6f1c48bbc82d7a154aed3fc41b1a20) should be safe from infinite loops, as it checks the actual file length in each iteration (even if this costs us one more `synchronized` per iteration). > > I need to look at it closely but I suspect this introduces a potential overflow. Also if output stream is backed by a SocketChannel configured non-blocking then FC::transferTo may return 0 so I assume there is a potential infinite loop there too. I suspect the eventually patch will need have to make use of the blockingLock to prevent the underlying channels from being changed to non-blocking during the transfer. @AlanBateman Did I recap the sum your comments correctly, is the above conclusion what you wanted to tell me? Shall I proceed with one of the two solutions outlined in the "...2:2 matrix..." section of my answer *or* shall I wait until you had a deeper look? ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From github.com+1701815+mkarg at openjdk.java.net Sun Aug 1 15:11:44 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sun, 1 Aug 2021 15:11:44 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v12] In-Reply-To: References: Message-ID: > This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review. > > As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are: > * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. > * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides. > > Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. > > I encourage everybody to discuss this draft: > * Are there valid arguments for *not* doing this change? > * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`? > * How to go on from here: What is missing to get this ready for an actual review? Markus KARG has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: [Draft] Using blocking lock to prevent concurrently switching into non-blocking mode ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4263/files - new: https://git.openjdk.java.net/jdk/pull/4263/files/f4485d5b..55c96880 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=10-11 Stats: 16 lines in 1 file changed: 8 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4263.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4263/head:pull/4263 PR: https://git.openjdk.java.net/jdk/pull/4263 From github.com+1701815+mkarg at openjdk.java.net Sun Aug 1 22:01:33 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sun, 1 Aug 2021 22:01:33 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: Message-ID: > 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 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4263/files - new: https://git.openjdk.java.net/jdk/pull/4263/files/55c96880..4a0d7cf7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=11-12 Stats: 43 lines in 1 file changed: 21 ins; 8 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/4263.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4263/head:pull/4263 PR: https://git.openjdk.java.net/jdk/pull/4263 From github.com+1701815+mkarg at openjdk.java.net Sun Aug 1 22:01:33 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sun, 1 Aug 2021 22:01:33 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v6] In-Reply-To: References: <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com> Message-ID: On Sun, 1 Aug 2021 08:24:13 GMT, Markus KARG wrote: >>> The modified code found in [4b501b2](https://github.com/openjdk/jdk/commit/4b501b205c6f1c48bbc82d7a154aed3fc41b1a20) should be safe from infinite loops, as it checks the actual file length in each iteration (even if this costs us one more `synchronized` per iteration). >> >> I need to look at it closely but I suspect this introduces a potential overflow. Also if output stream is backed by a SocketChannel configured non-blocking then FC::transferTo may return 0 so I assume there is a potential infinite loop there too. I suspect the eventually patch will need have to make use of the blockingLock to prevent the underlying channels from being changed to non-blocking during the transfer. > > @AlanBateman Did I recap the sum your comments correctly, is the above conclusion what you wanted to tell me? Shall I proceed with one of the two solutions outlined in the "...2:2 matrix..." section of my answer *or* shall I wait until you had a deeper look? Asserting blocking mode for *both* sides (source and target) in https://github.com/openjdk/jdk/pull/4263/commits/fc38eae44de9e16468d33bd2ebab6502c92b4860. Eliminated the resulting duplicate code in https://github.com/openjdk/jdk/pull/4263/commits/4a0d7cf74ee7e35aa0448df4b5ea4c5e3113ece6. Do you see more problems we need to solve? ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From dholmes at openjdk.java.net Mon Aug 2 01:32:47 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 2 Aug 2021 01:32:47 GMT Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2] In-Reply-To: References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Message-ID: <4BScf_-Ipx7eEH5LNCXAjhCn7j-JoCikldXnPzX1xZ0=.4827e655-7e70-4174-97af-2f6649e616e9@github.com> On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? >> >> the majority of the patch is the following substitutions: >> - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` >> - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` >> - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` >> - `s/sun.hotspot.code/jdk.test.whitebox.code/g` >> - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` >> - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` >> >> testing: tier1-4 >> >> Thanks, >> -- Igor > > Igor Ignatyev 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. Hi Igor, This set of changes seems much more manageable to me. Not sure about the new deprecation warnings for the old WB classes .. might that not itself trigger some failures? If not then I don't see how the deprecation warnings help with transitioning to the new WB class? Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/290 From jiefu at openjdk.java.net Mon Aug 2 01:48:33 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 2 Aug 2021 01:48:33 GMT Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2] In-Reply-To: References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Message-ID: <5SYAFqMrZzYAv1C1HVLm7ehQ22NmC401c5hiRA0KfsY=.bad74f4b-2787-44d8-9639-a809be6133ea@github.com> On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? >> >> the majority of the patch is the following substitutions: >> - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` >> - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` >> - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` >> - `s/sun.hotspot.code/jdk.test.whitebox.code/g` >> - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` >> - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` >> >> testing: tier1-4 >> >> Thanks, >> -- Igor > > Igor Ignatyev 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 12 new commits since the last revision: > > - fixed ctw build > - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's inner class > - updated requires.VMProps > - updated TEST.ROOT > - adjusted hotspot source > - added test > - moved and adjusted WhiteBox tests (test/lib-test/sun/hotspot/whitebox) > - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class > - removed sun/hotspot/parser/DiagnosticCommand > - deprecated sun/hotspot classes > disallowed s.h.WhiteBox w/ security manager > - ... and 2 more: https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860 Shall we also update the copyright year like test/lib/sun/hotspot/cpuinfo/CPUInfo.java? Thanks. ------------- PR: https://git.openjdk.java.net/jdk17/pull/290 From serb at openjdk.java.net Mon Aug 2 05:15:31 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 2 Aug 2021 05:15:31 GMT Subject: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov wrote: > I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. > This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. Changes in the desktop module looks fine. ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4487 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 07:27:33 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 2 Aug 2021 07:27:33 GMT Subject: RFR: 8269665: Clean-up toString() methods of some primitive wrappers [v2] In-Reply-To: References: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com> Message-ID: On Sun, 4 Jul 2021 21:35:31 GMT, ?????? ??????? wrote: >> As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double` and `Float` in their implementations of `Object.toString()` delegate to own utility `toString(primitive)` methods. >> >> Unlike those, `Boolean`, `Byte`, `Character` and `Short` just duplicate the contents of utility methods in implementations of `Object.toString()`. >> >> Yet another issue is a tiny discrepancy in implementation related to `Byte` and `Short` (see the first): >> >> public static String toString(byte b) { >> return Integer.toString((int)b, 10); >> } >> >> public String toString() { >> return Integer.toString((int)value); >> } >> >> Unlike in overriden method, In utility one they explicitly specify radix which can be skipped, as implementation of `Integer.toString(int,int)` has a fast-path for radix 10, ending in `Integer.toString(int)`. This simplification gives tiny improvement, see benchmark: >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class ByteToStringBenchmark { >> @Benchmark >> public String byteToString() { >> return Byte.toString((byte) 1); >> } >> } >> >> Results: >> >> before >> >> Benchmark Mode Cnt Score Error Units >> ByteToStringBenchmark.byteToString avgt 30 11,648 ? 1,906 ns/op >> ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3288,576 ? 418,119 MB/sec >> ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3301,804 ? 455,932 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 48,158 ? 2,085 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,001 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op >> ByteToStringBenchmark.byteToString:?gc.count avgt 30 202,000 counts >> ByteToStringBenchmark.byteToString:?gc.time avgt 30 413,000 ms >> >> after >> >> Benchmark Mode Cnt Score Error Units >> ByteToStringBenchmark.byteToString avgt 30 10,016 ? 0,530 ns/op >> ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3673,700 ? 167,450 MB/sec >> ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3662,406 ? 205,978 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 47,870 ? 1,750 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,002 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op >> ByteToStringBenchmark.byteToString:?gc.count avgt 30 224,000 counts >> ByteToStringBenchmark.byteToString:?gc.time avgt 30 358,000 ms > > ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: > > - 8269665: Update copy-right year > - 8269665: Reuse String.valueOf(boolean) > @stsypanov This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! Not now ------------- PR: https://git.openjdk.java.net/jdk/pull/4633 From redestad at openjdk.java.net Mon Aug 2 10:52:40 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 10:52:40 GMT Subject: RFR: 8266972: Use String.concat() in j.l.Class where invokedynamic-based String concatenation is not available [v7] In-Reply-To: <89-oUHcxXQG6OI8aEC84Y1LXclStOtfNi_UmZxs_ubc=.48ace564-95fc-452e-8438-6d655f61a0b5@github.com> References: <89-oUHcxXQG6OI8aEC84Y1LXclStOtfNi_UmZxs_ubc=.48ace564-95fc-452e-8438-6d655f61a0b5@github.com> Message-ID: On Mon, 26 Jul 2021 08:31:23 GMT, ?????? ??????? wrote: >> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like `baseName.replace('.', '/') + '/' + name` are not compiled into `invokedynamic`-based code, but into one using `StringBuilder`. This happens due to some bootstraping issues. >> >> However the code like >> >> private String getSimpleName0() { >> if (isArray()) { >> return getComponentType().getSimpleName() + "[]"; >> } >> //... >> } >> >> can be improved via replacement of `+` with `String.concat()` call. >> >> I've used this benchmark to measure impact: >> >> @State(Scope.Thread) >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class ClassMethodsBenchmark { >> private final Class arrayClass = Object[].class; >> private Method descriptorString; >> >> @Setup >> public void setUp() throws NoSuchMethodException { >> //fore some reason compiler doesn't allow me to call Class.descriptorString() directly >> descriptorString = Class.class.getDeclaredMethod("descriptorString"); >> } >> >> @Benchmark >> public Object descriptorString() throws Exception { >> return descriptorString.invoke(arrayClass); >> } >> >> @Benchmark >> public Object typeName() { >> return arrayClass.getTypeName(); >> } >> } >> >> and got those results >> >> Mode Cnt Score Error Units >> descriptorString avgt 60 91.480 ? 1.839 ns/op >> descriptorString:?gc.alloc.rate.norm avgt 60 404.008 ? 4.033 B/op >> descriptorString:?gc.churn.G1_Eden_Space avgt 60 2791.866 ? 181.589 MB/sec >> descriptorString:?gc.churn.G1_Eden_Space.norm avgt 60 401.702 ? 26.047 B/op >> descriptorString:?gc.churn.G1_Survivor_Space avgt 60 0.003 ? 0.001 MB/sec >> descriptorString:?gc.churn.G1_Survivor_Space.norm avgt 60 ? 10?? B/op >> descriptorString:?gc.count avgt 60 205.000 counts >> descriptorString:?gc.time avgt 60 216.000 ms >> >> patched >> Mode Cnt Score Error Units >> descriptorString avgt 60 65.016 ? 3.446 ns/op >> descriptorString:?gc.alloc.rate avgt 60 2844.240 ? 115.719 MB/sec >> descriptorString:?gc.alloc.rate.norm avgt 60 288.006 ? 0.001 B/op >> descriptorString:?gc.churn.G1_Eden_Space avgt 60 2832.996 ? 206.939 MB/sec >> descriptorString:?gc.churn.G1_Eden_Space.norm avgt 60 286.955 ? 17.853 B/op >> descriptorString:?gc.churn.G1_Survivor_Space avgt 60 0.003 ? 0.001 MB/sec >> descriptorString:?gc.churn.G1_Survivor_Space.norm avgt 60 ? 10?? B/op >> descriptorString:?gc.count avgt 60 208.000 counts >> descriptorString:?gc.time avgt 60 228.000 ms >> ----------------- >> typeName avgt 60 34.273 ? 0.480 ns/op >> typeName:?gc.alloc.rate avgt 60 3265.356 ? 45.113 MB/sec >> typeName:?gc.alloc.rate.norm avgt 60 176.004 ? 0.001 B/op >> typeName:?gc.churn.G1_Eden_Space avgt 60 3268.454 ? 134.458 MB/sec >> typeName:?gc.churn.G1_Eden_Space.norm avgt 60 176.109 ? 6.595 B/op >> typeName:?gc.churn.G1_Survivor_Space avgt 60 0.003 ? 0.001 MB/sec >> typeName:?gc.churn.G1_Survivor_Space.norm avgt 60 ? 10?? B/op >> typeName:?gc.count avgt 60 240.000 counts >> typeName:?gc.time avgt 60 255.000 ms >> >> patched >> >> typeName avgt 60 15.787 ? 0.214 ns/op >> typeName:?gc.alloc.rate avgt 60 2577.554 ? 32.339 MB/sec >> typeName:?gc.alloc.rate.norm avgt 60 64.001 ? 0.001 B/op >> typeName:?gc.churn.G1_Eden_Space avgt 60 2574.039 ? 147.774 MB/sec >> typeName:?gc.churn.G1_Eden_Space.norm avgt 60 63.895 ? 3.511 B/op >> typeName:?gc.churn.G1_Survivor_Space avgt 60 0.003 ? 0.001 MB/sec >> typeName:?gc.churn.G1_Survivor_Space.norm avgt 60 ? 10?? B/op >> typeName:?gc.count avgt 60 189.000 counts >> typeName:?gc.time avgt 60 199.000 ms >> >> I think this patch is likely to improve reflection operations related to arrays. >> >> If one finds this patch useful, then I'll create a ticket to track this. Also it'd be nice to have a list of classes, that are compiled in the same way as `j.l.Class` (i.e. have no access to `invokedynamic`) so I could look into them for other snippets where two String are joined so `concat`-based optimization is possible. >> >> Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and `Class.getCanonicalName0()` is one more improvement opportunity here. > > ?????? ??????? 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: > > - Merge branch 'master' into class-concat > - Merge remote-tracking branch 'origin/class-concat' into class-concat > - Merge branch 'master' into class-concat > - Merge branch 'master' into class-concat > - 8266972: Revert change in Class.descriptorString() > - Merge branch 'master' into class-concat > - Merge branch 'master' into class-concat > - 8266972: Use String.concat() in j.l.Class.toSting() > - Use String.concat() where invokedynamic-based String concatenation is not available Looks fine to me. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3627 From redestad at openjdk.java.net Mon Aug 2 10:56:38 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 10:56:38 GMT Subject: RFR: 8270160: Remove redundant bounds check from AbstractStringBuilder.charAt() [v4] In-Reply-To: References: Message-ID: <_0GD3B1zqRFApwnS16c_KJQOOoLE7Csf7YIdfVEwMQ8=.3f770eff-2426-4c02-b2c9-86b204e2771a@github.com> On Mon, 26 Jul 2021 08:22:28 GMT, ?????? ??????? wrote: >> `AbstractStringBuilder.charAt(int)` does bounds check before calling `charAt()` (for non-latin Strings): >> >> @Override >> public char charAt(int index) { >> checkIndex(index, count); >> if (isLatin1()) { >> return (char)(value[index] & 0xff); >> } >> return StringUTF16.charAt(value, index); >> } >> >> This can be improved by removing bounds check from ASB.charAt() in favour of one in String*.charAt(). This gives slight improvement: >> >> before >> Benchmark Mode Cnt Score Error Units >> StringBuilderCharAtBenchmark.latin avgt 50 2,827 ? 0,024 ns/op >> StringBuilderCharAtBenchmark.utf avgt 50 2,985 ? 0,020 ns/op >> >> after >> Benchmark Mode Cnt Score Error Units >> StringBuilderCharAtBenchmark.latin avgt 50 2,434 ? 0,004 ns/op >> StringBuilderCharAtBenchmark.utf avgt 50 2,631 ? 0,004 ns/op > > ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into 8270160 > - Merge branch 'master' into 8270160 > > # Conflicts: > # src/java.base/share/classes/java/lang/StringLatin1.java > - 8270160: Remove redundant bounds check from AbstractStringBuilder.charAt() src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 227: > 225: private void ensureCapacityInternal(int minimumCapacity) { > 226: // overflow-conscious code > 227: int oldCapacity = capacity(); This doesn't seem related to the intent of the patch, and might distort startup profiles a bit. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 352: > 350: @Override > 351: public char charAt(int index) { > 352: checkIndex(index, count); This is good and harmonizes with the implementation in `String`. src/java.base/share/classes/java/lang/StringLatin1.java line 47: > 45: public static char charAt(byte[] value, int index) { > 46: checkIndex(index, value.length); > 47: return getChar(value, index); Seems unrelated to the gist of the patch, and again might skew startup profiles. ------------- PR: https://git.openjdk.java.net/jdk/pull/4738 From redestad at openjdk.java.net Mon Aug 2 10:56:34 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 10:56:34 GMT Subject: RFR: 8270160: Remove redundant bounds check from AbstractStringBuilder.charAt() [v3] In-Reply-To: References: Message-ID: <4a-ir7XI1BVrjmCVF6rVVFJ6cHMRSMoMJRCvKW-Nu6g=.692aad5b-1032-46f7-95c1-68abecc95d04@github.com> On Thu, 15 Jul 2021 11:56:31 GMT, ?????? ??????? wrote: >> `AbstractStringBuilder.charAt(int)` does bounds check before calling `charAt()` (for non-latin Strings): >> >> @Override >> public char charAt(int index) { >> checkIndex(index, count); >> if (isLatin1()) { >> return (char)(value[index] & 0xff); >> } >> return StringUTF16.charAt(value, index); >> } >> >> This can be improved by removing bounds check from ASB.charAt() in favour of one in String*.charAt(). This gives slight improvement: >> >> before >> Benchmark Mode Cnt Score Error Units >> StringBuilderCharAtBenchmark.latin avgt 50 2,827 ? 0,024 ns/op >> StringBuilderCharAtBenchmark.utf avgt 50 2,985 ? 0,020 ns/op >> >> after >> Benchmark Mode Cnt Score Error Units >> StringBuilderCharAtBenchmark.latin avgt 50 2,434 ? 0,004 ns/op >> StringBuilderCharAtBenchmark.utf avgt 50 2,631 ? 0,004 ns/op > > ?????? ??????? 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. Changes requested by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4738 From redestad at openjdk.java.net Mon Aug 2 11:12:35 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 11:12:35 GMT Subject: RFR: 8269665: Clean-up toString() methods of some primitive wrappers [v2] In-Reply-To: References: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com> Message-ID: <7j2g1YOzRIQBkqVUshU5FPE4Ic8xdighw-G4p87pSZw=.1a0f103b-1ad9-4c4c-a8fb-974cf3365f72@github.com> On Sun, 4 Jul 2021 21:35:31 GMT, ?????? ??????? wrote: >> As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double` and `Float` in their implementations of `Object.toString()` delegate to own utility `toString(primitive)` methods. >> >> Unlike those, `Boolean`, `Byte`, `Character` and `Short` just duplicate the contents of utility methods in implementations of `Object.toString()`. >> >> Yet another issue is a tiny discrepancy in implementation related to `Byte` and `Short` (see the first): >> >> public static String toString(byte b) { >> return Integer.toString((int)b, 10); >> } >> >> public String toString() { >> return Integer.toString((int)value); >> } >> >> Unlike in overriden method, In utility one they explicitly specify radix which can be skipped, as implementation of `Integer.toString(int,int)` has a fast-path for radix 10, ending in `Integer.toString(int)`. This simplification gives tiny improvement, see benchmark: >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class ByteToStringBenchmark { >> @Benchmark >> public String byteToString() { >> return Byte.toString((byte) 1); >> } >> } >> >> Results: >> >> before >> >> Benchmark Mode Cnt Score Error Units >> ByteToStringBenchmark.byteToString avgt 30 11,648 ? 1,906 ns/op >> ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3288,576 ? 418,119 MB/sec >> ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3301,804 ? 455,932 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 48,158 ? 2,085 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,001 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op >> ByteToStringBenchmark.byteToString:?gc.count avgt 30 202,000 counts >> ByteToStringBenchmark.byteToString:?gc.time avgt 30 413,000 ms >> >> after >> >> Benchmark Mode Cnt Score Error Units >> ByteToStringBenchmark.byteToString avgt 30 10,016 ? 0,530 ns/op >> ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3673,700 ? 167,450 MB/sec >> ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3662,406 ? 205,978 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 47,870 ? 1,750 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,002 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op >> ByteToStringBenchmark.byteToString:?gc.count avgt 30 224,000 counts >> ByteToStringBenchmark.byteToString:?gc.time avgt 30 358,000 ms > > ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: > > - 8269665: Update copy-right year > - 8269665: Reuse String.valueOf(boolean) Changes requested by redestad (Reviewer). src/java.base/share/classes/java/lang/Byte.java line 93: > 91: */ > 92: public static String toString(byte b) { > 93: return Integer.toString(b); This change makes sense given the evidence that the radix tests in `Integer.toString(int, int)` are not elided. Same for the equivalent change in `Short.java`. src/java.base/share/classes/java/lang/Byte.java line 441: > 439: @Override > 440: public String toString() { > 441: return toString(value); I'm a bit more skeptical about these changes that re-route from `Integer.toString(int)` to the local `Byte.toString(byte)` which will then call `Integer.toString(int)` anyhow. An extra indirection will likely not be seen having an effect in micros, but can mess things up due inlining heuristics and of course slightly hamper startup, so I would prefer leaving the code as is. Adding missing `@Override`s is fine, of course. ------------- PR: https://git.openjdk.java.net/jdk/pull/4633 From redestad at openjdk.java.net Mon Aug 2 11:22:44 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 11:22:44 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v11] In-Reply-To: References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: <1tMR5seQ0nt1U7RbpVx7RNgvMl9Eov8JRVmmjASa5HQ=.b4f65b78-74ee-457b-b9db-e1acbfff80c2@github.com> On Mon, 26 Jul 2021 08:27:14 GMT, ?????? ??????? wrote: >> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). > > ?????? ??????? 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 13 additional commits since the last revision: > > - Merge branch 'master' into 8268113 > - 8270160 Revert changes in BitSet.hashCode > - Merge branch 'master' into 8268113 > - 8270160 Revert changes in BitSet.hashCode > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - Merge branch 'master' into 8268113 > - ... and 3 more: https://git.openjdk.java.net/jdk/compare/1d801fa0...bd762b7d All changes look good to me, though 3rd party sources like xerces/.../DoubleDV.java should probably be dealt with in the upstream first. @AlanBateman probably knows who maintains and downstreams this usually (or whether we are now practically maintaining a fork of xerces)? ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4309 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 11:34:10 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 2 Aug 2021 11:34:10 GMT Subject: RFR: 8270160: Remove redundant bounds check from AbstractStringBuilder.charAt() [v4] In-Reply-To: <_0GD3B1zqRFApwnS16c_KJQOOoLE7Csf7YIdfVEwMQ8=.3f770eff-2426-4c02-b2c9-86b204e2771a@github.com> References: <_0GD3B1zqRFApwnS16c_KJQOOoLE7Csf7YIdfVEwMQ8=.3f770eff-2426-4c02-b2c9-86b204e2771a@github.com> Message-ID: On Mon, 2 Aug 2021 10:52:26 GMT, Claes Redestad wrote: >> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Merge branch 'master' into 8270160 >> - Merge branch 'master' into 8270160 >> >> # Conflicts: >> # src/java.base/share/classes/java/lang/StringLatin1.java >> - 8270160: Remove redundant bounds check from AbstractStringBuilder.charAt() > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 227: > >> 225: private void ensureCapacityInternal(int minimumCapacity) { >> 226: // overflow-conscious code >> 227: int oldCapacity = capacity(); > > This doesn't seem related to the intent of the patch, and might distort startup profiles a bit. Reverted > src/java.base/share/classes/java/lang/StringLatin1.java line 47: > >> 45: public static char charAt(byte[] value, int index) { >> 46: checkIndex(index, value.length); >> 47: return getChar(value, index); > > Seems unrelated to the gist of the patch, and again might skew startup profiles. Reverted ------------- PR: https://git.openjdk.java.net/jdk/pull/4738 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 11:34:00 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 2 Aug 2021 11:34:00 GMT Subject: RFR: 8270160: Remove redundant bounds check from AbstractStringBuilder.charAt() [v5] In-Reply-To: References: Message-ID: > `AbstractStringBuilder.charAt(int)` does bounds check before calling `charAt()` (for non-latin Strings): > > @Override > public char charAt(int index) { > checkIndex(index, count); > if (isLatin1()) { > return (char)(value[index] & 0xff); > } > return StringUTF16.charAt(value, index); > } > > This can be improved by removing bounds check from ASB.charAt() in favour of one in String*.charAt(). This gives slight improvement: > > before > Benchmark Mode Cnt Score Error Units > StringBuilderCharAtBenchmark.latin avgt 50 2,827 ? 0,024 ns/op > StringBuilderCharAtBenchmark.utf avgt 50 2,985 ? 0,020 ns/op > > after > Benchmark Mode Cnt Score Error Units > StringBuilderCharAtBenchmark.latin avgt 50 2,434 ? 0,004 ns/op > StringBuilderCharAtBenchmark.utf avgt 50 2,631 ? 0,004 ns/op ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8270160 Revert irrelevant changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4738/files - new: https://git.openjdk.java.net/jdk/pull/4738/files/c8be3be4..529fdcd4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4738&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4738&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4738.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4738/head:pull/4738 PR: https://git.openjdk.java.net/jdk/pull/4738 From redestad at openjdk.java.net Mon Aug 2 11:40:36 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 11:40:36 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList [v5] In-Reply-To: References: Message-ID: <_IT0JRHdfpmkeZIKV0F3138xY_AJgeRi8_-iRh0ZgkQ=.2b1bfed1-0473-4f45-be5a-8da3a3b14406@github.com> On Mon, 26 Jul 2021 08:27:20 GMT, ?????? ??????? wrote: >> After I've renamed remove branch GitHub for some reason has closed original https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it. > > ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge branch 'master' into 8263561 > - Merge branch 'master' into 8263561 > - Merge branch 'master' into 8263561 > - Merge branch 'master' into 8263561 > - Merge branch 'master' into 8263561 > > # Conflicts: > # src/java.base/unix/classes/sun/net/dns/ResolverConfigurationImpl.java > - Merge branch 'master' into purge-linked-list > - 8263561: Use sized constructor where reasonable > - 8263561: Use interface List instead of particular type where possible > - 8263561: Rename requestList -> requests > - 8263561: Re-examine uses of LinkedList I always approve of removing LinkedLists and Vectors. Using ArrayDeque in AbstractPoller seems like the right choice. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4304 From redestad at openjdk.java.net Mon Aug 2 11:43:33 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 11:43:33 GMT Subject: RFR: 8270160: Remove redundant bounds check from AbstractStringBuilder.charAt() [v5] In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 11:34:00 GMT, ?????? ??????? wrote: >> `AbstractStringBuilder.charAt(int)` does bounds check before calling `charAt()` (for non-latin Strings): >> >> @Override >> public char charAt(int index) { >> checkIndex(index, count); >> if (isLatin1()) { >> return (char)(value[index] & 0xff); >> } >> return StringUTF16.charAt(value, index); >> } >> >> This can be improved by removing bounds check from ASB.charAt() in favour of one in String*.charAt(). This gives slight improvement: >> >> before >> Benchmark Mode Cnt Score Error Units >> StringBuilderCharAtBenchmark.latin avgt 50 2,827 ? 0,024 ns/op >> StringBuilderCharAtBenchmark.utf avgt 50 2,985 ? 0,020 ns/op >> >> after >> Benchmark Mode Cnt Score Error Units >> StringBuilderCharAtBenchmark.latin avgt 50 2,434 ? 0,004 ns/op >> StringBuilderCharAtBenchmark.utf avgt 50 2,631 ? 0,004 ns/op > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8270160 Revert irrelevant changes Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4738 From sgehwolf at openjdk.java.net Mon Aug 2 11:45:32 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 2 Aug 2021 11:45:32 GMT Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v6] In-Reply-To: References: <80NDhQE20WOO7LMCDS9C9zYQIRy-YKqNiGgrPQAPI64=.ef6e55d9-8995-4669-9c6f-e10a61bd427f@github.com> <_CXJ5Lcpd7-PqzRzGAtEE4NyZzAGirYGSgVT7KbPyFw=.f2ce7164-7d28-4b6e-9a79-9417054e0113@github.com> Message-ID: <7iBHbVtU_eX1kulxCimscf3qRO213qaZ8fyK2-_aJGA=.c6c9e083-e098-409f-9b8f-685cab8ff977@github.com> On Tue, 27 Jul 2021 10:25:22 GMT, Matthias Baesken wrote: > What do you think about accepting, when setting -1/unlimited, a high limit number like 20.000+ as well (and and a comment that on some setups unlimited means just "high number" but not unlimited? This seems most reasonable. I'd suggest to accept a limit of `> 20000` or `Unlimited` in the test output. In case of it NOT being `Unlimited` for the `--pids-limit=-1` case, I'd also include the actual output in logs with a message that it got accepted as unlimited. > Another Idea I had was to start a little test java program that creates e.g. 50.000 (or another high number) of threads. If this fails with "unilimited" pids-limit set, we might have a setup like yours and then skip the test (or accept a high number like I suggested). This seems overkill and prone to failures, IMHO. ------------- PR: https://git.openjdk.java.net/jdk/pull/4518 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 12:29:00 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 2 Aug 2021 12:29:00 GMT Subject: RFR: 8269665: Clean-up toString() methods of some primitive wrappers [v3] In-Reply-To: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com> References: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com> Message-ID: > As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double` and `Float` in their implementations of `Object.toString()` delegate to own utility `toString(primitive)` methods. > > Unlike those, `Boolean`, `Byte`, `Character` and `Short` just duplicate the contents of utility methods in implementations of `Object.toString()`. > > Yet another issue is a tiny discrepancy in implementation related to `Byte` and `Short` (see the first): > > public static String toString(byte b) { > return Integer.toString((int)b, 10); > } > > public String toString() { > return Integer.toString((int)value); > } > > Unlike in overriden method, In utility one they explicitly specify radix which can be skipped, as implementation of `Integer.toString(int,int)` has a fast-path for radix 10, ending in `Integer.toString(int)`. This simplification gives tiny improvement, see benchmark: > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class ByteToStringBenchmark { > @Benchmark > public String byteToString() { > return Byte.toString((byte) 1); > } > } > > Results: > > before > > Benchmark Mode Cnt Score Error Units > ByteToStringBenchmark.byteToString avgt 30 11,648 ? 1,906 ns/op > ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3288,576 ? 418,119 MB/sec > ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op > ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3301,804 ? 455,932 MB/sec > ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 48,158 ? 2,085 B/op > ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,001 MB/sec > ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op > ByteToStringBenchmark.byteToString:?gc.count avgt 30 202,000 counts > ByteToStringBenchmark.byteToString:?gc.time avgt 30 413,000 ms > > after > > Benchmark Mode Cnt Score Error Units > ByteToStringBenchmark.byteToString avgt 30 10,016 ? 0,530 ns/op > ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3673,700 ? 167,450 MB/sec > ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op > ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3662,406 ? 205,978 MB/sec > ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 47,870 ? 1,750 B/op > ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,002 MB/sec > ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op > ByteToStringBenchmark.byteToString:?gc.count avgt 30 224,000 counts > ByteToStringBenchmark.byteToString:?gc.time avgt 30 358,000 ms ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8269665: Revert irrelevant changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4633/files - new: https://git.openjdk.java.net/jdk/pull/4633/files/e939d72b..b9fb156c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4633&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4633&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4633.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4633/head:pull/4633 PR: https://git.openjdk.java.net/jdk/pull/4633 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 12:29:03 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 2 Aug 2021 12:29:03 GMT Subject: RFR: 8269665: Clean-up toString() methods of some primitive wrappers [v2] In-Reply-To: <7j2g1YOzRIQBkqVUshU5FPE4Ic8xdighw-G4p87pSZw=.1a0f103b-1ad9-4c4c-a8fb-974cf3365f72@github.com> References: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com> <7j2g1YOzRIQBkqVUshU5FPE4Ic8xdighw-G4p87pSZw=.1a0f103b-1ad9-4c4c-a8fb-974cf3365f72@github.com> Message-ID: On Mon, 2 Aug 2021 11:09:30 GMT, Claes Redestad wrote: >> ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8269665: Update copy-right year >> - 8269665: Reuse String.valueOf(boolean) > > src/java.base/share/classes/java/lang/Byte.java line 441: > >> 439: @Override >> 440: public String toString() { >> 441: return toString(value); > > I'm a bit more skeptical about these changes that re-route from `Integer.toString(int)` to the local `Byte.toString(byte)` which will then call `Integer.toString(int)` anyhow. An extra indirection will likely not be seen having an effect in micros, but can mess things up due inlining heuristics and of course slightly hamper startup, so I would prefer leaving the code as is. Adding missing `@Override`s is fine, of course. Reverted ------------- PR: https://git.openjdk.java.net/jdk/pull/4633 From redestad at openjdk.java.net Mon Aug 2 12:34:35 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 12:34:35 GMT Subject: RFR: 8269665: Clean-up toString() methods of some primitive wrappers [v3] In-Reply-To: References: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com> Message-ID: <75kOSfsEE1Iomy8_XE5-KzHLO7TFz39YYZ0MW_mxy60=.20236468-723d-4ca5-b78b-77b34c24480a@github.com> On Mon, 2 Aug 2021 12:29:00 GMT, ?????? ??????? wrote: >> As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double` and `Float` in their implementations of `Object.toString()` delegate to own utility `toString(primitive)` methods. >> >> Unlike those, `Boolean`, `Byte`, `Character` and `Short` just duplicate the contents of utility methods in implementations of `Object.toString()`. >> >> Yet another issue is a tiny discrepancy in implementation related to `Byte` and `Short` (see the first): >> >> public static String toString(byte b) { >> return Integer.toString((int)b, 10); >> } >> >> public String toString() { >> return Integer.toString((int)value); >> } >> >> Unlike in overriden method, In utility one they explicitly specify radix which can be skipped, as implementation of `Integer.toString(int,int)` has a fast-path for radix 10, ending in `Integer.toString(int)`. This simplification gives tiny improvement, see benchmark: >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class ByteToStringBenchmark { >> @Benchmark >> public String byteToString() { >> return Byte.toString((byte) 1); >> } >> } >> >> Results: >> >> before >> >> Benchmark Mode Cnt Score Error Units >> ByteToStringBenchmark.byteToString avgt 30 11,648 ? 1,906 ns/op >> ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3288,576 ? 418,119 MB/sec >> ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3301,804 ? 455,932 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 48,158 ? 2,085 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,001 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op >> ByteToStringBenchmark.byteToString:?gc.count avgt 30 202,000 counts >> ByteToStringBenchmark.byteToString:?gc.time avgt 30 413,000 ms >> >> after >> >> Benchmark Mode Cnt Score Error Units >> ByteToStringBenchmark.byteToString avgt 30 10,016 ? 0,530 ns/op >> ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3673,700 ? 167,450 MB/sec >> ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3662,406 ? 205,978 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 47,870 ? 1,750 B/op >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,002 MB/sec >> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op >> ByteToStringBenchmark.byteToString:?gc.count avgt 30 224,000 counts >> ByteToStringBenchmark.byteToString:?gc.time avgt 30 358,000 ms > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8269665: Revert irrelevant changes Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4633 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 12:39:47 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 2 Aug 2021 12:39:47 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList [v6] In-Reply-To: References: Message-ID: > After I've renamed remove branch GitHub for some reason has closed original https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it. ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge branch 'master' into 8263561 # Conflicts: # src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java - Merge branch 'master' into 8263561 - Merge branch 'master' into 8263561 - Merge branch 'master' into 8263561 - Merge branch 'master' into 8263561 - Merge branch 'master' into 8263561 # Conflicts: # src/java.base/unix/classes/sun/net/dns/ResolverConfigurationImpl.java - Merge branch 'master' into purge-linked-list - 8263561: Use sized constructor where reasonable - 8263561: Use interface List instead of particular type where possible - 8263561: Rename requestList -> requests - ... and 1 more: https://git.openjdk.java.net/jdk/compare/7cc1eb3e...dea42cac ------------- Changes: https://git.openjdk.java.net/jdk/pull/4304/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4304&range=05 Stats: 47 lines in 9 files changed: 0 ins; 2 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/4304.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4304/head:pull/4304 PR: https://git.openjdk.java.net/jdk/pull/4304 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 12:49:38 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 2 Aug 2021 12:49:38 GMT Subject: Integrated: 8269665: Clean-up toString() methods of some primitive wrappers In-Reply-To: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com> References: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com> Message-ID: On Wed, 30 Jun 2021 08:40:21 GMT, ?????? ??????? wrote: > As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double` and `Float` in their implementations of `Object.toString()` delegate to own utility `toString(primitive)` methods. > > Unlike those, `Boolean`, `Byte`, `Character` and `Short` just duplicate the contents of utility methods in implementations of `Object.toString()`. > > Yet another issue is a tiny discrepancy in implementation related to `Byte` and `Short` (see the first): > > public static String toString(byte b) { > return Integer.toString((int)b, 10); > } > > public String toString() { > return Integer.toString((int)value); > } > > Unlike in overriden method, In utility one they explicitly specify radix which can be skipped, as implementation of `Integer.toString(int,int)` has a fast-path for radix 10, ending in `Integer.toString(int)`. This simplification gives tiny improvement, see benchmark: > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class ByteToStringBenchmark { > @Benchmark > public String byteToString() { > return Byte.toString((byte) 1); > } > } > > Results: > > before > > Benchmark Mode Cnt Score Error Units > ByteToStringBenchmark.byteToString avgt 30 11,648 ? 1,906 ns/op > ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3288,576 ? 418,119 MB/sec > ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op > ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3301,804 ? 455,932 MB/sec > ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 48,158 ? 2,085 B/op > ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,001 MB/sec > ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op > ByteToStringBenchmark.byteToString:?gc.count avgt 30 202,000 counts > ByteToStringBenchmark.byteToString:?gc.time avgt 30 413,000 ms > > after > > Benchmark Mode Cnt Score Error Units > ByteToStringBenchmark.byteToString avgt 30 10,016 ? 0,530 ns/op > ByteToStringBenchmark.byteToString:?gc.alloc.rate avgt 30 3673,700 ? 167,450 MB/sec > ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm avgt 30 48,001 ? 0,001 B/op > ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space avgt 30 3662,406 ? 205,978 MB/sec > ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm avgt 30 47,870 ? 1,750 B/op > ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space avgt 30 0,004 ? 0,002 MB/sec > ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op > ByteToStringBenchmark.byteToString:?gc.count avgt 30 224,000 counts > ByteToStringBenchmark.byteToString:?gc.time avgt 30 358,000 ms This pull request has now been integrated. Changeset: 72145f3b Author: Sergey Tsypanov Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/72145f3b9472c8f5f64f9b9ac93e3331e646f15a Stats: 13 lines in 4 files changed: 4 ins; 0 del; 9 mod 8269665: Clean-up toString() methods of some primitive wrappers Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/4633 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 12:50:36 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 2 Aug 2021 12:50:36 GMT Subject: Integrated: 8266972: Use String.concat() in j.l.Class where invokedynamic-based String concatenation is not available In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 14:07:20 GMT, ?????? ??????? wrote: > Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like `baseName.replace('.', '/') + '/' + name` are not compiled into `invokedynamic`-based code, but into one using `StringBuilder`. This happens due to some bootstraping issues. > > However the code like > > private String getSimpleName0() { > if (isArray()) { > return getComponentType().getSimpleName() + "[]"; > } > //... > } > > can be improved via replacement of `+` with `String.concat()` call. > > I've used this benchmark to measure impact: > > @State(Scope.Thread) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class ClassMethodsBenchmark { > private final Class arrayClass = Object[].class; > private Method descriptorString; > > @Setup > public void setUp() throws NoSuchMethodException { > //fore some reason compiler doesn't allow me to call Class.descriptorString() directly > descriptorString = Class.class.getDeclaredMethod("descriptorString"); > } > > @Benchmark > public Object descriptorString() throws Exception { > return descriptorString.invoke(arrayClass); > } > > @Benchmark > public Object typeName() { > return arrayClass.getTypeName(); > } > } > > and got those results > > Mode Cnt Score Error Units > descriptorString avgt 60 91.480 ? 1.839 ns/op > descriptorString:?gc.alloc.rate.norm avgt 60 404.008 ? 4.033 B/op > descriptorString:?gc.churn.G1_Eden_Space avgt 60 2791.866 ? 181.589 MB/sec > descriptorString:?gc.churn.G1_Eden_Space.norm avgt 60 401.702 ? 26.047 B/op > descriptorString:?gc.churn.G1_Survivor_Space avgt 60 0.003 ? 0.001 MB/sec > descriptorString:?gc.churn.G1_Survivor_Space.norm avgt 60 ? 10?? B/op > descriptorString:?gc.count avgt 60 205.000 counts > descriptorString:?gc.time avgt 60 216.000 ms > > patched > Mode Cnt Score Error Units > descriptorString avgt 60 65.016 ? 3.446 ns/op > descriptorString:?gc.alloc.rate avgt 60 2844.240 ? 115.719 MB/sec > descriptorString:?gc.alloc.rate.norm avgt 60 288.006 ? 0.001 B/op > descriptorString:?gc.churn.G1_Eden_Space avgt 60 2832.996 ? 206.939 MB/sec > descriptorString:?gc.churn.G1_Eden_Space.norm avgt 60 286.955 ? 17.853 B/op > descriptorString:?gc.churn.G1_Survivor_Space avgt 60 0.003 ? 0.001 MB/sec > descriptorString:?gc.churn.G1_Survivor_Space.norm avgt 60 ? 10?? B/op > descriptorString:?gc.count avgt 60 208.000 counts > descriptorString:?gc.time avgt 60 228.000 ms > ----------------- > typeName avgt 60 34.273 ? 0.480 ns/op > typeName:?gc.alloc.rate avgt 60 3265.356 ? 45.113 MB/sec > typeName:?gc.alloc.rate.norm avgt 60 176.004 ? 0.001 B/op > typeName:?gc.churn.G1_Eden_Space avgt 60 3268.454 ? 134.458 MB/sec > typeName:?gc.churn.G1_Eden_Space.norm avgt 60 176.109 ? 6.595 B/op > typeName:?gc.churn.G1_Survivor_Space avgt 60 0.003 ? 0.001 MB/sec > typeName:?gc.churn.G1_Survivor_Space.norm avgt 60 ? 10?? B/op > typeName:?gc.count avgt 60 240.000 counts > typeName:?gc.time avgt 60 255.000 ms > > patched > > typeName avgt 60 15.787 ? 0.214 ns/op > typeName:?gc.alloc.rate avgt 60 2577.554 ? 32.339 MB/sec > typeName:?gc.alloc.rate.norm avgt 60 64.001 ? 0.001 B/op > typeName:?gc.churn.G1_Eden_Space avgt 60 2574.039 ? 147.774 MB/sec > typeName:?gc.churn.G1_Eden_Space.norm avgt 60 63.895 ? 3.511 B/op > typeName:?gc.churn.G1_Survivor_Space avgt 60 0.003 ? 0.001 MB/sec > typeName:?gc.churn.G1_Survivor_Space.norm avgt 60 ? 10?? B/op > typeName:?gc.count avgt 60 189.000 counts > typeName:?gc.time avgt 60 199.000 ms > > I think this patch is likely to improve reflection operations related to arrays. > > If one finds this patch useful, then I'll create a ticket to track this. Also it'd be nice to have a list of classes, that are compiled in the same way as `j.l.Class` (i.e. have no access to `invokedynamic`) so I could look into them for other snippets where two String are joined so `concat`-based optimization is possible. > > Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and `Class.getCanonicalName0()` is one more improvement opportunity here. This pull request has now been integrated. Changeset: 6c4c48fa Author: Sergey Tsypanov Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/6c4c48faea8a8309a71d7a5d261f776031014881 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 8266972: Use String.concat() in j.l.Class where invokedynamic-based String concatenation is not available Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/3627 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 12:51:39 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 2 Aug 2021 12:51:39 GMT Subject: Integrated: 8270160: Remove redundant bounds check from AbstractStringBuilder.charAt() In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 11:50:38 GMT, ?????? ??????? wrote: > `AbstractStringBuilder.charAt(int)` does bounds check before calling `charAt()` (for non-latin Strings): > > @Override > public char charAt(int index) { > checkIndex(index, count); > if (isLatin1()) { > return (char)(value[index] & 0xff); > } > return StringUTF16.charAt(value, index); > } > > This can be improved by removing bounds check from ASB.charAt() in favour of one in String*.charAt(). This gives slight improvement: > > before > Benchmark Mode Cnt Score Error Units > StringBuilderCharAtBenchmark.latin avgt 50 2,827 ? 0,024 ns/op > StringBuilderCharAtBenchmark.utf avgt 50 2,985 ? 0,020 ns/op > > after > Benchmark Mode Cnt Score Error Units > StringBuilderCharAtBenchmark.latin avgt 50 2,434 ? 0,004 ns/op > StringBuilderCharAtBenchmark.utf avgt 50 2,631 ? 0,004 ns/op This pull request has now been integrated. Changeset: 2536e434 Author: Sergey Tsypanov Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/2536e4342e6c33c16685c9983b09f83a9c7ea869 Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod 8270160: Remove redundant bounds check from AbstractStringBuilder.charAt() Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/4738 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 12:52:34 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 2 Aug 2021 12:52:34 GMT Subject: Integrated: 8268113: Re-use Long.hashCode() where possible In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: On Wed, 2 Jun 2021 14:10:38 GMT, ?????? ??????? wrote: > There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). This pull request has now been integrated. Changeset: 6a3f8343 Author: Sergey Tsypanov Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/6a3f8343bc0e92c29a87c5840cbef9ab2988f153 Stats: 10 lines in 6 files changed: 0 ins; 4 del; 6 mod 8268113: Re-use Long.hashCode() where possible Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/4309 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 2 12:53:37 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 2 Aug 2021 12:53:37 GMT Subject: Integrated: 8263561: Re-examine uses of LinkedList In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 12:10:46 GMT, ?????? ??????? wrote: > After I've renamed remove branch GitHub for some reason has closed original https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it. This pull request has now been integrated. Changeset: 249d6418 Author: Sergey Tsypanov Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/249d641889c6f9aed6957502d5fca9c74c9baceb Stats: 47 lines in 9 files changed: 0 ins; 2 del; 45 mod 8263561: Re-examine uses of LinkedList Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/4304 From redestad at openjdk.java.net Mon Aug 2 13:36:42 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 13:36:42 GMT Subject: RFR: 8271611: Use SecurityConstants.ACCESS_PERMISSION in MethodHandles Message-ID: <23sfJhxmfKvZ6gLI-w2L0rjP6EB-0IR_NdVtn-OROVI=.34fc0b76-4970-469f-a902-aa5f7239b1a7@github.com> Reusing SecurityConstants.ACCESS_PERMISSION (which was moved from AccessibleObject by JDK-8202419) avoids initialization of ReflectPermission when no SecurityManager is installed ------------- Commit messages: - Use SecurityConstants.ACCESS_PERMISSION in MethodHandles Changes: https://git.openjdk.java.net/jdk/pull/4957/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4957&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271611 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4957.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4957/head:pull/4957 PR: https://git.openjdk.java.net/jdk/pull/4957 From herrick at openjdk.java.net Mon Aug 2 13:54:50 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Mon, 2 Aug 2021 13:54:50 GMT Subject: RFR: JDK-8271344: Windows product version issue Message-ID: JDK-8271344: Windows product version issue ------------- Commit messages: - JDK-8271344: Windows product version issue Changes: https://git.openjdk.java.net/jdk/pull/4958/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4958&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271344 Stats: 21 lines in 5 files changed: 5 ins; 2 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/4958.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4958/head:pull/4958 PR: https://git.openjdk.java.net/jdk/pull/4958 From daniel.peintner at gmail.com Mon Aug 2 13:57:09 2021 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Mon, 2 Aug 2021 15:57:09 +0200 Subject: [External] : Re: jpackage MacOS Notarization In-Reply-To: <7092667d-6ac9-1e82-27e4-3bca64fd5a8b@oracle.com> References: <9d2ab55d-7ab7-b4a9-d49d-3f8e92e8da6a@oracle.com> <7092667d-6ac9-1e82-27e4-3bca64fd5a8b@oracle.com> Message-ID: Hi Andy, > sorry - code looks for certificate key starting with: "Developer ID > Application: " + in order to not > have to put full user name in. I missed that that with null user name that > causes it to look for anything starting with "Developer ID Application: " > (same thing with "Developer ID Installer: " for .pkg signing). And macos > looks at the non-default keychains as well as the default ones when no > keychain is specified. > Thanks for your feedback and yes in the simple case (with one certificate installed) it works without any further information. May I ask you whether you were able to reproduce the issue? Is there anything I can do to help? Thanks, -- Daniel > /Andy > On 7/29/2021 10:00 AM, Daniel Peintner wrote: > > Hi Andy, > > Since I don't know your setup I did not put anything there. > > '--mac-sign' is enough to use the defaults in my setup. > > It looks for the signing keys installed on my machine that start with "Developer > ID Application " similar to > '--mac-signing-key-user-name', 'Developer ID Application: ' > etc. > > If you want to test it you need to add your credentials which I do not > know. > > Hope this clarifies things, > > -- Daniel > > > > On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick > wrote: > >> The 'build.gradle' in this branch has --mac-signing-key-user-name >> commented out. >> >> installerOptions += [ >> '--mac-sign', >> // '--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name', >> System.getenv('SIGNING_KEY_USER_NAME'), >> // '--mac-signing-keychain', >> System.getenv('SIGNING_KEYCHAIN_PATH') >> ] >> >> clearly this cannot work, I assume you were just trying things ... >> >> What is the full name of the certificate you intended to use, what >> keychain is it shown in "Keychain Access", and what are you normal values >> for your environment variables: 'SIGNING_KEY_USER_NAME' and >> 'SIGNING_KEYCHAIN_PATH' ? >> >> /Andy >> On 7/29/2021 4:36 AM, Daniel Peintner wrote: >> >> Kevin, Andy, >> >> Thanks for your quick response. >> >> Full support for notarization in jpackage was added in JDK 17. Can you >>> try an early access build of JDK 17 [1] and see if that works for you? >>> >> >> I did try JDK17-ea-32 also with the same result. >> >> Since I do understand it is difficult reproduce the problem I put >> together a *very* simple test application which you can find in the >> "non-modular" branch here: >> https://github.com/danielpeintner/Java11Test/tree/non-modular >> >> >> It is a gradle project. It uses Java 11 to run but in build.gradle on >> line#83 [1] one can set the jpackage location (JDK17-ea-32 in this case). >> >> The process is as follows >> * ./gradlew build >> * ./gradlew jpackage // creates the dmg/pkg in folder build/jpackage >> * afterwards Apple notarization process can be started >> >> Note: notarization of dmg or pkg lead to the same failure. >> See [2] for the full log w.r.t. pkg. >> >> I hope this helps you to be able to reproduce the issue. >> >> Thanks for your investigations! >> >> -- Daniel >> >> [1] >> https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle#L83 >> >> [2] >> https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs%2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w%2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh%2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX%2FN6zZoyz73I%3D >> >> >> >>> >>> >>> -- Kevin >>> >>> [1] https://jdk.java.net/17 >>> >>> >>> On 7/28/2021 8:27 AM, Daniel Peintner wrote: >>> > All, >>> > >>> > I am trying to notarize an app (built with jpackage) for MacOS. >>> > >>> > jpackage at first *seems* to properly sign all resources with the >>> available >>> > --mac-sign options et cetera. >>> > >>> > Having said that, there are still remaining issues >>> > 1. The app cannot be properly installed >>> > (without hacks like xattr -d com.apple.quarantine >>> /Applications/myAPP.app >>> > ). >>> > 2. I am also not able to properly notarize the app. >>> > >>> > According to online resources there seem to exist issues in *past* >>> about >>> > notarization but according to [1, 2] the issues are fixed. >>> > >>> > As mentioned, I still have issues :-( >>> > Am I really the only one still having problems? >>> > >>> > Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without >>> success) >>> > >>> > The issue seems to boil down to 2 errors (attached the error log from >>> Apple >>> > notarization process). >>> > * app Folder >>> > * libjli.dylib >>> > >>> > I thought I better ask first on the mailing list before creating an >>> actual >>> > bug report. >>> > >>> > Note1: I used to use the *old* javapackager that worked with the same >>> > signature/credentials. >>> > Note2: running jpackage without --mac-sign options causes many more >>> errors >>> > in notarization (Hence, jpackage signs most resources but fails with >>> some) >>> > >>> > Any help / hint appreciated. >>> > >>> > Thanks, >>> > >>> > -- Daniel >>> > >>> > [1] https://bugs.openjdk.java.net/browse/JDK-8257488 >>> > [2] https://bugs.openjdk.java.net/browse/JDK-8251892 >>> > >>> > >>> > >>> > ## APPLE LOG ## >>> > >>> > { >>> > "logFormatVersion": 1, >>> > "jobId": "...", >>> > "status": "Invalid", >>> > "statusSummary": "Archive contains critical validation errors", >>> > "statusCode": 4000, >>> > "archiveFilename": "myAPP-21.07.28.dmg", >>> > "uploadDate": "2021-07-28T14:31:24Z", >>> > "sha256": "...", >>> > "ticketContents": null, >>> > "issues": [ >>> > { >>> > "severity": "error", >>> > "code": null, >>> > "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP", >>> > "message": "The signature of the binary is invalid.", >>> > "docUrl": null, >>> > "architecture": "x86_64" >>> > }, >>> > { >>> > "severity": "error", >>> > "code": null, >>> > "path": >>> "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib", >>> > "message": "The signature of the binary is invalid.", >>> > "docUrl": null, >>> > "architecture": "x86_64" >>> > } >>> > ] >>> > } >>> >>> From coleenp at openjdk.java.net Mon Aug 2 14:28:33 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 2 Aug 2021 14:28:33 GMT Subject: RFR: JDK-8256844: Make NMT late-initializable [v2] In-Reply-To: References: Message-ID: <9fJF6K7k4Pn7Ktu4W9KgcjmekQv3wYfS1pWiA0SlntI=.177a2a19-0639-4a8b-8ed5-f5f3d4030713@github.com> On Fri, 30 Jul 2021 09:44:57 GMT, Thomas Stuefe wrote: > Is that a real-life problem? Are there cases where the launcher would want to live on if the JVM failed to load? There are a lot of other reasons why the launcher couldn't live on if the JVM fails to load. This was only one of them. We used to think about this problem once but don't really think it's solveable. ------------- PR: https://git.openjdk.java.net/jdk/pull/4874 From coleenp at openjdk.java.net Mon Aug 2 14:28:33 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 2 Aug 2021 14:28:33 GMT Subject: RFR: JDK-8256844: Make NMT late-initializable [v2] In-Reply-To: References: Message-ID: On Fri, 30 Jul 2021 09:32:22 GMT, Thomas Stuefe wrote: >> [Not a review, just a drive-by comment.] This is a normal and idiomatic overload on the const-ness of `this`. > > To expand on Kim's answer. This is a way to solve const/nonconst problems like https://github.com/openjdk/jdk/pull/4938/files#r679639391. > > You get a const version (suitably returning a write-protected pointer) which the compiler chooses in const code, and a non-const version for non-const code, and no awkward const-casts are needed from the outside. > > In this case the implementation is simple enough that I just duplicated it; were it more complex, I'd call one in terms of the other. We do this in other places too, see e.g. `ResourceHashTable::lookup_node`. This is ok. This was just new to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/4874 From rriggs at openjdk.java.net Mon Aug 2 14:33:37 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 2 Aug 2021 14:33:37 GMT Subject: RFR: 8271611: Use SecurityConstants.ACCESS_PERMISSION in MethodHandles In-Reply-To: <23sfJhxmfKvZ6gLI-w2L0rjP6EB-0IR_NdVtn-OROVI=.34fc0b76-4970-469f-a902-aa5f7239b1a7@github.com> References: <23sfJhxmfKvZ6gLI-w2L0rjP6EB-0IR_NdVtn-OROVI=.34fc0b76-4970-469f-a902-aa5f7239b1a7@github.com> Message-ID: <2wHztuvg6ZuuOJ9K2KZVhZW1vI1Zv5iVImrKMHqqYL8=.e0b9961d-06de-4176-8257-bc1ffec9eabe@github.com> On Mon, 2 Aug 2021 13:27:15 GMT, Claes Redestad wrote: > Reusing SecurityConstants.ACCESS_PERMISSION (which was moved from AccessibleObject by JDK-8202419) avoids initialization of ReflectPermission when no SecurityManager is installed LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4957 From lzang at openjdk.java.net Mon Aug 2 14:39:37 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 2 Aug 2021 14:39:37 GMT Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v9] In-Reply-To: References: Message-ID: <5DDRBWy4rFI9s5CVo9atKf3kc254LdIrX8V1xDSVyvY=.348ed25b-5cf3-4723-826a-023494f48e4f@github.com> On Tue, 27 Jul 2021 15:52:23 GMT, Alan Bateman wrote: >> Thank you for reviving the discussion. >> >> I have not gone through the latest update in detail but there are some changes that are needed. Before moving forward with the CSR, I would like to give time for additional feedback on naming and design. >> >> I am not sure the builder names withXXX are the preferred naming pattern. > >> I have not gone through the latest update in detail but there are some changes that are needed. Before moving forward with the CSR, I would like to give time for additional feedback on naming and design. > > This proposal will need a few iterations to get to the right API. There are several issues with the proposed GZIPHeaderBuilder, also GZIPHeaderData is mutable (having byte[] as elements in a record is a hazard). I will try to make time in the coming weeks to help. Dear @AlanBateman and @LanceAndersen, Sorry for late response, and really appreciated for your help on looking at this PR. I will update the pr based on Lance's comments first. Thanks! Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/3072 From coleenp at openjdk.java.net Mon Aug 2 14:41:38 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 2 Aug 2021 14:41:38 GMT Subject: RFR: JDK-8256844: Make NMT late-initializable [v2] In-Reply-To: References: Message-ID: On Sun, 1 Aug 2021 08:17:08 GMT, Thomas Stuefe wrote: >> Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing, cleans them up and makes them sideeffect-free. >> >> --------- >> >> NMT continues to be an extremely useful tool for SAP to tackle memory problems in the JVM. >> >> However, NMT is of limited use due to the following restrictions: >> >> - NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible. >> - Worse, if that custom launcher links the libjvm *statically* there is just no way to activate NMT at all. This is the reason NMT cannot be used in the `gtestlauncher`. >> - Related to that is that we cannot pass NMT options via `JAVA_TOOL_OPTIONS` and `-XX:Flags=`. >> - The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff. >> >> The reason for all this is that NMT initialization happens very early, on the first call to `os::malloc()`. And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments. >> >> The current solution is to pass NMT arguments via a specially prepared environment variable: `NMT_LEVEL_=`. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher. >> >> All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. `java` itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand. >> >> And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., `JAVA_TOOL_OPTIONS`. >> >> ------ >> >> This patch fixes these shortcomings by making NMT late-initializable: it can now be initialized after normal VM argument parsing, like all other parts of the VM. This greatly simplifies NMT initialization and makes it work automagically for every third party launcher, as well as within our gtests. >> >> The glaring problem with late-initializing NMT is the NMT malloc headers. If we rule out just always having them (unacceptable in terms of memory overhead), there is no safe way to determine, in os::free(), if an allocation came from before or after NMT initialization ran, and therefore what to do with its malloc headers. For a more extensive explanation, please see the comment block `nmtPreInit.hpp` and the discussion with @kimbarrett and @zhengyu123 in the JBS comment section. >> >> The heart of this patch is a new way to track early, pre-NMT-init allocations. These are tracked via a lookup table. This was a suggestion by Kim and it worked out well. >> >> Changes in detail: >> >> - pre-NMT-init handling: >> - the new files `nmtPreInit.hpp/cpp` take case of NMT pre-init handling. They contain a small global lookup table managing C-heap blocks allocated in the pre-NMT-init phase. >> - `os::malloc()/os::realloc()/os::free()` defer to this code before doing anything else. >> - Please see the extensive comment block at the start of `nmtPreinit.hpp` explaining the details. >> >> - Changes to NMT: >> - Before, NMT initialization was spread over two phases, `initialize()` and `late_initialize()`. Those were merged into one and simplified - there is only one initialization now which happens after argument parsing. >> - Minor changes were needed for the `NMT_TrackingLevel` enum - to simplify code, I changed NMT_unknown to be numerically 0. A new comment block in `nmtCommon.hpp` now clearly specifies what's what, including allowed level state transitions. >> - New utility functions to translate tracking level from/to strings added to `NMTUtil` >> - NMT has never been able to handle virtual memory allocations before initialization, which is fine since os::reserve_memory() is not called before VM parses arguments. We now assert that. >> - All code outside the VM handling NMT initialization (eg. libjli) has been removed, as has the code testing it. >> >> - Gtests: >> - Some existing gtests had to be modified: before, they all changed global state (turning NMT on/off) before testing. This is not allowed anymore, to keep NMT simple. Also, this pattern disturbed other tests. >> - The new way to test is to passively check whether NMT has been switched on or off, and do tests accordingly: if on, full tests, if off, test just what makes sense in off-state. That does not disturb neighboring tests, gives us actually better coverage all around. >> - It is now possible to start the gtestlauncher with NMT on! Which additionally gives us good coverage. >> - To actually do gtests with NMT - since it's disabled by default - we now run NMT-enabled gtests as part of the hotspot jtreg NMT wrapper. This pattern we have done for a number of other facitilites, see all the tests in test/hotspot/jtreg/gtest.. . It works very well. >> - Finally, a new gtest has been written to test the NMT preinit lookup map in isolation, placed in `gtest/nmt/test_nmtpreinitmap.cpp`. >> >> - jtreg: >> - A new test has been added, `runtime/NMT/NMTInitializationTest.java`, testing NMT initialization in the face of many many VM arguments. >> >> ------------- >> >> Tests: >> - ran manually all new tests on 64-bit and 32-bit Linux >> - GHAs >> - The patch has been active in SAPs test systems for a while now. > > Thomas Stuefe has updated the pull request incrementally with six additional commits since the last revision: > > - feedback zhengyu > - feeback Coleen/Kim (constness fix) > - Feedback David > - Add test to test for non-java launcher support of NMT > - move all test code to gtest > - actually free blocks freed in pre-init phase This looks good. Thanks for fixing the mysterious (to me) cast. src/hotspot/share/services/nmtPreInit.cpp line 207: > 205: static TestAllocations g_test_allocations; // make this an automatic object to let ctor run during in C++ dynamic initialization. > 206: #endif // ASSERT > 207: Oh, good. I was hoping this didn't need to be an in-jvm test. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4874 From lzang at openjdk.java.net Mon Aug 2 15:03:45 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 2 Aug 2021 15:03:45 GMT Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v9] In-Reply-To: References: Message-ID: <0HK-hupQYkk8LZsEhQbC7mglXao9Pi0rfc7xMLIvnIk=.797d203b-0598-48d2-a118-5788ab05d6e7@github.com> On Mon, 26 Jul 2021 20:55:00 GMT, Lance Andersen wrote: >> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: >> >> - change since version to 18 >> - Merge branch 'master' into gzip-field >> - Merge branch 'master' into gzip-field >> - Add api in GZIPInputStream to get header data >> - Merge remote-tracking branch 'upstream/master' into gzip-field >> - remove trailing spaces >> - Use record and Builder pattern >> - add class GZIPHeaderData, refine testcases >> - update copyright >> - reuse arguments constructor for non-argument one. >> - ... and 3 more: https://git.openjdk.java.net/jdk/compare/e627caec...b1868e8f > > src/java.base/share/classes/java/util/zip/GZIPHeaderBuilder.java line 114: > >> 112: */ >> 113: public GZIPHeaderBuilder withFileComment(String fileComment) { >> 114: if (fileComment == null || fileComment.length() == 0) { > > What happens if the String contains characters outside of ISO_8859_1? good point! I am not sure whether there should be a check for the characters encoding, I didn't find any implementation that does the check (e.g. the gzip.c implementation) . But I prefer the idea of checking here, as the specification has defined the encoding. ------------- PR: https://git.openjdk.java.net/jdk/pull/3072 From asemenyuk at openjdk.java.net Mon Aug 2 15:29:30 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 2 Aug 2021 15:29:30 GMT Subject: RFR: JDK-8271344: Windows product version issue In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 13:45:17 GMT, Andy Herrick wrote: > JDK-8271344: Windows product version issue Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4958 From redestad at openjdk.java.net Mon Aug 2 15:38:33 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 15:38:33 GMT Subject: RFR: 8271611: Use SecurityConstants.ACCESS_PERMISSION in MethodHandles In-Reply-To: <2wHztuvg6ZuuOJ9K2KZVhZW1vI1Zv5iVImrKMHqqYL8=.e0b9961d-06de-4176-8257-bc1ffec9eabe@github.com> References: <23sfJhxmfKvZ6gLI-w2L0rjP6EB-0IR_NdVtn-OROVI=.34fc0b76-4970-469f-a902-aa5f7239b1a7@github.com> <2wHztuvg6ZuuOJ9K2KZVhZW1vI1Zv5iVImrKMHqqYL8=.e0b9961d-06de-4176-8257-bc1ffec9eabe@github.com> Message-ID: <21zPR0WAHHUBiv1wNSZLIZjHb2Tv-K9FdKLwaEB9PHw=.2ab28b2b-202b-4d95-8e92-46ccd3a16395@github.com> On Mon, 2 Aug 2021 14:30:08 GMT, Roger Riggs wrote: >> Reusing SecurityConstants.ACCESS_PERMISSION (which was moved from AccessibleObject by JDK-8202419) avoids initialization of ReflectPermission when no SecurityManager is installed > > LGTM Thanks for the review @RogerRiggs! ------------- PR: https://git.openjdk.java.net/jdk/pull/4957 From redestad at openjdk.java.net Mon Aug 2 15:38:34 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 15:38:34 GMT Subject: Integrated: 8271611: Use SecurityConstants.ACCESS_PERMISSION in MethodHandles In-Reply-To: <23sfJhxmfKvZ6gLI-w2L0rjP6EB-0IR_NdVtn-OROVI=.34fc0b76-4970-469f-a902-aa5f7239b1a7@github.com> References: <23sfJhxmfKvZ6gLI-w2L0rjP6EB-0IR_NdVtn-OROVI=.34fc0b76-4970-469f-a902-aa5f7239b1a7@github.com> Message-ID: On Mon, 2 Aug 2021 13:27:15 GMT, Claes Redestad wrote: > Reusing SecurityConstants.ACCESS_PERMISSION (which was moved from AccessibleObject by JDK-8202419) avoids initialization of ReflectPermission when no SecurityManager is installed This pull request has now been integrated. Changeset: 7a4c754e Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/7a4c754e5db374a7bc3dd36bb1ccf7e8e7821d3b Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod 8271611: Use SecurityConstants.ACCESS_PERMISSION in MethodHandles Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/4957 From lance.andersen at oracle.com Mon Aug 2 15:43:05 2021 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 2 Aug 2021 15:43:05 +0000 Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v9] In-Reply-To: <5DDRBWy4rFI9s5CVo9atKf3kc254LdIrX8V1xDSVyvY=.348ed25b-5cf3-4723-826a-023494f48e4f@github.com> References: <5DDRBWy4rFI9s5CVo9atKf3kc254LdIrX8V1xDSVyvY=.348ed25b-5cf3-4723-826a-023494f48e4f@github.com> Message-ID: On Aug 2, 2021, at 10:39 AM, Lin Zang > wrote: On Tue, 27 Jul 2021 15:52:23 GMT, Alan Bateman > wrote: Thank you for reviving the discussion. I have not gone through the latest update in detail but there are some changes that are needed. Before moving forward with the CSR, I would like to give time for additional feedback on naming and design. I am not sure the builder names withXXX are the preferred naming pattern. I have not gone through the latest update in detail but there are some changes that are needed. Before moving forward with the CSR, I would like to give time for additional feedback on naming and design. This proposal will need a few iterations to get to the right API. There are several issues with the proposed GZIPHeaderBuilder, also GZIPHeaderData is mutable (having byte[] as elements in a record is a hazard). I will try to make time in the coming weeks to help. Dear @AlanBateman and @LanceAndersen, Sorry for late response, and really appreciated for your help on looking at this PR. I will update the pr based on Lance's comments first. Thanks! Hi Lin, I would hold off on updates to the PR until Alan has a chance to provide his input. I have not yet had time to go through everything outside of the very quick pass I made earlier. Best Lance Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/3072 [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lzang at openjdk.java.net Mon Aug 2 15:43:41 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 2 Aug 2021 15:43:41 GMT Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v9] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 20:47:59 GMT, Lance Andersen wrote: >> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: >> >> - change since version to 18 >> - Merge branch 'master' into gzip-field >> - Merge branch 'master' into gzip-field >> - Add api in GZIPInputStream to get header data >> - Merge remote-tracking branch 'upstream/master' into gzip-field >> - remove trailing spaces >> - Use record and Builder pattern >> - add class GZIPHeaderData, refine testcases >> - update copyright >> - reuse arguments constructor for non-argument one. >> - ... and 3 more: https://git.openjdk.java.net/jdk/compare/e627caec...b1868e8f > > src/java.base/share/classes/java/util/zip/GZIPHeaderBuilder.java line 136: > >> 134: return this; >> 135: } >> 136: > > Is this really needed as a public method ? >From the spec RFC-1952(https://www.ietf.org/rfc/rfc1952.txt), the FHCRC is an optional field which user can decide whether to use it or not. So here I make it public. May be we can enable it by default? Let's discuss it and make the decision :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3072 From lancea at openjdk.java.net Mon Aug 2 15:50:51 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 2 Aug 2021 15:50:51 GMT Subject: Integrated: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside In-Reply-To: References: Message-ID: On Sun, 25 Jul 2021 21:56:10 GMT, Lance Andersen wrote: > Hi, > > As discussed in the https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html thread, this is the revised patch to address the use of '.' and '..' within Zip FS > > Zip FS needs to use "." and ".." as links to the current and parent directories and cannot reliably support entries that have "." and ".." as name elements. This patch updates Zip Fs to reject ZIP files that have entries in the CEN that can't be used for files in a file system. > > > Mach5 tiers 1 through 3 have been run without any errors encountered . > > Best, > Lance This pull request has now been integrated. Changeset: 3e3051e2 Author: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/3e3051e2ee93142983e9a3edee038e4f7b5ac0f2 Stats: 201 lines in 3 files changed: 200 ins; 0 del; 1 mod 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside Reviewed-by: alanb, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/4900 From stuefe at openjdk.java.net Mon Aug 2 15:51:34 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 2 Aug 2021 15:51:34 GMT Subject: RFR: JDK-8256844: Make NMT late-initializable [v2] In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 14:38:23 GMT, Coleen Phillimore wrote: > This looks good. Thanks for fixing the mysterious (to me) cast. Thank you, Coleen! ------------- PR: https://git.openjdk.java.net/jdk/pull/4874 From linzang at tencent.com Mon Aug 2 15:55:56 2021 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Mon, 2 Aug 2021 15:55:56 +0000 Subject: [Internet]Re: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v9] Message-ID: <1A271656-EF89-4C78-9D7D-1259C5D8A179@tencent.com> Dear Lance, OK, Thanks for your reviewing and effort! BRs, Lin From: Lance Andersen Date: Monday, August 2, 2021 at 11:43 PM To: Lin Zang Cc: "core-libs-dev at openjdk.java.net" Subject: [Internet]Re: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v9] On Aug 2, 2021, at 10:39 AM, Lin Zang > wrote: On Tue, 27 Jul 2021 15:52:23 GMT, Alan Bateman > wrote: Thank you for reviving the discussion. I have not gone through the latest update in detail but there are some changes that are needed. Before moving forward with the CSR, I would like to give time for additional feedback on naming and design. I am not sure the builder names withXXX are the preferred naming pattern. I have not gone through the latest update in detail but there are some changes that are needed. Before moving forward with the CSR, I would like to give time for additional feedback on naming and design. This proposal will need a few iterations to get to the right API. There are several issues with the proposed GZIPHeaderBuilder, also GZIPHeaderData is mutable (having byte[] as elements in a record is a hazard). I will try to make time in the coming weeks to help. Dear @AlanBateman and @LanceAndersen, Sorry for late response, and really appreciated for your help on looking at this PR. I will update the pr based on Lance's comments first. Thanks! Hi Lin, I would hold off on updates to the PR until Alan has a chance to provide his input. I have not yet had time to go through everything outside of the very quick pass I made earlier. Best Lance Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/3072 [cid:image001.gif at 01D787F9.EF1164E0] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From kvn at openjdk.java.net Mon Aug 2 15:59:36 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 2 Aug 2021 15:59:36 GMT Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2] In-Reply-To: References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Message-ID: On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? >> >> the majority of the patch is the following substitutions: >> - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` >> - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` >> - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` >> - `s/sun.hotspot.code/jdk.test.whitebox.code/g` >> - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` >> - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` >> >> testing: tier1-4 >> >> Thanks, >> -- Igor > > Igor Ignatyev 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. I agree with these revised changes for JDK 17. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/290 From lzang at openjdk.java.net Mon Aug 2 16:00:16 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 2 Aug 2021 16:00:16 GMT Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v10] In-Reply-To: References: Message-ID: > 4890732: GZIPOutputStream doesn't support optional GZIP fields Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - refine code - Merge branch 'master' into gzip-field - change since version to 18 - Merge branch 'master' into gzip-field - Merge branch 'master' into gzip-field - Add api in GZIPInputStream to get header data - Merge remote-tracking branch 'upstream/master' into gzip-field - remove trailing spaces - Use record and Builder pattern - add class GZIPHeaderData, refine testcases - ... and 5 more: https://git.openjdk.java.net/jdk/compare/249d6418...474e54ce ------------- Changes: https://git.openjdk.java.net/jdk/pull/3072/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=09 Stats: 618 lines in 4 files changed: 568 ins; 26 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/3072.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072 PR: https://git.openjdk.java.net/jdk/pull/3072 From lzang at openjdk.java.net Mon Aug 2 16:05:13 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 2 Aug 2021 16:05:13 GMT Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v11] In-Reply-To: References: Message-ID: > 4890732: GZIPOutputStream doesn't support optional GZIP fields Lin Zang has updated the pull request incrementally with one additional commit since the last revision: delete trailing spaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3072/files - new: https://git.openjdk.java.net/jdk/pull/3072/files/474e54ce..35debf28 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3072.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072 PR: https://git.openjdk.java.net/jdk/pull/3072 From iignatyev at openjdk.java.net Mon Aug 2 16:25:19 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 2 Aug 2021 16:25:19 GMT Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v3] In-Reply-To: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Message-ID: > Hi all, > > could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? > > the majority of the patch is the following substitutions: > - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` > - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` > - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` > - `s/sun.hotspot.code/jdk.test.whitebox.code/g` > - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` > - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` > > testing: tier1-4 > > Thanks, > -- Igor Igor Ignatyev has updated the pull request incrementally with two additional commits since the last revision: - copyright update - fixed typo in ClassFileInstaller ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/290/files - new: https://git.openjdk.java.net/jdk17/pull/290/files/237e8860..fcaf41f8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=290&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=290&range=01-02 Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk17/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk17/pull/290 From iignatyev at openjdk.java.net Mon Aug 2 16:25:21 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 2 Aug 2021 16:25:21 GMT Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2] In-Reply-To: References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Message-ID: On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? >> >> the majority of the patch is the following substitutions: >> - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` >> - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` >> - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` >> - `s/sun.hotspot.code/jdk.test.whitebox.code/g` >> - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` >> - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` >> >> testing: tier1-4 >> >> Thanks, >> -- Igor > > Igor Ignatyev 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 12 new commits since the last revision: > > - fixed ctw build > - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's inner class > - updated requires.VMProps > - updated TEST.ROOT > - adjusted hotspot source > - added test > - moved and adjusted WhiteBox tests (test/lib-test/sun/hotspot/whitebox) > - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class > - removed sun/hotspot/parser/DiagnosticCommand > - deprecated sun/hotspot classes > disallowed s.h.WhiteBox w/ security manager > - ... and 2 more: https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860 Hi David, > This set of changes seems much more manageable to me. thank you for your review, David. > Not sure about the new deprecation warnings for the old WB classes .. might that not itself trigger some failures? If not then I don't see how the deprecation warnings help with transitioning to the new WB class? the deprecation warnings (hopefully) will help people not to forget that they should use the new WB class in new tests. Thanks, -- Igor Hi Jie, > Shall we also update the copyright year like test/lib/sun/hotspot/cpuinfo/CPUInfo.java? we most certainly shall, just pushed the commit that updates the copyright years in the touched files. Cheers, -- Igor ------------- PR: https://git.openjdk.java.net/jdk17/pull/290 From iignatyev at openjdk.java.net Mon Aug 2 16:26:33 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 2 Aug 2021 16:26:33 GMT Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2] In-Reply-To: References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Message-ID: On Mon, 2 Aug 2021 15:56:39 GMT, Vladimir Kozlov wrote: > I agree with these revised changes for JDK 17. Thanks for your review, Vladimir. I'll rerun my testing before integrating (just for good luck). -- Igor ------------- PR: https://git.openjdk.java.net/jdk17/pull/290 From redestad at openjdk.java.net Mon Aug 2 18:10:48 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 18:10:48 GMT Subject: RFR: 8271624: Avoid unnecessary ThreadGroup.checkAccess calls when creating Threads Message-ID: <1P8lVQJHDgZzKXXps1B39tkkMJNBSetsCF8-0MgdXE0=.3e67803f-976f-418c-bc6d-af767f5b9d68@github.com> Trivially avoid some redundant calls when creating threads. (ThreadGroup.checkAccess is final, and all it does is call security.checkAccess(g) if there's a SM installed) ------------- Commit messages: - Merge branch 'master' into thread_access - Avoid calling ThreadGroup.checkAccess when no SecurityManager is installed Changes: https://git.openjdk.java.net/jdk/pull/4959/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4959&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271624 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4959/head:pull/4959 PR: https://git.openjdk.java.net/jdk/pull/4959 From redestad at openjdk.java.net Mon Aug 2 18:35:50 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 18:35:50 GMT Subject: RFR: 8271627: Use local field access in favor of Class.getClassLoader0 Message-ID: Trivial startup hack/cleanup to use the `classLoader` field directly rather than the `getClassLoader0` accessor. Before aa12c8fbf5b020d168cf29412643bf15514b0439 there was no `classLoader` field and `getClassLoader0` was a native method that retrieved the `ClassLoader` by calling into the runtime. However, now that `classLoader` is injected on mirror creation it makes less sense to use the accessor when not necessary. ------------- Commit messages: - Merge branch 'master' into startup_classLoader0 - Avoid getClassLoader0 calls from within Class - Reuse SecurityConstants.ACCESS_PERMISSION from MethodHandles Changes: https://git.openjdk.java.net/jdk/pull/4960/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4960&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271627 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4960.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4960/head:pull/4960 PR: https://git.openjdk.java.net/jdk/pull/4960 From duke at openjdk.java.net Mon Aug 2 18:58:36 2021 From: duke at openjdk.java.net (duke) Date: Mon, 2 Aug 2021 18:58:36 GMT Subject: Withdrawn: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 00:09:33 GMT, Joe Darcy wrote: > Make explicit illegal argument cases of Class.arrayType. > > Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8268300 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4382 From rriggs at openjdk.java.net Mon Aug 2 19:43:32 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 2 Aug 2021 19:43:32 GMT Subject: RFR: 8271624: Avoid unnecessary ThreadGroup.checkAccess calls when creating Threads In-Reply-To: <1P8lVQJHDgZzKXXps1B39tkkMJNBSetsCF8-0MgdXE0=.3e67803f-976f-418c-bc6d-af767f5b9d68@github.com> References: <1P8lVQJHDgZzKXXps1B39tkkMJNBSetsCF8-0MgdXE0=.3e67803f-976f-418c-bc6d-af767f5b9d68@github.com> Message-ID: On Mon, 2 Aug 2021 18:03:42 GMT, Claes Redestad wrote: > Trivially avoid some redundant calls when creating threads. (ThreadGroup.checkAccess is final, and all it does is call security.checkAccess(g) if there's a SM installed) LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4959 From mchung at openjdk.java.net Mon Aug 2 19:47:34 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 2 Aug 2021 19:47:34 GMT Subject: RFR: 8271627: Use local field access in favor of Class.getClassLoader0 In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 18:27:00 GMT, Claes Redestad wrote: > Trivial startup hack/cleanup to use the `classLoader` field directly rather than the `getClassLoader0` accessor. > > Before aa12c8fbf5b020d168cf29412643bf15514b0439 there was no `classLoader` field and `getClassLoader0` was a native method that retrieved the `ClassLoader` by calling into the runtime. However, now that `classLoader` is injected on mirror creation it makes less sense to use the accessor when not necessary. This looks okay. I assume you concern about the early startup when this method is running in interpreted mode. Do you see any startup improvement by this change? ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4960 From github.com+70726043+rgiulietti at openjdk.java.net Mon Aug 2 20:06:45 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Mon, 2 Aug 2021 20:06:45 GMT Subject: RFR: 8271601: Math.floorMod(int, int) and Math.floorMod(long, long) differ in their logic Message-ID: Hello, please review this tiny change in the implementation of j.l.Math.floorMod(int, int). While the results are unaffected, all of floorDiv(int, int) floorDiv(long, long) floorMod(long, long) use x ^ y in the tests to correct the result if needed. Not only is the proposed change more consistent with the other methods, but it might benefit later stages in the cpu to proceed with the evaluation of x ^ y in parallel with the previous x % y and, depending of the outcome, even further down. Greetings Raffaello ------------- Commit messages: - 8271601: Math.floorMod(int, int) and Math.floorMod(long, long) differ in their logic Changes: https://git.openjdk.java.net/jdk/pull/4962/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4962&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271601 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4962.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4962/head:pull/4962 PR: https://git.openjdk.java.net/jdk/pull/4962 From redestad at openjdk.java.net Mon Aug 2 20:41:30 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 20:41:30 GMT Subject: RFR: 8271627: Use local field access in favor of Class.getClassLoader0 In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 19:44:22 GMT, Mandy Chung wrote: > Do you see any startup improvement by this change? Very tiny, ~90 calls on bootstrap. > This looks okay. Thanks! > I assume you concern about the early startup when this method is running in interpreted mode. Do you see any startup improvement by this change? Yes. Many of these things that will be executed only when loading and bootstrapping, so might be interpreted for most of a JVM lifecycle. Right off the bat see a thousand or so less bytecode get executed on a hello world with this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/4960 From iignatyev at openjdk.java.net Mon Aug 2 20:47:35 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 2 Aug 2021 20:47:35 GMT Subject: [jdk17] Integrated: 8067223: [TESTBUG] Rename Whitebox API package In-Reply-To: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Message-ID: <7NcTTjXdOT2FGyik79Who_BkmchG225aO4-ufpU1eZk=.9b2f1a53-7739-49ce-b2b8-f587d78f55e4@github.com> On Wed, 28 Jul 2021 17:13:49 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? > > the majority of the patch is the following substitutions: > - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` > - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` > - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` > - `s/sun.hotspot.code/jdk.test.whitebox.code/g` > - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` > - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` > > testing: tier1-4 > > Thanks, > -- Igor This pull request has now been integrated. Changeset: ada58d13 Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk17/commit/ada58d13f78eb8a240220c45c573335eeb47cf07 Stats: 532 lines in 36 files changed: 449 ins; 0 del; 83 mod 8067223: [TESTBUG] Rename Whitebox API package Reviewed-by: dholmes, kvn ------------- PR: https://git.openjdk.java.net/jdk17/pull/290 From david.holmes at oracle.com Mon Aug 2 22:00:36 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 Aug 2021 08:00:36 +1000 Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2] In-Reply-To: References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Message-ID: On 3/08/2021 2:25 am, Igor Ignatyev wrote: > On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote: > >>> Hi all, >>> >>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? >>> >>> the majority of the patch is the following substitutions: >>> - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` >>> - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` >>> - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` >>> - `s/sun.hotspot.code/jdk.test.whitebox.code/g` >>> - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` >>> - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` >>> >>> testing: tier1-4 >>> >>> Thanks, >>> -- Igor >> >> Igor Ignatyev 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 12 new commits since the last revision: >> >> - fixed ctw build >> - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's inner class >> - updated requires.VMProps >> - updated TEST.ROOT >> - adjusted hotspot source >> - added test >> - moved and adjusted WhiteBox tests (test/lib-test/sun/hotspot/whitebox) >> - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class >> - removed sun/hotspot/parser/DiagnosticCommand >> - deprecated sun/hotspot classes >> disallowed s.h.WhiteBox w/ security manager >> - ... and 2 more: https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860 > > Hi David, > >> This set of changes seems much more manageable to me. > > thank you for your review, David. > >> Not sure about the new deprecation warnings for the old WB classes .. might that not itself trigger some failures? If not then I don't see how the deprecation warnings help with transitioning to the new WB class? > > the deprecation warnings (hopefully) will help people not to forget that they should use the new WB class in new tests. If the test passes it is unlikely people will actually notice these in the jtr file - and even if they see them they may just ignore them thinking they are similar to all the security manager warnings that we ignore. But as long as it does no harm. Cheers, David > Thanks, > -- Igor > > Hi Jie, >> Shall we also update the copyright year like test/lib/sun/hotspot/cpuinfo/CPUInfo.java? > > we most certainly shall, just pushed the commit that updates the copyright years in the touched files. > > Cheers, > -- Igor > > ------------- > > PR: https://git.openjdk.java.net/jdk17/pull/290 > From redestad at openjdk.java.net Mon Aug 2 22:40:36 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 22:40:36 GMT Subject: Integrated: 8271627: Use local field access in favor of Class.getClassLoader0 In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 18:27:00 GMT, Claes Redestad wrote: > Trivial startup hack/cleanup to use the `classLoader` field directly rather than the `getClassLoader0` accessor. > > Before aa12c8fbf5b020d168cf29412643bf15514b0439 there was no `classLoader` field and `getClassLoader0` was a native method that retrieved the `ClassLoader` by calling into the runtime. However, now that `classLoader` is injected on mirror creation it makes less sense to use the accessor when not necessary. This pull request has now been integrated. Changeset: e621cffa Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/e621cffa4fee0b403a8650519c70e0a6cb76b03c Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod 8271627: Use local field access in favor of Class.getClassLoader0 Reviewed-by: mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/4960 From github.com+70726043+rgiulietti at openjdk.java.net Mon Aug 2 22:43:42 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Mon, 2 Aug 2021 22:43:42 GMT Subject: RFR: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places Message-ID: Hello, please review the changes in documentation of floorDiv() and floorMod() in all their variants. Some are clarifications, some are corrections. Here's an example of a confusing formulation in the current doc > "the / operator returns the integer closest to zero" Literally, the integer closest to zero is zero! The doc of floorMod(int, int) also states: > "If the signs of arguments are unknown and a positive modulus > is needed it can be computed as (floorMod(x, y) + abs(y)) % abs(y)." That's a questionable advice, as the sum in parentheses can lead to irrecoverable overflow (beside requiring two divisions instead of one). E.g., setting x = Integer.MAX_VALUE - 1, y = Integer.MAX_VALUE leads to the quite incorrect result -3, which is not even positive! Greetings Raffaello ------------- Commit messages: - 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places Changes: https://git.openjdk.java.net/jdk/pull/4963/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4963&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271599 Stats: 31 lines in 1 file changed: 4 ins; 7 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/4963.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4963/head:pull/4963 PR: https://git.openjdk.java.net/jdk/pull/4963 From bpb at openjdk.java.net Mon Aug 2 22:49:30 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 2 Aug 2021 22:49:30 GMT Subject: RFR: 8271601: Math.floorMod(int, int) and Math.floorMod(long, long) differ in their logic In-Reply-To: References: Message-ID: <0J3bi1qdvqrduTtQGpQ4vLMp3U2wrGs1XYx3Cz1YRwU=.a1dd1c5a-d905-467a-a528-2b10ee8e85ef@github.com> On Mon, 2 Aug 2021 19:59:57 GMT, Raffaello Giulietti wrote: > Hello, > > please review this tiny change in the implementation of j.l.Math.floorMod(int, int). > > While the results are unaffected, all of > floorDiv(int, int) > floorDiv(long, long) > floorMod(long, long) > use x ^ y in the tests to correct the result if needed. > > Not only is the proposed change more consistent with the other methods, but it might benefit later stages in the cpu to proceed with the evaluation of x ^ y in parallel with the previous x % y and, depending of the outcome, even further down. > > > Greetings > Raffaello This looks all right to me. Verified by running all `java/lang/Math` tests against the patch. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4962 From redestad at openjdk.java.net Mon Aug 2 23:02:34 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 23:02:34 GMT Subject: RFR: 8271624: Avoid unnecessary ThreadGroup.checkAccess calls when creating Threads In-Reply-To: References: <1P8lVQJHDgZzKXXps1B39tkkMJNBSetsCF8-0MgdXE0=.3e67803f-976f-418c-bc6d-af767f5b9d68@github.com> Message-ID: On Mon, 2 Aug 2021 19:40:12 GMT, Roger Riggs wrote: >> Trivially avoid some redundant calls when creating threads. (ThreadGroup.checkAccess is final, and all it does is call security.checkAccess(g) if there's a SM installed) > > LGTM Thanks again @RogerRiggs! ------------- PR: https://git.openjdk.java.net/jdk/pull/4959 From redestad at openjdk.java.net Mon Aug 2 23:02:34 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Aug 2021 23:02:34 GMT Subject: Integrated: 8271624: Avoid unnecessary ThreadGroup.checkAccess calls when creating Threads In-Reply-To: <1P8lVQJHDgZzKXXps1B39tkkMJNBSetsCF8-0MgdXE0=.3e67803f-976f-418c-bc6d-af767f5b9d68@github.com> References: <1P8lVQJHDgZzKXXps1B39tkkMJNBSetsCF8-0MgdXE0=.3e67803f-976f-418c-bc6d-af767f5b9d68@github.com> Message-ID: On Mon, 2 Aug 2021 18:03:42 GMT, Claes Redestad wrote: > Trivially avoid some redundant calls when creating threads. (ThreadGroup.checkAccess is final, and all it does is call security.checkAccess(g) if there's a SM installed) This pull request has now been integrated. Changeset: 0b953940 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/0b9539405d764670a1a6dca5a6552b58c3edd7a3 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod 8271624: Avoid unnecessary ThreadGroup.checkAccess calls when creating Threads Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/4959 From almatvee at openjdk.java.net Mon Aug 2 23:05:34 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 2 Aug 2021 23:05:34 GMT Subject: RFR: JDK-8271344: Windows product version issue In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 13:45:17 GMT, Andy Herrick wrote: > JDK-8271344: Windows product version issue Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4958 From jwilhelm at openjdk.java.net Mon Aug 2 23:38:00 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 2 Aug 2021 23:38:00 GMT Subject: RFR: Merge jdk17 Message-ID: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com> Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8067223: [TESTBUG] Rename Whitebox API package - 8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34) The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4964&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4964&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4964/files Stats: 535 lines in 37 files changed: 449 ins; 1 del; 85 mod Patch: https://git.openjdk.java.net/jdk/pull/4964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4964/head:pull/4964 PR: https://git.openjdk.java.net/jdk/pull/4964 From jwilhelm at openjdk.java.net Mon Aug 2 23:53:59 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 2 Aug 2021 23:53:59 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com> References: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com> Message-ID: > Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: Revert "8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34)" This reverts commit f8fb5713074b8960f5530d7aca954f84d57c1f30. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4964/files - new: https://git.openjdk.java.net/jdk/pull/4964/files/a95b06a1..e353ddcc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4964&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4964&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4964/head:pull/4964 PR: https://git.openjdk.java.net/jdk/pull/4964 From mikael at openjdk.java.net Tue Aug 3 00:01:33 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Tue, 3 Aug 2021 00:01:33 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: References: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com> Message-ID: <8IbQAIkLr13OmKSOcnZrb5FRd6tN-pdqAAJlHnIbh-8=.cbb12df6-21d6-42c4-b9f4-82db2dadc9b4@github.com> On Mon, 2 Aug 2021 23:53:59 GMT, Jesper Wilhelmsson wrote: >> Forwardport JDK 17 -> JDK 18 > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Revert "8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34)" > > This reverts commit f8fb5713074b8960f5530d7aca954f84d57c1f30. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4964 From bpb at openjdk.java.net Tue Aug 3 00:16:03 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 3 Aug 2021 00:16:03 GMT Subject: RFR: 8271225: Add floorDivExact() method to java.lang.[Strict]Math [v2] In-Reply-To: References: Message-ID: > Add methods `floorDivExact(int,int)` and `floorDivExact(long,long)` to `java.lang.Math` and `java.lang.StrictMath`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8271225: Some verbiage updates ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4941/files - new: https://git.openjdk.java.net/jdk/pull/4941/files/03e83cda..7601fe9b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4941&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4941&range=00-01 Stats: 20 lines in 2 files changed: 0 ins; 0 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/4941.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4941/head:pull/4941 PR: https://git.openjdk.java.net/jdk/pull/4941 From jwilhelm at openjdk.java.net Tue Aug 3 01:04:35 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 3 Aug 2021 01:04:35 GMT Subject: Integrated: Merge jdk17 In-Reply-To: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com> References: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com> Message-ID: On Mon, 2 Aug 2021 23:30:55 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: c8add223 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/c8add223a10030e40ccef42e081fd0d8f00e0593 Stats: 534 lines in 36 files changed: 449 ins; 1 del; 84 mod Merge Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/4964 From github.com+70726043+rgiulietti at openjdk.java.net Tue Aug 3 08:45:30 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Tue, 3 Aug 2021 08:45:30 GMT Subject: RFR: 8271225: Add floorDivExact() method to java.lang.[Strict]Math In-Reply-To: References: Message-ID: <83UNXL7d91UFeJPj1EyRR7JEc_nY0GUrLSZxFR5GECo=.4bc03eb1-4f39-44fd-b96a-470360034054@github.com> On Thu, 29 Jul 2021 23:28:07 GMT, Brian Burkhalter wrote: >> Add methods `floorDivExact(int,int)` and `floorDivExact(long,long)` to `java.lang.Math` and `java.lang.StrictMath`. > > The `floorDivExact()` methods are identical to their `floorDiv()` counterparts aside from that they throw an `ArithmeticException` when the dividend is `MIN_VALUE` and the divisor is `-1`. These methods behave with respect to the methods `floorDiv()` as the methods `divideExact()` behave with respect to the division operator `/`. Hello @bplb, the doc of floorDivExact() is not, well..., exact. For example, > The floor rounding mode gives different results from truncation when the exact result is negative. The truth is that the results are different when the exact quotient _is not an integer and is negative_. The description following this sentence is imprecise as well. The doc seems to have been copied and adapted from the doc of floorDiv(), which is imprecise in the first place. You might want to take a look at [PR 4963](https://github.com/openjdk/jdk/pull/4963) which addresses this and wait until that one is thoroughly discussed for mathematical accuracy and correct wording. Greetings Raffaello ------------- PR: https://git.openjdk.java.net/jdk/pull/4941 From whuang at openjdk.java.net Tue Aug 3 13:33:07 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 3 Aug 2021 13:33:07 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v5] In-Reply-To: References: Message-ID: > Dear all, > Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo. > > * We add a JMH test case > * Here is the result of this test case > > Benchmark |(size)| Mode| Cnt|Score | Error |Units > ---------------------------------|------|-----|----|------|--------|----- > StringCompare.compareLL | 64 | avgt| 5 |7.992 | ? 0.005|us/op > StringCompare.compareLL | 72 | avgt| 5 |15.029| ? 0.006|us/op > StringCompare.compareLL | 80 | avgt| 5 |14.655| ? 0.011|us/op > StringCompare.compareLL | 91 | avgt| 5 |16.363| ? 0.12 |us/op > StringCompare.compareLL | 101 | avgt| 5 |16.966| ? 0.007|us/op > StringCompare.compareLL | 121 | avgt| 5 |19.276| ? 0.006|us/op > StringCompare.compareLL | 181 | avgt| 5 |19.002| ? 0.417|us/op > StringCompare.compareLL | 256 | avgt| 5 |24.707| ? 0.041|us/op > StringCompare.compareLLWithLdp| 64 | avgt| 5 |8.001 | ? 0.121|us/op > StringCompare.compareLLWithLdp| 72 | avgt| 5 |11.573| ? 0.003|us/op > StringCompare.compareLLWithLdp| 80 | avgt| 5 |6.861 | ? 0.004|us/op > StringCompare.compareLLWithLdp| 91 | avgt| 5 |12.774| ? 0.201|us/op > StringCompare.compareLLWithLdp| 101 | avgt| 5 |8.691 | ? 0.004|us/op > StringCompare.compareLLWithLdp| 121 | avgt| 5 |11.091| ? 1.342|us/op > StringCompare.compareLLWithLdp| 181 | avgt| 5 |14.64 | ? 0.581|us/op > StringCompare.compareLLWithLdp| 256 | avgt| 5 |25.879| ? 1.775|us/op > StringCompare.compareUU | 64 | avgt| 5 |13.476| ? 0.01 |us/op > StringCompare.compareUU | 72 | avgt| 5 |15.078| ? 0.006|us/op > StringCompare.compareUU | 80 | avgt| 5 |23.512| ? 0.011|us/op > StringCompare.compareUU | 91 | avgt| 5 |24.284| ? 0.008|us/op > StringCompare.compareUU | 101 | avgt| 5 |20.707| ? 0.017|us/op > StringCompare.compareUU | 121 | avgt| 5 |29.302| ? 0.011|us/op > StringCompare.compareUU | 181 | avgt| 5 |39.31 | ? 0.016|us/op > StringCompare.compareUU | 256 | avgt| 5 |54.592| ? 0.392|us/op > StringCompare.compareUUWithLdp| 64 | avgt| 5 |16.389| ? 0.008|us/op > StringCompare.compareUUWithLdp| 72 | avgt| 5 |10.71 | ? 0.158|us/op > StringCompare.compareUUWithLdp| 80 | avgt| 5 |11.488| ? 0.024|us/op > StringCompare.compareUUWithLdp| 91 | avgt| 5 |13.412| ? 0.006|us/op > StringCompare.compareUUWithLdp| 101 | avgt| 5 |16.245| ? 0.434|us/op > StringCompare.compareUUWithLdp| 121 | avgt| 5 |16.597| ? 0.016|us/op > StringCompare.compareUUWithLdp| 181 | avgt| 5 |27.373| ? 0.017|us/op > StringCompare.compareUUWithLdp| 256 | avgt| 5 |41.74 | ? 3.5 |us/op > > From this table, we can see that in most cases, our patch is better than old one. > > Thank you for your review. Any suggestions are welcome. Wang Huang 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: - fix bugs - Merge branch 'master' of https://gitee.com/ustc-wh/jdk into JDK-8268231 - fix style and add unalign test case - refact codes - draft of refactor - 8268231: Aarch64: Use ldp in intrinsics for String.compareTo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4722/files - new: https://git.openjdk.java.net/jdk/pull/4722/files/c85cd126..60dd0516 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4722&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4722&range=03-04 Stats: 9839 lines in 397 files changed: 5783 ins; 2526 del; 1530 mod Patch: https://git.openjdk.java.net/jdk/pull/4722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4722/head:pull/4722 PR: https://git.openjdk.java.net/jdk/pull/4722 From whuang at openjdk.java.net Tue Aug 3 13:33:10 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 3 Aug 2021 13:33:10 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v4] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 03:30:46 GMT, Wang Huang wrote: >> Dear all, >> Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo. >> >> * We add a JMH test case >> * Here is the result of this test case >> >> Benchmark |(size)| Mode| Cnt|Score | Error |Units >> ---------------------------------|------|-----|----|------|--------|----- >> StringCompare.compareLL | 64 | avgt| 5 |7.992 | ? 0.005|us/op >> StringCompare.compareLL | 72 | avgt| 5 |15.029| ? 0.006|us/op >> StringCompare.compareLL | 80 | avgt| 5 |14.655| ? 0.011|us/op >> StringCompare.compareLL | 91 | avgt| 5 |16.363| ? 0.12 |us/op >> StringCompare.compareLL | 101 | avgt| 5 |16.966| ? 0.007|us/op >> StringCompare.compareLL | 121 | avgt| 5 |19.276| ? 0.006|us/op >> StringCompare.compareLL | 181 | avgt| 5 |19.002| ? 0.417|us/op >> StringCompare.compareLL | 256 | avgt| 5 |24.707| ? 0.041|us/op >> StringCompare.compareLLWithLdp| 64 | avgt| 5 |8.001 | ? 0.121|us/op >> StringCompare.compareLLWithLdp| 72 | avgt| 5 |11.573| ? 0.003|us/op >> StringCompare.compareLLWithLdp| 80 | avgt| 5 |6.861 | ? 0.004|us/op >> StringCompare.compareLLWithLdp| 91 | avgt| 5 |12.774| ? 0.201|us/op >> StringCompare.compareLLWithLdp| 101 | avgt| 5 |8.691 | ? 0.004|us/op >> StringCompare.compareLLWithLdp| 121 | avgt| 5 |11.091| ? 1.342|us/op >> StringCompare.compareLLWithLdp| 181 | avgt| 5 |14.64 | ? 0.581|us/op >> StringCompare.compareLLWithLdp| 256 | avgt| 5 |25.879| ? 1.775|us/op >> StringCompare.compareUU | 64 | avgt| 5 |13.476| ? 0.01 |us/op >> StringCompare.compareUU | 72 | avgt| 5 |15.078| ? 0.006|us/op >> StringCompare.compareUU | 80 | avgt| 5 |23.512| ? 0.011|us/op >> StringCompare.compareUU | 91 | avgt| 5 |24.284| ? 0.008|us/op >> StringCompare.compareUU | 101 | avgt| 5 |20.707| ? 0.017|us/op >> StringCompare.compareUU | 121 | avgt| 5 |29.302| ? 0.011|us/op >> StringCompare.compareUU | 181 | avgt| 5 |39.31 | ? 0.016|us/op >> StringCompare.compareUU | 256 | avgt| 5 |54.592| ? 0.392|us/op >> StringCompare.compareUUWithLdp| 64 | avgt| 5 |16.389| ? 0.008|us/op >> StringCompare.compareUUWithLdp| 72 | avgt| 5 |10.71 | ? 0.158|us/op >> StringCompare.compareUUWithLdp| 80 | avgt| 5 |11.488| ? 0.024|us/op >> StringCompare.compareUUWithLdp| 91 | avgt| 5 |13.412| ? 0.006|us/op >> StringCompare.compareUUWithLdp| 101 | avgt| 5 |16.245| ? 0.434|us/op >> StringCompare.compareUUWithLdp| 121 | avgt| 5 |16.597| ? 0.016|us/op >> StringCompare.compareUUWithLdp| 181 | avgt| 5 |27.373| ? 0.017|us/op >> StringCompare.compareUUWithLdp| 256 | avgt| 5 |41.74 | ? 3.5 |us/op >> >> From this table, we can see that in most cases, our patch is better than old one. >> >> Thank you for your review. Any suggestions are welcome. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix style and add unalign test case Thank you for your suggestion. I have pushed new commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From andy.herrick at oracle.com Tue Aug 3 14:37:02 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 3 Aug 2021 10:37:02 -0400 Subject: [External] : Re: jpackage MacOS Notarization In-Reply-To: References: <9d2ab55d-7ab7-b4a9-d49d-3f8e92e8da6a@oracle.com> <7092667d-6ac9-1e82-27e4-3bca64fd5a8b@oracle.com> Message-ID: <96386cce-031c-b12c-b92e-9b7bbcd69991@oracle.com> I was having problems notarizing anything yesterday, but fixed them today. I can notarize my own test - but get failure when trying to notarize your app as built from non-modular branch of https://github.com/danielpeintner/Java11Test/ am looking into it ... /Andy On 8/2/2021 9:57 AM, Daniel Peintner wrote: > Hi Andy, > > sorry - code looks for certificate key starting with: "Developer > ID Application: " + in order > to not have to put full user name in.? I missed that that with > null user name that causes it to look for anything starting with > "Developer ID Application: " (same thing with "Developer ID > Installer: " for .pkg signing).? And macos? looks at the > non-default keychains as well as the default ones when no keychain > is specified. > > Thanks for your feedback and yes in the simple case (with one > certificate installed) it works without any further information. > > May I ask you whether you were able to reproduce the issue? > > Is there anything I can do to help? > > Thanks, > > -- Daniel > > /Andy > > On 7/29/2021 10:00 AM, Daniel Peintner wrote: >> Hi Andy, >> >> Since I don't know your setup I did not put anything there. >> >> '--mac-sign' is enough to use the defaults in my setup. >> >> It looks for the signing keys installed on my machine that start >> with "Developer ID Application " similar to >> '--mac-signing-key-user-name', 'Developer ID Application: ' >> etc. >> >> If you want to test it you need to add your credentials which I >> do not know. >> >> Hope this clarifies things, >> >> -- Daniel >> >> >> >> On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick >> > wrote: >> >> The 'build.gradle' in this branch has >> --mac-signing-key-user-name commented out. >> >>> installerOptions += [ >>> ??????????????? '--mac-sign', >>> ??????????????? // >>> '--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name', >>> System.getenv('SIGNING_KEY_USER_NAME'), >>> ??????????????? // '--mac-signing-keychain', >>> System.getenv('SIGNING_KEYCHAIN_PATH') >>> ??????????? ] >> >> clearly this cannot work, I assume you were just trying >> things ... >> >> What is the full name of the certificate you intended to use, >> what keychain is it shown in "Keychain Access", and what are >> you normal values for your environment variables: >> 'SIGNING_KEY_USER_NAME' and 'SIGNING_KEYCHAIN_PATH' ? >> >> /Andy >> >> On 7/29/2021 4:36 AM, Daniel Peintner wrote: >>> Kevin, Andy, >>> >>> Thanks for your quick?response. >>> >>> Full support for notarization in jpackage was added in >>> JDK 17. Can you >>> try an early access build of JDK 17 [1] and see if that >>> works for you? >>> >>> >>> I did try JDK17-ea-32 also with the same result. >>> >>> Since I do understand it is difficult reproduce the problem >>> I put together a *very* simple test application which you >>> can find in the "non-modular" branch here: >>> https://github.com/danielpeintner/Java11Test/tree/non-modular >>> >>> >>> It is a gradle project. It uses Java 11 to run but in >>> build.gradle on line#83[1] one can set the jpackage?location >>> (JDK17-ea-32 in this case). >>> >>> The process is as?follows >>> * ./gradlew build >>> *?./gradlew?jpackage??? // creates the dmg/pkg in folder >>> build/jpackage >>> * afterwards Apple?notarization?process can be started >>> >>> Note: notarization of dmg or pkg lead to the same failure. >>> See [2] for the full log w.r.t. pkg. >>> >>> I hope this helps you to be able to reproduce the issue. >>> >>> Thanks for your investigations! >>> >>> -- Daniel >>> >>> [1] >>> https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle#L83 >>> >>> [2] >>> https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs%2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w%2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh%2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX%2FN6zZoyz73I%3D >>> >>> >>> >>> -- Kevin >>> >>> [1] https://jdk.java.net/17 >>> >>> >>> On 7/28/2021 8:27 AM, Daniel Peintner wrote: >>> > All, >>> > >>> > I am trying to notarize an app (built with jpackage) >>> for MacOS. >>> > >>> > jpackage at first *seems* to properly sign all >>> resources with the available >>> > --mac-sign options et cetera. >>> > >>> > Having said that, there are still remaining issues >>> > 1. The app cannot be properly installed >>> >? ? ?(without hacks like xattr -d com.apple.quarantine >>> /Applications/myAPP.app >>> > ). >>> > 2. I am also not able to properly notarize the app. >>> > >>> > According to online resources there seem to exist >>> issues in *past* about >>> > notarization but according to [1, 2] the issues are fixed. >>> > >>> > As mentioned, I still have issues :-( >>> > Am I really the only one still having problems? >>> > >>> > Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK >>> also without success) >>> > >>> > The issue seems to boil down to 2 errors (attached the >>> error log from Apple >>> > notarization process). >>> > * app Folder >>> > * libjli.dylib >>> > >>> > I thought I better ask first on the mailing list >>> before creating an actual >>> > bug report. >>> > >>> > Note1: I used to use the *old* javapackager that >>> worked with the same >>> > signature/credentials. >>> > Note2: running jpackage without --mac-sign options >>> causes many more errors >>> > in notarization (Hence, jpackage signs most resources >>> but fails with some) >>> > >>> > Any help / hint appreciated. >>> > >>> > Thanks, >>> > >>> > -- Daniel >>> > >>> > [1] https://bugs.openjdk.java.net/browse/JDK-8257488 >>> >>> > [2] https://bugs.openjdk.java.net/browse/JDK-8251892 >>> >>> > >>> > >>> > >>> > ## APPLE LOG ## >>> > >>> > { >>> >? ? "logFormatVersion": 1, >>> >? ? "jobId": "...", >>> >? ? "status": "Invalid", >>> >? ? "statusSummary": "Archive contains critical >>> validation errors", >>> >? ? "statusCode": 4000, >>> >? ? "archiveFilename": "myAPP-21.07.28.dmg", >>> >? ? "uploadDate": "2021-07-28T14:31:24Z", >>> >? ? "sha256": "...", >>> >? ? "ticketContents": null, >>> >? ? "issues": [ >>> >? ? ? { >>> >? ? ? ? "severity": "error", >>> >? ? ? ? "code": null, >>> >? ? ? ? "path": >>> "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP", >>> >? ? ? ? "message": "The signature of the binary is >>> invalid.", >>> >? ? ? ? "docUrl": null, >>> >? ? ? ? "architecture": "x86_64" >>> >? ? ? }, >>> >? ? ? { >>> >? ? ? ? "severity": "error", >>> >? ? ? ? "code": null, >>> >? ? ? ? "path": >>> "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib", >>> >? ? ? ? "message": "The signature of the binary is >>> invalid.", >>> >? ? ? ? "docUrl": null, >>> >? ? ? ? "architecture": "x86_64" >>> >? ? ? } >>> >? ? ] >>> > } >>> From volker.simonis at gmail.com Tue Aug 3 14:36:43 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 3 Aug 2021 16:36:43 +0200 Subject: Quick question on JDK-8198997 and normalization of user.dir Message-ID: Hi, I have a quick question on JDK-8198997 [1] (a follow-up of JDK-8194154 [2]) which introduced normalization for the cached "user.dir" property in order to avoid "inefficient, repeated normalization". However, from what I can see, WinNTFileSystem.getUserPath(), the only place where the cached and normalized "userDir" is used, still calls normalize() on each invocation: class WinNTFileSystem extends FileSystem { ... private final String userDir; ... public WinNTFileSystem() { ... userDir = normalize(props.getProperty("user.dir")); } ... private String getUserPath() { ... return normalize(userDir); } Is this just an oversight (in which case I'll fix it) or am I missing something? Thank you and best regards, Volker [1] https://bugs.openjdk.java.net/browse/JDK-8198997 [2] https://bugs.openjdk.java.net/browse/JDK-8194154 From Alan.Bateman at oracle.com Tue Aug 3 14:40:47 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Aug 2021 15:40:47 +0100 Subject: Quick question on JDK-8198997 and normalization of user.dir In-Reply-To: References: Message-ID: On 03/08/2021 15:36, Volker Simonis wrote: > Hi, > > I have a quick question on JDK-8198997 [1] (a follow-up of JDK-8194154 > [2]) which introduced normalization for the cached "user.dir" property > in order to avoid "inefficient, repeated normalization". > > However, from what I can see, WinNTFileSystem.getUserPath(), the only > place where the cached and normalized "userDir" is used, still calls > normalize() on each invocation: > > class WinNTFileSystem extends FileSystem { > ... > private final String userDir; > ... > public WinNTFileSystem() { > ... > userDir = normalize(props.getProperty("user.dir")); > } > ... > private String getUserPath() { > ... > return normalize(userDir); > } > > Is this just an oversight (in which case I'll fix it) or am I missing something? > It looks like a left over, it's harmless, but it should be okay to change to just return userDir. -Alan From volker.simonis at gmail.com Tue Aug 3 14:59:07 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 3 Aug 2021 16:59:07 +0200 Subject: Quick question on JDK-8198997 and normalization of user.dir In-Reply-To: References: Message-ID: Thanks for the quick confirmation! On Tue, Aug 3, 2021 at 4:41 PM Alan Bateman wrote: > > On 03/08/2021 15:36, Volker Simonis wrote: > > Hi, > > > > I have a quick question on JDK-8198997 [1] (a follow-up of JDK-8194154 > > [2]) which introduced normalization for the cached "user.dir" property > > in order to avoid "inefficient, repeated normalization". > > > > However, from what I can see, WinNTFileSystem.getUserPath(), the only > > place where the cached and normalized "userDir" is used, still calls > > normalize() on each invocation: > > > > class WinNTFileSystem extends FileSystem { > > ... > > private final String userDir; > > ... > > public WinNTFileSystem() { > > ... > > userDir = normalize(props.getProperty("user.dir")); > > } > > ... > > private String getUserPath() { > > ... > > return normalize(userDir); > > } > > > > Is this just an oversight (in which case I'll fix it) or am I missing something? > > > It looks like a left over, it's harmless, but it should be okay to > change to just return userDir. > > -Alan From bpb at openjdk.java.net Tue Aug 3 16:16:29 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 3 Aug 2021 16:16:29 GMT Subject: RFR: 8271225: Add floorDivExact() method to java.lang.[Strict]Math In-Reply-To: <83UNXL7d91UFeJPj1EyRR7JEc_nY0GUrLSZxFR5GECo=.4bc03eb1-4f39-44fd-b96a-470360034054@github.com> References: <83UNXL7d91UFeJPj1EyRR7JEc_nY0GUrLSZxFR5GECo=.4bc03eb1-4f39-44fd-b96a-470360034054@github.com> Message-ID: On Tue, 3 Aug 2021 08:42:18 GMT, Raffaello Giulietti wrote: >> The `floorDivExact()` methods are identical to their `floorDiv()` counterparts aside from that they throw an `ArithmeticException` when the dividend is `MIN_VALUE` and the divisor is `-1`. These methods behave with respect to the methods `floorDiv()` as the methods `divideExact()` behave with respect to the division operator `/`. > > Hello @bplb, > > the doc of floorDivExact() is not, well..., exact. > > For example, >> The floor rounding mode gives different results from truncation > when the exact result is negative. > > The truth is that the results are different when the exact quotient _is not an integer and is negative_. > The description following this sentence is imprecise as well. > > The doc seems to have been copied and adapted from the doc of floorDiv(), which is imprecise in the first place. > You might want to take a look at [PR 4963](https://github.com/openjdk/jdk/pull/4963) which addresses this and wait until that one is thoroughly discussed for mathematical accuracy and correct wording. > > > Greetings > Raffaello @rgiulietti Yes, that doc was copied. I tend to agree that it would be better to get 4963 right and hold off on this PR until then. ------------- PR: https://git.openjdk.java.net/jdk/pull/4941 From andy.herrick at oracle.com Tue Aug 3 18:19:40 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 3 Aug 2021 14:19:40 -0400 Subject: [External] : Re: jpackage MacOS Notarization In-Reply-To: <96386cce-031c-b12c-b92e-9b7bbcd69991@oracle.com> References: <9d2ab55d-7ab7-b4a9-d49d-3f8e92e8da6a@oracle.com> <7092667d-6ac9-1e82-27e4-3bca64fd5a8b@oracle.com> <96386cce-031c-b12c-b92e-9b7bbcd69991@oracle.com> Message-ID: OK - took me a while to see what you are doing. The problem is you are signing the pkg but building it from an unsigned app-image. If you are building in two phases (app-image, then installer package) you need the --mac-sign option on both phases. /Andy On 8/3/2021 10:37 AM, Andy Herrick wrote: > > I was having problems notarizing anything yesterday, but fixed them today. > > I can notarize my own test - but get failure when trying to notarize > your app as built from non-modular branch of > https://github.com/danielpeintner/Java11Test/ > > am looking into it ... > > /Andy > > > On 8/2/2021 9:57 AM, Daniel Peintner wrote: >> Hi Andy, >> >> sorry - code looks for certificate key starting with: "Developer >> ID Application: " + in order >> to not have to put full user name in.? I missed that that with >> null user name that causes it to look for anything starting with >> "Developer ID Application: " (same thing with "Developer ID >> Installer: " for .pkg signing).? And macos? looks at the >> non-default keychains as well as the default ones when no >> keychain is specified. >> >> Thanks for your feedback and yes in the simple case (with one >> certificate installed) it works without any further information. >> >> May I ask you whether you were able to reproduce the issue? >> >> Is there anything I can do to help? >> >> Thanks, >> >> -- Daniel >> >> /Andy >> >> On 7/29/2021 10:00 AM, Daniel Peintner wrote: >>> Hi Andy, >>> >>> Since I don't know your setup I did not put anything there. >>> >>> '--mac-sign' is enough to use the defaults in my setup. >>> >>> It looks for the signing keys installed on my machine that start >>> with "Developer ID Application " similar to >>> '--mac-signing-key-user-name', 'Developer ID Application: ' >>> etc. >>> >>> If you want to test it you need to add your credentials which I >>> do not know. >>> >>> Hope this clarifies things, >>> >>> -- Daniel >>> >>> >>> >>> On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick >>> > wrote: >>> >>> The 'build.gradle' in this branch has >>> --mac-signing-key-user-name commented out. >>> >>>> installerOptions += [ >>>> ??????????????? '--mac-sign', >>>> ??????????????? // >>>> '--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name', >>>> System.getenv('SIGNING_KEY_USER_NAME'), >>>> ??????????????? // '--mac-signing-keychain', >>>> System.getenv('SIGNING_KEYCHAIN_PATH') >>>> ??????????? ] >>> >>> clearly this cannot work, I assume you were just trying >>> things ... >>> >>> What is the full name of the certificate you intended to >>> use, what keychain is it shown in "Keychain Access", and >>> what are you normal values for your environment variables: >>> 'SIGNING_KEY_USER_NAME' and 'SIGNING_KEYCHAIN_PATH' ? >>> >>> /Andy >>> >>> On 7/29/2021 4:36 AM, Daniel Peintner wrote: >>>> Kevin, Andy, >>>> >>>> Thanks for your quick?response. >>>> >>>> Full support for notarization in jpackage was added in >>>> JDK 17. Can you >>>> try an early access build of JDK 17 [1] and see if that >>>> works for you? >>>> >>>> >>>> I did try JDK17-ea-32 also with the same result. >>>> >>>> Since I do understand it is difficult reproduce the problem >>>> I put together a *very* simple test application which you >>>> can find in the "non-modular" branch here: >>>> https://github.com/danielpeintner/Java11Test/tree/non-modular >>>> >>>> >>>> It is a gradle project. It uses Java 11 to run but in >>>> build.gradle on line#83[1] one can set the >>>> jpackage?location (JDK17-ea-32 in this case). >>>> >>>> The process is as?follows >>>> * ./gradlew build >>>> *?./gradlew?jpackage??? // creates the dmg/pkg in folder >>>> build/jpackage >>>> * afterwards Apple?notarization?process can be started >>>> >>>> Note: notarization of dmg or pkg lead to the same failure. >>>> See [2] for the full log w.r.t. pkg. >>>> >>>> I hope this helps you to be able to reproduce the issue. >>>> >>>> Thanks for your investigations! >>>> >>>> -- Daniel >>>> >>>> [1] >>>> https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle#L83 >>>> >>>> [2] >>>> https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs%2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w%2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh%2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX%2FN6zZoyz73I%3D >>>> >>>> >>>> >>>> -- Kevin >>>> >>>> [1] https://jdk.java.net/17 >>>> >>>> >>>> On 7/28/2021 8:27 AM, Daniel Peintner wrote: >>>> > All, >>>> > >>>> > I am trying to notarize an app (built with jpackage) >>>> for MacOS. >>>> > >>>> > jpackage at first *seems* to properly sign all >>>> resources with the available >>>> > --mac-sign options et cetera. >>>> > >>>> > Having said that, there are still remaining issues >>>> > 1. The app cannot be properly installed >>>> >? ? ?(without hacks like xattr -d com.apple.quarantine >>>> /Applications/myAPP.app >>>> > ). >>>> > 2. I am also not able to properly notarize the app. >>>> > >>>> > According to online resources there seem to exist >>>> issues in *past* about >>>> > notarization but according to [1, 2] the issues are >>>> fixed. >>>> > >>>> > As mentioned, I still have issues :-( >>>> > Am I really the only one still having problems? >>>> > >>>> > Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK >>>> also without success) >>>> > >>>> > The issue seems to boil down to 2 errors (attached >>>> the error log from Apple >>>> > notarization process). >>>> > * app Folder >>>> > * libjli.dylib >>>> > >>>> > I thought I better ask first on the mailing list >>>> before creating an actual >>>> > bug report. >>>> > >>>> > Note1: I used to use the *old* javapackager that >>>> worked with the same >>>> > signature/credentials. >>>> > Note2: running jpackage without --mac-sign options >>>> causes many more errors >>>> > in notarization (Hence, jpackage signs most resources >>>> but fails with some) >>>> > >>>> > Any help / hint appreciated. >>>> > >>>> > Thanks, >>>> > >>>> > -- Daniel >>>> > >>>> > [1] https://bugs.openjdk.java.net/browse/JDK-8257488 >>>> >>>> > [2] https://bugs.openjdk.java.net/browse/JDK-8251892 >>>> >>>> > >>>> > >>>> > >>>> > ## APPLE LOG ## >>>> > >>>> > { >>>> >? ? "logFormatVersion": 1, >>>> >? ? "jobId": "...", >>>> >? ? "status": "Invalid", >>>> >? ? "statusSummary": "Archive contains critical >>>> validation errors", >>>> >? ? "statusCode": 4000, >>>> >? ? "archiveFilename": "myAPP-21.07.28.dmg", >>>> >? ? "uploadDate": "2021-07-28T14:31:24Z", >>>> >? ? "sha256": "...", >>>> >? ? "ticketContents": null, >>>> >? ? "issues": [ >>>> >? ? ? { >>>> >? ? ? ? "severity": "error", >>>> >? ? ? ? "code": null, >>>> >? ? ? ? "path": >>>> "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP", >>>> >? ? ? ? "message": "The signature of the binary is >>>> invalid.", >>>> >? ? ? ? "docUrl": null, >>>> >? ? ? ? "architecture": "x86_64" >>>> >? ? ? }, >>>> >? ? ? { >>>> >? ? ? ? "severity": "error", >>>> >? ? ? ? "code": null, >>>> >? ? ? ? "path": >>>> "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib", >>>> >? ? ? ? "message": "The signature of the binary is >>>> invalid.", >>>> >? ? ? ? "docUrl": null, >>>> >? ? ? ? "architecture": "x86_64" >>>> >? ? ? } >>>> >? ? ] >>>> > } >>>> From herrick at openjdk.java.net Tue Aug 3 18:54:34 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 3 Aug 2021 18:54:34 GMT Subject: Integrated: JDK-8271344: Windows product version issue In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 13:45:17 GMT, Andy Herrick wrote: > JDK-8271344: Windows product version issue This pull request has now been integrated. Changeset: 0199b03e Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/0199b03eb3bd9ffe79b5193ff1792144b5c488f1 Stats: 21 lines in 5 files changed: 5 ins; 2 del; 14 mod 8271344: Windows product version issue Reviewed-by: asemenyuk, almatvee ------------- PR: https://git.openjdk.java.net/jdk/pull/4958 From weijun at openjdk.java.net Tue Aug 3 19:14:40 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 3 Aug 2021 19:14:40 GMT Subject: RFR: 8271616: oddPart in MutableBigInteger::mutableModInverse contains info on final result Message-ID: oddPart contains a lot of info on the modInverse output, sometimes it's even the same. Clearing it in case the result is sensitive. No new regression test since it's difficult to access a temporary local variable in an internal class. Existing tier1-2 tests passed. ------------- Commit messages: - 8271616: oddPart in MutableBigInteger::mutableModInverse contains info on final result Changes: https://git.openjdk.java.net/jdk/pull/4973/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4973&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271616 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4973.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4973/head:pull/4973 PR: https://git.openjdk.java.net/jdk/pull/4973 From bpb at openjdk.java.net Tue Aug 3 20:26:34 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 3 Aug 2021 20:26:34 GMT Subject: RFR: 8271616: oddPart in MutableBigInteger::mutableModInverse contains info on final result In-Reply-To: References: Message-ID: On Tue, 3 Aug 2021 19:05:55 GMT, Weijun Wang wrote: > `oddPart` contains a lot of info on the `modInverse` output, sometimes it's even the same. Clearing it in case the result is sensitive. > > No new regression test since it's difficult to access a temporary local variable in an internal class. Existing tier1-2 tests passed. Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4973 From darcy at openjdk.java.net Tue Aug 3 22:04:30 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 3 Aug 2021 22:04:30 GMT Subject: RFR: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 22:34:58 GMT, Raffaello Giulietti wrote: > Hello, > > please review the changes in documentation of floorDiv() and floorMod() in all their variants. Some are clarifications, some are corrections. > > Here's an example of a confusing formulation in the current doc >> "the / operator returns the integer closest to zero" > > Literally, the integer closest to zero is zero! > > > The doc of floorMod(int, int) also states: >> "If the signs of arguments are unknown and a positive modulus >> is needed it can be computed as (floorMod(x, y) + abs(y)) % abs(y)." > > That's a questionable advice, as the sum in parentheses can lead to irrecoverable overflow (beside requiring two divisions instead of one). > E.g., setting x = Integer.MAX_VALUE - 1, y = Integer.MAX_VALUE leads to the quite incorrect result -3, which is not even positive! > > > Greetings > Raffaello Looks fine; please make the same edits to StrictMath for a final code review and CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4963 From darcy at openjdk.java.net Tue Aug 3 22:18:34 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 3 Aug 2021 22:18:34 GMT Subject: RFR: 8271616: oddPart in MutableBigInteger::mutableModInverse contains info on final result In-Reply-To: References: Message-ID: On Tue, 3 Aug 2021 19:05:55 GMT, Weijun Wang wrote: > `oddPart` contains a lot of info on the `modInverse` output, sometimes it's even the same. Clearing it in case the result is sensitive. > > No new regression test since it's difficult to access a temporary local variable in an internal class. Existing tier1-2 tests passed. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4973 From github.com+70726043+rgiulietti at openjdk.java.net Tue Aug 3 22:25:47 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Tue, 3 Aug 2021 22:25:47 GMT Subject: RFR: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places [v2] In-Reply-To: References: Message-ID: > Hello, > > please review the changes in documentation of floorDiv() and floorMod() in all their variants. Some are clarifications, some are corrections. > > Here's an example of a confusing formulation in the current doc >> "the / operator returns the integer closest to zero" > > Literally, the integer closest to zero is zero! > > > The doc of floorMod(int, int) also states: >> "If the signs of arguments are unknown and a positive modulus >> is needed it can be computed as (floorMod(x, y) + abs(y)) % abs(y)." > > That's a questionable advice, as the sum in parentheses can lead to irrecoverable overflow (beside requiring two divisions instead of one). > E.g., setting x = Integer.MAX_VALUE - 1, y = Integer.MAX_VALUE leads to the quite incorrect result -3, which is not even positive! > > > Greetings > Raffaello Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4963/files - new: https://git.openjdk.java.net/jdk/pull/4963/files/423af129..cab4c54c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4963&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4963&range=00-01 Stats: 21 lines in 2 files changed: 2 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/4963.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4963/head:pull/4963 PR: https://git.openjdk.java.net/jdk/pull/4963 From github.com+70726043+rgiulietti at openjdk.java.net Tue Aug 3 22:40:50 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Tue, 3 Aug 2021 22:40:50 GMT Subject: RFR: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places [v3] In-Reply-To: References: Message-ID: > Hello, > > please review the changes in documentation of floorDiv() and floorMod() in all their variants. Some are clarifications, some are corrections. > > Here's an example of a confusing formulation in the current doc >> "the / operator returns the integer closest to zero" > > Literally, the integer closest to zero is zero! > > > The doc of floorMod(int, int) also states: >> "If the signs of arguments are unknown and a positive modulus >> is needed it can be computed as (floorMod(x, y) + abs(y)) % abs(y)." > > That's a questionable advice, as the sum in parentheses can lead to irrecoverable overflow (beside requiring two divisions instead of one). > E.g., setting x = Integer.MAX_VALUE - 1, y = Integer.MAX_VALUE leads to the quite incorrect result -3, which is not even positive! > > > Greetings > Raffaello Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4963/files - new: https://git.openjdk.java.net/jdk/pull/4963/files/cab4c54c..dc81446f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4963&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4963&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4963.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4963/head:pull/4963 PR: https://git.openjdk.java.net/jdk/pull/4963 From bpb at openjdk.java.net Tue Aug 3 22:40:53 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 3 Aug 2021 22:40:53 GMT Subject: RFR: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places [v3] In-Reply-To: References: Message-ID: On Tue, 3 Aug 2021 22:37:12 GMT, Raffaello Giulietti wrote: >> Hello, >> >> please review the changes in documentation of floorDiv() and floorMod() in all their variants. Some are clarifications, some are corrections. >> >> Here's an example of a confusing formulation in the current doc >>> "the / operator returns the integer closest to zero" >> >> Literally, the integer closest to zero is zero! >> >> >> The doc of floorMod(int, int) also states: >>> "If the signs of arguments are unknown and a positive modulus >>> is needed it can be computed as (floorMod(x, y) + abs(y)) % abs(y)." >> >> That's a questionable advice, as the sum in parentheses can lead to irrecoverable overflow (beside requiring two divisions instead of one). >> E.g., setting x = Integer.MAX_VALUE - 1, y = Integer.MAX_VALUE leads to the quite incorrect result -3, which is not even positive! >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places src/java.base/share/classes/java/lang/Math.java line 1250: > 1248: * Returns the largest (closest to positive infinity) > 1249: * {@code int} value that is less than or equal to the algebraic quotient. > 1250: * There is one special case: if the dividend is the I think the "the" at the end of line 1250 can be deleted. src/java.base/share/classes/java/lang/Math.java line 1268: > 1266: * while the {@code /} operator returns the smallest integer greater > 1267: * than or equal to the quotient. > 1268: * There's a difference if and only if the quotient is not an integer.
Maybe "There's a difference" -> "They differ" ? src/java.base/share/classes/java/lang/Math.java line 1295: > 1293: * Returns the largest (closest to positive infinity) > 1294: * {@code long} value that is less than or equal to the algebraic quotient. > 1295: * There is one special case: if the dividend is the Again, "the" can go away. src/java.base/share/classes/java/lang/Math.java line 1324: > 1322: * Returns the largest (closest to positive infinity) > 1323: * {@code long} value that is less than or equal to the algebraic quotient. > 1324: * There is one special case: if the dividend is the Delete "the" again. src/java.base/share/classes/java/lang/StrictMath.java line 1054: > 1052: * Returns the largest (closest to positive infinity) > 1053: * {@code int} value that is less than or equal to the algebraic quotient. > 1054: * There is one special case: if the dividend is the "the" src/java.base/share/classes/java/lang/StrictMath.java line 1078: > 1076: * Returns the largest (closest to positive infinity) > 1077: * {@code long} value that is less than or equal to the algebraic quotient. > 1078: * There is one special case: if the dividend is the "the" src/java.base/share/classes/java/lang/StrictMath.java line 1102: > 1100: * Returns the largest (closest to positive infinity) > 1101: * {@code long} value that is less than or equal to the algebraic quotient. > 1102: * There is one special case: if the dividend is the "the" ------------- PR: https://git.openjdk.java.net/jdk/pull/4963 From github.com+70726043+rgiulietti at openjdk.java.net Tue Aug 3 22:44:57 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Tue, 3 Aug 2021 22:44:57 GMT Subject: RFR: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places [v4] In-Reply-To: References: Message-ID: > Hello, > > please review the changes in documentation of floorDiv() and floorMod() in all their variants. Some are clarifications, some are corrections. > > Here's an example of a confusing formulation in the current doc >> "the / operator returns the integer closest to zero" > > Literally, the integer closest to zero is zero! > > > The doc of floorMod(int, int) also states: >> "If the signs of arguments are unknown and a positive modulus >> is needed it can be computed as (floorMod(x, y) + abs(y)) % abs(y)." > > That's a questionable advice, as the sum in parentheses can lead to irrecoverable overflow (beside requiring two divisions instead of one). > E.g., setting x = Integer.MAX_VALUE - 1, y = Integer.MAX_VALUE leads to the quite incorrect result -3, which is not even positive! > > > Greetings > Raffaello Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4963/files - new: https://git.openjdk.java.net/jdk/pull/4963/files/dc81446f..21e4f370 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4963&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4963&range=02-03 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4963.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4963/head:pull/4963 PR: https://git.openjdk.java.net/jdk/pull/4963 From darcy at openjdk.java.net Tue Aug 3 22:44:58 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 3 Aug 2021 22:44:58 GMT Subject: RFR: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places [v4] In-Reply-To: References: Message-ID: On Tue, 3 Aug 2021 22:41:52 GMT, Raffaello Giulietti wrote: >> Hello, >> >> please review the changes in documentation of floorDiv() and floorMod() in all their variants. Some are clarifications, some are corrections. >> >> Here's an example of a confusing formulation in the current doc >>> "the / operator returns the integer closest to zero" >> >> Literally, the integer closest to zero is zero! >> >> >> The doc of floorMod(int, int) also states: >>> "If the signs of arguments are unknown and a positive modulus >>> is needed it can be computed as (floorMod(x, y) + abs(y)) % abs(y)." >> >> That's a questionable advice, as the sum in parentheses can lead to irrecoverable overflow (beside requiring two divisions instead of one). >> E.g., setting x = Integer.MAX_VALUE - 1, y = Integer.MAX_VALUE leads to the quite incorrect result -3, which is not even positive! >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4963 From valeriep at openjdk.java.net Tue Aug 3 23:52:29 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 3 Aug 2021 23:52:29 GMT Subject: RFR: 8271616: oddPart in MutableBigInteger::mutableModInverse contains info on final result In-Reply-To: References: Message-ID: <4sCd6iG8E_kVw728QhGY_dmT7oQG8Cnre9CRGsT5zFg=.f3cc66e8-3160-4f0e-a7cb-ae3db43c980a@github.com> On Tue, 3 Aug 2021 19:05:55 GMT, Weijun Wang wrote: > `oddPart` contains a lot of info on the `modInverse` output, sometimes it's even the same. Clearing it in case the result is sensitive. > > No new regression test since it's difficult to access a temporary local variable in an internal class. Existing tier1-2 tests passed. Marked as reviewed by valeriep (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4973 From weijun at openjdk.java.net Wed Aug 4 00:06:31 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 4 Aug 2021 00:06:31 GMT Subject: Integrated: 8271616: oddPart in MutableBigInteger::mutableModInverse contains info on final result In-Reply-To: References: Message-ID: <70hn8wIe1_7Q8DlfOTPQ4LfRNhcX6hKYlHxUhpM9-ZU=.73b1ec5f-55f8-48cc-b158-9dbd3407e7d2@github.com> On Tue, 3 Aug 2021 19:05:55 GMT, Weijun Wang wrote: > `oddPart` contains a lot of info on the `modInverse` output, sometimes it's even the same. Clearing it in case the result is sensitive. > > No new regression test since it's difficult to access a temporary local variable in an internal class. Existing tier1-2 tests passed. This pull request has now been integrated. Changeset: a8408708 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/a8408708b065a877278acc6b007ad6a9baaf2561 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8271616: oddPart in MutableBigInteger::mutableModInverse contains info on final result Reviewed-by: bpb, darcy, valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/4973 From bpb at openjdk.java.net Wed Aug 4 01:00:30 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 4 Aug 2021 01:00:30 GMT Subject: RFR: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places [v4] In-Reply-To: References: Message-ID: On Tue, 3 Aug 2021 22:44:57 GMT, Raffaello Giulietti wrote: >> Hello, >> >> please review the changes in documentation of floorDiv() and floorMod() in all their variants. Some are clarifications, some are corrections. >> >> Here's an example of a confusing formulation in the current doc >>> "the / operator returns the integer closest to zero" >> >> Literally, the integer closest to zero is zero! >> >> >> The doc of floorMod(int, int) also states: >>> "If the signs of arguments are unknown and a positive modulus >>> is needed it can be computed as (floorMod(x, y) + abs(y)) % abs(y)." >> >> That's a questionable advice, as the sum in parentheses can lead to irrecoverable overflow (beside requiring two divisions instead of one). >> E.g., setting x = Integer.MAX_VALUE - 1, y = Integer.MAX_VALUE leads to the quite incorrect result -3, which is not even positive! >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4963 From ngasson at openjdk.java.net Wed Aug 4 03:32:35 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 4 Aug 2021 03:32:35 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v5] In-Reply-To: References: Message-ID: On Tue, 3 Aug 2021 13:33:07 GMT, Wang Huang wrote: >> Dear all, >> Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo. >> >> * We add a JMH test case >> * Here is the result of this test case >> >> Benchmark |(size)| Mode| Cnt|Score | Error |Units >> ---------------------------------|------|-----|----|------|--------|----- >> StringCompare.compareLL | 64 | avgt| 5 |7.992 | ? 0.005|us/op >> StringCompare.compareLL | 72 | avgt| 5 |15.029| ? 0.006|us/op >> StringCompare.compareLL | 80 | avgt| 5 |14.655| ? 0.011|us/op >> StringCompare.compareLL | 91 | avgt| 5 |16.363| ? 0.12 |us/op >> StringCompare.compareLL | 101 | avgt| 5 |16.966| ? 0.007|us/op >> StringCompare.compareLL | 121 | avgt| 5 |19.276| ? 0.006|us/op >> StringCompare.compareLL | 181 | avgt| 5 |19.002| ? 0.417|us/op >> StringCompare.compareLL | 256 | avgt| 5 |24.707| ? 0.041|us/op >> StringCompare.compareLLWithLdp| 64 | avgt| 5 |8.001 | ? 0.121|us/op >> StringCompare.compareLLWithLdp| 72 | avgt| 5 |11.573| ? 0.003|us/op >> StringCompare.compareLLWithLdp| 80 | avgt| 5 |6.861 | ? 0.004|us/op >> StringCompare.compareLLWithLdp| 91 | avgt| 5 |12.774| ? 0.201|us/op >> StringCompare.compareLLWithLdp| 101 | avgt| 5 |8.691 | ? 0.004|us/op >> StringCompare.compareLLWithLdp| 121 | avgt| 5 |11.091| ? 1.342|us/op >> StringCompare.compareLLWithLdp| 181 | avgt| 5 |14.64 | ? 0.581|us/op >> StringCompare.compareLLWithLdp| 256 | avgt| 5 |25.879| ? 1.775|us/op >> StringCompare.compareUU | 64 | avgt| 5 |13.476| ? 0.01 |us/op >> StringCompare.compareUU | 72 | avgt| 5 |15.078| ? 0.006|us/op >> StringCompare.compareUU | 80 | avgt| 5 |23.512| ? 0.011|us/op >> StringCompare.compareUU | 91 | avgt| 5 |24.284| ? 0.008|us/op >> StringCompare.compareUU | 101 | avgt| 5 |20.707| ? 0.017|us/op >> StringCompare.compareUU | 121 | avgt| 5 |29.302| ? 0.011|us/op >> StringCompare.compareUU | 181 | avgt| 5 |39.31 | ? 0.016|us/op >> StringCompare.compareUU | 256 | avgt| 5 |54.592| ? 0.392|us/op >> StringCompare.compareUUWithLdp| 64 | avgt| 5 |16.389| ? 0.008|us/op >> StringCompare.compareUUWithLdp| 72 | avgt| 5 |10.71 | ? 0.158|us/op >> StringCompare.compareUUWithLdp| 80 | avgt| 5 |11.488| ? 0.024|us/op >> StringCompare.compareUUWithLdp| 91 | avgt| 5 |13.412| ? 0.006|us/op >> StringCompare.compareUUWithLdp| 101 | avgt| 5 |16.245| ? 0.434|us/op >> StringCompare.compareUUWithLdp| 121 | avgt| 5 |16.597| ? 0.016|us/op >> StringCompare.compareUUWithLdp| 181 | avgt| 5 |27.373| ? 0.017|us/op >> StringCompare.compareUUWithLdp| 256 | avgt| 5 |41.74 | ? 3.5 |us/op >> >> From this table, we can see that in most cases, our patch is better than old one. >> >> Thank you for your review. Any suggestions are welcome. > > Wang Huang 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: > > - fix bugs > - Merge branch 'master' of https://gitee.com/ustc-wh/jdk into JDK-8268231 > - fix style and add unalign test case > - refact codes > - draft of refactor > - 8268231: Aarch64: Use ldp in intrinsics for String.compareTo Please provide the updated benchmark results for this version. Are you able to test it on several different machines? src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4892: > 4890: __ cmp(tmp1, tmp2); > 4891: __ ccmp(tmp1h, tmp2h, 0, Assembler::EQ); > 4892: __ br(__ NE, DIFF); The line above uses `Assembler::EQ` for the condition code but this line uses `__ NE`. Better to be consistent and use `Assembler::` everywhere. ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From stuefe at openjdk.java.net Wed Aug 4 03:39:31 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 4 Aug 2021 03:39:31 GMT Subject: RFR: JDK-8256844: Make NMT late-initializable [v2] In-Reply-To: References: Message-ID: On Sun, 1 Aug 2021 08:17:08 GMT, Thomas Stuefe wrote: >> Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing, cleans them up and makes them sideeffect-free. >> >> --------- >> >> NMT continues to be an extremely useful tool for SAP to tackle memory problems in the JVM. >> >> However, NMT is of limited use due to the following restrictions: >> >> - NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible. >> - Worse, if that custom launcher links the libjvm *statically* there is just no way to activate NMT at all. This is the reason NMT cannot be used in the `gtestlauncher`. >> - Related to that is that we cannot pass NMT options via `JAVA_TOOL_OPTIONS` and `-XX:Flags=`. >> - The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff. >> >> The reason for all this is that NMT initialization happens very early, on the first call to `os::malloc()`. And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments. >> >> The current solution is to pass NMT arguments via a specially prepared environment variable: `NMT_LEVEL_=`. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher. >> >> All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. `java` itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand. >> >> And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., `JAVA_TOOL_OPTIONS`. >> >> ------ >> >> This patch fixes these shortcomings by making NMT late-initializable: it can now be initialized after normal VM argument parsing, like all other parts of the VM. This greatly simplifies NMT initialization and makes it work automagically for every third party launcher, as well as within our gtests. >> >> The glaring problem with late-initializing NMT is the NMT malloc headers. If we rule out just always having them (unacceptable in terms of memory overhead), there is no safe way to determine, in os::free(), if an allocation came from before or after NMT initialization ran, and therefore what to do with its malloc headers. For a more extensive explanation, please see the comment block `nmtPreInit.hpp` and the discussion with @kimbarrett and @zhengyu123 in the JBS comment section. >> >> The heart of this patch is a new way to track early, pre-NMT-init allocations. These are tracked via a lookup table. This was a suggestion by Kim and it worked out well. >> >> Changes in detail: >> >> - pre-NMT-init handling: >> - the new files `nmtPreInit.hpp/cpp` take case of NMT pre-init handling. They contain a small global lookup table managing C-heap blocks allocated in the pre-NMT-init phase. >> - `os::malloc()/os::realloc()/os::free()` defer to this code before doing anything else. >> - Please see the extensive comment block at the start of `nmtPreinit.hpp` explaining the details. >> >> - Changes to NMT: >> - Before, NMT initialization was spread over two phases, `initialize()` and `late_initialize()`. Those were merged into one and simplified - there is only one initialization now which happens after argument parsing. >> - Minor changes were needed for the `NMT_TrackingLevel` enum - to simplify code, I changed NMT_unknown to be numerically 0. A new comment block in `nmtCommon.hpp` now clearly specifies what's what, including allowed level state transitions. >> - New utility functions to translate tracking level from/to strings added to `NMTUtil` >> - NMT has never been able to handle virtual memory allocations before initialization, which is fine since os::reserve_memory() is not called before VM parses arguments. We now assert that. >> - All code outside the VM handling NMT initialization (eg. libjli) has been removed, as has the code testing it. >> >> - Gtests: >> - Some existing gtests had to be modified: before, they all changed global state (turning NMT on/off) before testing. This is not allowed anymore, to keep NMT simple. Also, this pattern disturbed other tests. >> - The new way to test is to passively check whether NMT has been switched on or off, and do tests accordingly: if on, full tests, if off, test just what makes sense in off-state. That does not disturb neighboring tests, gives us actually better coverage all around. >> - It is now possible to start the gtestlauncher with NMT on! Which additionally gives us good coverage. >> - To actually do gtests with NMT - since it's disabled by default - we now run NMT-enabled gtests as part of the hotspot jtreg NMT wrapper. This pattern we have done for a number of other facitilites, see all the tests in test/hotspot/jtreg/gtest.. . It works very well. >> - Finally, a new gtest has been written to test the NMT preinit lookup map in isolation, placed in `gtest/nmt/test_nmtpreinitmap.cpp`. >> >> - jtreg: >> - A new test has been added, `runtime/NMT/NMTInitializationTest.java`, testing NMT initialization in the face of many many VM arguments. >> >> ------------- >> >> Tests: >> - ran manually all new tests on 64-bit and 32-bit Linux >> - GHAs >> - The patch has been active in SAPs test systems for a while now. > > Thomas Stuefe has updated the pull request incrementally with six additional commits since the last revision: > > - feedback zhengyu > - feeback Coleen/Kim (constness fix) > - Feedback David > - Add test to test for non-java launcher support of NMT > - move all test code to gtest > - actually free blocks freed in pre-init phase Nightlies at SAP showed no problems for several runs now. The failed GHA test (StringDeduplication) seems to have nothing to do with my patch. @zhengyu123 are you fine with the latest version of this patch? ------------- PR: https://git.openjdk.java.net/jdk/pull/4874 From myano at openjdk.java.net Wed Aug 4 07:25:06 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Wed, 4 Aug 2021 07:25:06 GMT Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v2] In-Reply-To: References: Message-ID: > Hi all, > > Could you please review the 8269373 bug fixes? > > These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder. Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: 8269373: use test opts for process arguments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4594/files - new: https://git.openjdk.java.net/jdk/pull/4594/files/e5546ded..99925f72 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4594&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4594&range=00-01 Stats: 14 lines in 6 files changed: 4 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4594/head:pull/4594 PR: https://git.openjdk.java.net/jdk/pull/4594 From myano at openjdk.java.net Wed Aug 4 07:32:45 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Wed, 4 Aug 2021 07:32:45 GMT Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v2] In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 07:25:06 GMT, Masanori Yano wrote: >> Hi all, >> >> Could you please review the 8269373 bug fixes? >> >> These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder. > > Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: > > 8269373: use test opts for process arguments Sorry for late reply. These tests compare the output of running the jar, and the correct answers to the output results are written in English. When these are run on localized Windows platform, the output will be in the local language and the comparison result will be false. So, these need to add -Duser.language=en and -Duser.country=US to the execution option of the jar. And I fixed to avoid hardcoding by using "test.vm.opts". If we want to run these tests on localized Windows platform, we need to add -Duser.language=en and -Duser.country=US as jtreg command options. ------------- PR: https://git.openjdk.java.net/jdk/pull/4594 From github.com+70726043+rgiulietti at openjdk.java.net Wed Aug 4 07:44:31 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Wed, 4 Aug 2021 07:44:31 GMT Subject: RFR: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places [v4] In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 00:57:16 GMT, Brian Burkhalter wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places > > Marked as reviewed by bpb (Reviewer). @bplb or @jddarcy could you please file a CSR on the JBS for this PR? As I don't have Author status, I'm not entitled to help myself. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/4963 From redestad at openjdk.java.net Wed Aug 4 07:53:44 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 4 Aug 2021 07:53:44 GMT Subject: RFR: 8271840: Add simple Integer.toString microbenchmarks Message-ID: This adds Integer.toString microbenchmarks, roughly similar to the Long.toString microbenchmarks (toStringSmall should use an equivalent data set). This is useful for comparison purposes and completeness. Also tuned existing benchmarks to harmonize setup, reduce runtime without significantly harming reliability of results, and remove the explicit Threads.MAX from Longs ------------- Commit messages: - Add simple Integer.toString microbenchmarks Changes: https://git.openjdk.java.net/jdk/pull/4988/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4988&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271840 Stats: 43 lines in 2 files changed: 33 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4988.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4988/head:pull/4988 PR: https://git.openjdk.java.net/jdk/pull/4988 From daniel.peintner at gmail.com Wed Aug 4 07:56:34 2021 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Wed, 4 Aug 2021 09:56:34 +0200 Subject: [External] : Re: jpackage MacOS Notarization In-Reply-To: References: <9d2ab55d-7ab7-b4a9-d49d-3f8e92e8da6a@oracle.com> <7092667d-6ac9-1e82-27e4-3bca64fd5a8b@oracle.com> <96386cce-031c-b12c-b92e-9b7bbcd69991@oracle.com> Message-ID: Hi Andy, The problem is you are signing the pkg but building it from an unsigned > app-image. > > If you are building in two phases (app-image, then installer package) you > need the --mac-sign option on both phases. > Thank you very much. It resolved the problem (I wasn't aware that --mac-sign option is required on both phases) I updated my test repo hoping it might be of use for others https://github.com/danielpeintner/Java11Test/tree/non-modular Thank you very much! -- Daniel > /Andy > On 8/3/2021 10:37 AM, Andy Herrick wrote: > > I was having problems notarizing anything yesterday, but fixed them today. > > I can notarize my own test - but get failure when trying to notarize your > app as built from non-modular branch of > https://github.com/danielpeintner/Java11Test/ > > am looking into it ... > > /Andy > > > On 8/2/2021 9:57 AM, Daniel Peintner wrote: > > Hi Andy, > >> sorry - code looks for certificate key starting with: "Developer ID >> Application: " + in order to not >> have to put full user name in. I missed that that with null user name that >> causes it to look for anything starting with "Developer ID Application: >> " (same thing with "Developer ID Installer: " for .pkg signing). And >> macos looks at the non-default keychains as well as the default ones when >> no keychain is specified. >> > Thanks for your feedback and yes in the simple case (with one certificate > installed) it works without any further information. > > May I ask you whether you were able to reproduce the issue? > > Is there anything I can do to help? > > Thanks, > > -- Daniel > > > >> /Andy >> On 7/29/2021 10:00 AM, Daniel Peintner wrote: >> >> Hi Andy, >> >> Since I don't know your setup I did not put anything there. >> >> '--mac-sign' is enough to use the defaults in my setup. >> >> It looks for the signing keys installed on my machine that start with "Developer >> ID Application " similar to >> '--mac-signing-key-user-name', 'Developer ID Application: ' >> etc. >> >> If you want to test it you need to add your credentials which I do not >> know. >> >> Hope this clarifies things, >> >> -- Daniel >> >> >> >> On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick >> wrote: >> >>> The 'build.gradle' in this branch has --mac-signing-key-user-name >>> commented out. >>> >>> installerOptions += [ >>> '--mac-sign', >>> // '--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name', >>> System.getenv('SIGNING_KEY_USER_NAME'), >>> // '--mac-signing-keychain', >>> System.getenv('SIGNING_KEYCHAIN_PATH') >>> ] >>> >>> clearly this cannot work, I assume you were just trying things ... >>> >>> What is the full name of the certificate you intended to use, what >>> keychain is it shown in "Keychain Access", and what are you normal values >>> for your environment variables: 'SIGNING_KEY_USER_NAME' and >>> 'SIGNING_KEYCHAIN_PATH' ? >>> >>> /Andy >>> On 7/29/2021 4:36 AM, Daniel Peintner wrote: >>> >>> Kevin, Andy, >>> >>> Thanks for your quick response. >>> >>> Full support for notarization in jpackage was added in JDK 17. Can you >>>> try an early access build of JDK 17 [1] and see if that works for you? >>>> >>> >>> I did try JDK17-ea-32 also with the same result. >>> >>> Since I do understand it is difficult reproduce the problem I put >>> together a *very* simple test application which you can find in the >>> "non-modular" branch here: >>> https://github.com/danielpeintner/Java11Test/tree/non-modular >>> >>> >>> It is a gradle project. It uses Java 11 to run but in build.gradle on >>> line#83 [1] one can set the jpackage location (JDK17-ea-32 in this >>> case). >>> >>> The process is as follows >>> * ./gradlew build >>> * ./gradlew jpackage // creates the dmg/pkg in folder build/jpackage >>> * afterwards Apple notarization process can be started >>> >>> Note: notarization of dmg or pkg lead to the same failure. >>> See [2] for the full log w.r.t. pkg. >>> >>> I hope this helps you to be able to reproduce the issue. >>> >>> Thanks for your investigations! >>> >>> -- Daniel >>> >>> [1] >>> https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle#L83 >>> >>> [2] >>> https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs%2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w%2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh%2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX%2FN6zZoyz73I%3D >>> >>> >>> >>>> >>>> >>>> -- Kevin >>>> >>>> [1] https://jdk.java.net/17 >>>> >>>> >>>> On 7/28/2021 8:27 AM, Daniel Peintner wrote: >>>> > All, >>>> > >>>> > I am trying to notarize an app (built with jpackage) for MacOS. >>>> > >>>> > jpackage at first *seems* to properly sign all resources with the >>>> available >>>> > --mac-sign options et cetera. >>>> > >>>> > Having said that, there are still remaining issues >>>> > 1. The app cannot be properly installed >>>> > (without hacks like xattr -d com.apple.quarantine >>>> /Applications/myAPP.app >>>> > ). >>>> > 2. I am also not able to properly notarize the app. >>>> > >>>> > According to online resources there seem to exist issues in *past* >>>> about >>>> > notarization but according to [1, 2] the issues are fixed. >>>> > >>>> > As mentioned, I still have issues :-( >>>> > Am I really the only one still having problems? >>>> > >>>> > Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without >>>> success) >>>> > >>>> > The issue seems to boil down to 2 errors (attached the error log from >>>> Apple >>>> > notarization process). >>>> > * app Folder >>>> > * libjli.dylib >>>> > >>>> > I thought I better ask first on the mailing list before creating an >>>> actual >>>> > bug report. >>>> > >>>> > Note1: I used to use the *old* javapackager that worked with the same >>>> > signature/credentials. >>>> > Note2: running jpackage without --mac-sign options causes many more >>>> errors >>>> > in notarization (Hence, jpackage signs most resources but fails with >>>> some) >>>> > >>>> > Any help / hint appreciated. >>>> > >>>> > Thanks, >>>> > >>>> > -- Daniel >>>> > >>>> > [1] https://bugs.openjdk.java.net/browse/JDK-8257488 >>>> > [2] https://bugs.openjdk.java.net/browse/JDK-8251892 >>>> > >>>> > >>>> > >>>> > ## APPLE LOG ## >>>> > >>>> > { >>>> > "logFormatVersion": 1, >>>> > "jobId": "...", >>>> > "status": "Invalid", >>>> > "statusSummary": "Archive contains critical validation errors", >>>> > "statusCode": 4000, >>>> > "archiveFilename": "myAPP-21.07.28.dmg", >>>> > "uploadDate": "2021-07-28T14:31:24Z", >>>> > "sha256": "...", >>>> > "ticketContents": null, >>>> > "issues": [ >>>> > { >>>> > "severity": "error", >>>> > "code": null, >>>> > "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP", >>>> > "message": "The signature of the binary is invalid.", >>>> > "docUrl": null, >>>> > "architecture": "x86_64" >>>> > }, >>>> > { >>>> > "severity": "error", >>>> > "code": null, >>>> > "path": >>>> "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib", >>>> > "message": "The signature of the binary is invalid.", >>>> > "docUrl": null, >>>> > "architecture": "x86_64" >>>> > } >>>> > ] >>>> > } >>>> >>>> From shade at openjdk.java.net Wed Aug 4 08:07:32 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 4 Aug 2021 08:07:32 GMT Subject: RFR: 8271840: Add simple Integer.toString microbenchmarks In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 07:46:48 GMT, Claes Redestad wrote: > This adds Integer.toString microbenchmarks, roughly similar to the Long.toString microbenchmarks (toStringSmall should use an equivalent data set). This is useful for comparison purposes and completeness. > > Also tuned existing benchmarks to harmonize setup, reduce runtime without significantly harming reliability of results, and remove the explicit Threads.MAX from Longs Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4988 From wuyan at openjdk.java.net Wed Aug 4 09:40:36 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Wed, 4 Aug 2021 09:40:36 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v5] In-Reply-To: References: Message-ID: <6GBF5z5V25bgVwvSAEjhzaLpfmMU0PXymvVtQ0P9h0U=.28aa8931-0f3e-47eb-8c31-226b897815dd@github.com> On Wed, 4 Aug 2021 03:29:40 GMT, Nick Gasson wrote: > Please provide the updated benchmark results for this version. Are you able to test it on several different machines? We tested this version on Raspberry Pi 4B. base: Benchmark (diff_pos) (size) Mode Cnt Score Error Units StringCompare.compareLLDiffStrings 7 256 avgt 5 14.882 ? 0.157 us/op StringCompare.compareLLDiffStrings 15 256 avgt 5 15.514 ? 0.094 us/op StringCompare.compareLLDiffStrings 31 256 avgt 5 16.756 ? 0.050 us/op StringCompare.compareLLDiffStrings 47 256 avgt 5 18.196 ? 0.727 us/op StringCompare.compareLLDiffStrings 63 256 avgt 5 20.110 ? 0.075 us/op StringCompare.compareLLDiffStrings 127 256 avgt 5 31.458 ? 0.032 us/op StringCompare.compareLLDiffStrings 255 256 avgt 5 53.099 ? 1.212 us/op StringCompare.compareUUDiffStrings 7 256 avgt 5 15.419 ? 0.012 us/op StringCompare.compareUUDiffStrings 15 256 avgt 5 16.761 ? 0.078 us/op StringCompare.compareUUDiffStrings 31 256 avgt 5 20.132 ? 0.112 us/op StringCompare.compareUUDiffStrings 47 256 avgt 5 27.492 ? 0.104 us/op StringCompare.compareUUDiffStrings 63 256 avgt 5 32.147 ? 0.028 us/op StringCompare.compareUUDiffStrings 127 256 avgt 5 56.208 ? 0.016 us/op StringCompare.compareUUDiffStrings 255 256 avgt 5 100.439 ? 0.782 us/op StringCompare.compareUUDiffStringsTurnOffCCP 7 256 avgt 5 15.441 ? 0.071 us/op StringCompare.compareUUDiffStringsTurnOffCCP 15 256 avgt 5 16.781 ? 0.192 us/op StringCompare.compareUUDiffStringsTurnOffCCP 31 256 avgt 5 20.109 ? 0.010 us/op StringCompare.compareUUDiffStringsTurnOffCCP 47 256 avgt 5 27.463 ? 0.068 us/op StringCompare.compareUUDiffStringsTurnOffCCP 63 256 avgt 5 32.168 ? 0.064 us/op StringCompare.compareUUDiffStringsTurnOffCCP 127 256 avgt 5 56.283 ? 0.551 us/op StringCompare.compareUUDiffStringsTurnOffCCP 255 256 avgt 5 100.419 ? 0.914 us/op opt: Benchmark (diff_pos) (size) Mode Cnt Score Error Units StringCompare.compareLLDiffStrings 7 256 avgt 5 14.064 ? 0.048 us/op StringCompare.compareLLDiffStrings 15 256 avgt 5 16.079 ? 0.041 us/op StringCompare.compareLLDiffStrings 31 256 avgt 5 17.413 ? 0.033 us/op StringCompare.compareLLDiffStrings 47 256 avgt 5 18.750 ? 0.012 us/op StringCompare.compareLLDiffStrings 63 256 avgt 5 20.093 ? 0.052 us/op StringCompare.compareLLDiffStrings 127 256 avgt 5 27.432 ? 0.009 us/op StringCompare.compareLLDiffStrings 255 256 avgt 5 44.832 ? 0.173 us/op StringCompare.compareUUDiffStrings 7 256 avgt 5 16.071 ? 0.028 us/op StringCompare.compareUUDiffStrings 15 256 avgt 5 18.082 ? 0.015 us/op StringCompare.compareUUDiffStrings 31 256 avgt 5 20.753 ? 0.006 us/op StringCompare.compareUUDiffStrings 47 256 avgt 5 25.427 ? 0.051 us/op StringCompare.compareUUDiffStrings 63 256 avgt 5 28.170 ? 0.091 us/op StringCompare.compareUUDiffStrings 127 256 avgt 5 42.809 ? 0.143 us/op StringCompare.compareUUDiffStrings 255 256 avgt 5 75.056 ? 0.741 us/op StringCompare.compareUUDiffStringsTurnOffCCP 7 256 avgt 5 16.132 ? 0.195 us/op StringCompare.compareUUDiffStringsTurnOffCCP 15 256 avgt 5 17.423 ? 0.023 us/op StringCompare.compareUUDiffStringsTurnOffCCP 31 256 avgt 5 20.102 ? 0.112 us/op StringCompare.compareUUDiffStringsTurnOffCCP 47 256 avgt 5 25.529 ? 0.367 us/op StringCompare.compareUUDiffStringsTurnOffCCP 63 256 avgt 5 26.804 ? 0.051 us/op StringCompare.compareUUDiffStringsTurnOffCCP 127 256 avgt 5 40.988 ? 0.425 us/op StringCompare.compareUUDiffStringsTurnOffCCP 255 256 avgt 5 77.157 ? 0.187 us/op On the Raspberry Pi, the improvement is more obvious when the diff_pos is above 127. > I meant the earlier String.compareTo that this is partially replacing. This one might be fine but I just wanted to check it had be thoroughly tested. For reference they were: > > https://bugs.openjdk.java.net/browse/JDK-8215100 > https://bugs.openjdk.java.net/browse/JDK-8237524 > https://bugs.openjdk.java.net/browse/JDK-8218966 Thank you for your reminder. This version can pass these three test cases. In addition, we tested tier1-tier3 and no new test cases fail. ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From redestad at openjdk.java.net Wed Aug 4 10:51:38 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 4 Aug 2021 10:51:38 GMT Subject: RFR: 8260710: Inline and simplify String*::{coder, value, isLatin1} methods In-Reply-To: References: Message-ID: <9jJTRouqCOBFLjPJh4ZN1ez3novoHRL-nARD8BIt2WE=.39fe3123-7a0d-4e7b-bcca-6a897581ce23@github.com> On Mon, 1 Feb 2021 13:11:52 GMT, Aleksey Shipilev wrote: > Since Compact Strings implementation, there are simple methods in String and StringBuilders: `coder()`, `value()`, `isLatin1()`. They are mostly there to capture `COMPACT_STRINGS` flag that would fold to "false" when compact strings are disabled with `-XX:-CompactStrings`. > > This was to guarantee the same performance when Compact String are unimplemented and/or have surprising performance behaviors. Quite some time had passed since JDK 9 release, and we can consider simplifying these. For example, ignoring `COMPACT_STRINGS` and inlining the methods simplifies the code. Some new code added to `String` after JDK 9 already has these methods inlined, checking `coder` directly. > > The major drawback is that supplying `-XX:-CompactStrings` would have to go through the same `coder == UTF16` paths the "normal" Compact Strings are going. It would not be folded to the most optimal form by the optimizer, because `coder` field value is generally opaque to optimizers. > > On the flip side, there is an advantage on paths that do not have optimizer ready (yet), for example at startup. Hello World startup improves for about 0.3 msec (or ~1.3%). The improvement is quite probably more visible on larger workloads, i.e. large application servers. (In fact, this is where I spotted this opportunity: OpenLiberty startup profiles). > > Interpreter-only "Hello World": > > > Performance counter stats for 'taskset -c 13 build/baseline/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs): > > 23.40 msec task-clock # 0.933 CPUs utilized ( +- 0.01% ) > 86,133,190 cycles # 3.680 GHz ( +- 0.01% ) > 79,854,588 instructions # 0.93 insn per cycle ( +- 0.00% ) > > 0.02507105 +- 0.00000343 seconds time elapsed ( +- 0.01% ) > > Performance counter stats for 'taskset -c 13 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs): > > 23.07 msec task-clock # 0.935 CPUs utilized ( +- 0.01% ) > 84,877,118 cycles # 3.679 GHz ( +- 0.01% ) > 79,231,598 instructions # 0.93 insn per cycle ( +- 0.00% ) > > 0.02466467 +- 0.00000382 seconds time elapsed ( +- 0.02% ) > > > > OpenLiberty startup: > > > Before: 2.296, 2.281, 2.291 (seconds) > After: 2.254, 2.267, 2.272 (seconds) > > > Additional tests: > - [x] Linux `tier1` default (passes) > - [x] Linux `tier1` `-XX:-CompactStrings` Was this abandoned out of concern there'd be noticeable regressions when `COMPACT_STRING` is `false`? > > It would be useful to drive a discussion of removing fallback provided > > by COMPACT_STRINGS? entirely. > > It was retained initially as a hedge against bugs in the new implementation. > > It adds complexity to the implementation and can hide implementation bugs. > > Isn't COMPACT_STRING inherently slower if you are processing predominantly Chinese/Japanese/Korean text? I'm curious how common it is to deploy with `-XX:-CompactStrings` in such locales. Does anyone have any real world data on this on JDK 11 or later? In most apps I'd expect a large number of strings created and retained to be latin1-encodable independent of locale (think: XML/JSON/HTML tags/attributes, many of the Strings created and passed around by the JDK and libraries etc..), so it's not clear-cut that `+CompactStrings` is always inherently slower there. And if it is I think the slowness might stem mainly from things like speculatively assuming latin1 in some places when decoding character data etc. Since JDK 9 there has seen several useful optimizations that might have removed some rough edges here, e.g., https://bugs.openjdk.java.net/browse/JDK-8231717 Academics aside, if `-CompactStrings` is commonly used and this patch would harm performance in that mode (would it, really?) then we shouldn't do this for a small startup win. ------------- PR: https://git.openjdk.java.net/jdk/pull/2334 From zgu at openjdk.java.net Wed Aug 4 12:16:34 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 4 Aug 2021 12:16:34 GMT Subject: RFR: JDK-8256844: Make NMT late-initializable [v2] In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 03:36:11 GMT, Thomas Stuefe wrote: > Nightlies at SAP showed no problems for several runs now. The failed GHA test (StringDeduplication) seems to have nothing to do with my patch. > > @zhengyu123 are you fine with the latest version of this patch? Still good. ------------- PR: https://git.openjdk.java.net/jdk/pull/4874 From stuefe at openjdk.java.net Wed Aug 4 12:21:38 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 4 Aug 2021 12:21:38 GMT Subject: Integrated: JDK-8256844: Make NMT late-initializable In-Reply-To: References: Message-ID: <23V2mAhhsYn7SXfOfL-8FRZY0UCIRutSli-Q8mizBUg=.410c3c0a-5526-42fe-88eb-ffae255159d4@github.com> On Thu, 22 Jul 2021 14:58:47 GMT, Thomas Stuefe wrote: > Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing, cleans them up and makes them sideeffect-free. > > --------- > > NMT continues to be an extremely useful tool for SAP to tackle memory problems in the JVM. > > However, NMT is of limited use due to the following restrictions: > > - NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible. > - Worse, if that custom launcher links the libjvm *statically* there is just no way to activate NMT at all. This is the reason NMT cannot be used in the `gtestlauncher`. > - Related to that is that we cannot pass NMT options via `JAVA_TOOL_OPTIONS` and `-XX:Flags=`. > - The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff. > > The reason for all this is that NMT initialization happens very early, on the first call to `os::malloc()`. And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments. > > The current solution is to pass NMT arguments via a specially prepared environment variable: `NMT_LEVEL_=`. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher. > > All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. `java` itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand. > > And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., `JAVA_TOOL_OPTIONS`. > > ------ > > This patch fixes these shortcomings by making NMT late-initializable: it can now be initialized after normal VM argument parsing, like all other parts of the VM. This greatly simplifies NMT initialization and makes it work automagically for every third party launcher, as well as within our gtests. > > The glaring problem with late-initializing NMT is the NMT malloc headers. If we rule out just always having them (unacceptable in terms of memory overhead), there is no safe way to determine, in os::free(), if an allocation came from before or after NMT initialization ran, and therefore what to do with its malloc headers. For a more extensive explanation, please see the comment block `nmtPreInit.hpp` and the discussion with @kimbarrett and @zhengyu123 in the JBS comment section. > > The heart of this patch is a new way to track early, pre-NMT-init allocations. These are tracked via a lookup table. This was a suggestion by Kim and it worked out well. > > Changes in detail: > > - pre-NMT-init handling: > - the new files `nmtPreInit.hpp/cpp` take case of NMT pre-init handling. They contain a small global lookup table managing C-heap blocks allocated in the pre-NMT-init phase. > - `os::malloc()/os::realloc()/os::free()` defer to this code before doing anything else. > - Please see the extensive comment block at the start of `nmtPreinit.hpp` explaining the details. > > - Changes to NMT: > - Before, NMT initialization was spread over two phases, `initialize()` and `late_initialize()`. Those were merged into one and simplified - there is only one initialization now which happens after argument parsing. > - Minor changes were needed for the `NMT_TrackingLevel` enum - to simplify code, I changed NMT_unknown to be numerically 0. A new comment block in `nmtCommon.hpp` now clearly specifies what's what, including allowed level state transitions. > - New utility functions to translate tracking level from/to strings added to `NMTUtil` > - NMT has never been able to handle virtual memory allocations before initialization, which is fine since os::reserve_memory() is not called before VM parses arguments. We now assert that. > - All code outside the VM handling NMT initialization (eg. libjli) has been removed, as has the code testing it. > > - Gtests: > - Some existing gtests had to be modified: before, they all changed global state (turning NMT on/off) before testing. This is not allowed anymore, to keep NMT simple. Also, this pattern disturbed other tests. > - The new way to test is to passively check whether NMT has been switched on or off, and do tests accordingly: if on, full tests, if off, test just what makes sense in off-state. That does not disturb neighboring tests, gives us actually better coverage all around. > - It is now possible to start the gtestlauncher with NMT on! Which additionally gives us good coverage. > - To actually do gtests with NMT - since it's disabled by default - we now run NMT-enabled gtests as part of the hotspot jtreg NMT wrapper. This pattern we have done for a number of other facitilites, see all the tests in test/hotspot/jtreg/gtest.. . It works very well. > - Finally, a new gtest has been written to test the NMT preinit lookup map in isolation, placed in `gtest/nmt/test_nmtpreinitmap.cpp`. > > - jtreg: > - A new test has been added, `runtime/NMT/NMTInitializationTest.java`, testing NMT initialization in the face of many many VM arguments. > > ------------- > > Tests: > - ran manually all new tests on 64-bit and 32-bit Linux > - GHAs > - The patch has been active in SAPs test systems for a while now. This pull request has now been integrated. Changeset: eec64f55 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/eec64f55870cf51746755d8fa59098a82109e826 Stats: 1828 lines in 25 files changed: 1394 ins; 390 del; 44 mod 8256844: Make NMT late-initializable Reviewed-by: coleenp, zgu ------------- PR: https://git.openjdk.java.net/jdk/pull/4874 From stuefe at openjdk.java.net Wed Aug 4 12:21:37 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 4 Aug 2021 12:21:37 GMT Subject: RFR: JDK-8256844: Make NMT late-initializable [v2] In-Reply-To: <9fJF6K7k4Pn7Ktu4W9KgcjmekQv3wYfS1pWiA0SlntI=.177a2a19-0639-4a8b-8ed5-f5f3d4030713@github.com> References: <9fJF6K7k4Pn7Ktu4W9KgcjmekQv3wYfS1pWiA0SlntI=.177a2a19-0639-4a8b-8ed5-f5f3d4030713@github.com> Message-ID: On Mon, 2 Aug 2021 14:24:54 GMT, Coleen Phillimore wrote: >>> This is an interesting and it seems a better way to solve this problem. Where were you all those years ago?? I hope @zhengyu123 has a chance to review it. >> >> Thank you! I was here, but we were not yet doing much upstream :) To be fair, this problem got quite involved and did cost me some cycles and false starts. I fully understand that the first solution uses the environment variable approach. >> >> I spend some time investigating different ideas with this one; at first I did not use a hash-table but a static pre-allocated buffer from which I fed early allocations. But the code got too complex, and Kim's suggestion with the side table turned out just to be a lot simpler. >> >>> Also interesting is that we were wondering how we could return malloc'd memory on JVM creation failure, and this might partially help with that larger problem. >> >> Yes, this would be trivial now, to return that memory. Though I am afraid it would be a small part only. But NMT may be instrumental in releasing all memory, since it knows everything. Only, its not always enabled. >> >> Is that a real-life problem? Are there cases where the launcher would want to live on if the JVM failed to load? > >> Is that a real-life problem? Are there cases where the launcher would want to live on if the JVM failed to load? > > There are a lot of other reasons why the launcher couldn't live on if the JVM fails to load. This was only one of them. We used to think about this problem once but don't really think it's solveable. Thanks @coleenp and @zhengyu123 ! ------------- PR: https://git.openjdk.java.net/jdk/pull/4874 From bpb at openjdk.java.net Wed Aug 4 16:13:30 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 4 Aug 2021 16:13:30 GMT Subject: RFR: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places [v4] In-Reply-To: References: Message-ID: On Tue, 3 Aug 2021 22:44:57 GMT, Raffaello Giulietti wrote: >> Hello, >> >> please review the changes in documentation of floorDiv() and floorMod() in all their variants. Some are clarifications, some are corrections. >> >> Here's an example of a confusing formulation in the current doc >>> "the / operator returns the integer closest to zero" >> >> Literally, the integer closest to zero is zero! >> >> >> The doc of floorMod(int, int) also states: >>> "If the signs of arguments are unknown and a positive modulus >>> is needed it can be computed as (floorMod(x, y) + abs(y)) % abs(y)." >> >> That's a questionable advice, as the sum in parentheses can lead to irrecoverable overflow (beside requiring two divisions instead of one). >> E.g., setting x = Integer.MAX_VALUE - 1, y = Integer.MAX_VALUE leads to the quite incorrect result -3, which is not even positive! >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places Done yesterday (JDK-8271827). ------------- PR: https://git.openjdk.java.net/jdk/pull/4963 From github.com+70726043+rgiulietti at openjdk.java.net Wed Aug 4 17:19:37 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Wed, 4 Aug 2021 17:19:37 GMT Subject: Integrated: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 22:34:58 GMT, Raffaello Giulietti wrote: > Hello, > > please review the changes in documentation of floorDiv() and floorMod() in all their variants. Some are clarifications, some are corrections. > > Here's an example of a confusing formulation in the current doc >> "the / operator returns the integer closest to zero" > > Literally, the integer closest to zero is zero! > > > The doc of floorMod(int, int) also states: >> "If the signs of arguments are unknown and a positive modulus >> is needed it can be computed as (floorMod(x, y) + abs(y)) % abs(y)." > > That's a questionable advice, as the sum in parentheses can lead to irrecoverable overflow (beside requiring two divisions instead of one). > E.g., setting x = Integer.MAX_VALUE - 1, y = Integer.MAX_VALUE leads to the quite incorrect result -3, which is not even positive! > > > Greetings > Raffaello This pull request has now been integrated. Changeset: 9f1edafa Author: Raffaello Giulietti Committer: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/9f1edafac4f096977ea6ce075ae7a6b0c2112b7d Stats: 50 lines in 2 files changed: 6 ins; 7 del; 37 mod 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places Reviewed-by: darcy, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/4963 From bpb at openjdk.java.net Wed Aug 4 18:52:42 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 4 Aug 2021 18:52:42 GMT Subject: Integrated: 8271888: build error after JDK-8271599 In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 18:42:08 GMT, Joe Darcy wrote: > Remove extraneous

tag to fix build breakage. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5002 From darcy at openjdk.java.net Wed Aug 4 18:52:42 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 4 Aug 2021 18:52:42 GMT Subject: Integrated: 8271888: build error after JDK-8271599 Message-ID: Remove extraneous

tag to fix build breakage. ------------- Commit messages: - 8271888 Changes: https://git.openjdk.java.net/jdk/pull/5002/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5002&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271888 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5002.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5002/head:pull/5002 PR: https://git.openjdk.java.net/jdk/pull/5002 From psandoz at openjdk.java.net Wed Aug 4 18:52:42 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 4 Aug 2021 18:52:42 GMT Subject: Integrated: 8271888: build error after JDK-8271599 In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 18:42:08 GMT, Joe Darcy wrote: > Remove extraneous

tag to fix build breakage. Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5002 From darcy at openjdk.java.net Wed Aug 4 18:52:43 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 4 Aug 2021 18:52:43 GMT Subject: Integrated: 8271888: build error after JDK-8271599 In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 18:42:08 GMT, Joe Darcy wrote: > Remove extraneous

tag to fix build breakage. This pull request has now been integrated. Changeset: 91bbe2fc Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/91bbe2fcbda008a9adc8aa77149a4f2156e1b46b Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8271888: build error after JDK-8271599 Reviewed-by: psandoz, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5002 From herrick at openjdk.java.net Wed Aug 4 20:40:40 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Wed, 4 Aug 2021 20:40:40 GMT Subject: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. Message-ID: 8271868: Warn user when using mac-sign option with unsigned app-image. ------------- Commit messages: - JDK-8271868: Warn user when using mac-sign option with unsigned app-image. - JDK-8271868: Warn user when using mac-sign option with unsigned app-image. - JDK-8271868: Warn user when using mac-sign option with unsigned app-image. - JDK-8271868: Warn user when using mac-sign option with unsigned app-image. Changes: https://git.openjdk.java.net/jdk/pull/5004/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5004&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271868 Stats: 34 lines in 5 files changed: 32 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5004.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5004/head:pull/5004 PR: https://git.openjdk.java.net/jdk/pull/5004 From almatvee at openjdk.java.net Wed Aug 4 21:01:29 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 4 Aug 2021 21:01:29 GMT Subject: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 20:00:37 GMT, Andy Herrick wrote: > 8271868: Warn user when using mac-sign option with unsigned app-image. Changes requested by almatvee (Reviewer). src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java line 877: > 875: try { > 876: IOUtils.exec(new ProcessBuilder("/usr/bin/codesign", > 877: "--verify", file.toString())); --deep should be added, so check is run on nested frameworks and helpers. src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java line 142: > 140: // is not allready signed. > 141: Path launcher = applicationImage.resolve("Contents/MacOS") > 142: .resolve(APP_NAME.fetchFrom(params)); As far as I remember launcher can be signed, but entire app image might not be signed. So, in this case check will pass, but notarization will fail. I think we should run check on app image itself. ------------- PR: https://git.openjdk.java.net/jdk/pull/5004 From asemenyuk at openjdk.java.net Wed Aug 4 21:05:27 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 4 Aug 2021 21:05:27 GMT Subject: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 20:00:37 GMT, Andy Herrick wrote: > 8271868: Warn user when using mac-sign option with unsigned app-image. What if we save "signed/not signed" flag in ".jpackage.xml" when building app image and read its value instead of guessing if they signed app image or not using `codesign`? .jpackage.xml is designed specifically to pass data between multiple invocations of jpackage. ------------- PR: https://git.openjdk.java.net/jdk/pull/5004 From almatvee at openjdk.java.net Wed Aug 4 21:11:28 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 4 Aug 2021 21:11:28 GMT Subject: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 20:00:37 GMT, Andy Herrick wrote: > 8271868: Warn user when using mac-sign option with unsigned app-image. I think it will not work. User might modify app image after it was created and it will invalidate signature. ------------- PR: https://git.openjdk.java.net/jdk/pull/5004 From asemenyuk at openjdk.java.net Wed Aug 4 21:14:28 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 4 Aug 2021 21:14:28 GMT Subject: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 20:00:37 GMT, Andy Herrick wrote: > 8271868: Warn user when using mac-sign option with unsigned app-image. What options exist for building a package from app image with invalid signature? ------------- PR: https://git.openjdk.java.net/jdk/pull/5004 From herrick at openjdk.java.net Wed Aug 4 22:18:29 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Wed, 4 Aug 2021 22:18:29 GMT Subject: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 20:00:37 GMT, Andy Herrick wrote: > 8271868: Warn user when using mac-sign option with unsigned app-image. The purpose of this change is to catch the case (and emit a warning) when user creates an app-image w/o using --mac-sign, and then uses that app image to build a pkg or dmg bundle using --mac-sign. For this purpose, checking if the main launcher is signed is sufficient. There is no reason to check all the executables, libraries, and/or Frameworks in the app image., and there is no such thing as signing the app-image itself, also using --deep arg to codesigner is specifically recommended against in all codesigner documentation I have read. The user can modify the app-image in any way he chooses, possibly invalidating the signing, before using it to create dmg or pkg (or he may create the app-image unsigned, and manually sign all or any part of it. This really has nothing to do with this change. The app-image can still be used to create a dmg or pkg using --mac-sign or not. The alternative of recording if the app-image was created with --app-sign in the AppImageFile is a reasonable alternative to verifying the signing of the main launchers ------------- PR: https://git.openjdk.java.net/jdk/pull/5004 From herrick at openjdk.java.net Wed Aug 4 22:25:28 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Wed, 4 Aug 2021 22:25:28 GMT Subject: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 20:56:46 GMT, Alexander Matveev wrote: >> 8271868: Warn user when using mac-sign option with unsigned app-image. > > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java line 142: > >> 140: // is not allready signed. >> 141: Path launcher = applicationImage.resolve("Contents/MacOS") >> 142: .resolve(APP_NAME.fetchFrom(params)); > > As far as I remember launcher can be signed, but entire app image might not be signed. So, in this case check will pass, but notarization will fail. I think we should run check on app image itself. jpackage will either copy the launcher from resource unmodified and unsigned, or sign all the sign-able elements in the app-image (including the launcher). ------------- PR: https://git.openjdk.java.net/jdk/pull/5004 From almatvee at openjdk.java.net Wed Aug 4 22:53:32 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 4 Aug 2021 22:53:32 GMT Subject: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. In-Reply-To: References: Message-ID: <1mQM2tPkcfewOEPbU59eYpFX2NdHmu0EGR0Ul3m4CzQ=.536a3ab4-7c12-45a5-9786-2e0626b1cd54@github.com> On Wed, 4 Aug 2021 20:00:37 GMT, Andy Herrick wrote: > 8271868: Warn user when using mac-sign option with unsigned app-image. First of all why we only want to cover case when app-image was produced without --mac-sign? If we want to cover such case only, then we need to use approach suggested by Alexey and record signing flag in .jpackage.xml. Otherwise, user will receive false warning if unsigned app-image is provided which was generated without using jpackage or in case if app-image was modified after it was generated and signed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5004 From asemenyuk at openjdk.java.net Wed Aug 4 23:07:29 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 4 Aug 2021 23:07:29 GMT Subject: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 20:00:37 GMT, Andy Herrick wrote: > 8271868: Warn user when using mac-sign option with unsigned app-image. My understanding of this enhancement is to warn user when app image created without --mac-sign is used in building a signed package. I.e. to warn user they misused --mac-sign option. We don't want to check the quality of app image and its suitability for packaging in signed package as a part of this enhancement. For this limited scope checking the value of signing flag recorded in .jpackage.xml seems reasonable approach. ------------- PR: https://git.openjdk.java.net/jdk/pull/5004 From naoto at openjdk.java.net Wed Aug 4 23:20:30 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 4 Aug 2021 23:20:30 GMT Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v2] In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 07:25:06 GMT, Masanori Yano wrote: >> Hi all, >> >> Could you please review the 8269373 bug fixes? >> >> These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder. > > Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: > > 8269373: use test opts for process arguments Then I would think the better fix would be to run the test if the default locale is `Locale.US`, otherwise the test should exit gracefully. ------------- PR: https://git.openjdk.java.net/jdk/pull/4594 From wuyan at openjdk.java.net Thu Aug 5 02:43:37 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Thu, 5 Aug 2021 02:43:37 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v5] In-Reply-To: References: Message-ID: On Tue, 3 Aug 2021 13:33:07 GMT, Wang Huang wrote: >> Dear all, >> Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo. >> >> * We add a JMH test case >> * Here is the result of this test case >> >> Benchmark |(size)| Mode| Cnt|Score | Error |Units >> ---------------------------------|------|-----|----|------|--------|----- >> StringCompare.compareLL | 64 | avgt| 5 |7.992 | ? 0.005|us/op >> StringCompare.compareLL | 72 | avgt| 5 |15.029| ? 0.006|us/op >> StringCompare.compareLL | 80 | avgt| 5 |14.655| ? 0.011|us/op >> StringCompare.compareLL | 91 | avgt| 5 |16.363| ? 0.12 |us/op >> StringCompare.compareLL | 101 | avgt| 5 |16.966| ? 0.007|us/op >> StringCompare.compareLL | 121 | avgt| 5 |19.276| ? 0.006|us/op >> StringCompare.compareLL | 181 | avgt| 5 |19.002| ? 0.417|us/op >> StringCompare.compareLL | 256 | avgt| 5 |24.707| ? 0.041|us/op >> StringCompare.compareLLWithLdp| 64 | avgt| 5 |8.001 | ? 0.121|us/op >> StringCompare.compareLLWithLdp| 72 | avgt| 5 |11.573| ? 0.003|us/op >> StringCompare.compareLLWithLdp| 80 | avgt| 5 |6.861 | ? 0.004|us/op >> StringCompare.compareLLWithLdp| 91 | avgt| 5 |12.774| ? 0.201|us/op >> StringCompare.compareLLWithLdp| 101 | avgt| 5 |8.691 | ? 0.004|us/op >> StringCompare.compareLLWithLdp| 121 | avgt| 5 |11.091| ? 1.342|us/op >> StringCompare.compareLLWithLdp| 181 | avgt| 5 |14.64 | ? 0.581|us/op >> StringCompare.compareLLWithLdp| 256 | avgt| 5 |25.879| ? 1.775|us/op >> StringCompare.compareUU | 64 | avgt| 5 |13.476| ? 0.01 |us/op >> StringCompare.compareUU | 72 | avgt| 5 |15.078| ? 0.006|us/op >> StringCompare.compareUU | 80 | avgt| 5 |23.512| ? 0.011|us/op >> StringCompare.compareUU | 91 | avgt| 5 |24.284| ? 0.008|us/op >> StringCompare.compareUU | 101 | avgt| 5 |20.707| ? 0.017|us/op >> StringCompare.compareUU | 121 | avgt| 5 |29.302| ? 0.011|us/op >> StringCompare.compareUU | 181 | avgt| 5 |39.31 | ? 0.016|us/op >> StringCompare.compareUU | 256 | avgt| 5 |54.592| ? 0.392|us/op >> StringCompare.compareUUWithLdp| 64 | avgt| 5 |16.389| ? 0.008|us/op >> StringCompare.compareUUWithLdp| 72 | avgt| 5 |10.71 | ? 0.158|us/op >> StringCompare.compareUUWithLdp| 80 | avgt| 5 |11.488| ? 0.024|us/op >> StringCompare.compareUUWithLdp| 91 | avgt| 5 |13.412| ? 0.006|us/op >> StringCompare.compareUUWithLdp| 101 | avgt| 5 |16.245| ? 0.434|us/op >> StringCompare.compareUUWithLdp| 121 | avgt| 5 |16.597| ? 0.016|us/op >> StringCompare.compareUUWithLdp| 181 | avgt| 5 |27.373| ? 0.017|us/op >> StringCompare.compareUUWithLdp| 256 | avgt| 5 |41.74 | ? 3.5 |us/op >> >> From this table, we can see that in most cases, our patch is better than old one. >> >> Thank you for your review. Any suggestions are welcome. > > Wang Huang 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: > > - fix bugs > - Merge branch 'master' of https://gitee.com/ustc-wh/jdk into JDK-8268231 > - fix style and add unalign test case > - refact codes > - draft of refactor > - 8268231: Aarch64: Use ldp in intrinsics for String.compareTo We also tested this version on Hisilicon, increasing the count of each test and the length of the string because the test data fluctuates more. When diff_pos is greater than 255, the improvement will be more obvious. And in all cases there was no significant decline. base: Benchmark (diff_pos) (size) Mode Cnt Score Error Units StringCompare.compareLLDiffStrings 7 512 avgt 50 5.481 ? 1.230 us/op StringCompare.compareLLDiffStrings 31 512 avgt 50 6.944 ? 0.962 us/op StringCompare.compareLLDiffStrings 63 512 avgt 50 10.129 ? 0.973 us/op StringCompare.compareLLDiffStrings 127 512 avgt 50 15.944 ? 0.786 us/op StringCompare.compareLLDiffStrings 255 512 avgt 50 28.233 ? 0.737 us/op StringCompare.compareLLDiffStrings 511 512 avgt 50 51.612 ? 1.357 us/op StringCompare.compareUUDiffStrings 7 512 avgt 50 5.552 ? 0.809 us/op StringCompare.compareUUDiffStrings 31 512 avgt 50 12.024 ? 1.499 us/op StringCompare.compareUUDiffStrings 63 512 avgt 50 15.368 ? 0.009 us/op StringCompare.compareUUDiffStrings 127 512 avgt 50 28.354 ? 0.655 us/op StringCompare.compareUUDiffStrings 255 512 avgt 50 52.932 ? 0.598 us/op StringCompare.compareUUDiffStrings 511 512 avgt 50 99.377 ? 1.194 us/op StringCompare.compareUUDiffStringsTurnOffCCP 7 512 avgt 50 5.599 ? 0.801 us/op StringCompare.compareUUDiffStringsTurnOffCCP 31 512 avgt 50 10.200 ? 1.206 us/op StringCompare.compareUUDiffStringsTurnOffCCP 63 512 avgt 50 15.897 ? 0.783 us/op StringCompare.compareUUDiffStringsTurnOffCCP 127 512 avgt 50 28.420 ? 0.818 us/op StringCompare.compareUUDiffStringsTurnOffCCP 255 512 avgt 50 53.377 ? 1.049 us/op StringCompare.compareUUDiffStringsTurnOffCCP 511 512 avgt 50 98.362 ? 0.889 us/op opt: Benchmark (diff_pos) (size) Mode Cnt Score Error Units StringCompare.compareLLDiffStrings 7 512 avgt 50 6.338 ? 1.513 us/op StringCompare.compareLLDiffStrings 31 512 avgt 50 6.734 ? 0.789 us/op StringCompare.compareLLDiffStrings 63 512 avgt 50 9.799 ? 1.757 us/op StringCompare.compareLLDiffStrings 127 512 avgt 50 13.954 ? 1.688 us/op StringCompare.compareLLDiffStrings 255 512 avgt 50 19.128 ? 1.024 us/op StringCompare.compareLLDiffStrings 511 512 avgt 50 38.108 ? 1.595 us/op StringCompare.compareUUDiffStrings 7 512 avgt 50 7.327 ? 1.376 us/op StringCompare.compareUUDiffStrings 31 512 avgt 50 8.969 ? 1.311 us/op StringCompare.compareUUDiffStrings 63 512 avgt 50 13.482 ? 1.623 us/op StringCompare.compareUUDiffStrings 127 512 avgt 50 20.602 ? 1.495 us/op StringCompare.compareUUDiffStrings 255 512 avgt 50 37.906 ? 3.763 us/op StringCompare.compareUUDiffStrings 511 512 avgt 50 72.682 ? 6.374 us/op StringCompare.compareUUDiffStringsTurnOffCCP 7 512 avgt 50 6.638 ? 1.279 us/op StringCompare.compareUUDiffStringsTurnOffCCP 31 512 avgt 50 8.044 ? 0.924 us/op StringCompare.compareUUDiffStringsTurnOffCCP 63 512 avgt 50 12.921 ? 1.540 us/op StringCompare.compareUUDiffStringsTurnOffCCP 127 512 avgt 50 19.010 ? 1.333 us/op StringCompare.compareUUDiffStringsTurnOffCCP 255 512 avgt 50 36.326 ? 1.302 us/op StringCompare.compareUUDiffStringsTurnOffCCP 511 512 avgt 50 75.746 ? 3.786 us/op ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From wuyan at openjdk.java.net Thu Aug 5 02:43:40 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Thu, 5 Aug 2021 02:43:40 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v5] In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 03:27:49 GMT, Nick Gasson wrote: >> Wang Huang 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: >> >> - fix bugs >> - Merge branch 'master' of https://gitee.com/ustc-wh/jdk into JDK-8268231 >> - fix style and add unalign test case >> - refact codes >> - draft of refactor >> - 8268231: Aarch64: Use ldp in intrinsics for String.compareTo > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4892: > >> 4890: __ cmp(tmp1, tmp2); >> 4891: __ ccmp(tmp1h, tmp2h, 0, Assembler::EQ); >> 4892: __ br(__ NE, DIFF); > > The line above uses `Assembler::EQ` for the condition code but this line uses `__ NE`. Better to be consistent and use `Assembler::` everywhere. Thanks, I'll fix it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From mbaesken at openjdk.java.net Thu Aug 5 07:51:08 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 5 Aug 2021 07:51:08 GMT Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v7] In-Reply-To: References: Message-ID: > Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups. > > I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory" on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional , see the coding > > > if (!cg_infos[PIDS_IDX]._data_complete) { > log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); > // keep the other controller info, pids is optional > } Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8266490 - Minor adjustments, handling of Unlimited - Merge remote-tracking branch 'origin/master' into JDK-8266490 - Add hotspot tests - test and small adjustments suggested by Severin - Adjustments following Severins comments - JDK-8266490 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4518/files - new: https://git.openjdk.java.net/jdk/pull/4518/files/857ab1db..39b50089 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4518&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4518&range=05-06 Stats: 4915 lines in 198 files changed: 3503 ins; 507 del; 905 mod Patch: https://git.openjdk.java.net/jdk/pull/4518.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4518/head:pull/4518 PR: https://git.openjdk.java.net/jdk/pull/4518 From mbaesken at openjdk.java.net Thu Aug 5 11:21:59 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 5 Aug 2021 11:21:59 GMT Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v6] In-Reply-To: <7iBHbVtU_eX1kulxCimscf3qRO213qaZ8fyK2-_aJGA=.c6c9e083-e098-409f-9b8f-685cab8ff977@github.com> References: <80NDhQE20WOO7LMCDS9C9zYQIRy-YKqNiGgrPQAPI64=.ef6e55d9-8995-4669-9c6f-e10a61bd427f@github.com> <_CXJ5Lcpd7-PqzRzGAtEE4NyZzAGirYGSgVT7KbPyFw=.f2ce7164-7d28-4b6e-9a79-9417054e0113@github.com> <7iBHbVtU_eX1kulxCimscf3qRO213qaZ8fyK2-_aJGA=.c6c9e083-e098-409f-9b8f-685cab8ff977@github.com> Message-ID: On Mon, 2 Aug 2021 11:42:33 GMT, Severin Gehwolf wrote: > > What do you think about accepting, when setting -1/unlimited, a high limit number like 20.000+ as well (and and a comment that on some setups unlimited means just "high number" but not unlimited? > > This seems most reasonable. I'd suggest to accept a limit of `> 20000` or `Unlimited` in the test output. In case of it NOT being `Unlimited` for the `--pids-limit=-1` case, I'd also include the actual output in logs with a message that it got accepted as unlimited. > Hi Severin, I adjusted the tests so that in case of Unlimited, an integer value > 20000 is accepted as well. Hopefully this addresses the issues observed on your setup. Best regards, Matthias ------------- PR: https://git.openjdk.java.net/jdk/pull/4518 From mbaesken at openjdk.java.net Thu Aug 5 11:21:59 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 5 Aug 2021 11:21:59 GMT Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v8] In-Reply-To: References: Message-ID: > Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups. > > I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory" on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional , see the coding > > > if (!cg_infos[PIDS_IDX]._data_complete) { > log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); > // keep the other controller info, pids is optional > } Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust tests, unlimited pids value can lead on some setups to high number ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4518/files - new: https://git.openjdk.java.net/jdk/pull/4518/files/39b50089..0dd58e00 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4518&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4518&range=06-07 Stats: 68 lines in 2 files changed: 65 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4518.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4518/head:pull/4518 PR: https://git.openjdk.java.net/jdk/pull/4518 From alanb at openjdk.java.net Thu Aug 5 13:16:45 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 5 Aug 2021 13:16:45 GMT Subject: RFR: JDK-8271858: Handle to jimage file inherited into child processes (posix) In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 12:22:24 GMT, Thomas Stuefe wrote: > We should not leak the handle to the jimage file (lib/modules) to childs. > > JDK-8194734 did solve this for windows. We should use FD_CLOEXEC on Posix as well. > > Note that this only poses a problem when a child process is spawned off not via `Runtime.exec` but via another route since the spawnhelper closes all file descriptors. > > --- > test: > > manually verified that lib/modules now has the FD_CLOEXEC flag set. src/java.base/unix/native/libjimage/osSupport_unix.cpp line 41: > 39: */ > 40: jint osSupport::openReadOnly(const char *path) { > 41: return ::open(path, O_CLOEXEC); This is okay but I think it would be useful to know why this one place needs O_CLOEXEC and not others. ------------- PR: https://git.openjdk.java.net/jdk/pull/4991 From stuefe at openjdk.java.net Thu Aug 5 13:16:46 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 5 Aug 2021 13:16:46 GMT Subject: RFR: JDK-8271858: Handle to jimage file inherited into child processes (posix) In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 13:35:59 GMT, Alan Bateman wrote: >> We should not leak the handle to the jimage file (lib/modules) to childs. >> >> JDK-8194734 did solve this for windows. We should use FD_CLOEXEC on Posix as well. >> >> Note that this only poses a problem when a child process is spawned off not via `Runtime.exec` but via another route since the spawnhelper closes all file descriptors. >> >> --- >> test: >> >> manually verified that lib/modules now has the FD_CLOEXEC flag set. > > src/java.base/unix/native/libjimage/osSupport_unix.cpp line 41: > >> 39: */ >> 40: jint osSupport::openReadOnly(const char *path) { >> 41: return ::open(path, O_CLOEXEC); > > This is okay but I think it would be useful to know why this one place needs O_CLOEXEC and not others. Probably others too, if we care about inheriting read handles to child. The background is that I am playing with a new test which checks that the VM has no open inheritable file descriptors. It is supposed to replace some specialized tests which are maintenance-intensive. I am still tuning the test, since at the moment it turns out too many false positives. Anyway, this is the very first descriptor the VM opens, therefore it triggered my test. I thought since there is a sibling fix for windows, a similar fix for posix would be symmetric. If you think this is not worth fixing, or we should fix all occurrences in one swoop, that is fine too. ------------- PR: https://git.openjdk.java.net/jdk/pull/4991 From stuefe at openjdk.java.net Thu Aug 5 13:16:43 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 5 Aug 2021 13:16:43 GMT Subject: RFR: JDK-8271858: Handle to jimage file inherited into child processes (posix) Message-ID: We should not leak the handle to the jimage file (lib/modules) to childs. JDK-8194734 did solve this for windows. We should use FD_CLOEXEC on Posix as well. Note that this only poses a problem when a child process is spawned off not via `Runtime.exec` but via another route since the spawnhelper closes all file descriptors. --- test: manually verified that lib/modules now has the FD_CLOEXEC flag set. ------------- Commit messages: - open image file with O_CLOEXEC Changes: https://git.openjdk.java.net/jdk/pull/4991/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4991&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271858 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4991.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4991/head:pull/4991 PR: https://git.openjdk.java.net/jdk/pull/4991 From alanb at openjdk.java.net Thu Aug 5 13:16:46 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 5 Aug 2021 13:16:46 GMT Subject: RFR: JDK-8271858: Handle to jimage file inherited into child processes (posix) In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 17:04:38 GMT, Thomas Stuefe wrote: >> src/java.base/unix/native/libjimage/osSupport_unix.cpp line 41: >> >>> 39: */ >>> 40: jint osSupport::openReadOnly(const char *path) { >>> 41: return ::open(path, O_CLOEXEC); >> >> This is okay but I think it would be useful to know why this one place needs O_CLOEXEC and not others. > > Probably others too, if we care about inheriting read handles to child. > > The background is that I am playing with a new test which checks that the VM has no open inheritable file descriptors. It is supposed to replace some specialized tests which are maintenance-intensive. I am still tuning the test, since at the moment it turns out too many false positives. > > Anyway, this is the very first descriptor the VM opens, therefore it triggered my test. I thought since there is a sibling fix for windows, a similar fix for posix would be symmetric. > > If you think this is not worth fixing, or we should fix all occurrences in one swoop, that is fine too. On Unix systems, the JDK has always relied on the Runtime.exec implementation to close the file descriptors. On Windows the inheritance has to be disabled in the parent. So if the gtest launcher is forking directly then we may have a bit of whack-a-mole to change all the places that open file descriptors. ------------- PR: https://git.openjdk.java.net/jdk/pull/4991 From stuefe at openjdk.java.net Thu Aug 5 14:09:28 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 5 Aug 2021 14:09:28 GMT Subject: RFR: JDK-8271858: Handle to jimage file inherited into child processes (posix) In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 13:13:27 GMT, Alan Bateman wrote: >> Probably others too, if we care about inheriting read handles to child. >> >> The background is that I am playing with a new test which checks that the VM has no open inheritable file descriptors. It is supposed to replace some specialized tests which are maintenance-intensive. I am still tuning the test, since at the moment it turns out too many false positives. >> >> Anyway, this is the very first descriptor the VM opens, therefore it triggered my test. I thought since there is a sibling fix for windows, a similar fix for posix would be symmetric. >> >> If you think this is not worth fixing, or we should fix all occurrences in one swoop, that is fine too. > > On Unix systems, the JDK has always relied on the Runtime.exec implementation to close the file descriptors. On Windows the inheritance has to be disabled in the parent. So if the gtest launcher is forking directly then we may have a bit of whack-a-mole to change all the places that open file descriptors. My idea was born since we have jtreg tests that assert that certain VM internal fds, namely of log files, are not handed down to child processes. The motivation originally was Windows, since child processes would block that file from being moved. The test is done for both Unix and Windows, however. It is fragile and difficult to analyze when it fails. I wanted to throw away the Unix portion of that test and replace it with a simple gtest, either checking CLOEXEC for just that particular fd, or (my current approach) for all handles. But if what you are saying is how we do things - we don't bother with CLOEXEC, just rely on Runtime.exec() to close all fds, and accept the fact that "foreign" forks will cause us problems - then I could just throw the Unix portion of that test away without replacing it with anything. ATM the libs/module fd seems to be the only file descriptor tripping up my test though. Maybe it's not so bad. I am mainly afraid of situations where the gtestlauncher runs in some instrumented form, maybe with a virus scanner in its belly, with foreign code opening fds without our knowledge. I am still unsure about which direction to go. ------------- PR: https://git.openjdk.java.net/jdk/pull/4991 From jpai at openjdk.java.net Thu Aug 5 14:37:42 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 5 Aug 2021 14:37:42 GMT Subject: RFR: 8271208: Typo in ModuleDescriptor.read javadoc Message-ID: Can I please get a review of this trivial fix which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271208? Ran `make docs-image` locally and generated the new javadocs and the change looks fine. ------------- Commit messages: - 8271208: Typo in ModuleDescriptor.read javadoc Changes: https://git.openjdk.java.net/jdk/pull/5021/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5021&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271208 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5021.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5021/head:pull/5021 PR: https://git.openjdk.java.net/jdk/pull/5021 From alanb at openjdk.java.net Thu Aug 5 14:37:42 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 5 Aug 2021 14:37:42 GMT Subject: RFR: 8271208: Typo in ModuleDescriptor.read javadoc In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 14:28:30 GMT, Jaikiran Pai wrote: > Can I please get a review of this trivial fix which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271208? > > Ran `make docs-image` locally and generated the new javadocs and the change looks fine. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5021 From redestad at openjdk.java.net Thu Aug 5 14:49:31 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 5 Aug 2021 14:49:31 GMT Subject: RFR: 8271840: Add simple Integer.toString microbenchmarks In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 08:04:48 GMT, Aleksey Shipilev wrote: > Looks fine. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4988 From redestad at openjdk.java.net Thu Aug 5 14:49:32 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 5 Aug 2021 14:49:32 GMT Subject: Integrated: 8271840: Add simple Integer.toString microbenchmarks In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 07:46:48 GMT, Claes Redestad wrote: > This adds Integer.toString microbenchmarks, roughly similar to the Long.toString microbenchmarks (toStringSmall should use an equivalent data set). This is useful for comparison purposes and completeness. > > Also tuned existing benchmarks to harmonize setup, reduce runtime without significantly harming reliability of results, and remove the explicit Threads.MAX from Longs This pull request has now been integrated. Changeset: 55bd52a1 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/55bd52a14283033d66cd7bf1deadb31c040b09c7 Stats: 43 lines in 2 files changed: 33 ins; 3 del; 7 mod 8271840: Add simple Integer.toString microbenchmarks Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/4988 From sgehwolf at openjdk.java.net Thu Aug 5 14:56:35 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 5 Aug 2021 14:56:35 GMT Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v6] In-Reply-To: References: <80NDhQE20WOO7LMCDS9C9zYQIRy-YKqNiGgrPQAPI64=.ef6e55d9-8995-4669-9c6f-e10a61bd427f@github.com> <_CXJ5Lcpd7-PqzRzGAtEE4NyZzAGirYGSgVT7KbPyFw=.f2ce7164-7d28-4b6e-9a79-9417054e0113@github.com> <7iBHbVtU_eX1kulxCimscf3qRO213qaZ8fyK2-_aJGA=.c6c9e083-e098-409f-9b8f-685cab8ff977@github.com> Message-ID: On Thu, 5 Aug 2021 11:19:17 GMT, Matthias Baesken wrote: >>> What do you think about accepting, when setting -1/unlimited, a high limit number like 20.000+ as well (and and a comment that on some setups unlimited means just "high number" but not unlimited? >> >> This seems most reasonable. I'd suggest to accept a limit of `> 20000` or `Unlimited` in the test output. In case of it NOT being `Unlimited` for the `--pids-limit=-1` case, I'd also include the actual output in logs with a message that it got accepted as unlimited. >> >>> Another Idea I had was to start a little test java program that creates e.g. 50.000 (or another high number) of threads. If this fails with "unilimited" pids-limit set, we might have a setup like yours and then skip the test (or accept a high number like I suggested). >> >> This seems overkill and prone to failures, IMHO. > >> > What do you think about accepting, when setting -1/unlimited, a high limit number like 20.000+ as well (and and a comment that on some setups unlimited means just "high number" but not unlimited? >> >> This seems most reasonable. I'd suggest to accept a limit of `> 20000` or `Unlimited` in the test output. In case of it NOT being `Unlimited` for the `--pids-limit=-1` case, I'd also include the actual output in logs with a message that it got accepted as unlimited. >> > > Hi Severin, I adjusted the tests so that in case of Unlimited, an integer value > 20000 is accepted as well. > Hopefully this addresses the issues observed on your setup. > Best regards, Matthias @MBaesken Thanks. I'll test it and will report back. ------------- PR: https://git.openjdk.java.net/jdk/pull/4518 From iris at openjdk.java.net Thu Aug 5 15:17:28 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 5 Aug 2021 15:17:28 GMT Subject: RFR: 8271208: Typo in ModuleDescriptor.read javadoc In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 14:28:30 GMT, Jaikiran Pai wrote: > Can I please get a review of this trivial fix which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271208? > > Ran `make docs-image` locally and generated the new javadocs and the change looks fine. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5021 From herrick at openjdk.java.net Thu Aug 5 17:07:13 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 5 Aug 2021 17:07:13 GMT Subject: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. [v2] In-Reply-To: References: Message-ID: > 8271868: Warn user when using mac-sign option with unsigned app-image. Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: JDK-8271868: Warn user when using mac-sign option with unsigned app-image. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5004/files - new: https://git.openjdk.java.net/jdk/pull/5004/files/153e75ea..afc0f197 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5004&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5004&range=00-01 Stats: 72 lines in 6 files changed: 30 ins; 27 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/5004.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5004/head:pull/5004 PR: https://git.openjdk.java.net/jdk/pull/5004 From herrick at openjdk.java.net Thu Aug 5 17:12:30 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 5 Aug 2021 17:12:30 GMT Subject: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. [v2] In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 17:07:13 GMT, Andy Herrick wrote: >> 8271868: Warn user when using mac-sign option with unsigned app-image. > > Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8271868: Warn user when using mac-sign option with unsigned app-image. now recording in AppImageFile if signing used to create the app-image, and showing warning only if signing an app using an app-image that is not so recorded as signed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5004 From mark.reinhold at oracle.com Thu Aug 5 17:59:02 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 5 Aug 2021 10:59:02 -0700 (PDT) Subject: New candidate JEP: 416: Reimplement Core Reflection with Method Handles Message-ID: <20210805175902.A4E823EE0CD@eggemoggin.niobe.net> https://openjdk.java.net/jeps/416 Summary: Reimplement java.lang.reflect.Method, Constructor, and Field on top of java.lang.invoke method handles. Making method handles the underlying mechanism for reflection will reduce the maintenance and development cost of both the java.lang.reflect and java.lang.invoke APIs. - Mark From asemenyuk at openjdk.java.net Thu Aug 5 18:18:36 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 5 Aug 2021 18:18:36 GMT Subject: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. [v2] In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 17:07:13 GMT, Andy Herrick wrote: >> 8271868: Warn user when using mac-sign option with unsigned app-image. > > Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8271868: Warn user when using mac-sign option with unsigned app-image. Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5004 From herrick at openjdk.java.net Thu Aug 5 18:49:33 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 5 Aug 2021 18:49:33 GMT Subject: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. [v2] In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 17:07:13 GMT, Andy Herrick wrote: >> 8271868: Warn user when using mac-sign option with unsigned app-image. > > Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8271868: Warn user when using mac-sign option with unsigned app-image. will fix this spelling error ------------- PR: https://git.openjdk.java.net/jdk/pull/5004 From bpb at openjdk.java.net Thu Aug 5 18:57:42 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 5 Aug 2021 18:57:42 GMT Subject: RFR: 8271225: Add floorDivExact() method to java.lang.[Strict]Math [v3] In-Reply-To: References: Message-ID: > Add methods `floorDivExact(int,int)` and `floorDivExact(long,long)` to `java.lang.Math` and `java.lang.StrictMath`. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - 8271225: Verbiage update after 8271599 - Merge - 8271225: Revert drive-by verbiage updates - 8271225: Some verbiage updates - 8271225: Add floorDivExact() method to java.lang.[Strict]Math ------------- Changes: https://git.openjdk.java.net/jdk/pull/4941/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4941&range=02 Stats: 205 lines in 3 files changed: 202 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4941.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4941/head:pull/4941 PR: https://git.openjdk.java.net/jdk/pull/4941 From github.com+11281461+danielpeintner at openjdk.java.net Thu Aug 5 19:00:34 2021 From: github.com+11281461+danielpeintner at openjdk.java.net (danielpeintner) Date: Thu, 5 Aug 2021 19:00:34 GMT Subject: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. [v2] In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 17:07:13 GMT, Andy Herrick wrote: >> 8271868: Warn user when using mac-sign option with unsigned app-image. > > Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8271868: Warn user when using mac-sign option with unsigned app-image. src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java line 142: > 140: SIGN_BUNDLE.fetchFrom(params)).orElse(Boolean.FALSE)) { > 141: // if signing bundle with app-image, warn user if app-image > 142: // is not allready signed. nitpicking: typo "allready" -> "already" ------------- PR: https://git.openjdk.java.net/jdk/pull/5004 From bpb at openjdk.java.net Thu Aug 5 19:12:32 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 5 Aug 2021 19:12:32 GMT Subject: RFR: 8271225: Add floorDivExact() method to java.lang.[Strict]Math [v3] In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 18:57:42 GMT, Brian Burkhalter wrote: >> Add methods `floorDivExact(int,int)` and `floorDivExact(long,long)` to `java.lang.Math` and `java.lang.StrictMath`. > > Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - 8271225: Verbiage update after 8271599 > - Merge > - 8271225: Revert drive-by verbiage updates > - 8271225: Some verbiage updates > - 8271225: Add floorDivExact() method to java.lang.[Strict]Math CSR updated to match this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4941 From jjg at openjdk.java.net Thu Aug 5 19:26:50 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 5 Aug 2021 19:26:50 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 Message-ID: Please review a semi-automatic update of the nroff man pages from the upstream files. ------------- Commit messages: - JDK-8270872: Final nroff manpage update for JDK 17 Changes: https://git.openjdk.java.net/jdk17/pull/303/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=303&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270872 Stats: 289 lines in 27 files changed: 117 ins; 31 del; 141 mod Patch: https://git.openjdk.java.net/jdk17/pull/303.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/303/head:pull/303 PR: https://git.openjdk.java.net/jdk17/pull/303 From darcy at openjdk.java.net Thu Aug 5 19:44:37 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 5 Aug 2021 19:44:37 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons wrote: > Please review a semi-automatic update of the nroff man pages from the upstream files. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From naoto at openjdk.java.net Thu Aug 5 20:01:37 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 5 Aug 2021 20:01:37 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: References: Message-ID: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com> On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons wrote: > Please review a semi-automatic update of the nroff man pages from the upstream files. src/jdk.hotspot.agent/share/man/jhsdb.1 line 1: > 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved. This seems not correct? ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From mr at openjdk.java.net Thu Aug 5 20:13:39 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Thu, 5 Aug 2021 20:13:39 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons wrote: > Please review a semi-automatic update of the nroff man pages from the upstream files. Marked as reviewed by mr (Lead). ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From iris at openjdk.java.net Thu Aug 5 20:40:40 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 5 Aug 2021 20:40:40 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons wrote: > Please review a semi-automatic update of the nroff man pages from the upstream files. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From jjg at openjdk.java.net Thu Aug 5 21:39:38 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 5 Aug 2021 21:39:38 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com> References: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com> Message-ID: <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com> On Thu, 5 Aug 2021 19:57:59 GMT, Naoto Sato wrote: >> Please review a semi-automatic update of the nroff man pages from the upstream files. > > src/jdk.hotspot.agent/share/man/jhsdb.1 line 1: > >> 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved. > > This seems not correct? According to the comments in the makefile (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the original Markdown file, so if the year is wrong there, it will be wrong in the generated nroff file. I think it would be incorrect to edit the dates locally in these files, because they'll just be overwritten when we generate the files again. Ideally, the dates should be fixed (if necessary) in the Markdown files, but that seems out of scope for this P1. This is "just" an issue with copyright dates in source files ... and yes, while I know copyright dates are important, this problem is arguably part of an ongoing more general problem. I note that the generated files *do* correctly identify themselves with `2021` in the visible output generated to the console by the `man` command. ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From naoto at openjdk.java.net Thu Aug 5 21:44:35 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 5 Aug 2021 21:44:35 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons wrote: > Please review a semi-automatic update of the nroff man pages from the upstream files. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From naoto at openjdk.java.net Thu Aug 5 21:44:36 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 5 Aug 2021 21:44:36 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com> References: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com> <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com> Message-ID: On Thu, 5 Aug 2021 21:36:58 GMT, Jonathan Gibbons wrote: >> src/jdk.hotspot.agent/share/man/jhsdb.1 line 1: >> >>> 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved. >> >> This seems not correct? > > According to the comments in the makefile (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the original Markdown file, so if the year is wrong there, it will be wrong in the generated nroff file. > > I think it would be incorrect to edit the dates locally in these files, because they'll just be overwritten when we generate the files again. Ideally, the dates should be fixed (if necessary) in the Markdown files, but that seems out of scope for this P1. > > This is "just" an issue with copyright dates in source files ... and yes, while I know copyright dates are important, this problem is arguably part of an ongoing more general problem. > > I note that the generated files *do* correctly identify themselves with `2021` in the visible output generated to the console by the `man` command. Thanks for the explanation, Jon. Fine by me. ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From mr at openjdk.java.net Thu Aug 5 21:44:36 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Thu, 5 Aug 2021 21:44:36 GMT Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: References: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com> <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com> Message-ID: On Thu, 5 Aug 2021 21:40:40 GMT, Naoto Sato wrote: >> According to the comments in the makefile (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the original Markdown file, so if the year is wrong there, it will be wrong in the generated nroff file. >> >> I think it would be incorrect to edit the dates locally in these files, because they'll just be overwritten when we generate the files again. Ideally, the dates should be fixed (if necessary) in the Markdown files, but that seems out of scope for this P1. >> >> This is "just" an issue with copyright dates in source files ... and yes, while I know copyright dates are important, this problem is arguably part of an ongoing more general problem. >> >> I note that the generated files *do* correctly identify themselves with `2021` in the visible output generated to the console by the `man` command. > > Thanks for the explanation, Jon. Fine by me. I agree that fixing this date is not necessary at this time. ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From jjg at openjdk.java.net Thu Aug 5 22:15:29 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 5 Aug 2021 22:15:29 GMT Subject: [jdk17] Integrated: JDK-8270872: Final nroff manpage update for JDK 17 In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons wrote: > Please review a semi-automatic update of the nroff man pages from the upstream files. This pull request has now been integrated. Changeset: dfacda48 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk17/commit/dfacda488bfbe2e11e8d607a6d08527710286982 Stats: 289 lines in 27 files changed: 117 ins; 31 del; 141 mod 8270872: Final nroff manpage update for JDK 17 Reviewed-by: darcy, mr, iris, naoto ------------- PR: https://git.openjdk.java.net/jdk17/pull/303 From almatvee at openjdk.java.net Thu Aug 5 22:32:30 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 5 Aug 2021 22:32:30 GMT Subject: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. [v2] In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 17:07:13 GMT, Andy Herrick wrote: >> 8271868: Warn user when using mac-sign option with unsigned app-image. > > Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8271868: Warn user when using mac-sign option with unsigned app-image. Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5004 From jwilhelm at openjdk.java.net Thu Aug 5 23:57:59 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 5 Aug 2021 23:57:59 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8270872: Final nroff manpage update for JDK 17 - 8271588: JFR Recorder Thread crashed with SIGSEGV in write_klass - 8271863: ProblemList serviceability/sa/TestJmapCore.java on linux-x64 with ZGC The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=5026&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=5026&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/5026/files Stats: 307 lines in 32 files changed: 129 ins; 33 del; 145 mod Patch: https://git.openjdk.java.net/jdk/pull/5026.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5026/head:pull/5026 PR: https://git.openjdk.java.net/jdk/pull/5026 From mchung at openjdk.java.net Fri Aug 6 00:12:47 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 6 Aug 2021 00:12:47 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle Message-ID: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> This reimplements core reflection with method handles. For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. Ran tier1-tier8 tests. [1] https://bugs.openjdk.java.net/browse/JDK-8013527 [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 ------------- Commit messages: - fix whitespace - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - Merge - clean up test - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - cleanup - Merge branch 'master' of https://github.com/openjdk/jdk into reimplement-method-invoke - fix ClassByteBuilder to handle short field type properly. Support volatile fields - minor cleanup - ... and 5 more: https://git.openjdk.java.net/jdk/compare/cb368802...c575c3db Changes: https://git.openjdk.java.net/jdk/pull/5027/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271820 Stats: 7572 lines in 75 files changed: 7103 ins; 288 del; 181 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027 From jwilhelm at openjdk.java.net Fri Aug 6 01:27:33 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 6 Aug 2021 01:27:33 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 23:49:48 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: 14692d5e Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/14692d5ed0652b867fcf28baafa498a9441683ac Stats: 307 lines in 32 files changed: 129 ins; 33 del; 145 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/5026 From jwilhelm at openjdk.java.net Fri Aug 6 01:27:32 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 6 Aug 2021 01:27:32 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: References: Message-ID: <1oUovSIU_RoljyN5VHPljZLMI5NpHqK3ys9BDhsuLI8=.15d53c62-802e-4982-9415-527c302b8ab4@github.com> > Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 440 commits: - Merge - 8271293: Monitor class should use ThreadBlockInVMPreprocess Reviewed-by: dholmes, dcubed - 8270116: Expand ButtonGroupLayoutTraversalTest.java to run in all LaFs, including Aqua on macOS Reviewed-by: psadhukhan, aivanov - 8271905: mark hotspot runtime/Metaspace tests which ignore external VM flags Reviewed-by: stuefe - 8271308: (fc) FileChannel.transferTo() transfers no more than Integer.MAX_VALUE bytes in one call Reviewed-by: alanb, vtewari - 8271953: fix mis-merge in JDK-8271878 Reviewed-by: jwilhelm, ctornqvi - 8267840: Improve URLStreamHandler.parseURL() Reviewed-by: dfuchs, redestad - 8271840: Add simple Integer.toString microbenchmarks Reviewed-by: shade - 8271121: ZGC: stack overflow (segv) when -Xlog:gc+start=debug Reviewed-by: ayang, eosterlund - 8270903: sun.net.httpserver.HttpConnection: Improve toString Reviewed-by: chegar, vtewari - ... and 430 more: https://git.openjdk.java.net/jdk/compare/dfacda48...7e069880 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5026/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5026&range=01 Stats: 97370 lines in 1522 files changed: 61891 ins; 27834 del; 7645 mod Patch: https://git.openjdk.java.net/jdk/pull/5026.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5026/head:pull/5026 PR: https://git.openjdk.java.net/jdk/pull/5026 From jpai at openjdk.java.net Fri Aug 6 01:34:33 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 6 Aug 2021 01:34:33 GMT Subject: RFR: 8271208: Typo in ModuleDescriptor.read javadoc In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 14:28:30 GMT, Jaikiran Pai wrote: > Can I please get a review of this trivial fix which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271208? > > Ran `make docs-image` locally and generated the new javadocs and the change looks fine. Thank you for the reviews, Alan and Iris. ------------- PR: https://git.openjdk.java.net/jdk/pull/5021 From jpai at openjdk.java.net Fri Aug 6 01:34:34 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 6 Aug 2021 01:34:34 GMT Subject: Integrated: 8271208: Typo in ModuleDescriptor.read javadoc In-Reply-To: References: Message-ID: <-V43Kbcm4eRq5wFH_GjjgCKKGfq4v1EXUmhcuVHaw1k=.0d216e69-14cf-40a5-9963-980cd547905d@github.com> On Thu, 5 Aug 2021 14:28:30 GMT, Jaikiran Pai wrote: > Can I please get a review of this trivial fix which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271208? > > Ran `make docs-image` locally and generated the new javadocs and the change looks fine. This pull request has now been integrated. Changeset: e38e365c Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/e38e365c70197f7e45d8bdc7d6c2e3c59717369e Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8271208: Typo in ModuleDescriptor.read javadoc Reviewed-by: alanb, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/5021 From sgehwolf at openjdk.java.net Fri Aug 6 08:32:30 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 6 Aug 2021 08:32:30 GMT Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v8] In-Reply-To: References: Message-ID: <4Q9NnQH4-CV3Q5F1yGFSZTjRMPpvsnqRFzIZD46C-cM=.2498df3e-ceb8-47a1-9381-019f7b980c75@github.com> On Thu, 5 Aug 2021 11:21:59 GMT, Matthias Baesken wrote: >> Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups. >> >> I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory" on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional , see the coding >> >> >> if (!cg_infos[PIDS_IDX]._data_complete) { >> log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); >> // keep the other controller info, pids is optional >> } > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust tests, unlimited pids value can lead on some setups to high number This looks good to me now and passes tests on my cgroup v1 and cgroup v2 setups. test/hotspot/jtreg/containers/docker/TestPids.java line 130: > 128: opts.addDockerOpts("--pids-limit=-1"); > 129: } else { > 130: opts.addDockerOpts("--pids-limit="+value); Style nit: Space before and after `+`. test/jdk/jdk/internal/platform/docker/TestPidsLimit.java line 111: > 109: opts.addDockerOpts("--pids-limit=-1"); > 110: } else { > 111: opts.addDockerOpts("--pids-limit="+pidsLimit); Style nit: Space before and after `+`. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4518 From whuang at openjdk.java.net Fri Aug 6 09:50:54 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 6 Aug 2021 09:50:54 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v6] In-Reply-To: References: Message-ID: > Dear all, > Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo. > > * We add a JMH test case > * Here is the result of this test case > > Benchmark |(size)| Mode| Cnt|Score | Error |Units > ---------------------------------|------|-----|----|------|--------|----- > StringCompare.compareLL | 64 | avgt| 5 |7.992 | ? 0.005|us/op > StringCompare.compareLL | 72 | avgt| 5 |15.029| ? 0.006|us/op > StringCompare.compareLL | 80 | avgt| 5 |14.655| ? 0.011|us/op > StringCompare.compareLL | 91 | avgt| 5 |16.363| ? 0.12 |us/op > StringCompare.compareLL | 101 | avgt| 5 |16.966| ? 0.007|us/op > StringCompare.compareLL | 121 | avgt| 5 |19.276| ? 0.006|us/op > StringCompare.compareLL | 181 | avgt| 5 |19.002| ? 0.417|us/op > StringCompare.compareLL | 256 | avgt| 5 |24.707| ? 0.041|us/op > StringCompare.compareLLWithLdp| 64 | avgt| 5 |8.001 | ? 0.121|us/op > StringCompare.compareLLWithLdp| 72 | avgt| 5 |11.573| ? 0.003|us/op > StringCompare.compareLLWithLdp| 80 | avgt| 5 |6.861 | ? 0.004|us/op > StringCompare.compareLLWithLdp| 91 | avgt| 5 |12.774| ? 0.201|us/op > StringCompare.compareLLWithLdp| 101 | avgt| 5 |8.691 | ? 0.004|us/op > StringCompare.compareLLWithLdp| 121 | avgt| 5 |11.091| ? 1.342|us/op > StringCompare.compareLLWithLdp| 181 | avgt| 5 |14.64 | ? 0.581|us/op > StringCompare.compareLLWithLdp| 256 | avgt| 5 |25.879| ? 1.775|us/op > StringCompare.compareUU | 64 | avgt| 5 |13.476| ? 0.01 |us/op > StringCompare.compareUU | 72 | avgt| 5 |15.078| ? 0.006|us/op > StringCompare.compareUU | 80 | avgt| 5 |23.512| ? 0.011|us/op > StringCompare.compareUU | 91 | avgt| 5 |24.284| ? 0.008|us/op > StringCompare.compareUU | 101 | avgt| 5 |20.707| ? 0.017|us/op > StringCompare.compareUU | 121 | avgt| 5 |29.302| ? 0.011|us/op > StringCompare.compareUU | 181 | avgt| 5 |39.31 | ? 0.016|us/op > StringCompare.compareUU | 256 | avgt| 5 |54.592| ? 0.392|us/op > StringCompare.compareUUWithLdp| 64 | avgt| 5 |16.389| ? 0.008|us/op > StringCompare.compareUUWithLdp| 72 | avgt| 5 |10.71 | ? 0.158|us/op > StringCompare.compareUUWithLdp| 80 | avgt| 5 |11.488| ? 0.024|us/op > StringCompare.compareUUWithLdp| 91 | avgt| 5 |13.412| ? 0.006|us/op > StringCompare.compareUUWithLdp| 101 | avgt| 5 |16.245| ? 0.434|us/op > StringCompare.compareUUWithLdp| 121 | avgt| 5 |16.597| ? 0.016|us/op > StringCompare.compareUUWithLdp| 181 | avgt| 5 |27.373| ? 0.017|us/op > StringCompare.compareUUWithLdp| 256 | avgt| 5 |41.74 | ? 3.5 |us/op > > From this table, we can see that in most cases, our patch is better than old one. > > Thank you for your review. Any suggestions are welcome. Wang Huang has updated the pull request incrementally with one additional commit since the last revision: fix codestyle ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4722/files - new: https://git.openjdk.java.net/jdk/pull/4722/files/60dd0516..2f756261 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4722&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4722&range=04-05 Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4722/head:pull/4722 PR: https://git.openjdk.java.net/jdk/pull/4722 From mbaesken at openjdk.java.net Fri Aug 6 10:29:28 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 6 Aug 2021 10:29:28 GMT Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v8] In-Reply-To: <4Q9NnQH4-CV3Q5F1yGFSZTjRMPpvsnqRFzIZD46C-cM=.2498df3e-ceb8-47a1-9381-019f7b980c75@github.com> References: <4Q9NnQH4-CV3Q5F1yGFSZTjRMPpvsnqRFzIZD46C-cM=.2498df3e-ceb8-47a1-9381-019f7b980c75@github.com> Message-ID: On Fri, 6 Aug 2021 08:29:50 GMT, Severin Gehwolf wrote: > This looks good to me now and passes tests on my cgroup v1 and cgroup v2 setups. Thanks for the review and approval . Best regards, Matthias ------------- PR: https://git.openjdk.java.net/jdk/pull/4518 From herrick at openjdk.java.net Fri Aug 6 12:28:31 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 6 Aug 2021 12:28:31 GMT Subject: Integrated: 8271868: Warn user when using mac-sign option with unsigned app-image. In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 20:00:37 GMT, Andy Herrick wrote: > 8271868: Warn user when using mac-sign option with unsigned app-image. This pull request has now been integrated. Changeset: 0aca4f72 Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/0aca4f72ce48bc75f2c466d1cba4ad70d3c7b875 Stats: 65 lines in 9 files changed: 46 ins; 11 del; 8 mod 8271868: Warn user when using mac-sign option with unsigned app-image. Reviewed-by: almatvee, asemenyuk ------------- PR: https://git.openjdk.java.net/jdk/pull/5004 From alanb at openjdk.java.net Fri Aug 6 13:25:28 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 6 Aug 2021 13:25:28 GMT Subject: RFR: JDK-8271858: Handle to jimage file inherited into child processes (posix) In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 14:06:17 GMT, Thomas Stuefe wrote: >> On Unix systems, the JDK has always relied on the Runtime.exec implementation to close the file descriptors. On Windows the inheritance has to be disabled in the parent. So if the gtest launcher is forking directly then we may have a bit of whack-a-mole to change all the places that open file descriptors. > > My idea was born since we have jtreg tests that assert that certain VM internal fds, namely of log files, are not handed down to child processes. The motivation originally was Windows, since child processes would block that file from being moved. The test is done for both Unix and Windows, however. It is fragile and difficult to analyze when it fails. I wanted to throw away the Unix portion of that test and replace it with a simple gtest, either checking CLOEXEC for just that particular fd, or (my current approach) for all handles. > > But if what you are saying is how we do things - we don't bother with CLOEXEC, just rely on Runtime.exec() to close all fds, and accept the fact that "foreign" forks will cause us problems - then I could just throw the Unix portion of that test away without replacing it with anything. > > ATM the libs/module fd seems to be the only file descriptor tripping up my test though. Maybe it's not so bad. I am mainly afraid of situations where the gtestlauncher runs in some instrumented form, maybe with a virus scanner in its belly, with foreign code opening fds without our knowledge. I am still unsure about which direction to go. lib/modules is opened/mapped early in the startup so I assume this is why this one shows up quickly. Adding O_CLOEXEC everywhere is open, up you if you want to do that or switch it to Runtime.exec. ------------- PR: https://git.openjdk.java.net/jdk/pull/4991 From dcubed at openjdk.java.net Fri Aug 6 13:42:44 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 6 Aug 2021 13:42:44 GMT Subject: Integrated: 8272095: ProblemList java/nio/channels/FileChannel/Transfer2GPlus.java on linux-aarch64 In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 13:34:37 GMT, Alan Bateman wrote: >> A trivial fix to ProblemList java/nio/channels/FileChannel/Transfer2GPlus.java on linux-aarch64 > > Marked as reviewed by alanb (Reviewer). @AlanBateman - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/5032 From alanb at openjdk.java.net Fri Aug 6 13:42:44 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 6 Aug 2021 13:42:44 GMT Subject: Integrated: 8272095: ProblemList java/nio/channels/FileChannel/Transfer2GPlus.java on linux-aarch64 In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 13:32:00 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/nio/channels/FileChannel/Transfer2GPlus.java on linux-aarch64 Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5032 From dcubed at openjdk.java.net Fri Aug 6 13:42:44 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 6 Aug 2021 13:42:44 GMT Subject: Integrated: 8272095: ProblemList java/nio/channels/FileChannel/Transfer2GPlus.java on linux-aarch64 Message-ID: A trivial fix to ProblemList java/nio/channels/FileChannel/Transfer2GPlus.java on linux-aarch64 ------------- Commit messages: - 8272095: ProblemList java/nio/channels/FileChannel/Transfer2GPlus.java on linux-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/5032/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5032&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272095 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5032.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5032/head:pull/5032 PR: https://git.openjdk.java.net/jdk/pull/5032 From dcubed at openjdk.java.net Fri Aug 6 13:42:45 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 6 Aug 2021 13:42:45 GMT Subject: Integrated: 8272095: ProblemList java/nio/channels/FileChannel/Transfer2GPlus.java on linux-aarch64 In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 13:32:00 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/nio/channels/FileChannel/Transfer2GPlus.java on linux-aarch64 This pull request has now been integrated. Changeset: f4cf2f7c Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/f4cf2f7cef6c09c16d714f08505327edd7032604 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8272095: ProblemList java/nio/channels/FileChannel/Transfer2GPlus.java on linux-aarch64 Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5032 From naoto at openjdk.java.net Fri Aug 6 16:45:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 6 Aug 2021 16:45:41 GMT Subject: RFR: 8264792: The NumberFormat for locale sq_XK formats price incorrectly. Message-ID: Please review the fix to the subject issue. The root cause of this problem is that the currency for the country code `XK` is undefined because the country code is user-defined in the ISO 3166 standard. However, it is commonly used to represent the region `Kosovo`, which CLDR supports and subsequently is supported by the JDK since JDK9. Adding the data `EUR` for the country code `XK` will fix the issue. ------------- Commit messages: - 8264792: The NumberFormat for locale sq_XK formats price incorrectly. Changes: https://git.openjdk.java.net/jdk/pull/5033/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5033&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264792 Stats: 13 lines in 3 files changed: 6 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5033.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5033/head:pull/5033 PR: https://git.openjdk.java.net/jdk/pull/5033 From joehw at openjdk.java.net Fri Aug 6 17:31:33 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 6 Aug 2021 17:31:33 GMT Subject: RFR: 8264792: The NumberFormat for locale sq_XK formats price incorrectly. In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 16:39:34 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. The root cause of this problem is that the currency for the country code `XK` is undefined because the country code is user-defined in the ISO 3166 standard. However, it is commonly used to represent the region `Kosovo`, which CLDR supports and subsequently is supported by the JDK since JDK9. Adding the data `EUR` for the country code `XK` will fix the issue. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5033 From iris at openjdk.java.net Fri Aug 6 21:09:28 2021 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 6 Aug 2021 21:09:28 GMT Subject: RFR: 8264792: The NumberFormat for locale sq_XK formats price incorrectly. In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 16:39:34 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. The root cause of this problem is that the currency for the country code `XK` is undefined because the country code is user-defined in the ISO 3166 standard. However, it is commonly used to represent the region `Kosovo`, which CLDR supports and subsequently is supported by the JDK since JDK9. Adding the data `EUR` for the country code `XK` will fix the issue. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5033 From mchung at openjdk.java.net Sat Aug 7 02:07:24 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Sat, 7 Aug 2021 02:07:24 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v2] In-Reply-To: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: > This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. > > The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. > > The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: minor test cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5027/files - new: https://git.openjdk.java.net/jdk/pull/5027/files/c575c3db..b73a6faf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=00-01 Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027 From github.com+1701815+mkarg at openjdk.java.net Sat Aug 7 06:48:34 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sat, 7 Aug 2021 06:48:34 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: Message-ID: <5v2JxcXvfhlsA_lPDTS1u7LQul5S12tNrFHtN3lmnK8=.0186f02f-6537-4ae6-beda-a4268bc047a9@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 I think I fixed all requested changes. Anymore comments on this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From plevart at openjdk.java.net Sat Aug 7 08:39:29 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Sat, 7 Aug 2021 08:39:29 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v2] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Sat, 7 Aug 2021 02:07:24 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor test cleanup Hi Mandy, Quite a big change this has become. Good work! These are just preliminary observations. I'll try to do a more in-depth check in a week since I'm off on vacation in the coming week. I noticed there's a lot of complication due to logic that specializes the cases for small number of parameters via indirection through MHMethodAccessorDelegate just to avoid spreading the arguments of an Object[] array via the MH combinator asSpreader. Does this really bring noticeable performance improvement for the small number of arguments? I'm asking because the arguments in reflection API are already boxed and packed into an Object[] array and my feeling tells me that spreading them via MH combinator should have similar performance as doing that manually in the switch of DirectMethodAccessorImpl.XXX#invokeImpl methods. I may be wrong. If MH combinator is noticeably slower, I think it should be fixed. Another brittle part in my opinion is the AccessorUtils.isIllegalArgument method and the use of it in logic to determine where the caught exception comes from to wrap it in the correct type of exception for the reflection API. The logic of that method is based on assumptions of how a lot of other code is structured. Any change to the structure of that code can brake that logic. I liked the solution used in previous iterations where an exception handler was inserted in the MH chain immediately after the DMH which wrapped any Throwable into InvocationTargetException. So any naked exceptions thrown from MH chain could be contributed to argument processing. Why did you choose another route? Regards, Peter ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From mchung at openjdk.java.net Sat Aug 7 19:52:27 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Sat, 7 Aug 2021 19:52:27 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v2] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Sat, 7 Aug 2021 02:07:24 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor test cleanup Hi Peter, I also like the previous simpler version as much as you do. However, both of these complications are done for the performance that I worked with @cl4es on these changes. Claes can explain and provide additional data w.r.t. the cost in the `catchException` and `asSpreader` he observes. A few observations from the performance analysis are the following: 1. The `catchException` combination is costly for setup. 2. Funneling the target method handle through `MethodHandles::asSpreader` costs another overhead. Dropping the `catchException` and specializing for a few arguments improve the cold startup for ~3x when measuring with `ReflectionColdstartBenchmark` you had [1]. Specializing to remove the asSpreader combinator also improves slightly on the throughtput. Claes can say more about the performance improvement without the spreader. 3. Splitting the virtual and static methods also improve on the throughtput. `isIllegalArgument` is not ideal but I found it acceptable as the solution for this work because it's on the exception case and depends on the implementation of core reflection and method handle exception when types mismatch. We also have tests to validate these cases. I think we should look into longer-term solution in reducing the overhead of the combinators that will benefit not only the core reflection code but also the clients of method handles. [1] http://cr.openjdk.java.net/~plevart/jdk-dev/6824466_MHReflectionAccessors/ReflectionColdstartBenchmark.java ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From redestad at openjdk.java.net Sat Aug 7 20:56:29 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Sat, 7 Aug 2021 20:56:29 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v2] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Sat, 7 Aug 2021 02:07:24 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor test cleanup Great to see this come along! It's been a while since I worked on this (I've been on parental leave for a couple of months), but I plan to do a full review, re-run all benchmarks and verify that performance is where we want it to be. So I don't have much details to add to this as of right now. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From github.com+741251+turbanoff at openjdk.java.net Mon Aug 9 07:19:35 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 9 Aug 2021 07:19:35 GMT Subject: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 19:55:09 GMT, Brett Okken wrote: >> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. >> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/SystemDictionaryHelper.java line 92: > >> 90: } >> 91: >> 92: InstanceKlass[] searchResult = tmp.toArray(new InstanceKlass[0]); > > Is it too far outside the scope of these changes to make `tmp` an `ArrayList` rather than a `Vector`? I'll create separate PRs to migrate Vector usages to ArrayList. ------------- PR: https://git.openjdk.java.net/jdk/pull/4487 From github.com+741251+turbanoff at openjdk.java.net Mon Aug 9 07:22:32 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 9 Aug 2021 07:22:32 GMT Subject: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 19:15:55 GMT, Brett Okken wrote: >> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. >> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. > > src/java.base/share/classes/java/security/Security.java line 656: > >> 654: return null; >> 655: >> 656: return candidates.toArray(new Provider[0]); > > Is this called often enough to warrant creating a constant of `new Provider[0]` (benefits of this covered in the _Wisdom of the Ancients_ blog linked)? May be yes, may be not. I like `0`-sized array approach more. 1. It looks clearer and easier to read 2. It should be faster than original code anyway ------------- PR: https://git.openjdk.java.net/jdk/pull/4487 From lucy at openjdk.java.net Mon Aug 9 12:57:32 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 9 Aug 2021 12:57:32 GMT Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v8] In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 11:21:59 GMT, Matthias Baesken wrote: >> Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups. >> >> I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory" on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional , see the coding >> >> >> if (!cg_infos[PIDS_IDX]._data_complete) { >> log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); >> // keep the other controller info, pids is optional >> } > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust tests, unlimited pids value can lead on some setups to high number The changes look good to me. I have one question/suggestion re. copyright comments. The files test/hotspot/jtreg/containers/docker/TestPids.java and test/jdk/jdk/internal/platform/docker/TestPidsLimit.java are new with this PR. Shouldn't the copyright then just specify the current year and not a range? And how about adding the author's company as additional copyright holder? ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4518 From pliden at openjdk.java.net Mon Aug 9 13:28:48 2021 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 9 Aug 2021 13:28:48 GMT Subject: RFR: 8271862: C2 intrinsic for Reference.refersTo() is often not used Message-ID: While fixing JDK-8270626 it was discovered that the C2 intrinsic for `Reference.refersTo()` is not used as often as one would think. Instead C2 often prefers using the native implementation, which is much slower which defeats the purpose of having an intrinsic in the first place. The problem arise from having `refersTo0()` be virtual, native and @IntrinsicCandidate. This can be worked around by introducing an virtual method layer and so that `refersTo0()` can be made `final`. That's what this patch does, by adding a virtual `refersToImpl()` which in turn calls the now final `refersTo0()`. It should be noted that `Object.clone()` and `Object.hashCode()` are also virtual, native and @IntrinsicCandidate and these methods get special treatment by C2 to get the intrinsic generated more optimally. We might want to do a similar optimization for `Reference.refersTo0()`. In that case, it is suggested that such an improvement could come later and be handled as a separate enhancement, and @kimbarrett has already filed JDK-8272140 to track that. Testing: I found this hard to test without instrumenting Hotspot to tell me that the intrinsic was called instead of the native method. So, for that reason testing was ad-hoc, using an instrumented Hotspot in combination with the test (`vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java`) that initially uncovered the problem. See JDK-8270626 for additional information. ------------- Commit messages: - 8271862: C2 intrinsic for Reference.refersTo() is often not used Changes: https://git.openjdk.java.net/jdk/pull/5052/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5052&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271862 Stats: 14 lines in 2 files changed: 11 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5052.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5052/head:pull/5052 PR: https://git.openjdk.java.net/jdk/pull/5052 From naoto at openjdk.java.net Mon Aug 9 16:25:37 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 9 Aug 2021 16:25:37 GMT Subject: Integrated: 8264792: The NumberFormat for locale sq_XK formats price incorrectly. In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 16:39:34 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. The root cause of this problem is that the currency for the country code `XK` is undefined because the country code is user-defined in the ISO 3166 standard. However, it is commonly used to represent the region `Kosovo`, which CLDR supports and subsequently is supported by the JDK since JDK9. Adding the data `EUR` for the country code `XK` will fix the issue. This pull request has now been integrated. Changeset: 41dc795d Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/41dc795d6c08af84aa6544cc5a5704dcf99386cf Stats: 13 lines in 3 files changed: 6 ins; 0 del; 7 mod 8264792: The NumberFormat for locale sq_XK formats price incorrectly. Reviewed-by: joehw, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/5033 From asemenyuk at openjdk.java.net Mon Aug 9 17:29:52 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 9 Aug 2021 17:29:52 GMT Subject: RFR: 8271170: Add unit test for what jpackage app launcher puts in the environment Message-ID: Added jtreg test to verify jpackage launcher adds app dir to `java.library.path` system property. Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java. Moved test/jdk/tools/jpackage/apps/image/Hello.java to test/jdk/tools/jpackage/apps/Hello.java. ------------- Commit messages: - dummy commit - Whitespace clean up - 8271170: Add unit test for what jpackage app launcher puts in the environment Changes: https://git.openjdk.java.net/jdk/pull/5056/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5056&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271170 Stats: 342 lines in 7 files changed: 212 ins; 116 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/5056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5056/head:pull/5056 PR: https://git.openjdk.java.net/jdk/pull/5056 From alanb at openjdk.java.net Mon Aug 9 18:13:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 9 Aug 2021 18:13:40 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: <5v2JxcXvfhlsA_lPDTS1u7LQul5S12tNrFHtN3lmnK8=.0186f02f-6537-4ae6-beda-a4268bc047a9@github.com> References: <5v2JxcXvfhlsA_lPDTS1u7LQul5S12tNrFHtN3lmnK8=.0186f02f-6537-4ae6-beda-a4268bc047a9@github.com> Message-ID: On Sat, 7 Aug 2021 06:45:21 GMT, Markus KARG wrote: > I think I fixed all requested changes. Anymore comments on this PR? I hope to get to this soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From asemenyuk at openjdk.java.net Mon Aug 9 18:19:03 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 9 Aug 2021 18:19:03 GMT Subject: RFR: 8271170: Add unit test for what jpackage app launcher puts in the environment [v2] In-Reply-To: References: Message-ID: > Added jtreg test to verify jpackage launcher adds app dir to `java.library.path` system property. > Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java. > Moved test/jdk/tools/jpackage/apps/image/Hello.java to test/jdk/tools/jpackage/apps/Hello.java. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Handle duplicate elements in `java.library.path` system property value. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5056/files - new: https://git.openjdk.java.net/jdk/pull/5056/files/bda38d39..4c0891dd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5056&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5056&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5056/head:pull/5056 PR: https://git.openjdk.java.net/jdk/pull/5056 From almatvee at openjdk.java.net Mon Aug 9 18:50:33 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 9 Aug 2021 18:50:33 GMT Subject: RFR: 8271170: Add unit test for what jpackage app launcher puts in the environment [v2] In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 18:19:03 GMT, Alexey Semenyuk wrote: >> Added jtreg test to verify jpackage launcher adds app dir to `java.library.path` system property. >> Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java. >> Moved test/jdk/tools/jpackage/apps/image/Hello.java to test/jdk/tools/jpackage/apps/Hello.java. > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > Handle duplicate elements in `java.library.path` system property value. Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5056 From herrick at openjdk.java.net Mon Aug 9 19:03:40 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Mon, 9 Aug 2021 19:03:40 GMT Subject: RFR: 8271170: Add unit test for what jpackage app launcher puts in the environment [v2] In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 18:19:03 GMT, Alexey Semenyuk wrote: >> Added jtreg test to verify jpackage launcher adds app dir to `java.library.path` system property. >> Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java. >> Moved test/jdk/tools/jpackage/apps/image/Hello.java to test/jdk/tools/jpackage/apps/Hello.java. > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > Handle duplicate elements in `java.library.path` system property value. Marked as reviewed by herrick (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5056 From kbarrett at openjdk.java.net Mon Aug 9 18:17:35 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 9 Aug 2021 18:17:35 GMT Subject: RFR: 8271862: C2 intrinsic for Reference.refersTo() is often not used In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 13:13:33 GMT, Per Liden wrote: > While fixing JDK-8270626 it was discovered that the C2 intrinsic for `Reference.refersTo()` is not used as often as one would think. Instead C2 often prefers using the native implementation, which is much slower which defeats the purpose of having an intrinsic in the first place. > > The problem arise from having `refersTo0()` be virtual, native and @IntrinsicCandidate. This can be worked around by introducing an virtual method layer and so that `refersTo0()` can be made `final`. That's what this patch does, by adding a virtual `refersToImpl()` which in turn calls the now final `refersTo0()`. > > It should be noted that `Object.clone()` and `Object.hashCode()` are also virtual, native and @IntrinsicCandidate and these methods get special treatment by C2 to get the intrinsic generated more optimally. We might want to do a similar optimization for `Reference.refersTo0()`. In that case, it is suggested that such an improvement could come later and be handled as a separate enhancement, and @kimbarrett has already filed JDK-8272140 to track that. > > Testing: > I found this hard to test without instrumenting Hotspot to tell me that the intrinsic was called instead of the native method. So, for that reason testing was ad-hoc, using an instrumented Hotspot in combination with the test (`vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java`) that initially uncovered the problem. See JDK-8270626 for additional information. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5052 From mchung at openjdk.java.net Mon Aug 9 19:29:32 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 9 Aug 2021 19:29:32 GMT Subject: RFR: 8271862: C2 intrinsic for Reference.refersTo() is often not used In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 13:13:33 GMT, Per Liden wrote: > While fixing JDK-8270626 it was discovered that the C2 intrinsic for `Reference.refersTo()` is not used as often as one would think. Instead C2 often prefers using the native implementation, which is much slower which defeats the purpose of having an intrinsic in the first place. > > The problem arise from having `refersTo0()` be virtual, native and @IntrinsicCandidate. This can be worked around by introducing an virtual method layer and so that `refersTo0()` can be made `final`. That's what this patch does, by adding a virtual `refersToImpl()` which in turn calls the now final `refersTo0()`. > > It should be noted that `Object.clone()` and `Object.hashCode()` are also virtual, native and @IntrinsicCandidate and these methods get special treatment by C2 to get the intrinsic generated more optimally. We might want to do a similar optimization for `Reference.refersTo0()`. In that case, it is suggested that such an improvement could come later and be handled as a separate enhancement, and @kimbarrett has already filed JDK-8272140 to track that. > > Testing: > I found this hard to test without instrumenting Hotspot to tell me that the intrinsic was called instead of the native method. So, for that reason testing was ad-hoc, using an instrumented Hotspot in combination with the test (`vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java`) that initially uncovered the problem. See JDK-8270626 for additional information. Looks good to me too. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5052 From vlivanov at openjdk.java.net Mon Aug 9 20:03:36 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 9 Aug 2021 20:03:36 GMT Subject: RFR: 8271862: C2 intrinsic for Reference.refersTo() is often not used In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 13:13:33 GMT, Per Liden wrote: > While fixing JDK-8270626 it was discovered that the C2 intrinsic for `Reference.refersTo()` is not used as often as one would think. Instead C2 often prefers using the native implementation, which is much slower which defeats the purpose of having an intrinsic in the first place. > > The problem arise from having `refersTo0()` be virtual, native and @IntrinsicCandidate. This can be worked around by introducing an virtual method layer and so that `refersTo0()` can be made `final`. That's what this patch does, by adding a virtual `refersToImpl()` which in turn calls the now final `refersTo0()`. > > It should be noted that `Object.clone()` and `Object.hashCode()` are also virtual, native and @IntrinsicCandidate and these methods get special treatment by C2 to get the intrinsic generated more optimally. We might want to do a similar optimization for `Reference.refersTo0()`. In that case, it is suggested that such an improvement could come later and be handled as a separate enhancement, and @kimbarrett has already filed JDK-8272140 to track that. > > Testing: > I found this hard to test without instrumenting Hotspot to tell me that the intrinsic was called instead of the native method. So, for that reason testing was ad-hoc, using an instrumented Hotspot in combination with the test (`vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java`) that initially uncovered the problem. See JDK-8270626 for additional information. src/java.base/share/classes/java/lang/ref/Reference.java line 374: > 372: * to call the native implementation over the intrinsic. > 373: */ > 374: boolean refersToImpl(T obj) { I'm curious why can't you get rid of `refersToImpl` (virtual method) and just override `refersTo` on `PhantomReference`. Am I missing something important about keeping `refersTo` final? src/java.base/share/classes/java/lang/ref/Reference.java line 379: > 377: > 378: @IntrinsicCandidate > 379: private native final boolean refersTo0(Object o); No need to have it both `private` and `final`. Just `private` should be enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/5052 From mchung at openjdk.java.net Mon Aug 9 20:18:31 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 9 Aug 2021 20:18:31 GMT Subject: RFR: 8271862: C2 intrinsic for Reference.refersTo() is often not used In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 19:58:48 GMT, Vladimir Ivanov wrote: >> While fixing JDK-8270626 it was discovered that the C2 intrinsic for `Reference.refersTo()` is not used as often as one would think. Instead C2 often prefers using the native implementation, which is much slower which defeats the purpose of having an intrinsic in the first place. >> >> The problem arise from having `refersTo0()` be virtual, native and @IntrinsicCandidate. This can be worked around by introducing an virtual method layer and so that `refersTo0()` can be made `final`. That's what this patch does, by adding a virtual `refersToImpl()` which in turn calls the now final `refersTo0()`. >> >> It should be noted that `Object.clone()` and `Object.hashCode()` are also virtual, native and @IntrinsicCandidate and these methods get special treatment by C2 to get the intrinsic generated more optimally. We might want to do a similar optimization for `Reference.refersTo0()`. In that case, it is suggested that such an improvement could come later and be handled as a separate enhancement, and @kimbarrett has already filed JDK-8272140 to track that. >> >> Testing: >> I found this hard to test without instrumenting Hotspot to tell me that the intrinsic was called instead of the native method. So, for that reason testing was ad-hoc, using an instrumented Hotspot in combination with the test (`vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java`) that initially uncovered the problem. See JDK-8270626 for additional information. > > src/java.base/share/classes/java/lang/ref/Reference.java line 374: > >> 372: * to call the native implementation over the intrinsic. >> 373: */ >> 374: boolean refersToImpl(T obj) { > > I'm curious why can't you get rid of `refersToImpl` (virtual method) and just override `refersTo` on `PhantomReference`. Am I missing something important about keeping `refersTo` final? We don't want user-defined subclass of `Reference` overriding the `refersTo` implementation accidentally. ------------- PR: https://git.openjdk.java.net/jdk/pull/5052 From darcy at openjdk.java.net Mon Aug 9 21:04:35 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 9 Aug 2021 21:04:35 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v2] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Sat, 7 Aug 2021 02:07:24 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor test cleanup Are there any user-visible aspects of this re-implementation that would merit a CSR for behavioral changes? ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From vlivanov at openjdk.java.net Mon Aug 9 21:16:31 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 9 Aug 2021 21:16:31 GMT Subject: RFR: 8271862: C2 intrinsic for Reference.refersTo() is often not used In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 20:15:59 GMT, Mandy Chung wrote: >> src/java.base/share/classes/java/lang/ref/Reference.java line 374: >> >>> 372: * to call the native implementation over the intrinsic. >>> 373: */ >>> 374: boolean refersToImpl(T obj) { >> >> I'm curious why can't you get rid of `refersToImpl` (virtual method) and just override `refersTo` on `PhantomReference`. Am I missing something important about keeping `refersTo` final? > > We don't want user-defined subclass of `Reference` overriding the `refersTo` implementation accidentally. Got it. Thanks for the clarification! ------------- PR: https://git.openjdk.java.net/jdk/pull/5052 From mchung at openjdk.java.net Mon Aug 9 21:51:32 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 9 Aug 2021 21:51:32 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v2] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Sat, 7 Aug 2021 02:07:24 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > minor test cleanup There is no user-visible aspect. I plan to file a CSR to document the workaround to enable the old implementation when running into the issues described in the risks and assumption section of JEP 416. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From serb at openjdk.java.net Tue Aug 10 05:20:42 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 10 Aug 2021 05:20:42 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules Message-ID: This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. In many places standard charsets are looked up via their names, for example: absolutePath.getBytes("UTF-8"); This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: absolutePath.getBytes(StandardCharsets.UTF_8); The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. ------------- Commit messages: - Initial fix of JDK-8272120 Changes: https://git.openjdk.java.net/jdk/pull/5063/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5063&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272120 Stats: 127 lines in 15 files changed: 24 ins; 53 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/5063.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5063/head:pull/5063 PR: https://git.openjdk.java.net/jdk/pull/5063 From mbaesken at openjdk.java.net Tue Aug 10 06:55:02 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 10 Aug 2021 06:55:02 GMT Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v9] In-Reply-To: References: Message-ID: > Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups. > > I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory" on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional , see the coding > > > if (!cg_infos[PIDS_IDX]._data_complete) { > log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); > // keep the other controller info, pids is optional > } Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Update test Copyright headers ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4518/files - new: https://git.openjdk.java.net/jdk/pull/4518/files/0dd58e00..217ffb26 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4518&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4518&range=07-08 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4518.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4518/head:pull/4518 PR: https://git.openjdk.java.net/jdk/pull/4518 From luke.hutch at gmail.com Tue Aug 10 06:58:12 2021 From: luke.hutch at gmail.com (Luke Hutchison) Date: Tue, 10 Aug 2021 00:58:12 -0600 Subject: Issue with BuiltinClassLoader.ucp field not being visible In-Reply-To: References: Message-ID: On Tue, Aug 10, 2021 at 12:51 AM Luke Hutchison wrote: > Could a getURLClassPath() method please be added to BuiltInClassLoader? > For security reasons, the getURLClassPath() method should return a copy of ucp, not the reference to ucp, to prevent the caller from modifying the system classpath. From Alan.Bateman at oracle.com Tue Aug 10 07:16:36 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Aug 2021 08:16:36 +0100 Subject: Issue with BuiltinClassLoader.ucp field not being visible In-Reply-To: References: Message-ID: <1b2bf4c6-54e3-0595-33c4-841c53e43f16@oracle.com> On 10/08/2021 07:58, Luke Hutchison wrote: > On Tue, Aug 10, 2021 at 12:51 AM Luke Hutchison > wrote: > >> Could a getURLClassPath() method please be added to BuiltInClassLoader? >> > For security reasons, the getURLClassPath() method should return a copy of > ucp, not the reference to ucp, to prevent the caller from modifying the > system classpath. I think you need more context here. This a JDK internal class so shouldn't be used directly. It reads like the original message was looking for the value of java.class.path as a sequence of URLs, is that right? -Alan From luke.hutch at gmail.com Tue Aug 10 07:34:49 2021 From: luke.hutch at gmail.com (Luke Hutchison) Date: Tue, 10 Aug 2021 01:34:49 -0600 Subject: Issue with BuiltinClassLoader.ucp field not being visible In-Reply-To: <1b2bf4c6-54e3-0595-33c4-841c53e43f16@oracle.com> References: <1b2bf4c6-54e3-0595-33c4-841c53e43f16@oracle.com> Message-ID: The issue is that the Instrumentation.appendToSystemClassLoaderSearch method "does not change the value of java.class.path system property" (stated in the JavaDoc): https://docs.oracle.com/en/java/javase/16/docs/api/java.instrument/java/lang/instrument/Instrumentation.html#appendToSystemClassLoaderSearch(java.util.jar.JarFile) but classpath entries that are added to the end of the system classloader classpath in this way are also not recorded anywhere else that is readable by user code. Without a method for reading these manual additions to BaseClassLoader.ucp, there is simply no way to determine what if any jars or directories have been added to the classpath using this mechanism. What I'm asking for is some public API mechanism to determine what additional classpath elements have been added to the end of the system classloader path via the Instrumentation.appendToSystemClassLoaderSearch method, so that classpath scanners can also work in the Java agent context, if this method has been called to augment the classpath. Maybe that should be part of the Instrumentation class, so that it is only accessible to Java agent code that is able to get a reference to an Instrumentation object. On Tue, Aug 10, 2021 at 1:16 AM Alan Bateman wrote: > On 10/08/2021 07:58, Luke Hutchison wrote: > > On Tue, Aug 10, 2021 at 12:51 AM Luke Hutchison > > wrote: > > > >> Could a getURLClassPath() method please be added to BuiltInClassLoader? > >> > > For security reasons, the getURLClassPath() method should return a copy > of > > ucp, not the reference to ucp, to prevent the caller from modifying the > > system classpath. > I think you need more context here. This a JDK internal class so > shouldn't be used directly. It reads like the original message was > looking for the value of java.class.path as a sequence of URLs, is that > right? > > -Alan > From luke.hutch at gmail.com Tue Aug 10 07:37:25 2021 From: luke.hutch at gmail.com (Luke Hutchison) Date: Tue, 10 Aug 2021 01:37:25 -0600 Subject: Issue with BuiltinClassLoader.ucp field not being visible In-Reply-To: References: <1b2bf4c6-54e3-0595-33c4-841c53e43f16@oracle.com> Message-ID: On Tue, Aug 10, 2021 at 1:34 AM Luke Hutchison wrote: > Maybe that should be part of the Instrumentation class, so that it is only > accessible to Java agent code that is able to get a reference to an > Instrumentation object. > Actually I take that last part back, that would not be very helpful to libraries like ClassGraph. It would be much better if there were simply a public method in `AppClassLoader` that could be used to get all classpath elements that have been added for instrumentation. From mbaesken at openjdk.java.net Tue Aug 10 07:44:45 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 10 Aug 2021 07:44:45 GMT Subject: Integrated: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 12:27:25 GMT, Matthias Baesken wrote: > Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups. > > I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory" on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional , see the coding > > > if (!cg_infos[PIDS_IDX]._data_complete) { > log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); > // keep the other controller info, pids is optional > } This pull request has now been integrated. Changeset: 089e83bf Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/089e83bf1bf6f28cec8dd30288720b6d066301f0 Stats: 555 lines in 22 files changed: 476 ins; 28 del; 51 mod 8266490: Extend the OSContainer API to support the pids controller of cgroups Reviewed-by: sgehwolf, lucy ------------- PR: https://git.openjdk.java.net/jdk/pull/4518 From pliden at openjdk.java.net Tue Aug 10 08:59:59 2021 From: pliden at openjdk.java.net (Per Liden) Date: Tue, 10 Aug 2021 08:59:59 GMT Subject: RFR: 8271862: C2 intrinsic for Reference.refersTo() is often not used [v2] In-Reply-To: References: Message-ID: > While fixing JDK-8270626 it was discovered that the C2 intrinsic for `Reference.refersTo()` is not used as often as one would think. Instead C2 often prefers using the native implementation, which is much slower which defeats the purpose of having an intrinsic in the first place. > > The problem arise from having `refersTo0()` be virtual, native and @IntrinsicCandidate. This can be worked around by introducing an virtual method layer and so that `refersTo0()` can be made `final`. That's what this patch does, by adding a virtual `refersToImpl()` which in turn calls the now final `refersTo0()`. > > It should be noted that `Object.clone()` and `Object.hashCode()` are also virtual, native and @IntrinsicCandidate and these methods get special treatment by C2 to get the intrinsic generated more optimally. We might want to do a similar optimization for `Reference.refersTo0()`. In that case, it is suggested that such an improvement could come later and be handled as a separate enhancement, and @kimbarrett has already filed JDK-8272140 to track that. > > Testing: > I found this hard to test without instrumenting Hotspot to tell me that the intrinsic was called instead of the native method. So, for that reason testing was ad-hoc, using an instrumented Hotspot in combination with the test (`vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java`) that initially uncovered the problem. See JDK-8270626 for additional information. Per Liden has updated the pull request incrementally with one additional commit since the last revision: Private implies final ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5052/files - new: https://git.openjdk.java.net/jdk/pull/5052/files/66743f76..3bc3d5e5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5052&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5052&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5052.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5052/head:pull/5052 PR: https://git.openjdk.java.net/jdk/pull/5052 From pliden at openjdk.java.net Tue Aug 10 09:00:00 2021 From: pliden at openjdk.java.net (Per Liden) Date: Tue, 10 Aug 2021 09:00:00 GMT Subject: RFR: 8271862: C2 intrinsic for Reference.refersTo() is often not used [v2] In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 19:59:21 GMT, Vladimir Ivanov wrote: >> Per Liden has updated the pull request incrementally with one additional commit since the last revision: >> >> Private implies final > > src/java.base/share/classes/java/lang/ref/Reference.java line 379: > >> 377: >> 378: @IntrinsicCandidate >> 379: private native final boolean refersTo0(Object o); > > No need to have it both `private` and `final`. Just `private` should be enough. Good point. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5052 From alanb at openjdk.java.net Tue Aug 10 09:21:28 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 10 Aug 2021 09:21:28 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. It would be useful to get up to date performance data on using Charset vs. charset name. At least historically, the charset name versions were faster (see [JDK-6764325](https://bugs.openjdk.java.net/browse/JDK-6764325)). ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From github.com+10835776+stsypanov at openjdk.java.net Tue Aug 10 13:24:41 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 10 Aug 2021 13:24:41 GMT Subject: RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable Message-ID: The code in `Integer.decode()` and `Long.decode()` might allocate two instances of Integer/Long for the negative values less than -127: Integer result; result = Integer.valueOf(nm.substring(index), radix); result = negative ? Integer.valueOf(-result.intValue()) : result; To avoid this we can declare 'result' as `int` and use `Integer.parseInt()` method. Same applicable for `Long` and some other classes. ------------- Commit messages: - Merge branch 'master' into 8267844 - 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable Changes: https://git.openjdk.java.net/jdk/pull/5068/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5068&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267844 Stats: 12 lines in 4 files changed: 0 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5068.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5068/head:pull/5068 PR: https://git.openjdk.java.net/jdk/pull/5068 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 10 13:31:33 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 10 Aug 2021 13:31:33 GMT Subject: Integrated: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov wrote: > I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. > This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. This pull request has now been integrated. Changeset: 35b399ac Author: Andrey Turbanov Committer: Jayathirth D V URL: https://git.openjdk.java.net/jdk/commit/35b399aca810db63371ff65046f047ef0b955161 Stats: 70 lines in 8 files changed: 0 ins; 54 del; 16 mod 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying Reviewed-by: mullan, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/4487 From redestad at openjdk.java.net Tue Aug 10 15:00:37 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 10 Aug 2021 15:00:37 GMT Subject: RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 13:16:42 GMT, ?????? ??????? wrote: > The code in `Integer.decode()` and `Long.decode()` might allocate two instances of Integer/Long for the negative values less than -127: > > Integer result; > > result = Integer.valueOf(nm.substring(index), radix); > result = negative ? Integer.valueOf(-result.intValue()) : result; > > To avoid this we can declare 'result' as `int` and use `Integer.parseInt()` method. Same applicable for `Long` and some other classes. Looks fine to me. Could you consider adding microbenchmarks for Integer/Long.decode? src/java.base/share/classes/java/lang/Integer.java line 1450: > 1448: > 1449: try { > 1450: result = parseInt(nm.substring(index), radix); Possibly a follow-up, but I think using `parseInt/-Long(nm, index, nm.length(), radix)` could give an additional speed-up in these cases (by avoiding a substring allocation). ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5068 From github.com+70726043+rgiulietti at openjdk.java.net Tue Aug 10 17:19:55 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Tue, 10 Aug 2021 17:19:55 GMT Subject: Integrated: 8271601: Math.floorMod(int, int) and Math.floorMod(long, long) differ in their logic In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 19:59:57 GMT, Raffaello Giulietti wrote: > Hello, > > please review this tiny change in the implementation of j.l.Math.floorMod(int, int). > > While the results are unaffected, all of > floorDiv(int, int) > floorDiv(long, long) > floorMod(long, long) > use x ^ y in the tests to correct the result if needed. > > Not only is the proposed change more consistent with the other methods, but it might benefit later stages in the cpu to proceed with the evaluation of x ^ y in parallel with the previous x % y and, depending of the outcome, even further down. > > > Greetings > Raffaello This pull request has now been integrated. Changeset: 66d1faa7 Author: Raffaello Giulietti Committer: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/66d1faa7847b645f20ab2e966adf0a523e3ffeb2 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8271601: Math.floorMod(int, int) and Math.floorMod(long, long) differ in their logic Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/4962 From github.com+10835776+stsypanov at openjdk.java.net Tue Aug 10 17:43:15 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 10 Aug 2021 17:43:15 GMT Subject: RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 14:56:11 GMT, Claes Redestad wrote: >> The code in `Integer.decode()` and `Long.decode()` might allocate two instances of Integer/Long for the negative values less than -127: >> >> Integer result; >> >> result = Integer.valueOf(nm.substring(index), radix); >> result = negative ? Integer.valueOf(-result.intValue()) : result; >> >> To avoid this we can declare 'result' as `int` and use `Integer.parseInt()` method. Same applicable for `Long` and some other classes. > > src/java.base/share/classes/java/lang/Integer.java line 1450: > >> 1448: >> 1449: try { >> 1450: result = parseInt(nm.substring(index), radix); > > Possibly a follow-up, but I think using `parseInt/-Long(nm, index, nm.length(), radix)` could give an additional speed-up in these cases (by avoiding a substring allocation). Good point! Let me check this. ------------- PR: https://git.openjdk.java.net/jdk/pull/5068 From serb at openjdk.java.net Tue Aug 10 18:09:26 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 10 Aug 2021 18:09:26 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: <9hTy8U6wk2uDoxCYlENexy2olb-8vaF49ZukcQj_bSA=.b9c53124-ea69-4cee-8698-3781b2b4acc5@github.com> On Tue, 10 Aug 2021 09:18:39 GMT, Alan Bateman wrote: > It would be useful to get up to date performance data on using Charset vs. charset name. At least historically, the charset name versions were faster (see [JDK-6764325](https://bugs.openjdk.java.net/browse/JDK-6764325)). The code in question was changed a few times since then, the last change was done by the https://github.com/openjdk/jdk/pull/2102. So currently the code for string.getBytes String/Charset uses the same code paths, except that the string version has an additional call to lookup the charset. The string version: https://github.com/openjdk/jdk/blob/66d1faa7847b645f20ab2e966adf0a523e3ffeb2/src/java.base/share/classes/java/lang/String.java#L1753 The charset version: https://github.com/openjdk/jdk/blob/66d1faa7847b645f20ab2e966adf0a523e3ffeb2/src/java.base/share/classes/java/lang/String.java#L1777 I checked the performance and the charset is always faster, depending on the string size, up to x20. @cl4es please confirm my observation since you did it already for https://github.com/openjdk/jdk/pull/2102 ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From redestad at openjdk.java.net Tue Aug 10 18:44:26 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 10 Aug 2021 18:44:26 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. Yes, while I don't know exactly which changes resolved JDK-6764325, it's clear from the microbenchmarks added for #2102 that it's no longer an issue - at least not in the mainline. ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From github.com+10835776+stsypanov at openjdk.java.net Tue Aug 10 21:01:27 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 10 Aug 2021 21:01:27 GMT Subject: RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 17:39:01 GMT, ?????? ??????? wrote: >> src/java.base/share/classes/java/lang/Integer.java line 1450: >> >>> 1448: >>> 1449: try { >>> 1450: result = parseInt(nm.substring(index), radix); >> >> Possibly a follow-up, but I think using `parseInt/-Long(nm, index, nm.length(), radix)` could give an additional speed-up in these cases (by avoiding a substring allocation). > > Good point! Let me check this. Indeed, looks like getting rid of `substring()` call makes things faster: before Benchmark (size) Mode Cnt Score Error Units Integers.decode 500 avgt 15 11.444 ? 0.949 us/op Integers.parseInt 500 avgt 15 8.669 ? 0.152 us/op Integers.toStringBig 500 avgt 15 10.295 ? 0.612 us/op Integers.toStringSmall 500 avgt 15 7.020 ? 0.581 us/op Benchmark (size) Mode Cnt Score Error Units Longs.decode 500 avgt 15 29.568 ? 9.785 us/op Longs.repetitiveSubtraction 500 avgt 15 0.820 ? 0.153 us/op Longs.toStringBig 500 avgt 15 13.418 ? 0.744 us/op Longs.toStringSmall 500 avgt 15 8.180 ? 0.780 us/op after Benchmark (size) Mode Cnt Score Error Units Integers.decode 500 avgt 15 7.377 ? 0.040 us/op Integers.parseInt 500 avgt 15 8.720 ? 0.230 us/op Integers.toStringBig 500 avgt 15 10.328 ? 0.266 us/op Integers.toStringSmall 500 avgt 15 6.913 ? 0.178 us/op Benchmark (size) Mode Cnt Score Error Units Longs.decode 500 avgt 15 8.373 ? 0.708 us/op Longs.repetitiveSubtraction 500 avgt 15 0.771 ? 0.003 us/op Longs.toStringBig 500 avgt 15 13.126 ? 0.079 us/op Longs.toStringSmall 500 avgt 15 6.915 ? 0.259 us/op ------------- PR: https://git.openjdk.java.net/jdk/pull/5068 From github.com+10835776+stsypanov at openjdk.java.net Tue Aug 10 21:06:00 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 10 Aug 2021 21:06:00 GMT Subject: RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable [v2] In-Reply-To: References: Message-ID: > The code in `Integer.decode()` and `Long.decode()` might allocate two instances of Integer/Long for the negative values less than -127: > > Integer result; > > result = Integer.valueOf(nm.substring(index), radix); > result = negative ? Integer.valueOf(-result.intValue()) : result; > > To avoid this we can declare 'result' as `int` and use `Integer.parseInt()` method. Same applicable for `Long` and some other classes. ?????? ??????? 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: - 8267844: Add benchmarks for Integer/Long.decode() - 8267844: Rid useless substring when calling Integer/Long.parse*() - Merge branch 'master' into 8267844 - Merge branch 'master' into 8267844 - 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5068/files - new: https://git.openjdk.java.net/jdk/pull/5068/files/a1b993d4..7486b13f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5068&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5068&range=00-01 Stats: 149574 lines in 2453 files changed: 97455 ins; 39648 del; 12471 mod Patch: https://git.openjdk.java.net/jdk/pull/5068.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5068/head:pull/5068 PR: https://git.openjdk.java.net/jdk/pull/5068 From redestad at openjdk.java.net Tue Aug 10 22:03:33 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 10 Aug 2021 22:03:33 GMT Subject: RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable [v2] In-Reply-To: References: Message-ID: <2OzfJmEt7sSc38Bh1NrMuGKpe1_xJP8VHMWQNN7Mlac=.9bf87fdb-fd25-43bb-ac01-1231d1c85cee@github.com> On Tue, 10 Aug 2021 21:06:00 GMT, ?????? ??????? wrote: >> The code in `Integer.decode()` and `Long.decode()` might allocate two instances of Integer/Long for the negative values less than -127: >> >> Integer result; >> >> result = Integer.valueOf(nm.substring(index), radix); >> result = negative ? Integer.valueOf(-result.intValue()) : result; >> >> To avoid this we can declare 'result' as `int` and use `Integer.parseInt()` method. Same applicable for `Long` and some other classes. > > ?????? ??????? 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: > > - 8267844: Add benchmarks for Integer/Long.decode() > - 8267844: Rid useless substring when calling Integer/Long.parse*() > - Merge branch 'master' into 8267844 > - Merge branch 'master' into 8267844 > - 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable Nice! ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5068 From stuefe at openjdk.java.net Wed Aug 11 07:01:30 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 11 Aug 2021 07:01:30 GMT Subject: RFR: JDK-8271858: Handle to jimage file inherited into child processes (posix) In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 12:22:24 GMT, Thomas Stuefe wrote: > We should not leak the handle to the jimage file (lib/modules) to childs. > > JDK-8194734 did solve this for windows. We should use FD_CLOEXEC on Posix as well. > > Note that this only poses a problem when a child process is spawned off not via `Runtime.exec` but via another route since the spawnhelper closes all file descriptors. > > --- > test: > > manually verified that lib/modules now has the FD_CLOEXEC flag set. I withdraw the PR and close the issue as won't fix since the issue is very unlikely to cause real problems (only in the event of someone raw-forking, bypassing Runtime.exec()). I'll find a narrower solution to simplify the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/4991 From stuefe at openjdk.java.net Wed Aug 11 07:01:30 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 11 Aug 2021 07:01:30 GMT Subject: Withdrawn: JDK-8271858: Handle to jimage file inherited into child processes (posix) In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 12:22:24 GMT, Thomas Stuefe wrote: > We should not leak the handle to the jimage file (lib/modules) to childs. > > JDK-8194734 did solve this for windows. We should use FD_CLOEXEC on Posix as well. > > Note that this only poses a problem when a child process is spawned off not via `Runtime.exec` but via another route since the spawnhelper closes all file descriptors. > > --- > test: > > manually verified that lib/modules now has the FD_CLOEXEC flag set. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4991 From dfuchs at openjdk.java.net Wed Aug 11 09:15:24 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 11 Aug 2021 09:15:24 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. >From my pure developer's perspective the proposed changes look good. If the performance concerns are removed I'd say it looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From pliden at openjdk.java.net Wed Aug 11 11:12:29 2021 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 11 Aug 2021 11:12:29 GMT Subject: Integrated: 8271862: C2 intrinsic for Reference.refersTo() is often not used In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 13:13:33 GMT, Per Liden wrote: > While fixing JDK-8270626 it was discovered that the C2 intrinsic for `Reference.refersTo()` is not used as often as one would think. Instead C2 often prefers using the native implementation, which is much slower which defeats the purpose of having an intrinsic in the first place. > > The problem arise from having `refersTo0()` be virtual, native and @IntrinsicCandidate. This can be worked around by introducing an virtual method layer and so that `refersTo0()` can be made `final`. That's what this patch does, by adding a virtual `refersToImpl()` which in turn calls the now final `refersTo0()`. > > It should be noted that `Object.clone()` and `Object.hashCode()` are also virtual, native and @IntrinsicCandidate and these methods get special treatment by C2 to get the intrinsic generated more optimally. We might want to do a similar optimization for `Reference.refersTo0()`. In that case, it is suggested that such an improvement could come later and be handled as a separate enhancement, and @kimbarrett has already filed JDK-8272140 to track that. > > Testing: > I found this hard to test without instrumenting Hotspot to tell me that the intrinsic was called instead of the native method. So, for that reason testing was ad-hoc, using an instrumented Hotspot in combination with the test (`vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java`) that initially uncovered the problem. See JDK-8270626 for additional information. This pull request has now been integrated. Changeset: 3f723ca4 Author: Per Liden URL: https://git.openjdk.java.net/jdk/commit/3f723ca4577b9cffeb6153ee386edd75f1dfb1c6 Stats: 14 lines in 2 files changed: 11 ins; 0 del; 3 mod 8271862: C2 intrinsic for Reference.refersTo() is often not used Reviewed-by: kbarrett, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/5052 From pliden at openjdk.java.net Wed Aug 11 11:12:29 2021 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 11 Aug 2021 11:12:29 GMT Subject: RFR: 8271862: C2 intrinsic for Reference.refersTo() is often not used [v2] In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 08:59:59 GMT, Per Liden wrote: >> While fixing JDK-8270626 it was discovered that the C2 intrinsic for `Reference.refersTo()` is not used as often as one would think. Instead C2 often prefers using the native implementation, which is much slower which defeats the purpose of having an intrinsic in the first place. >> >> The problem arise from having `refersTo0()` be virtual, native and @IntrinsicCandidate. This can be worked around by introducing an virtual method layer and so that `refersTo0()` can be made `final`. That's what this patch does, by adding a virtual `refersToImpl()` which in turn calls the now final `refersTo0()`. >> >> It should be noted that `Object.clone()` and `Object.hashCode()` are also virtual, native and @IntrinsicCandidate and these methods get special treatment by C2 to get the intrinsic generated more optimally. We might want to do a similar optimization for `Reference.refersTo0()`. In that case, it is suggested that such an improvement could come later and be handled as a separate enhancement, and @kimbarrett has already filed JDK-8272140 to track that. >> >> Testing: >> I found this hard to test without instrumenting Hotspot to tell me that the intrinsic was called instead of the native method. So, for that reason testing was ad-hoc, using an instrumented Hotspot in combination with the test (`vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java`) that initially uncovered the problem. See JDK-8270626 for additional information. > > Per Liden has updated the pull request incrementally with one additional commit since the last revision: > > Private implies final Thanks all for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/5052 From alanb at openjdk.java.net Wed Aug 11 11:30:28 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 Aug 2021 11:30:28 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: <5v2JxcXvfhlsA_lPDTS1u7LQul5S12tNrFHtN3lmnK8=.0186f02f-6537-4ae6-beda-a4268bc047a9@github.com> Message-ID: On Mon, 9 Aug 2021 18:10:52 GMT, Alan Bateman wrote: > I think I fixed all requested changes. Anymore comments on this PR? I've looked through the latest revision. Is here any way that we could drop most of the changes to ChannelInputStream and focus on one or two specific cases? I'm asking because there are several issues, inconsistencies, and it is trying to cover many scenarios that aren't covered by the test. If the original motivation was file -> file then it could be simplified down to a FileChannel -> FileChannel transfer as the default provider uses file channels. We could even push some support into FileChannelImpl so that it is done while holding the position lock. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From redestad at openjdk.java.net Wed Aug 11 14:33:33 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 Aug 2021 14:33:33 GMT Subject: RFR: 8271732: Regression in StringBuilder.charAt bounds checking Message-ID: In #4738 we removed the `checkIndex(value, count)` call in `ASB.charAt` to avoid potentially getting two bounds checks in the UTF-16 case. Problem is this optimization cause a regression since `StringUTF16.charAt(..)` checks `index` against the length of the `value` array and not `count`. A correct fix that still maintain the possible performance advantage reported by #4738 is to reinstate the `checkIndex(value, count)` and call `StringUTF16.getChar` instead of `charAt`. ------------- Commit messages: - 8271732: Regression in StringBuilder.charAt bounds checking Changes: https://git.openjdk.java.net/jdk/pull/5086/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5086&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271732 Stats: 24 lines in 2 files changed: 22 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5086.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5086/head:pull/5086 PR: https://git.openjdk.java.net/jdk/pull/5086 From alanb at openjdk.java.net Wed Aug 11 15:11:22 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 Aug 2021 15:11:22 GMT Subject: RFR: 8271732: Regression in StringBuilder.charAt bounds checking In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 14:26:32 GMT, Claes Redestad wrote: > In #4738 we removed the `checkIndex(value, count)` call in `ASB.charAt` to avoid potentially getting two bounds checks in the UTF-16 case. Problem is this optimization cause a regression since `StringUTF16.charAt(..)` checks `index` against the length of the `value` array and not `count`. > > A correct fix that still maintain the possible performance advantage reported by #4738 is to reinstate the `checkIndex(value, count)` and call `StringUTF16.getChar` instead of `charAt`. This looks okay but surprised there wasn't a jtreg test that would have caught this before integration, maybe we should add a test as part of this change. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5086 From asemenyuk at openjdk.java.net Wed Aug 11 15:20:00 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 11 Aug 2021 15:20:00 GMT Subject: RFR: 8271170: Add unit test for what jpackage app launcher puts in the environment [v3] In-Reply-To: References: Message-ID: > Added jtreg test to verify jpackage launcher adds app dir to `java.library.path` system property. > Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java. > Moved test/jdk/tools/jpackage/apps/image/Hello.java to test/jdk/tools/jpackage/apps/Hello.java. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Removed unused output to file in the new PrintEnv test app. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5056/files - new: https://git.openjdk.java.net/jdk/pull/5056/files/4c0891dd..27e82df3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5056&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5056&range=01-02 Stats: 13 lines in 2 files changed: 0 ins; 11 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5056/head:pull/5056 PR: https://git.openjdk.java.net/jdk/pull/5056 From naoto at openjdk.java.net Wed Aug 11 17:08:23 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 11 Aug 2021 17:08:23 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. +1 ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From naoto at openjdk.java.net Wed Aug 11 17:13:25 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 11 Aug 2021 17:13:25 GMT Subject: RFR: 8271732: Regression in StringBuilder.charAt bounds checking In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 14:26:32 GMT, Claes Redestad wrote: > In #4738 we removed the `checkIndex(value, count)` call in `ASB.charAt` to avoid potentially getting two bounds checks in the UTF-16 case. Problem is this optimization cause a regression since `StringUTF16.charAt(..)` checks `index` against the length of the `value` array and not `count`. > > A correct fix that still maintain the possible performance advantage reported by #4738 is to reinstate the `checkIndex(value, count)` and call `StringUTF16.getChar` instead of `charAt`. LGTM. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5086 From asemenyuk at openjdk.java.net Wed Aug 11 17:57:23 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 11 Aug 2021 17:57:23 GMT Subject: RFR: 8271170: Add unit test for what jpackage app launcher puts in the environment [v3] In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 15:20:00 GMT, Alexey Semenyuk wrote: >> Added jtreg test to verify jpackage launcher adds app dir to `java.library.path` system property. >> Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java. >> Moved test/jdk/tools/jpackage/apps/image/Hello.java to test/jdk/tools/jpackage/apps/Hello.java. > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > Removed unused output to file in the new PrintEnv test app. These changes will be pushed after https://bugs.openjdk.java.net/browse/JDK-8272328 is fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5056 From asemenyuk at openjdk.java.net Wed Aug 11 17:59:32 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 11 Aug 2021 17:59:32 GMT Subject: RFR: 8272328: java.library.path is not set properly by Windows jpackage app launcher Message-ID: Restart window app launcher to make changes made to `PATH` env variable visible to JLI code in https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L347 ------------- Commit messages: - 8272328: java.library.path is not set properly by Windows jpackage app launcher Changes: https://git.openjdk.java.net/jdk/pull/5090/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5090&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272328 Stats: 75 lines in 4 files changed: 63 ins; 5 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5090/head:pull/5090 PR: https://git.openjdk.java.net/jdk/pull/5090 From github.com+1701815+mkarg at openjdk.java.net Wed Aug 11 18:15:33 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Wed, 11 Aug 2021 18:15:33 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: <5v2JxcXvfhlsA_lPDTS1u7LQul5S12tNrFHtN3lmnK8=.0186f02f-6537-4ae6-beda-a4268bc047a9@github.com> Message-ID: On Wed, 11 Aug 2021 11:27:53 GMT, Alan Bateman wrote: > I've looked through the latest revision. Is there any way that we could drop most of the changes to ChannelInputStream and focus on one or two specific cases? I'm asking because there are several issues, inconsistencies, and it is trying to cover many scenarios that aren't covered by the test. > If the original motivation was file -> file then it could be simplified down to a FileChannel -> FileChannel transfer as the default provider uses file channels. We could even push some support into FileChannelImpl so that it is done while holding the position lock. I am a bit disappointed actually about that destructive answer at that late point in time, now that I worked for months on all the requested changes and tests. To prevent exactly this situation, I deliberately had the discussion started in JIRA only, and I deliberately had the original code being just a draft in the first place, and I deliberately did nearly *everything* I was asked to (including even the most irrelevant minor code style issues). And you come up with the request to drop the code **now**? Certainly we could reduce the PR to just file channels, but in fact, now that I spent all the time in the non-file-channels, I wonder why I shall throw away all that work and go just with file channels actually? What is not covered that was originally covered, and what is that lots of issues you talk about? Actually I cannot see the actual problem unless you name it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From igraves at openjdk.java.net Wed Aug 11 18:29:40 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 11 Aug 2021 18:29:40 GMT Subject: RFR: 8271302: Regex Test Refresh Message-ID: 8271302: Regex Test Refresh ------------- Commit messages: - Migrating regular expression tests to TestNG Changes: https://git.openjdk.java.net/jdk/pull/5092/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271302 Stats: 2226 lines in 3 files changed: 225 ins; 965 del; 1036 mod Patch: https://git.openjdk.java.net/jdk/pull/5092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5092/head:pull/5092 PR: https://git.openjdk.java.net/jdk/pull/5092 From igraves at openjdk.java.net Wed Aug 11 18:29:40 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 11 Aug 2021 18:29:40 GMT Subject: RFR: 8271302: Regex Test Refresh In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 18:22:42 GMT, Ian Graves wrote: > 8271302: Regex Test Refresh This PR migrates all regular expression tests in the jdk/java/util/regex directory to use TestNG assertions and annotations. The assertions utilized for this refresh are shared in common with standard ones from JUnit5 should such a migration occur in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From alanb at openjdk.java.net Wed Aug 11 18:59:22 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 Aug 2021 18:59:22 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 18:41:04 GMT, Claes Redestad wrote: > Yes, while I don't know exactly which changes resolved JDK-6764325, it's clear from the microbenchmarks added for #2102 that it's no longer an issue - at least not in the mainline. Thanks for checking and for closing that issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From alanb at openjdk.java.net Wed Aug 11 18:59:22 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 Aug 2021 18:59:22 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From dfuchs at openjdk.java.net Wed Aug 11 19:04:24 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 11 Aug 2021 19:04:24 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From naoto at openjdk.java.net Wed Aug 11 19:10:26 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 11 Aug 2021 19:10:26 GMT Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From herrick at openjdk.java.net Wed Aug 11 19:48:25 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Wed, 11 Aug 2021 19:48:25 GMT Subject: RFR: 8272328: java.library.path is not set properly by Windows jpackage app launcher In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 17:52:57 GMT, Alexey Semenyuk wrote: > Restart window app launcher to make changes made to `PATH` env variable visible to JLI code in https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L347 Marked as reviewed by herrick (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5090 From redestad at openjdk.java.net Wed Aug 11 20:15:11 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 Aug 2021 20:15:11 GMT Subject: RFR: 8271732: Regression in StringBuilder.charAt bounds checking [v2] In-Reply-To: References: Message-ID: > In #4738 we removed the `checkIndex(value, count)` call in `ASB.charAt` to avoid potentially getting two bounds checks in the UTF-16 case. Problem is this optimization cause a regression since `StringUTF16.charAt(..)` checks `index` against the length of the `value` array and not `count`. > > A correct fix that still maintain the possible performance advantage reported by #4738 is to reinstate the `checkIndex(value, count)` and call `StringUTF16.getChar` instead of `charAt`. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Add SB.charAt test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5086/files - new: https://git.openjdk.java.net/jdk/pull/5086/files/e72d9e15..e29c576a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5086&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5086&range=00-01 Stats: 66 lines in 1 file changed: 66 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5086.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5086/head:pull/5086 PR: https://git.openjdk.java.net/jdk/pull/5086 From almatvee at openjdk.java.net Wed Aug 11 20:29:25 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 11 Aug 2021 20:29:25 GMT Subject: RFR: 8272328: java.library.path is not set properly by Windows jpackage app launcher In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 17:52:57 GMT, Alexey Semenyuk wrote: > Restart window app launcher to make changes made to `PATH` env variable visible to JLI code in https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L347 Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5090 From asemenyuk at openjdk.java.net Wed Aug 11 20:57:27 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 11 Aug 2021 20:57:27 GMT Subject: Integrated: 8272328: java.library.path is not set properly by Windows jpackage app launcher In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 17:52:57 GMT, Alexey Semenyuk wrote: > Restart window app launcher to make changes made to `PATH` env variable visible to JLI code in https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L347 This pull request has now been integrated. Changeset: cd2dbe5f Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/cd2dbe5f007baf81ae9262c1152917e620970621 Stats: 75 lines in 4 files changed: 63 ins; 5 del; 7 mod 8272328: java.library.path is not set properly by Windows jpackage app launcher Reviewed-by: herrick, almatvee ------------- PR: https://git.openjdk.java.net/jdk/pull/5090 From asemenyuk at openjdk.java.net Wed Aug 11 21:00:51 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 11 Aug 2021 21:00:51 GMT Subject: RFR: 8271170: Add unit test for what jpackage app launcher puts in the environment [v4] In-Reply-To: References: Message-ID: <2Uyr-oQ-XvHwcOTPyS5UGlw94LgzbXUMm1D88XUfsTk=.09e2810f-36c9-4ad1-9315-52f0101f16a5@github.com> > Added jtreg test to verify jpackage launcher adds app dir to `java.library.path` system property. > Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java. > Moved test/jdk/tools/jpackage/apps/image/Hello.java to test/jdk/tools/jpackage/apps/Hello.java. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: dummy commit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5056/files - new: https://git.openjdk.java.net/jdk/pull/5056/files/27e82df3..3e7011e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5056&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5056&range=02-03 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5056/head:pull/5056 PR: https://git.openjdk.java.net/jdk/pull/5056 From redestad at openjdk.java.net Wed Aug 11 21:37:50 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 Aug 2021 21:37:50 GMT Subject: RFR: 8271732: Regression in StringBuilder.charAt bounds checking [v3] In-Reply-To: References: Message-ID: > In #4738 we removed the `checkIndex(value, count)` call in `ASB.charAt` to avoid potentially getting two bounds checks in the UTF-16 case. Problem is this optimization cause a regression since `StringUTF16.charAt(..)` checks `index` against the length of the `value` array and not `count`. > > A correct fix that still maintain the possible performance advantage reported by #4738 is to reinstate the `checkIndex(value, count)` and call `StringUTF16.getChar` instead of `charAt`. Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: - Fix copy-paste error - Add UTF-16 tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5086/files - new: https://git.openjdk.java.net/jdk/pull/5086/files/e29c576a..4ef9ccbc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5086&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5086&range=01-02 Stats: 23 lines in 1 file changed: 18 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5086.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5086/head:pull/5086 PR: https://git.openjdk.java.net/jdk/pull/5086 From redestad at openjdk.java.net Wed Aug 11 21:40:52 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 Aug 2021 21:40:52 GMT Subject: RFR: 8271732: Regression in StringBuilder.charAt bounds checking [v4] In-Reply-To: References: Message-ID: > In #4738 we removed the `checkIndex(value, count)` call in `ASB.charAt` to avoid potentially getting two bounds checks in the UTF-16 case. Problem is this optimization cause a regression since `StringUTF16.charAt(..)` checks `index` against the length of the `value` array and not `count`. > > A correct fix that still maintain the possible performance advantage reported by #4738 is to reinstate the `checkIndex(value, count)` and call `StringUTF16.getChar` instead of `charAt`. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Fix copy-paste error ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5086/files - new: https://git.openjdk.java.net/jdk/pull/5086/files/4ef9ccbc..83a64828 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5086&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5086&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5086.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5086/head:pull/5086 PR: https://git.openjdk.java.net/jdk/pull/5086 From naoto at openjdk.java.net Wed Aug 11 22:37:25 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 11 Aug 2021 22:37:25 GMT Subject: RFR: 8271732: Regression in StringBuilder.charAt bounds checking [v4] In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 21:40:52 GMT, Claes Redestad wrote: >> In #4738 we removed the `checkIndex(value, count)` call in `ASB.charAt` to avoid potentially getting two bounds checks in the UTF-16 case. Problem is this optimization cause a regression since `StringUTF16.charAt(..)` checks `index` against the length of the `value` array and not `count`. >> >> A correct fix that still maintain the possible performance advantage reported by #4738 is to reinstate the `checkIndex(value, count)` and call `StringUTF16.getChar` instead of `charAt`. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Fix copy-paste error Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5086 From asemenyuk at openjdk.java.net Wed Aug 11 23:43:32 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 11 Aug 2021 23:43:32 GMT Subject: Integrated: 8271170: Add unit test for what jpackage app launcher puts in the environment In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 17:02:55 GMT, Alexey Semenyuk wrote: > Added jtreg test to verify jpackage launcher adds app dir to `java.library.path` system property. > Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java. > Moved test/jdk/tools/jpackage/apps/image/Hello.java to test/jdk/tools/jpackage/apps/Hello.java. This pull request has now been integrated. Changeset: 44f137ff Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/44f137ff9c0229ab2d5eccd9ebaadf8db11f386d Stats: 330 lines in 7 files changed: 200 ins; 116 del; 14 mod 8271170: Add unit test for what jpackage app launcher puts in the environment Reviewed-by: almatvee, herrick ------------- PR: https://git.openjdk.java.net/jdk/pull/5056 From bpb at openjdk.java.net Thu Aug 12 01:13:32 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 Aug 2021 01:13:32 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: Message-ID: 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 src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 175: > 173: throw new IllegalBlockingModeException(); > 174: } > 175: return tls.supply(); It does not look like the `SelectableChannel` branch is tested, including whether an `IllegalBlockingModeException` is thrown when it should be. src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 249: > 247: } > 248: > 249: private static long transfer(ReadableByteChannel src, WritableByteChannel dst) throws IOException { Does this method have a measurable improvement in performance over `InputStream.transferTo()`? test/jdk/sun/nio/ch/ChannelInputStream/TransferTo.java line 93: > 91: checkTransferredContents(inputStreamProvider, outputStreamProvider, createRandomBytes(1024, 4096)); > 92: // to span through several batches > 93: checkTransferredContents(inputStreamProvider, outputStreamProvider, createRandomBytes(16384, 16384)); Should some random-sized buffers be tested? (Use `jdk.test.lib.RandomFactory` factory for this, not `j.u.Random`. The existing use of `Random` is fine.) Should some testing be done of streams with non-zero initial position? test/jdk/sun/nio/ch/ChannelInputStream/TransferTo.java line 101: > 99: try (InputStream in = inputStreamProvider.input(inBytes); > 100: OutputStream out = outputStreamProvider.output(recorder::set)) { > 101: in.transferTo(out); The return value of `transferTo()` is not checked. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From bpb at openjdk.java.net Thu Aug 12 01:22:40 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 Aug 2021 01:22:40 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance Message-ID: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. ------------- Commit messages: - 8272297: FileInputStream should override transferTo() for better performance Changes: https://git.openjdk.java.net/jdk/pull/5097/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5097&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272297 Stats: 21 lines in 1 file changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5097.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5097/head:pull/5097 PR: https://git.openjdk.java.net/jdk/pull/5097 From bpb at openjdk.java.net Thu Aug 12 01:22:41 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 Aug 2021 01:22:41 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance In-Reply-To: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> Message-ID: On Thu, 12 Aug 2021 01:16:04 GMT, Brian Burkhalter wrote: > Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. Invoking `transferTo()` on a `FileInputStream` will use the superclass method which copies using looping over buffers of a fixed size. If the parameter is a `FileOutputStream`, the copy is greatly accelerated by using the `java.nio.channels.FileChannel.transferTo()` method with the `FileChannel`s of the source and destination streams. Performance measurements were made for streams of length 100000, 1000000, 100000000, and 1000000000 bytes. Throughput improvement was observed for all cases on the three usual platforms, with the largest of nearly 5X being seen on Linux because in this case the sendfile() system call is used underneath. In no case did throughput decrease. ------------- PR: https://git.openjdk.java.net/jdk/pull/5097 From serb at openjdk.java.net Thu Aug 12 05:49:28 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 12 Aug 2021 05:49:28 GMT Subject: Integrated: 8272120: Avoid looking for standard encodings in "java." modules In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. This pull request has now been integrated. Changeset: ec2fc384 Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/ec2fc384e50668b667335f973ffeb5a19bbcfb9b Stats: 127 lines in 15 files changed: 24 ins; 53 del; 50 mod 8272120: Avoid looking for standard encodings in "java." modules Reviewed-by: alanb, dfuchs, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/5063 From alanb at openjdk.java.net Thu Aug 12 06:31:22 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 12 Aug 2021 06:31:22 GMT Subject: RFR: 8271732: Regression in StringBuilder.charAt bounds checking [v4] In-Reply-To: References: Message-ID: <4O1zPz57PC0tvZmxoR6f0kf1Qb-ILVS19CX_LMqfc5g=.dfded68a-1af2-4bd1-8e77-4e2ba279a835@github.com> On Wed, 11 Aug 2021 21:40:52 GMT, Claes Redestad wrote: >> In #4738 we removed the `checkIndex(value, count)` call in `ASB.charAt` to avoid potentially getting two bounds checks in the UTF-16 case. Problem is this optimization cause a regression since `StringUTF16.charAt(..)` checks `index` against the length of the `value` array and not `count`. >> >> A correct fix that still maintain the possible performance advantage reported by #4738 is to reinstate the `checkIndex(value, count)` and call `StringUTF16.getChar` instead of `charAt`. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Fix copy-paste error Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5086 From redestad at openjdk.java.net Thu Aug 12 07:05:33 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 12 Aug 2021 07:05:33 GMT Subject: Integrated: 8271732: Regression in StringBuilder.charAt bounds checking In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 14:26:32 GMT, Claes Redestad wrote: > In #4738 we removed the `checkIndex(value, count)` call in `ASB.charAt` to avoid potentially getting two bounds checks in the UTF-16 case. Problem is this optimization cause a regression since `StringUTF16.charAt(..)` checks `index` against the length of the `value` array and not `count`. > > A correct fix that still maintain the possible performance advantage reported by #4738 is to reinstate the `checkIndex(value, count)` and call `StringUTF16.getChar` instead of `charAt`. This pull request has now been integrated. Changeset: a15b6592 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/a15b659278741337aefc15ce8002df66ce6323c0 Stats: 108 lines in 3 files changed: 106 ins; 0 del; 2 mod 8271732: Regression in StringBuilder.charAt bounds checking Reviewed-by: alanb, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/5086 From alanb at openjdk.java.net Thu Aug 12 08:43:34 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 12 Aug 2021 08:43:34 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: Message-ID: <9K3gZpDYVCFjt7WjCfW6YJKmULOHw7cv-doIFWeoI-E=.b4a84b0d-a448-4d0a-a54a-0756c899fd69@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 > I am a bit disappointed actually about that destructive answer at that late point in time, now that I worked for months on all the requested changes and tests. To prevent exactly this situation, I deliberately had the discussion started in JIRA only, and I deliberately had the original code being just a draft in the first place, and I deliberately did nearly _everything_ I was asked to (including even the most irrelevant minor code style issues). And you come up with the request to drop the code **now**? > > Certainly we could reduce the PR to just file channels, but in fact, now that I spent all the time in the non-file-channels, I wonder why I shall throw away all that work and go just with file channels actually? What is not covered that was originally covered, and what is that lots of issues you talk about? Actually I cannot see the actual problem unless you name it. There are 78 comments on this PR so far. We've tried to point out the bugs and issues at each iteration. We asked for tests because the changes introduce several code paths and implementations that would not be exercised by existing tests. There are several scenarios still missing and the patch doesn't yet have the microbenchmarks to demonstrate the improvements. I assume this is your first contribution so there will be learning curve and maybe some frustration. I think you have a better chance of success if you split this up and reduce the scope of this PR down to something manageable. Keeping the selectable channels out of this PR and focusing on the case where the input and output streams wrap file channels should make it simpler and may lead to a better solution. Reducing the scope will also reduce the burden on reviewers. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From bpb at openjdk.java.net Thu Aug 12 08:43:33 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 Aug 2021 08:43:33 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: <5v2JxcXvfhlsA_lPDTS1u7LQul5S12tNrFHtN3lmnK8=.0186f02f-6537-4ae6-beda-a4268bc047a9@github.com> Message-ID: On Wed, 11 Aug 2021 11:27:53 GMT, Alan Bateman wrote: >>> I think I fixed all requested changes. Anymore comments on this PR? >> >> I hope to get to this soon. > >> I think I fixed all requested changes. Anymore comments on this PR? > > I've looked through the latest revision. Is there any way that we could drop most of the changes to ChannelInputStream and focus on one or two specific cases? I'm asking because there are several issues, inconsistencies, and it is trying to cover many scenarios that aren't covered by the test. > > If the original motivation was file -> file then it could be simplified down to a FileChannel -> FileChannel transfer as the default provider uses file channels. We could even push some support into FileChannelImpl so that it is done while holding the position lock. I do not know exactly what @AlanBateman had in mind, but I think there is general concern about ensuring that all combinations of channel types and all execution paths are exercised. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From github.com+10835776+stsypanov at openjdk.java.net Thu Aug 12 10:07:29 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 12 Aug 2021 10:07:29 GMT Subject: Integrated: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 13:16:42 GMT, ?????? ??????? wrote: > The code in `Integer.decode()` and `Long.decode()` might allocate two instances of Integer/Long for the negative values less than -127: > > Integer result; > > result = Integer.valueOf(nm.substring(index), radix); > result = negative ? Integer.valueOf(-result.intValue()) : result; > > To avoid this we can declare 'result' as `int` and use `Integer.parseInt()` method. Same applicable for `Long` and some other classes. This pull request has now been integrated. Changeset: b29fbad9 Author: Sergey Tsypanov Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/b29fbad940808c59f30e60222a9ca7a23c8e54b9 Stats: 32 lines in 6 files changed: 19 ins; 1 del; 12 mod 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/5068 From alanb at openjdk.java.net Thu Aug 12 11:33:26 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 12 Aug 2021 11:33:26 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance In-Reply-To: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> Message-ID: <7DYDJX8xUZPyTiK0vqGbXg_J0jZp24S4XAkoGwpPvic=.0ebcb2f7-ea1b-4b2e-9d0c-ca7f5b57ed0f@github.com> On Thu, 12 Aug 2021 01:16:04 GMT, Brian Burkhalter wrote: > Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. Changes requested by alanb (Reviewer). src/java.base/share/classes/java/io/FileInputStream.java line 371: > 369: // not, then use the superclass method to copy those remaining > 370: if (fci.transferTo(pos, count, fco) == count) { > 371: return count; Are you sure this is right? FileChannel transferTo doesn't modify the source channel's position so I assume the method above will finish with the InputStream at its initial position rather than EOF. How are we on test coverage for this case? ------------- PR: https://git.openjdk.java.net/jdk/pull/5097 From bpb at openjdk.java.net Thu Aug 12 15:27:24 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 Aug 2021 15:27:24 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance In-Reply-To: <7DYDJX8xUZPyTiK0vqGbXg_J0jZp24S4XAkoGwpPvic=.0ebcb2f7-ea1b-4b2e-9d0c-ca7f5b57ed0f@github.com> References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> <7DYDJX8xUZPyTiK0vqGbXg_J0jZp24S4XAkoGwpPvic=.0ebcb2f7-ea1b-4b2e-9d0c-ca7f5b57ed0f@github.com> Message-ID: On Thu, 12 Aug 2021 11:30:16 GMT, Alan Bateman wrote: >> Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. > > src/java.base/share/classes/java/io/FileInputStream.java line 371: > >> 369: // not, then use the superclass method to copy those remaining >> 370: if (fci.transferTo(pos, count, fco) == count) { >> 371: return count; > > Are you sure this is right? FileChannel transferTo doesn't modify the source channel's position so I assume the method above will finish with the InputStream at its initial position rather than EOF. How are we on test coverage for this case? You're right, that is stupid. I don't think it affected the benchmark, but testing likely needs to be revisited. ------------- PR: https://git.openjdk.java.net/jdk/pull/5097 From lancea at openjdk.java.net Thu Aug 12 17:50:41 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 12 Aug 2021 17:50:41 GMT Subject: RFR: 8263940: NPE when creating default file system when default file system provider is packaged as JAR file on class path Message-ID: <3S_DNN9eJHOO64aa2RmCliXhv9P6eyk-Y32BhAACbjs=.e5267400-28e2-4ee7-8237-25321fb88e16@github.com> Hi all, Please review the fix for JDK-8263940 to address an issues when the default file system provider is packaged as JAR file on class path. The patch also addresses the `@bug` line for JDK-8271194 Mach5 Tier1 - Tier3 have run without issues Best, Lance ------------- Commit messages: - Fix for JDK-8263940 Changes: https://git.openjdk.java.net/jdk/pull/5103/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5103&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263940 Stats: 55 lines in 2 files changed: 49 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5103.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5103/head:pull/5103 PR: https://git.openjdk.java.net/jdk/pull/5103 From github.com+1701815+mkarg at openjdk.java.net Thu Aug 12 18:15:32 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Thu, 12 Aug 2021 18:15:32 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: <9K3gZpDYVCFjt7WjCfW6YJKmULOHw7cv-doIFWeoI-E=.b4a84b0d-a448-4d0a-a54a-0756c899fd69@github.com> References: <9K3gZpDYVCFjt7WjCfW6YJKmULOHw7cv-doIFWeoI-E=.b4a84b0d-a448-4d0a-a54a-0756c899fd69@github.com> Message-ID: On Thu, 12 Aug 2021 08:40:34 GMT, Alan Bateman wrote: >> 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 > >> I am a bit disappointed actually about that destructive answer at that late point in time, now that I worked for months on all the requested changes and tests. To prevent exactly this situation, I deliberately had the discussion started in JIRA only, and I deliberately had the original code being just a draft in the first place, and I deliberately did nearly _everything_ I was asked to (including even the most irrelevant minor code style issues). And you come up with the request to drop the code **now**? >> >> Certainly we could reduce the PR to just file channels, but in fact, now that I spent all the time in the non-file-channels, I wonder why I shall throw away all that work and go just with file channels actually? What is not covered that was originally covered, and what is that lots of issues you talk about? Actually I cannot see the actual problem unless you name it. > > There are 78 comments on this PR so far. We've tried to point out the bugs and issues at each iteration. We asked for tests because the changes introduce several code paths and implementations that would not be exercised by existing tests. There are several scenarios still missing and the patch doesn't yet have the microbenchmarks to demonstrate the improvements. > > I assume this is your first contribution so there will be learning curve and maybe some frustration. I think you have a better chance of success if you split this up and reduce the scope of this PR down to something manageable. Keeping the selectable channels out of this PR and focusing on the case where the input and output streams wrap file channels should make it simpler and may lead to a better solution. Reducing the scope will also reduce the burden on reviewers. > I do not know exactly what @AlanBateman had in mind, but I think there is general concern about ensuring that all combinations of channel types and all execution paths are exercised. @AlanBateman @bplb Does it make **any** real sense to answer your recent questions, provide the proofs, tests and benchmark results (I actually would love to *if* it makes sense) *or* will the outcome be that I *must* drop everything besides file channels *anyways* (In that case it is in vain)? As my time is just as precious as yours I really need to know that **before** I spend more weeks into code paths that you possibly decided to never accept ever. Don't get me wrong, if you see a chance to keep the code once I provided the answers I will do that, but if you do not see that chance, please frankly and unambiguously tell me **now**. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From naoto at openjdk.java.net Thu Aug 12 18:59:25 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 12 Aug 2021 18:59:25 GMT Subject: RFR: 8263940: NPE when creating default file system when default file system provider is packaged as JAR file on class path In-Reply-To: <3S_DNN9eJHOO64aa2RmCliXhv9P6eyk-Y32BhAACbjs=.e5267400-28e2-4ee7-8237-25321fb88e16@github.com> References: <3S_DNN9eJHOO64aa2RmCliXhv9P6eyk-Y32BhAACbjs=.e5267400-28e2-4ee7-8237-25321fb88e16@github.com> Message-ID: On Thu, 12 Aug 2021 17:43:48 GMT, Lance Andersen wrote: > Hi all, > > Please review the fix for JDK-8263940 to address an issues when the default file system provider is packaged as JAR file on class path. > > The patch also addresses the `@bug` line for JDK-8271194 > > Mach5 Tier1 - Tier3 have run without issues > > Best, > Lance Looks good to me, Lance. test/jdk/java/nio/file/spi/SetDefaultProvider.java line 107: > 105: .map(path -> path.getFileName().toString()) > 106: .filter(f -> f.startsWith("TestProvider")) > 107: .collect(Collectors.toList()); Nit: Could simply issue `.toList()` here. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5103 From lancea at openjdk.java.net Thu Aug 12 19:27:42 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 12 Aug 2021 19:27:42 GMT Subject: RFR: 8263940: NPE when creating default file system when default file system provider is packaged as JAR file on class path [v2] In-Reply-To: <3S_DNN9eJHOO64aa2RmCliXhv9P6eyk-Y32BhAACbjs=.e5267400-28e2-4ee7-8237-25321fb88e16@github.com> References: <3S_DNN9eJHOO64aa2RmCliXhv9P6eyk-Y32BhAACbjs=.e5267400-28e2-4ee7-8237-25321fb88e16@github.com> Message-ID: > Hi all, > > Please review the fix for JDK-8263940 to address an issues when the default file system provider is packaged as JAR file on class path. > > The patch also addresses the `@bug` line for JDK-8271194 > > Mach5 Tier1 - Tier3 have run without issues > > Best, > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Use toList() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5103/files - new: https://git.openjdk.java.net/jdk/pull/5103/files/c09d7c32..6a65fb35 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5103&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5103&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5103.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5103/head:pull/5103 PR: https://git.openjdk.java.net/jdk/pull/5103 From bpb at openjdk.java.net Thu Aug 12 19:27:43 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 Aug 2021 19:27:43 GMT Subject: RFR: 8263940: NPE when creating default file system when default file system provider is packaged as JAR file on class path [v2] In-Reply-To: References: <3S_DNN9eJHOO64aa2RmCliXhv9P6eyk-Y32BhAACbjs=.e5267400-28e2-4ee7-8237-25321fb88e16@github.com> Message-ID: On Thu, 12 Aug 2021 19:24:39 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the fix for JDK-8263940 to address an issues when the default file system provider is packaged as JAR file on class path. >> >> The patch also addresses the `@bug` line for JDK-8271194 >> >> Mach5 Tier1 - Tier3 have run without issues >> >> Best, >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Use toList() Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5103 From lancea at openjdk.java.net Thu Aug 12 19:27:44 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 12 Aug 2021 19:27:44 GMT Subject: RFR: 8263940: NPE when creating default file system when default file system provider is packaged as JAR file on class path [v2] In-Reply-To: References: <3S_DNN9eJHOO64aa2RmCliXhv9P6eyk-Y32BhAACbjs=.e5267400-28e2-4ee7-8237-25321fb88e16@github.com> Message-ID: On Thu, 12 Aug 2021 18:55:08 GMT, Naoto Sato wrote: >> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: >> >> Use toList() > > test/jdk/java/nio/file/spi/SetDefaultProvider.java line 107: > >> 105: .map(path -> path.getFileName().toString()) >> 106: .filter(f -> f.startsWith("TestProvider")) >> 107: .collect(Collectors.toList()); > > Nit: Could simply issue `.toList()` here. Thank you Naoto, it is a bit cleaner so pushed the update. ------------- PR: https://git.openjdk.java.net/jdk/pull/5103 From naoto at openjdk.java.net Thu Aug 12 20:22:04 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 12 Aug 2021 20:22:04 GMT Subject: RFR: 8260265: UTF-8 by Default [v7] In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: > This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. > > JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 > CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge branch 'master' into JDK-8260265 - Merge branch 'master' into JDK-8260265 - Merge branch 'master' into JDK-8260265 - Merge branch 'master' into JDK-8260265 - Refined `file.encoding` description - Merge branch 'master' into JDK-8260265 - Reflects comments - Removed leftover `console` references in `PrintStream` - Reflects comments - Reflects review comments - ... and 2 more: https://git.openjdk.java.net/jdk/compare/387b32b3...7d5137d3 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4733/files - new: https://git.openjdk.java.net/jdk/pull/4733/files/6f9e5eb4..7d5137d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=05-06 Stats: 53933 lines in 926 files changed: 45460 ins; 4145 del; 4328 mod Patch: https://git.openjdk.java.net/jdk/pull/4733.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4733/head:pull/4733 PR: https://git.openjdk.java.net/jdk/pull/4733 From bpb at openjdk.java.net Thu Aug 12 21:07:53 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 Aug 2021 21:07:53 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance [v2] In-Reply-To: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> Message-ID: > Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8272297: Set source position after FC.transferTo(); add test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5097/files - new: https://git.openjdk.java.net/jdk/pull/5097/files/54f14550..a199fc67 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5097&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5097&range=00-01 Stats: 133 lines in 2 files changed: 132 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5097.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5097/head:pull/5097 PR: https://git.openjdk.java.net/jdk/pull/5097 From iris at openjdk.java.net Thu Aug 12 21:42:25 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 12 Aug 2021 21:42:25 GMT Subject: RFR: 8263940: NPE when creating default file system when default file system provider is packaged as JAR file on class path [v2] In-Reply-To: References: <3S_DNN9eJHOO64aa2RmCliXhv9P6eyk-Y32BhAACbjs=.e5267400-28e2-4ee7-8237-25321fb88e16@github.com> Message-ID: On Thu, 12 Aug 2021 19:27:42 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the fix for JDK-8263940 to address an issues when the default file system provider is packaged as JAR file on class path. >> >> The patch also addresses the `@bug` line for JDK-8271194 >> >> Mach5 Tier1 - Tier3 have run without issues >> >> Best, >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Use toList() Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5103 From joehw at openjdk.java.net Thu Aug 12 22:24:24 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 12 Aug 2021 22:24:24 GMT Subject: RFR: 8263940: NPE when creating default file system when default file system provider is packaged as JAR file on class path [v2] In-Reply-To: References: <3S_DNN9eJHOO64aa2RmCliXhv9P6eyk-Y32BhAACbjs=.e5267400-28e2-4ee7-8237-25321fb88e16@github.com> Message-ID: On Thu, 12 Aug 2021 19:27:42 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the fix for JDK-8263940 to address an issues when the default file system provider is packaged as JAR file on class path. >> >> The patch also addresses the `@bug` line for JDK-8271194 >> >> Mach5 Tier1 - Tier3 have run without issues >> >> Best, >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Use toList() Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5103 From bpb at openjdk.java.net Thu Aug 12 23:36:26 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 12 Aug 2021 23:36:26 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance [v2] In-Reply-To: References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> Message-ID: On Thu, 12 Aug 2021 21:07:53 GMT, Brian Burkhalter wrote: >> Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8272297: Set source position after FC.transferTo(); add test Without the source change the test fails, but passes with the change in place. ------------- PR: https://git.openjdk.java.net/jdk/pull/5097 From alanb at openjdk.java.net Fri Aug 13 07:29:25 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 13 Aug 2021 07:29:25 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance [v2] In-Reply-To: References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> Message-ID: On Thu, 12 Aug 2021 21:07:53 GMT, Brian Burkhalter wrote: >> Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8272297: Set source position after FC.transferTo(); add test src/java.base/share/classes/java/io/FileInputStream.java line 364: > 362: FileChannel fci = getChannel(); > 363: long pos = fci.position(); > 364: long count = fci.size() - pos; It might be better to just specify the count as Long.MAX_VALUE and test the size after the transfer. This would be a bit more robust in the scenario that the file grows and would avoid fallback when the file is truncated, e.g. FileChannel fc = getChannel(); long pos = fc.position(); long transferred = fc.transferTo(pos, Long.MAX_VALUE, out.getChannel()); long newPos = pos + transferred; fc.position(newPos); if (newPos >= fc.size()) { return transferred; } ------------- PR: https://git.openjdk.java.net/jdk/pull/5097 From alanb at openjdk.java.net Fri Aug 13 08:15:27 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 13 Aug 2021 08:15:27 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance [v2] In-Reply-To: References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> Message-ID: <_PoigaJ1WWgkDNmU6fv5fNjZ0oLQHtWmYlyWsBh1XbQ=.98b5165b-c109-41a9-942a-65f2b436315e@github.com> On Thu, 12 Aug 2021 21:07:53 GMT, Brian Burkhalter wrote: >> Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8272297: Set source position after FC.transferTo(); add test src/java.base/share/classes/java/io/FileInputStream.java line 377: > 375: } > 376: } > 377: return super.transferTo(out); I think there is also another bug here for the case that transferTo does a partial transfer, it should be: return transferred + super.transferTo(out)); ------------- PR: https://git.openjdk.java.net/jdk/pull/5097 From github.com+919349+skatescout at openjdk.java.net Fri Aug 13 08:35:36 2021 From: github.com+919349+skatescout at openjdk.java.net (SkateScout) Date: Fri, 13 Aug 2021 08:35:36 GMT Subject: RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable [v2] In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 21:06:00 GMT, ?????? ??????? wrote: >> The code in `Integer.decode()` and `Long.decode()` might allocate two instances of Integer/Long for the negative values less than -127: >> >> Integer result; >> >> result = Integer.valueOf(nm.substring(index), radix); >> result = negative ? Integer.valueOf(-result.intValue()) : result; >> >> To avoid this we can declare 'result' as `int` and use `Integer.parseInt()` method. Same applicable for `Long` and some other classes. > > ?????? ??????? 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: > > - 8267844: Add benchmarks for Integer/Long.decode() > - 8267844: Rid useless substring when calling Integer/Long.parse*() > - Merge branch 'master' into 8267844 > - Merge branch 'master' into 8267844 > - 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable Hi, i check Long.java line 1301...1311 and i am not sure if this code is really good. 1) If negative is false the whole part ends with two times the same substring and this implies the same error. 2) If negative is true and we get an error than we can throw the error without an second parse step or we can use the substring from the first round. 3) Also as mentioned above the parseLong(text,radix) should be changed to parseLong(seq, beginIndex, endIndex, radix) this would avoid at least in the positive case the substring at all. 4) The same points are with Integer as well. try { result = parseLong(nm.substring(index), radix); result = negative ? -result : result; } catch (NumberFormatException e) { // If number is Long.MIN_VALUE, we'll end up here. The next line // handles this case, and causes any genuine format error to be // rethrown. String constant = negative ? ("-" + nm.substring(index)) : nm.substring(index); result = parseLong(constant, radix); } ------------- PR: https://git.openjdk.java.net/jdk/pull/5068 From redestad at openjdk.java.net Fri Aug 13 09:42:29 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 13 Aug 2021 09:42:29 GMT Subject: RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable [v2] In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 21:26:08 GMT, SkateScout wrote: > Hi, > i check Long.java line 1301...1311 and i am not sure if this code is really good. > > 1. If negative is false the whole part ends with two times the same substring and this implies the same error. > > 2. If negative is true and we get an error than we can throw the error without an second parse step or we can use the substring from the first round. > > 3. Also as mentioned above the parseLong(text,radix) should be changed to parseLong(seq, beginIndex, endIndex, radix) > this would avoid at least in the positive case the substring at all. > > 4. The same points are with Integer as well. > try { > result = parseLong(nm.substring(index), radix); > result = negative ? -result : result; > } catch (NumberFormatException e) { > // If number is Long.MIN_VALUE, we'll end up here. The next line > // handles this case, and causes any genuine format error to be > // rethrown. > String constant = negative ? ("-" + nm.substring(index)) > : nm.substring(index); > result = parseLong(constant, radix); > } The pre-existing logic here is iffy, but I think it is correct. For Integer: If negative is true, then parsing "2147483648" (Integer.MAX_VALUE + 1) would throw, be reparsed as "-2147483648" and then be accepted as Integer.MIN_VALUE. This is the only case that should be non-exceptional, but it should also be exceedingly rare in practice. For negative values it improves the error messages a bit to add the "-" and reparse. Improving the catch clauses with `parseLong(CharSequence, int, int, int)` and adding an `if (!negative) throw e` case to the catch could theoretically improve performance of parsing the MIN_VALUE edge case and repeated decoding of malformed positive numbers, but these are rare or exceptional cases where we should favor simplicity over optimal performance ------------- PR: https://git.openjdk.java.net/jdk/pull/5068 From alanb at openjdk.java.net Fri Aug 13 12:57:29 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 13 Aug 2021 12:57:29 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: Message-ID: 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 > Does it make **any** real sense to answer your recent questions, provide the proofs, tests and benchmark results (I actually would love to _if_ it makes sense) _or_ will the outcome be that I _must_ drop everything besides file channels _anyways_ (In that case it is in vain)? As my time is just as precious as yours I really need to know that **before** I spend more weeks into code paths that you possibly decided to never accept ever. Don't get me wrong, if you see a chance to keep the code once I provided the answers I will do that, but if you do not see that chance, please frankly and unambiguously tell me **now**. Thanks. I think the best course of action is to reduce the scope of this PR to the file channel cases. There is no reason why future PRs can't build on this and add implementations for other channel types. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From github.com+919349+skatescout at openjdk.java.net Fri Aug 13 13:19:39 2021 From: github.com+919349+skatescout at openjdk.java.net (SkateScout) Date: Fri, 13 Aug 2021 13:19:39 GMT Subject: RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable [v2] In-Reply-To: References: Message-ID: On Tue, 10 Aug 2021 21:06:00 GMT, ?????? ??????? wrote: >> The code in `Integer.decode()` and `Long.decode()` might allocate two instances of Integer/Long for the negative values less than -127: >> >> Integer result; >> >> result = Integer.valueOf(nm.substring(index), radix); >> result = negative ? Integer.valueOf(-result.intValue()) : result; >> >> To avoid this we can declare 'result' as `int` and use `Integer.parseInt()` method. Same applicable for `Long` and some other classes. > > ?????? ??????? 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: > > - 8267844: Add benchmarks for Integer/Long.decode() > - 8267844: Rid useless substring when calling Integer/Long.parse*() > - Merge branch 'master' into 8267844 > - Merge branch 'master' into 8267844 > - 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable OK even if we keep out the edge case in the try block the "parseLong(nm.substring(index), radix)" could be replaced as already mentioned with parseLong(nm. index, nm.length(), radix) and in the catch block the idea to throw an "nice" error can be misleading. since -02147483648 for example would become -2147483648 because the radix is 8. Since per Radix only one String is possible to get through would if not be faster and more clear to check (compare) if it is the matching string and return the correct value else throw the error. This is also easy to read and even if is on the edge avoid substring , concationation and reparsing. ------------- PR: https://git.openjdk.java.net/jdk/pull/5068 From redestad at openjdk.java.net Fri Aug 13 13:47:27 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 13 Aug 2021 13:47:27 GMT Subject: RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable [v2] In-Reply-To: References: Message-ID: On Fri, 13 Aug 2021 13:16:04 GMT, SkateScout wrote: > OK even if we keep out the edge case in the try block the "parseLong(nm.substring(index), radix)" could be replaced as already mentioned with parseLong(nm. index, nm.length(), radix) I think it already was: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Long.java#L1287 > and in the catch block the idea to throw an "nice" error can be misleading. > since -02147483648 for example would become -2147483648 because the radix is 8. Yes, it's slightly misleading that the radix specifier gets cropped out, but the error message does include the radix information so it's not a bug technically: jshell> Integer.decode("-01234567890123"); | Exception java.lang.NumberFormatException: For input string: "-1234567890123" under radix 8 > Since per Radix only one String is possible to get through would if not be faster and more clear to check (compare) if it is the matching string and return the correct value else throw the error. This is also easy to read and even if is on the edge avoid substring , concationation and reparsing. It might be a bit faster for that one non-exceptional accepted input, sure. It could also incur a cost on the fast path due increasing the weight of the code. You'd need to carefully measure that the added logic and checks doesn't cause any trouble elsewhere. ------------- PR: https://git.openjdk.java.net/jdk/pull/5068 From rkennke at openjdk.java.net Fri Aug 13 14:35:25 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 13 Aug 2021 14:35:25 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance [v2] In-Reply-To: References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> Message-ID: On Thu, 12 Aug 2021 21:07:53 GMT, Brian Burkhalter wrote: >> Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8272297: Set source position after FC.transferTo(); add test Is this what you have been asking @mkarg in #4263 to do? Optimize transferTo() only for FileInputStream? Would it interfere with #4263? ------------- PR: https://git.openjdk.java.net/jdk/pull/5097 From bpb at openjdk.java.net Fri Aug 13 14:41:26 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 13 Aug 2021 14:41:26 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance [v2] In-Reply-To: References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> Message-ID: <7G0Mgfj-gYJm0ZTxFCAOq_X5AEvu8wOt2KXuFJlC3lw=.c0dc5fa8-5c2b-45aa-84d4-111dbc14296b@github.com> On Thu, 12 Aug 2021 21:07:53 GMT, Brian Burkhalter wrote: >> Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8272297: Set source position after FC.transferTo(); add test There is no overlap with #4263. ------------- PR: https://git.openjdk.java.net/jdk/pull/5097 From alanb at openjdk.java.net Fri Aug 13 14:44:24 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 13 Aug 2021 14:44:24 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance [v2] In-Reply-To: References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> Message-ID: <7PnVd89ihHGWYtOo66h68gX8pf2UQsHHP9WNycpSGx0=.3d112a2d-1f63-4114-89e0-6cc83a0c0a79@github.com> On Fri, 13 Aug 2021 14:32:41 GMT, Roman Kennke wrote: > Is this what you have been asking @mkarg in #4263 to do? Optimize transferTo() only for FileInputStream? Would it interfere with #4263? #4263 is the input stream returned by Channels.newInputStream where the source may be a FileChannel and the output stream specified to InputStream::transferTo may be connected to a FileChannel. ------------- PR: https://git.openjdk.java.net/jdk/pull/5097 From bpb at openjdk.java.net Fri Aug 13 14:53:45 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 13 Aug 2021 14:53:45 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance [v3] In-Reply-To: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> Message-ID: > Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8272297: Improve growing source and partial transfer cases ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5097/files - new: https://git.openjdk.java.net/jdk/pull/5097/files/a199fc67..796248e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5097&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5097&range=01-02 Stats: 13 lines in 1 file changed: 1 ins; 3 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/5097.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5097/head:pull/5097 PR: https://git.openjdk.java.net/jdk/pull/5097 From lancea at openjdk.java.net Fri Aug 13 16:14:24 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 13 Aug 2021 16:14:24 GMT Subject: Integrated: 8263940: NPE when creating default file system when default file system provider is packaged as JAR file on class path In-Reply-To: <3S_DNN9eJHOO64aa2RmCliXhv9P6eyk-Y32BhAACbjs=.e5267400-28e2-4ee7-8237-25321fb88e16@github.com> References: <3S_DNN9eJHOO64aa2RmCliXhv9P6eyk-Y32BhAACbjs=.e5267400-28e2-4ee7-8237-25321fb88e16@github.com> Message-ID: On Thu, 12 Aug 2021 17:43:48 GMT, Lance Andersen wrote: > Hi all, > > Please review the fix for JDK-8263940 to address an issues when the default file system provider is packaged as JAR file on class path. > > The patch also addresses the `@bug` line for JDK-8271194 > > Mach5 Tier1 - Tier3 have run without issues > > Best, > Lance This pull request has now been integrated. Changeset: 717792c3 Author: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/717792c3b728584413572e7aede83290779be2a2 Stats: 55 lines in 2 files changed: 49 ins; 2 del; 4 mod 8263940: NPE when creating default file system when default file system provider is packaged as JAR file on class path Reviewed-by: naoto, bpb, iris, joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/5103 From alanb at openjdk.java.net Fri Aug 13 17:46:26 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 13 Aug 2021 17:46:26 GMT Subject: RFR: 8263940: NPE when creating default file system when default file system provider is packaged as JAR file on class path [v2] In-Reply-To: References: <3S_DNN9eJHOO64aa2RmCliXhv9P6eyk-Y32BhAACbjs=.e5267400-28e2-4ee7-8237-25321fb88e16@github.com> Message-ID: On Thu, 12 Aug 2021 19:27:42 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the fix for JDK-8263940 to address an issues when the default file system provider is packaged as JAR file on class path. >> >> The patch also addresses the `@bug` line for JDK-8271194 >> >> Mach5 Tier1 - Tier3 have run without issues >> >> Best, >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Use toList() test/jdk/java/nio/file/spi/SetDefaultProvider.java line 26: > 24: /** > 25: * @test > 26: * @bug 4313887 7006126 8142968 8178380 8183320 8210112 8266345 8263940 Thanks for correcting the @bug tag. test/jdk/java/nio/file/spi/SetDefaultProvider.java line 89: > 87: createFileSystemProviderJar(jar, Path.of(testClasses)); > 88: String classpath = jar + File.pathSeparator + testClasses > 89: + File.separator + "modules" + File.separator + "m"; This ends up with two copies of TestFIleSystemProvider on the class path. I think we should compile TestProvider to a different directory. That will eliminate the need to filter the classes when creating the JAR file. test/jdk/java/nio/file/spi/SetDefaultProvider.java line 99: > 97: */ > 98: private void createFileSystemProviderJar(Path jar, Path dir) throws IOException { > 99: In this test, the supporting methods are at the end of the source file, probably should keep it consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/5103 From alanb at openjdk.java.net Fri Aug 13 18:44:24 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 13 Aug 2021 18:44:24 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance [v3] In-Reply-To: References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> Message-ID: <_YBrbp5PoNJ_l-tMq7rvdXqC01uJysOxnJyxel0Jkl8=.5d61f3e0-78b3-4800-9570-7500d31cb8aa@github.com> On Fri, 13 Aug 2021 14:53:45 GMT, Brian Burkhalter wrote: >> Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8272297: Improve growing source and partial transfer cases src/java.base/share/classes/java/io/FileInputStream.java line 367: > 365: long count = fc.size() - pos; > 366: if (pos >= 0 && count >= 0) { > 367: transferred = fc.transferTo(pos, Long.MAX_VALUE, fos.getChannel()); This version looks better I think we can drop L365 and 366. The position cannot be negative and checking that size >= pos isn't useful. In other words, you can just call transferTo with the position without these checks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5097 From bpb at openjdk.java.net Fri Aug 13 19:20:48 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 13 Aug 2021 19:20:48 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance [v4] In-Reply-To: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> Message-ID: <_YXU9vBn7G_lEfLefUunU92MWEcnyotVK71JLke9xrk=.964d80d6-3c64-4cfc-9e90-926e383d10d9@github.com> > Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8272297: Remove unneeded check of position and couunt ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5097/files - new: https://git.openjdk.java.net/jdk/pull/5097/files/796248e7..3e575ba2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5097&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5097&range=02-03 Stats: 8 lines in 1 file changed: 0 ins; 3 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5097.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5097/head:pull/5097 PR: https://git.openjdk.java.net/jdk/pull/5097 From alanb at openjdk.java.net Fri Aug 13 19:26:32 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 13 Aug 2021 19:26:32 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance [v4] In-Reply-To: <_YXU9vBn7G_lEfLefUunU92MWEcnyotVK71JLke9xrk=.964d80d6-3c64-4cfc-9e90-926e383d10d9@github.com> References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> <_YXU9vBn7G_lEfLefUunU92MWEcnyotVK71JLke9xrk=.964d80d6-3c64-4cfc-9e90-926e383d10d9@github.com> Message-ID: <0L0uEJhQSHRZjGzgNUb5w4jC838Tb7JfA7MXx_tF6Qk=.36d9469e-4d1d-4476-9511-1a52a8b8fcdf@github.com> On Fri, 13 Aug 2021 19:20:48 GMT, Brian Burkhalter wrote: >> Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8272297: Remove unneeded check of position and couunt src/java.base/share/classes/java/io/FileInputStream.java line 373: > 371: } > 372: return transferred + super.transferTo(out); > 373: } Good, I think this version is right. ------------- PR: https://git.openjdk.java.net/jdk/pull/5097 From github.com+5381337+cc007 at openjdk.java.net Fri Aug 13 19:53:41 2021 From: github.com+5381337+cc007 at openjdk.java.net (CC007) Date: Fri, 13 Aug 2021 19:53:41 GMT Subject: RFR: 8272137: Make Iterable classes streamable Message-ID: create Streamable and ParallelStreamable interface and use them in Collection and Optional ------------- Commit messages: - 8272137: no CR - 8272137: create Streamable and ParallelStreamable interface and use in Collection and Optional Changes: https://git.openjdk.java.net/jdk/pull/5050/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5050&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272137 Stats: 104 lines in 4 files changed: 101 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5050.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5050/head:pull/5050 PR: https://git.openjdk.java.net/jdk/pull/5050 From github.com+5381337+cc007 at openjdk.java.net Fri Aug 13 19:53:42 2021 From: github.com+5381337+cc007 at openjdk.java.net (CC007) Date: Fri, 13 Aug 2021 19:53:42 GMT Subject: RFR: 8272137: Make Iterable classes streamable In-Reply-To: References: Message-ID: <9ya5hhCQEXrHEPDwDwIdQIBERosRSYdape8cL_Fpsn0=.c7699310-6dcf-412c-b704-a60c0b116c4f@github.com> On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional Something seemed to have gone wrong with the jcheck ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From bchristi at openjdk.java.net Fri Aug 13 20:22:28 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 13 Aug 2021 20:22:28 GMT Subject: RFR: 8271302: Regex Test Refresh In-Reply-To: References: Message-ID: <_jpkGZFcS9zL0JKgTHBD4-1eKEAKTP76i0evJd073bc=.8172da72-d099-4129-83ed-f028fd8e1e18@github.com> On Wed, 11 Aug 2021 18:22:42 GMT, Ian Graves wrote: > 8271302: Regex Test Refresh Changes requested by bchristi (Reviewer). In the JBS issue, it looks like the Description was put in the Environment. :) test/jdk/java/util/regex/RegExTest.java line 291: > 289: > 290: int resultStart1 = mr.start(); > 291: assertEquals(matcherStart1, resultStart1, "equal matchers have equal start indices"); Should the message be that they *don't* have equal start indices ? test/jdk/java/util/regex/RegExTest.java line 2362: > 2360: > 2361: { "test\ud834\uddc0", "test\ud834\uddc0", "m", true }, > 2362: //{ "test\ud834\uddbc\ud834\udd6f", "test\ud834\uddc0", "m", true }, //problem Should an issue be filed for these //problems ? test/jdk/java/util/regex/RegExTest.java line 3952: > 3950: > 3951: m = Pattern.compile("\\H").matcher(matcherSubstring); > 3952: assertTrue(m.find() || ng.equals(m.group())); Should this be: `assertTrue(m.find() && ng.equals(m.group()));` ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From github.com+5381337+cc007 at openjdk.java.net Fri Aug 13 23:21:21 2021 From: github.com+5381337+cc007 at openjdk.java.net (CC007) Date: Fri, 13 Aug 2021 23:21:21 GMT Subject: RFR: 8272137: Make Iterable classes streamable In-Reply-To: References: Message-ID: <-CbvlC3xxNgh7OCgDruv6OwSUtuxxXGahZ5iBX8aZik=.58cf815f-0d35-4b0e-832a-d266ecf37a2b@github.com> On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional I couldn't think of any, but if there are more places where these interfaces could be used, please tell me, so I can add them. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From github.com+7806504+liach at openjdk.java.net Sat Aug 14 00:56:21 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Sat, 14 Aug 2021 00:56:21 GMT Subject: RFR: 8272137: Make Iterable classes streamable In-Reply-To: References: Message-ID: <11ucz9zuyd0t90gmODhTlHhVPFs8F-iky_cVVqFowoQ=.95e5befd-3a07-473d-93ad-efa77ae47734@github.com> On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional Aren't all iterable implementations effectively streamable if they properly implement `spliterator`? And the spliterator implementation can always be sequential or parallel, dependent on how you feed it into `StreamSupport`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From forax at openjdk.java.net Sat Aug 14 09:59:24 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Sat, 14 Aug 2021 09:59:24 GMT Subject: RFR: 8272137: Make Iterable classes streamable In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional Hi Rick, I do not think that such interfaces are a good addition to the JDK, we do not want to promote the fact that you can create a Stream from an Iterable because the resulting Stream is not efficient (or is not as efficient as it could be) and we can already uses a Supplier if we want to to represent a factory of streams See my comment on the bug for more details ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From github.com+5381337+cc007 at openjdk.java.net Sat Aug 14 11:15:25 2021 From: github.com+5381337+cc007 at openjdk.java.net (CC007) Date: Sat, 14 Aug 2021 11:15:25 GMT Subject: RFR: 8272137: Make Iterable classes streamable In-Reply-To: References: Message-ID: <0-x0D1QTTbt7ziKLl7xk1yA-SA6ISx2pBF5-qVq87jo=.30ef02aa-f97b-4549-b02c-fe2de28550b6@github.com> On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional The name of this pull request is a bit wrong, but it had to be the same as the JBS name. The interfaces don't make the Iterable have stream and parallelStream methods, but are two separate interfaces to denote that an object can be streamed. These interfaces are fully decoupled from the Iterable interface and it is merely suggested that these can be used together in cases that an object is both Iterable and Streamable. No implementation is implied and has to be provided by the object or its superclasses or other interfaces (like collection). ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From github.com+5381337+cc007 at openjdk.java.net Sat Aug 14 11:28:27 2021 From: github.com+5381337+cc007 at openjdk.java.net (CC007) Date: Sat, 14 Aug 2021 11:28:27 GMT Subject: RFR: 8272137: Make Iterable classes streamable In-Reply-To: <11ucz9zuyd0t90gmODhTlHhVPFs8F-iky_cVVqFowoQ=.95e5befd-3a07-473d-93ad-efa77ae47734@github.com> References: <11ucz9zuyd0t90gmODhTlHhVPFs8F-iky_cVVqFowoQ=.95e5befd-3a07-473d-93ad-efa77ae47734@github.com> Message-ID: On Sat, 14 Aug 2021 00:53:06 GMT, liach wrote: > Aren't all iterable implementations effectively streamable if they properly implement `spliterator`? And the spliterator implementation can always be sequential or parallel, dependent on how you feed it into `StreamSupport`. Yes indeed, but to add extra methods to the Iterable interface itself could have compatibility or possible security issues depending on whether these methods are abstract or not resp. Therefore I made it a fully separate interface here and used it in places with known implementations (Collection and Optional) so that there's no changes in the exposed API of the other classes. The only difference is that you can now make use of the fact that these interfaces extend Streamable and/or ParallelStreamable ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From brian.goetz at oracle.com Sat Aug 14 13:28:19 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 14 Aug 2021 13:28:19 +0000 Subject: RFR: 8272137: Make Iterable classes streamable In-Reply-To: References: Message-ID: <35CD64C2-1BA7-4ABF-A193-AD643DC3DA15@oracle.com> Starting with a PR is not the way to add significant API surface to the JDK. You have to first build consensus on the mailing list for the design concept before we start talking about code. FTR, Interfaces like these were already discussed and rejected in the JSR 335 design discussions. Sent from my iPad > On Aug 14, 2021, at 6:00 AM, R?mi Forax wrote: > > ?On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > >> create Streamable and ParallelStreamable interface and use them in Collection and Optional > > Hi Rick, > I do not think that such interfaces are a good addition to the JDK, > we do not want to promote the fact that you can create a Stream from an Iterable because the resulting Stream is not efficient (or is not as efficient as it could be) and we can already uses a Supplier if we want to to represent a factory of streams > > See my comment on the bug for more details > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5050 From briangoetz at openjdk.java.net Sat Aug 14 15:16:24 2021 From: briangoetz at openjdk.java.net (Brian Goetz) Date: Sat, 14 Aug 2021 15:16:24 GMT Subject: RFR: 8272137: Make Iterable classes streamable In-Reply-To: References: Message-ID: <3UYP99N9KsmZRtf3b6HEnN7iK44iBJO42J2Aa5KFbdA=.f0be758a-5a22-4eaa-bbc3-4f82089def3c@github.com> On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional I object to this change. These issues were explored in the JSR 335 EG and it was agreed that this abstraction did not carry its weight. In any case, it is premature to bring a PR for a significant API change that has not been discussed first on corelibs-dev. Please withdraw the PR, and if you want to continue the discussion, bring it to corelibs-dev. ------------- Changes requested by briangoetz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5050 From github.com+5381337+cc007 at openjdk.java.net Sun Aug 15 00:56:27 2021 From: github.com+5381337+cc007 at openjdk.java.net (CC007) Date: Sun, 15 Aug 2021 00:56:27 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: <3UYP99N9KsmZRtf3b6HEnN7iK44iBJO42J2Aa5KFbdA=.f0be758a-5a22-4eaa-bbc3-4f82089def3c@github.com> References: <3UYP99N9KsmZRtf3b6HEnN7iK44iBJO42J2Aa5KFbdA=.f0be758a-5a22-4eaa-bbc3-4f82089def3c@github.com> Message-ID: <82u1MHKv4erxVT1csc5DhioWtZL904sJtydUdklPvbY=.c14d29d1-6ae4-4737-bc3c-3200eee6c362@github.com> On Sat, 14 Aug 2021 15:13:39 GMT, Brian Goetz wrote: > I object to this change. These issues were explored in the JSR 335 EG and it was agreed that this abstraction did not carry its weight. In any case, it is premature to bring a PR for a significant API change that has not been discussed first on corelibs-dev. Please withdraw the PR, and if you want to continue the discussion, bring it to corelibs-dev. I agree with the spliterator performance issues and the ability to be able to create IntStreams from Iterable. Therefore option 1 and 2 from JDK-8272137 seem fairly unfeasible to implement. This was already hinted at there, but for different reasons. This PR however implements option 4: an option that doesn't actually make the Iterable class have a stream method, but instead abstracts the stream method to an interface. This method is then implemented by Collection and Optional. It also allows other code to implement this interface. Using this implementation, you don't have the issues that the JSR 335 EG specified that would be present if Iterable itself were to be made Streamable. You wouldn't want that anyway, because streamability and iterability are two similar but very separate concerns in Java. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From github.com+5381337+cc007 at openjdk.java.net Sun Aug 15 00:59:25 2021 From: github.com+5381337+cc007 at openjdk.java.net (CC007) Date: Sun, 15 Aug 2021 00:59:25 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional Changed the title, since it seemed to cause confusion. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From briangoetz at openjdk.java.net Sun Aug 15 01:10:25 2021 From: briangoetz at openjdk.java.net (Brian Goetz) Date: Sun, 15 Aug 2021 01:10:25 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional I understand what you are proposing. I do not believe Streamable carries its weight. Sent from my iPad > On Aug 14, 2021, at 8:53 PM, CC007 ***@***.***> wrote: > > ? > I object to this change. These issues were explored in the JSR 335 EG and it was agreed that this abstraction did not carry its weight. In any case, it is premature to bring a PR for a significant API change that has not been discussed first on corelibs-dev. Please withdraw the PR, and if you want to continue the discussion, bring it to corelibs-dev. > > I agree with the spliterator performance issues and the ability to be able to create IntStreams from Iterable. Therefore option 1 and 2 from JDK-8272137 seem fairly unfeasible to implement. This was already hinted at there, but for different reasons. > > This PR however implements option 4: an option that doesn't actually make the Iterable class have a stream method, but instead abstracts the stream method to an interface. This method is then implemented by Collection and Optional. It also allows other code to implement this interface. > > Using this implementation, you don't have the issues that the JSR 335 EG specified that would be present if Iterable itself were to be made Streamable. You wouldn't want that anyway, because streamability and iterability are two similar but very separate concerns in Java. > > ? > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or unsubscribe. > Triage notifications on the go with GitHub Mobile for iOS or Android. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From github.com+5381337+cc007 at openjdk.java.net Sun Aug 15 01:13:32 2021 From: github.com+5381337+cc007 at openjdk.java.net (CC007) Date: Sun, 15 Aug 2021 01:13:32 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: On Sun, 15 Aug 2021 01:07:10 GMT, Brian Goetz wrote: > I understand what you are proposing. I do not believe Streamable carries its weight. That argument seems subjective. Could you elaborate on that in an objective manner? ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From briangoetz at openjdk.java.net Sun Aug 15 01:46:32 2021 From: briangoetz at openjdk.java.net (Brian Goetz) Date: Sun, 15 Aug 2021 01:46:32 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional To reiterate: These issues were explored in the JSR 335 EG and it was agreed that this abstraction did not carry its weight. In any case, it is premature to bring a PR for a significant API change that has not been discussed first on corelibs-dev. Please withdraw the PR, and if you want to continue the discussion, bring it to corelibs-dev. Sent from my iPad > On Aug 14, 2021, at 9:10 PM, CC007 ***@***.***> wrote: > > ? > I understand what you are proposing. I do not believe Streamable carries its weight. > > That argument seems subjective. Could you elaborate on that in an objective manner? > > ? > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or unsubscribe. > Triage notifications on the go with GitHub Mobile for iOS or Android. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From github.com+5381337+cc007 at openjdk.java.net Sun Aug 15 02:48:29 2021 From: github.com+5381337+cc007 at openjdk.java.net (CC007) Date: Sun, 15 Aug 2021 02:48:29 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: <4uq03074s-8clKL7xclc8aQbVvxnUFQuqgxcK7aP6Cg=.cbdfb171-2a75-43b5-81e4-c7bb08f54770@github.com> On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional I read through [these posts](http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-June/thread.html#1910) and while I did see good reasons for not moving stream to Iterable, I didn't see any mention of a separate Streamable-like interface, so could you elaborate on that it "did not carry its weight"? ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From turbanoff at gmail.com Sun Aug 15 09:12:09 2021 From: turbanoff at gmail.com (Andrey Turbanov) Date: Sun, 15 Aug 2021 12:12:09 +0300 Subject: 'Condition is always false' in 'BigInteger#multiply(BigInteger, boolean)' Message-ID: Hello. I found suspicious condition in method "java.math.BigInteger#multiply(java.math.BigInteger, boolean)" It's detected by IntelliJ IDEA inspection 'Constant conditions & exceptions' ``` if (bitLength(mag, mag.length) + bitLength(val.mag, val.mag.length) > 32L*MAX_MAG_LENGTH) { reportOverflow(); } ``` Method bitLength returns 'int', hence the left operand of '>' comparison is 'int' too. But the right operand of '>' comparison is 'long' with value == Integer.MAX_VALUE + 1. It means this condition is always false. Reproducer: BigInteger a = new BigInteger(1073742825, ThreadLocalRandom.current()); BigInteger b = new BigInteger(1073742825, ThreadLocalRandom.current()); BigInteger c = a.multiply(b); Andrey Turbanov From brian.goetz at oracle.com Sun Aug 15 13:29:31 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 15 Aug 2021 09:29:31 -0400 Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: <4uq03074s-8clKL7xclc8aQbVvxnUFQuqgxcK7aP6Cg=.cbdfb171-2a75-43b5-81e4-c7bb08f54770@github.com> References: <4uq03074s-8clKL7xclc8aQbVvxnUFQuqgxcK7aP6Cg=.cbdfb171-2a75-43b5-81e4-c7bb08f54770@github.com> Message-ID: For the third time: This discussion illustrates why the PR was premature; the design was not agreed upon first.? High-level design discussions (i.e., "is this a good design", "is this a good idea at all", "are we solving the right problem", "does it need to be solved in the JDK") should happen first on the discussion lists; if they happen on a PR like this, that's clear evidence that important steps have been skipped. On 8/14/2021 10:48 PM, CC007 wrote: > On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > >> create Streamable and ParallelStreamable interface and use them in Collection and Optional > I read through [these posts](http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-June/thread.html#1910) and while I did see good reasons for not moving stream to Iterable, I didn't see any mention of a separate Streamable-like interface, so could you elaborate on that it "did not carry its weight"? > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5050 From github.com+1701815+mkarg at openjdk.java.net Sun Aug 15 13:40:36 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sun, 15 Aug 2021 13:40:36 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: Message-ID: On Fri, 13 Aug 2021 12:54:55 GMT, Alan Bateman wrote: > > Does it make **any** real sense to answer your recent questions, provide the proofs, tests and benchmark results (I actually would love to _if_ it makes sense) _or_ will the outcome be that I _must_ drop everything besides file channels _anyways_ (In that case it is in vain)? As my time is just as precious as yours I really need to know that **before** I spend more weeks into code paths that you possibly decided to never accept ever. Don't get me wrong, if you see a chance to keep the code once I provided the answers I will do that, but if you do not see that chance, please frankly and unambiguously tell me **now**. Thanks. > > I think the best course of action is to reduce the scope of this PR to the file channel cases. There is no reason why future PRs can't build on this and add implementations for other channel types. Agreed, I will split this PR into several PRs, so we can start with the low-hanging fruits first and later dive into the more complex cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From Alan.Bateman at oracle.com Sun Aug 15 16:19:14 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 15 Aug 2021 17:19:14 +0100 Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: <4uq03074s-8clKL7xclc8aQbVvxnUFQuqgxcK7aP6Cg=.cbdfb171-2a75-43b5-81e4-c7bb08f54770@github.com> Message-ID: On 15/08/2021 14:29, Brian Goetz wrote: > For the third time: This discussion illustrates why the PR was > premature; the design was not agreed upon first.? High-level design > discussions (i.e., "is this a good design", "is this a good idea at > all", "are we solving the right problem", "does it need to be solved > in the JDK") should happen first on the discussion lists; if they > happen on a PR like this, that's clear evidence that important steps > have been skipped. The OpenJDK developers guide has been getting some TLC in recent months. One of the improvements is the "Socialize your change" section [1] which does try to make it clear that API proposals should be discussed on the mailing list before going near a PR. -Alan [1] https://openjdk.java.net/guide/#socialize-your-change From alanb at openjdk.java.net Sun Aug 15 16:22:33 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 15 Aug 2021 16:22:33 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance [v4] In-Reply-To: <_YXU9vBn7G_lEfLefUunU92MWEcnyotVK71JLke9xrk=.964d80d6-3c64-4cfc-9e90-926e383d10d9@github.com> References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> <_YXU9vBn7G_lEfLefUunU92MWEcnyotVK71JLke9xrk=.964d80d6-3c64-4cfc-9e90-926e383d10d9@github.com> Message-ID: On Fri, 13 Aug 2021 19:20:48 GMT, Brian Burkhalter wrote: >> Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8272297: Remove unneeded check of position and couunt Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5097 From rkennke at openjdk.java.net Sun Aug 15 16:55:24 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Sun, 15 Aug 2021 16:55:24 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance [v2] In-Reply-To: <7PnVd89ihHGWYtOo66h68gX8pf2UQsHHP9WNycpSGx0=.3d112a2d-1f63-4114-89e0-6cc83a0c0a79@github.com> References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> <7PnVd89ihHGWYtOo66h68gX8pf2UQsHHP9WNycpSGx0=.3d112a2d-1f63-4114-89e0-6cc83a0c0a79@github.com> Message-ID: <0lBS28FNk8XB2iXQhJVSnN1HLHPKL5gw1Tuf4JxLm9M=.856a7e2d-3728-49b6-b4e7-789e954f67aa@github.com> On Fri, 13 Aug 2021 14:41:54 GMT, Alan Bateman wrote: > > Is this what you have been asking @mkarg in #4263 to do? Optimize transferTo() only for FileInputStream? Would it interfere with #4263? > > #4263 is the input stream returned by Channels.newInputStream where the source may be a FileChannel and the output stream specified to InputStream::transferTo may be connected to a FileChannel. Having followed both #4263 and this PR from the sidelines, may I ask why for #4263 much more rigorous testing is asked but not here? E.g. test for NPE, random-sized files/buffers, random position, return value, comprehensive JMH tests to show performance, etc? I'm all for high quality standards and good test coverage, but why are we seemingly measuring with double standards? ------------- PR: https://git.openjdk.java.net/jdk/pull/5097 From tvaleev at openjdk.java.net Mon Aug 16 03:42:28 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Mon, 16 Aug 2021 03:42:28 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional Mostly agreed with Brian. Judging from 7 years of using Stream API, I can say that this abstraction would not solve any real problem. If you need a way to create many identical streams on demand, just accept `Supplier>`. This allows more flexibility for clients. They can not only supply `myCollection::stream` or `myOptional::stream` but also `() -> Arrays.stream(myArray)`, `() -> IntStream.range(...).boxed()`, `() -> myCollection.stream().filter(something)` or whatever else. A dedicated `Streamable` interface is too limited and will require adapters in many cases but you can already adapt anything to `Supplier>`. People already use `Supplier>` idiom pretty often, so creating a new `Streamable` interface would add an API mess: some people would stick with `Supplier` and others would migrate to `Streamable`. So I vote to reject this PR. I said "mostly" because I think that PR is a good starting point for discussion. It's much easier to explain which enhancement you are proposing if you already present some code. And we are already at corelibs-dev, as PR comments are mirrored there, and for some people, it's more comfortable to discuss via GitHub interface, as you don't have to subscribe and get tons of unrelated e-mails, you can concentrate on a single discussion only. So in my opinion, it's completely ok to write code and create a PR before the discussion, even if it's likely to be thrown away. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From javalists at cbfiddle.com Mon Aug 16 04:00:56 2021 From: javalists at cbfiddle.com (Alan Snyder) Date: Sun, 15 Aug 2021 21:00:56 -0700 Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: Ah, if only one could define a type alias Streamable = Supplier>... > On Aug 15, 2021, at 8:42 PM, Tagir F.Valeev wrote: > > On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > >> create Streamable and ParallelStreamable interface and use them in Collection and Optional > > Mostly agreed with Brian. Judging from 7 years of using Stream API, I can say that this abstraction would not solve any real problem. If you need a way to create many identical streams on demand, just accept `Supplier>`. This allows more flexibility for clients. They can not only supply `myCollection::stream` or `myOptional::stream` but also `() -> Arrays.stream(myArray)`, `() -> IntStream.range(...).boxed()`, `() -> myCollection.stream().filter(something)` or whatever else. A dedicated `Streamable` interface is too limited and will require adapters in many cases but you can already adapt anything to `Supplier>`. People already use `Supplier>` idiom pretty often, so creating a new `Streamable` interface would add an API mess: some people would stick with `Supplier` and others would migrate to `Streamable`. So I vote to reject this PR. > > I said "mostly" because I think that PR is a good starting point for discussion. It's much easier to explain which enhancement you are proposing if you already present some code. And we are already at corelibs-dev, as PR comments are mirrored there, and for some people, it's more comfortable to discuss via GitHub interface, as you don't have to subscribe and get tons of unrelated e-mails, you can concentrate on a single discussion only. So in my opinion, it's completely ok to write code and create a PR before the discussion, even if it's likely to be thrown away. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5050 > From tvaleev at openjdk.java.net Mon Aug 16 05:20:31 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Mon, 16 Aug 2021 05:20:31 GMT Subject: RFR: 6506405: Math.abs(float) is slow [v9] In-Reply-To: References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com> Message-ID: On Mon, 12 Jul 2021 17:59:32 GMT, Brian Burkhalter wrote: >> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free. > > 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. I wonder when this improvement actually takes place. I see that there's equivalent asm [generated](https://github.com/openjdk/jdk/blob/87d2761f1b4572633de020b2d4681918c6f10f06/src/hotspot/cpu/x86/x86.ad#L3215) for x86 for 10 years already. Why the intrinsified version doesn't work on Linux, so changes in Java result in performance improvement? Just curious. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4711 From alanb at openjdk.java.net Mon Aug 16 08:03:29 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 16 Aug 2021 08:03:29 GMT Subject: RFR: 8272297: FileInputStream should override transferTo() for better performance [v2] In-Reply-To: <0lBS28FNk8XB2iXQhJVSnN1HLHPKL5gw1Tuf4JxLm9M=.856a7e2d-3728-49b6-b4e7-789e954f67aa@github.com> References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> <7PnVd89ihHGWYtOo66h68gX8pf2UQsHHP9WNycpSGx0=.3d112a2d-1f63-4114-89e0-6cc83a0c0a79@github.com> <0lBS28FNk8XB2iXQhJVSnN1HLHPKL5gw1Tuf4JxLm9M=.856a7e2d-3728-49b6-b4e7-789e954f67aa@github.com> Message-ID: On Sun, 15 Aug 2021 16:51:59 GMT, Roman Kennke wrote: > Having followed both #4263 and this PR from the sidelines, may I ask why for #4263 much more rigorous testing is asked but not here? E.g. test for NPE, random-sized files/buffers, random position, return value, comprehensive JMH tests to show performance, etc? I'm all for high quality standards and good test coverage, but why are we seemingly measuring with double standards? I don't think your comment is fair. The FIS PR is modest, covering one scenario, it's easy to review. The serious bugs that we pointed out have been addressed and test coverage has been added. The Channels PR is much more ambitious and is trying to cover a matrix of scenarios involving file channel and selectable channels, lots of corner cases and potential issues, and will require a lot of review cycles. None of the scenarios had any test coverage initially. This has been partially addressed but the proposal is still unwieldy, hence the discussion on reducing the scope to something manageable. ------------- PR: https://git.openjdk.java.net/jdk/pull/5097 From kcr at openjdk.java.net Mon Aug 16 12:12:28 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 16 Aug 2021 12:12:28 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: <4uq03074s-8clKL7xclc8aQbVvxnUFQuqgxcK7aP6Cg=.cbdfb171-2a75-43b5-81e4-c7bb08f54770@github.com> References: <4uq03074s-8clKL7xclc8aQbVvxnUFQuqgxcK7aP6Cg=.cbdfb171-2a75-43b5-81e4-c7bb08f54770@github.com> Message-ID: On Sun, 15 Aug 2021 02:45:17 GMT, CC007 wrote: >> create Streamable and ParallelStreamable interface and use them in Collection and Optional > > I read through [these posts](http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-June/thread.html#1910) and while I did see good reasons for not moving stream to Iterable, I didn't see any mention of a separate Streamable-like interface, so could you elaborate on that it "did not carry its weight"? @CC007 Please follow the course of action that @briangoetz has requested. This needs to be discussed on the appropriate mailing list (core-libs-dev in this case) prior to submitting a pull request. It is premature to review this PR. I invite you to refer to the [OpenJDK Developers' Guide](https://openjdk.java.net/guide/), specifically the [Socialize your change](https://openjdk.java.net/guide/#socialize-your-change) section. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From jlaskey at openjdk.java.net Mon Aug 16 12:40:37 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 16 Aug 2021 12:40:37 GMT Subject: RFR: JDK-8272326 java/util/Random/RandomTestMoments.java had two Gaussian fails Message-ID: RandomTestMoments.java and RandomTestChiSquared.java expect successive calls to nextLong to reproduce the same sequence of values. SecureRandom, by its nature, does not follow this requirement. The patch filters out SecureRandom from these tests. ------------- Commit messages: - Filter out SecureRandom Changes: https://git.openjdk.java.net/jdk/pull/5124/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5124&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272326 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5124.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5124/head:pull/5124 PR: https://git.openjdk.java.net/jdk/pull/5124 From github.com+5709644+fdesu at openjdk.java.net Mon Aug 16 13:56:44 2021 From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko) Date: Mon, 16 Aug 2021 13:56:44 GMT Subject: RFR: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError [v3] In-Reply-To: References: Message-ID: > Change #3294 helps to avoid `AnnotaionFormatException` in `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. While it fixes the case with e.g. `Runnable` that generates the synthetic method without parameters, validation still fails on synthetic methods that have parameters e.g. `Function`, `BiFunction`, etc. > > This change removes the restriction on parameters count to be zero i.e. lambdas with parameters > would be skipped from validation. Sergei Ustimenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError ------------- Changes: https://git.openjdk.java.net/jdk/pull/4642/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4642&range=02 Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4642.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4642/head:pull/4642 PR: https://git.openjdk.java.net/jdk/pull/4642 From bpb at openjdk.java.net Mon Aug 16 15:56:34 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 16 Aug 2021 15:56:34 GMT Subject: Integrated: 8272297: FileInputStream should override transferTo() for better performance In-Reply-To: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> References: <3tAxuPasO4OOGAfUTghVcVcvZ0-0JP6HuhlAyfgF9pQ=.47a2bfb2-b1e7-4058-8a6d-a645f18dc186@github.com> Message-ID: On Thu, 12 Aug 2021 01:16:04 GMT, Brian Burkhalter wrote: > Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. This pull request has now been integrated. Changeset: 82688258 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/82688258f676e6be8a603f6ab744d52728e3478b Stats: 148 lines in 2 files changed: 148 ins; 0 del; 0 mod 8272297: FileInputStream should override transferTo() for better performance Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5097 From psandoz at openjdk.java.net Mon Aug 16 15:57:27 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 16 Aug 2021 15:57:27 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: On Sun, 15 Aug 2021 01:43:32 GMT, Brian Goetz wrote: > To reiterate: These issues were explored in the JSR 335 EG and it was agreed that this abstraction did not carry its weight. Yes, we explored this when the Stream API was being designed. It's hard, if not impossible, to capture all decisions for posterity. In the passing years I don't think anything significantly new has arisen for us to revisit that decision. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From github.com+5709644+fdesu at openjdk.java.net Mon Aug 16 16:09:29 2021 From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko) Date: Mon, 16 Aug 2021 16:09:29 GMT Subject: RFR: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError [v3] In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 13:56:44 GMT, Sergei Ustimenko wrote: >> Change #3294 helps to avoid `AnnotaionFormatException` in `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. While it fixes the case with e.g. `Runnable` that generates the synthetic method without parameters, validation still fails on synthetic methods that have parameters e.g. `Function`, `BiFunction`, etc. >> >> This change removes the restriction on parameters count to be zero i.e. lambdas with parameters >> would be skipped from validation. > > Sergei Ustimenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8268788: Annotations with lambda expressions can still cause AnnotationFormatError Hi, that would be great if anyone would have time to take a quick look on this pull request. I hope this change is still relevant and I am happy to have any feedback from you. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4642 From hseigel at openjdk.java.net Mon Aug 16 17:33:36 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 16 Aug 2021 17:33:36 GMT Subject: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon Message-ID: Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli". The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64. Thanks, Harold ------------- Commit messages: - 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon Changes: https://git.openjdk.java.net/jdk/pull/5127/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5127&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272124 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5127/head:pull/5127 PR: https://git.openjdk.java.net/jdk/pull/5127 From lancea at openjdk.java.net Mon Aug 16 17:36:36 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 16 Aug 2021 17:36:36 GMT Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. [v4] In-Reply-To: References: Message-ID: <-hpQJOupTVcbXU4d1tZwTNxuoWI0TvQ8mp1pHsikE2Y=.19b9e7d7-1032-4fdf-9dd7-ff2d3982cba7@github.com> On Mon, 24 May 2021 11:18:57 GMT, Mitsuru Kariya wrote: >> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases: >> >> 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test31) >> >> 2. `pos - 1 + length > this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1 >> (test32) >> >> 3. `pos == this.length() + 1` >> The original implementation throws `SerialException` but this case should end successfully. *2 >> (test33) >> >> 4. `length < 0` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test34) >> >> 5. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test35) >> >> Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases: >> >> 1. `offset > str.length()` >> The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test39) >> >> 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()` >> The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. >> (test32) >> >> 3. `pos - 1 + length > this.length()` >> The original implementaion throws `SerialException` but this case should end successfully. *3 >> (test40) >> >> 4. `pos == this.length() + 1` >> The original implementaion throws `SerialException` but this case should end successfully. *4 >> (test41) >> >> 5. `length < 0` >> The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`. >> (test42) >> >> 6. `offset + length > Integer.MAX_VALUE` >> The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`. >> (test43) >> >> >> The javadoc has also been modified according to the above. >> >> *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes." >> >> *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the BLOB value. >> >> *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters." >> >> *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined." >> So, it should work correctly when pos == length+1 of the CLOB value. > > Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision: > > Modify javadoc for consistency In process ------------- PR: https://git.openjdk.java.net/jdk/pull/4001 From brian.burkhalter at oracle.com Mon Aug 16 18:13:01 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 16 Aug 2021 18:13:01 +0000 Subject: 'Condition is always false' in 'BigInteger#multiply(BigInteger, boolean)' In-Reply-To: References: Message-ID: Hello Andrey, Indeed that appears to be incorrect. I filed [1] to track it. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8272541 On Aug 15, 2021, at 2:12 AM, Andrey Turbanov > wrote: I found suspicious condition in method "java.math.BigInteger#multiply(java.math.BigInteger, boolean)" It's detected by IntelliJ IDEA inspection 'Constant conditions & exceptions' ``` if (bitLength(mag, mag.length) + bitLength(val.mag, val.mag.length) > 32L*MAX_MAG_LENGTH) { reportOverflow(); } ``` Method bitLength returns 'int', hence the left operand of '>' comparison is 'int' too. But the right operand of '>' comparison is 'long' with value == Integer.MAX_VALUE + 1. It means this condition is always false. Reproducer: BigInteger a = new BigInteger(1073742825, ThreadLocalRandom.current()); BigInteger b = new BigInteger(1073742825, ThreadLocalRandom.current()); BigInteger c = a.multiply(b); From bpb at openjdk.java.net Mon Aug 16 21:07:54 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 16 Aug 2021 21:07:54 GMT Subject: RFR: 8272541: Incorrect overflow test in Toom-Cook branch of BigInteger multiplication Message-ID: Please consider this change which would modify a conditional `a + b > c` where the left side variables are `int`s and the right side is `(long)Integer.MAX_VALUE + 1`. The change is to cast the left side variables to `long`s. ------------- Commit messages: - 8272541: Incorrect overflow test in Toom-Cook branch of BigInteger multiplication Changes: https://git.openjdk.java.net/jdk/pull/5130/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5130&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272541 Stats: 30 lines in 2 files changed: 18 ins; 3 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/5130.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5130/head:pull/5130 PR: https://git.openjdk.java.net/jdk/pull/5130 From github.com+78814694+tatwaichong at openjdk.java.net Mon Aug 16 21:09:56 2021 From: github.com+78814694+tatwaichong at openjdk.java.net (TatWai Chong) Date: Mon, 16 Aug 2021 21:09:56 GMT Subject: RFR: 8269559: AArch64: Implement string_compare intrinsic in SVE Message-ID: This patch implements string_compare intrinsic in SVE. It supports all LL, LU, UL and UU comparisons. As we haven't found an existing benchmark to measure performance impact, we created a benchmark derived from the test [1] for this evaluation. This benchmark is attached to this patch. Besides, remove the unused temporary register `vtmp3` from the existing match rules for StrCmp. The result below shows all varients can be benefited largely. Command: make exploded-test TEST="micro:StringCompareToDifferentLength" Benchmark (size) Mode Cnt Score Speedup Units compareToLL 24 avgt 10 1.0x ms/op compareToLL 36 avgt 10 1.0x ms/op compareToLL 72 avgt 10 1.0x ms/op compareToLL 128 avgt 10 1.4x ms/op compareToLL 256 avgt 10 1.8x ms/op compareToLL 512 avgt 10 2.7x ms/op compareToLU 24 avgt 10 1.6x ms/op compareToLU 36 avgt 10 1.8x ms/op compareToLU 72 avgt 10 2.3x ms/op compareToLU 128 avgt 10 3.8x ms/op compareToLU 256 avgt 10 4.7x ms/op compareToLU 512 avgt 10 6.3x ms/op compareToUL 24 avgt 10 1.6x ms/op compareToUL 36 avgt 10 1.7x ms/op compareToUL 72 avgt 10 2.2x ms/op compareToUL 128 avgt 10 3.3x ms/op compareToUL 256 avgt 10 4.4x ms/op compareToUL 512 avgt 10 6.1x ms/op compareToUU 24 avgt 10 1.0x ms/op compareToUU 36 avgt 10 1.0x ms/op compareToUU 72 avgt 10 1.4x ms/op compareToUU 128 avgt 10 2.2x ms/op compareToUU 256 avgt 10 2.6x ms/op compareToUU 512 avgt 10 3.7x ms/op [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToDifferentLength.java ------------- Commit messages: - 8269559: AArch64: Implement string_compare intrinsic in SVE Changes: https://git.openjdk.java.net/jdk/pull/5129/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5129&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269559 Stats: 550 lines in 12 files changed: 447 ins; 12 del; 91 mod Patch: https://git.openjdk.java.net/jdk/pull/5129.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5129/head:pull/5129 PR: https://git.openjdk.java.net/jdk/pull/5129 From filteredaccount1 at gmail.com Mon Aug 16 23:41:35 2021 From: filteredaccount1 at gmail.com (Filteredaccount1) Date: Tue, 17 Aug 2021 09:41:35 +1000 Subject: JPackage and ask for microphone permissions broken on OSX... Message-ID: Hi Core-libs-dev, I?m trying to report an issue with JPackage on recent versions of OSX. Problem is, the microphone permissions aren?t granted to applications created by jpackage. The resulting recorded 16 bit PCM line in samples files are the correct duration, but don?t have any sound (samples all set to 0). System Preferences -> Security & Privacy -> Privacy -> Microphone (application never asks for permissions) Otherwise, the only workaround I can figure out is to have the app launch then bootstrap itself using Runtime and grant applications to the Terminal.app (when it calls itself from `java Application.app/MacOS/Resources/Application`) There are various reports of this on the Internet - but I?m wondering if the JPackage team is aware of the issue. https://stackoverflow.com/questions/55727488/application-doesnt-ask-for-permission-to-access-microphone-in-macos-10-14-mojav This pretty much shows the solution - needs a bit of Objective C though. Reproducing the problem: JPackage any java sound recording app on latest OSX, run it... will be unable to capture sound. Run the same code from the command line, via classpath or modules... it will record audio after asking the user to grant microphone permissions to Terminal.app. It would be great if this is fixed in JDK 17. Many Thanks, Ben S From mseledtsov at openjdk.java.net Mon Aug 16 23:40:44 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Mon, 16 Aug 2021 23:40:44 GMT Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() In-Reply-To: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: On Mon, 16 Aug 2021 23:31:41 GMT, Mikhailo Seledtsov wrote: > Please review this change that updates the buildJdkDockerImage() test library API. > > This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested". > The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content. > As I analyzed the usage of buildJdkDockerImage() I realized that: > - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest" > its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils > - 3rd argument "buildDirName" is also always the same: "jdk-docker" > > Hence I thought it would be a good idea to simplify this API and make it up-to-date. > > Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology: > buildJdkDockerImage() --> buildJdkContainerImage() @hseigel Could you please review when you have a chance ? Testing: - ran jdk/containers and hotspot/containers tests on - OL 7.9 with Docker - OL 8.3 with Podman - OL 8.3 aarch64 with Podman All PASS ------------- PR: https://git.openjdk.java.net/jdk/pull/5134 From mseledtsov at openjdk.java.net Mon Aug 16 23:40:44 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Mon, 16 Aug 2021 23:40:44 GMT Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() Message-ID: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Please review this change that updates the buildJdkDockerImage() test library API. This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested". The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content. As I analyzed the usage of buildJdkDockerImage() I realized that: - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest" its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils - 3rd argument "buildDirName" is also always the same: "jdk-docker" Hence I thought it would be a good idea to simplify this API and make it up-to-date. Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology: buildJdkDockerImage() --> buildJdkContainerImage() ------------- Commit messages: - Updated buildJdkDockerImage, changed signature and renamed to buildJdkContainerImage - Proposed docker build API updates Changes: https://git.openjdk.java.net/jdk/pull/5134/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5134&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272398 Stats: 68 lines in 17 files changed: 20 ins; 15 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/5134.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5134/head:pull/5134 PR: https://git.openjdk.java.net/jdk/pull/5134 From iignatyev at openjdk.java.net Mon Aug 16 23:51:33 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 16 Aug 2021 23:51:33 GMT Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() In-Reply-To: References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: On Mon, 16 Aug 2021 23:47:04 GMT, Igor Ignatyev wrote: >> Please review this change that updates the buildJdkDockerImage() test library API. >> >> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested". >> The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content. >> As I analyzed the usage of buildJdkDockerImage() I realized that: >> - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest" >> its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils >> - 3rd argument "buildDirName" is also always the same: "jdk-docker" >> >> Hence I thought it would be a good idea to simplify this API and make it up-to-date. >> >> Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology: >> buildJdkDockerImage() --> buildJdkContainerImage() > > test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 145: > >> 143: >> 144: // Create an image build/staging directory >> 145: Path buildDir = Paths.get(".", "image-build"); > > to make it more robust and possible to have more than one container within a test, I'd use `imagName` + "image-build" as build dir name. you also don't need to have `.` as a first argument, `Paths.get("x")` returns you a path to "x" in current directory. ------------- PR: https://git.openjdk.java.net/jdk/pull/5134 From iignatyev at openjdk.java.net Mon Aug 16 23:51:32 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 16 Aug 2021 23:51:32 GMT Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() In-Reply-To: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: On Mon, 16 Aug 2021 23:31:41 GMT, Mikhailo Seledtsov wrote: > Please review this change that updates the buildJdkDockerImage() test library API. > > This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested". > The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content. > As I analyzed the usage of buildJdkDockerImage() I realized that: > - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest" > its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils > - 3rd argument "buildDirName" is also always the same: "jdk-docker" > > Hence I thought it would be a good idea to simplify this API and make it up-to-date. > > Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology: > buildJdkDockerImage() --> buildJdkContainerImage() Changes requested by iignatyev (Reviewer). test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 145: > 143: > 144: // Create an image build/staging directory > 145: Path buildDir = Paths.get(".", "image-build"); to make it more robust and possible to have more than one container within a test, I'd use `imagName` + "image-build" as build dir name. test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 179: > 177: * @throws Exception > 178: */ > 179: public static void buildImage(String imageName, Path buildDir) throws Exception { it seems there are no users of this method, do we need to keep it public? ------------- PR: https://git.openjdk.java.net/jdk/pull/5134 From kcr at openjdk.java.net Mon Aug 16 23:56:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 16 Aug 2021 23:56:29 GMT Subject: Withdrawn: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From mseledtsov at openjdk.java.net Tue Aug 17 00:51:23 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Tue, 17 Aug 2021 00:51:23 GMT Subject: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon In-Reply-To: References: Message-ID: <4K0vR12G3TYzHYgOjxrlL23DqsDzRdKZlvtQXPOKhc0=.16e92016-8bd3-49ae-abb6-d21a358c8122@github.com> On Mon, 16 Aug 2021 17:25:57 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli". > > The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64. > > Thanks, Harold Changes look good to me. ------------- Marked as reviewed by mseledtsov (Committer). PR: https://git.openjdk.java.net/jdk/pull/5127 From mseledtsov at openjdk.java.net Tue Aug 17 01:49:23 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Tue, 17 Aug 2021 01:49:23 GMT Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() In-Reply-To: References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: On Mon, 16 Aug 2021 23:48:46 GMT, Igor Ignatyev wrote: >> Please review this change that updates the buildJdkDockerImage() test library API. >> >> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested". >> The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content. >> As I analyzed the usage of buildJdkDockerImage() I realized that: >> - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest" >> its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils >> - 3rd argument "buildDirName" is also always the same: "jdk-docker" >> >> Hence I thought it would be a good idea to simplify this API and make it up-to-date. >> >> Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology: >> buildJdkDockerImage() --> buildJdkContainerImage() > > test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 179: > >> 177: * @throws Exception >> 178: */ >> 179: public static void buildImage(String imageName, Path buildDir) throws Exception { > > it seems there are no users of this method, do we need to keep it public? Sounds good. Will do. ------------- PR: https://git.openjdk.java.net/jdk/pull/5134 From bpb at openjdk.java.net Tue Aug 17 02:54:43 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 17 Aug 2021 02:54:43 GMT Subject: RFR: 8272369: java/io/File/GetXSpace.java failed with "RuntimeException: java.nio.file.NoSuchFileException: /run/user/0" Message-ID: This change proposes to exclude `/run/user` mounts from the test when run on Linux as they can "disappear" while the test is running. ------------- Commit messages: - 8272369: java/io/File/GetXSpace.java failed with "RuntimeException: java.nio.file.NoSuchFileException: /run/user/0" Changes: https://git.openjdk.java.net/jdk/pull/5136/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5136&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272369 Stats: 15 lines in 1 file changed: 7 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5136.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5136/head:pull/5136 PR: https://git.openjdk.java.net/jdk/pull/5136 From github.com+5381337+cc007 at openjdk.java.net Tue Aug 17 02:56:26 2021 From: github.com+5381337+cc007 at openjdk.java.net (CC007) Date: Tue, 17 Aug 2021 02:56:26 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 03:39:02 GMT, Tagir F. Valeev wrote: >> create Streamable and ParallelStreamable interface and use them in Collection and Optional > > Mostly agreed with Brian. Judging from 7 years of using Stream API, I can say that this abstraction would not solve any real problem. If you need a way to create many identical streams on demand, just accept `Supplier>`. This allows more flexibility for clients. They can not only supply `myCollection::stream` or `myOptional::stream` but also `() -> Arrays.stream(myArray)`, `() -> IntStream.range(...).boxed()`, `() -> myCollection.stream().filter(something)` or whatever else. A dedicated `Streamable` interface is too limited and will require adapters in many cases but you can already adapt anything to `Supplier>`. People already use `Supplier>` idiom pretty often, so creating a new `Streamable` interface would add an API mess: some people would stick with `Supplier` and others would migrate to `Streamable`. So I vote to reject this PR. > > I said "mostly" because I think that PR is a good starting point for discussion. It's much easier to explain which enhancement you are proposing if you already present some code. And we are already at corelibs-dev, as PR comments are mirrored there, and for some people, it's more comfortable to discuss via GitHub interface, as you don't have to subscribe and get tons of unrelated e-mails, you can concentrate on a single discussion only. So in my opinion, it's completely ok to write code and create a PR before the discussion, even if it's likely to be thrown away. It is fine that the pull request is closed for now, but I agree with @amaembo that if this conversation is indeed mirrored there, then it shouldn't be a problem to discuss the proposal here, along with the proposed changes. I actually worked out a usecase (See: https://github.com/CC007/InterfaceSegregationDemo), where I partially reimagined the Collection interface stack and its neighboring interfaces/classes. I also added a `Demo` class to show how I imagined to use these interfaces and to show how the granularity of these interfaces can be useful. The fact that I have to create copies of interfaces and delegates for implementations makes me feel like something is lacking in the collection stack and that for this usecase `Supplier` wouldn't cut it, but feel free to fork and refactor my code to prove me wrong. PS: while creating the Demo class, I noticed that it couldn't be analyzed if the return value of a method with type ` & Addable & Iterable & RandomAccess>` could be safely cast to a new local variable with type ` & Addable` and that you can't declare variables of type ` & Addable` (it won't let you use the `&` when using the `?`), but I digress. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From github.com+5381337+cc007 at openjdk.java.net Tue Aug 17 03:11:31 2021 From: github.com+5381337+cc007 at openjdk.java.net (CC007) Date: Tue, 17 Aug 2021 03:11:31 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional Also, sorry for my Millennial lack of knowledge of older communication methods, but if I wanted to reply to a specific thread in a mailing list, how would I do that? Does it require certain content in the subject and/or quoted text in the message body? It does feel way less intuitive than just clicking the comment box or clicking `... -> Quote reply` on a comment in this PR ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From github.com+7806504+liach at openjdk.java.net Tue Aug 17 03:42:27 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Tue, 17 Aug 2021 03:42:27 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional You can view the mailing lists at https://mail.openjdk.java.net/mailman/listinfo and subscribe there. If you want to send a mail, just send one to say `jdk-dev` at `openjdk.java.net` (and carbon copy if you reply to a specific person so the list can see a copy) ---------------- On a separate note, @CC007 your model falls back to the fairly-old inheritance vs embodiment (extending a class vs using it as a field) debate. Nowadays, I think Java has evolved to reduce excessive reliances on inheritances, as there can be clashes (for example, a class cannot implement a comparator for two different type arguments). Also due to these potential of clashing, in a lot of java code, interface implementation classes avoid implementing multiple interfaces at once. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From github.com+5381337+cc007 at openjdk.java.net Tue Aug 17 04:17:28 2021 From: github.com+5381337+cc007 at openjdk.java.net (CC007) Date: Tue, 17 Aug 2021 04:17:28 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional The List and Collection interface was almost directly taken from java.util (apart from the small feature interfaces, that I extracted from them), so it would make sense that those classes use an older design. Are you suggesting that there are deeper architectural issues with the hierarchy-heavy collection stack? Would it be better if a list contained a collection, rather than inheriting from it? If that is the case, anything that is proposed in this PR is merely aiming at symptoms of a possibility much larger underlying problem, which might require going back to the drawing board for all collection related features. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From donraab at gmail.com Tue Aug 17 04:55:29 2021 From: donraab at gmail.com (Donald Raab) Date: Tue, 17 Aug 2021 00:55:29 -0400 Subject: Proposal: Replace foreach loop with Iterable.forEach in String.join(CharSequence, Iterable) Message-ID: The following code: for (CharSequence cs: elements) { joiner.add(cs); } Can be replaced with: elements.forEach(joiner::add); This would have the minor benefit of making it safe to use String.join with synchronized collections without requiring a client side lock. There are likely other opportunities like this in the JDK. Also, with the addition of forEach on Iterable, and Predicate in Java 8, the following design FAQ is outdated. https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/doc-files/coll-designfaq.html#a6 Thanks, Don From github.com+7806504+liach at openjdk.java.net Tue Aug 17 06:50:30 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Tue, 17 Aug 2021 06:50:30 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional With modern java, you can always create a `Streamable` on your own (and have specifications/documentations that a simple `Supplier` lacks) and implement it like: public interface Streamable { Stream stream(); static Streamable ofIterable(Iterable iterable) { return () -> StreamSupport.stream(iterable.spliterator(), false); } } The lack of such an interface in the JDK is not really a problem. > Are you suggesting that there are deeper architectural issues with the hierarchy-heavy collection stack? I am saying that your sample project has unnecessarily many interfaces for your collection model, where many of them have little virtue on their own. This interface mash is susceptible to accidentally introducing unwanted features into the hierarchy and having method or specification clashes for implementation. Looking back on identifying efficiently streamable objects, people can usually find efficient streams by the method return types. Your interface doesn't allow people to identify `BufferedReader.lines()` as an efficiently streamable target, for instance. In addition, I think the main purpose of `Optional.stream()` is to allow using it in stream flatmapping than to promote stream creation with optionals. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From ngasson at openjdk.java.net Tue Aug 17 07:17:30 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Tue, 17 Aug 2021 07:17:30 GMT Subject: RFR: 8269559: AArch64: Implement string_compare intrinsic in SVE In-Reply-To: References: Message-ID: <_lSp-23GertACKXqh3cAP2hFlevG6Qhg-PmPswR5ctw=.f0b13664-3fce-42f3-9420-1d24d19d15ca@github.com> On Mon, 16 Aug 2021 20:59:55 GMT, TatWai Chong wrote: > This patch implements string_compare intrinsic in SVE. > It supports all LL, LU, UL and UU comparisons. > > As we haven't found an existing benchmark to measure performance impact, > we created a benchmark derived from the test [1] for this evaluation. > This benchmark is attached to this patch. > > Besides, remove the unused temporary register `vtmp3` from the existing > match rules for StrCmp. > > The result below shows all varients can be benefited largely. > Command: make exploded-test TEST="micro:StringCompareToDifferentLength" > > Benchmark (size) Mode Cnt Score Speedup Units > compareToLL 24 avgt 10 1.0x ms/op > compareToLL 36 avgt 10 1.0x ms/op > compareToLL 72 avgt 10 1.0x ms/op > compareToLL 128 avgt 10 1.4x ms/op > compareToLL 256 avgt 10 1.8x ms/op > compareToLL 512 avgt 10 2.7x ms/op > compareToLU 24 avgt 10 1.6x ms/op > compareToLU 36 avgt 10 1.8x ms/op > compareToLU 72 avgt 10 2.3x ms/op > compareToLU 128 avgt 10 3.8x ms/op > compareToLU 256 avgt 10 4.7x ms/op > compareToLU 512 avgt 10 6.3x ms/op > compareToUL 24 avgt 10 1.6x ms/op > compareToUL 36 avgt 10 1.7x ms/op > compareToUL 72 avgt 10 2.2x ms/op > compareToUL 128 avgt 10 3.3x ms/op > compareToUL 256 avgt 10 4.4x ms/op > compareToUL 512 avgt 10 6.1x ms/op > compareToUU 24 avgt 10 1.0x ms/op > compareToUU 36 avgt 10 1.0x ms/op > compareToUU 72 avgt 10 1.4x ms/op > compareToUU 128 avgt 10 2.2x ms/op > compareToUU 256 avgt 10 2.6x ms/op > compareToUU 512 avgt 10 3.7x ms/op > > [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToDifferentLength.java src/hotspot/cpu/aarch64/aarch64.ad line 16515: > 16513: instruct string_compareUL(iRegP_R1 str1, iRegI_R2 cnt1, iRegP_R3 str2, iRegI_R4 cnt2, > 16514: iRegI_R0 result, iRegP_R10 tmp1, iRegL_R11 tmp2, > 16515: vRegD_V0 vtmp1, vRegD_V1 vtmp2, vRegD_V2 vtmp3, rFlagsReg cr) I think vtmp3 (=V2) is still used by the non-SVE compare-long-strings stub? (see `generate_compare_long_string_different_encoding`) ------------- PR: https://git.openjdk.java.net/jdk/pull/5129 From github.com+10835776+stsypanov at openjdk.java.net Tue Aug 17 07:32:29 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 17 Aug 2021 07:32:29 GMT Subject: RFR: 8270057: Use Objects.checkFromToIndex for j.u.c.CopyOnWriteArrayList In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 11:51:18 GMT, Yi Yang wrote: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. > > As Mandy suggested, I create this PR for changes involving JUC changes. Very simple change, LGTM. ------------- Marked as reviewed by stsypanov at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/4723 From claes.redestad at oracle.com Tue Aug 17 12:20:34 2021 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 17 Aug 2021 14:20:34 +0200 Subject: Proposal: Replace foreach loop with Iterable.forEach in String.join(CharSequence, Iterable) In-Reply-To: References: Message-ID: Hi Don, so the win comes from forEach on the synchronized collection implicitly being synchronized atomically, whereas foreach will synchronize on each iterator operation and thus allow racy modification of elements in between iteration, right? Seems reasonable to consider, though it'd have to percolate through to most production deployments before you could use it - and even then it seems somewhat fragile. And isn't this just one of many utility methods that would have to be fixed to avoid issues with hidden iterators completely? String.join was recently changed to this by JDK-8265237[1]: for (CharSequence cs: elements) { if (size >= elems.length) { elems = Arrays.copyOf(elems, elems.length << 1); } elems[size++] = String.valueOf(cs); } Of course the body in the new code could be extracted to the same effect. The drawback in either implementation is that it would by necessity be a capturing lambda, so might add a small allocation overhead. I'm biased towards avoiding performance overheads, but maybe someone else can make a call on whether this is a worthwhile thing to attempt. Thanks! /Claes [1] https://bugs.openjdk.java.net/browse/JDK-8265237 On 2021-08-17 06:55, Donald Raab wrote: > The following code: > > for (CharSequence cs: elements) { > joiner.add(cs); > } > > Can be replaced with: > > elements.forEach(joiner::add); > > This would have the minor benefit of making it safe to use String.join with synchronized collections without requiring a client side lock. There are likely other opportunities like this in the JDK. > > Also, with the addition of forEach on Iterable, and Predicate in Java 8, the following design FAQ is outdated. > > https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/doc-files/coll-designfaq.html#a6 > > Thanks, > Don > From sgehwolf at openjdk.java.net Tue Aug 17 13:12:24 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 17 Aug 2021 13:12:24 GMT Subject: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon In-Reply-To: References: Message-ID: <2UtKcMi4-HV7wJ-jXgw1eicdGRCKmHdt5MLrEzU2woI=.a01f2eff-0d80-499a-97bc-91bf26ca7b67@github.com> On Mon, 16 Aug 2021 17:25:57 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli". > > The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64. > > Thanks, Harold src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 199: > 197: action = (tokens -> setCgroupV2Path(infos, tokens)); > 198: } > 199: selfCgroupLines.map(line -> line.split(":", 3)) Could you please add a comment explaining that the limit value of 3 comes from the fact that `/proc/self/cgroup` contains three colon-separated tokens per line. The last value, cgroup path, might contain `:`. src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 200: > 198: } > 199: selfCgroupLines.map(line -> line.split(":", 3)) > 200: .filter(tokens -> (tokens.length >= 3)) This filter no longer makes sense as tokens.length == 3 in every case after this patch. Please remove. From the javadoc from `String.split(String, limit)`: If the limit is positive then the pattern will be applied at most limit-1 times, the array's length will be no greater than limit, and the array's last entry will contain all input beyond the last matched delimiter. test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java line 175: > 173: private String mntInfoCgroupsV1DoubleCpuset = mntInfoHybrid + mntInfoCgroupv1MoreCpusetLine; > 174: private String mntInfoCgroupsV1DoubleCpuset2 = mntInfoCgroupv1MoreCpusetLine + mntInfoHybrid; > 175: private String cgroupv1SelfCgroupContent = "11:memory:/user.slice/user-1000.slice/user at 1000.s:ervice\n" + Could you please add a comment explaining that `/proc/self/cgroup` is supposed to contain **three** colon-separated fields, `hierarchy-ID:controller-list:cgroup-path`. Thus, this cgroup-path intentionally contains a colon so as to ensure the correct path is being extracted by the logic in CgroupSubsystemFactory. Better yet, add a new test with `mountinfo` and `/proc/self/cgroup` contents observed in the wild and assert that `memoryInfo.getCgroupPath()` equals `memoryInfo.getMountRoot()` ------------- PR: https://git.openjdk.java.net/jdk/pull/5127 From mseledtsov at openjdk.java.net Tue Aug 17 14:58:48 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Tue, 17 Aug 2021 14:58:48 GMT Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() [v2] In-Reply-To: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: > Please review this change that updates the buildJdkDockerImage() test library API. > > This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested". > The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content. > As I analyzed the usage of buildJdkDockerImage() I realized that: > - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest" > its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils > - 3rd argument "buildDirName" is also always the same: "jdk-docker" > > Hence I thought it would be a good idea to simplify this API and make it up-to-date. > > Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology: > buildJdkDockerImage() --> buildJdkContainerImage() Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision: Addressing review feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5134/files - new: https://git.openjdk.java.net/jdk/pull/5134/files/51a75339..d211c220 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5134&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5134&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5134.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5134/head:pull/5134 PR: https://git.openjdk.java.net/jdk/pull/5134 From sgehwolf at openjdk.java.net Tue Aug 17 15:04:28 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 17 Aug 2021 15:04:28 GMT Subject: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon In-Reply-To: <2UtKcMi4-HV7wJ-jXgw1eicdGRCKmHdt5MLrEzU2woI=.a01f2eff-0d80-499a-97bc-91bf26ca7b67@github.com> References: <2UtKcMi4-HV7wJ-jXgw1eicdGRCKmHdt5MLrEzU2woI=.a01f2eff-0d80-499a-97bc-91bf26ca7b67@github.com> Message-ID: On Tue, 17 Aug 2021 09:07:17 GMT, Severin Gehwolf wrote: >> Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli". >> >> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64. >> >> Thanks, Harold > > src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 200: > >> 198: } >> 199: selfCgroupLines.map(line -> line.split(":", 3)) >> 200: .filter(tokens -> (tokens.length >= 3)) > > This filter no longer makes sense as tokens.length == 3 in every case after this patch. Please remove. From the javadoc from `String.split(String, limit)`: > > If the limit is positive then the pattern will be applied > at most limit-1 times, the array's length will be > no greater than limit, and the array's last entry will contain > all input beyond the last matched delimiter. On second thought, we might want to keep `tokens.length == 3`, but I don't know if it'll ever be < 3 in reality. It certainly would no longer be > 3. ------------- PR: https://git.openjdk.java.net/jdk/pull/5127 From rriggs at openjdk.java.net Tue Aug 17 15:05:30 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 17 Aug 2021 15:05:30 GMT Subject: RFR: JDK-8272326 java/util/Random/RandomTestMoments.java had two Gaussian fails In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 12:32:34 GMT, Jim Laskey wrote: > RandomTestMoments.java and RandomTestChiSquared.java expect successive calls to nextLong to reproduce the same sequence of values. SecureRandom, by its nature, does not follow this requirement. The patch filters out SecureRandom from these tests. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5124 From iignatyev at openjdk.java.net Tue Aug 17 15:06:25 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 17 Aug 2021 15:06:25 GMT Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() [v2] In-Reply-To: References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: On Tue, 17 Aug 2021 14:58:48 GMT, Mikhailo Seledtsov wrote: >> Please review this change that updates the buildJdkDockerImage() test library API. >> >> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested". >> The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content. >> As I analyzed the usage of buildJdkDockerImage() I realized that: >> - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest" >> its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils >> - 3rd argument "buildDirName" is also always the same: "jdk-docker" >> >> Hence I thought it would be a good idea to simplify this API and make it up-to-date. >> >> Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology: >> buildJdkDockerImage() --> buildJdkContainerImage() > > Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision: > > Addressing review feedback Looks good and trivial to me. ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5134 From bpb at openjdk.java.net Tue Aug 17 15:16:23 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 17 Aug 2021 15:16:23 GMT Subject: RFR: 8272369: java/io/File/GetXSpace.java failed with "RuntimeException: java.nio.file.NoSuchFileException: /run/user/0" In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 02:48:35 GMT, Brian Burkhalter wrote: > This change proposes to exclude `/run/user` mounts from the test when run on Linux as they can "disappear" while the test is running. That's correct, it's [pam_systemd](https://www.man7.org/linux/man-pages/man8/pam_systemd.8.html). I have not yet examined any other tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/5136 From bpb at openjdk.java.net Tue Aug 17 15:21:25 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 17 Aug 2021 15:21:25 GMT Subject: RFR: JDK-8272326 java/util/Random/RandomTestMoments.java had two Gaussian fails In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 12:32:34 GMT, Jim Laskey wrote: > RandomTestMoments.java and RandomTestChiSquared.java expect successive calls to nextLong to reproduce the same sequence of values. SecureRandom, by its nature, does not follow this requirement. The patch filters out SecureRandom from these tests. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5124 From alanb at openjdk.java.net Tue Aug 17 15:32:25 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 17 Aug 2021 15:32:25 GMT Subject: RFR: 8272369: java/io/File/GetXSpace.java failed with "RuntimeException: java.nio.file.NoSuchFileException: /run/user/0" In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 02:48:35 GMT, Brian Burkhalter wrote: > This change proposes to exclude `/run/user` mounts from the test when run on Linux as they can "disappear" while the test is running. Marked as reviewed by alanb (Reviewer). The change looks okay but I suspect a similar change will require in a few other tests. It may be worth trying to identify those tests while the issue the understood. ------------- PR: https://git.openjdk.java.net/jdk/pull/5136 From bpb at openjdk.java.net Tue Aug 17 15:35:28 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 17 Aug 2021 15:35:28 GMT Subject: RFR: 8272369: java/io/File/GetXSpace.java failed with "RuntimeException: java.nio.file.NoSuchFileException: /run/user/0" In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 02:48:35 GMT, Brian Burkhalter wrote: > This change proposes to exclude `/run/user` mounts from the test when run on Linux as they can "disappear" while the test is running. There is no other occurrence of `df` in the `java/io` or the `java/nio` tests that I can find. The test `java/nio/file/FileStore/Basic.java` does however have this construct: // check space attributes are accessible try { store.getTotalSpace(); store.getUnallocatedSpace(); store.getUsableSpace(); } catch (NoSuchFileException nsfe) { // ignore exception as the store could have been // deleted since the iterator was instantiated System.err.format("%s was not found\n", store); } catch (AccessDeniedException ade) { // ignore exception as the lack of ability to access the // store due to lack of file permission or similar does not // reflect whether the space attributes would be accessible // were access to be permitted System.err.format("%s is inaccessible\n", store); } which might be a better way to handle the current problem, i.e., don't filter out the `/run/user` mounts up front, but ignore the NSFE if it occurs on one of them ------------- PR: https://git.openjdk.java.net/jdk/pull/5136 From jlaskey at openjdk.java.net Tue Aug 17 15:57:27 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 17 Aug 2021 15:57:27 GMT Subject: Integrated: JDK-8272326 java/util/Random/RandomTestMoments.java had two Gaussian fails In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 12:32:34 GMT, Jim Laskey wrote: > RandomTestMoments.java and RandomTestChiSquared.java expect successive calls to nextLong to reproduce the same sequence of values. SecureRandom, by its nature, does not follow this requirement. The patch filters out SecureRandom from these tests. This pull request has now been integrated. Changeset: cf64c3e7 Author: Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/cf64c3e7e226eacf675d984db52872b0a8343a46 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod 8272326: java/util/Random/RandomTestMoments.java had two Gaussian fails Reviewed-by: rriggs, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5124 From bpb at openjdk.java.net Tue Aug 17 16:03:47 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 17 Aug 2021 16:03:47 GMT Subject: RFR: 8272369: java/io/File/GetXSpace.java failed with "RuntimeException: java.nio.file.NoSuchFileException: /run/user/0" [v2] In-Reply-To: References: Message-ID: > This change proposes to exclude `/run/user` mounts from the test when run on Linux as they can "disappear" while the test is running. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8272369: On Linux, do not filter /run/user mounts unless an NSFE is thrown ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5136/files - new: https://git.openjdk.java.net/jdk/pull/5136/files/9db1d7f4..80b43b99 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5136&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5136&range=00-01 Stats: 10 lines in 1 file changed: 7 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5136.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5136/head:pull/5136 PR: https://git.openjdk.java.net/jdk/pull/5136 From alanb at openjdk.java.net Tue Aug 17 16:33:27 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 17 Aug 2021 16:33:27 GMT Subject: RFR: 8272369: java/io/File/GetXSpace.java failed with "RuntimeException: java.nio.file.NoSuchFileException: /run/user/0" [v2] In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 16:03:47 GMT, Brian Burkhalter wrote: >> This change proposes to exclude `/run/user` mounts from the test when run on Linux as they can "disappear" while the test is running. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8272369: On Linux, do not filter /run/user mounts unless an NSFE is thrown Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5136 From donraab at gmail.com Tue Aug 17 17:05:36 2021 From: donraab at gmail.com (Donald Raab) Date: Tue, 17 Aug 2021 13:05:36 -0400 Subject: Proposal: Replace foreach loop with Iterable.forEach in String.join(CharSequence, Iterable) In-Reply-To: References: Message-ID: Hi Claes, > so the win comes from forEach on the synchronized collection implicitly > being synchronized atomically, whereas foreach will synchronize on > each iterator operation and thus allow racy modification of elements > in between iteration, right? Yes, this win will be applied to any type that does something special in forEach. For instance we have MultiReader collections in Eclipse Collections, which take a read lock on forEach, and throws UnsupportedOperationException on iterator. This change would make String.join safe to use for these as well, without requiring an explicit lock in client code. > > Seems reasonable to consider, though it'd have to percolate through to most production deployments before you could use it - and even then > it seems somewhat fragile. And isn't this just one of many utility > methods that would have to be fixed to avoid issues with hidden > iterators completely? > Yes, this is one small step. Synchronized collections wouldn?t become less tricky to use, but there would be one less hidden iterator to worry about. > String.join was recently changed to this by JDK-8265237[1]: > > for (CharSequence cs: elements) { > if (size >= elems.length) { > elems = Arrays.copyOf(elems, elems.length << 1); > } > elems[size++] = String.valueOf(cs); > } > This looks like the code for the overloaded String.join which takes an array. I was referring to only the version that takes Iterable. > Of course the body in the new code could be extracted to the same > effect. The drawback in either implementation is that it would by > necessity be a capturing lambda, so might add a small allocation > overhead. I'm biased towards avoiding performance overheads, but maybe > someone else can make a call on whether this is a worthwhile thing to > attempt. > There is a trade-off here. You remove the need to create an iterator for all types (due to foreach loop), and replace with forEach with a method reference, which IIRC might be slightly better than having a lambda. The underlying collection (let?s say ArrayList) will be called which will also not create an iterator but iterate directly over the ArrayList internal array. Thanks, Don > Thanks! > > /Claes > > [1] https://bugs.openjdk.java.net/browse/JDK-8265237 > > On 2021-08-17 06:55, Donald Raab wrote: >> The following code: >> for (CharSequence cs: elements) { >> joiner.add(cs); >> } >> Can be replaced with: >> elements.forEach(joiner::add); >> This would have the minor benefit of making it safe to use String.join with synchronized collections without requiring a client side lock. There are likely other opportunities like this in the JDK. >> Also, with the addition of forEach on Iterable, and Predicate in Java 8, the following design FAQ is outdated. >> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/doc-files/coll-designfaq.html#a6 >> Thanks, >> Don From bpb at openjdk.java.net Tue Aug 17 17:10:27 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 17 Aug 2021 17:10:27 GMT Subject: Integrated: 8272369: java/io/File/GetXSpace.java failed with "RuntimeException: java.nio.file.NoSuchFileException: /run/user/0" In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 02:48:35 GMT, Brian Burkhalter wrote: > This change proposes to exclude `/run/user` mounts from the test when run on Linux as they can "disappear" while the test is running. This pull request has now been integrated. Changeset: a68b5b9c Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/a68b5b9c1dd9dd69fa3ef29d8f1186707ec09311 Stats: 19 lines in 1 file changed: 11 ins; 4 del; 4 mod 8272369: java/io/File/GetXSpace.java failed with "RuntimeException: java.nio.file.NoSuchFileException: /run/user/0" Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5136 From hseigel at openjdk.java.net Tue Aug 17 17:39:49 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 17 Aug 2021 17:39:49 GMT Subject: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon [v2] In-Reply-To: References: Message-ID: <4hKKCdMZJ4OnLvvdOvTGLkI1DsbMVdPOPMA53U1urWY=.8e11fc69-6756-47ae-b973-cdd114cadfd7@github.com> > Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli". > > The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: add test case, comments, and other small changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5127/files - new: https://git.openjdk.java.net/jdk/pull/5127/files/918df2b4..5fa37e97 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5127&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5127&range=00-01 Stats: 41 lines in 2 files changed: 36 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5127/head:pull/5127 PR: https://git.openjdk.java.net/jdk/pull/5127 From hseigel at openjdk.java.net Tue Aug 17 17:39:49 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 17 Aug 2021 17:39:49 GMT Subject: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 17:25:57 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli". > > The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64. > > Thanks, Harold Thanks Misha and Severin for looking at this change! Please review this updated commit that tries to address Severin's comments. A new test case was added to TestCgroupSubsystemFactory.java for the multiple ':'s case and comments were added to CgroupSubsystemFactory.java. The ".filter(tokens -> (tokens.length >= 3))" code was removed but can be restored if need be. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/5127 From sgehwolf at openjdk.java.net Tue Aug 17 17:51:25 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 17 Aug 2021 17:51:25 GMT Subject: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon [v2] In-Reply-To: <4hKKCdMZJ4OnLvvdOvTGLkI1DsbMVdPOPMA53U1urWY=.8e11fc69-6756-47ae-b973-cdd114cadfd7@github.com> References: <4hKKCdMZJ4OnLvvdOvTGLkI1DsbMVdPOPMA53U1urWY=.8e11fc69-6756-47ae-b973-cdd114cadfd7@github.com> Message-ID: On Tue, 17 Aug 2021 17:39:49 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli". >> >> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > add test case, comments, and other small changes test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java line 375: > 373: CgroupInfo memoryInfo = res.getInfos().get("memory"); > 374: assertEquals(memoryInfo.getCgroupPath(), "/system.slice/containerd.service/kubepods-burstable-podf65e797d_d5f9_4604_9773_94f4bb9946a0.slice:cri-containerd:86ac6260f9f8a9c1276748250f330ae9c2fcefe5ae809364ad1e45f3edf7e08a"); > 375: assertEquals(memoryInfo.getMountRoot(), memoryInfo.getMountRoot()); What I meant here is to also change the mountinfo entry for `memory` and then use assertEquals(memoryInfo.getMountRoot(), memoryInfo.getCgroupPath()); as that's really what was happening in the wild. mount root - containing colons - would correctly parse, but the cgroup path - containing colons - would not and the assertion would fail (without the change in CgroupSubsystemFactory). Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/5127 From github.com+5381337+cc007 at openjdk.java.net Tue Aug 17 17:54:32 2021 From: github.com+5381337+cc007 at openjdk.java.net (CC007) Date: Tue, 17 Aug 2021 17:54:32 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional Ah ok, I see your point. In the case that you want to have something be only `Streamable`, you can create an interface like this (fixed missing method type param and added `ofCollection`: public interface Streamable { Stream stream(); static Streamable ofIterable(Iterable iterable) { return () -> StreamSupport.stream(iterable.spliterator(), false); } static Streamable ofCollection(Collection collection) { return collection::stream; } } This will indeed allow you to only expose the `stream()` method, even to the degree that you can't even expose the other methods with type casting, which is a nice side effect. You could also add a static method for `ofOptional`, if required, but you made a good point about `Optional.stream`'s general use case (though it could still be used as a stream when needed). At first I didn't fully understand how that would resolve the issue for whenever you need something that is both `Iterable` and `Streamable`, but after rereading your comment I came up with the following interface: /** * This is an interface that specifies that its content can be traversed and acted upon, * either through iteration or using streams */ public interface Traversable extends Streamable, Iterable { static Traversable ofIterable(Iterable iterable) { return new Traversable() { @Override public Stream stream() { return StreamSupport.stream(iterable.spliterator(), false); } @Override public Iterator iterator() { return iterable.iterator(); } }; } static Traversable ofStreamable(Streamable streamable) { return new Traversable() { @Override public Stream stream() { return streamable.stream(); } @Override public Iterator iterator() { return streamable.stream().iterator(); } }; } static Traversable ofCollection(Collection collection) { return new Traversable() { @Override public Stream stream() { return collection.stream(); } @Override public Iterator iterator() { return collection.iterator(); } }; } } For anyone who's doubtful about the arguments against this change, you can find this code in use in demo2 in my demo repo: https://github.com/CC007/InterfaceSegregationDemo/tree/master/src/main/java/com/github/cc007/interfacesegregationdemo/demo2 ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From javalists at cbfiddle.com Tue Aug 17 18:55:23 2021 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 17 Aug 2021 11:55:23 -0700 Subject: RFR: 8272137: Make Collection and Optional classes streamable [plug for Extensible interface] In-Reply-To: References: Message-ID: <28B083FC-CD7F-4066-A9CE-7C56DD72BC8F@cbfiddle.com> This provides an opportunity for me to promote what I believe is a much more important missing interface, namely, an interface that supports a semantic replacement for type casting. Using type casting (instanceof) is a really bad way to test an object for an optional capability. The reason is that instanceof is strictly limited by how the object is implemented. It will only work if the object *directly* implements the interface. It does not support an object that might provide the requested interface using an auxiliary object. It doesn?t support delegation at all. If you try to wrap an object with a transparent wrapper implemented using delegation, the wrapper must support exactly the interfaces that you expect from the wrapped object. If some of those are optional, you wind up with many versions of the wrapper to ensure that instanceof will work on the wrapper as expected. This is hardly a new idea. I?ve seen this idea in several major libraries. But, because Java does define its own version of this interface, this approach cannot be used in general. I suspect it would be useful for some of the problems being discussed here. For concreteness, this is how I define it: public interface Extensible { @Nullable T getExtension(@NotNull Class c); } with a static method used in place of instanceof: public static @Nullable T getExtension(@Nullable Object o, @NotNull Class c) { if (o == null) { return null; } if (c.isInstance(o)) { return c.cast(o); } if (o instanceof Extensible) { Extensible x = (Extensible) o; return x.getExtension(c); } return null; } > On Aug 17, 2021, at 10:54 AM, CC007 wrote: > > On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > >> create Streamable and ParallelStreamable interface and use them in Collection and Optional > > Ah ok, I see your point. In the case that you want to have something be only `Streamable`, you can create an interface like this (fixed missing method type param and added `ofCollection`: > > public interface Streamable { > > Stream stream(); > > static Streamable ofIterable(Iterable iterable) { > return () -> StreamSupport.stream(iterable.spliterator(), false); > } > > static Streamable ofCollection(Collection collection) { > return collection::stream; > } > } > > This will indeed allow you to only expose the `stream()` method, even to the degree that you can't even expose the other methods with type casting, which is a nice side effect. You could also add a static method for `ofOptional`, if required, but you made a good point about `Optional.stream`'s general use case (though it could still be used as a stream when needed). > From claes.redestad at oracle.com Tue Aug 17 19:06:50 2021 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 17 Aug 2021 21:06:50 +0200 Subject: Proposal: Replace foreach loop with Iterable.forEach in String.join(CharSequence, Iterable) In-Reply-To: References: Message-ID: <56d1f02e-926d-984d-4ab0-ac4295376ad0@oracle.com> Hi Don, On 2021-08-17 19:05, Donald Raab wrote: > Hi Claes, > >> so the win comes from forEach on the synchronized collection implicitly >> being synchronized atomically, whereas foreach will synchronize on >> each iterator operation and thus allow racy modification of elements >> in between iteration, right? > > Yes, this win will be applied to any type that does something special in forEach. For instance we have MultiReader collections in Eclipse Collections, which take a read lock on forEach, and throws UnsupportedOperationException on iterator. This change would make String.join safe to use for these as well, without requiring an explicit lock in client code. Thanks, I think this will help inform the decision-making. > >> >> Seems reasonable to consider, though it'd have to percolate through to most production deployments before you could use it - and even then >> it seems somewhat fragile. And isn't this just one of many utility >> methods that would have to be fixed to avoid issues with hidden >> iterators completely? >> > > Yes, this is one small step. Synchronized collections wouldn?t become less tricky to use, but there would be one less hidden iterator to worry about. Just thinking in terms of whether this ought to be a concerted effort. And perhaps some paranoid fear it might spiral out of control unless we're wary. :-) Fixing the OpenJDK implementation is one thing, but I think this ought to be also considered on a specification (and JCK) level to avoid creating a dependency on the implementation. > >> String.join was recently changed to this by JDK-8265237[1]: >> >> for (CharSequence cs: elements) { >> if (size >= elems.length) { >> elems = Arrays.copyOf(elems, elems.length << 1); >> } >> elems[size++] = String.valueOf(cs); >> } >> > > This looks like the code for the overloaded String.join which takes an array. I was referring to only the version that takes Iterable. I'm looking at the Iterable-based implementation in openjdk/jdk: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L3320 > >> Of course the body in the new code could be extracted to the same >> effect. The drawback in either implementation is that it would by >> necessity be a capturing lambda, so might add a small allocation >> overhead. I'm biased towards avoiding performance overheads, but maybe >> someone else can make a call on whether this is a worthwhile thing to >> attempt. >> > > There is a trade-off here. You remove the need to create an iterator for all types (due to foreach loop), and replace with forEach with a method reference, which IIRC might be slightly better than having a lambda. The underlying collection (let?s say ArrayList) will be called which will also not create an iterator but iterate directly over the ArrayList internal array. Method references and lambdas should boil down to the same thing at runtime. The differentiator for performance is when you need to capture some state, in which the lambda won't be a singleton but instead each invocation will allocate an object that captures the state. I believe this would happen with joiner::add pre-JDK-8265237 (the method ref will capture joiner). But you're right that for many (most?) collections then forEach is specialized and we could become more or less performance neutral. I've prototyped a solution using a local Consumer class, along with a microbenchmark, here: https://github.com/openjdk/jdk/pull/5152/files Both baseline and prototype allocates about as much (ArrayList-based), while the prototype actually comes out slightly faster: Benchmark (count) (length) (mode) Mode Cnt Score Error Units StringJoinerBenchmark.joinIterable 5 1 latin avgt 10 362.882 ? 6.789 ns/op # 18-b09 baseline StringJoinerBenchmark.joinIterable 5 1 latin avgt 10 394.977 ? 9.448 ns/op # prototype Collections without a forEach specialization might suffer since the default method will go via the iterator, but that should be acceptable from a performance point of view. Thanks, Claes > > Thanks, > Don > >> Thanks! >> >> /Claes >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8265237 >> >> On 2021-08-17 06:55, Donald Raab wrote: >>> The following code: >>> for (CharSequence cs: elements) { >>> joiner.add(cs); >>> } >>> Can be replaced with: >>> elements.forEach(joiner::add); >>> This would have the minor benefit of making it safe to use String.join with synchronized collections without requiring a client side lock. There are likely other opportunities like this in the JDK. >>> Also, with the addition of forEach on Iterable, and Predicate in Java 8, the following design FAQ is outdated. >>> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/doc-files/coll-designfaq.html#a6 >>> Thanks, >>> Don > From github.com+5381337+cc007 at openjdk.java.net Tue Aug 17 20:33:31 2021 From: github.com+5381337+cc007 at openjdk.java.net (CC007) Date: Tue, 17 Aug 2021 20:33:31 GMT Subject: RFR: 8272137: Make Collection and Optional classes streamable In-Reply-To: References: Message-ID: <1E8v-cOtCxK4EltY0oZUe0jz05z70hRzfp-8EacEhtI=.3b849e63-185f-4855-aa5d-09f6e911f79f@github.com> On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection and Optional I believe that the accompanying JBS issue (JDK-8272137) can be closed. Maybe a mention of how the discussion in this PR was resolved (with code examples) could be added there before closing it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050 From hseigel at openjdk.java.net Tue Aug 17 20:35:23 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 17 Aug 2021 20:35:23 GMT Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() [v2] In-Reply-To: References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: On Tue, 17 Aug 2021 14:58:48 GMT, Mikhailo Seledtsov wrote: >> Please review this change that updates the buildJdkDockerImage() test library API. >> >> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested". >> The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content. >> As I analyzed the usage of buildJdkDockerImage() I realized that: >> - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest" >> its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils >> - 3rd argument "buildDirName" is also always the same: "jdk-docker" >> >> Hence I thought it would be a good idea to simplify this API and make it up-to-date. >> >> Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology: >> buildJdkDockerImage() --> buildJdkContainerImage() > > Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision: > > Addressing review feedback Other than that one obsolete comment the changes look good. Thanks, Harold test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 175: > 173: /** > 174: * Build a container image based on given Dockerfile and image build directory. > 175: * This comment looks wrong because there is no longer a given Dockerfile. ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5134 From mseledtsov at openjdk.java.net Tue Aug 17 22:06:22 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Tue, 17 Aug 2021 22:06:22 GMT Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() [v2] In-Reply-To: References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: On Tue, 17 Aug 2021 20:30:04 GMT, Harold Seigel wrote: >> Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing review feedback > > test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 175: > >> 173: /** >> 174: * Build a container image based on given Dockerfile and image build directory. >> 175: * > > This comment looks wrong because there is no longer a given Dockerfile. Thanks. I will remove this comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/5134 From mseledtsov at openjdk.java.net Tue Aug 17 22:13:54 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Tue, 17 Aug 2021 22:13:54 GMT Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() [v3] In-Reply-To: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: > Please review this change that updates the buildJdkDockerImage() test library API. > > This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested". > The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content. > As I analyzed the usage of buildJdkDockerImage() I realized that: > - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest" > its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils > - 3rd argument "buildDirName" is also always the same: "jdk-docker" > > Hence I thought it would be a good idea to simplify this API and make it up-to-date. > > Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology: > buildJdkDockerImage() --> buildJdkContainerImage() Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision: Fixed a comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5134/files - new: https://git.openjdk.java.net/jdk/pull/5134/files/d211c220..5dc08781 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5134&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5134&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5134.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5134/head:pull/5134 PR: https://git.openjdk.java.net/jdk/pull/5134 From mseledtsov at openjdk.java.net Tue Aug 17 23:26:28 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Tue, 17 Aug 2021 23:26:28 GMT Subject: Integrated: 8272398: Update DockerTestUtils.buildJdkDockerImage() In-Reply-To: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: <36l3IOw3PFT9woDJaDBUSztd7XkzYJWeCEX2lZvTwI4=.dff81de4-b593-4519-afc9-4a8fab496ec2@github.com> On Mon, 16 Aug 2021 23:31:41 GMT, Mikhailo Seledtsov wrote: > Please review this change that updates the buildJdkDockerImage() test library API. > > This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested". > The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content. > As I analyzed the usage of buildJdkDockerImage() I realized that: > - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest" > its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils > - 3rd argument "buildDirName" is also always the same: "jdk-docker" > > Hence I thought it would be a good idea to simplify this API and make it up-to-date. > > Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology: > buildJdkDockerImage() --> buildJdkContainerImage() This pull request has now been integrated. Changeset: ec63957f Author: Mikhailo Seledtsov URL: https://git.openjdk.java.net/jdk/commit/ec63957f9d103e86d3b8e235e79cabb8992cb3ca Stats: 68 lines in 17 files changed: 20 ins; 13 del; 35 mod 8272398: Update DockerTestUtils.buildJdkDockerImage() Reviewed-by: iignatyev, hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/5134 From mseledtsov at openjdk.java.net Tue Aug 17 23:26:27 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Tue, 17 Aug 2021 23:26:27 GMT Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() [v3] In-Reply-To: References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: <6nxeZAJ9wzVs6WB41Jcfx-4d3iQ24BJ78aPLA6Mmdpc=.e1298d97-a3cd-44b0-a482-3f51c90b3532@github.com> On Tue, 17 Aug 2021 22:13:54 GMT, Mikhailo Seledtsov wrote: >> Please review this change that updates the buildJdkDockerImage() test library API. >> >> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested". >> The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content. >> As I analyzed the usage of buildJdkDockerImage() I realized that: >> - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest" >> its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils >> - 3rd argument "buildDirName" is also always the same: "jdk-docker" >> >> Hence I thought it would be a good idea to simplify this API and make it up-to-date. >> >> Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology: >> buildJdkDockerImage() --> buildJdkContainerImage() > > Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a comment Igor, Harold, thank you for review. ------------- PR: https://git.openjdk.java.net/jdk/pull/5134 From redestad at openjdk.java.net Wed Aug 18 10:14:46 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 18 Aug 2021 10:14:46 GMT Subject: RFR: 8272626: Avoid C-style array declarations in java.* Message-ID: C-style array declarations generate noisy warnings in IDEs, et.c. This patch cleans up all java.* packages. (Copyrights intentionally not updated due the triviality of most changes) ------------- Commit messages: - Avoid C-style array declarations in java packages Changes: https://git.openjdk.java.net/jdk/pull/5161/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5161&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272626 Stats: 140 lines in 54 files changed: 0 ins; 0 del; 140 mod Patch: https://git.openjdk.java.net/jdk/pull/5161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5161/head:pull/5161 PR: https://git.openjdk.java.net/jdk/pull/5161 From dfuchs at openjdk.java.net Wed Aug 18 10:36:22 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 18 Aug 2021 10:36:22 GMT Subject: RFR: 8272626: Avoid C-style array declarations in java.* In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote: > C-style array declarations generate noisy warnings in IDEs, et.c. This patch cleans up all java.* packages. > > (Copyrights intentionally not updated due the triviality of most changes) Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5161 From alanb at openjdk.java.net Wed Aug 18 10:41:27 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 18 Aug 2021 10:41:27 GMT Subject: RFR: 8272626: Avoid C-style array declarations in java.* In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote: > C-style array declarations generate noisy warnings in IDEs, et.c. This patch cleans up all java.* packages. > > (Copyrights intentionally not updated due the triviality of most changes) Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5161 From redestad at openjdk.java.net Wed Aug 18 10:50:32 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 18 Aug 2021 10:50:32 GMT Subject: Integrated: 8272626: Avoid C-style array declarations in java.* In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote: > C-style array declarations generate noisy warnings in IDEs, et.c. This patch cleans up all java.* packages. > > (Copyrights intentionally not updated due the triviality of most changes) This pull request has now been integrated. Changeset: 30b0f820 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/30b0f820cec12b6da62229fe78a528ab3ad0d134 Stats: 140 lines in 54 files changed: 0 ins; 0 del; 140 mod 8272626: Avoid C-style array declarations in java.* Reviewed-by: dfuchs, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5161 From redestad at openjdk.java.net Wed Aug 18 10:50:32 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 18 Aug 2021 10:50:32 GMT Subject: RFR: 8272626: Avoid C-style array declarations in java.* In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote: > C-style array declarations generate noisy warnings in IDEs, et.c. This patch cleans up all java.* packages. > > (Copyrights intentionally not updated due the triviality of most changes) Thanks for reviewing, Daniel and Alan! ------------- PR: https://git.openjdk.java.net/jdk/pull/5161 From hseigel at openjdk.java.net Wed Aug 18 12:25:45 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 18 Aug 2021 12:25:45 GMT Subject: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon [v3] In-Reply-To: References: Message-ID: > Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli". > > The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: add mountinfo containing colongs to test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5127/files - new: https://git.openjdk.java.net/jdk/pull/5127/files/5fa37e97..fcc8c908 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5127&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5127&range=01-02 Stats: 19 lines in 1 file changed: 18 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5127/head:pull/5127 PR: https://git.openjdk.java.net/jdk/pull/5127 From hseigel at openjdk.java.net Wed Aug 18 12:25:46 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 18 Aug 2021 12:25:46 GMT Subject: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon [v2] In-Reply-To: <4hKKCdMZJ4OnLvvdOvTGLkI1DsbMVdPOPMA53U1urWY=.8e11fc69-6756-47ae-b973-cdd114cadfd7@github.com> References: <4hKKCdMZJ4OnLvvdOvTGLkI1DsbMVdPOPMA53U1urWY=.8e11fc69-6756-47ae-b973-cdd114cadfd7@github.com> Message-ID: <8DLm9R5g9w6NFIpQO6L2DkinqvbCYJedTtc7guuhRGw=.1814fadd-53e7-4442-b136-56599fa86cc9@github.com> On Tue, 17 Aug 2021 17:39:49 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli". >> >> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > add test case, comments, and other small changes Please review this update that modifies the new test case to have a mountinfo entry that contains multiple ":" characters. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/5127 From andy.herrick at oracle.com Wed Aug 18 12:43:08 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 18 Aug 2021 08:43:08 -0400 Subject: JPackage and ask for microphone permissions broken on OSX... In-Reply-To: References: Message-ID: <1534b02b-262a-f338-aae5-d1693d0072b3@oracle.com> OK - I have reproduced this problem, filed an issue, and found the fix. You can see the issue in https://bugs.openjdk.java.net/browse/JDK-8272639. Basically another key is needed in application plist to cause application to ask for microphone access. It is far to late to get any fix into JDK17, but I will fix in JDK18 and you can work around this issue in JDK17 (or JDK16) by using the --resource-dir option: /Andy > 1.) create an empty directory test-resources > 2.) copy from the openjdk sources the file > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/Info-lite.plist.template > to test-resources/Info.plist. > 3.) edit test-resources/info.plist to include the key: > ???NSMicrophoneUsageDescription > ????The application is requesting access to the > microphone. > 4.) now add "--resource-dir test-resources" option to your jpackage > command, and it will use this plist template instead of the default one. On 8/16/21 7:41 PM, Filteredaccount1 wrote: > Hi Core-libs-dev, > > I?m trying to report an issue with JPackage on recent versions of OSX. > > Problem is, the microphone permissions aren?t granted to applications created by jpackage. The resulting recorded 16 bit PCM line in samples files are the correct duration, but don?t have any sound (samples all set to 0). > > System Preferences -> Security & Privacy -> Privacy -> Microphone > (application never asks for permissions) > > Otherwise, the only workaround I can figure out is to have the app launch then bootstrap itself using Runtime and grant applications to the Terminal.app (when it calls itself from `java Application.app/MacOS/Resources/Application`) > > There are various reports of this on the Internet - but I?m wondering if the JPackage team is aware of the issue. > > https://stackoverflow.com/questions/55727488/application-doesnt-ask-for-permission-to-access-microphone-in-macos-10-14-mojav > > This pretty much shows the solution - needs a bit of Objective C though. > > Reproducing the problem: JPackage any java sound recording app on latest OSX, run it... will be unable to capture sound. Run the same code from the command line, via classpath or modules... it will record audio after asking the user to grant microphone permissions to Terminal.app. > > It would be great if this is fixed in JDK 17. > > > Many Thanks, > > > Ben S From sgehwolf at openjdk.java.net Wed Aug 18 12:49:26 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 18 Aug 2021 12:49:26 GMT Subject: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon [v2] In-Reply-To: References: <4hKKCdMZJ4OnLvvdOvTGLkI1DsbMVdPOPMA53U1urWY=.8e11fc69-6756-47ae-b973-cdd114cadfd7@github.com> Message-ID: On Tue, 17 Aug 2021 17:46:29 GMT, Severin Gehwolf wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> add test case, comments, and other small changes > > test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java line 375: > >> 373: CgroupInfo memoryInfo = res.getInfos().get("memory"); >> 374: assertEquals(memoryInfo.getCgroupPath(), "/system.slice/containerd.service/kubepods-burstable-podf65e797d_d5f9_4604_9773_94f4bb9946a0.slice:cri-containerd:86ac6260f9f8a9c1276748250f330ae9c2fcefe5ae809364ad1e45f3edf7e08a"); >> 375: assertEquals(memoryInfo.getMountRoot(), memoryInfo.getMountRoot()); > > What I meant here is to also change the mountinfo entry for `memory` and then use > > assertEquals(memoryInfo.getMountRoot(), memoryInfo.getCgroupPath()); > > as that's really what was happening in the wild. mount root - containing colons - would correctly parse, but the cgroup path - containing colons - would not and the assertion would fail (without the change in CgroupSubsystemFactory). Thanks! @hseigel it still has `assertEquals(memoryInfo.getMountRoot(), memoryInfo.getMountRoot());` - tautology - should be: `assertEquals(memoryInfo.getMountRoot(), memoryInfo.getCgroupPath());` ------------- PR: https://git.openjdk.java.net/jdk/pull/5127 From sgehwolf at openjdk.java.net Wed Aug 18 12:49:25 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 18 Aug 2021 12:49:25 GMT Subject: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon [v3] In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 12:25:45 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli". >> >> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > add mountinfo containing colongs to test Changes requested by sgehwolf (Reviewer). test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java line 207: > 205: // `hierarchy-ID:controller-list:cgroup-path`. This cgroup-path intentionally > 206: // contains a colon to ensure that the correct path is being extracted by the > 207: // login in CgroupSubsystemFactory. s/login/logic ------------- PR: https://git.openjdk.java.net/jdk/pull/5127 From hseigel at openjdk.java.net Wed Aug 18 13:04:46 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 18 Aug 2021 13:04:46 GMT Subject: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon [v4] In-Reply-To: References: Message-ID: > Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli". > > The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: Fix test typo and error ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5127/files - new: https://git.openjdk.java.net/jdk/pull/5127/files/fcc8c908..f339fe14 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5127&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5127&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5127/head:pull/5127 PR: https://git.openjdk.java.net/jdk/pull/5127 From hseigel at openjdk.java.net Wed Aug 18 13:04:47 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 18 Aug 2021 13:04:47 GMT Subject: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon [v3] In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 12:25:45 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli". >> >> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > add mountinfo containing colongs to test Thanks for finding those issues. Please review the latest iteration of this fix. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/5127 From rriggs at openjdk.java.net Wed Aug 18 13:20:28 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 18 Aug 2021 13:20:28 GMT Subject: RFR: 8272626: Avoid C-style array declarations in java.* In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote: > C-style array declarations generate noisy warnings in IDEs, et.c. This patch cleans up all java.* packages. > > (Copyrights intentionally not updated due the triviality of most changes) 34 Minutes from proposed to integrated! Its hard to argue with the efficiency, but only 1 timezone of developers had a chance to review or even be aware of the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/5161 From sgehwolf at openjdk.java.net Wed Aug 18 14:13:28 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 18 Aug 2021 14:13:28 GMT Subject: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon [v4] In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 13:04:46 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli". >> >> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > Fix test typo and error Looks good. Thank you! ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5127 From hseigel at openjdk.java.net Wed Aug 18 14:28:27 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 18 Aug 2021 14:28:27 GMT Subject: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon [v4] In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 13:04:46 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli". >> >> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > Fix test typo and error Thanks Severin and Misha for your reviews and improvements for this fix! ------------- PR: https://git.openjdk.java.net/jdk/pull/5127 From hseigel at openjdk.java.net Wed Aug 18 14:28:28 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 18 Aug 2021 14:28:28 GMT Subject: Integrated: 8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 17:25:57 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli". > > The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64. > > Thanks, Harold This pull request has now been integrated. Changeset: 4d6593ce Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/4d6593ce0243457e7431a5990957a8f880e0a3fb Stats: 57 lines in 2 files changed: 54 ins; 0 del; 3 mod 8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon Reviewed-by: mseledtsov, sgehwolf ------------- PR: https://git.openjdk.java.net/jdk/pull/5127 From joe.darcy at oracle.com Wed Aug 18 16:31:12 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 18 Aug 2021 09:31:12 -0700 Subject: RFR: 8272626: Avoid C-style array declarations in java.* In-Reply-To: References: Message-ID: <1eb1c8b3-dfc6-8ba3-9fe3-0df6c6ed4184@oracle.com> On 8/18/2021 6:20 AM, Roger Riggs wrote: > On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote: > >> C-style array declarations generate noisy warnings in IDEs, et.c. This patch cleans up all java.* packages. >> >> (Copyrights intentionally not updated due the triviality of most changes) > 34 Minutes from proposed to integrated! > Its hard to argue with the efficiency, but only 1 timezone of developers had a chance to review or even be aware of the change. > I don't think removing use of this archaic language feature, which doesn't change semantics, should be in any way controversial and is long overdue. -Joe From igraves at openjdk.java.net Wed Aug 18 18:19:32 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 18 Aug 2021 18:19:32 GMT Subject: RFR: 8271302: Regex Test Refresh In-Reply-To: <_jpkGZFcS9zL0JKgTHBD4-1eKEAKTP76i0evJd073bc=.8172da72-d099-4129-83ed-f028fd8e1e18@github.com> References: <_jpkGZFcS9zL0JKgTHBD4-1eKEAKTP76i0evJd073bc=.8172da72-d099-4129-83ed-f028fd8e1e18@github.com> Message-ID: On Fri, 13 Aug 2021 20:16:22 GMT, Brent Christian wrote: >> 8271302: Regex Test Refresh > > test/jdk/java/util/regex/RegExTest.java line 2362: > >> 2360: >> 2361: { "test\ud834\uddc0", "test\ud834\uddc0", "m", true }, >> 2362: //{ "test\ud834\uddbc\ud834\udd6f", "test\ud834\uddc0", "m", true }, //problem > > Should an issue be filed for these //problems ? Yessir! https://bugs.openjdk.java.net/browse/JDK-8271919 ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From igraves at openjdk.java.net Wed Aug 18 18:35:53 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 18 Aug 2021 18:35:53 GMT Subject: RFR: 8271302: Regex Test Refresh [v2] In-Reply-To: References: Message-ID: > 8271302: Regex Test Refresh Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Couple of fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5092/files - new: https://git.openjdk.java.net/jdk/pull/5092/files/1426e323..0e9fa209 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5092/head:pull/5092 PR: https://git.openjdk.java.net/jdk/pull/5092 From igraves at openjdk.java.net Wed Aug 18 18:35:55 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 18 Aug 2021 18:35:55 GMT Subject: RFR: 8271302: Regex Test Refresh [v2] In-Reply-To: <_jpkGZFcS9zL0JKgTHBD4-1eKEAKTP76i0evJd073bc=.8172da72-d099-4129-83ed-f028fd8e1e18@github.com> References: <_jpkGZFcS9zL0JKgTHBD4-1eKEAKTP76i0evJd073bc=.8172da72-d099-4129-83ed-f028fd8e1e18@github.com> Message-ID: On Fri, 13 Aug 2021 20:17:56 GMT, Brent Christian wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Couple of fixes > > test/jdk/java/util/regex/RegExTest.java line 3952: > >> 3950: >> 3951: m = Pattern.compile("\\H").matcher(matcherSubstring); >> 3952: assertTrue(m.find() || ng.equals(m.group())); > > Should this be: > `assertTrue(m.find() && ng.equals(m.group()));` Good catch. De Morgan's mistake ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From bchristi at openjdk.java.net Wed Aug 18 20:32:25 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 18 Aug 2021 20:32:25 GMT Subject: RFR: 8271302: Regex Test Refresh [v2] In-Reply-To: References: Message-ID: <7SGDf5W7Ll9Rk5GWKumSVWdnhph9MqR0iTWbyC_mXyQ=.65c2a8f3-07e2-445d-b31f-6fb7a2c0a7a2@github.com> On Wed, 18 Aug 2021 18:35:53 GMT, Ian Graves wrote: >> 8271302: Regex Test Refresh > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Couple of fixes Marked as reviewed by bchristi (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From simon at cjnash.com Wed Aug 18 21:03:05 2021 From: simon at cjnash.com (Simon Nash) Date: Wed, 18 Aug 2021 22:03:05 +0100 Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default In-Reply-To: <13adfe64-930d-a6cb-22a7-23678f7f09d5@oracle.com> References: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> <3821d480-78e9-47d6-b99a-5fc6df175291@cjnash.com> <13adfe64-930d-a6cb-22a7-23678f7f09d5@oracle.com> Message-ID: On 18/08/2021 20:49, Naoto Sato wrote: > Hi Simon, > > Please post your comments at core-libs-dev mailing list, where the discussion should take place. > > Naoto > My apologies that I am late into the discussion of this JEP. I am the developer of a fairly large application that uses file I/O extensively. In most cases, the charset should be UTF-8 and I have used an explicit charset parameter on all method invocations where this applies. In some cases, the charset needs to be the platform default charset to produce output that is readable by other programs or by a user (for example, Windows-1252 on some versions of Windows). In the cases that need the platform default charset, I have omitted the charset (intentionally, not carelessly or accidentally). If the behaviour changes in these cases, it will produce unexpected results for users. I could try to find all the method invocations that currently use the implicit default charset, although I have no idea how to do this other than reading every line of code. The problems with this are 1) that I would almost certainly miss some invocations that need to be changed and 2) more seriously, from what I have seen in the JEP I don't think there is a way to update these method invocations that works exactly as at present on all versions of Java back to JDK 8 and provides the same behaviour on JDK 18. This is because (as far as I can tell) there is no API call that returns the "old-style" platform default charset and can be used on all JDK versions from JDK 8 to JDK 18. Adding a -D option when the application is started isn't possible in some contexts such as launching the application from a Windows executable jar file association. If I could make a single API call when the application is first started to force backward-compatible behaviour in all cases, this would solve the problem. This feels very much like a "hack" and I would much prefer a clean solution but it would be better than nothing. Does this JEP provide some way to do what I need? Simon From github.com+741251+turbanoff at openjdk.java.net Wed Aug 18 21:04:35 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 18 Aug 2021 21:04:35 GMT Subject: RFR: 8272616: Strange code in java.text.DecimalFormat#applyPattern Message-ID: remove redundant if ------------- Commit messages: - 8272616: Strange code in java.text.DecimalFormat#applyPattern Changes: https://git.openjdk.java.net/jdk/pull/5171/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5171&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272616 Stats: 11 lines in 1 file changed: 1 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5171.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5171/head:pull/5171 PR: https://git.openjdk.java.net/jdk/pull/5171 From bpb at openjdk.java.net Wed Aug 18 21:17:27 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 18 Aug 2021 21:17:27 GMT Subject: RFR: 8272616: Strange code in java.text.DecimalFormat#applyPattern In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 20:59:20 GMT, Andrey Turbanov wrote: > remove redundant if Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5171 From ccheung at openjdk.java.net Wed Aug 18 21:32:51 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 18 Aug 2021 21:32:51 GMT Subject: RFR: 8264322: Generate CDS archive when creating custom JDK image Message-ID: Please review this change for adding a `jlink` command line option `--generate-cds-archive` for generating CDS archives as a post processing step during the creation of a custom JDK image. Details can be found in the corresponding CSR [JDK-8269178](https://bugs.openjdk.java.net/browse/JDK-8269178). Testing: - [x] tiers 1,2 (including the new test) ------------- Commit messages: - fix trailing whitespace - 8264322: Generate CDS archive when creating custom JDK image Changes: https://git.openjdk.java.net/jdk/pull/5174/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5174&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264322 Stats: 394 lines in 11 files changed: 354 ins; 7 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/5174.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5174/head:pull/5174 PR: https://git.openjdk.java.net/jdk/pull/5174 From naoto.sato at oracle.com Wed Aug 18 21:44:06 2021 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 18 Aug 2021 14:44:06 -0700 Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default In-Reply-To: References: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> <3821d480-78e9-47d6-b99a-5fc6df175291@cjnash.com> <13adfe64-930d-a6cb-22a7-23678f7f09d5@oracle.com> Message-ID: <0e614c78-02cf-bb96-1563-1f82eee6fdca@oracle.com> On 8/18/21 2:03 PM, Simon Nash wrote: > I am the developer of a fairly large application that uses file I/O > extensively. In most cases, the charset should be UTF-8 and I have used > an explicit charset parameter on all method invocations where this > applies. In some cases, the charset needs to be the platform default > charset to produce output that is readable by other programs or by a > user (for example, Windows-1252 on some versions of Windows). > > In the cases that need the platform default charset, I have omitted the > charset (intentionally, not carelessly or accidentally). If the > behaviour changes in these cases, it will produce unexpected results for > users. In preparation for JEP 400, we have provided a new system property that retrieves the native encoding name in JDK17: https://bugs.openjdk.java.net/browse/JDK-8265989 Apps that have luxury to make code base change can use the property to retrieve the native encoding, then use it to replace no-arg I/O constructors to the explicit equivalent ones. > > I could try to find all the method invocations that currently use the > implicit default charset, although I have no idea how to do this other > than reading every line of code. The problems with this are 1) that I > would almost certainly miss some invocations that need to be changed and > 2) more seriously, from what I have seen in the JEP I don't think there > is a way to update these method invocations that works exactly as at > present on all versions of Java back to JDK 8 and provides the same > behaviour on JDK 18. This is because (as far as I can tell) there is no > API call that returns the "old-style" platform default charset and can > be used on all JDK versions from JDK 8 to JDK 18. Adding a -D option > when the application is started isn't possible in some contexts such as > launching the application from a Windows executable jar file association. > > If I could make a single API call when the application is first started > to force backward-compatible behaviour in all cases, this would solve > the problem. This feels very much like a "hack" and I would much prefer > a clean solution but it would be better than nothing. I am reluctant to provide such a single API call which has the same effect as `COMPAT`, as it will become less meaningful when UTF-8 as default sinks in. Naoto From naoto at openjdk.java.net Wed Aug 18 21:52:23 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 18 Aug 2021 21:52:23 GMT Subject: RFR: 8272616: Strange code in java.text.DecimalFormat#applyPattern In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 20:59:20 GMT, Andrey Turbanov wrote: > remove redundant if Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5171 From iris at openjdk.java.net Wed Aug 18 22:41:25 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 18 Aug 2021 22:41:25 GMT Subject: RFR: 8272616: Strange code in java.text.DecimalFormat#applyPattern In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 20:59:20 GMT, Andrey Turbanov wrote: > remove redundant if Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5171 From mchung at openjdk.java.net Thu Aug 19 00:37:25 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 19 Aug 2021 00:37:25 GMT Subject: RFR: 8264322: Generate CDS archive when creating custom JDK image In-Reply-To: References: Message-ID: <5C8ZW4JoQhyPGpurPzRQB_HcM3qbKeB3GVtz5Rfh-FY=.7657aee8-3e3c-452e-b080-9cd9edacd2d5@github.com> On Wed, 18 Aug 2021 21:21:06 GMT, Calvin Cheung wrote: > Please review this change for adding a `jlink` command line option `--generate-cds-archive` for generating CDS archives as a post processing step during the creation of a custom JDK image. > > Details can be found in the corresponding CSR [JDK-8269178](https://bugs.openjdk.java.net/browse/JDK-8269178). > > Testing: > > - [x] tiers 1,2 (including the new test) src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java line 89: > 87: private final List args; > 88: private final Set modules; > 89: private Platform platform; Can `DefaultExecutableImage` constructor take an additional `platform` argument and make this `platform` field final? When the `DefaultExecutableImage` is constructed, it already has the target platform information. In the constructor, it can check if the `platform` parameter must not be `UNKNOWN`; otherwise throw IAE. src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java line 134: > 132: > 133: @Override > 134: public void setTargetPlatform(Platform p) { This setter is not needed if it's passed to the constructor. src/jdk.jlink/share/classes/jdk/tools/jlink/builder/ImageBuilder.java line 82: > 80: * Gets the target image platform. > 81: * > 82: * @return Platform Suggestion: * @return {@code Platform} object representing the platform of the runtime image src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ExecutableImage.java line 70: > 68: * @param p > 69: */ > 70: public void setTargetPlatform(Platform p); This method should not be needed. The platform should be known when an executable image is created. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ExecutableImage.java line 75: > 73: * The Platform of the image. > 74: * > 75: * @return Platform Suggestion: * @return {@code Platform} object representing the platform of the runtime image src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ExecutableImage.java line 82: > 80: * Checks if the image is 64-bit. > 81: * > 82: * @return boolean Suggestion: * @return true if it's a 64-bit platform src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ExecutableImage.java line 84: > 82: * @return boolean > 83: */ > 84: public boolean is64Bit(); This `is64Bit` method should belong to `Platform` class src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java line 195: > 193: public void operate(ImageProvider provider) throws Exception { > 194: ExecutableImage img = provider.retrieve(this); > 195: img.setTargetPlatform(imageBuilder.getTargetPlatform()); See above comment - the ExecutableImage should know the platform when it's constructed. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 55: > 53: * Returns the {@code Platform} based on the platformString of the form -. > 54: */ > 55: public static Platform parseTargetPlatform(String platformString) { This method can be renamed back to `parsePlatform` (an earlier version). My suggestion to name this method as `parseTargetPlatform` no longer apply in this version. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/CDSPlugin.java line 80: > 78: status = p.waitFor(); > 79: } catch (Exception ex) { > 80: ex.printStackTrace(); This plugin should fail with any exception. jlink will handle `PluginException` and `UncheckedIOException` and print the error message. You can simply wrap IOException with `UncheckedIOException` try { Process p = builder.inheritIO().start(); status = p.waitFor(); } catch (IOException e) { throw new UncheckedIOException(e); } src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/CDSPlugin.java line 83: > 81: } > 82: if (status == 0) { > 83: System.out.println("Created " + archiveMsg + " archive successfully"); Is it significant to print two lines on 64-bit platform? Users may not have any idea what `NOCOOPS` means? Created CDS archive successfully Created NOCOOPS CDS archive successfully It seems adequate to me as a user to get one output: Created CDS archive successfully src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/CDSPlugin.java line 121: > 119: @Override > 120: public ResourcePool transform(ResourcePool in, ResourcePoolBuilder out) { > 121: in.transformAndCopy((file) -> { This method should not be called in a post-processor. Plugin API needs some re-thinking to support post-processor plugin. As `Plugin::transform` is abstract method, for now this method should simply throw `UnsupportedOperationException`. src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 90: > 88: \ the runtime image. > 89: > 90: main.opt.generate-cds-archive=\ This should not be needed. Leftover from an early version. src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 143: > 141: > 142: generate-cds-archive.description=\ > 143: CDS plugin: generate cds archives (classes.jsa, classes_nocoops.jsa).\n\ Is it necessary to show `classes.jsa, classes_nocoops.jsa` the archive file name? Simply drop them? src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 148: > 146: generate-cds-archive.usage=\ > 147: \ --generate-cds-archive Generate CDS archives (classes.jsa, classes_nocoops.jsa).\n\ > 148: \ Applicable to JDK images built with the CDS feature. Suggestion: \ --generate-cds-archive Generate CDS archives if the runtime image supports CDS feature.\n\ Does this match what you want to say? test/jdk/tools/jlink/plugins/CDSPluginTest.java line 66: > 64: String sep = File.separator; > 65: String osName = System.getProperty("os.name"); > 66: if (System.getProperty("os.name").startsWith("Windows")) { Since this test already depends on `jdk.tools.jlink.internal`, maybe it can use `Platform::runtime` to get the runtime platform. test/jdk/tools/jlink/plugins/CDSPluginTest.java line 80: > 78: String jlinkPath = JDKToolFinder.getJDKTool("jlink"); > 79: String[] cmd = {jlinkPath, "--add-modules", "java.base,java.logging", > 80: "-J-Dos.name=windows", "--generate-cds-archive", Is there a better way of setting `os.name` system property on the command line? Maybe override `ModuleTarget` attribute in module-info.class of java.base to be a different platform? ------------- PR: https://git.openjdk.java.net/jdk/pull/5174 From coderodd3 at gmail.com Thu Aug 19 03:30:03 2021 From: coderodd3 at gmail.com (Rodion Efremov) Date: Thu, 19 Aug 2021 06:30:03 +0300 Subject: [(Much) faster java.util.LinkedList] Message-ID: Hello, I have implemented a heuristic, indexed doubly-linked list data structure [1][2] implementing java.util.List and java.util.Deque interfaces that has superior performance compared to java.util.LinkedList and java.util.ArrayList. I would like to propose it into the upcoming versions of OpenJDK, but, first, I need to know what do you think about it? Best regards, rodde [1] https://github.com/coderodde/LinkedList [2] http://coderodde.github.io/weblog/#eill From liangchenblue at gmail.com Thu Aug 19 04:34:51 2021 From: liangchenblue at gmail.com (-) Date: Wed, 18 Aug 2021 23:34:51 -0500 Subject: Fwd: [(Much) faster java.util.LinkedList] In-Reply-To: References: Message-ID: ---------- Forwarded message --------- From: - Date: Wed, Aug 18, 2021 at 11:34 PM Subject: Re: [(Much) faster java.util.LinkedList] To: Rodion Efremov The main drawback is that this linked list now runs at O(sqrt(N)) than O(1) time complexity for single-element head/tail modifications, which is probably the main usage of linked lists. LinkedList is probably deemed legacy now; in https://bugs.openjdk.java.net/browse/JDK-8263561 ( https://github.com/openjdk/jdk/pull/4304), existing LinkedList usages have been either replaced by ArrayList or ArrayDeque dependent on its type as deque or list. Does this implementation excel either as a list or a deque? Best On Wed, Aug 18, 2021 at 10:30 PM Rodion Efremov wrote: > Hello, > > I have implemented a heuristic, indexed doubly-linked list data structure > [1][2] implementing java.util.List and java.util.Deque interfaces that has > superior performance compared to java.util.LinkedList and > java.util.ArrayList. > > I would like to propose it into the upcoming versions of OpenJDK, but, > first, I need to know what do you think about it? > > Best regards, > rodde > > [1] https://github.com/coderodde/LinkedList > [2] http://coderodde.github.io/weblog/#eill > From github.com+1701815+mkarg at openjdk.java.net Thu Aug 19 06:24:29 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Thu, 19 Aug 2021 06:24:29 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: Message-ID: On Sun, 15 Aug 2021 13:37:23 GMT, Markus KARG wrote: > I think the best course of action is to reduce the scope of this PR to the file channel cases. There is no reason why future PRs can't build on this and add implementations for other channel types. I have split up this PR so that only the lowest hanging fruit is covered and kindly request review: https://github.com/openjdk/jdk/pull/5179. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From Alan.Bateman at oracle.com Thu Aug 19 06:40:13 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Aug 2021 07:40:13 +0100 Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default In-Reply-To: <0e614c78-02cf-bb96-1563-1f82eee6fdca@oracle.com> References: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> <3821d480-78e9-47d6-b99a-5fc6df175291@cjnash.com> <13adfe64-930d-a6cb-22a7-23678f7f09d5@oracle.com> <0e614c78-02cf-bb96-1563-1f82eee6fdca@oracle.com> Message-ID: <53d22a42-1c15-499e-c616-d6a8268d98d7@oracle.com> On 18/08/2021 22:44, Naoto Sato wrote: > On 8/18/21 2:03 PM, Simon Nash wrote: >> I am the developer of a fairly large application that uses file I/O >> extensively. In most cases, the charset should be UTF-8 and I have >> used an explicit charset parameter on all method invocations where >> this applies. In some cases, the charset needs to be the platform >> default charset to produce output that is readable by other programs >> or by a user (for example, Windows-1252 on some versions of Windows). >> >> In the cases that need the platform default charset, I have omitted >> the charset (intentionally, not carelessly or accidentally). If the >> behaviour changes in these cases, it will produce unexpected results >> for users. > > In preparation for JEP 400, we have provided a new system property > that retrieves the native encoding name in JDK17: > > https://bugs.openjdk.java.net/browse/JDK-8265989 > > Apps that have luxury to make code base change can use the property to > retrieve the native encoding, then use it to replace no-arg I/O > constructors to the explicit equivalent ones. Yes, if there is code that really wants to use the native encoding and run of wide range of JDK releases without the using COMPAT then it can read the value of native.encoding and use Charset.defaultCharset if the property is not set. -Alan. From simon at cjnash.com Thu Aug 19 06:59:28 2021 From: simon at cjnash.com (Simon Nash) Date: Thu, 19 Aug 2021 07:59:28 +0100 Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default In-Reply-To: <53d22a42-1c15-499e-c616-d6a8268d98d7@oracle.com> References: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> <3821d480-78e9-47d6-b99a-5fc6df175291@cjnash.com> <13adfe64-930d-a6cb-22a7-23678f7f09d5@oracle.com> <0e614c78-02cf-bb96-1563-1f82eee6fdca@oracle.com> <53d22a42-1c15-499e-c616-d6a8268d98d7@oracle.com> Message-ID: <4160b0e4-9fc5-c2d6-bd30-75e044832068@cjnash.com> On 19/08/2021 07:40, Alan Bateman wrote: > Yes, if there is code that really wants to use the native encoding and run of wide range of JDK releases without the using COMPAT then it can read the value > of native.encoding and use Charset.defaultCharset if the property is not set. > > -Alan. > Thanks for this suggestion. This should work for my situation. Simon From liangchenblue at gmail.com Thu Aug 19 07:16:00 2021 From: liangchenblue at gmail.com (-) Date: Thu, 19 Aug 2021 02:16:00 -0500 Subject: [(Much) faster java.util.LinkedList] In-Reply-To: References: Message-ID: Oh, just fyi, remember to send to core-libs-dev at openjdk.java.net as well; gmail removes the mailing list when you reply by default, so our discussion like these are not shared there. We might need to check the common use cases of linked list in other places (since jdk has largely eliminated it); I think it's mainly used as a deque and a small-sized collection (as arrays for both array deque/list may have empty slots and copying on expansion is costly). We might need to see how this change impacts those usages. On Thu, Aug 19, 2021 at 12:17 AM Rodion Efremov wrote: > Hello, > > True. But could you consider the following table: > > > https://github.com/coderodde/LinkedList/blob/main/README.md#running-time-comparison > > Best regards, > rodde > From myano at openjdk.java.net Thu Aug 19 08:01:26 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Thu, 19 Aug 2021 08:01:26 GMT Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v2] In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 07:25:06 GMT, Masanori Yano wrote: >> Hi all, >> >> Could you please review the 8269373 bug fixes? >> >> These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder. > > Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: > > 8269373: use test opts for process arguments It is true that some other tests say Passed if the locale is not US, but I rather think that is not a good way. I think we should run tests as much as possible to ensure quality even in non-US environments. ------------- PR: https://git.openjdk.java.net/jdk/pull/4594 From coderodd3 at gmail.com Thu Aug 19 09:03:47 2021 From: coderodd3 at gmail.com (Rodion Efremov) Date: Thu, 19 Aug 2021 12:03:47 +0300 Subject: [A linked list data structure running some operations in O(sqrt(n)) time instead of O(n)] Message-ID: Hello, I was kindly directed to this mailing list in order to discuss this data structure: https://github.com/coderodde/LinkedList The README of that repository contains a table of running times for different methods and different List implementations (ArrayList, LinkedList, my version of the LinkedList). Basically, if all we want to do is to add/remove from the head/tail of a List, my implementation won't provide any performance gain. However, in case we want to work on the List in a versatile way (many add(int), addFirst/addLast, get(int), remove(int), removeFirst, removeLast, addAll(int, coll)) my version beats that of java.util package by a factor of 35 in a benchmark I wrote. I understand that ArrayList/LinkedList have a status of legacy code in JDK, but how about including my work with a different name (perhaps, FingerList or something like IndexedList/IndexedLinkedList)? Now, I would like to discuss my work with you. Did I write mature JDK code? Or, can it make it to the JDK in the first place? Best regards, rodde From github.com+10835776+stsypanov at openjdk.java.net Thu Aug 19 11:18:26 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 19 Aug 2021 11:18:26 GMT Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable [v4] In-Reply-To: References: Message-ID: <2Y5ulI-nScJrXU-odPSJt0mDFuXaE9cbqwnc0U-tqqI=.c714ad19-2cc1-421d-bf57-12767cd60d25@github.com> On Thu, 1 Jul 2021 12:19:53 GMT, ?????? ??????? wrote: >> In some JDK classes there's still the following hashCode() implementation: >> >> long objNum; >> >> public int hashCode() { >> return (int) objNum; >> } >> >> This outdated expression should be replaced with Long.hashCode(long) as it >> >> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). >> >> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. >> >> See https://stackoverflow.com/a/4045083 >> >> This is related to https://github.com/openjdk/jdk/pull/4309 > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8268764: Update copy-right year Let's wait, bridgekeeper. ------------- PR: https://git.openjdk.java.net/jdk/pull/4491 From ljnelson at gmail.com Thu Aug 19 14:32:29 2021 From: ljnelson at gmail.com (Laird Nelson) Date: Thu, 19 Aug 2021 07:32:29 -0700 Subject: Process for adding default method to javax.naming.Context? Message-ID: Hello; I am new to this mailing list and its conventions; if I misstep I am happy to be pointed in the right direction. Disclaimer in case it matters: I work for Oracle on project Helidon. I would like to understand how to request an enhancement to the javax.naming.Context interface. A prior discussion on this subject from many years ago can be found here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2016-October/044137.html To recap in brief: being able to do: Frob frob = someNamingContext.lookup("frob", Frob.class); would be very convenient, e.g. via something like: // Proposed new default method in javax.naming.Context default T lookup(Name name, Class type) { return type.cast(lookup(name)); // just delegate to the existing lookup() method } Should I simply file an RFE in https://bugs.openjdk.java.net/ or should I first further discuss the idea here? The contribution guide (https://openjdk.java.net/contribute/) seemed to suggest starting with a discussion on the list when an RFE doesn't already exist, but to be honest there's not much more to the idea than this at the moment. Best, Laird From herrick at openjdk.java.net Thu Aug 19 14:33:42 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 19 Aug 2021 14:33:42 GMT Subject: RFR: JDK-8272639: jpackaged applications using microphone on mac Message-ID: JDK-8272639: jpackaged applications using microphone on mac ------------- Commit messages: - JDK-8272639: jpackaged applications using microphone on mac Changes: https://git.openjdk.java.net/jdk/pull/5186/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5186&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272639 Stats: 5 lines in 3 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5186.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5186/head:pull/5186 PR: https://git.openjdk.java.net/jdk/pull/5186 From shade at openjdk.java.net Thu Aug 19 15:24:33 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 19 Aug 2021 15:24:33 GMT Subject: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1 Message-ID: See the bug report for more details. I would appreciate if people with their corporate testing systems would run this through their systems to avoid surprises. (ping @RealCLanger, @iignatev). ------------- Commit messages: - Drop stream tests exclusivity Changes: https://git.openjdk.java.net/jdk/pull/5189/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5189&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247980 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5189.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5189/head:pull/5189 PR: https://git.openjdk.java.net/jdk/pull/5189 From github.com+741251+turbanoff at openjdk.java.net Thu Aug 19 16:00:27 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 19 Aug 2021 16:00:27 GMT Subject: Integrated: 8272616: Strange code in java.text.DecimalFormat#applyPattern In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 20:59:20 GMT, Andrey Turbanov wrote: > remove redundant if This pull request has now been integrated. Changeset: 51c1b9a6 Author: Andrey Turbanov Committer: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/51c1b9a6870bd9644e92227e47082a53e2d1c066 Stats: 11 lines in 1 file changed: 1 ins; 3 del; 7 mod 8272616: Strange code in java.text.DecimalFormat#applyPattern Reviewed-by: bpb, naoto, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/5171 From iignatyev at openjdk.java.net Thu Aug 19 16:10:25 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 19 Aug 2021 16:10:25 GMT Subject: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1 In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote: > See the bug report for more details. I would appreciate if people with their corporate testing systems would run this through their systems to avoid surprises. (ping @RealCLanger, @iignatev). Hi @shipilev , I've submitted testing for this patch in our system. meanwhile, I'd like to hear @PaulSandoz's and/or @AlanBateman's option on this as I don't think that the underlying issue, that forced us to add these tests to `exclusiveAccess.dirs` by [8058204](https://bugs.openjdk.java.net/browse/JDK-8058204), was resolved. Thanks, -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/5189 From Alan.Bateman at oracle.com Thu Aug 19 16:21:12 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Aug 2021 17:21:12 +0100 Subject: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1 In-Reply-To: References: Message-ID: <0d92687d-15b9-1f50-8405-65c3968c84e3@oracle.com> On 19/08/2021 17:10, Igor Ignatyev wrote: > On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote: > >> See the bug report for more details. I would appreciate if people with their corporate testing systems would run this through their systems to avoid surprises. (ping @RealCLanger, @iignatev). > Hi @shipilev , > > I've submitted testing for this patch in our system. meanwhile, I'd like to hear @PaulSandoz's and/or @AlanBateman's option on this as I don't think that the underlying issue, that forced us to add these tests to `exclusiveAccess.dirs` by [8058204](https://bugs.openjdk.java.net/browse/JDK-8058204), was resolved. > These tests use all cores so were historically problematic with several agents VMs running concurrently, lots of timeouts. I don't recall if the reason for putting then on exclusiveAccess.dirs was release or debug builds. Getting fresh results would be useful. -Alan From psandoz at openjdk.java.net Thu Aug 19 16:41:24 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 19 Aug 2021 16:41:24 GMT Subject: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1 In-Reply-To: References: Message-ID: <7sJQZ0e_hxYgpakKcKNlBOuKpgLkUwDGht-F6v9fNT8=.f667e0cc-09c1-416c-bf93-69c33f864a96@github.com> On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote: > See the bug report for more details. I would appreciate if people with their corporate testing systems would run this through their systems to avoid surprises. (ping @RealCLanger, @iignatev). Struggling to recall all the details. I think in part the tests were made exclusive to avoid the greedy parallel tests potentially competing with the execution of other greedy parallel stream tests and other independent tests. The issue may be petrubed when using machines with a large number of cores, as cost of greedly using all hardware threads is counter productive to the data sizes. It may be useful if we could limit the parallelism of stream tests on machines with large cores. I don't recall if we currently do that or have explored that. There may be no ideal configuration that fits machines with small and large cores. If there is a prioritization i would lean towards optimization by default for the automated test infra with options to modify that default for others running the tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/5189 From bpb at openjdk.java.net Thu Aug 19 19:35:27 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 19 Aug 2021 19:35:27 GMT Subject: RFR: 8271225: Add floorDivExact() method to java.lang.[Strict]Math [v3] In-Reply-To: References: Message-ID: <-_FTEUYbOwM0nT-CpzPVJdAOM47QtVqtpTFwrAWirUc=.894ac01e-43bd-4652-8782-b9d9a3501719@github.com> On Thu, 5 Aug 2021 18:57:42 GMT, Brian Burkhalter wrote: >> Add methods `floorDivExact(int,int)` and `floorDivExact(long,long)` to `java.lang.Math` and `java.lang.StrictMath`. > > Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - 8271225: Verbiage update after 8271599 > - Merge > - 8271225: Revert drive-by verbiage updates > - 8271225: Some verbiage updates > - 8271225: Add floorDivExact() method to java.lang.[Strict]Math The CSR for this PR has been approved. ------------- PR: https://git.openjdk.java.net/jdk/pull/4941 From almatvee at openjdk.java.net Thu Aug 19 20:59:24 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 19 Aug 2021 20:59:24 GMT Subject: RFR: JDK-8272639: jpackaged applications using microphone on mac In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 14:12:00 GMT, Andy Herrick wrote: > JDK-8272639: jpackaged applications using microphone on mac Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5186 From javalists at cbfiddle.com Thu Aug 19 21:52:54 2021 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 19 Aug 2021 14:52:54 -0700 Subject: what does the spec say about file paths that are too long? Message-ID: <7CBCF03A-AEBA-46EE-BCBD-4ED9D1C97450@cbfiddle.com> I?ve been looking for some specification of what happens when a file request is made using a path that is too long (whatever that means to the underlying system). I have not found one. Is there one? My opinion is that silent truncation should not happen. Instead, an exception should be thrown. I have had the misfortunate of using an application (not Java) that did not check path lengths and the OS truncated the paths. The result was a kind of corruption to an implied schema causing incorrect search results and potentially data loss. Writing defensively to protect against silent path truncation is probably quite challenging, as well as tedious, especially when working with a system-independent API. If it is not already covered, I would like to see the specification mandate exceptions instead of silent truncation. From serb at openjdk.java.net Thu Aug 19 22:49:29 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 19 Aug 2021 22:49:29 GMT Subject: RFR: JDK-8272639: jpackaged applications using microphone on mac In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 14:12:00 GMT, Andy Herrick wrote: > JDK-8272639: jpackaged applications using microphone on mac src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/Info-lite.plist.template line 37: > 35: true > 36: NSMicrophoneUsageDescription > 37: The application is requesting access to the microphone. Should not it include the "application name" here? This is different from the java tool, where we do not know that info in advance. ------------- PR: https://git.openjdk.java.net/jdk/pull/5186 From mgronlun at openjdk.java.net Thu Aug 19 22:59:08 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 19 Aug 2021 22:59:08 GMT Subject: RFR: 8266936: Add a finalization JFR event [v5] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund 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 20 additional commits since the last revision: - Merge branches '8266936-alt' and '8266936-alt' of github.com:mgronlun/jdk into 8266936-alt - remove build directive - Code Source attribute for Finalizer event - whitespace - update - update - whitespace - 8266936-alt: Add a finalization JFR event - shortcut calling Jfr::is_recording() - 8266936: Add a finalization JFR event - ... and 10 more: https://git.openjdk.java.net/jdk/compare/663b1a74...c8dbca54 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/44988036..c8dbca54 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=03-04 Stats: 65693 lines in 1278 files changed: 54237 ins; 5619 del; 5837 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Thu Aug 19 23:26:25 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 19 Aug 2021 23:26:25 GMT Subject: RFR: 8266936: Add a finalization JFR event [v6] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund 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. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/c8dbca54..d8b829e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=04-05 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From ccheung at openjdk.java.net Fri Aug 20 00:09:01 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 20 Aug 2021 00:09:01 GMT Subject: RFR: 8264322: Generate CDS archive when creating custom JDK image [v2] In-Reply-To: References: Message-ID: > Please review this change for adding a `jlink` command line option `--generate-cds-archive` for generating CDS archives as a post processing step during the creation of a custom JDK image. > > Details can be found in the corresponding CSR [JDK-8269178](https://bugs.openjdk.java.net/browse/JDK-8269178). > > Testing: > > - [x] tiers 1,2 (including the new test) Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: @mlchung comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5174/files - new: https://git.openjdk.java.net/jdk/pull/5174/files/918d5066..b7a5ec68 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5174&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5174&range=00-01 Stats: 74 lines in 10 files changed: 14 ins; 39 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/5174.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5174/head:pull/5174 PR: https://git.openjdk.java.net/jdk/pull/5174 From ccheung at openjdk.java.net Fri Aug 20 00:09:26 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 20 Aug 2021 00:09:26 GMT Subject: RFR: 8264322: Generate CDS archive when creating custom JDK image [v2] In-Reply-To: <5C8ZW4JoQhyPGpurPzRQB_HcM3qbKeB3GVtz5Rfh-FY=.7657aee8-3e3c-452e-b080-9cd9edacd2d5@github.com> References: <5C8ZW4JoQhyPGpurPzRQB_HcM3qbKeB3GVtz5Rfh-FY=.7657aee8-3e3c-452e-b080-9cd9edacd2d5@github.com> Message-ID: <1r_8lzqM5SlOweerNiJsnNeh6j-xFs8KpAuhGTTGpKE=.1005a3b2-4697-46f5-a0aa-e438656e5b7c@github.com> On Wed, 18 Aug 2021 23:55:25 GMT, Mandy Chung wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> @mlchung comments > > src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java line 89: > >> 87: private final List args; >> 88: private final Set modules; >> 89: private Platform platform; > > Can `DefaultExecutableImage` constructor take an additional `platform` argument and make this `platform` field final? > > When the `DefaultExecutableImage` is constructed, it already has the target platform information. > > In the constructor, it can check if the `platform` parameter must not be `UNKNOWN`; otherwise throw IAE. I've added the `platform` argument and made the `platform` field final. However, as we've discussed offline, there's a code path via the `--post-process-path` option where the platform may not be available. So we can't throw IAE on an `UNKNOWN` platform in the constructor. > src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java line 134: > >> 132: >> 133: @Override >> 134: public void setTargetPlatform(Platform p) { > > This setter is not needed if it's passed to the constructor. Fixed. > src/jdk.jlink/share/classes/jdk/tools/jlink/builder/ImageBuilder.java line 82: > >> 80: * Gets the target image platform. >> 81: * >> 82: * @return Platform > > Suggestion: > > * @return {@code Platform} object representing the platform of the runtime image Fixed. > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ExecutableImage.java line 70: > >> 68: * @param p >> 69: */ >> 70: public void setTargetPlatform(Platform p); > > This method should not be needed. The platform should be known when an executable image is created. Fixed. > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ExecutableImage.java line 75: > >> 73: * The Platform of the image. >> 74: * >> 75: * @return Platform > > Suggestion: > > * @return {@code Platform} object representing the platform of the runtime image Done. > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ExecutableImage.java line 82: > >> 80: * Checks if the image is 64-bit. >> 81: * >> 82: * @return boolean > > Suggestion: > > * @return true if it's a 64-bit platform Fixed. > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ExecutableImage.java line 84: > >> 82: * @return boolean >> 83: */ >> 84: public boolean is64Bit(); > > This `is64Bit` method should belong to `Platform` class Done. I've moved the method to the `Platform` class. > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java line 195: > >> 193: public void operate(ImageProvider provider) throws Exception { >> 194: ExecutableImage img = provider.retrieve(this); >> 195: img.setTargetPlatform(imageBuilder.getTargetPlatform()); > > See above comment - the ExecutableImage should know the platform when it's constructed. Removed the code. > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 55: > >> 53: * Returns the {@code Platform} based on the platformString of the form -. >> 54: */ >> 55: public static Platform parseTargetPlatform(String platformString) { > > This method can be renamed back to `parsePlatform` (an earlier version). My suggestion to name this method as `parseTargetPlatform` no longer apply in this version. Changed the name back to `parsePlatform`. > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/CDSPlugin.java line 80: > >> 78: status = p.waitFor(); >> 79: } catch (Exception ex) { >> 80: ex.printStackTrace(); > > This plugin should fail with any exception. jlink will handle `PluginException` and `UncheckedIOException` and print the error message. You can simply wrap IOException with `UncheckedIOException` > > > try { > Process p = builder.inheritIO().start(); > status = p.waitFor(); > } catch (IOException e) { > throw new UncheckedIOException(e); > } I've changed it to the following since we also need to catch the `InterruptedException`: try { Process p = builder.inheritIO().start(); status = p.waitFor(); } catch (InterruptedException | IOException e) { throw new PluginException(e); } > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/CDSPlugin.java line 83: > >> 81: } >> 82: if (status == 0) { >> 83: System.out.println("Created " + archiveMsg + " archive successfully"); > > Is it significant to print two lines on 64-bit platform? Users may not have any idea what `NOCOOPS` means? > > Created CDS archive successfully > Created NOCOOPS CDS archive successfully > > It seems adequate to me as a user to get one output: > > Created CDS archive successfully I've made the change; the plugin will print only one successful message. > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/CDSPlugin.java line 121: > >> 119: @Override >> 120: public ResourcePool transform(ResourcePool in, ResourcePoolBuilder out) { >> 121: in.transformAndCopy((file) -> { > > This method should not be called in a post-processor. Plugin API needs some re-thinking to support post-processor plugin. As `Plugin::transform` is abstract method, for now this method should simply throw `UnsupportedOperationException`. It is being called. The minimal implementation is: @Override public ResourcePool transform(ResourcePool in, ResourcePoolBuilder out) { return in; } I've filed [JDK-8272734](https://bugs.openjdk.java.net/browse/JDK-8272743) to follow-up the issue. > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 90: > >> 88: \ the runtime image. >> 89: >> 90: main.opt.generate-cds-archive=\ > > This should not be needed. Leftover from an early version. Removed. > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 143: > >> 141: >> 142: generate-cds-archive.description=\ >> 143: CDS plugin: generate cds archives (classes.jsa, classes_nocoops.jsa).\n\ > > Is it necessary to show `classes.jsa, classes_nocoops.jsa` the archive file name? Simply drop them? Removed the file names. > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 148: > >> 146: generate-cds-archive.usage=\ >> 147: \ --generate-cds-archive Generate CDS archives (classes.jsa, classes_nocoops.jsa).\n\ >> 148: \ Applicable to JDK images built with the CDS feature. > > Suggestion: > > \ --generate-cds-archive Generate CDS archives if the runtime image supports CDS feature.\n\ > > > Does this match what you want to say? Yes. > test/jdk/tools/jlink/plugins/CDSPluginTest.java line 66: > >> 64: String sep = File.separator; >> 65: String osName = System.getProperty("os.name"); >> 66: if (System.getProperty("os.name").startsWith("Windows")) { > > Since this test already depends on `jdk.tools.jlink.internal`, maybe it can use `Platform::runtime` to get the runtime platform. I'm using the `jdk.test.lib.Platform` so that `if (Platform.isWindows())` can be used to check if the platform is Windows. > test/jdk/tools/jlink/plugins/CDSPluginTest.java line 80: > >> 78: String jlinkPath = JDKToolFinder.getJDKTool("jlink"); >> 79: String[] cmd = {jlinkPath, "--add-modules", "java.base,java.logging", >> 80: "-J-Dos.name=windows", "--generate-cds-archive", > > Is there a better way of setting `os.name` system property on the command line? > > Maybe override `ModuleTarget` attribute in module-info.class of java.base to be a different platform? I'd prefer to leave it as is for now since it's in a test case and I don't think the code is complex. ------------- PR: https://git.openjdk.java.net/jdk/pull/5174 From mchung at openjdk.java.net Fri Aug 20 02:01:29 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 20 Aug 2021 02:01:29 GMT Subject: RFR: 8264322: Generate CDS archive when creating custom JDK image [v2] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 00:09:01 GMT, Calvin Cheung wrote: >> Please review this change for adding a `jlink` command line option `--generate-cds-archive` for generating CDS archives as a post processing step during the creation of a custom JDK image. >> >> Details can be found in the corresponding CSR [JDK-8269178](https://bugs.openjdk.java.net/browse/JDK-8269178). >> >> Testing: >> >> - [x] tiers 1,2 (including the new test) > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @mlchung comments Thanks for the change. Looks okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/5174 From mchung at openjdk.java.net Fri Aug 20 02:01:29 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 20 Aug 2021 02:01:29 GMT Subject: RFR: 8264322: Generate CDS archive when creating custom JDK image [v2] In-Reply-To: <1r_8lzqM5SlOweerNiJsnNeh6j-xFs8KpAuhGTTGpKE=.1005a3b2-4697-46f5-a0aa-e438656e5b7c@github.com> References: <5C8ZW4JoQhyPGpurPzRQB_HcM3qbKeB3GVtz5Rfh-FY=.7657aee8-3e3c-452e-b080-9cd9edacd2d5@github.com> <1r_8lzqM5SlOweerNiJsnNeh6j-xFs8KpAuhGTTGpKE=.1005a3b2-4697-46f5-a0aa-e438656e5b7c@github.com> Message-ID: On Thu, 19 Aug 2021 23:56:00 GMT, Calvin Cheung wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java line 89: >> >>> 87: private final List args; >>> 88: private final Set modules; >>> 89: private Platform platform; >> >> Can `DefaultExecutableImage` constructor take an additional `platform` argument and make this `platform` field final? >> >> When the `DefaultExecutableImage` is constructed, it already has the target platform information. >> >> In the constructor, it can check if the `platform` parameter must not be `UNKNOWN`; otherwise throw IAE. > > I've added the `platform` argument and made the `platform` field final. > However, as we've discussed offline, there's a code path via the `--post-process-path` option where the platform may not be available. So we can't throw IAE on an `UNKNOWN` platform in the constructor. Since `--post-process-path` is a hidden option, it's fine not to support it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5174 From mchung at openjdk.java.net Fri Aug 20 02:07:25 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 20 Aug 2021 02:07:25 GMT Subject: RFR: 8264322: Generate CDS archive when creating custom JDK image [v2] In-Reply-To: <1r_8lzqM5SlOweerNiJsnNeh6j-xFs8KpAuhGTTGpKE=.1005a3b2-4697-46f5-a0aa-e438656e5b7c@github.com> References: <5C8ZW4JoQhyPGpurPzRQB_HcM3qbKeB3GVtz5Rfh-FY=.7657aee8-3e3c-452e-b080-9cd9edacd2d5@github.com> <1r_8lzqM5SlOweerNiJsnNeh6j-xFs8KpAuhGTTGpKE=.1005a3b2-4697-46f5-a0aa-e438656e5b7c@github.com> Message-ID: <7-Cono7O5baO1NjJNuZe1ol7E-57gh246Fi8ycvq14M=.4c4d4cd6-0cae-4a75-92dd-1be9b5b997a9@github.com> On Thu, 19 Aug 2021 23:59:32 GMT, Calvin Cheung wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/CDSPlugin.java line 121: >> >>> 119: @Override >>> 120: public ResourcePool transform(ResourcePool in, ResourcePoolBuilder out) { >>> 121: in.transformAndCopy((file) -> { >> >> This method should not be called in a post-processor. Plugin API needs some re-thinking to support post-processor plugin. As `Plugin::transform` is abstract method, for now this method should simply throw `UnsupportedOperationException`. > > It is being called. The minimal implementation is: > > > @Override > public ResourcePool transform(ResourcePool in, ResourcePoolBuilder out) { > return in; > } > > I've filed [JDK-8272734](https://bugs.openjdk.java.net/browse/JDK-8272743) to follow-up the issue. Thanks for filing the issue. I didn't expect `Plugin::transform` should be called. This is a good workaround for now. >> test/jdk/tools/jlink/plugins/CDSPluginTest.java line 80: >> >>> 78: String jlinkPath = JDKToolFinder.getJDKTool("jlink"); >>> 79: String[] cmd = {jlinkPath, "--add-modules", "java.base,java.logging", >>> 80: "-J-Dos.name=windows", "--generate-cds-archive", >> >> Is there a better way of setting `os.name` system property on the command line? >> >> Maybe override `ModuleTarget` attribute in module-info.class of java.base to be a different platform? > > I'd prefer to leave it as is for now since it's in a test case and I don't think the code is complex. This is fragile by setting `os.name`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5174 From Alan.Bateman at oracle.com Fri Aug 20 09:58:01 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Aug 2021 10:58:01 +0100 Subject: what does the spec say about file paths that are too long? In-Reply-To: <7CBCF03A-AEBA-46EE-BCBD-4ED9D1C97450@cbfiddle.com> References: <7CBCF03A-AEBA-46EE-BCBD-4ED9D1C97450@cbfiddle.com> Message-ID: On 19/08/2021 22:52, Alan Snyder wrote: > I?ve been looking for some specification of what happens when a file request is made using a path that is too long (whatever that means to the underlying system). > I have not found one. > Is there one? > > My opinion is that silent truncation should not happen. Instead, an exception should be thrown. > > I have had the misfortunate of using an application (not Java) that did not check path lengths and the OS truncated the paths. > The result was a kind of corruption to an implied schema causing incorrect search results and potentially data loss. > > Writing defensively to protect against silent path truncation is probably quite challenging, as well as tedious, > especially when working with a system-independent API. > > If it is not already covered, I would like to see the specification mandate exceptions instead of silent truncation. > Where are you seeing "silent truncation"? You should see an I/O exception if you attempt to access a file and the resolved file path is too long. -Alan From Alan.Bateman at oracle.com Fri Aug 20 10:12:52 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Aug 2021 11:12:52 +0100 Subject: Process for adding default method to javax.naming.Context? In-Reply-To: References: Message-ID: <4f438149-b1a1-fa9e-fa18-dc8bbaf60c63@oracle.com> On 19/08/2021 15:32, Laird Nelson wrote: > : > > To recap in brief: being able to do: > > Frob frob = someNamingContext.lookup("frob", Frob.class); > > would be very convenient, e.g. via something like: > > // Proposed new default method in javax.naming.Context > default T lookup(Name name, Class type) { > return type.cast(lookup(name)); // just delegate to the existing > lookup() method > } > > Should I simply file an RFE in https://bugs.openjdk.java.net/ or should I > first further discuss the idea here? > > The contribution guide (https://openjdk.java.net/contribute/) seemed to > suggest starting with a discussion on the list when an RFE doesn't already > exist, but to be honest there's not much more to the idea than this at the > moment. Yes, it's best to start a discussion here. We can create a JBS issues as needed. I think you are asking for an overload that specifies a class literal as a type token to avoid an explicit cast at the use-sites. Is this to improve usages within Helidon or are there enterprise libs that expose JNDI Context objects that would be used by a wider set of users? -Alan From gli at openjdk.java.net Fri Aug 20 10:34:28 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 20 Aug 2021 10:34:28 GMT Subject: [jdk17] RFR: 8270916: Update java.lang.annotation.Target for changes in JLS 9.6.4.1 In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 19:38:07 GMT, Joe Darcy wrote: >> Given changes in JLS 9.6.4.1, JDK-8261610 in Java SE 17, the statements about annotation applicability made in java.lang.annotation.Target need to be updated to match. >> >> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8270917 > > CSR now approved. Hi @jddarcy, Sorry for the delay. I notice the current javac code(shown below) doesn't meet the JLS 9.6.4.1 . The code doesn't mark `TYPE_PARAMETER` as the default target. Because the PR https://github.com/openjdk/jdk/pull/622 and https://github.com/openjdk/jdk/pull/2412 , which tried to fix this problem, is earlier than the [JDK-8261610](https://bugs.openjdk.java.net/browse/JDK-8261610), [JDK-8270916](https://bugs.openjdk.java.net/browse/JDK-8270916), and [JDK-8270917](https://bugs.openjdk.java.net/browse/JDK-8270917). According to the new JLS 9.6.4.1, the javac compiler should be adjusted to add `TYPE_PARAMETER` as the default target. Should we fix the compiler issue in JDK17? But it seems too late to do that. Maybe JDK18 is a good place. What do you think about it? Any ideas are appreciated. // com.sun.tools.javac.comp.Check.java private Name[] dfltTargetMeta; private Name[] defaultTargetMetaInfo() { if (dfltTargetMeta == null) { ArrayList defaultTargets = new ArrayList<>(); defaultTargets.add(names.PACKAGE); defaultTargets.add(names.TYPE); defaultTargets.add(names.FIELD); defaultTargets.add(names.METHOD); defaultTargets.add(names.CONSTRUCTOR); defaultTargets.add(names.ANNOTATION_TYPE); defaultTargets.add(names.LOCAL_VARIABLE); defaultTargets.add(names.PARAMETER); if (allowRecords) { defaultTargets.add(names.RECORD_COMPONENT); } if (allowModules) { defaultTargets.add(names.MODULE); } dfltTargetMeta = defaultTargets.toArray(new Name[0]); } return dfltTargetMeta; } Best Regards, -- Guoxiong ------------- PR: https://git.openjdk.java.net/jdk17/pull/256 From prappo at openjdk.java.net Fri Aug 20 13:57:32 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 20 Aug 2021 13:57:32 GMT Subject: RFR: 8271302: Regex Test Refresh [v2] In-Reply-To: References: Message-ID: <4gsqMFxqlgphTRZQR7uc1V2nm8eHSG8RNSjgOGYuS90=.b86723df-0de5-4e09-bd76-e302b9a6f682@github.com> On Wed, 18 Aug 2021 18:35:53 GMT, Ian Graves wrote: >> 8271302: Regex Test Refresh > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Couple of fixes test/jdk/java/util/regex/NegativeArraySize.java line 2: > 1: /* > 2: * Copyright (c) 2019, 2021 Oracle and/or its affiliates. All rights reserved. Add comma after 2021, or the copyright headers check won't pass. test/jdk/java/util/regex/NegativeArraySize.java line 29: > 27: * @summary Pattern.compile() can throw confusing NegativeArraySizeException > 28: * @requires os.maxMemory >= 5g > 29: * @run testng/othervm -Xms5G -Xmx5G NegativeArraySize I note that the order of the arguments has changed. Will that work as expected? Had it worked as expected before? test/jdk/java/util/regex/NegativeArraySize.java line 40: > 38: @Test > 39: public static void testNegativeArraySize() { > 40: assertThrows(OutOfMemoryError.class, () -> Pattern.compile("\\Q" + "a".repeat(42 + Integer.MAX_VALUE / 3))); One observation on this regex. Although the regex looks invalid because `\\Q` misses the pairing `\\E`, it can still be compiled (with a reasonable number of a's, of course). Moreover, the resulting pattern matches strings in a surprising way: jshell> Pattern.compile("\\Qaaa").matcher("aaa").matches() $1 ==> true test/jdk/java/util/regex/RegExTest.java line 27: > 25: * @test > 26: * @summary tests RegExp framework (use -Dseed=X to set PRNG seed) > 27: * @author Mike McCloskey What happened to Mike here? :-) test/jdk/java/util/regex/RegExTest.java line 121: > 119: private static void check(String p, String s, boolean expected) { > 120: Matcher matcher = Pattern.compile(p).matcher(s); > 121: assertSame(matcher.find(), expected); Why use `assertSame(Object, Object)`? I would expect `assertEquals(boolean, boolean)`. test/jdk/java/util/regex/RegExTest.java line 206: > 204: } > 205: > 206: // Regular expression test// Most of the tests are in a file Mistakenly joined comment lines? ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From javalists at cbfiddle.com Fri Aug 20 14:05:13 2021 From: javalists at cbfiddle.com (Alan Snyder) Date: Fri, 20 Aug 2021 07:05:13 -0700 Subject: what does the spec say about file paths that are too long? In-Reply-To: References: <7CBCF03A-AEBA-46EE-BCBD-4ED9D1C97450@cbfiddle.com> Message-ID: Where did I say that I was seeing silent truncation? My question is about the specification. I want to know if I should write code that defends against silent truncation. I should be writing code based on the specification, not what I observe in a test program on a particular platform. I?m pleased that you believe an exception should be thrown, but is that behavior mandated in the specification and tested by the JCK? Alan > On Aug 20, 2021, at 2:58 AM, Alan Bateman wrote: > > Where are you seeing "silent truncation"? You should see an I/O exception if you attempt to access a file and the resolved file path is too long. > > -Alan > From prappo at openjdk.java.net Fri Aug 20 14:28:25 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 20 Aug 2021 14:28:25 GMT Subject: RFR: 8271302: Regex Test Refresh [v2] In-Reply-To: <4gsqMFxqlgphTRZQR7uc1V2nm8eHSG8RNSjgOGYuS90=.b86723df-0de5-4e09-bd76-e302b9a6f682@github.com> References: <4gsqMFxqlgphTRZQR7uc1V2nm8eHSG8RNSjgOGYuS90=.b86723df-0de5-4e09-bd76-e302b9a6f682@github.com> Message-ID: On Fri, 20 Aug 2021 13:46:39 GMT, Pavel Rappo wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Couple of fixes > > test/jdk/java/util/regex/NegativeArraySize.java line 40: > >> 38: @Test >> 39: public static void testNegativeArraySize() { >> 40: assertThrows(OutOfMemoryError.class, () -> Pattern.compile("\\Q" + "a".repeat(42 + Integer.MAX_VALUE / 3))); > > One observation on this regex. Although the regex looks invalid because `\\Q` misses the pairing `\\E`, it can still be compiled (with a reasonable number of a's, of course). Moreover, the resulting pattern matches strings in a surprising way: > > > jshell> Pattern.compile("\\Qaaa").matcher("aaa").matches() > $1 ==> true Maybe that behavior is expected after all. From "Mastering Regular Expressions" by Jeffrey E.F. Friedl, 3rd Edition, p. 136: > Literal-text span: `\Q...\E` > > First introduced with Perl, the special sequence `\Q...\E` turns off all regex meta-characters between them, except for `\E` itself. (If the `\E` is omitted, they are turned off until the end of the regex.) ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From igraves at openjdk.java.net Fri Aug 20 15:49:27 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Fri, 20 Aug 2021 15:49:27 GMT Subject: RFR: 8271302: Regex Test Refresh [v2] In-Reply-To: <4gsqMFxqlgphTRZQR7uc1V2nm8eHSG8RNSjgOGYuS90=.b86723df-0de5-4e09-bd76-e302b9a6f682@github.com> References: <4gsqMFxqlgphTRZQR7uc1V2nm8eHSG8RNSjgOGYuS90=.b86723df-0de5-4e09-bd76-e302b9a6f682@github.com> Message-ID: On Fri, 20 Aug 2021 13:32:24 GMT, Pavel Rappo wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Couple of fixes > > test/jdk/java/util/regex/NegativeArraySize.java line 29: > >> 27: * @summary Pattern.compile() can throw confusing NegativeArraySizeException >> 28: * @requires os.maxMemory >= 5g >> 29: * @run testng/othervm -Xms5G -Xmx5G NegativeArraySize > > I note that the order of the arguments has changed. Will that work as expected? Had it worked as expected before? The new order is consistent with other tests. I had difficulty getting it to run in the original configuration. Perhaps jtreg is more sensitive on order with the testng runner. > test/jdk/java/util/regex/RegExTest.java line 121: > >> 119: private static void check(String p, String s, boolean expected) { >> 120: Matcher matcher = Pattern.compile(p).matcher(s); >> 121: assertSame(matcher.find(), expected); > > Why use `assertSame(Object, Object)`? I would expect `assertEquals(boolean, boolean)`. Artifacting because of the use of `==` I'll make it more readable. ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From igraves at openjdk.java.net Fri Aug 20 16:27:53 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Fri, 20 Aug 2021 16:27:53 GMT Subject: RFR: 8271302: Regex Test Refresh [v3] In-Reply-To: References: Message-ID: > 8271302: Regex Test Refresh Ian Graves has updated the pull request incrementally with one additional commit since the last revision: some quick fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5092/files - new: https://git.openjdk.java.net/jdk/pull/5092/files/0e9fa209..3937bf8f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=01-02 Stats: 8 lines in 2 files changed: 1 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5092/head:pull/5092 PR: https://git.openjdk.java.net/jdk/pull/5092 From prappo at openjdk.java.net Fri Aug 20 16:55:26 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 20 Aug 2021 16:55:26 GMT Subject: RFR: 8271302: Regex Test Refresh [v3] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 16:27:53 GMT, Ian Graves wrote: >> 8271302: Regex Test Refresh > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > some quick fixes test/jdk/java/util/regex/RegExTest.java line 4270: > 4268: String s = (String)pm[1]; > 4269: boolean r = (Boolean)pm[2]; > 4270: assertSame(r, Pattern.compile(p).matcher(s).matches()); `assertEquals(boolean, boolean)` might be better. test/jdk/java/util/regex/RegExTest.java line 4270: > 4268: String s = (String)pm[1]; > 4269: boolean r = (Boolean)pm[2]; > 4270: assertSame(r, Pattern.compile(p).matcher(s).matches()); `expectThrows(PatternSyntaxException.class, ...)` might suit better for this and similar cases in this file. Not only does `expectThrows` test for expected exception, it also returns an exception which you can further inspect. Now, if we only had `assertThat` or similar functionality for compound assertions, the complete test might've looked nicely. ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From prappo at openjdk.java.net Fri Aug 20 17:01:28 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 20 Aug 2021 17:01:28 GMT Subject: RFR: 8271302: Regex Test Refresh [v3] In-Reply-To: References: Message-ID: <_DOJNVzi4RCF1GO1UwUDLFvInQTX0YzybumZLX24oss=.c35fd18b-df03-4184-b071-c3ae5624112b@github.com> On Fri, 20 Aug 2021 16:49:15 GMT, Pavel Rappo wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> some quick fixes > > test/jdk/java/util/regex/RegExTest.java line 4270: > >> 4268: String s = (String)pm[1]; >> 4269: boolean r = (Boolean)pm[2]; >> 4270: assertSame(r, Pattern.compile(p).matcher(s).matches()); > > `expectThrows(PatternSyntaxException.class, ...)` might suit better for this and similar cases in this file. Not only does `expectThrows` test for expected exception, it also returns an exception which you can further inspect. Now, if we only had `assertThat` or similar functionality for compound assertions, the complete test might've looked nicely. The latter comment referred to hand-rolled try-fail constructs like this: https://github.com/openjdk/jdk/blob/3937bf8f9921395d6fcbdc2bb00a4a98dc2aaf62/test/jdk/java/util/regex/RegExTest.java#L4281-L4289 Not sure why my IDE plugin messed up the comment position. ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From igraves at openjdk.java.net Fri Aug 20 21:17:50 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Fri, 20 Aug 2021 21:17:50 GMT Subject: RFR: 8271302: Regex Test Refresh [v4] In-Reply-To: References: Message-ID: > 8271302: Regex Test Refresh Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Additional cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5092/files - new: https://git.openjdk.java.net/jdk/pull/5092/files/3937bf8f..3f01c172 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=02-03 Stats: 46 lines in 1 file changed: 1 ins; 27 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/5092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5092/head:pull/5092 PR: https://git.openjdk.java.net/jdk/pull/5092 From weijun at openjdk.java.net Fri Aug 20 22:52:43 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 20 Aug 2021 22:52:43 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow Message-ID: This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install one at runtime. ------------- Commit messages: - 8270380: Change the default value of the java.security.manager system property to disallow Changes: https://git.openjdk.java.net/jdk/pull/5204/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5204&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270380 Stats: 24 lines in 6 files changed: 3 ins; 8 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/5204.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5204/head:pull/5204 PR: https://git.openjdk.java.net/jdk/pull/5204 From lancea at openjdk.java.net Fri Aug 20 23:05:26 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 20 Aug 2021 23:05:26 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. > > The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install one at runtime. Looks good Max. One minor suggestion below src/java.base/share/classes/java/lang/SecurityManager.java line 128: > 126: * null > 127: * None > 128: * Always throws {@code UnsupportedOperationException} Not sure "Always" is needed, could just be "Throws UOE" ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5204 From weijun at openjdk.java.net Sat Aug 21 11:26:26 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 21 Aug 2021 11:26:26 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 23:01:27 GMT, Lance Andersen wrote: >> This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. >> >> The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install one at runtime. > > src/java.base/share/classes/java/lang/SecurityManager.java line 128: > >> 126: * null >> 127: * None >> 128: * Always throws {@code UnsupportedOperationException} > > Not sure "Always" is needed, could just be "Throws UOE" This is the same as the existing words for "disallow". ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From Alan.Bateman at oracle.com Sat Aug 21 16:48:51 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 21 Aug 2021 17:48:51 +0100 Subject: Process for adding default method to javax.naming.Context? In-Reply-To: References: <4f438149-b1a1-fa9e-fa18-dc8bbaf60c63@oracle.com> Message-ID: <196693f5-7bb8-8471-fe45-1ea49d8bfdec@oracle.com> On 20/08/2021 17:03, Laird Nelson wrote: > On Fri, Aug 20, 2021 at 3:13 AM Alan Bateman > wrote: > > I think you are asking for an overload that specifies a class > literal as > a type token to avoid an explicit cast at the use-sites. > > > Yes, that's right. > > Is this to > improve usages within Helidon or are there enterprise libs that > expose > JNDI Context objects that would be used by a wider set of users? > > > Nothing so concrete. I've worked with Java-now-Jakarta EE for many > years and periodically like many like-minded users get frustrated with > the amount of explicit casting required when looking something up from > a Context. > > Also anecdotally: when you bring up JNDI in conversation, you get > responses along the lines of "but it's so old and clunky", and when > you push a little bit to find out what people are really objecting to, > the "old" and "clunky" bits turn out to be related to various methods > returning Object. (Well, that and Hashtable, but that's obviously not > repairable.)? Supposedly "modern" lookup-oriented APIs in other > libraries (offhand thinking hazily of CDI, various configuration > libraries, etc.) often have a variant of the kind of enhancement I'm > proposing and are then suddenly perceived as more sleek and fleet of > foot than this one. This kind of overload enhancement just seemed like > a low-effort way to drastically improve the perceived relevance of > what is a pretty powerful API under the hood. JNDI dates from 1997 and came into the JDK in Java SE 1.3. There have been very few API changes since then. There hasn't been any significant interest (to my knowledge anyway) in re-investing and modernizing the API. No objection to adding an overload with a type token but it's only a very small improvement. I suspect it would take a much bigger effort to shake off the old/clunky perception. A starting point for most people using this API will be creating an InitialContext and adding a new constructor that takes a Map with the environment would at least avoid some of the usages of Hashtable. -Alan. From alanb at openjdk.java.net Sat Aug 21 17:02:26 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 21 Aug 2021 17:02:26 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow In-Reply-To: References: Message-ID: <0_yy8U0y2nqLiVw5a-xrkaAHG_Mvs2gcOiMbphOvUsc=.90ae5c00-f9c4-4955-add8-4ac07a0b8877@github.com> On Sat, 21 Aug 2021 11:23:54 GMT, Weijun Wang wrote: >> src/java.base/share/classes/java/lang/SecurityManager.java line 128: >> >>> 126: * null >>> 127: * None >>> 128: * Always throws {@code UnsupportedOperationException} >> >> Not sure "Always" is needed, could just be "Throws UOE" > > This is the same as the existing words for "disallow". I think I agree with Lance that "Throws UOE" would be clearer in this table. ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From mchung at openjdk.java.net Sat Aug 21 22:37:05 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Sat, 21 Aug 2021 22:37:05 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3] In-Reply-To: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: > This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. > > The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. > > The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Remove separate accessor for static vs instance method There is no effective difference when using MethodHandle::dropArgument for static method. Removing Static*Accessor and Instance*Accessor simplifies the implementation. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5027/files - new: https://git.openjdk.java.net/jdk/pull/5027/files/b73a6faf..cff856f9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=01-02 Stats: 809 lines in 15 files changed: 235 ins; 422 del; 152 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027 From mchung at openjdk.java.net Sat Aug 21 22:45:31 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Sat, 21 Aug 2021 22:45:31 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Sat, 21 Aug 2021 22:37:05 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Remove separate accessor for static vs instance method > > There is no effective difference when using MethodHandle::dropArgument for static method. Removing Static*Accessor and Instance*Accessor simplifies the implementation. [cff856f](https://github.com/openjdk/jdk/pull/5027/commits/cff856f9df89293cbc8f2f1e977148cd6ece4f85) removed the distinct classes to specialize for static vs instance methods simplify the `DirectMethodAccessorImpl` implementation and its subclasses. There is no effective difference for static method invocation to drop the first argument via MethodHandle::dropArgument or special case it in `StaticMethodAccessor::invoke`. The cold startup time increases 4ms from 92.73ms to 96.80ms when MethodHandle::dropArgument is used. Current implementation Benchmark Mode Cnt Score Error Units ReflectionMethods.instance_method avgt 10 14.902 ? 0.031 ns/op ReflectionMethods.instance_method_3arg avgt 10 18.099 ? 0.632 ns/op ReflectionMethods.instance_method_var avgt 10 14.670 ? 0.044 ns/op ReflectionMethods.instance_method_var_3arg avgt 10 18.038 ? 0.109 ns/op ReflectionMethods.static_method avgt 10 20.140 ? 0.032 ns/op ReflectionMethods.static_method_3arg avgt 10 26.999 ? 0.046 ns/op ReflectionMethods.static_method_var avgt 10 22.272 ? 0.153 ns/op ReflectionMethods.static_method_var_3arg avgt 10 26.567 ? 0.088 ns/op No special casing for static vs instance methods Benchmark Mode Cnt Score Error Units ReflectionMethods.instance_method avgt 10 15.177 ? 0.032 ns/op ReflectionMethods.instance_method_3arg avgt 10 17.906 ? 0.050 ns/op ReflectionMethods.instance_method_var avgt 10 14.759 ? 0.083 ns/op ReflectionMethods.instance_method_var_3arg avgt 10 18.054 ? 0.197 ns/op ReflectionMethods.static_method avgt 10 13.599 ? 0.029 ns/op ReflectionMethods.static_method_3arg avgt 10 16.910 ? 0.099 ns/op ReflectionMethods.static_method_var avgt 10 13.993 ? 0.189 ns/op ReflectionMethods.static_method_var_3arg avgt 10 17.555 ? 0.068 ns/op $ perf stat -r 50 jep-build/linux-x86_64-server-release/images/jdk/bin/java -cp $MICRO_JAR org.openjdk.bench.java.lang.reflect.ReflectionColdstartBenchmark Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -cp build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.java.lang.reflect.ReflectionColdstartBenchmark' (50 runs): 138.361238 task-clock:u (msec) # 1.492 CPUs utilized ( +- 0.79% ) 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 4029 page-faults:u # 0.029 M/sec ( +- 0.12% ) 165249965 cycles:u # 1.194 GHz ( +- 0.85% ) 187374236 instructions:u # 1.13 insn per cycle ( +- 0.44% ) 35240188 branches:u # 254.697 M/sec ( +- 0.46% ) 1205192 branch-misses:u # 3.42% of all branches ( +- 1.15% ) 0.092733825 seconds time elapsed ( +- 1.02% ) $ perf stat -r 50 build/linux-x86_64-server-release/images/jdk/bin/java -cp $MICRO_JAR org.openjdk.bench.java.lang.reflect.ReflectionColdstartBenchmark Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -cp build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.java.lang.reflect.ReflectionColdstartBenchmark' (50 runs): 153.339577 task-clock:u (msec) # 1.584 CPUs utilized ( +- 0.83% ) 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 4129 page-faults:u # 0.027 M/sec ( +- 0.10% ) 187019454 cycles:u # 1.220 GHz ( +- 1.06% ) 203065287 instructions:u # 1.09 insn per cycle ( +- 0.34% ) 38350445 branches:u # 250.101 M/sec ( +- 0.36% ) 1385764 branch-misses:u # 3.61% of all branches ( +- 1.08% ) 0.096803078 seconds time elapsed ( +- 1.07% ) Note that static_method* are slower than instance_method* in the current implementation but seem to perform better after this patch. Claes looked into the current implementation via the disassembly and found that instance_method* get a more optimal code shape at the call-site but static_methods* do not. With this patch, we will need to look closer if instance_method* and static_method* benchmarks probbly get the optimal code shape at the call-site. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From weijun at openjdk.java.net Sat Aug 21 22:52:21 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 21 Aug 2021 22:52:21 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow In-Reply-To: <0_yy8U0y2nqLiVw5a-xrkaAHG_Mvs2gcOiMbphOvUsc=.90ae5c00-f9c4-4955-add8-4ac07a0b8877@github.com> References: <0_yy8U0y2nqLiVw5a-xrkaAHG_Mvs2gcOiMbphOvUsc=.90ae5c00-f9c4-4955-add8-4ac07a0b8877@github.com> Message-ID: On Sat, 21 Aug 2021 16:59:39 GMT, Alan Bateman wrote: >> This is the same as the existing words for "disallow". > > I think I agree with Lance that "Throws UOE" would be clearer in this table. Suggestion accepted. ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From mchung at openjdk.java.net Sat Aug 21 22:56:29 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Sat, 21 Aug 2021 22:56:29 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Sat, 21 Aug 2021 22:37:05 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Remove separate accessor for static vs instance method > > There is no effective difference when using MethodHandle::dropArgument for static method. Removing Static*Accessor and Instance*Accessor simplifies the implementation. Peter, I have a patch [1] that adds `-Djdk.reflect.useSpreader` and `-Djdk.reflect.useCatchExceptionCombinator` flags for doing performance comparison using `asSpreader` without specializing methods with <= 3 argument and using the `catchException` combinator. Note that [1] does not change the exception handling code as I keep it simple just for performance discussion. The main drive of the specialization and not using `catchException` is the cold startup regression. Note that we run `ReflectionColdstartBenchmark` without JMH. Running it with JMH may overly skew results. I increase the number running `ReflectionColdstartBenchmark` with JMH and without JMH below. The use of `asSpreader` increases the cold startup time by ~5ms, from 98ms to 103ms whereas the use of `catchException` increases the cold startup time by ~17ms, from 98ms to ~115ms. For the instance_method* and static_method* benchmarks, we need to look at the disassembly and understand where the performance differences come from. One idea we'd like to explore is to have a special decoding logic in the spreader that can wrap NPE and CCE with IAE for core reflection use. This will remove the need of decoding the exception's stacktrace and using the `catchException` combinator. Core reflection can use the spreader with a special decoding logic. I'd propose the current implementation as the initial integration for this JEP and explore the spreader special logic and other incremental performance improvement in the core method handle implementation like in spreader or `catchException` combinator after integration. What do you think? [1] http://cr.openjdk.java.net/~mchung/jep416/useSpreader-catchException-combinator.patch -Djdk.reflect.useSpreader=false -Djdk.reflect.useCatchExceptionCombinator=false ReflectionMethods.instance_method avgt 10 15.419 ? 0.026 ns/op ReflectionMethods.instance_method_3arg avgt 10 19.991 ? 0.087 ns/op ReflectionMethods.instance_method_var avgt 10 15.325 ? 0.048 ns/op ReflectionMethods.instance_method_var_3arg avgt 10 22.998 ? 0.093 ns/op ReflectionMethods.static_method avgt 10 13.927 ? 0.038 ns/op ReflectionMethods.static_method_3arg avgt 10 18.040 ? 0.081 ns/op ReflectionMethods.static_method_var avgt 10 14.165 ? 0.048 ns/op ReflectionMethods.static_method_var_3arg avgt 10 17.573 ? 0.160 ns/op ReflectionColdstartBenchmark.invokeMethods ss 10 2096.975 ? 90.331 us/op -Djdk.reflect.useSpreader=true -Djdk.reflect.useCatchExceptionCombinator=false ReflectionMethods.instance_method avgt 10 23.217 ? 0.058 ns/op ReflectionMethods.instance_method_3arg avgt 10 27.676 ? 0.223 ns/op ReflectionMethods.instance_method_var avgt 10 25.428 ? 0.038 ns/op ReflectionMethods.instance_method_var_3arg avgt 10 30.340 ? 0.079 ns/op ReflectionMethods.static_method avgt 10 21.705 ? 0.046 ns/op ReflectionMethods.static_method_3arg avgt 10 26.003 ? 0.039 ns/op ReflectionMethods.static_method_var avgt 10 24.916 ? 0.040 ns/op ReflectionMethods.static_method_var_3arg avgt 10 28.269 ? 0.067 ns/op ReflectionColdstartBenchmark.invokeMethods ss 10 3328.333 ? 882.301 us/op -Djdk.reflect.useSpreader=false -Djdk.reflect.useCatchExceptionCombinator=true ReflectionMethods.instance_method avgt 10 15.416 ? 0.043 ns/op ReflectionMethods.instance_method_3arg avgt 10 20.150 ? 0.161 ns/op ReflectionMethods.instance_method_var avgt 10 15.430 ? 0.094 ns/op ReflectionMethods.instance_method_var_3arg avgt 10 21.688 ? 0.105 ns/op ReflectionMethods.static_method avgt 10 13.894 ? 0.026 ns/op ReflectionMethods.static_method_3arg avgt 10 19.340 ? 0.054 ns/op ReflectionMethods.static_method_var avgt 10 14.250 ? 0.039 ns/op ReflectionMethods.static_method_var_3arg avgt 10 17.573 ? 0.130 ns/op ReflectionColdstartBenchmark.invokeMethods ss 10 3947.061 ? 171.567 us/op -Djdk.reflect.useSpreader=true -Djdk.reflect.useCatchExceptionCombinator=true ReflectionMethods.instance_method avgt 10 22.760 ? 0.049 ns/op ReflectionMethods.instance_method_3arg avgt 10 27.855 ? 0.143 ns/op ReflectionMethods.instance_method_var avgt 10 25.730 ? 0.106 ns/op ReflectionMethods.instance_method_var_3arg avgt 10 31.697 ? 5.826 ns/op ReflectionMethods.static_method avgt 10 21.682 ? 0.070 ns/op ReflectionMethods.static_method_3arg avgt 10 25.714 ? 0.151 ns/op ReflectionMethods.static_method_var avgt 10 24.397 ? 0.047 ns/op ReflectionMethods.static_method_var_3arg avgt 10 27.758 ? 0.154 ns/op ReflectionColdstartBenchmark.invokeMethods ss 10 5103.479 ? 2006.719 us/op Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Djdk.reflect.useSpreader=false -Djdk.refle ct.useCatchExceptionCombinator=false -cp build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.jav a.lang.reflect.ReflectionColdstartBenchmark' (50 runs): 156.098457 task-clock:u (msec) # 1.594 CPUs utilized ( +- 1.10% ) 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 4135 page-faults:u # 0.026 M/sec ( +- 0.12% ) 187098445 cycles:u # 1.199 GHz ( +- 1.26% ) 204415894 instructions:u # 1.09 insn per cycle ( +- 0.41% ) 38603060 branches:u # 247.299 M/sec ( +- 0.44% ) 1396828 branch-misses:u # 3.62% of all branches ( +- 1.21% ) 0.097899139 seconds time elapsed ( +- 1.31% ) Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Djdk.reflect.useSpreader=true -Djdk.reflec t.useCatchExceptionCombinator=false -cp build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.java .lang.reflect.ReflectionColdstartBenchmark' (50 runs): 172.039531 task-clock:u (msec) # 1.668 CPUs utilized ( +- 0.78% ) 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 4168 page-faults:u # 0.024 M/sec ( +- 0.09% ) 216832246 cycles:u # 1.260 GHz ( +- 0.82% ) 231306186 instructions:u # 1.07 insn per cycle ( +- 0.34% ) 43927129 branches:u # 255.332 M/sec ( +- 0.37% ) 1740904 branch-misses:u # 3.96% of all branches ( +- 0.74% ) 0.103161477 seconds time elapsed ( +- 0.86% ) Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Djdk.reflect.useSpreader=false -Djdk.reflect.useCatchExceptionCombinator=true -cp build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.java.lang.reflect.ReflectionColdstartBenchmark' (50 runs): 197.458370 task-clock:u (msec) # 1.724 CPUs utilized ( +- 1.09% ) 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 4407 page-faults:u # 0.022 M/sec ( +- 0.10% ) 252564982 cycles:u # 1.279 GHz ( +- 1.07% ) 261908793 instructions:u # 1.04 insn per cycle ( +- 0.35% ) 50031099 branches:u # 253.375 M/sec ( +- 0.37% ) 2094636 branch-misses:u # 4.19% of all branches ( +- 1.09% ) 0.114564702 seconds time elapsed ( +- 1.07% ) Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Djdk.reflect.useSpreader=true -Djdk.reflect.useCatchExceptionCombinator=true -cp build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.java.lang.reflect.ReflectionColdstartBenchmark' (50 runs): 202.628008 task-clock:u (msec) # 1.738 CPUs utilized ( +- 0.99% ) 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 4402 page-faults:u # 0.022 M/sec ( +- 0.10% ) 258306496 cycles:u # 1.275 GHz ( +- 1.14% ) 267584861 instructions:u # 1.04 insn per cycle ( +- 0.38% ) 51154598 branches:u # 252.456 M/sec ( +- 0.40% ) 2174735 branch-misses:u # 4.25% of all branches ( +- 1.18% ) 0.116577823 seconds time elapsed ( +- 0.82% ) ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From redestad at openjdk.java.net Sat Aug 21 22:59:21 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Sat, 21 Aug 2021 22:59:21 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Sat, 21 Aug 2021 22:37:05 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Remove separate accessor for static vs instance method > > There is no effective difference when using MethodHandle::dropArgument for static method. Removing Static*Accessor and Instance*Accessor simplifies the implementation. Right, early on splitting instance and static accessor implementations looked like a win for at least the instance accessor on micros, but it seems much of this win gets eaten up in more complex benchmarks since the hot call-site in `Method.invoke` sees more implementations and will be penalized by becoming bi- or megamorphic. Merging the split implementations back and accepting the need for a `dropArguments` combinator in the static case appears to be the right choice for maintainability and peak performance. A bit more overhead setting up - especially when reflecting on static methods (which is all the cold start benchmark does) - but I think that's the right trade-off in this case. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From github.com+7806504+liach at openjdk.java.net Sun Aug 22 01:56:42 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Sun, 22 Aug 2021 01:56:42 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Sat, 21 Aug 2021 22:37:05 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Remove separate accessor for static vs instance method > > There is no effective difference when using MethodHandle::dropArgument for static method. Removing Static*Accessor and Instance*Accessor simplifies the implementation. src/java.base/share/classes/jdk/internal/reflect/DirectConstructorAccessorImpl.java line 46: > 44: // fast invoker > 45: var mhInvoker = newMethodHandleInvoker(ctor, target); > 46: return new DirectConstructorAccessorImpl(ctor, target); The created fast invoker should be passed to the ctor than discarded. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From ljnelson at gmail.com Sun Aug 22 02:38:09 2021 From: ljnelson at gmail.com (Laird Nelson) Date: Sat, 21 Aug 2021 19:38:09 -0700 Subject: Process for adding default method to javax.naming.Context? In-Reply-To: <196693f5-7bb8-8471-fe45-1ea49d8bfdec@oracle.com> References: <4f438149-b1a1-fa9e-fa18-dc8bbaf60c63@oracle.com> <196693f5-7bb8-8471-fe45-1ea49d8bfdec@oracle.com> Message-ID: On Sat, Aug 21, 2021 at 9:49 AM Alan Bateman wrote: > JNDI dates from 1997 and came into the JDK in Java SE 1.3. > Yes; I remember it well. :-) > There have been very few API changes since then. There hasn't been any > significant interest (to my knowledge anyway) in re-investing and > modernizing the API. No objection to adding an overload with a type token > but it's only a very small improvement. I suspect it would take a much > bigger effort to shake off the old/clunky perception. > OK; it was worth a shot! Best, Laird From serb at openjdk.java.net Sun Aug 22 06:28:18 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 22 Aug 2021 06:28:18 GMT Subject: RFR: 8272805: Avoid looking up standard charsets Message-ID: This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. See https://github.com/openjdk/jdk/pull/5063 and https://github.com/openjdk/jdk/pull/4951 In many places standard charsets are looked up via their names, for example: absolutePath.getBytes("UTF-8"); This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: absolutePath.getBytes(StandardCharsets.UTF_8); The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. This change includes: * demo/utils * jdk.xx packages * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. Also checked for "aliases" usage. Some performance discussion: https://github.com/openjdk/jdk/pull/5063 Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the "java.naming"(the change there is not straightforward, will do it later). Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. ------------- Commit messages: - Fix related imports - Merge branch 'master' into standard-encodings-in-non-public-modules - Cleanup UnsupportedEncodingException - Update PacketStream.java - Rollback TextTests, should be compatible with jdk1.4 - Rollback TextRenderTests, should be compatible with jdk1.4 - Cleanup the UnsupportedEncodingException - aliases for ISO_8859_1 - Update imageio - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/5210/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272805 Stats: 333 lines in 48 files changed: 91 ins; 123 del; 119 mod Patch: https://git.openjdk.java.net/jdk/pull/5210.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210 PR: https://git.openjdk.java.net/jdk/pull/5210 From weijun at openjdk.java.net Sun Aug 22 13:22:38 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 22 Aug 2021 13:22:38 GMT Subject: RFR: 8272805: Avoid looking up standard charsets In-Reply-To: References: Message-ID: <0eO4SD_N9lrP5k5bhEejUKXeMauRC8zuc_slUJSrc5c=.c886ae36-5039-450f-9293-5f9910ce432d@github.com> On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: > absolutePath.getBytes(StandardCharsets.UTF_8); > > The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. > > This change includes: > * demo/utils > * jdk.xx packages > * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. > > Some performance discussion: https://github.com/openjdk/jdk/pull/5063 > > Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later). > > Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. The security related change looks fine to me. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5210 From mchung at openjdk.java.net Sun Aug 22 22:02:31 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Sun, 22 Aug 2021 22:02:31 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Sun, 22 Aug 2021 01:53:40 GMT, liach wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove separate accessor for static vs instance method >> >> There is no effective difference when using MethodHandle::dropArgument for static method. Removing Static*Accessor and Instance*Accessor simplifies the implementation. > > src/java.base/share/classes/jdk/internal/reflect/DirectConstructorAccessorImpl.java line 46: > >> 44: // fast invoker >> 45: var mhInvoker = newMethodHandleInvoker(ctor, target); >> 46: return new DirectConstructorAccessorImpl(ctor, target); > > The created fast invoker should be passed to the ctor than discarded. Good catch. Will fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From naoto at openjdk.java.net Mon Aug 23 00:24:29 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 23 Aug 2021 00:24:29 GMT Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v2] In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 07:25:06 GMT, Masanori Yano wrote: >> Hi all, >> >> Could you please review the 8269373 bug fixes? >> >> These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder. > > Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: > > 8269373: use test opts for process arguments IMHO, this kind of test that sets the locale forcefully sometimes gives us false positives. I'd rather eliminate that possibility than run tests in different locales ------------- PR: https://git.openjdk.java.net/jdk/pull/4594 From liangchenblue at gmail.com Mon Aug 23 02:08:18 2021 From: liangchenblue at gmail.com (-) Date: Sun, 22 Aug 2021 21:08:18 -0500 Subject: Implementing MethodHandleProxies#asInterfaceInstance with hidden classes Message-ID: Currently, java.lang.invoke.MethodHandleProxies#asInterfaceInstance [1] is implemented with java.lang.reflect.Proxy. After looking at its public API, including Javadoc, it seems that MethodHandleProxies would benefit from a hidden class implementation without changing its public API definition (including Javadocs). Recently, there is JEP 416 [2] for reimplementing reflection based on method handles. This implementation utilizes hidden classes with method handles passed in classdata and retrieved to condy, which allows generic method handles (beyond regular constable ones) to be optimized in method calls. Similarly, for MethodHandleProxies, hidden classes allow the implementations to detach from classloaders and be freely recyclable; they can use class data to store the adapted method handles (which can significantly speed up invocations); and it can allow it to support implementing single-abstract-method abstract classes in the future (as discussed in its Javadoc) as well, with only minor tweaks. Does this sound feasible? I want to ensure it is a good idea before any implementation is attempted. If there is any issue with this vision, please don't hesitate to point it out. Feel free to comment, too! If this looks good, I hope an issue can be created for it. Best [1] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/invoke/MethodHandleProxies.html [2] https://openjdk.java.net/jeps/416 From brian.goetz at oracle.com Mon Aug 23 02:26:29 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 23 Aug 2021 02:26:29 +0000 Subject: Implementing MethodHandleProxies#asInterfaceInstance with hidden classes In-Reply-To: References: Message-ID: This was an early attempt at the functionality provided by LambdaMetafactory. It could probably be reimplemented on top of that, but probably could be deprecated in favor of LMF as well. Sent from my iPad > On Aug 22, 2021, at 10:08 PM, liangchenblue at gmail.com wrote: > > ?Currently, java.lang.invoke.MethodHandleProxies#asInterfaceInstance [1] is > implemented with java.lang.reflect.Proxy. After looking at its public API, > including Javadoc, it seems that MethodHandleProxies would benefit from a > hidden class implementation without changing its public API definition > (including Javadocs). > > Recently, there is JEP 416 [2] for reimplementing reflection based on > method handles. This implementation utilizes hidden classes with method > handles passed in classdata and retrieved to condy, which allows generic > method handles (beyond regular constable ones) to be optimized in method > calls. Similarly, for MethodHandleProxies, hidden classes allow the > implementations to detach from classloaders and be freely recyclable; they > can use class data to store the adapted method handles (which can > significantly speed up invocations); and it can allow it to support > implementing single-abstract-method abstract classes in the future (as > discussed in its Javadoc) as well, with only minor tweaks. > > Does this sound feasible? I want to ensure it is a good idea before any > implementation is attempted. If there is any issue with this vision, please > don't hesitate to point it out. Feel free to comment, too! If this looks > good, I hope an issue can be created for it. > > Best > > [1] > https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/invoke/MethodHandleProxies.html > [2] https://openjdk.java.net/jeps/416 From jpai at openjdk.java.net Mon Aug 23 03:25:28 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 23 Aug 2021 03:25:28 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. > > The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install a `SecurityManager` at runtime. A somewhat broader question - I looked at the javadocs of this latest update to `SecurityManager` in this PR. One thing I'm unclear about is, consider the case where the `java.security.manager` is _not_ set to anything at the command line. Then in some application code, let's say we have this: String oldVal = System.getProperty("java.security.manager"); try { System.setProperty("java.security.manager", "allow"); System.setSecurityManager(someSecurityManager); .... // do something } finally { System.setProperty("java.security.manager", oldVal); } Would this then allow the security manager to be used? In other words, can the value of `java.security.manager` be changed dynamically at runtime or is it restricted to be set only at launch time (via command line arugment `-Djava.security.manager`)? ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From jpai at openjdk.java.net Mon Aug 23 03:30:29 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 23 Aug 2021 03:30:29 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow In-Reply-To: References: Message-ID: <0OvyRWsLuVKx4zTj2PDVY25B63KcIUUmpSDaM6PrzWA=.e272b8c2-2eca-460c-8731-e58fd52c6d76@github.com> On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. > > The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install a `SecurityManager` at runtime. It looks to me that the failures reported in the GitHub jobs are genuine and related to this change. It looks like the `jtreg` framework itself is impacted by this change because it calls the `System.setSecurityManager(....)` while launching the tests. 2021-08-21T01:41:42.5731927Z stderr: 2021-08-21T01:41:42.5733295Z java.lang.UnsupportedOperationException: The Security Manager is deprecated and will be removed in a future release 2021-08-21T01:41:42.5734843Z at java.base/java.lang.System.setSecurityManager(System.java:409) 2021-08-21T01:41:42.5736946Z at com.sun.javatest.regtest.agent.RegressionSecurityManager.install(RegressionSecurityManager.java:56) 2021-08-21T01:41:42.5739224Z at com.sun.javatest.regtest.agent.AgentServer.(AgentServer.java:211) 2021-08-21T01:41:42.5740879Z at com.sun.javatest.regtest.agent.AgentServer.main(AgentServer.java:70) 2021-08-21T01:41:42.5741805Z 2021-08-21T01:41:42.5743348Z TEST RESULT: Error. Agent communication error: java.net.SocketException: Connection reset; check console log for any additional details 2021-08-21T01:41:42.5745030Z -------------------------------------------------- 2021-08-21T01:41:51.2539413Z Test results: passed: 5; error: 879 2021-08-21T01:41:59.0887042Z Report written to /home/runner/work/jdk/jdk/build/run-test-prebuilt/test-results/jtreg_test_jdk_tier1_part1/html/report.html 2021-08-21T01:41:59.0892404Z Results written to /home/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part1 2021-08-21T01:41:59.0895498Z Error: Some tests failed or other problems occurred. 2021-08-21T01:41:59.1235748Z Finished running test 'jtreg:test/jdk:tier1_part1' 2021-08-21T01:41:59.1237631Z Test report is stored in build/run-test-prebuilt/test-results/jtreg_test_jdk_tier1_part1 2021-08-21T01:41:59.1650100Z 2021-08-21T01:41:59.1667939Z ============================== 2021-08-21T01:41:59.1668727Z Test summary 2021-08-21T01:41:59.1669635Z ============================== 2021-08-21T01:41:59.1670187Z TEST TOTAL PASS FAIL ERROR 2021-08-21T01:41:59.1670795Z >> jtreg:test/jdk:tier1_part1 884 5 0 879 << ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From dholmes at openjdk.java.net Mon Aug 23 04:45:28 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 23 Aug 2021 04:45:28 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. > > The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install a `SecurityManager` at runtime. @wangweij there are many tests that can call setSecurityManager() and will presumably need to be fixed before this switch can be applied. And all testing will need to be updated to require jtreg 6.1 (which no longer uses the SM) once it is released. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From Alan.Bateman at oracle.com Mon Aug 23 05:47:57 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Aug 2021 06:47:57 +0100 Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow In-Reply-To: References: Message-ID: <666ba939-2422-21f7-3ce4-d8444169a755@oracle.com> On 23/08/2021 05:45, David Holmes wrote: > : > > @wangweij there are many tests that can call setSecurityManager() and will presumably need to be fixed before this switch can be applied. And all testing will need to be updated to require jtreg 6.1 (which no longer uses the SM) once it is released. > Most of the preparation work for the tests was done via JDK-8267184 in JDK 17. JDK-8270380 isn't going to be integrated until after the upgrade the jtreg 6.1 (which I think is one part of Jai's mail). -Alan. From liangchenblue at gmail.com Mon Aug 23 06:34:17 2021 From: liangchenblue at gmail.com (-) Date: Mon, 23 Aug 2021 01:34:17 -0500 Subject: Implementing MethodHandleProxies#asInterfaceInstance with hidden classes In-Reply-To: References: Message-ID: Thanks for the quick reply! The main drawback, API wise, with LMF is that it does not accept non-direct method handles [1], while the MHP is able accept any method handle, such as native ones from JEP 389 [2]. LMF also lacks the ability to restore a method handle from a wrapper instance. Using LMF also requires user discretion on which methods to implement, and the lookup's required privileges may change too. In general, MHP would be more runtime-oriented and transient compared to LMF. I am inclined toward a separate bytecode generation implementation for the improved MHP asInterfaceInstance, somewhat similar to what's in JEP 416's implementation [3]. The extra bridges for all compatible methods, accessors to backing method handle/interface, potential to expand to abstract classes, different hidden class modes would reduce the commonalities between the two implementations and make refactorings on LMF to support these MHP functionalities costly. [1] https://github.com/openjdk/jdk/blob/b690f29699180149d33b6a83de10697790587a87/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java#L141 [2] https://openjdk.java.net/jeps/389#The-C-linker [3] https://github.com/openjdk/jdk/blob/cff856f9df89293cbc8f2f1e977148cd6ece4f85/src/java.base/share/classes/jdk/internal/reflect/ClassByteBuilder.java On Sun, Aug 22, 2021 at 9:26 PM Brian Goetz wrote: > > This was an early attempt at the functionality provided by LambdaMetafactory. It could probably be reimplemented on top of that, but probably could be deprecated in favor of LMF as well. > > Sent from my iPad > > > On Aug 22, 2021, at 10:08 PM, liangchenblue at gmail.com wrote: > > > > ?Currently, java.lang.invoke.MethodHandleProxies#asInterfaceInstance [1] is > > implemented with java.lang.reflect.Proxy. After looking at its public API, > > including Javadoc, it seems that MethodHandleProxies would benefit from a > > hidden class implementation without changing its public API definition > > (including Javadocs). > > > > Recently, there is JEP 416 [2] for reimplementing reflection based on > > method handles. This implementation utilizes hidden classes with method > > handles passed in classdata and retrieved to condy, which allows generic > > method handles (beyond regular constable ones) to be optimized in method > > calls. Similarly, for MethodHandleProxies, hidden classes allow the > > implementations to detach from classloaders and be freely recyclable; they > > can use class data to store the adapted method handles (which can > > significantly speed up invocations); and it can allow it to support > > implementing single-abstract-method abstract classes in the future (as > > discussed in its Javadoc) as well, with only minor tweaks. > > > > Does this sound feasible? I want to ensure it is a good idea before any > > implementation is attempted. If there is any issue with this vision, please > > don't hesitate to point it out. Feel free to comment, too! If this looks > > good, I hope an issue can be created for it. > > > > Best > > > > [1] > > https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/invoke/MethodHandleProxies.html > > [2] https://openjdk.java.net/jeps/416 From dholmes at openjdk.java.net Mon Aug 23 10:27:33 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 23 Aug 2021 10:27:33 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow In-Reply-To: References: Message-ID: <678VQPtxK_Q0cs5xv_bWQi9zscVNvCXYXla8yT48I_w=.5ded3519-7792-413c-bf71-b03649628ccc@github.com> On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. > > The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install a `SecurityManager` at runtime. Thanks for the clarification @AlanBateman . @wangweij my apologies as I misunderstood the affect this change was going to have on the existing warnings - which is none. David ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From shade at openjdk.java.net Mon Aug 23 11:40:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Aug 2021 11:40:42 GMT Subject: RFR: 8272836: Optimize run time for java/lang/invoke/LFCaching tests Message-ID: See the RFE for discussion. Current PR improves the test time like this: $ make run-test TEST=java/lang/invoke/LFCaching/ # Before real 3m51.608s user 5m21.612s sys 0m5.391s # After real 1m13.606s user 2m26.827s sys 0m4.761s ------------- Commit messages: - 8272836: Optimize run time for java/lang/invoke/LFCaching tests Changes: https://git.openjdk.java.net/jdk/pull/5214/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5214&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272836 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5214.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5214/head:pull/5214 PR: https://git.openjdk.java.net/jdk/pull/5214 From weijun at openjdk.java.net Mon Aug 23 12:03:31 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 23 Aug 2021 12:03:31 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. > > The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install a `SecurityManager` at runtime. > > Please note that this code change requires jtreg to be upgraded to 6.1, where a security manager [will not be set](https://bugs.openjdk.java.net/browse/CODETOOLS-7902990). This issue (https://bugs.openjdk.java.net/browse/JDK-8270380) is blocked by jtreg 6.1 (https://bugs.openjdk.java.net/browse/CODETOOLS-7902990). Precisely, it should be blocked by a JDK bug that updates the jtreg required version to 6.1. I should have mentioned this in the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From weijun at openjdk.java.net Mon Aug 23 12:15:32 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 23 Aug 2021 12:15:32 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 03:22:18 GMT, Jaikiran Pai wrote: > Would this then allow the security manager to be used? In other words, can the value of `java.security.manager` be changed dynamically at runtime or is it restricted to be set only at launch time (via command line arugment `-Djava.security.manager`)? Whether to allow a SecurityManager to be installed later is determined at system initialization time, so there is no use to set it to "allow" inside a program. See https://github.com/openjdk/jdk/blob/3a690240336bda8582a15ca52f4dcb78be323dcd/src/java.base/share/classes/java/lang/System.java#L2191 The spec in `SecurityManager.java` uses the words "if the Java virtual machine **is started with** the java.security.manager system property..." to describe this. ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From redestad at openjdk.java.net Mon Aug 23 12:25:29 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 23 Aug 2021 12:25:29 GMT Subject: RFR: 8272836: Optimize run time for java/lang/invoke/LFCaching tests In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 11:33:35 GMT, Aleksey Shipilev wrote: > See the RFE for discussion. > > Current PR improves the test time like this: > > > $ make run-test TEST=java/lang/invoke/LFCaching/ > > # Before > real 3m51.608s > user 5m21.612s > sys 0m5.391s > > # After > real 1m13.606s > user 2m26.827s > sys 0m4.761s Looks reasonable. Maybe "Limit" rather than "Optimize"? ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5214 From jpai at openjdk.java.net Mon Aug 23 12:46:31 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 23 Aug 2021 12:46:31 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 12:09:42 GMT, Weijun Wang wrote: > > Would this then allow the security manager to be used? In other words, can the value of `java.security.manager` be changed dynamically at runtime or is it restricted to be set only at launch time (via command line arugment `-Djava.security.manager`)? > > Whether to allow a SecurityManager to be installed later is determined at system initialization time, so there is no use to set it to "allow" inside a program. See > > https://github.com/openjdk/jdk/blob/3a690240336bda8582a15ca52f4dcb78be323dcd/src/java.base/share/classes/java/lang/System.java#L2191 > > The spec in `SecurityManager.java` uses the words "if the Java virtual machine **is started with** the java.security.manager system property..." to describe this. Thank you for that clarification @wangweij. ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From mgronlun at openjdk.java.net Mon Aug 23 13:21:25 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 23 Aug 2021 13:21:25 GMT Subject: RFR: 8266936: Add a finalization JFR event [v7] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: lock ranking ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/d8b829e8..7d63693f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=05-06 Stats: 26 lines in 3 files changed: 6 ins; 11 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From herrick at openjdk.java.net Mon Aug 23 13:36:27 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Mon, 23 Aug 2021 13:36:27 GMT Subject: RFR: JDK-8272639: jpackaged applications using microphone on mac In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 22:46:18 GMT, Sergey Bylokhov wrote: >> JDK-8272639: jpackaged applications using microphone on mac > > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/Info-lite.plist.template line 37: > >> 35: true >> 36: NSMicrophoneUsageDescription >> 37: The application is requesting access to the microphone. > > Should not it include the "application name" here? This is different from the java tool, where we do not know that info in advance. Yes - I will revise with name substituted here. I also considered localizing this string, but we only support localization of the tool, which would put string in the local that jpackage was run in, not the local the generated artifact was run in. ------------- PR: https://git.openjdk.java.net/jdk/pull/5186 From shade at openjdk.java.net Mon Aug 23 13:37:29 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Aug 2021 13:37:29 GMT Subject: RFR: 8272836: Limit run time for java/lang/invoke/LFCaching tests In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 11:33:35 GMT, Aleksey Shipilev wrote: > See the RFE for discussion. > > Current PR improves the test time like this: > > > $ make run-test TEST=java/lang/invoke/LFCaching/ > > # Before > real 3m51.608s > user 5m21.612s > sys 0m5.391s > > # After > real 1m13.606s > user 2m26.827s > sys 0m4.761s Can be "Limit", sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/5214 From mgronlun at openjdk.java.net Mon Aug 23 14:13:22 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 23 Aug 2021 14:13:22 GMT Subject: RFR: 8266936: Add a finalization JFR event [v8] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: enqueued data point ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/7d63693f..5da3bb89 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=06-07 Stats: 62 lines in 5 files changed: 46 ins; 8 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From herrick at openjdk.java.net Mon Aug 23 14:34:52 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Mon, 23 Aug 2021 14:34:52 GMT Subject: RFR: JDK-8272639: jpackaged applications using microphone on mac [v2] In-Reply-To: References: Message-ID: > JDK-8272639: jpackaged applications using microphone on mac Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: JDK-8272639: jpackaged applications using microphone on mac ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5186/files - new: https://git.openjdk.java.net/jdk/pull/5186/files/e1f460e1..337e1fa1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5186&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5186&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5186.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5186/head:pull/5186 PR: https://git.openjdk.java.net/jdk/pull/5186 From naoto at openjdk.java.net Mon Aug 23 16:48:37 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 23 Aug 2021 16:48:37 GMT Subject: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong Message-ID: Please review the fix to the subject issue. When instant seconds and zone co-exist in parsed data, instant seconds was not resolved correctly from them. ------------- Commit messages: - 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong Changes: https://git.openjdk.java.net/jdk/pull/5225/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5225&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272473 Stats: 14 lines in 2 files changed: 8 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5225/head:pull/5225 PR: https://git.openjdk.java.net/jdk/pull/5225 From vromero at openjdk.java.net Mon Aug 23 18:22:42 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 23 Aug 2021 18:22:42 GMT Subject: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null Message-ID: Please review this simple PR along with the associated CSR. The PR is basically adding a line the the specification of method `java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a NPE will be thrown. TIA link to the [CSR](https://bugs.openjdk.java.net/browse/JDK-8272852) ------------- Commit messages: - 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null Changes: https://git.openjdk.java.net/jdk/pull/5226/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5226&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272347 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5226.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5226/head:pull/5226 PR: https://git.openjdk.java.net/jdk/pull/5226 From brian.goetz at oracle.com Mon Aug 23 20:04:31 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 23 Aug 2021 16:04:31 -0400 Subject: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null In-Reply-To: References: Message-ID: +1 On 8/23/2021 2:22 PM, Vicente Romero wrote: > Please review this simple PR along with the associated CSR. The PR is basically adding a line the the specification of method `java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a NPE will be thrown. > > TIA > > link to the [CSR](https://bugs.openjdk.java.net/browse/JDK-8272852) > > ------------- > > Commit messages: > - 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null > > Changes: https://git.openjdk.java.net/jdk/pull/5226/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5226&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8272347 > Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod > Patch: https://git.openjdk.java.net/jdk/pull/5226.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/5226/head:pull/5226 > > PR: https://git.openjdk.java.net/jdk/pull/5226 From brian.goetz at oracle.com Mon Aug 23 20:07:27 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 23 Aug 2021 16:07:27 -0400 Subject: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null In-Reply-To: References: Message-ID: <163ae5cd-86ea-48bb-496a-208ef71aaf21@oracle.com> Actually, it will not NPE if `names` is null and you have selected equals/hashCode as the name.? Might be better to do requiresNonNull() up front for all the arguments, just to make such analysis simpler: requireNonNull(methodName); requireNonNull(type); requireNonNull(recordClass); requireNonNull(names); ??? requireNonNull(getters); On 8/23/2021 4:04 PM, Brian Goetz wrote: > +1 > > On 8/23/2021 2:22 PM, Vicente Romero wrote: >> Please review this simple PR along with the associated CSR. The PR is >> basically adding a line the the specification of method >> `java.lang.runtime.ObjectMethods::bootstrap` stating under what >> conditions a NPE will be thrown. >> >> TIA >> >> link to the [CSR](https://bugs.openjdk.java.net/browse/JDK-8272852) >> >> ------------- >> >> Commit messages: >> ? - 8272347: ObjectMethods::bootstrap should specify NPE if any >> argument except lookup is null >> >> Changes: https://git.openjdk.java.net/jdk/pull/5226/files >> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5226&range=00 >> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8272347 >> ?? Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod >> ?? Patch: https://git.openjdk.java.net/jdk/pull/5226.diff >> ?? Fetch: git fetch https://git.openjdk.java.net/jdk >> pull/5226/head:pull/5226 >> >> PR: https://git.openjdk.java.net/jdk/pull/5226 > From serb at openjdk.java.net Mon Aug 23 20:53:30 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 23 Aug 2021 20:53:30 GMT Subject: RFR: JDK-8272639: jpackaged applications using microphone on mac [v2] In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 14:34:52 GMT, Andy Herrick wrote: >> JDK-8272639: jpackaged applications using microphone on mac > > Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8272639: jpackaged applications using microphone on mac Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5186 From paul.sandoz at oracle.com Mon Aug 23 20:55:11 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 23 Aug 2021 20:55:11 +0000 Subject: [(Much) faster java.util.LinkedList] In-Reply-To: References: Message-ID: Hi, Thanks for sharing. I browsed through the code (not a review) and gave it a test drive, generally it looks of good quality. Over time, since LinkedList was added, there are less reasons to use it, thereby making such improvements you propose less impactful. CPU caches have got much better, so traversal of ArrayList is really good, whereas traversal of LinkedList is not cache efficient and nor is it easily amenable to runtime compiler optimizations like auto-vectorization. ArrayDeque (almost if not as good as ArrayList) was added that supports efficient first/last addition. I would argue that ArrayList or ArrayDeque are better choices in the majority of cases. In other cases where insertion is more generally required and there is a relation between elements a TreeSet or PriorityQueue may be a better choice. So while I think you have done a good job implementing an enhanced LinkedList implementation I am not convinced it's worth adding to the JDK. There are other areas we could enhance that might have more impact. For example, can we improve how ArrayList and ArrayDeque grow in size? When we added the Java Stream API we added an internal data structure SpinedBuffer, which behaves like an append-only array list with better growth characteristics, using an array of arrays (the spine). Maybe such a technique is more broadly applicable to ArrayList and perhaps ArrayDeque? Paul. > On Aug 18, 2021, at 8:30 PM, Rodion Efremov wrote: > > Hello, > > I have implemented a heuristic, indexed doubly-linked list data structure > [1][2] implementing java.util.List and java.util.Deque interfaces that has > superior performance compared to java.util.LinkedList and > java.util.ArrayList. > > I would like to propose it into the upcoming versions of OpenJDK, but, > first, I need to know what do you think about it? > > Best regards, > rodde > > [1] https://github.com/coderodde/LinkedList > [2] http://coderodde.github.io/weblog/#eill From github.com+78814694+tatwaichong at openjdk.java.net Mon Aug 23 21:48:01 2021 From: github.com+78814694+tatwaichong at openjdk.java.net (TatWai Chong) Date: Mon, 23 Aug 2021 21:48:01 GMT Subject: RFR: 8269559: AArch64: Implement string_compare intrinsic in SVE [v2] In-Reply-To: References: Message-ID: > This patch implements string_compare intrinsic in SVE. > It supports all LL, LU, UL and UU comparisons. > > As we haven't found an existing benchmark to measure performance impact, > we created a benchmark derived from the test [1] for this evaluation. > This benchmark is attached to this patch. > > Besides, remove the unused temporary register `vtmp3` from the existing > match rules for StrCmp. > > The result below shows all varients can be benefited largely. > Command: make exploded-test TEST="micro:StringCompareToDifferentLength" > > Benchmark (size) Mode Cnt Score Speedup Units > compareToLL 24 avgt 10 1.0x ms/op > compareToLL 36 avgt 10 1.0x ms/op > compareToLL 72 avgt 10 1.0x ms/op > compareToLL 128 avgt 10 1.4x ms/op > compareToLL 256 avgt 10 1.8x ms/op > compareToLL 512 avgt 10 2.7x ms/op > compareToLU 24 avgt 10 1.6x ms/op > compareToLU 36 avgt 10 1.8x ms/op > compareToLU 72 avgt 10 2.3x ms/op > compareToLU 128 avgt 10 3.8x ms/op > compareToLU 256 avgt 10 4.7x ms/op > compareToLU 512 avgt 10 6.3x ms/op > compareToUL 24 avgt 10 1.6x ms/op > compareToUL 36 avgt 10 1.7x ms/op > compareToUL 72 avgt 10 2.2x ms/op > compareToUL 128 avgt 10 3.3x ms/op > compareToUL 256 avgt 10 4.4x ms/op > compareToUL 512 avgt 10 6.1x ms/op > compareToUU 24 avgt 10 1.0x ms/op > compareToUU 36 avgt 10 1.0x ms/op > compareToUU 72 avgt 10 1.4x ms/op > compareToUU 128 avgt 10 2.2x ms/op > compareToUU 256 avgt 10 2.6x ms/op > compareToUU 512 avgt 10 3.7x ms/op > > [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToDifferentLength.java TatWai Chong has updated the pull request incrementally with one additional commit since the last revision: Restore the removal of vtmp3 (=V2) as it is still used by the non-SVE compare-long-strings stub. And remove the assertion in `string_compare` since it won't help as the registers used in the stub are fixed. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5129/files - new: https://git.openjdk.java.net/jdk/pull/5129/files/bae862e1..2ae102d0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5129&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5129&range=00-01 Stats: 31 lines in 6 files changed: 6 ins; 2 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/5129.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5129/head:pull/5129 PR: https://git.openjdk.java.net/jdk/pull/5129 From github.com+78814694+tatwaichong at openjdk.java.net Mon Aug 23 21:48:06 2021 From: github.com+78814694+tatwaichong at openjdk.java.net (TatWai Chong) Date: Mon, 23 Aug 2021 21:48:06 GMT Subject: RFR: 8269559: AArch64: Implement string_compare intrinsic in SVE [v2] In-Reply-To: <_lSp-23GertACKXqh3cAP2hFlevG6Qhg-PmPswR5ctw=.f0b13664-3fce-42f3-9420-1d24d19d15ca@github.com> References: <_lSp-23GertACKXqh3cAP2hFlevG6Qhg-PmPswR5ctw=.f0b13664-3fce-42f3-9420-1d24d19d15ca@github.com> Message-ID: On Tue, 17 Aug 2021 07:14:24 GMT, Nick Gasson wrote: >> TatWai Chong has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore the removal of vtmp3 (=V2) as it is still used by the non-SVE compare-long-strings stub. >> >> And remove the assertion in `string_compare` since it won't help as the registers >> used in the stub are fixed. > > src/hotspot/cpu/aarch64/aarch64.ad line 16515: > >> 16513: instruct string_compareUL(iRegP_R1 str1, iRegI_R2 cnt1, iRegP_R3 str2, iRegI_R4 cnt2, >> 16514: iRegI_R0 result, iRegP_R10 tmp1, iRegL_R11 tmp2, >> 16515: vRegD_V0 vtmp1, vRegD_V1 vtmp2, vRegD_V2 vtmp3, rFlagsReg cr) > > I think vtmp3 (=V2) is still used by the non-SVE compare-long-strings stub? (see `generate_compare_long_string_different_encoding`) Thanks, Nick. Yes. I remove this vtmp3 from input arguments wrongly. I roll back this mistake in the following patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/5129 From mchung at openjdk.java.net Mon Aug 23 23:18:38 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 23 Aug 2021 23:18:38 GMT Subject: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 18:08:02 GMT, Vicente Romero wrote: > Please review this simple PR along with the associated CSR. The PR is basically adding a line the the specification of method `java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a NPE will be thrown. > > TIA > > link to the [CSR](https://bugs.openjdk.java.net/browse/JDK-8272852) Does the existing `ObjectMethodsTest` test verify all NPE cases? src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 327: > 325: * @throws IllegalArgumentException if the bootstrap arguments are invalid > 326: * or inconsistent > 327: * @throws NullPointerException if any argument but {@code lookup} is {@code null} `names` may be null if the {@code methodName} is {@code "equals"} or {@code "hashCode"}. This should be captured here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5226 From sviswanathan at openjdk.java.net Mon Aug 23 23:58:46 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Mon, 23 Aug 2021 23:58:46 GMT Subject: RFR: 8272861: Add a micro benchmark for vector api Message-ID: This pull request adds a micro benchmark for Vector API. The Black Scholes algorithm is implemented with and without Vector API. We see about ~6x gain with Vector API for this micro benchmark using 256 bit vectors. ------------- Commit messages: - whitespace - 8272861: Add a micro benchmark for vector api Changes: https://git.openjdk.java.net/jdk/pull/5234/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5234&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272861 Stats: 190 lines in 1 file changed: 190 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5234.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5234/head:pull/5234 PR: https://git.openjdk.java.net/jdk/pull/5234 From vicente.romero at oracle.com Tue Aug 24 01:51:25 2021 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 23 Aug 2021 21:51:25 -0400 Subject: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null In-Reply-To: <163ae5cd-86ea-48bb-496a-208ef71aaf21@oracle.com> References: <163ae5cd-86ea-48bb-496a-208ef71aaf21@oracle.com> Message-ID: On 8/23/21 4:07 PM, Brian Goetz wrote: > Actually, it will not NPE if `names` is null and you have selected > equals/hashCode as the name.? Might be better to do requiresNonNull() > up front for all the arguments, just to make such analysis simpler: > > requireNonNull(methodName); > requireNonNull(type); > requireNonNull(recordClass); > requireNonNull(names); > requireNonNull(getters); will do, thanks, Vicente > > On 8/23/2021 4:04 PM, Brian Goetz wrote: >> +1 >> >> On 8/23/2021 2:22 PM, Vicente Romero wrote: >>> Please review this simple PR along with the associated CSR. The PR >>> is basically adding a line the the specification of method >>> `java.lang.runtime.ObjectMethods::bootstrap` stating under what >>> conditions a NPE will be thrown. >>> >>> TIA >>> >>> link to the [CSR](https://bugs.openjdk.java.net/browse/JDK-8272852) >>> >>> ------------- >>> >>> Commit messages: >>> ? - 8272347: ObjectMethods::bootstrap should specify NPE if any >>> argument except lookup is null >>> >>> Changes: https://git.openjdk.java.net/jdk/pull/5226/files >>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5226&range=00 >>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8272347 >>> ?? Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod >>> ?? Patch: https://git.openjdk.java.net/jdk/pull/5226.diff >>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk >>> pull/5226/head:pull/5226 >>> >>> PR: https://git.openjdk.java.net/jdk/pull/5226 >> > From ccheung at openjdk.java.net Tue Aug 24 02:12:30 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 24 Aug 2021 02:12:30 GMT Subject: RFR: 8264322: Generate CDS archive when creating custom JDK image [v2] In-Reply-To: <7-Cono7O5baO1NjJNuZe1ol7E-57gh246Fi8ycvq14M=.4c4d4cd6-0cae-4a75-92dd-1be9b5b997a9@github.com> References: <5C8ZW4JoQhyPGpurPzRQB_HcM3qbKeB3GVtz5Rfh-FY=.7657aee8-3e3c-452e-b080-9cd9edacd2d5@github.com> <1r_8lzqM5SlOweerNiJsnNeh6j-xFs8KpAuhGTTGpKE=.1005a3b2-4697-46f5-a0aa-e438656e5b7c@github.com> <7-Cono7O5baO1NjJNuZe1ol7E-57gh246Fi8ycvq14M=.4c4d4cd6-0cae-4a75-92dd-1be9b5b997a9@github.com> Message-ID: On Fri, 20 Aug 2021 02:04:52 GMT, Mandy Chung wrote: >> I'd prefer to leave it as is for now since it's in a test case and I don't think the code is complex. > > This is fragile by setting `os.name`. I've filed [JDK-8272868](https://bugs.openjdk.java.net/browse/JDK-8272868) to follow-up the above issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/5174 From mchung at openjdk.java.net Tue Aug 24 02:19:27 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 24 Aug 2021 02:19:27 GMT Subject: RFR: 8264322: Generate CDS archive when creating custom JDK image [v2] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 00:09:01 GMT, Calvin Cheung wrote: >> Please review this change for adding a `jlink` command line option `--generate-cds-archive` for generating CDS archives as a post processing step during the creation of a custom JDK image. >> >> Details can be found in the corresponding CSR [JDK-8269178](https://bugs.openjdk.java.net/browse/JDK-8269178). >> >> Testing: >> >> - [x] tiers 1,2 (including the new test) > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @mlchung comments Thanks for creating a JBS issue. I'm okay to follow up the test improvement as a separate issue. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5174 From wuyan at openjdk.java.net Tue Aug 24 02:48:26 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Tue, 24 Aug 2021 02:48:26 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v4] In-Reply-To: References: Message-ID: On Wed, 28 Jul 2021 08:51:38 GMT, Andrew Haley wrote: >> I don't think we want to keep two copies of the compareTo intrinsic. If there are no cases where the LDP version is worse than the original version then we should just delete the old one and replace it with this. > >> I don't think we want to keep two copies of the compareTo intrinsic. If there are no cases where the LDP version is worse than the original version then we should just delete the old one and replace it with this. > > I agree. The trouble is, what does "worse" mean? I'm looking at SDEN-1982442, Neoverse N2 errata, 2001293, and I see that LDP has to be slowed down on streaming workloads, which will affect this. (That's just an example: I'm making the point that implementations differ.) > > The trouble with this patch is that it (probably) makes things better for long strings, which are very rare. What we actually need to care about is performance for a large number of typical-sized strings, which are names, identifiers, passwords, and so on: about 10-30 characters. Hi, @theRealAph @nick-arm, The test data looks OK on Raspberry Pi 4B and Hisilicon, do you have any other questions about this patch? ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From vromero at openjdk.java.net Tue Aug 24 03:03:48 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 24 Aug 2021 03:03:48 GMT Subject: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v2] In-Reply-To: References: Message-ID: > Please review this simple PR along with the associated CSR. The PR is basically adding a line the the specification of method `java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a NPE will be thrown. > > TIA > > link to the [CSR](https://bugs.openjdk.java.net/browse/JDK-8272852) Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5226/files - new: https://git.openjdk.java.net/jdk/pull/5226/files/b7489b41..89086ca1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5226&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5226&range=00-01 Stats: 30 lines in 2 files changed: 17 ins; 1 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/5226.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5226/head:pull/5226 PR: https://git.openjdk.java.net/jdk/pull/5226 From vromero at openjdk.java.net Tue Aug 24 03:06:30 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 24 Aug 2021 03:06:30 GMT Subject: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v2] In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 23:13:58 GMT, Mandy Chung wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> addressing review comments > > src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 327: > >> 325: * @throws IllegalArgumentException if the bootstrap arguments are invalid >> 326: * or inconsistent >> 327: * @throws NullPointerException if any argument but {@code lookup} is {@code null} > > `names` may be null if the {@code methodName} is {@code "equals"} or {@code "hashCode"}. This should be captured here. Hi Mandy, I have changed the implementation of the method to explicitly require all arguments but lookup to be non-null as suggested by Brian. I have also covered, I think, all the missing test cases in test `ObjectMethodsTest`, thanks for your comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/5226 From njian at openjdk.java.net Tue Aug 24 03:40:28 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 24 Aug 2021 03:40:28 GMT Subject: RFR: 8272861: Add a micro benchmark for vector api In-Reply-To: References: Message-ID: <3OMbjYMvzchwNvvPOXHD5JX1QOwU3n6XdwLpEEZ5apk=.a48f9261-6b41-45f6-9122-35f1cc988a46@github.com> On Mon, 23 Aug 2021 23:18:28 GMT, Sandhya Viswanathan wrote: > This pull request adds a micro benchmark for Vector API. > The Black Scholes algorithm is implemented with and without Vector API. > We see about ~6x gain with Vector API for this micro benchmark using 256 bit vectors. test/micro/org/openjdk/bench/jdk/incubator/vector/BlackScholes.java line 138: > 136: } > 137: > 138: static final VectorSpecies fsp = FloatVector.SPECIES_256; Can we use a more portable way instead of fixed size SPECIES_256? ------------- PR: https://git.openjdk.java.net/jdk/pull/5234 From ngasson at openjdk.java.net Tue Aug 24 04:21:31 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Tue, 24 Aug 2021 04:21:31 GMT Subject: RFR: 8269559: AArch64: Implement string_compare intrinsic in SVE [v2] In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:48:01 GMT, TatWai Chong wrote: >> This patch implements string_compare intrinsic in SVE. >> It supports all LL, LU, UL and UU comparisons. >> >> As we haven't found an existing benchmark to measure performance impact, >> we created a benchmark derived from the test [1] for this evaluation. >> This benchmark is attached to this patch. >> >> Besides, remove the unused temporary register `vtmp3` from the existing >> match rules for StrCmp. >> >> The result below shows all varients can be benefited largely. >> Command: make exploded-test TEST="micro:StringCompareToDifferentLength" >> >> Benchmark (size) Mode Cnt Score Speedup Units >> compareToLL 24 avgt 10 1.0x ms/op >> compareToLL 36 avgt 10 1.0x ms/op >> compareToLL 72 avgt 10 1.0x ms/op >> compareToLL 128 avgt 10 1.4x ms/op >> compareToLL 256 avgt 10 1.8x ms/op >> compareToLL 512 avgt 10 2.7x ms/op >> compareToLU 24 avgt 10 1.6x ms/op >> compareToLU 36 avgt 10 1.8x ms/op >> compareToLU 72 avgt 10 2.3x ms/op >> compareToLU 128 avgt 10 3.8x ms/op >> compareToLU 256 avgt 10 4.7x ms/op >> compareToLU 512 avgt 10 6.3x ms/op >> compareToUL 24 avgt 10 1.6x ms/op >> compareToUL 36 avgt 10 1.7x ms/op >> compareToUL 72 avgt 10 2.2x ms/op >> compareToUL 128 avgt 10 3.3x ms/op >> compareToUL 256 avgt 10 4.4x ms/op >> compareToUL 512 avgt 10 6.1x ms/op >> compareToUU 24 avgt 10 1.0x ms/op >> compareToUU 36 avgt 10 1.0x ms/op >> compareToUU 72 avgt 10 1.4x ms/op >> compareToUU 128 avgt 10 2.2x ms/op >> compareToUU 256 avgt 10 2.6x ms/op >> compareToUU 512 avgt 10 3.7x ms/op >> >> [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToDifferentLength.java > > TatWai Chong has updated the pull request incrementally with one additional commit since the last revision: > > Restore the removal of vtmp3 (=V2) as it is still used by the non-SVE compare-long-strings stub. > > And remove the assertion in `string_compare` since it won't help as the registers > used in the stub are fixed. This looks ok to me now but please wait to see if @theRealAph has any comments. I suppose the the short-string comparison code which is expanded at the call site could also benefit from SVE, if only to make it shorter. ------------- Marked as reviewed by ngasson (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5129 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 24 06:22:38 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 24 Aug 2021 06:22:38 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules Message-ID: Collections.sort is just a wrapper, so it is better to use an instance method directly. ------------- Commit messages: - [PATCH] Replace usages of Collections.sort with List.sort call in public java modules Changes: https://git.openjdk.java.net/jdk/pull/5229/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5229&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272863 Stats: 27 lines in 10 files changed: 0 ins; 8 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/5229.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5229/head:pull/5229 PR: https://git.openjdk.java.net/jdk/pull/5229 From serb at openjdk.java.net Tue Aug 24 06:22:38 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 Aug 2021 06:22:38 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. The changes in the src/java.desktop/ looks fine. Filed: https://bugs.openjdk.java.net/browse/JDK-8272863 ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5229 From turbanoff at gmail.com Tue Aug 24 06:50:15 2021 From: turbanoff at gmail.com (Andrey Turbanov) Date: Tue, 24 Aug 2021 09:50:15 +0300 Subject: Dangling class-level javadoc comments in JDK Message-ID: Hello. I found a few internal classes in the JDK codebase which don't have proper javadoc, but have dangling javadoc-like comments. Dangling Javadoc comments are ignored by the javadoc tool and IDE. Perhaps it was intentional to not add proper javadoc to them? I believe it's better to convert them to proper javadoc to make developing JDK a bit more friendly within IDE. What do you think? List of classes: com.sun.beans.editors.BooleanEditor com.sun.beans.editors.ByteEditor com.sun.beans.editors.DoubleEditor com.sun.beans.editors.FloatEditor com.sun.beans.editors.IntegerEditor com.sun.beans.editors.LongEditor com.sun.beans.editors.NumberEditor com.sun.beans.editors.ShortEditor com.sun.jndi.toolkit.dir.ContainmentFilter com.sun.jndi.toolkit.dir.LazySearchEnumerationImpl com.sun.security.auth.module.Crypt java.math.MutableBigInteger java.net.DefaultInterface javax.swing.GraphicsWrapper jdk.internal.access.JavaAWTFontAccess jdk.javadoc.internal.doclets.toolkit.CommentUtils sun.awt.X11.XAtom sun.awt.X11.XAwtState sun.java2d.xr.XRBackend sun.java2d.xr.XRDrawLine sun.jvm.hotspot.debugger.PageCache sun.jvm.hotspot.runtime.JavaThreadFactory sun.jvm.hotspot.utilities.Interval sun.jvm.hotspot.utilities.MessageQueueBackend sun.jvm.hotspot.utilities.RBTree sun.launcher.LauncherHelper sun.net.www.content.text.plain sun.net.www.protocol.file.FileURLConnection sun.nio.ch.Interruptible sun.security.pkcs.ParsingException sun.security.provider.SeedGenerator sun.security.util.ByteArrayTagOrder sun.security.util.IOUtils Andrey Turbanov From filteredaccount1 at gmail.com Tue Aug 24 10:08:33 2021 From: filteredaccount1 at gmail.com (Filteredaccount1) Date: Tue, 24 Aug 2021 20:08:33 +1000 Subject: JPackage and ask for microphone permissions broken on OSX... Message-ID: <15D1DFF8-0D3D-4DBF-9607-C63010FB7F23@gmail.com> ?Hi Andy, During the wait for JDK 18, would it be possible to describe on the bug ticket what manual workaround steps are required to apply to an existing jPackaged app for distribution both inside and outside the app store? There are two info.plist files inside a jPackaged app. In my experience adding keys to both didn?t turn the ask microphone permissions on. com.apple.security.device.audio-input NSMicrophoneUsageDescription The application is requesting access to the microphone. Also, I raised at http://bugreport.java.com/ 9071230. So developer time isn?t wasted, could this be cancelled? (seems setup so the general public cannot). Thank You, Ben S. > Date: Wed, 18 Aug 2021 08:43:08 -0400 > From: Andy Herrick > To: core-libs-dev at openjdk.java.net > Subject: Re: JPackage and ask for microphone permissions broken on > OSX... > Message-ID: <1534b02b-262a-f338-aae5-d1693d0072b3 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > OK - I have reproduced this problem, filed an issue, and found the fix. > > You can see the issue in https://bugs.openjdk.java.net/browse/JDK-8272639. > > Basically another key is needed in application plist to cause > application to ask for microphone access. > > It is far to late to get any fix into JDK17, but I will fix in JDK18 and > you can work around this issue in JDK17 (or JDK16) by using the > --resource-dir option: From shade at openjdk.java.net Tue Aug 24 10:12:31 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 24 Aug 2021 10:12:31 GMT Subject: RFR: 8272861: Add a micro benchmark for vector api In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 23:18:28 GMT, Sandhya Viswanathan wrote: > This pull request adds a micro benchmark for Vector API. > The Black Scholes algorithm is implemented with and without Vector API. > We see about ~6x gain with Vector API for this micro benchmark using 256 bit vectors. Some benchmark comments. test/micro/org/openjdk/bench/jdk/incubator/vector/BlackScholes.java line 91: > 89: static float A4 = -1.821255978f; > 90: static float A5 = 1.330274429f; > 91: static float PI = (float)Math.PI; Want to make these `static final`? test/micro/org/openjdk/bench/jdk/incubator/vector/BlackScholes.java line 134: > 132: > 133: @Benchmark > 134: public void scalar_black_scholes(Blackhole bh) { So there is a `Blackhole` argument here, but what is actually blackholed? AFAICS, stores to `call` and `put` are roughly okay to avoid dead-code elimination on these paths. ------------- PR: https://git.openjdk.java.net/jdk/pull/5234 From duke at openjdk.java.net Tue Aug 24 10:30:32 2021 From: duke at openjdk.java.net (duke) Date: Tue, 24 Aug 2021 10:30:32 GMT Subject: Withdrawn: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach wrote: > There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From alanb at openjdk.java.net Tue Aug 24 10:36:29 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 24 Aug 2021 10:36:29 GMT Subject: RFR: 8264322: Generate CDS archive when creating custom JDK image [v2] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 00:09:01 GMT, Calvin Cheung wrote: >> Please review this change for adding a `jlink` command line option `--generate-cds-archive` for generating CDS archives as a post processing step during the creation of a custom JDK image. >> >> Details can be found in the corresponding CSR [JDK-8269178](https://bugs.openjdk.java.net/browse/JDK-8269178). >> >> Testing: >> >> - [x] tiers 1,2 (including the new test) > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @mlchung comments This looks okay, and I see a follow-on issue has been created for the test improvements. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5174 From Alan.Bateman at oracle.com Tue Aug 24 10:42:59 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Aug 2021 11:42:59 +0100 Subject: Dangling class-level javadoc comments in JDK In-Reply-To: References: Message-ID: <281efd24-1ec4-593f-58ba-b4987547f7e0@oracle.com> On 24/08/2021 07:50, Andrey Turbanov wrote: > Hello. > I found a few internal classes in the JDK codebase which don't have > proper javadoc, but have dangling javadoc-like comments. > Dangling Javadoc comments are ignored by the javadoc tool and IDE. > Perhaps it was intentional to not add proper javadoc to them? > I believe it's better to convert them to proper javadoc to make > developing JDK a bit more friendly within IDE. > What do you think? There isn't any requirement for internal classes to have complete javadoc. If there are cases in the list where fleshing out or fixing javadoc issues would help future maintainers then go ahead. Looking at your list then I assume some of these are just noise and not worth doing anything. -Alan From dfuchs at openjdk.java.net Tue Aug 24 10:59:27 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 24 Aug 2021 10:59:27 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. java/net and sun/net changes LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5229 From azvegint at openjdk.java.net Tue Aug 24 11:51:26 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 24 Aug 2021 11:51:26 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. There are a bunch of calls to `Collections.sort()` without a comparator specified (at least in java.desktop): https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/Spans.java#L144 https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/awt/DebugSettings.java#L278 https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/swing/text/TextComponentPrintable.java#L787 https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultRowSorter.java#L1070 https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultRowSorter.java#L1204 https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/GroupLayout.java#L2137 It is also a wrapper to `list.sort(null)`. Is there any reason to not touch them along with this fix? ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From mgronlun at openjdk.java.net Tue Aug 24 12:58:29 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 24 Aug 2021 12:58:29 GMT Subject: RFR: 8266936: Add a finalization JFR event [v9] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: Model as finalizerService ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/5da3bb89..e6b786f1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=07-08 Stats: 1153 lines in 13 files changed: 578 ins; 555 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From clanger at openjdk.java.net Tue Aug 24 13:21:34 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 24 Aug 2021 13:21:34 GMT Subject: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1 In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote: > See the bug report for more details. I would appreciate if people with their corporate testing systems would run this through their systems to avoid surprises. (ping @RealCLanger, @iignatev). I have added this to our internal testing, let's see how it goes. Notifying @ArnoZeller about this. ------------- PR: https://git.openjdk.java.net/jdk/pull/5189 From andy.herrick at oracle.com Tue Aug 24 13:52:40 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 24 Aug 2021 09:52:40 -0400 Subject: JPackage and ask for microphone permissions broken on OSX... In-Reply-To: <15D1DFF8-0D3D-4DBF-9607-C63010FB7F23@gmail.com> References: <15D1DFF8-0D3D-4DBF-9607-C63010FB7F23@gmail.com> Message-ID: <54a933c5-c4a2-02bd-11f7-31250e59262d@oracle.com> On 8/24/2021 6:08 AM, Filteredaccount1 wrote: > Hi Andy, > > During the wait for JDK 18, would it be possible to describe on the bug ticket what manual workaround steps are required to apply to an existing jPackaged app for distribution both inside and outside the app store? The instructions for working around this bug as described are in public comment in https://bugs.openjdk.java.net/browse/ The related app-store specific change is in the default entitlements file.? I will add comment to JDK-8272639. explaining how to work around that issue by using the --entitlements option. There is one Info.plist for the app (.app/Contents/Info.plist) and another for the runtime (.app/Contents/runtime/Contents/Info.plist). Only the first one is relevant here.? The key NSMicrophoneUsageDescription belongs in the entitlements file (not the Info.plist). The default entitlements file for an app-store targeted app is src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/sandbox.plist , but that can be overridden using the --mac-entitlements option. One final thing to note, MacOS keeps track of what you have ever previously granted microphone permission to (and will never ask again) based on the mac package identifier (which defaults to the main class name), so I explicitly set this using a shell script with jpackage option "--mac-package-identifier audio-$1" option, so I can pass in different values and create a unique one each time. Hope this helps. /Andy > > There are two info.plist files inside a jPackaged app. In my experience adding keys to both didn?t turn the ask microphone permissions on. > > com.apple.security.device.audio-input > > > The application is requesting access to the microphone. > > Also, I raised at http://bugreport.java.com/ 9071230. So developer time isn?t wasted, could this be cancelled? (seems setup so the general public cannot). I can't see this issue, so it must already have been removed. /Andy > > Thank You, > > Ben S. > > >> Date: Wed, 18 Aug 2021 08:43:08 -0400 >> From: Andy Herrick >> To: core-libs-dev at openjdk.java.net >> Subject: Re: JPackage and ask for microphone permissions broken on >> OSX... >> Message-ID: <1534b02b-262a-f338-aae5-d1693d0072b3 at oracle.com> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> OK - I have reproduced this problem, filed an issue, and found the fix. >> >> You can see the issue in https://bugs.openjdk.java.net/browse/JDK-8272639. >> >> Basically another key is needed in application plist to cause >> application to ask for microphone access. >> >> It is far to late to get any fix into JDK17, but I will fix in JDK18 and >> you can work around this issue in JDK17 (or JDK16) by using the >> --resource-dir option: From jai.forums2013 at gmail.com Tue Aug 24 14:07:58 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 24 Aug 2021 19:37:58 +0530 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage Message-ID: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> The java.util.Properties class allows the properties to be written out to a stream or through a writer. In its current form, the specification of these APIs state that a comment comprising of the current date is always written out. The spec doesn't make any guarantees about the order of the properties when they are written out. There have been requests asking to make these APIs more deterministic. These requests, from what I have seen, mainly ask for: - A way to disable writing out the date comment - A way to write out the properties in a deterministic and reproducible way There have been discussions in the mailing list in the past which have been captured in JDK-8231640[1]. In these discussions, there has been an inclination to not touch the current existing API implementations and instead introduce new API(s) to achieve the proposed use cases. Before starting off with an implementation, I wanted to try and get some inputs on what the new API(s) would look like and what the scope of such a work should be. Right now, the Properties class has 2 "store" APIs: ??? public void store(Writer writer, String comments) throws IOException ??? public void store(OutputStream out, String comments) throws IOException For the sake of this discussion we won't be talking about the "save" API, in that same class, which has been deprecated. As part of this enhancement, one of the proposed API name is "storeCanonical". As a start, I plan to use this name for the new API. Is there any different suggestion for the name? As for the API signature, I plan to introduce 2 new APIs: ??? public void storeCanonical(Writer writer, String comments) throws IOException ??? public void storeCanonical(OutputStream out, String comments) throws IOException to match what the "store" variants currently provide. The first difference between these "storeCanonical" and the "store" will be the trivial part where these new "storeCanonical" implementations will no longer write out the date comment. Users are allowed to pass optional comments to these new APIs. If any comment is passed to these APIs, these will continue to be written out first, before the actual properties are written out. Speaking of optional comments, should the APIs accept an instance of java.util.Optional for the comments parameter. Perhaps: ??? public void storeCanonical(Writer writer, Optional comments) throws IOException ??? public void storeCanonical(OutputStream out, Optional comments) throws IOException Coming to the part where we write out the properties, these APIs will write out the properties in the lexicographical order of the property keys. An additional enhancement perhaps could be to allow users to pass in an optional java.util.Comparator instance to provide for application specific ordering of the property keys while being written out by these APIs. I am not too sure if we should introduce that. Any inputs? If we do introduce it, we would end up with 4 new APIs: ??? public void storeCanonical(Writer writer, Optional comments) throws IOException ??? public void storeCanonical(OutputStream out, Optional comments) throws IOException ??? public void storeCanonical(Writer writer, Optional comments, Comparator keyOrderer) throws IOException ??? public void storeCanonical(OutputStream out, Optional comments, Comparator keyOrderer) throws IOException Is that worth it? Finally, the other semantics, like the property key value separators, how/where newlines are inserted, what character encoding is used etc... will continue to match with the current semantics of the "store" APIs. [1] https://bugs.openjdk.java.net/browse/JDK-8231640 -Jaikiran From chegar at openjdk.java.net Tue Aug 24 14:24:33 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 24 Aug 2021 14:24:33 GMT Subject: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v2] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 03:03:48 GMT, Vicente Romero wrote: >> Please review this simple PR along with the associated CSR. The PR is basically adding a line the the specification of method `java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a NPE will be thrown. >> >> TIA >> >> link to the [CSR](https://bugs.openjdk.java.net/browse/JDK-8272852) > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review comments Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5226 From jonathan.gibbons at oracle.com Tue Aug 24 14:38:51 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 24 Aug 2021 07:38:51 -0700 Subject: Dangling class-level javadoc comments in JDK In-Reply-To: References: Message-ID: IIRC, the one in javadoc CommentUtils has recently been fixed. It might be worth a javac -Xlint option to detect/report such dangling comments. -- Jon On 8/23/21 11:50 PM, Andrey Turbanov wrote: > Hello. > I found a few internal classes in the JDK codebase which don't have > proper javadoc, but have dangling javadoc-like comments. > Dangling Javadoc comments are ignored by the javadoc tool and IDE. > Perhaps it was intentional to not add proper javadoc to them? > I believe it's better to convert them to proper javadoc to make > developing JDK a bit more friendly within IDE. > What do you think? > > List of classes: > > com.sun.beans.editors.BooleanEditor > com.sun.beans.editors.ByteEditor > com.sun.beans.editors.DoubleEditor > com.sun.beans.editors.FloatEditor > com.sun.beans.editors.IntegerEditor > com.sun.beans.editors.LongEditor > com.sun.beans.editors.NumberEditor > com.sun.beans.editors.ShortEditor > com.sun.jndi.toolkit.dir.ContainmentFilter > com.sun.jndi.toolkit.dir.LazySearchEnumerationImpl > com.sun.security.auth.module.Crypt > java.math.MutableBigInteger > java.net.DefaultInterface > javax.swing.GraphicsWrapper > jdk.internal.access.JavaAWTFontAccess > jdk.javadoc.internal.doclets.toolkit.CommentUtils > sun.awt.X11.XAtom > sun.awt.X11.XAwtState > sun.java2d.xr.XRBackend > sun.java2d.xr.XRDrawLine > sun.jvm.hotspot.debugger.PageCache > sun.jvm.hotspot.runtime.JavaThreadFactory > sun.jvm.hotspot.utilities.Interval > sun.jvm.hotspot.utilities.MessageQueueBackend > sun.jvm.hotspot.utilities.RBTree > sun.launcher.LauncherHelper > sun.net.www.content.text.plain > sun.net.www.protocol.file.FileURLConnection > sun.nio.ch.Interruptible > sun.security.pkcs.ParsingException > sun.security.provider.SeedGenerator > sun.security.util.ByteArrayTagOrder > sun.security.util.IOUtils > > > Andrey Turbanov From roger.riggs at oracle.com Tue Aug 24 14:44:38 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 24 Aug 2021 10:44:38 -0400 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> Message-ID: <2484bdde-173a-fa5a-278e-6502c799a095@oracle.com> Hi Jaikiran, Thanks for taking this on and getting it started. One use case of canonical storage is repeatable builds. It would be useful to identify the uses in the JDK that would need to be changed to use the new function. On 8/24/21 10:07 AM, Jaikiran Pai wrote: > The java.util.Properties class allows the properties to be written out > to a stream or through a writer. In its current form, the > specification of these APIs state that a comment comprising of the > current date is always written out. The spec doesn't make any > guarantees about the order of the properties when they are written out. > > There have been requests asking to make these APIs more deterministic. > These requests, from what I have seen, mainly ask for: > > - A way to disable writing out the date comment > - A way to write out the properties in a deterministic and > reproducible way > > There have been discussions in the mailing list in the past which have > been captured in JDK-8231640[1]. In these discussions, there has been > an inclination to not touch the current existing API implementations > and instead introduce new API(s) to achieve the proposed use cases. > > Before starting off with an implementation, I wanted to try and get > some inputs on what the new API(s) would look like and what the scope > of such a work should be. > > Right now, the Properties class has 2 "store" APIs: > > ??? public void store(Writer writer, String comments) throws IOException > ??? public void store(OutputStream out, String comments) throws > IOException I don't think two methods are needed, its easy enough for the caller to adapt an OutputStream to a Writer (OutputStreamWriter) and take control of the encoding, so the OutputStream version is not essential. > > For the sake of this discussion we won't be talking about the "save" > API, in that same class, which has been deprecated. > > As part of this enhancement, one of the proposed API name is > "storeCanonical". As a start, I plan to use this name for the new API. > Is there any different suggestion for the name? > > As for the API signature, I plan to introduce 2 new APIs: > > ??? public void storeCanonical(Writer writer, String comments) throws > IOException > ??? public void storeCanonical(OutputStream out, String comments) > throws IOException > > to match what the "store" variants currently provide. The first > difference between these "storeCanonical" and the "store" will be the > trivial part where these new "storeCanonical" implementations will no > longer write out the date comment. Users are allowed to pass optional > comments to these new APIs. If any comment is passed to these APIs, > these will continue to be written out first, before the actual > properties are written out. 'storeCanonical' captures the semantics. > > Speaking of optional comments, should the APIs accept an instance of > java.util.Optional for the comments parameter. Perhaps: > > ??? public void storeCanonical(Writer writer, Optional > comments) throws IOException > ??? public void storeCanonical(OutputStream out, Optional > comments) throws IOException Optional is overkill here, using null for no comment is conventional and matches the current usage in the store(..) methods. > > > Coming to the part where we write out the properties, these APIs will > write out the properties in the lexicographical order of the property > keys. An additional enhancement perhaps could be to allow users to > pass in an optional java.util.Comparator instance to provide for > application specific ordering of the property keys while being written > out by these APIs. I am not too sure if we should introduce that. Any > inputs? If we do introduce it, we would end up with 4 new APIs: > > ??? public void storeCanonical(Writer writer, Optional > comments) throws IOException > ??? public void storeCanonical(OutputStream out, Optional > comments) throws IOException > ??? public void storeCanonical(Writer writer, Optional > comments, Comparator keyOrderer) throws IOException > ??? public void storeCanonical(OutputStream out, Optional > comments, Comparator keyOrderer) throws IOException Canonical usually already means a non-variable encoding, that seems the inconsistent with providing a Comparator. However, it should be a goal that properties stored with storeCanonical can be loaded with load(). > > Is that worth it? > > Finally, the other semantics, like the property key value separators, > how/where newlines are inserted, what character encoding is used > etc... will continue to match with the current semantics of the > "store" APIs. If a client has the need for a custom format, its quite easy to iterate over the contents, sorting if desires and writing the format itself. A custom format would not be usable with Properties.load. Simpler is better, I think a single new method should suffice. Thanks, Roger > > > [1] https://bugs.openjdk.java.net/browse/JDK-8231640 > > -Jaikiran > From pavel.rappo at oracle.com Tue Aug 24 15:07:13 2021 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 24 Aug 2021 15:07:13 +0000 Subject: Dangling class-level javadoc comments in JDK In-Reply-To: References: Message-ID: <92857DA0-9885-4F21-803C-07D3222783AF@oracle.com> > On 24 Aug 2021, at 15:38, Jonathan Gibbons wrote: > > IIRC, the one in javadoc CommentUtils has recently been fixed. > > It might be worth a javac -Xlint option to detect/report such dangling comments. How would you currently implement that? Aren't comments on non-documentable constructs discarded early? At what point during compilation and how would you detect, for example, that this doc comment dangles? /** * IOUtils: A collection of IO-related public static methods. */ package sun.security.util; -Pavel > -- Jon > > On 8/23/21 11:50 PM, Andrey Turbanov wrote: >> Hello. >> I found a few internal classes in the JDK codebase which don't have >> proper javadoc, but have dangling javadoc-like comments. >> Dangling Javadoc comments are ignored by the javadoc tool and IDE. >> Perhaps it was intentional to not add proper javadoc to them? >> I believe it's better to convert them to proper javadoc to make >> developing JDK a bit more friendly within IDE. >> What do you think? >> >> List of classes: >> >> com.sun.beans.editors.BooleanEditor >> com.sun.beans.editors.ByteEditor >> com.sun.beans.editors.DoubleEditor >> com.sun.beans.editors.FloatEditor >> com.sun.beans.editors.IntegerEditor >> com.sun.beans.editors.LongEditor >> com.sun.beans.editors.NumberEditor >> com.sun.beans.editors.ShortEditor >> com.sun.jndi.toolkit.dir.ContainmentFilter >> com.sun.jndi.toolkit.dir.LazySearchEnumerationImpl >> com.sun.security.auth.module.Crypt >> java.math.MutableBigInteger >> java.net.DefaultInterface >> javax.swing.GraphicsWrapper >> jdk.internal.access.JavaAWTFontAccess >> jdk.javadoc.internal.doclets.toolkit.CommentUtils >> sun.awt.X11.XAtom >> sun.awt.X11.XAwtState >> sun.java2d.xr.XRBackend >> sun.java2d.xr.XRDrawLine >> sun.jvm.hotspot.debugger.PageCache >> sun.jvm.hotspot.runtime.JavaThreadFactory >> sun.jvm.hotspot.utilities.Interval >> sun.jvm.hotspot.utilities.MessageQueueBackend >> sun.jvm.hotspot.utilities.RBTree >> sun.launcher.LauncherHelper >> sun.net.www.content.text.plain >> sun.net.www.protocol.file.FileURLConnection >> sun.nio.ch.Interruptible >> sun.security.pkcs.ParsingException >> sun.security.provider.SeedGenerator >> sun.security.util.ByteArrayTagOrder >> sun.security.util.IOUtils >> >> >> Andrey Turbanov From pavel.rappo at oracle.com Tue Aug 24 15:15:46 2021 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 24 Aug 2021 15:15:46 +0000 Subject: Dangling class-level javadoc comments in JDK In-Reply-To: <92857DA0-9885-4F21-803C-07D3222783AF@oracle.com> References: <92857DA0-9885-4F21-803C-07D3222783AF@oracle.com> Message-ID: <5A04867F-D964-41F6-B1EA-43475C8009D1@oracle.com> Just to clarify that example of mine. I didn't mean the package-info.java file. I meant an ordinary file that comprises an interface, class, enum or record. Perhaps a better example from Andrey's list would be this: /** * A utility package for the java(1), javaw(1) launchers. * The following are helper methods that the native launcher uses * to perform checks etc. using JNI, see src/share/bin/java.c */ import java.io.File; In no context can an import statement be documented. -Pavel > On 24 Aug 2021, at 16:07, Pavel Rappo wrote: > >> On 24 Aug 2021, at 15:38, Jonathan Gibbons wrote: >> >> IIRC, the one in javadoc CommentUtils has recently been fixed. >> >> It might be worth a javac -Xlint option to detect/report such dangling comments. > > How would you currently implement that? Aren't comments on non-documentable constructs discarded early? At what point during compilation and how would you detect, for example, that this doc comment dangles? > > /** > * IOUtils: A collection of IO-related public static methods. > */ > > package sun.security.util; > > -Pavel > >> -- Jon >> >> On 8/23/21 11:50 PM, Andrey Turbanov wrote: >>> Hello. >>> I found a few internal classes in the JDK codebase which don't have >>> proper javadoc, but have dangling javadoc-like comments. >>> Dangling Javadoc comments are ignored by the javadoc tool and IDE. >>> Perhaps it was intentional to not add proper javadoc to them? >>> I believe it's better to convert them to proper javadoc to make >>> developing JDK a bit more friendly within IDE. >>> What do you think? >>> >>> List of classes: >>> >>> com.sun.beans.editors.BooleanEditor >>> com.sun.beans.editors.ByteEditor >>> com.sun.beans.editors.DoubleEditor >>> com.sun.beans.editors.FloatEditor >>> com.sun.beans.editors.IntegerEditor >>> com.sun.beans.editors.LongEditor >>> com.sun.beans.editors.NumberEditor >>> com.sun.beans.editors.ShortEditor >>> com.sun.jndi.toolkit.dir.ContainmentFilter >>> com.sun.jndi.toolkit.dir.LazySearchEnumerationImpl >>> com.sun.security.auth.module.Crypt >>> java.math.MutableBigInteger >>> java.net.DefaultInterface >>> javax.swing.GraphicsWrapper >>> jdk.internal.access.JavaAWTFontAccess >>> jdk.javadoc.internal.doclets.toolkit.CommentUtils >>> sun.awt.X11.XAtom >>> sun.awt.X11.XAwtState >>> sun.java2d.xr.XRBackend >>> sun.java2d.xr.XRDrawLine >>> sun.jvm.hotspot.debugger.PageCache >>> sun.jvm.hotspot.runtime.JavaThreadFactory >>> sun.jvm.hotspot.utilities.Interval >>> sun.jvm.hotspot.utilities.MessageQueueBackend >>> sun.jvm.hotspot.utilities.RBTree >>> sun.launcher.LauncherHelper >>> sun.net.www.content.text.plain >>> sun.net.www.protocol.file.FileURLConnection >>> sun.nio.ch.Interruptible >>> sun.security.pkcs.ParsingException >>> sun.security.provider.SeedGenerator >>> sun.security.util.ByteArrayTagOrder >>> sun.security.util.IOUtils >>> >>> >>> Andrey Turbanov > From ccheung at openjdk.java.net Tue Aug 24 15:34:34 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 24 Aug 2021 15:34:34 GMT Subject: RFR: 8264322: Generate CDS archive when creating custom JDK image [v2] In-Reply-To: References: Message-ID: <0W_IX_X-mwZmwtCK2ebVpdqfQw1laMBPJlEiCyxjDDk=.1c85ac7f-f917-4680-9032-6c9f1fe6f2e3@github.com> On Tue, 24 Aug 2021 02:16:31 GMT, Mandy Chung wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> @mlchung comments > > Thanks for creating a JBS issue. I'm okay to follow up the test improvement as a separate issue. @mlchung, @AlanBateman Thanks for the review and discussions. ------------- PR: https://git.openjdk.java.net/jdk/pull/5174 From ccheung at openjdk.java.net Tue Aug 24 15:34:37 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 24 Aug 2021 15:34:37 GMT Subject: Integrated: 8264322: Generate CDS archive when creating custom JDK image In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 21:21:06 GMT, Calvin Cheung wrote: > Please review this change for adding a `jlink` command line option `--generate-cds-archive` for generating CDS archives as a post processing step during the creation of a custom JDK image. > > Details can be found in the corresponding CSR [JDK-8269178](https://bugs.openjdk.java.net/browse/JDK-8269178). > > Testing: > > - [x] tiers 1,2 (including the new test) This pull request has now been integrated. Changeset: f608e81a Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/f608e81ad8309a001b8a92563a93b8adee1ce2b8 Stats: 372 lines in 11 files changed: 329 ins; 7 del; 36 mod 8264322: Generate CDS archive when creating custom JDK image Reviewed-by: mchung, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5174 From naoto at openjdk.java.net Tue Aug 24 15:55:30 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 24 Aug 2021 15:55:30 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. java.time changes look good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5229 From rriggs at openjdk.java.net Tue Aug 24 16:01:44 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 24 Aug 2021 16:01:44 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java Message-ID: The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. ------------- Commit messages: - 8272600: (test) Use native "sleep" in Basic.java Changes: https://git.openjdk.java.net/jdk/pull/5239/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5239&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272600 Stats: 116 lines in 2 files changed: 70 ins; 34 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/5239.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5239/head:pull/5239 PR: https://git.openjdk.java.net/jdk/pull/5239 From iklam at openjdk.java.net Tue Aug 24 16:36:28 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 24 Aug 2021 16:36:28 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 15:55:28 GMT, Roger Riggs wrote: > The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM > as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . > > There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. > The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. test/jdk/java/lang/ProcessBuilder/Basic.java line 30: > 28: * 6464154 6523983 6206031 4960438 6631352 6631966 6850957 6850958 > 29: * 4947220 7018606 7034570 4244896 5049299 8003488 8054494 8058464 > 30: * 8067796 8224905 8263729 8265173 8272600 8231297 The test should also be modified to use `@run main/othervm/native/timeout=300` so that this test will be flagged by jtreg if `-nativepath:` is not specified. test/jdk/java/lang/ProcessBuilder/Basic.java line 2635: > 2633: List childArgs = null; > 2634: Path sleepExe = TEST_NATIVEPATH.resolve("sleepmillis"); > 2635: if (sleepExe.toFile().canExecute()) { Why is the fallback necessary? Other test cases such as test/jdk/tools/launcher/JliLaunchTest.java do not have such a fallback. Also, I noticed that JliLaunchTest does something like this: Path launcher = Paths.get(System.getProperty("test.nativepath"), "JliLaunchTest" + (Platform.isWindows() ? ".exe" : "")); but test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java doesn't add ".exe", so it may not be necessary. test/jdk/java/lang/ProcessBuilder/exeSleepMillis.c line 45: > 43: sleeptime.tv_nsec = (millis % 1000) * 1000 * 1000; > 44: int rc; > 45: while ((rc = nanosleep(&sleeptime, &sleeptime)) > 0) { is `nanosleep` a portable call? I couldn't find documentation for it with google search of `nanosleep site:docs.microsoft.com`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From jonathan.gibbons at oracle.com Tue Aug 24 17:19:11 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 24 Aug 2021 10:19:11 -0700 Subject: Dangling class-level javadoc comments in JDK In-Reply-To: <92857DA0-9885-4F21-803C-07D3222783AF@oracle.com> References: <92857DA0-9885-4F21-803C-07D3222783AF@oracle.com> Message-ID: The poor-man's solution would be to detect common cases, with the comment appearing before a package or import statement. A more advanced solution would have to be in the lexer or parser, detecting that there is a "unused" comment when creating a tree node. -- Jon On 8/24/21 8:07 AM, Pavel Rappo wrote: >> On 24 Aug 2021, at 15:38, Jonathan Gibbons wrote: >> >> IIRC, the one in javadoc CommentUtils has recently been fixed. >> >> It might be worth a javac -Xlint option to detect/report such dangling comments. > How would you currently implement that? Aren't comments on non-documentable constructs discarded early? At what point during compilation and how would you detect, for example, that this doc comment dangles? > > /** > * IOUtils: A collection of IO-related public static methods. > */ > > package sun.security.util; > > -Pavel > >> -- Jon >> >> On 8/23/21 11:50 PM, Andrey Turbanov wrote: >>> Hello. >>> I found a few internal classes in the JDK codebase which don't have >>> proper javadoc, but have dangling javadoc-like comments. >>> Dangling Javadoc comments are ignored by the javadoc tool and IDE. >>> Perhaps it was intentional to not add proper javadoc to them? >>> I believe it's better to convert them to proper javadoc to make >>> developing JDK a bit more friendly within IDE. >>> What do you think? >>> >>> List of classes: >>> >>> com.sun.beans.editors.BooleanEditor >>> com.sun.beans.editors.ByteEditor >>> com.sun.beans.editors.DoubleEditor >>> com.sun.beans.editors.FloatEditor >>> com.sun.beans.editors.IntegerEditor >>> com.sun.beans.editors.LongEditor >>> com.sun.beans.editors.NumberEditor >>> com.sun.beans.editors.ShortEditor >>> com.sun.jndi.toolkit.dir.ContainmentFilter >>> com.sun.jndi.toolkit.dir.LazySearchEnumerationImpl >>> com.sun.security.auth.module.Crypt >>> java.math.MutableBigInteger >>> java.net.DefaultInterface >>> javax.swing.GraphicsWrapper >>> jdk.internal.access.JavaAWTFontAccess >>> jdk.javadoc.internal.doclets.toolkit.CommentUtils >>> sun.awt.X11.XAtom >>> sun.awt.X11.XAwtState >>> sun.java2d.xr.XRBackend >>> sun.java2d.xr.XRDrawLine >>> sun.jvm.hotspot.debugger.PageCache >>> sun.jvm.hotspot.runtime.JavaThreadFactory >>> sun.jvm.hotspot.utilities.Interval >>> sun.jvm.hotspot.utilities.MessageQueueBackend >>> sun.jvm.hotspot.utilities.RBTree >>> sun.launcher.LauncherHelper >>> sun.net.www.content.text.plain >>> sun.net.www.protocol.file.FileURLConnection >>> sun.nio.ch.Interruptible >>> sun.security.pkcs.ParsingException >>> sun.security.provider.SeedGenerator >>> sun.security.util.ByteArrayTagOrder >>> sun.security.util.IOUtils >>> >>> >>> Andrey Turbanov From ccheung at openjdk.java.net Tue Aug 24 17:29:38 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 24 Aug 2021 17:29:38 GMT Subject: RFR: 8272916: Copyright year was modified unintentionally in jlink.properties and ImagePluginStack.java Message-ID: Please review this trivial change for fixing the copyright year of the two files (jlink.properties and ImagePluginStack.java) which were modified unintentionally during the fix for JDK-8264322. ------------- Commit messages: - 8272916: Copyright year was modified unintentionally in jlink.properties and ImagePluginStack.java Changes: https://git.openjdk.java.net/jdk/pull/5240/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5240&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272916 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5240.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5240/head:pull/5240 PR: https://git.openjdk.java.net/jdk/pull/5240 From bpb at openjdk.java.net Tue Aug 24 17:38:25 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 24 Aug 2021 17:38:25 GMT Subject: RFR: 8272916: Copyright year was modified unintentionally in jlink.properties and ImagePluginStack.java In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 17:21:20 GMT, Calvin Cheung wrote: > Please review this trivial change for fixing the copyright year of the two files (jlink.properties and ImagePluginStack.java) which were modified unintentionally during the fix for JDK-8264322. I verified that in the commit to fix JDK-8264322 no content changes were actually made to the files in this commit. Approved. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5240 From ccheung at openjdk.java.net Tue Aug 24 18:13:29 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 24 Aug 2021 18:13:29 GMT Subject: RFR: 8272916: Copyright year was modified unintentionally in jlink.properties and ImagePluginStack.java In-Reply-To: References: Message-ID: <1h4NwwRzcT3cCRH-5_i2693rNvftjyphZnwUBkFwXyo=.cd2548ef-6148-49d2-9fc7-81856dff317a@github.com> On Tue, 24 Aug 2021 17:35:50 GMT, Brian Burkhalter wrote: >> Please review this trivial change for fixing the copyright year of the two files (jlink.properties and ImagePluginStack.java) which were modified unintentionally during the fix for JDK-8264322. > > I verified that in the commit to fix JDK-8264322 no content changes were actually made to the files in this commit. Approved. @bplb Thanks for your quick review. ------------- PR: https://git.openjdk.java.net/jdk/pull/5240 From ccheung at openjdk.java.net Tue Aug 24 18:13:30 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 24 Aug 2021 18:13:30 GMT Subject: Integrated: 8272916: Copyright year was modified unintentionally in jlink.properties and ImagePluginStack.java In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 17:21:20 GMT, Calvin Cheung wrote: > Please review this trivial change for fixing the copyright year of the two files (jlink.properties and ImagePluginStack.java) which were modified unintentionally during the fix for JDK-8264322. This pull request has now been integrated. Changeset: c547ead4 Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/c547ead493fafb6716550996a83276afc0ec018a Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8272916: Copyright year was modified unintentionally in jlink.properties and ImagePluginStack.java Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5240 From rriggs at openjdk.java.net Tue Aug 24 19:10:29 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 24 Aug 2021 19:10:29 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 16:14:16 GMT, Ioi Lam wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . >> >> There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. >> The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. > > test/jdk/java/lang/ProcessBuilder/Basic.java line 30: > >> 28: * 6464154 6523983 6206031 4960438 6631352 6631966 6850957 6850958 >> 29: * 4947220 7018606 7034570 4244896 5049299 8003488 8054494 8058464 >> 30: * 8067796 8224905 8263729 8265173 8272600 8231297 > > The test should also be modified to use `@run main/othervm/native/timeout=300` so that this test will be flagged by jtreg if `-nativepath:` is not specified. It should be possible to run this test as a main, without the overhead of building the native image. The use of a Java child greatly reduces the complexity of the test and improves its maintainability. Requiring a native special built program raises the overhead considerably. And all because the VM can't or won't allow its output to be managed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From rriggs at openjdk.java.net Tue Aug 24 19:21:29 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 24 Aug 2021 19:21:29 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 16:16:45 GMT, Ioi Lam wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . >> >> There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. >> The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. > > test/jdk/java/lang/ProcessBuilder/Basic.java line 2635: > >> 2633: List childArgs = null; >> 2634: Path sleepExe = TEST_NATIVEPATH.resolve("sleepmillis"); >> 2635: if (sleepExe.toFile().canExecute()) { > > Why is the fallback necessary? Other test cases such as test/jdk/tools/launcher/JliLaunchTest.java do not have such a fallback. > > Also, I noticed that JliLaunchTest does something like this: > > > Path launcher = Paths.get(System.getProperty("test.nativepath"), > "JliLaunchTest" + (Platform.isWindows() ? ".exe" : "")); > > > but test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java doesn't add ".exe", so it may not be necessary. See above, the java Child is more portable and lower maintenance. Windows looks for xxx.exe if xxx is not found. > test/jdk/java/lang/ProcessBuilder/exeSleepMillis.c line 45: > >> 43: sleeptime.tv_nsec = (millis % 1000) * 1000 * 1000; >> 44: int rc; >> 45: while ((rc = nanosleep(&sleeptime, &sleeptime)) > 0) { > > is `nanosleep` a portable call? I couldn't find documentation for it with google search of `nanosleep site:docs.microsoft.com`. Sadly, true. Falling back to the portable 'sleep(seconds)' is necessary; but the timing will be less precise. C++ supports a higher resolution 'sleep_for' but the JDK native test build does not support building main programs using C++ and its not worth the complications added. ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 24 20:21:52 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 24 Aug 2021 20:21:52 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2] In-Reply-To: References: Message-ID: > Collections.sort is just a wrapper, so it is better to use an instance method directly. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8272863: Replace usages of Collections.sort with List.sort call in public java modules replace Collections.sort without comparator too ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5229/files - new: https://git.openjdk.java.net/jdk/pull/5229/files/e31936a5..d6dfc8bf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5229&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5229&range=00-01 Stats: 21 lines in 10 files changed: 0 ins; 4 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/5229.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5229/head:pull/5229 PR: https://git.openjdk.java.net/jdk/pull/5229 From github.com+741251+turbanoff at openjdk.java.net Tue Aug 24 20:21:52 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 24 Aug 2021 20:21:52 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 11:48:46 GMT, Alexander Zvegintsev wrote: > Is there any reason to not touch them along with this fix? Update them too. ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From sviswanathan at openjdk.java.net Tue Aug 24 20:44:01 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 24 Aug 2021 20:44:01 GMT Subject: RFR: 8272861: Add a micro benchmark for vector api [v2] In-Reply-To: References: Message-ID: > This pull request adds a micro benchmark for Vector API. > The Black Scholes algorithm is implemented with and without Vector API. > We see about ~6x gain with Vector API for this micro benchmark using 256 bit vectors. Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Implement review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5234/files - new: https://git.openjdk.java.net/jdk/pull/5234/files/ca688faa..f92994cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5234&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5234&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5234.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5234/head:pull/5234 PR: https://git.openjdk.java.net/jdk/pull/5234 From sviswanathan at openjdk.java.net Tue Aug 24 20:49:52 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 24 Aug 2021 20:49:52 GMT Subject: RFR: 8272861: Add a micro benchmark for vector api [v3] In-Reply-To: References: Message-ID: <2RbnsJk-_7EXYWD0Vun5aJQn18sQUudSPOG3dxNma-U=.1665ff7a-5018-4b9f-8420-5555f64ca308@github.com> > This pull request adds a micro benchmark for Vector API. > The Black Scholes algorithm is implemented with and without Vector API. > We see about ~6x gain with Vector API for this micro benchmark using 256 bit vectors. Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Make constants as static final ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5234/files - new: https://git.openjdk.java.net/jdk/pull/5234/files/f92994cd..5b4abbf9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5234&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5234&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5234.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5234/head:pull/5234 PR: https://git.openjdk.java.net/jdk/pull/5234 From sviswanathan at openjdk.java.net Tue Aug 24 20:49:52 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 24 Aug 2021 20:49:52 GMT Subject: RFR: 8272861: Add a micro benchmark for vector api [v3] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 10:09:13 GMT, Aleksey Shipilev wrote: >> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: >> >> Make constants as static final > > Some benchmark comments. @shipilev @nsjian Thanks a lot for the feedback. I have implemented your review comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/5234 From herrick at openjdk.java.net Tue Aug 24 21:02:31 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 24 Aug 2021 21:02:31 GMT Subject: Integrated: JDK-8272639: jpackaged applications using microphone on mac In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 14:12:00 GMT, Andy Herrick wrote: > JDK-8272639: jpackaged applications using microphone on mac This pull request has now been integrated. Changeset: b17b821a Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/b17b821a570930e4188bcdfb396f0a7abe99caf6 Stats: 5 lines in 3 files changed: 4 ins; 0 del; 1 mod 8272639: jpackaged applications using microphone on mac Reviewed-by: almatvee, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/5186 From joehw at openjdk.java.net Tue Aug 24 23:14:25 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 24 Aug 2021 23:14:25 GMT Subject: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. When instant seconds and zone co-exist in parsed data, instant seconds was not resolved correctly from them. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5225 From iklam at openjdk.java.net Wed Aug 25 00:41:24 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 25 Aug 2021 00:41:24 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 19:15:56 GMT, Roger Riggs wrote: >> test/jdk/java/lang/ProcessBuilder/Basic.java line 2635: >> >>> 2633: List childArgs = null; >>> 2634: Path sleepExe = TEST_NATIVEPATH.resolve("sleepmillis"); >>> 2635: if (sleepExe.toFile().canExecute()) { >> >> Why is the fallback necessary? Other test cases such as test/jdk/tools/launcher/JliLaunchTest.java do not have such a fallback. >> >> Also, I noticed that JliLaunchTest does something like this: >> >> >> Path launcher = Paths.get(System.getProperty("test.nativepath"), >> "JliLaunchTest" + (Platform.isWindows() ? ".exe" : "")); >> >> >> but test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java doesn't add ".exe", so it may not be necessary. > > See above, the java Child is more portable and lower maintenance. > Windows looks for xxx.exe if xxx is not found. How about adding a comment to explain why the fallback is necessary? Also, if `jtreg -nativepath:xxx` is specified, but there's no xxx/sleepmillis, or xxx/sleepmillis is not executable, that should be a setup error (or a bug in the test itself). E.g., if we are testing inside mach5, we should always execute the native program, and should not silently fallback to the java Child program. Otherwise, setup problems in mach5 might bring us back to the mysterious intermittent failure. (The current version of the code is buggy on Windows and will always silently fall back to Child because the executable is named "sleepmillis.exe", not "sleepmillis"). ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From mchung at openjdk.java.net Wed Aug 25 02:20:32 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 25 Aug 2021 02:20:32 GMT Subject: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v2] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 03:03:37 GMT, Vicente Romero wrote: >> src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 327: >> >>> 325: * @throws IllegalArgumentException if the bootstrap arguments are invalid >>> 326: * or inconsistent >>> 327: * @throws NullPointerException if any argument but {@code lookup} is {@code null} >> >> `names` may be null if the {@code methodName} is {@code "equals"} or {@code "hashCode"}. This should be captured here. > > Hi Mandy, I have changed the implementation of the method to explicitly require all arguments but lookup to be non-null as suggested by Brian. I have also covered, I think, all the missing test cases in test `ObjectMethodsTest`, thanks for your comments. I think you meant requiring `names` to be non-null but `lookup` may still be null. It's okay to change the spec to require `names` to be non-null. Probably better to mention in `@param names` that `names` is ignored when the `methodName` is `equals` or `hashCode`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5226 From ngasson at openjdk.java.net Wed Aug 25 07:44:23 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 25 Aug 2021 07:44:23 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v6] In-Reply-To: References: Message-ID: <_XL6WybKwHeJ54kSQnN_q0_NgvR7ib9BFjNJ4HrkO_g=.f82e6cda-b31f-4eee-9185-3e52ebd6b54d@github.com> On Fri, 6 Aug 2021 09:50:54 GMT, Wang Huang wrote: >> Dear all, >> Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo. >> >> * We add a JMH test case >> * Here is the result of this test case >> >> Benchmark |(size)| Mode| Cnt|Score | Error |Units >> ---------------------------------|------|-----|----|------|--------|----- >> StringCompare.compareLL | 64 | avgt| 5 |7.992 | ? 0.005|us/op >> StringCompare.compareLL | 72 | avgt| 5 |15.029| ? 0.006|us/op >> StringCompare.compareLL | 80 | avgt| 5 |14.655| ? 0.011|us/op >> StringCompare.compareLL | 91 | avgt| 5 |16.363| ? 0.12 |us/op >> StringCompare.compareLL | 101 | avgt| 5 |16.966| ? 0.007|us/op >> StringCompare.compareLL | 121 | avgt| 5 |19.276| ? 0.006|us/op >> StringCompare.compareLL | 181 | avgt| 5 |19.002| ? 0.417|us/op >> StringCompare.compareLL | 256 | avgt| 5 |24.707| ? 0.041|us/op >> StringCompare.compareLLWithLdp| 64 | avgt| 5 |8.001 | ? 0.121|us/op >> StringCompare.compareLLWithLdp| 72 | avgt| 5 |11.573| ? 0.003|us/op >> StringCompare.compareLLWithLdp| 80 | avgt| 5 |6.861 | ? 0.004|us/op >> StringCompare.compareLLWithLdp| 91 | avgt| 5 |12.774| ? 0.201|us/op >> StringCompare.compareLLWithLdp| 101 | avgt| 5 |8.691 | ? 0.004|us/op >> StringCompare.compareLLWithLdp| 121 | avgt| 5 |11.091| ? 1.342|us/op >> StringCompare.compareLLWithLdp| 181 | avgt| 5 |14.64 | ? 0.581|us/op >> StringCompare.compareLLWithLdp| 256 | avgt| 5 |25.879| ? 1.775|us/op >> StringCompare.compareUU | 64 | avgt| 5 |13.476| ? 0.01 |us/op >> StringCompare.compareUU | 72 | avgt| 5 |15.078| ? 0.006|us/op >> StringCompare.compareUU | 80 | avgt| 5 |23.512| ? 0.011|us/op >> StringCompare.compareUU | 91 | avgt| 5 |24.284| ? 0.008|us/op >> StringCompare.compareUU | 101 | avgt| 5 |20.707| ? 0.017|us/op >> StringCompare.compareUU | 121 | avgt| 5 |29.302| ? 0.011|us/op >> StringCompare.compareUU | 181 | avgt| 5 |39.31 | ? 0.016|us/op >> StringCompare.compareUU | 256 | avgt| 5 |54.592| ? 0.392|us/op >> StringCompare.compareUUWithLdp| 64 | avgt| 5 |16.389| ? 0.008|us/op >> StringCompare.compareUUWithLdp| 72 | avgt| 5 |10.71 | ? 0.158|us/op >> StringCompare.compareUUWithLdp| 80 | avgt| 5 |11.488| ? 0.024|us/op >> StringCompare.compareUUWithLdp| 91 | avgt| 5 |13.412| ? 0.006|us/op >> StringCompare.compareUUWithLdp| 101 | avgt| 5 |16.245| ? 0.434|us/op >> StringCompare.compareUUWithLdp| 121 | avgt| 5 |16.597| ? 0.016|us/op >> StringCompare.compareUUWithLdp| 181 | avgt| 5 |27.373| ? 0.017|us/op >> StringCompare.compareUUWithLdp| 256 | avgt| 5 |41.74 | ? 3.5 |us/op >> >> From this table, we can see that in most cases, our patch is better than old one. >> >> Thank you for your review. Any suggestions are welcome. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix codestyle I've run the benchmark on several different machines and didn't see any performance regressions, and the speed-up for longer strings looks quite good. I also ran jtreg tier1-3 with no new failures so I think this is ok. If you fix the Windows build I'll approve it. But please wait for another review, preferably from @theRealAph. Note that JDK-8269559 (#5129) is also adding a JMH benchmark for this intrinsic: it would be good if we could merge them, either now or later. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4871: > 4869: // exit from large loop when less than 64 bytes left to read or we're about > 4870: // to prefetch memory behind array border > 4871: int largeLoopExitCondition = MAX(64, SoftwarePrefetchHintDistance)/(isLL ? 1 : 2); This breaks the Windows AArch64 build: Creating support/modules_libs/java.base/server/jvm.dll from 1051 file(s) d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\stubGenerator_aarch64.cpp(4871): error C3861: 'MAX': identifier not found make[3]: *** [lib/CompileJvm.gmk:143: /cygdrive/d/a/jdk/jdk/jdk/build/windows-aarch64/hotspot/variant-server/libjvm https://github.com/Wanghuang-Huawei/jdk/runs/3260986937 Should probably be left as `MAX2`. ------------- Changes requested by ngasson (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4722 From shade at openjdk.java.net Wed Aug 25 08:08:25 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 25 Aug 2021 08:08:25 GMT Subject: RFR: 8272836: Limit run time for java/lang/invoke/LFCaching tests In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 11:33:35 GMT, Aleksey Shipilev wrote: > See the RFE for discussion. > > Current PR improves the test time like this: > > > $ make run-test TEST=java/lang/invoke/LFCaching/ > > # Before > real 3m51.608s > user 5m21.612s > sys 0m5.391s > > # After > real 1m13.606s > user 2m26.827s > sys 0m4.761s Any other comments for this patch? I would integrate it soon otherwise. @iignatev, maybe? ------------- PR: https://git.openjdk.java.net/jdk/pull/5214 From dfuchs at openjdk.java.net Wed Aug 25 08:33:26 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 25 Aug 2021 08:33:26 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 20:21:52 GMT, Andrey Turbanov wrote: >> Collections.sort is just a wrapper, so it is better to use an instance method directly. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8272863: Replace usages of Collections.sort with List.sort call in public java modules > replace Collections.sort without comparator too src/java.base/share/classes/java/net/URLPermission.java line 222: > 220: > 221: List l = normalizeMethods(methods); > 222: l.sort(null); I am not opposed to this change, but I find this is slightly more ugly than `Collections.sort(l)`; so I have to ask: Is there any noticeable benefit? ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From forax at univ-mlv.fr Wed Aug 25 10:22:21 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 25 Aug 2021 12:22:21 +0200 (CEST) Subject: Implementing MethodHandleProxies#asInterfaceInstance with hidden classes In-Reply-To: References: Message-ID: <893757745.907387.1629886941949.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "-" > To: "Brian Goetz" , "core-libs-dev" > Sent: Lundi 23 Ao?t 2021 08:34:17 > Subject: Re: Implementing MethodHandleProxies#asInterfaceInstance with hidden classes > Thanks for the quick reply! > > The main drawback, API wise, with LMF is that it does not accept > non-direct method handles [1], while the MHP is able accept any method > handle, such as native ones from JEP 389 [2]. LMF also lacks the > ability to restore a method handle from a wrapper instance. Using LMF > also requires user discretion on which methods to implement, and the > lookup's required privileges may change too. In general, MHP would be > more runtime-oriented and transient compared to LMF. > > I am inclined toward a separate bytecode generation implementation for > the improved MHP asInterfaceInstance, somewhat similar to what's in > JEP 416's implementation [3]. The extra bridges for all compatible > methods, accessors to backing method handle/interface, potential to > expand to abstract classes, different hidden class modes would reduce > the commonalities between the two implementations and make > refactorings on LMF to support these MHP functionalities costly. In my opinion, what is missing is a java.lang.invoke.Proxy, the equivalent of java.lang.reflect.Proxy but using defineHiddenClass + a bootstrap method + method handles instead of the InvocationHandler + j.l.r.Method. With that, implementing java.lang.invoke.MethodHandleProxies on top of of java.lang.invoke.Proxy is just a matter of wiring. As you said, there is a need for a more dynamic version of the LambdaMetafactory. I believe it should work with any interfaces not only functional interfaces. This would avoid statically typed langages like Kotlin or Scala, or injection frameworks like Weld, Spring or Guice to generate a lot of proxy classes and it should be straightforward enough so static compilers like graal native image or Android d8 can generate the proxy classes at compile time to support "native" compilation (the same way lambdas are currently supported). So we get best of both worlds, efficient dynamic proxies at runtime AND supports of "native" compilation. R?mi > > [1] > https://github.com/openjdk/jdk/blob/b690f29699180149d33b6a83de10697790587a87/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java#L141 > [2] https://openjdk.java.net/jeps/389#The-C-linker > [3] > https://github.com/openjdk/jdk/blob/cff856f9df89293cbc8f2f1e977148cd6ece4f85/src/java.base/share/classes/jdk/internal/reflect/ClassByteBuilder.java > > > On Sun, Aug 22, 2021 at 9:26 PM Brian Goetz wrote: >> >> This was an early attempt at the functionality provided by LambdaMetafactory. >> It could probably be reimplemented on top of that, but probably could be >> deprecated in favor of LMF as well. >> >> Sent from my iPad >> >> > On Aug 22, 2021, at 10:08 PM, liangchenblue at gmail.com wrote: >> > >> > ?Currently, java.lang.invoke.MethodHandleProxies#asInterfaceInstance [1] is >> > implemented with java.lang.reflect.Proxy. After looking at its public API, >> > including Javadoc, it seems that MethodHandleProxies would benefit from a >> > hidden class implementation without changing its public API definition >> > (including Javadocs). >> > >> > Recently, there is JEP 416 [2] for reimplementing reflection based on >> > method handles. This implementation utilizes hidden classes with method >> > handles passed in classdata and retrieved to condy, which allows generic >> > method handles (beyond regular constable ones) to be optimized in method >> > calls. Similarly, for MethodHandleProxies, hidden classes allow the >> > implementations to detach from classloaders and be freely recyclable; they >> > can use class data to store the adapted method handles (which can >> > significantly speed up invocations); and it can allow it to support >> > implementing single-abstract-method abstract classes in the future (as >> > discussed in its Javadoc) as well, with only minor tweaks. >> > >> > Does this sound feasible? I want to ensure it is a good idea before any >> > implementation is attempted. If there is any issue with this vision, please >> > don't hesitate to point it out. Feel free to comment, too! If this looks >> > good, I hope an issue can be created for it. >> > >> > Best >> > >> > [1] >> > https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/invoke/MethodHandleProxies.html > > > [2] https://openjdk.java.net/jeps/416 From Alan.Bateman at oracle.com Wed Aug 25 10:44:32 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 Aug 2021 11:44:32 +0100 Subject: Implementing MethodHandleProxies#asInterfaceInstance with hidden classes In-Reply-To: <893757745.907387.1629886941949.JavaMail.zimbra@u-pem.fr> References: <893757745.907387.1629886941949.JavaMail.zimbra@u-pem.fr> Message-ID: <7096cf69-c914-d8f0-082c-e8098d2f56c4@oracle.com> On 25/08/2021 11:22, Remi Forax wrote: > : > In my opinion, what is missing is a java.lang.invoke.Proxy, the equivalent of java.lang.reflect.Proxy but using defineHiddenClass + a bootstrap method + method handles instead of the InvocationHandler + j.l.r.Method. With that, implementing java.lang.invoke.MethodHandleProxies on top of of java.lang.invoke.Proxy is just a matter of wiring. I suspect this will eventually be a new API. Mandy has captured some of the issues in JDK-8242888 [1] -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8242888 From jai.forums2013 at gmail.com Wed Aug 25 10:51:41 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 25 Aug 2021 16:21:41 +0530 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <2484bdde-173a-fa5a-278e-6502c799a095@oracle.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <2484bdde-173a-fa5a-278e-6502c799a095@oracle.com> Message-ID: <9160e0df-84cc-a7a0-5475-db7e01892c41@gmail.com> Hello Roger, On 24/08/21 8:14 pm, Roger Riggs wrote: > Hi Jaikiran, > > Thanks for taking this on and getting it started. > > One use case of canonical storage is repeatable builds. > It would be useful to identify the uses in the JDK that would need to > be changed to use the new function. Surprisingly, the usage of the current "store" APIs within the JDK appears to be very minimal. I'm hoping I didn't miss them, but from what I see the Properties.store(...) which takes the Writer as a param isn't used in anywhere within source of the JDK. The Properties.store(...) which takes an OutputStream as a parameter gets used in the following few places: 1. jdk.internal.vm.VMSupport#serializePropertiesToByteArray - Looking at the implementation in this method and as the name suggests, the Properties is being written out a byte array. This method gets called from native code, from what I can see. I'll need a bit of help on this one to understand whether that usage in the native code would benefit from switching to the new API (when it is introduced) for reproducibility when it comes to this call in VMSupport#serializePropertiesToByteArray. 2. sun.net.www.MimeTable#saveAsProperties - This is a "protected" method and from what I could see, doesn't get called anywhere in the JDK code. Furthermore, This class resides in an internal package (sun.net.www) and although it implements the public java.net.FileNameMap interface, the "saveAsProperties" isn't a method exposed on that interface. So I think this existing code/method wouldn't need to be updated to use the new API. 3. sun.font.FcFontConfiguration#writeFcInfo - This method writes out a "cache file" which appears to be an internal implementation detail of the FcFontConfiguration. More specifically, the contents of this file apparently is "JDK Font Configuration", going by the comment it adds to that file. This file gets written out to the "user.home" directory and as far as I can see it, is only used/relevant to this FcFontConfiguration. In context of reproducibility and the new API, I think using that new API here could have a potential benefit of reproducibility on the same system. However, someone with more experience of this code would have to review if at all this reproducibility is desirable. These are the only references I could find in the JDK code (I didn't include test cases). One thing I do remember is the JDK build (through the make files) would have certain Java code it would call to do some build steps. Is there a easy way to find all such build related Java files within the JDK? I would like to see if there are any references/calls to this method from those build files. I am doing some searches myself, but knowing where to search will give me more confidence that I haven't missed out any. -Jaikiran From Alan.Bateman at oracle.com Wed Aug 25 11:03:02 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 Aug 2021 12:03:02 +0100 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <9160e0df-84cc-a7a0-5475-db7e01892c41@gmail.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <2484bdde-173a-fa5a-278e-6502c799a095@oracle.com> <9160e0df-84cc-a7a0-5475-db7e01892c41@gmail.com> Message-ID: <73f13d35-7ff4-8506-db5b-2df56ebc1790@oracle.com> On 25/08/2021 11:51, Jaikiran Pai wrote: > : > > 1. jdk.internal.vm.VMSupport#serializePropertiesToByteArray - Looking > at the implementation in this method and as the name suggests, the > Properties is being written out a byte array. This method gets called > from native code, from what I can see. I'll need a bit of help on this > one to understand whether that usage in the native code would benefit > from switching to the new API (when it is introduced) for > reproducibility when it comes to this call in > VMSupport#serializePropertiesToByteArray. This is the VM side of the attach mechanism. The API to look at is com.sun.tools.attach.VirtualMachine::getSystemProperties. When this method is invoked (by a tool) then response is a byte stream of the property list (8859-1 encoded). I wouldn't expect you should need to touch this one. -Alan From vlivanov at openjdk.java.net Wed Aug 25 11:25:37 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 25 Aug 2021 11:25:37 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading Message-ID: `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. Testing: tier1 - tier6 ------------- Commit messages: - Remove the assert - Introduce 2nd level MethodHandle.asType cache - keepsAlive logic Changes: https://git.openjdk.java.net/jdk/pull/5246/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5246&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8078641 Stats: 108 lines in 2 files changed: 87 ins; 3 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/5246.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5246/head:pull/5246 PR: https://git.openjdk.java.net/jdk/pull/5246 From magnus.ihse.bursie at oracle.com Wed Aug 25 12:03:05 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 25 Aug 2021 14:03:05 +0200 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <9160e0df-84cc-a7a0-5475-db7e01892c41@gmail.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <2484bdde-173a-fa5a-278e-6502c799a095@oracle.com> <9160e0df-84cc-a7a0-5475-db7e01892c41@gmail.com> Message-ID: Hi Jaikiran, I'm glad to see this issue finally getting some love and attention! :) I don't fully support those "inclinations" that say that the old API should not change. I think keeping the old random order of store() would mean a missed chance to do good, otherwise a lot of Java programs will never get reproducible output of property files. We do have a chance of helping the community, in a single stroke, to make lots of application (more) reproducible without any programmer effort. There is a growing community pushing for reproducible builds (see e.g. https://reproducible-builds.org). Java programs tend to have reproducibility issues due to several cases of non-determinism in the Java platform, and I really think we should try to rectify that. The specification for store() does not say anything about the order properties are written, so I think the implementation is free to change this to a deterministic order. As long as files written by an updated version of store() can be read by old versions (and vice versa) there will be no compatibility issue in Java programs. And since the old (current...) order is non-deterministic, it seems exceedingly unlikely that any external program depends on the order currently generated by store(). The problem is with the time stamp, which the spec states should be present. I understand why changing this might need a new method. But I think we should try to steer users to this new method. Otherwise it is likely not to be used by those who should use it (the programmers) to the detrimental effect of users who get properties file which change for no good reason. Having an "attractive" name is definitely part of that. The name should scream "use me as a first hand choice for storing properties to a file". I don't really get that feeling from storeCanonical(). > One thing I do remember is the JDK build (through the make files) > would have certain Java code it would call to do some build steps. Is > there a easy way to find all such build related Java files within the > JDK? I would like to see if there are any references/calls to this > method from those build files. I am doing some searches myself, but > knowing where to search will give me more confidence that I haven't > missed out any. The java buildtool sources are located in the "make" directory, more specifically in "make/jdk/src", "make/langtools/src" and "make/src" (yeah, I know -- a cleanup is way overdue). I did a quick search now but could not find any references to Properties.store(). I'm trying to remember if we create properties during the build... We have several instances where .properties files in the Java source code are converted to hard-coded classes (for performance), and other where .properties files are copied verbatim. Ah, right, they are "cleaned" beforehand. We used to do this by a Java program, but nowadays they are mangled by sed. I think replacing that sed script with a trivial Java program doing storeCanonical() would be on the list of things to do. I can assist with that, when you are starting to get your implementation done. We might also write something as part of the jlink process that gets embedded in the resulting jimage; not quite sure about that. You should find that code in the normal src/ codebase though. /Magnus From liangchenblue at gmail.com Wed Aug 25 12:05:50 2021 From: liangchenblue at gmail.com (-) Date: Wed, 25 Aug 2021 07:05:50 -0500 Subject: Implementing MethodHandleProxies#asInterfaceInstance with hidden classes In-Reply-To: <893757745.907387.1629886941949.JavaMail.zimbra@u-pem.fr> References: <893757745.907387.1629886941949.JavaMail.zimbra@u-pem.fr> Message-ID: Thanks Remi, I strongly agree. In fact, with the ability to implement multiple methods in an invoke proxy (presumably through passing a list of name and handle pairs, and the impl method descriptors are stored in handles' method types), we can allow implementing any number of interfaces (even ones with language-wise conflicting methods like String getValue() and Long getValue()) and perform better initialization-time verifications (compared to invocation handlers, where users often forget to implement object methods and the proxy breaks only when it is sent into a hash set) My current vision is a proxy factory method that takes a list of interfaces and a list of method implementations, each represented by a pair of name and method handle. However, I don't know well about native compilation, so I wonder if this structure would serve native optimization well, or if it has any other drawbacks. Please enlighten me. On Wed, Aug 25, 2021 at 5:22 AM Remi Forax wrote: > > ----- Original Message ----- > > From: "-" > > To: "Brian Goetz" , "core-libs-dev" > > Sent: Lundi 23 Ao?t 2021 08:34:17 > > Subject: Re: Implementing MethodHandleProxies#asInterfaceInstance with hidden classes > > > Thanks for the quick reply! > > > > The main drawback, API wise, with LMF is that it does not accept > > non-direct method handles [1], while the MHP is able accept any method > > handle, such as native ones from JEP 389 [2]. LMF also lacks the > > ability to restore a method handle from a wrapper instance. Using LMF > > also requires user discretion on which methods to implement, and the > > lookup's required privileges may change too. In general, MHP would be > > more runtime-oriented and transient compared to LMF. > > > > I am inclined toward a separate bytecode generation implementation for > > the improved MHP asInterfaceInstance, somewhat similar to what's in > > JEP 416's implementation [3]. The extra bridges for all compatible > > methods, accessors to backing method handle/interface, potential to > > expand to abstract classes, different hidden class modes would reduce > > the commonalities between the two implementations and make > > refactorings on LMF to support these MHP functionalities costly. > > In my opinion, what is missing is a java.lang.invoke.Proxy, the equivalent of java.lang.reflect.Proxy but using defineHiddenClass + a bootstrap method + method handles instead of the InvocationHandler + j.l.r.Method. With that, implementing java.lang.invoke.MethodHandleProxies on top of of java.lang.invoke.Proxy is just a matter of wiring. > > As you said, there is a need for a more dynamic version of the LambdaMetafactory. > I believe it should work with any interfaces not only functional interfaces. > This would avoid statically typed langages like Kotlin or Scala, or injection frameworks like Weld, Spring or Guice to generate a lot of proxy classes and it should be straightforward enough so static compilers like graal native image or Android d8 can generate the proxy classes at compile time to support "native" compilation (the same way lambdas are currently supported). > So we get best of both worlds, efficient dynamic proxies at runtime AND supports of "native" compilation. > > R?mi > > > > > [1] > > https://github.com/openjdk/jdk/blob/b690f29699180149d33b6a83de10697790587a87/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java#L141 > > [2] https://openjdk.java.net/jeps/389#The-C-linker > > [3] > > https://github.com/openjdk/jdk/blob/cff856f9df89293cbc8f2f1e977148cd6ece4f85/src/java.base/share/classes/jdk/internal/reflect/ClassByteBuilder.java > > > > > > On Sun, Aug 22, 2021 at 9:26 PM Brian Goetz wrote: > >> > >> This was an early attempt at the functionality provided by LambdaMetafactory. > >> It could probably be reimplemented on top of that, but probably could be > >> deprecated in favor of LMF as well. > >> > >> Sent from my iPad > >> > >> > On Aug 22, 2021, at 10:08 PM, liangchenblue at gmail.com wrote: > >> > > >> > ?Currently, java.lang.invoke.MethodHandleProxies#asInterfaceInstance [1] is > >> > implemented with java.lang.reflect.Proxy. After looking at its public API, > >> > including Javadoc, it seems that MethodHandleProxies would benefit from a > >> > hidden class implementation without changing its public API definition > >> > (including Javadocs). > >> > > >> > Recently, there is JEP 416 [2] for reimplementing reflection based on > >> > method handles. This implementation utilizes hidden classes with method > >> > handles passed in classdata and retrieved to condy, which allows generic > >> > method handles (beyond regular constable ones) to be optimized in method > >> > calls. Similarly, for MethodHandleProxies, hidden classes allow the > >> > implementations to detach from classloaders and be freely recyclable; they > >> > can use class data to store the adapted method handles (which can > >> > significantly speed up invocations); and it can allow it to support > >> > implementing single-abstract-method abstract classes in the future (as > >> > discussed in its Javadoc) as well, with only minor tweaks. > >> > > >> > Does this sound feasible? I want to ensure it is a good idea before any > >> > implementation is attempted. If there is any issue with this vision, please > >> > don't hesitate to point it out. Feel free to comment, too! If this looks > >> > good, I hope an issue can be created for it. > >> > > >> > Best > >> > > >> > [1] > >> > https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/invoke/MethodHandleProxies.html > > > > [2] https://openjdk.java.net/jeps/416 From magnus.ihse.bursie at oracle.com Wed Aug 25 12:24:01 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 25 Aug 2021 14:24:01 +0200 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <2484bdde-173a-fa5a-278e-6502c799a095@oracle.com> <9160e0df-84cc-a7a0-5475-db7e01892c41@gmail.com> Message-ID: <21db7af3-3689-e1ac-04a0-627530b4bf57@oracle.com> On 2021-08-25 14:03, Magnus Ihse Bursie wrote: > Hi Jaikiran, > > I'm glad to see this issue finally getting some love and attention! :) > > I don't fully support those "inclinations" that say that the old API > should not change. I think keeping the old random order of store() > would mean a missed chance to do good, otherwise a lot of Java > programs will never get reproducible output of property files. We do > have a chance of helping the community, in a single stroke, to make > lots of application (more) reproducible without any programmer effort. > There is a growing community pushing for reproducible builds (see e.g. > https://reproducible-builds.org). Java programs tend to have > reproducibility issues due to several cases of non-determinism in the > Java platform, and I really think we should try to rectify that. > > The specification for store() does not say anything about the order > properties are written, so I think the implementation is free to > change this to a deterministic order. As long as files written by an > updated version of store() can be read by old versions (and vice > versa) there will be no compatibility issue in Java programs. And > since the old (current...) order is non-deterministic, it seems > exceedingly unlikely that any external program depends on the order > currently generated by store(). > > The problem is with the time stamp, which the spec states should be > present. I understand why changing this might need a new method. This got me thinking a bit. If we are willing to change the spec slightly, we could use the standard `SOURCE_DATE_EPOCH` environment variable. Many tools support this already. The meaning of this variable is that, if present, tools that generate timestamps should use that value instead. [1] It seems unlikely that a user running Java with `SOURCE_DATE_EPOCH` should get upset if the behavior of Properties.store() changed. Without this variable, store() would generate timestamps as usual of the current time. /Magnus [1] https://reproducible-builds.org/docs/source-date-epoch/ > But I think we should try to steer users to this new method. Otherwise > it is likely not to be used by those who should use it (the > programmers) to the detrimental effect of users who get properties > file which change for no good reason. Having an "attractive" name is > definitely part of that. The name should scream "use me as a first > hand choice for storing properties to a file". I don't really get that > feeling from storeCanonical(). > >> One thing I do remember is the JDK build (through the make files) >> would have certain Java code it would call to do some build steps. Is >> there a easy way to find all such build related Java files within the >> JDK? I would like to see if there are any references/calls to this >> method from those build files. I am doing some searches myself, but >> knowing where to search will give me more confidence that I haven't >> missed out any. > > The java buildtool sources are located in the "make" directory, more > specifically in "make/jdk/src", "make/langtools/src" and "make/src" > (yeah, I know -- a cleanup is way overdue). I did a quick search now > but could not find any references to Properties.store(). > > I'm trying to remember if we create properties during the build... We > have several instances where .properties files in the Java source code > are converted to hard-coded classes (for performance), and other where > .properties files are copied verbatim. Ah, right, they are "cleaned" > beforehand. We used to do this by a Java program, but nowadays they > are mangled by sed. I think replacing that sed script with a trivial > Java program doing storeCanonical() would be on the list of things to > do. I can assist with that, when you are starting to get your > implementation done. > > We might also write something as part of the jlink process that gets > embedded in the resulting jimage; not quite sure about that. You > should find that code in the normal src/ codebase though. > > /Magnus From github.com+741251+turbanoff at openjdk.java.net Wed Aug 25 12:50:27 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 25 Aug 2021 12:50:27 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2] In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 08:29:57 GMT, Daniel Fuchs wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8272863: Replace usages of Collections.sort with List.sort call in public java modules >> replace Collections.sort without comparator too > > src/java.base/share/classes/java/net/URLPermission.java line 222: > >> 220: >> 221: List l = normalizeMethods(methods); >> 222: l.sort(null); > > I am not opposed to this change, but I find this is slightly more ugly than `Collections.sort(l)`; so I have to ask: Is there any noticeable benefit? Actually I agree with you. One more point is that List.sort(null) doesn't check at compile time that class implements `Comparable`. But Collections.sort have this check. I will revert last commit. @azvegint are you ok with that? ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From Alan.Bateman at oracle.com Wed Aug 25 12:51:55 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 Aug 2021 13:51:55 +0100 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> Message-ID: <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> On 24/08/2021 15:07, Jaikiran Pai wrote: > The java.util.Properties class allows the properties to be written out > to a stream or through a writer. In its current form, the > specification of these APIs state that a comment comprising of the > current date is always written out. The spec doesn't make any > guarantees about the order of the properties when they are written out. > > There have been requests asking to make these APIs more deterministic. > These requests, from what I have seen, mainly ask for: > > - A way to disable writing out the date comment > - A way to write out the properties in a deterministic and > reproducible way > > There have been discussions in the mailing list in the past which have > been captured in JDK-8231640[1]. In these discussions, there has been > an inclination to not touch the current existing API implementations > and instead introduce new API(s) to achieve the proposed use cases. > > Before starting off with an implementation, I wanted to try and get > some inputs on what the new API(s) would look like and what the scope > of such a work should be. Another possibility is to add an overload of store that adds a java.time.Instant argument for the timestamp. It could be specified as Instant.EPOCH where reproducibility is required. Magnus brings up the possibility of specifying that the store methods look for SOURCE_DATE_EPOCH. As it happens, someone tried that [1]. With a spec change and the correct implementation then it should be feasible option to explore. We touched on the ordering issue in the jdk-dev discussion in 2019. I think that can be changed to write in sorted key order without a spec change, although it could be a useful property to specify. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8272157 From azvegint at openjdk.java.net Wed Aug 25 13:36:23 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Wed, 25 Aug 2021 13:36:23 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2] In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 12:47:41 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/java/net/URLPermission.java line 222: >> >>> 220: >>> 221: List l = normalizeMethods(methods); >>> 222: l.sort(null); >> >> I am not opposed to this change, but I find this is slightly more ugly than `Collections.sort(l)`; so I have to ask: Is there any noticeable benefit? > > Actually I agree with you. > One more point is that List.sort(null) doesn't check at compile time that class implements `Comparable`. But Collections.sort have this check. > I will revert last commit. > @azvegint are you ok with that? No objections. ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From javalists at cbfiddle.com Wed Aug 25 13:40:31 2021 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 25 Aug 2021 06:40:31 -0700 Subject: JPackage and ask for microphone permissions broken on OSX... In-Reply-To: <54a933c5-c4a2-02bd-11f7-31250e59262d@oracle.com> References: <15D1DFF8-0D3D-4DBF-9607-C63010FB7F23@gmail.com> <54a933c5-c4a2-02bd-11f7-31250e59262d@oracle.com> Message-ID: > On Aug 24, 2021, at 6:52 AM, Andy Herrick wrote: > > One final thing to note, MacOS keeps track of what you have ever previously granted microphone permission to (and will never ask again) based on the mac package identifier (which defaults to the main class name), so I explicitly set this using a shell script with jpackage option "--mac-package-identifier audio-$1" option, so I can pass in different values and create a unique one each time. I?ve been wondering what you mean here. Are you saying that you routinely generate random package identifiers or is this a workaround that you use in special circumstances? Alan From mik3hall at gmail.com Wed Aug 25 13:47:07 2021 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 25 Aug 2021 08:47:07 -0500 Subject: JPackage and ask for microphone permissions broken on OSX... In-Reply-To: References: <15D1DFF8-0D3D-4DBF-9607-C63010FB7F23@gmail.com> <54a933c5-c4a2-02bd-11f7-31250e59262d@oracle.com> Message-ID: <5A738017-330B-4E23-81E8-8E12ACF34EFE@gmail.com> > On Aug 25, 2021, at 8:40 AM, Alan Snyder wrote: > > > >> On Aug 24, 2021, at 6:52 AM, Andy Herrick wrote: >> >> One final thing to note, MacOS keeps track of what you have ever previously granted microphone permission to (and will never ask again) based on the mac package identifier (which defaults to the main class name), so I explicitly set this using a shell script with jpackage option "--mac-package-identifier audio-$1" option, so I can pass in different values and create a unique one each time. > > I?ve been wondering what you mean here. > > Are you saying that you routinely generate random package identifiers or is this a workaround that you use in special circumstances? > > Alan > I believe the permission is granted to a bundle idenditifer. I think tccutil can be used to reset https://apple.stackexchange.com/questions/384317/how-do-i-reset-camera-and-microphone-permission-on-macos-mojave From github.com+741251+turbanoff at openjdk.java.net Wed Aug 25 13:55:50 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 25 Aug 2021 13:55:50 GMT Subject: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v3] In-Reply-To: References: Message-ID: <8nANT75G1bu4pd892DJuQUV-g2p7jm9m5jQb82EWjfs=.0452ad76-845c-49ed-b0f7-df6641ec2102@github.com> > Collections.sort is just a wrapper, so it is better to use an instance method directly. Andrey Turbanov 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. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5229/files - new: https://git.openjdk.java.net/jdk/pull/5229/files/d6dfc8bf..e31936a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5229&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5229&range=01-02 Stats: 21 lines in 10 files changed: 4 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/5229.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5229/head:pull/5229 PR: https://git.openjdk.java.net/jdk/pull/5229 From roger.riggs at oracle.com Wed Aug 25 14:06:09 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 25 Aug 2021 10:06:09 -0400 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> Message-ID: <087c9e51-e850-646e-b120-948279a0b905@oracle.com> Hi, For the occasional human reader of a property file, a deterministic order would make them easier to use as well.? The natural sort order of the keys as String would be suitable. I'd support changing the order written without changing the API. Load and other readers of property files have no expectation of an order; there is almost no compatibility risk. Providing an alternate timestamp (or no timestamp) would need a new method. An overload of store(...) would be consistent with current uses. To produce a compatible format, including a timezone, it would need to be either java.util.Date or java.time.ZonedDateTime. (I'm not a fan of system properties that change API behavior). Regards, Roger On 8/25/21 8:51 AM, Alan Bateman wrote: > On 24/08/2021 15:07, Jaikiran Pai wrote: >> The java.util.Properties class allows the properties to be written >> out to a stream or through a writer. In its current form, the >> specification of these APIs state that a comment comprising of the >> current date is always written out. The spec doesn't make any >> guarantees about the order of the properties when they are written out. >> >> There have been requests asking to make these APIs more >> deterministic. These requests, from what I have seen, mainly ask for: >> >> - A way to disable writing out the date comment >> - A way to write out the properties in a deterministic and >> reproducible way >> >> There have been discussions in the mailing list in the past which >> have been captured in JDK-8231640[1]. In these discussions, there has >> been an inclination to not touch the current existing API >> implementations and instead introduce new API(s) to achieve the >> proposed use cases. >> >> Before starting off with an implementation, I wanted to try and get >> some inputs on what the new API(s) would look like and what the scope >> of such a work should be. > > Another possibility is to add an overload of store that adds a > java.time.Instant argument for the timestamp. It could be specified as > Instant.EPOCH where reproducibility is required. > > Magnus brings up the possibility of specifying that the store methods > look for SOURCE_DATE_EPOCH. As it happens, someone tried that [1]. > With a spec change and the correct implementation then it should be > feasible option to explore. > > We touched on the ordering issue in the jdk-dev discussion in 2019. I > think that can be changed to write in sorted key order without a spec > change, although it could be a useful property to specify. > > -Alan > > [1] https://bugs.openjdk.java.net/browse/JDK-8272157 From daniel.fuchs at oracle.com Wed Aug 25 14:26:00 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 25 Aug 2021 15:26:00 +0100 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <087c9e51-e850-646e-b120-948279a0b905@oracle.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <087c9e51-e850-646e-b120-948279a0b905@oracle.com> Message-ID: <9abc3ba4-e752-a70a-65e3-755cc05013b9@oracle.com> Hi, Not all properties file might benefit from being sorted in key ordering. Think for instance about the logging.properties file - where you would certainly want to keep the original ordering. That said - we rarely store() a logging properties file, and if we stored it, key might appear in random order anyway (due to HashMap hashing) - so maybe that's OK after all... As long as the build doesn't fiddle with these... :-) cheers, -- daniel On 25/08/2021 15:06, Roger Riggs wrote: > Hi, > > For the occasional human reader of a property file, a deterministic > order would make them > easier to use as well.? The natural sort order of the keys as String > would be suitable. > > I'd support changing the order written without changing the API. Load > and other readers > of property files have no expectation of an order; there is almost no > compatibility risk. > > Providing an alternate timestamp (or no timestamp) would need a new method. > An overload of store(...) would be consistent with current uses. > To produce a compatible format, including a timezone, it would need to > be either > java.util.Date or java.time.ZonedDateTime. > > (I'm not a fan of system properties that change API behavior). > > Regards, Roger > > From jai.forums2013 at gmail.com Wed Aug 25 14:34:13 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 25 Aug 2021 20:04:13 +0530 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <2484bdde-173a-fa5a-278e-6502c799a095@oracle.com> <9160e0df-84cc-a7a0-5475-db7e01892c41@gmail.com> Message-ID: <757c55d2-f346-98a4-3435-3f2da188a142@gmail.com> On 25/08/21 5:33 pm, Magnus Ihse Bursie wrote: > ... > > The problem is with the time stamp, which the spec states should be > present. I understand why changing this might need a new method. But I > think we should try to steer users to this new method. Otherwise it is > likely not to be used by those who should use it (the programmers) to > the detrimental effect of users who get properties file which change > for no good reason. Having an "attractive" name is definitely part of > that. The name should scream "use me as a first hand choice for > storing properties to a file". I don't really get that feeling from > storeCanonical(). > I'm not saying we should do this, but one other way to scream, is to deprecate (but not for removal) the old "store" APIs and point the users to the new ones (if we introduce them). Similar to what "save" API in that same class currently does. -Jaikiran From andy.herrick at oracle.com Wed Aug 25 14:35:03 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 25 Aug 2021 10:35:03 -0400 Subject: [External] : Re: JPackage and ask for microphone permissions broken on OSX... In-Reply-To: References: <15D1DFF8-0D3D-4DBF-9607-C63010FB7F23@gmail.com> <54a933c5-c4a2-02bd-11f7-31250e59262d@oracle.com> Message-ID: <71611983-1d6a-6d5c-b87f-16e98d1fe303@oracle.com> On 8/25/2021 9:40 AM, Alan Snyder wrote: > > >> On Aug 24, 2021, at 6:52 AM, Andy Herrick > > wrote: >> >> One final thing to note, MacOS keeps track of what you have ever >> previously granted microphone permission to (and will never ask >> again) based on the mac package identifier (which defaults to the >> main class name), so I explicitly set this using a shell script with >> jpackage option "--mac-package-identifier audio-$1" option, so I can >> pass in different values and create a unique one each time. > > I?ve been wondering what you mean here. > > Are you saying that you routinely generate random package identifiers > or is this a workaround that you use in special circumstances? > > ? Alan > no - I am just generating unique package identifiers to test this microphone permission dialog, /Andy From rriggs at openjdk.java.net Wed Aug 25 14:46:26 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 25 Aug 2021 14:46:26 GMT Subject: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. When instant seconds and zone co-exist in parsed data, instant seconds was not resolved correctly from them. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5225 From javalists at cbfiddle.com Wed Aug 25 14:49:07 2021 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 25 Aug 2021 07:49:07 -0700 Subject: [External] : Re: JPackage and ask for microphone permissions broken on OSX... In-Reply-To: <71611983-1d6a-6d5c-b87f-16e98d1fe303@oracle.com> References: <15D1DFF8-0D3D-4DBF-9607-C63010FB7F23@gmail.com> <54a933c5-c4a2-02bd-11f7-31250e59262d@oracle.com> <71611983-1d6a-6d5c-b87f-16e98d1fe303@oracle.com> Message-ID: Good to hear! > On Aug 25, 2021, at 7:35 AM, Andy Herrick wrote: > > > On 8/25/2021 9:40 AM, Alan Snyder wrote: >> >> >>> On Aug 24, 2021, at 6:52 AM, Andy Herrick > wrote: >>> >>> One final thing to note, MacOS keeps track of what you have ever previously granted microphone permission to (and will never ask again) based on the mac package identifier (which defaults to the main class name), so I explicitly set this using a shell script with jpackage option "--mac-package-identifier audio-$1" option, so I can pass in different values and create a unique one each time. >> >> I?ve been wondering what you mean here. >> >> Are you saying that you routinely generate random package identifiers or is this a workaround that you use in special circumstances? >> >> Alan >> > no - I am just generating unique package identifiers to test this microphone permission dialog, > > /Andy > From jai.forums2013 at gmail.com Wed Aug 25 14:57:58 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 25 Aug 2021 20:27:58 +0530 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> Message-ID: <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> On 25/08/21 6:21 pm, Alan Bateman wrote: > On 24/08/2021 15:07, Jaikiran Pai wrote: >> The java.util.Properties class allows the properties to be written >> out to a stream or through a writer. In its current form, the >> specification of these APIs state that a comment comprising of the >> current date is always written out. The spec doesn't make any >> guarantees about the order of the properties when they are written out. >> >> There have been requests asking to make these APIs more >> deterministic. These requests, from what I have seen, mainly ask for: >> >> - A way to disable writing out the date comment >> - A way to write out the properties in a deterministic and >> reproducible way >> >> There have been discussions in the mailing list in the past which >> have been captured in JDK-8231640[1]. In these discussions, there has >> been an inclination to not touch the current existing API >> implementations and instead introduce new API(s) to achieve the >> proposed use cases. >> >> Before starting off with an implementation, I wanted to try and get >> some inputs on what the new API(s) would look like and what the scope >> of such a work should be. > > Another possibility is to add an overload of store that adds a > java.time.Instant argument for the timestamp. It could be specified as > Instant.EPOCH where reproducibility is required. > > Magnus brings up the possibility of specifying that the store methods > look for SOURCE_DATE_EPOCH. As it happens, someone tried that [1]. > With a spec change and the correct implementation then it should be > feasible option to explore. Introducing an overloaded "store" which takes the timestamp or implicitly using the SOURCE_DATE_EPOCH environment variable would mean that the Properties.store(...) APIs will continue to always write out a Date representation into the outputstream. That effectively means that there will continue to be no way to disable writing out a (date) comment. More specifically, even if a user doesn't explicitly specify a comment, we would end up writing a default (date) comment. Do we want that? Or while we are doing these changes, should we introduce this ability of disabling writing out these date comments by default? That, IMO, can only be done by introducing new APIs instead of trying to slightly change the spec and the implementation of the current "store" APIs. After all, if any callers do want a date (and a reproducible one at that), they could always do so by passing that as a value for the "comment" parameter of these (new) "storeXXX" APIs. > > We touched on the ordering issue in the jdk-dev discussion in 2019. I > think that can be changed to write in sorted key order without a spec > change, although it could be a useful property to specify. I think, based on the discussion/inputs so far, there's clarity on this part that changing the current implementation of "store" to write out the property keys in a specific order would be a good thing, irrespective of whether or not we introduce new APIs to deal with the date comment aspect. Daniel had an interesting point of logging.properties file and the order that would need to be maintained for those, but like he noted in that same reply, I don't think that's a use case to consider for the "store" APIs, since they never previously supported/guaranteed that use case. -Jaikiran From iignatyev at openjdk.java.net Wed Aug 25 15:55:27 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 25 Aug 2021 15:55:27 GMT Subject: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1 In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote: > See the bug report for more details. I would appreciate if people with their corporate testing systems would run this through their systems to avoid surprises. (ping @RealCLanger, @iignatev). the testing in our infra returned green. ------------- PR: https://git.openjdk.java.net/jdk/pull/5189 From iignatyev at openjdk.java.net Wed Aug 25 16:01:33 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 25 Aug 2021 16:01:33 GMT Subject: RFR: 8272836: Limit run time for java/lang/invoke/LFCaching tests In-Reply-To: References: Message-ID: <5oBUCeJ76esS1Ennk5DZP3Muk0S61dtHyNXArVdEi9U=.8d7e4157-50fe-43f1-ac1b-fbd0064e1a1b@github.com> On Mon, 23 Aug 2021 11:33:35 GMT, Aleksey Shipilev wrote: > See the RFE for discussion. > > Current PR improves the test time like this: > > > $ make run-test TEST=java/lang/invoke/LFCaching/ > > # Before > real 3m51.608s > user 5m21.612s > sys 0m5.391s > > # After > real 1m13.606s > user 2m26.827s > sys 0m4.761s the reason we tie time-budget in this test (and other similar stress tests) to timeout is to give a test chance to do actual testing in slow configurations (which will set higher timeout factor), for example, runs w/ -Xcomp on debug builds. if we use hardcoded value, the test might spend (almost) all its allocated time to just init and wouldn't perform any testing. ] so instead of using the hardcode limit, I'd prefer to adjust the multiplication, `0.25` will give you the same 60s w/ current default timeout factor. -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/5214 From vromero at openjdk.java.net Wed Aug 25 16:08:25 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 25 Aug 2021 16:08:25 GMT Subject: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v2] In-Reply-To: References: Message-ID: <7x9mWjmW3tODdIUua7SC1NwmHqSQdaGzOVnbtRsiukE=.d1f3483e-22a8-443d-b875-f72d62356142@github.com> On Wed, 25 Aug 2021 02:17:12 GMT, Mandy Chung wrote: >> Hi Mandy, I have changed the implementation of the method to explicitly require all arguments but lookup to be non-null as suggested by Brian. I have also covered, I think, all the missing test cases in test `ObjectMethodsTest`, thanks for your comments. > > I think you meant requiring `names` to be non-null but `lookup` may still be null. It's okay to change the spec to require `names` to be non-null. > > Probably better to mention in `@param names` that `names` is ignored when the `methodName` is `equals` or `hashCode`. no I think I prefer to force names to be non-null all the time, that way we offer a more consistent interface to users. They don't have to remember what case was for which names can be null. ------------- PR: https://git.openjdk.java.net/jdk/pull/5226 From iris at openjdk.java.net Wed Aug 25 16:28:23 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 25 Aug 2021 16:28:23 GMT Subject: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. When instant seconds and zone co-exist in parsed data, instant seconds was not resolved correctly from them. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5225 From shade at openjdk.java.net Wed Aug 25 16:31:50 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 25 Aug 2021 16:31:50 GMT Subject: RFR: 8272836: Limit run time for java/lang/invoke/LFCaching tests [v2] In-Reply-To: References: Message-ID: <8tGUp0hFPKxQr7sHGKSndYgxboTfRtz_1poU0EFRGkA=.93700f0f-a25a-418b-9ec2-a0b7c3fc4456@github.com> > See the RFE for discussion. > > Current PR improves the test time like this: > > > $ make run-test TEST=java/lang/invoke/LFCaching/ > > # Before > real 3m51.608s > user 5m21.612s > sys 0m5.391s > > # After > real 1m13.606s > user 2m26.827s > sys 0m4.761s Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Make the timeout depend on global timeout with lower multiplier - Merge branch 'master' into JDK-8272836-perf-test-lfcaching - 8272836: Optimize run time for java/lang/invoke/LFCaching tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5214/files - new: https://git.openjdk.java.net/jdk/pull/5214/files/85e6287f..f694626a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5214&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5214&range=00-01 Stats: 6245 lines in 278 files changed: 4320 ins; 1044 del; 881 mod Patch: https://git.openjdk.java.net/jdk/pull/5214.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5214/head:pull/5214 PR: https://git.openjdk.java.net/jdk/pull/5214 From shade at openjdk.java.net Wed Aug 25 16:31:50 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 25 Aug 2021 16:31:50 GMT Subject: RFR: 8272836: Limit run time for java/lang/invoke/LFCaching tests In-Reply-To: <5oBUCeJ76esS1Ennk5DZP3Muk0S61dtHyNXArVdEi9U=.8d7e4157-50fe-43f1-ac1b-fbd0064e1a1b@github.com> References: <5oBUCeJ76esS1Ennk5DZP3Muk0S61dtHyNXArVdEi9U=.8d7e4157-50fe-43f1-ac1b-fbd0064e1a1b@github.com> Message-ID: <-4-pXKXxqjA6Qv5YTZE7t7yQsE5-iAzJQFBQyNu_-84=.88987ff6-71af-46d1-9f75-b11ecd95505e@github.com> On Wed, 25 Aug 2021 15:56:39 GMT, Igor Ignatyev wrote: > so instead of using the hardcode limit, I'd prefer to adjust the multiplication, `0.25` will give you the same 60s w/ current default timeout factor. Oh, okay, good point. I changed multiplier from `0.9` to `0.2`. That works out to ~75 seconds per actual test, and 90 seconds for entire run: ----------messages:(5/416)---------- command: main -XX:ReservedCodeCacheSize=128m LFSingleThreadCachingTest reason: User specified action: run main/othervm -XX:ReservedCodeCacheSize=128m LFSingleThreadCachingTest Mode: othervm [/othervm specified] Additional options from @modules: --add-modules java.base,java.management --add-opens java.base/java.lang.ref=ALL-UNNAMED --add-opens java.base/java.lang.invoke=ALL-UNNAMED elapsed time (seconds): 76.789 ... real 1m38.629s user 2m55.333s sys 0m5.318s ------------- PR: https://git.openjdk.java.net/jdk/pull/5214 From lancea at openjdk.java.net Wed Aug 25 17:10:27 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 25 Aug 2021 17:10:27 GMT Subject: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. When instant seconds and zone co-exist in parsed data, instant seconds was not resolved correctly from them. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5225 From iignatyev at openjdk.java.net Wed Aug 25 17:38:26 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 25 Aug 2021 17:38:26 GMT Subject: RFR: 8272836: Limit run time for java/lang/invoke/LFCaching tests [v2] In-Reply-To: <8tGUp0hFPKxQr7sHGKSndYgxboTfRtz_1poU0EFRGkA=.93700f0f-a25a-418b-9ec2-a0b7c3fc4456@github.com> References: <8tGUp0hFPKxQr7sHGKSndYgxboTfRtz_1poU0EFRGkA=.93700f0f-a25a-418b-9ec2-a0b7c3fc4456@github.com> Message-ID: <6OhME1kGgdN2XWAPeOb2qhVHggN6Q_amli4hYCAxMmo=.21548f02-33e8-4fb1-a108-a6c53f9aa439@github.com> On Wed, 25 Aug 2021 16:31:50 GMT, Aleksey Shipilev wrote: >> See the RFE for discussion. >> >> Current PR improves the test time like this: >> >> >> $ make run-test TEST=java/lang/invoke/LFCaching/ >> >> # Before >> real 3m51.608s >> user 5m21.612s >> sys 0m5.391s >> >> # After >> real 1m13.606s >> user 2m26.827s >> sys 0m4.761s > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Make the timeout depend on global timeout with lower multiplier > - Merge branch 'master' into JDK-8272836-perf-test-lfcaching > - 8272836: Optimize run time for java/lang/invoke/LFCaching tests LGTM ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5214 From github.com+5709644+fdesu at openjdk.java.net Wed Aug 25 17:53:52 2021 From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko) Date: Wed, 25 Aug 2021 17:53:52 GMT Subject: RFR: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError [v4] In-Reply-To: References: Message-ID: > Change #3294 helps to avoid `AnnotaionFormatException` in `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. While it fixes the case with e.g. `Runnable` that generates the synthetic method without parameters, validation still fails on synthetic methods that have parameters e.g. `Function`, `BiFunction`, etc. > > This change removes the restriction on parameters count to be zero i.e. lambdas with parameters > would be skipped from validation. Sergei Ustimenko 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 two additional commits since the last revision: - 8268788: Filter out synthetic methods from the member methods computation - 8268788: Annotations with lambda expressions can still cause AnnotationFormatError ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4642/files - new: https://git.openjdk.java.net/jdk/pull/4642/files/1f5fd0a5..9cf2f0c1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4642&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4642&range=02-03 Stats: 8852 lines in 417 files changed: 5797 ins; 1742 del; 1313 mod Patch: https://git.openjdk.java.net/jdk/pull/4642.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4642/head:pull/4642 PR: https://git.openjdk.java.net/jdk/pull/4642 From github.com+5709644+fdesu at openjdk.java.net Wed Aug 25 18:00:27 2021 From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko) Date: Wed, 25 Aug 2021 18:00:27 GMT Subject: RFR: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError [v4] In-Reply-To: References: Message-ID: <9FhG4F8nchScunRvw79gZ_wNlsjyaQ3T1gt3Sk6b9Rg=.e7aa3216-1d7b-4931-a100-b41829daa4a3@github.com> On Wed, 25 Aug 2021 17:53:52 GMT, Sergei Ustimenko wrote: >> Change #3294 helps to avoid `AnnotaionFormatException` in `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. While it fixes the case with e.g. `Runnable` that generates the synthetic method without parameters, validation still fails on synthetic methods that have parameters e.g. `Function`, `BiFunction`, etc. >> >> This change removes the restriction on parameters count to be zero i.e. lambdas with parameters >> would be skipped from validation. > > Sergei Ustimenko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - 8268788: Filter out synthetic methods from the member methods computation > - 8268788: Annotations with lambda expressions can still cause AnnotationFormatError Hi, I've reworked code in few places a bit. As we skip `synthetic` methods in couple of places in AnnotationInvocationHandler anyway: 1. In `equalsImpl` while going method-by-method, comparing them 2. In `validateAnnotationMethods` These two also work together to store methods in the `memberMethods` field. Then I though it makes sense to skip adding synthetic methods to the field altogether. What do you think, does it makes sense? Thanks for taking a look! ------------- PR: https://git.openjdk.java.net/jdk/pull/4642 From mandy.chung at oracle.com Wed Aug 25 20:45:38 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 Aug 2021 16:45:38 -0400 Subject: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v2] In-Reply-To: <7x9mWjmW3tODdIUua7SC1NwmHqSQdaGzOVnbtRsiukE=.d1f3483e-22a8-443d-b875-f72d62356142@github.com> References: <7x9mWjmW3tODdIUua7SC1NwmHqSQdaGzOVnbtRsiukE=.d1f3483e-22a8-443d-b875-f72d62356142@github.com> Message-ID: <22820d37-664b-fa86-70f7-89c0c662106d@oracle.com> On 8/25/21 12:08 PM, Vicente Romero wrote: > On Wed, 25 Aug 2021 02:17:12 GMT, Mandy Chung wrote: > >>> Hi Mandy, I have changed the implementation of the method to explicitly require all arguments but lookup to be non-null as suggested by Brian. I have also covered, I think, all the missing test cases in test `ObjectMethodsTest`, thanks for your comments. >> I think you meant requiring `names` to be non-null but `lookup` may still be null. It's okay to change the spec to require `names` to be non-null. >> >> Probably better to mention in `@param names` that `names` is ignored when the `methodName` is `equals` or `hashCode`. > no I think I prefer to force names to be non-null all the time, that way we offer a more consistent interface to users. They don't have to remember what case was for which names can be null. What I meant is to require it to be non-null but the spec should also mention `names` parameter is ignored if the method name is `equals` and `hashCode`. Mandy > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5226 From sviswanathan at openjdk.java.net Wed Aug 25 20:51:28 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 25 Aug 2021 20:51:28 GMT Subject: RFR: 8272861: Add a micro benchmark for vector api [v3] In-Reply-To: <2RbnsJk-_7EXYWD0Vun5aJQn18sQUudSPOG3dxNma-U=.1665ff7a-5018-4b9f-8420-5555f64ca308@github.com> References: <2RbnsJk-_7EXYWD0Vun5aJQn18sQUudSPOG3dxNma-U=.1665ff7a-5018-4b9f-8420-5555f64ca308@github.com> Message-ID: On Tue, 24 Aug 2021 20:49:52 GMT, Sandhya Viswanathan wrote: >> This pull request adds a micro benchmark for Vector API. >> The Black Scholes algorithm is implemented with and without Vector API. >> We see about ~6x gain with Vector API for this micro benchmark using 256 bit vectors. > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Make constants as static final @PaulSandoz @ericcaspole Looking forward to your review and approval for this vector api micro benchmark. ------------- PR: https://git.openjdk.java.net/jdk/pull/5234 From rriggs at openjdk.java.net Wed Aug 25 21:45:57 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 25 Aug 2021 21:45:57 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v2] In-Reply-To: References: Message-ID: <2liD8jolzM4UiSvM1PhfJOtAlfPeuX9omlNiB3U10xI=.91f61862-a828-477e-ba2f-c37feef4826c@github.com> > The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM > as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . > > There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. > The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Revised to use a native program for sleep ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5239/files - new: https://git.openjdk.java.net/jdk/pull/5239/files/0b960107..7ab6c934 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5239&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5239&range=00-01 Stats: 111 lines in 3 files changed: 58 ins; 49 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5239.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5239/head:pull/5239 PR: https://git.openjdk.java.net/jdk/pull/5239 From javalists at cbfiddle.com Wed Aug 25 22:12:33 2021 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 25 Aug 2021 15:12:33 -0700 Subject: what does the spec say about file paths that are too long? In-Reply-To: References: <7CBCF03A-AEBA-46EE-BCBD-4ED9D1C97450@cbfiddle.com> Message-ID: <81398B70-EC5E-4E06-9790-85CE56199591@cbfiddle.com> Lacking any new data, I guess it is fair to assume that there is no specification for the behavior of methods that use file paths that are too long, and presumably no tests, either. So the next question is whether there should be such a specification. I think there should be a specification because I would like to be able to use file paths without having to defend against possible unwanted bad effects when the paths are too long. By analogy, more like array indexing than integer overflow. If there is to be a specification, should it be at the method level? That would be best, I think. For example, the Path.toAbsolutePath() method in principle could return a path that is ?too long? even if the original path is fine. Should an exception be raised at that point or only when the absolute path is used? This distinction was not possible with File, but it may be possible with Path, given the association with file providers. (Regarding the comment from Alan B., is it the case that file paths are necessarily resolved before use? That would surprise me.) Also, there is the possibility of creating a more specific exception to be thrown when paths that are too long are used. A case can be made for distinguishing this error from general IOExceptions because it is repeatable and explainable, unlike the general IOException. Thoughts? Alan > On Aug 20, 2021, at 7:05 AM, Alan Snyder wrote: > > Where did I say that I was seeing silent truncation? > > My question is about the specification. > > I want to know if I should write code that defends against silent truncation. I should be writing code based on the specification, not what I observe in a test program on a particular platform. > > I?m pleased that you believe an exception should be thrown, but is that behavior mandated in the specification and tested by the JCK? > > Alan > > >> On Aug 20, 2021, at 2:58 AM, Alan Bateman wrote: >> >> Where are you seeing "silent truncation"? You should see an I/O exception if you attempt to access a file and the resolved file path is too long. >> >> -Alan >> > From vlivanov at openjdk.java.net Wed Aug 25 22:13:37 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 25 Aug 2021 22:13:37 GMT Subject: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation Message-ID: Get rid of WeakReference-based logic in DirectMethodHandle::checkInitialized() and reimplement it with `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`. The key observation is that `Unsafe::ensureClassInitialized()` does not block the initializing thread. Also, removed `Unsafe::shouldBeInitialized()` in `DMH::shouldBeInitialized(MemberName)` to save on calling into the VM. `Unsafe::ensureClassInitialized()` already has a fast-path check which checks whether the class is fully initialized or not. Testing: tier1 - tier6 ------------- Commit messages: - Remove WeakReference-based logic Changes: https://git.openjdk.java.net/jdk/pull/5258/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5258&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273000 Stats: 35 lines in 1 file changed: 0 ins; 32 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5258.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5258/head:pull/5258 PR: https://git.openjdk.java.net/jdk/pull/5258 From redestad at openjdk.java.net Wed Aug 25 22:28:26 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 25 Aug 2021 22:28:26 GMT Subject: RFR: 8272836: Limit run time for java/lang/invoke/LFCaching tests [v2] In-Reply-To: <8tGUp0hFPKxQr7sHGKSndYgxboTfRtz_1poU0EFRGkA=.93700f0f-a25a-418b-9ec2-a0b7c3fc4456@github.com> References: <8tGUp0hFPKxQr7sHGKSndYgxboTfRtz_1poU0EFRGkA=.93700f0f-a25a-418b-9ec2-a0b7c3fc4456@github.com> Message-ID: On Wed, 25 Aug 2021 16:31:50 GMT, Aleksey Shipilev wrote: >> See the RFE for discussion. >> >> Current PR improves the test time like this: >> >> >> $ make run-test TEST=java/lang/invoke/LFCaching/ >> >> # Before >> real 3m51.608s >> user 5m21.612s >> sys 0m5.391s >> >> # After >> real 1m13.606s >> user 2m26.827s >> sys 0m4.761s > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Make the timeout depend on global timeout with lower multiplier > - Merge branch 'master' into JDK-8272836-perf-test-lfcaching > - 8272836: Optimize run time for java/lang/invoke/LFCaching tests Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5214 From ecki at zusammenkunft.net Wed Aug 25 23:24:23 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 25 Aug 2021 23:24:23 +0000 Subject: what does the spec say about file paths that are too long? In-Reply-To: <81398B70-EC5E-4E06-9790-85CE56199591@cbfiddle.com> References: <7CBCF03A-AEBA-46EE-BCBD-4ED9D1C97450@cbfiddle.com> <81398B70-EC5E-4E06-9790-85CE56199591@cbfiddle.com> Message-ID: I think what constitutes a ?too long path? is highly environment and data dependent. For some OS it depends on configuration, version, filesystem type, mount structure, encoding, canonicalisation and API used. Java would have a really hard time to codify this all. So the current solution ?try the native API and report errors? sounds like the only really useable option - not to mention it is also safe (you get an error no crash). There are some unfortunate problems like OS where the gui limits more like the OS (Explorer) or where one path type (UNC or DOS-Short or relative) can create longer path than later readable, but basically for them it?s also hard for Java to predict and forbid them (especially if used intentionally). What could be done is to document this, document which functions actually use OS APIs and possibly and which Path And Filesystem API does or does not. And hopefully the IOException and native error Handling can be Unified and improved (for example Expose Errno/HERR return codes in IOException attribute which avoids to parse (localized error messages). It?s a bit annoying but even if you want to handle it better: there is not much you can do if you have such a Path constructed. Limit inputs and install dirs and not use user provided names if your systems should be reliable. -- https://Bernd.eckenfels.net ________________________________ From: core-libs-dev on behalf of Alan Snyder Sent: Thursday, August 26, 2021 12:12:33 AM To: core-libs-dev Subject: Re: what does the spec say about file paths that are too long? Lacking any new data, I guess it is fair to assume that there is no specification for the behavior of methods that use file paths that are too long, and presumably no tests, either. So the next question is whether there should be such a specification. I think there should be a specification because I would like to be able to use file paths without having to defend against possible unwanted bad effects when the paths are too long. By analogy, more like array indexing than integer overflow. If there is to be a specification, should it be at the method level? That would be best, I think. For example, the Path.toAbsolutePath() method in principle could return a path that is ?too long? even if the original path is fine. Should an exception be raised at that point or only when the absolute path is used? This distinction was not possible with File, but it may be possible with Path, given the association with file providers. (Regarding the comment from Alan B., is it the case that file paths are necessarily resolved before use? That would surprise me.) Also, there is the possibility of creating a more specific exception to be thrown when paths that are too long are used. A case can be made for distinguishing this error from general IOExceptions because it is repeatable and explainable, unlike the general IOException. Thoughts? Alan > On Aug 20, 2021, at 7:05 AM, Alan Snyder wrote: > > Where did I say that I was seeing silent truncation? > > My question is about the specification. > > I want to know if I should write code that defends against silent truncation. I should be writing code based on the specification, not what I observe in a test program on a particular platform. > > I?m pleased that you believe an exception should be thrown, but is that behavior mandated in the specification and tested by the JCK? > > Alan > > >> On Aug 20, 2021, at 2:58 AM, Alan Bateman wrote: >> >> Where are you seeing "silent truncation"? You should see an I/O exception if you attempt to access a file and the resolved file path is too long. >> >> -Alan >> > From vicente.romero at oracle.com Thu Aug 26 02:33:31 2021 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 25 Aug 2021 22:33:31 -0400 Subject: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v2] In-Reply-To: <22820d37-664b-fa86-70f7-89c0c662106d@oracle.com> References: <7x9mWjmW3tODdIUua7SC1NwmHqSQdaGzOVnbtRsiukE=.d1f3483e-22a8-443d-b875-f72d62356142@github.com> <22820d37-664b-fa86-70f7-89c0c662106d@oracle.com> Message-ID: <82c5ee5c-ca53-4a58-2216-78403a426e7f@oracle.com> On 8/25/21 4:45 PM, Mandy Chung wrote: > > > On 8/25/21 12:08 PM, Vicente Romero wrote: >> On Wed, 25 Aug 2021 02:17:12 GMT, Mandy Chung wrote: >> >>>> Hi Mandy, I have changed the implementation of the method to explicitly require all arguments but lookup to be non-null as suggested by Brian. I have also covered, I think, all the missing test cases in test `ObjectMethodsTest`, thanks for your comments. >>> I think you meant requiring `names` to be non-null but `lookup` may still be null. It's okay to change the spec to require `names` to be non-null. >>> >>> Probably better to mention in `@param names` that `names` is ignored when the `methodName` is `equals` or `hashCode`. >> no I think I prefer to force names to be non-null all the time, that way we offer a more consistent interface to users. They don't have to remember what case was for which names can be null. > > What I meant is to require it to be non-null but the spec should also > mention `names` parameter is ignored if the method name is `equals` > and `hashCode`. > > Mandy I see, I have updated the PR, thanks for your comments > >> ------------- >> >> PR:https://git.openjdk.java.net/jdk/pull/5226 > Vicente From vromero at openjdk.java.net Thu Aug 26 02:36:47 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 26 Aug 2021 02:36:47 GMT Subject: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v3] In-Reply-To: References: Message-ID: <4kDnwVGaxMk25dGRb2-wDyT6oeafNFiJoVXTKudTh5E=.082451de-1c6d-4651-92ae-532f15768c2e@github.com> > Please review this simple PR along with the associated CSR. The PR is basically adding a line the the specification of method `java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a NPE will be thrown. > > TIA > > link to the [CSR](https://bugs.openjdk.java.net/browse/JDK-8272852) Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: clarifying that the names parameter is ignored in some cases ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5226/files - new: https://git.openjdk.java.net/jdk/pull/5226/files/89086ca1..102cd1aa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5226&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5226&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5226.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5226/head:pull/5226 PR: https://git.openjdk.java.net/jdk/pull/5226 From dholmes at openjdk.java.net Thu Aug 26 02:51:24 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 26 Aug 2021 02:51:24 GMT Subject: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation In-Reply-To: References: Message-ID: <-FLHC8ydZskLXEf3s0VJdJVnw5WiRy_u2qby6sSg3FU=.0187c469-8d75-48e6-a408-9b51a84f1f10@github.com> On Wed, 25 Aug 2021 22:05:24 GMT, Vladimir Ivanov wrote: > The key observation is that `Unsafe::ensureClassInitialized()` does not block the initializing thread. I'm unclear exactly what that statement is meant to indicate. The thread actually running "clinit" does not block due to the initialization process, but will block if the class initialization code blocks. If the class is not initialized and you are racing with another thread doing the initialization then you may block until that initialization is complete. ------------- PR: https://git.openjdk.java.net/jdk/pull/5258 From iklam at openjdk.java.net Thu Aug 26 06:43:28 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 26 Aug 2021 06:43:28 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v2] In-Reply-To: <2liD8jolzM4UiSvM1PhfJOtAlfPeuX9omlNiB3U10xI=.91f61862-a828-477e-ba2f-c37feef4826c@github.com> References: <2liD8jolzM4UiSvM1PhfJOtAlfPeuX9omlNiB3U10xI=.91f61862-a828-477e-ba2f-c37feef4826c@github.com> Message-ID: On Wed, 25 Aug 2021 21:45:57 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . >> >> There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. >> The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revised to use a native program for sleep LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5239 From shade at openjdk.java.net Thu Aug 26 06:54:33 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 26 Aug 2021 06:54:33 GMT Subject: RFR: 8272836: Limit run time for java/lang/invoke/LFCaching tests [v2] In-Reply-To: <8tGUp0hFPKxQr7sHGKSndYgxboTfRtz_1poU0EFRGkA=.93700f0f-a25a-418b-9ec2-a0b7c3fc4456@github.com> References: <8tGUp0hFPKxQr7sHGKSndYgxboTfRtz_1poU0EFRGkA=.93700f0f-a25a-418b-9ec2-a0b7c3fc4456@github.com> Message-ID: <5ulj-G9bC395QxRqQRFVeE4s9PNS4hz7YPPiAoetY0Q=.ba05d16c-e6b8-48e7-8adb-18b2830f4d26@github.com> On Wed, 25 Aug 2021 16:31:50 GMT, Aleksey Shipilev wrote: >> See the RFE for discussion. >> >> Current PR improves the test time like this: >> >> >> $ make run-test TEST=java/lang/invoke/LFCaching/ >> >> # Before >> real 3m51.608s >> user 5m21.612s >> sys 0m5.391s >> >> # After >> real 1m13.606s >> user 2m26.827s >> sys 0m4.761s > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Make the timeout depend on global timeout with lower multiplier > - Merge branch 'master' into JDK-8272836-perf-test-lfcaching > - 8272836: Optimize run time for java/lang/invoke/LFCaching tests Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/5214 From shade at openjdk.java.net Thu Aug 26 06:54:33 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 26 Aug 2021 06:54:33 GMT Subject: Integrated: 8272836: Limit run time for java/lang/invoke/LFCaching tests In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 11:33:35 GMT, Aleksey Shipilev wrote: > See the RFE for discussion. > > Current PR improves the test time like this: > > > $ make run-test TEST=java/lang/invoke/LFCaching/ > > # Before > real 3m51.608s > user 5m21.612s > sys 0m5.391s > > # After > real 1m13.606s > user 2m26.827s > sys 0m4.761s This pull request has now been integrated. Changeset: a3308af0 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/a3308af0605bf936d9a9fb7093787a315ccc1e2a Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8272836: Limit run time for java/lang/invoke/LFCaching tests Reviewed-by: redestad, iignatyev ------------- PR: https://git.openjdk.java.net/jdk/pull/5214 From myano at openjdk.java.net Thu Aug 26 06:57:31 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Thu, 26 Aug 2021 06:57:31 GMT Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v2] In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 07:25:06 GMT, Masanori Yano wrote: >> Hi all, >> >> Could you please review the 8269373 bug fixes? >> >> These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder. > > Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: > > 8269373: use test opts for process arguments I think the current tests force the US locale, and false positives are test failures in non-US locale environments. This fix does not change the test results in the US locale, but allows it to work in non-US locale environments. I can't think of a false positive problem with this fix, but what specific cases do you think are the problems? ------------- PR: https://git.openjdk.java.net/jdk/pull/4594 From vlivanov at openjdk.java.net Thu Aug 26 08:20:29 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 26 Aug 2021 08:20:29 GMT Subject: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation In-Reply-To: <-FLHC8ydZskLXEf3s0VJdJVnw5WiRy_u2qby6sSg3FU=.0187c469-8d75-48e6-a408-9b51a84f1f10@github.com> References: <-FLHC8ydZskLXEf3s0VJdJVnw5WiRy_u2qby6sSg3FU=.0187c469-8d75-48e6-a408-9b51a84f1f10@github.com> Message-ID: On Thu, 26 Aug 2021 02:48:38 GMT, David Holmes wrote: > I'm unclear exactly what that statement is meant to indicate. `DirectMethodHandle::checkInitialized()` is dual-purpose: it implements class initialization barrier and reports whether the class is fully initialized, so the barrier can be safely elided. The call to `Unsafe::ensureClassInitialized()` blocks until initialization is over when the current thread is not the initializing one. But when call to `Unsafe::ensureClassInitialized()` finished, there are 2 cases possible: * the class is fully initialized; * the class is being initialized and the current thread is the initializing one. In the former case, it's safe to remove the barrier while in the latter the barrier is still required. Original implementation implemented that in an explicit manner by using `WeakReference`s to record the initializing thread. But a pair of `Unsafe::ensureClassInitialized()` and `Unsafe::shouldBeInitialized()` calls provides equivalent functionality and is much simpler at the same time. ------------- PR: https://git.openjdk.java.net/jdk/pull/5258 From scolebourne at openjdk.java.net Thu Aug 26 09:06:26 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Thu, 26 Aug 2021 09:06:26 GMT Subject: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. When instant seconds and zone co-exist in parsed data, instant seconds was not resolved correctly from them. LGTM ------------- Marked as reviewed by scolebourne (Author). PR: https://git.openjdk.java.net/jdk/pull/5225 From wuyan at openjdk.java.net Thu Aug 26 09:29:31 2021 From: wuyan at openjdk.java.net (Wu Yan) Date: Thu, 26 Aug 2021 09:29:31 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v6] In-Reply-To: <_XL6WybKwHeJ54kSQnN_q0_NgvR7ib9BFjNJ4HrkO_g=.f82e6cda-b31f-4eee-9185-3e52ebd6b54d@github.com> References: <_XL6WybKwHeJ54kSQnN_q0_NgvR7ib9BFjNJ4HrkO_g=.f82e6cda-b31f-4eee-9185-3e52ebd6b54d@github.com> Message-ID: On Wed, 25 Aug 2021 07:40:56 GMT, Nick Gasson wrote: > I've run the benchmark on several different machines and didn't see any performance regressions, and the speed-up for longer strings looks quite good. I also ran jtreg tier1-3 with no new failures so I think this is ok. > > If you fix the Windows build I'll approve it. But please wait for another review, preferably from @theRealAph. OK, Thank you very much! > Note that JDK-8269559 (#5129) is also adding a JMH benchmark for this intrinsic: it would be good if we could merge them, either now or later. The JMH benchmark added by JDK-8269559 (#5129) can cover our test items (compareToLL and compareToUU), and can show the improvement of our patch, so we decided to delete our JMH benchmark in the next commit. The test results using that JMH benchmark in JDK-8269559 are as follows: Raspberry Pi 4B base: Benchmark (delta) (size) Mode Cnt Score Error Units StringCompareToDifferentLength.compareToLL 2 24 avgt 3 2.310 ? 0.050 ms/op StringCompareToDifferentLength.compareToLL 2 36 avgt 3 2.818 ? 0.185 ms/op StringCompareToDifferentLength.compareToLL 2 72 avgt 3 3.151 ? 0.215 ms/op StringCompareToDifferentLength.compareToLL 2 128 avgt 3 4.171 ? 1.320 ms/op StringCompareToDifferentLength.compareToLL 2 256 avgt 3 6.169 ? 0.653 ms/op StringCompareToDifferentLength.compareToLL 2 512 avgt 3 10.911 ? 0.175 ms/op StringCompareToDifferentLength.compareToLU 2 24 avgt 3 3.312 ? 0.102 ms/op StringCompareToDifferentLength.compareToLU 2 36 avgt 3 4.162 ? 0.032 ms/op StringCompareToDifferentLength.compareToLU 2 72 avgt 3 5.705 ? 0.152 ms/op StringCompareToDifferentLength.compareToLU 2 128 avgt 3 9.301 ? 0.749 ms/op StringCompareToDifferentLength.compareToLU 2 256 avgt 3 16.507 ? 1.353 ms/op StringCompareToDifferentLength.compareToLU 2 512 avgt 3 30.160 ? 0.377 ms/op StringCompareToDifferentLength.compareToUL 2 24 avgt 3 3.366 ? 0.280 ms/op StringCompareToDifferentLength.compareToUL 2 36 avgt 3 4.308 ? 0.037 ms/op StringCompareToDifferentLength.compareToUL 2 72 avgt 3 5.674 ? 0.210 ms/op StringCompareToDifferentLength.compareToUL 2 128 avgt 3 9.358 ? 0.158 ms/op StringCompareToDifferentLength.compareToUL 2 256 avgt 3 16.165 ? 0.158 ms/op StringCompareToDifferentLength.compareToUL 2 512 avgt 3 29.857 ? 0.277 ms/op StringCompareToDifferentLength.compareToUU 2 24 avgt 3 3.149 ? 0.209 ms/op StringCompareToDifferentLength.compareToUU 2 36 avgt 3 3.157 ? 0.102 ms/op StringCompareToDifferentLength.compareToUU 2 72 avgt 3 4.415 ? 0.073 ms/op StringCompareToDifferentLength.compareToUU 2 128 avgt 3 6.244 ? 0.224 ms/op StringCompareToDifferentLength.compareToUU 2 256 avgt 3 11.032 ? 0.080 ms/op StringCompareToDifferentLength.compareToUU 2 512 avgt 3 20.942 ? 3.973 ms/op opt? Benchmark (delta) (size) Mode Cnt Score Error Units StringCompareToDifferentLength.compareToLL 2 24 avgt 3 2.319 ? 0.121 ms/op StringCompareToDifferentLength.compareToLL 2 36 avgt 3 2.820 ? 0.096 ms/op StringCompareToDifferentLength.compareToLL 2 72 avgt 3 2.511 ? 0.024 ms/op StringCompareToDifferentLength.compareToLL 2 128 avgt 3 3.496 ? 0.382 ms/op StringCompareToDifferentLength.compareToLL 2 256 avgt 3 5.215 ? 0.210 ms/op StringCompareToDifferentLength.compareToLL 2 512 avgt 3 7.772 ? 0.448 ms/op StringCompareToDifferentLength.compareToLU 2 24 avgt 3 3.432 ? 0.249 ms/op StringCompareToDifferentLength.compareToLU 2 36 avgt 3 4.156 ? 0.052 ms/op StringCompareToDifferentLength.compareToLU 2 72 avgt 3 5.735 ? 0.043 ms/op StringCompareToDifferentLength.compareToLU 2 128 avgt 3 9.215 ? 0.394 ms/op StringCompareToDifferentLength.compareToLU 2 256 avgt 3 16.373 ? 0.515 ms/op StringCompareToDifferentLength.compareToLU 2 512 avgt 3 29.906 ? 0.245 ms/op StringCompareToDifferentLength.compareToUL 2 24 avgt 3 3.361 ? 0.116 ms/op StringCompareToDifferentLength.compareToUL 2 36 avgt 3 4.253 ? 0.061 ms/op StringCompareToDifferentLength.compareToUL 2 72 avgt 3 5.744 ? 0.082 ms/op StringCompareToDifferentLength.compareToUL 2 128 avgt 3 9.167 ? 0.343 ms/op StringCompareToDifferentLength.compareToUL 2 256 avgt 3 16.591 ? 0.999 ms/op StringCompareToDifferentLength.compareToUL 2 512 avgt 3 30.232 ? 2.057 ms/op StringCompareToDifferentLength.compareToUU 2 24 avgt 3 3.147 ? 0.057 ms/op StringCompareToDifferentLength.compareToUU 2 36 avgt 3 2.526 ? 0.027 ms/op StringCompareToDifferentLength.compareToUU 2 72 avgt 3 3.832 ? 0.228 ms/op StringCompareToDifferentLength.compareToUU 2 128 avgt 3 5.332 ? 0.173 ms/op StringCompareToDifferentLength.compareToUU 2 256 avgt 3 8.417 ? 0.551 ms/op StringCompareToDifferentLength.compareToUU 2 512 avgt 3 14.903 ? 0.782 ms/op Hisilicon base: Benchmark (delta) (size) Mode Cnt Score Error Units StringCompareToDifferentLength.compareToLL 2 24 avgt 30 0.824 ? 0.003 ms/op StringCompareToDifferentLength.compareToLL 2 36 avgt 30 1.123 ? 0.050 ms/op StringCompareToDifferentLength.compareToLL 2 72 avgt 30 1.550 ? 0.052 ms/op StringCompareToDifferentLength.compareToLL 2 128 avgt 30 2.015 ? 0.040 ms/op StringCompareToDifferentLength.compareToLL 2 256 avgt 30 3.154 ? 0.032 ms/op StringCompareToDifferentLength.compareToLL 2 512 avgt 30 5.519 ? 0.044 ms/op StringCompareToDifferentLength.compareToLU 2 24 avgt 30 1.469 ? 0.196 ms/op StringCompareToDifferentLength.compareToLU 2 36 avgt 30 1.777 ? 0.097 ms/op StringCompareToDifferentLength.compareToLU 2 72 avgt 30 2.509 ? 0.073 ms/op StringCompareToDifferentLength.compareToLU 2 128 avgt 30 3.914 ? 0.044 ms/op StringCompareToDifferentLength.compareToLU 2 256 avgt 30 6.773 ? 0.049 ms/op StringCompareToDifferentLength.compareToLU 2 512 avgt 30 12.504 ? 0.081 ms/op StringCompareToDifferentLength.compareToUL 2 24 avgt 30 1.505 ? 0.107 ms/op StringCompareToDifferentLength.compareToUL 2 36 avgt 30 1.976 ? 0.145 ms/op StringCompareToDifferentLength.compareToUL 2 72 avgt 30 2.593 ? 0.082 ms/op StringCompareToDifferentLength.compareToUL 2 128 avgt 30 3.998 ? 0.062 ms/op StringCompareToDifferentLength.compareToUL 2 256 avgt 30 6.949 ? 0.110 ms/op StringCompareToDifferentLength.compareToUL 2 512 avgt 30 12.617 ? 0.068 ms/op StringCompareToDifferentLength.compareToUU 2 24 avgt 30 1.232 ? 0.038 ms/op StringCompareToDifferentLength.compareToUU 2 36 avgt 30 1.505 ? 0.008 ms/op StringCompareToDifferentLength.compareToUU 2 72 avgt 30 2.218 ? 0.066 ms/op StringCompareToDifferentLength.compareToUU 2 128 avgt 30 3.329 ? 0.119 ms/op StringCompareToDifferentLength.compareToUU 2 256 avgt 30 5.684 ? 0.030 ms/op StringCompareToDifferentLength.compareToUU 2 512 avgt 30 10.520 ? 0.031 ms/op opt: Benchmark (delta) (size) Mode Cnt Score Error Units StringCompareToDifferentLength.compareToLL 2 24 avgt 30 0.824 ? 0.003 ms/op StringCompareToDifferentLength.compareToLL 2 36 avgt 30 1.124 ? 0.032 ms/op StringCompareToDifferentLength.compareToLL 2 72 avgt 30 1.376 ? 0.123 ms/op StringCompareToDifferentLength.compareToLL 2 128 avgt 30 1.921 ? 0.040 ms/op StringCompareToDifferentLength.compareToLL 2 256 avgt 30 2.656 ? 0.156 ms/op StringCompareToDifferentLength.compareToLL 2 512 avgt 30 4.311 ? 0.267 ms/op StringCompareToDifferentLength.compareToLU 2 24 avgt 30 1.391 ? 0.154 ms/op StringCompareToDifferentLength.compareToLU 2 36 avgt 30 1.891 ? 0.170 ms/op StringCompareToDifferentLength.compareToLU 2 72 avgt 30 2.496 ? 0.082 ms/op StringCompareToDifferentLength.compareToLU 2 128 avgt 30 3.978 ? 0.046 ms/op StringCompareToDifferentLength.compareToLU 2 256 avgt 30 6.811 ? 0.057 ms/op StringCompareToDifferentLength.compareToLU 2 512 avgt 30 12.586 ? 0.054 ms/op StringCompareToDifferentLength.compareToUL 2 24 avgt 30 1.462 ? 0.085 ms/op StringCompareToDifferentLength.compareToUL 2 36 avgt 30 1.864 ? 0.070 ms/op StringCompareToDifferentLength.compareToUL 2 72 avgt 30 2.651 ? 0.090 ms/op StringCompareToDifferentLength.compareToUL 2 128 avgt 30 4.223 ? 0.383 ms/op StringCompareToDifferentLength.compareToUL 2 256 avgt 30 6.858 ? 0.085 ms/op StringCompareToDifferentLength.compareToUL 2 512 avgt 30 12.675 ? 0.099 ms/op StringCompareToDifferentLength.compareToUU 2 24 avgt 30 1.200 ? 0.013 ms/op StringCompareToDifferentLength.compareToUU 2 36 avgt 30 1.336 ? 0.156 ms/op StringCompareToDifferentLength.compareToUU 2 72 avgt 30 2.364 ? 0.545 ms/op StringCompareToDifferentLength.compareToUU 2 128 avgt 30 2.753 ? 0.154 ms/op StringCompareToDifferentLength.compareToUU 2 256 avgt 30 5.179 ? 0.834 ms/op StringCompareToDifferentLength.compareToUU 2 512 avgt 30 7.090 ? 0.423 ms/op > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4871: > >> 4869: // exit from large loop when less than 64 bytes left to read or we're about >> 4870: // to prefetch memory behind array border >> 4871: int largeLoopExitCondition = MAX(64, SoftwarePrefetchHintDistance)/(isLL ? 1 : 2); > > This breaks the Windows AArch64 build: > > > Creating support/modules_libs/java.base/server/jvm.dll from 1051 file(s) > d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\stubGenerator_aarch64.cpp(4871): error C3861: 'MAX': identifier not found > make[3]: *** [lib/CompileJvm.gmk:143: /cygdrive/d/a/jdk/jdk/jdk/build/windows-aarch64/hotspot/variant-server/libjvm > > > https://github.com/Wanghuang-Huawei/jdk/runs/3260986937 > > Should probably be left as `MAX2`. Thanks, I'll fix it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4722 From Alan.Bateman at oracle.com Thu Aug 26 10:39:59 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 Aug 2021 11:39:59 +0100 Subject: what does the spec say about file paths that are too long? In-Reply-To: <81398B70-EC5E-4E06-9790-85CE56199591@cbfiddle.com> References: <7CBCF03A-AEBA-46EE-BCBD-4ED9D1C97450@cbfiddle.com> <81398B70-EC5E-4E06-9790-85CE56199591@cbfiddle.com> Message-ID: <444a66bd-a4fe-edef-e620-1ff8ddd6b1cc@oracle.com> On 25/08/2021 23:12, Alan Snyder wrote: > Lacking any new data, I guess it is fair to assume that there is no specification for the behavior of methods that use file paths that are too long, and presumably no tests, either. > > So the next question is whether there should be such a specification. > > I think there should be a specification because I would like to be able to use file paths without having to defend against possible unwanted bad effects when the paths are too long. By analogy, more like array indexing than integer overflow. > > If there is to be a specification, should it be at the method level? That would be best, I think. > > For example, the Path.toAbsolutePath() method in principle could return a path that is ?too long? even if the original path is fine. Should an exception be raised at that point or only when the absolute path is used? This distinction was not possible with File, but it may be possible with Path, given the association with file providers. > > (Regarding the comment from Alan B., is it the case that file paths are necessarily resolved before use? That would surprise me.) As I said, you should see an I/O exception if you attempt to access the file system with a file path that is too long to locate a file. There are a couple of APIs that return a boolean rather than throw and they should all fail (usually by returning false) if the file path is too long. If you do find a case where you think the file path is "silently truncated" then please bring it up so we can see if this is a JDK or operating system issue. There was some exploration, in the JDK 7 time frame, into defining APIs that expose limits but it gets unapproachable very quickly due to handling by specific operating systems and encoding/normalization at the low-level file system level. I see your other mails asking if resolving or combining paths should fail. That is not feasible in general. Bernd mentioned some of the issues. If you add sym or hard links to the discussion then you will quickly see that you don't actually know which file system or file will be accessed until you attempt the access. You also mentioned being surprised that the JDK may have to "resolve" paths. It has to in some cases, the most obvious being long paths on Windows that need transformation and a prefix to order to generate the file path for the Windows call. -Alan. From Alan.Bateman at oracle.com Thu Aug 26 11:36:24 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 Aug 2021 12:36:24 +0100 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> Message-ID: On 25/08/2021 15:57, Jaikiran Pai wrote: > : > > Introducing an overloaded "store" which takes the timestamp or > implicitly using the SOURCE_DATE_EPOCH environment variable would mean > that the Properties.store(...) APIs will continue to always write out > a Date representation into the outputstream. That effectively means > that there will continue to be no way to disable writing out a (date) > comment. More specifically, even if a user doesn't explicitly specify > a comment, we would end up writing a default (date) comment. Do we > want that? Or while we are doing these changes, should we introduce > this ability of disabling writing out these date comments by default? > That, IMO, can only be done by introducing new APIs instead of trying > to slightly change the spec and the implementation of the current > "store" APIs. After all, if any callers do want a date (and a > reproducible one at that), they could always do so by passing that as > a value for the "comment" parameter of these (new) "storeXXX" APIs. Properties save/store has always emitted a comment line with the current date/time, it goes back to JDK 1.0. It's unfortunate that newer store methods didn't re-examine this, also unfortunate that it continued with 8859-1. In the discussion on jdk-dev about reproducibility then I think we concluded that we don't want to change the behavior of existing methods, hence the discussion on introducing a new method. An new overload of store would give the maximum flexibility to new code but it would require programs used in builds to use it consistently. It's possible that libraries or tools that are using Properties::store have no idea that they will ultimately be used in a system that is trying to produce reproducible builds. So I have some sympathy to the argument that there should a way to omit the date or emit it as the Unix epoch time or a fixed value. This would mean changing the spec to allow for some implementation means to do this, and maybe an implNote that documents that it reads SOURCE_DATE_EPOCH. I think Roger has misgivings about this. So let's list the options and the pros/cons and see if we can converge on an approach. > I think, based on the discussion/inputs so far, there's clarity on > this part that changing the current implementation of "store" to write > out the property keys in a specific order would be a good thing, > irrespective of whether or not we introduce new APIs to deal with the > date comment aspect. Daniel had an interesting point of > logging.properties file and the order that would need to be maintained > for those, but like he noted in that same reply, I don't think that's > a use case to consider for the "store" APIs, since they never > previously supported/guaranteed that use case. Yes, I think we should be okay there. I suspect the iteration order has changed once or twice already, e.g. when Properties was re-implemented to use a CHM. -Alan From jai.forums2013 at gmail.com Thu Aug 26 14:07:48 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 26 Aug 2021 19:37:48 +0530 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <2484bdde-173a-fa5a-278e-6502c799a095@oracle.com> <9160e0df-84cc-a7a0-5475-db7e01892c41@gmail.com> Message-ID: <10b4024a-cad0-e6ee-3eb6-db8db0a6fe29@gmail.com> Hello Magnus, On 25/08/21 5:33 pm, Magnus Ihse Bursie wrote: > ... >> One thing I do remember is the JDK build (through the make files) >> would have certain Java code it would call to do some build steps. Is >> there a easy way to find all such build related Java files within the >> JDK? I would like to see if there are any references/calls to this >> method from those build files. I am doing some searches myself, but >> knowing where to search will give me more confidence that I haven't >> missed out any. > > The java buildtool sources are located in the "make" directory, more > specifically in "make/jdk/src", "make/langtools/src" and "make/src" > (yeah, I know -- a cleanup is way overdue). I did a quick search now > but could not find any references to Properties.store(). > Thank you for that. I went ahead and verified it again and like you note, I don't see any usages in this code. > I'm trying to remember if we create properties during the build... We > have several instances where .properties files in the Java source code > are converted to hard-coded classes (for performance), and other where > .properties files are copied verbatim. Ah, right, they are "cleaned" > beforehand. We used to do this by a Java program, but nowadays they > are mangled by sed. I think replacing that sed script with a trivial > Java program doing storeCanonical() would be on the list of things to > do. I can assist with that, when you are starting to get your > implementation done. Thank you. Once the initial draft version is ready, I will contact you. > > We might also write something as part of the jlink process that gets > embedded in the resulting jimage; not quite sure about that. You > should find that code in the normal src/ codebase though. I had a look at the the jlink and image building code and I haven't found any references/usages in this area. -Jaikiran From jai.forums2013 at gmail.com Thu Aug 26 14:20:04 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 26 Aug 2021 19:50:04 +0530 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <2484bdde-173a-fa5a-278e-6502c799a095@oracle.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <2484bdde-173a-fa5a-278e-6502c799a095@oracle.com> Message-ID: <796202e4-f855-e06d-19c1-b70944ade105@gmail.com> Hello Roger, Sorry, I just read the top part of your reply the last time and didn't realize there were inline comments. I just noticed them. Replying inline. On 24/08/21 8:14 pm, Roger Riggs wrote: > Hi Jaikiran, > > Thanks for taking this on and getting it started. > > One use case of canonical storage is repeatable builds. > It would be useful to identify the uses in the JDK that would need to > be changed to use the new function. > > On 8/24/21 10:07 AM, Jaikiran Pai wrote: >> The java.util.Properties class allows the properties to be written >> out to a stream or through a writer. In its current form, the >> specification of these APIs state that a comment comprising of the >> current date is always written out. The spec doesn't make any >> guarantees about the order of the properties when they are written out. >> >> There have been requests asking to make these APIs more >> deterministic. These requests, from what I have seen, mainly ask for: >> >> - A way to disable writing out the date comment >> - A way to write out the properties in a deterministic and >> reproducible way >> >> There have been discussions in the mailing list in the past which >> have been captured in JDK-8231640[1]. In these discussions, there has >> been an inclination to not touch the current existing API >> implementations and instead introduce new API(s) to achieve the >> proposed use cases. >> >> Before starting off with an implementation, I wanted to try and get >> some inputs on what the new API(s) would look like and what the scope >> of such a work should be. >> >> Right now, the Properties class has 2 "store" APIs: >> >> ??? public void store(Writer writer, String comments) throws IOException >> ??? public void store(OutputStream out, String comments) throws >> IOException > > I don't think two methods are needed, its easy enough for the caller > to adapt an OutputStream to a Writer > (OutputStreamWriter) and take control of the encoding, so the > OutputStream version is not essential. That's a good point and makes sense. >> >> Speaking of optional comments, should the APIs accept an instance of >> java.util.Optional for the comments parameter. Perhaps: >> >> ??? public void storeCanonical(Writer writer, Optional >> comments) throws IOException >> ??? public void storeCanonical(OutputStream out, Optional >> comments) throws IOException > > Optional is overkill here, using null for no comment is conventional > and matches the current usage > in the store(..) methods. Okay. Not using Optional sounds fine. >> >> >> Coming to the part where we write out the properties, these APIs will >> write out the properties in the lexicographical order of the property >> keys. An additional enhancement perhaps could be to allow users to >> pass in an optional java.util.Comparator instance to provide for >> application specific ordering of the property keys while being >> written out by these APIs. I am not too sure if we should introduce >> that. Any inputs? If we do introduce it, we would end up with 4 new >> APIs: >> >> ??? public void storeCanonical(Writer writer, Optional >> comments) throws IOException >> ??? public void storeCanonical(OutputStream out, Optional >> comments) throws IOException >> ??? public void storeCanonical(Writer writer, Optional >> comments, Comparator keyOrderer) throws IOException >> ??? public void storeCanonical(OutputStream out, Optional >> comments, Comparator keyOrderer) throws IOException > Canonical usually already means a non-variable encoding, that seems > the inconsistent with > providing a Comparator. From the inputs received so far, there hasn't been a real use case where a custom user provided Comparator would be of genuine help. So I don't plan to look more into this aspect. > > However, it should be a goal that properties stored with > storeCanonical can be > loaded with load(). Agreed. > >> >> Is that worth it? >> >> Finally, the other semantics, like the property key value separators, >> how/where newlines are inserted, what character encoding is used >> etc... will continue to match with the current semantics of the >> "store" APIs. > > If a client has the need for a custom format, its quite easy to > iterate over the contents, > sorting if desires and writing the format itself. > A custom format would not be usable with Properties.load. > > Simpler is better, > Agreed. -Jaikiran From javalists at cbfiddle.com Thu Aug 26 14:43:34 2021 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 26 Aug 2021 07:43:34 -0700 Subject: what does the spec say about file paths that are too long? In-Reply-To: <444a66bd-a4fe-edef-e620-1ff8ddd6b1cc@oracle.com> References: <7CBCF03A-AEBA-46EE-BCBD-4ED9D1C97450@cbfiddle.com> <81398B70-EC5E-4E06-9790-85CE56199591@cbfiddle.com> <444a66bd-a4fe-edef-e620-1ff8ddd6b1cc@oracle.com> Message-ID: <3B9D5E22-20F2-4CEA-B824-37F421FDFED2@cbfiddle.com> As I said, I think it's great that we agree an exception should be thrown when an over-length path is used in an actual file operation. However, would it not be better to have that in the specification, rather than relying on the opinions of individual engineers expressed in a thread on a mailing list? And would it not also be better if there were test cases? I also think it would be good to have a specific exception to use for such cases. Regarding path resolving, I am not surprised that the JDK may have to resolve paths before use in some cases. Your original comment seemed to imply that *all* uses were resolved by the JDK first, and that would surprise me. Granted that path operations cannot in general predict when a path will be of usable length in a file operation, the question remains whether path operations should report over-length paths in those cases where it can be determined. Is it not the case that some OS APIs have hard limits on path length (unrelated to limits imposed by the file system itself)? For a file provider using such an API, would throwing an exception when that limit is exceeded be a good idea or a bad idea? Alan > On Aug 26, 2021, at 3:39 AM, Alan Bateman wrote: > > On 25/08/2021 23:12, Alan Snyder wrote: >> Lacking any new data, I guess it is fair to assume that there is no specification for the behavior of methods that use file paths that are too long, and presumably no tests, either. >> >> So the next question is whether there should be such a specification. >> >> I think there should be a specification because I would like to be able to use file paths without having to defend against possible unwanted bad effects when the paths are too long. By analogy, more like array indexing than integer overflow. >> >> If there is to be a specification, should it be at the method level? That would be best, I think. >> >> For example, the Path.toAbsolutePath() method in principle could return a path that is ?too long? even if the original path is fine. Should an exception be raised at that point or only when the absolute path is used? This distinction was not possible with File, but it may be possible with Path, given the association with file providers. >> >> (Regarding the comment from Alan B., is it the case that file paths are necessarily resolved before use? That would surprise me.) > As I said, you should see an I/O exception if you attempt to access the file system with a file path that is too long to locate a file. There are a couple of APIs that return a boolean rather than throw and they should all fail (usually by returning false) if the file path is too long. If you do find a case where you think the file path is "silently truncated" then please bring it up so we can see if this is a JDK or operating system issue. There was some exploration, in the JDK 7 time frame, into defining APIs that expose limits but it gets unapproachable very quickly due to handling by specific operating systems and encoding/normalization at the low-level file system level. > > I see your other mails asking if resolving or combining paths should fail. That is not feasible in general. Bernd mentioned some of the issues. If you add sym or hard links to the discussion then you will quickly see that you don't actually know which file system or file will be accessed until you attempt the access. You also mentioned being surprised that the JDK may have to "resolve" paths. It has to in some cases, the most obvious being long paths on Windows that need transformation and a prefix to order to generate the file path for the Windows call. > > -Alan. > From psandoz at openjdk.java.net Thu Aug 26 15:17:24 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 26 Aug 2021 15:17:24 GMT Subject: RFR: 8272861: Add a micro benchmark for vector api [v3] In-Reply-To: <2RbnsJk-_7EXYWD0Vun5aJQn18sQUudSPOG3dxNma-U=.1665ff7a-5018-4b9f-8420-5555f64ca308@github.com> References: <2RbnsJk-_7EXYWD0Vun5aJQn18sQUudSPOG3dxNma-U=.1665ff7a-5018-4b9f-8420-5555f64ca308@github.com> Message-ID: On Tue, 24 Aug 2021 20:49:52 GMT, Sandhya Viswanathan wrote: >> This pull request adds a micro benchmark for Vector API. >> The Black Scholes algorithm is implemented with and without Vector API. >> We see about ~6x gain with Vector API for this micro benchmark using 256 bit vectors. > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Make constants as static final Very nice, just one minor comment (no need for another review), thanks for contributing this. test/micro/org/openjdk/bench/jdk/incubator/vector/BlackScholes.java line 60: > 58: > 59: float randFloat(float low, float high) { > 60: float val = rand.nextFloat()/Float.MAX_VALUE; `nextFloat` returns a PSR between 0 and 1., so no need to divide by `Float.MAX_VALUE` ? ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5234 From psandoz at openjdk.java.net Thu Aug 26 15:38:26 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 26 Aug 2021 15:38:26 GMT Subject: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 22:05:24 GMT, Vladimir Ivanov wrote: > Get rid of WeakReference-based logic in DirectMethodHandle::checkInitialized() and reimplement it with `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`. > > The key observation is that `Unsafe::ensureClassInitialized()` does not block the initializing thread. > > Also, removed `Unsafe::shouldBeInitialized()` in `DMH::shouldBeInitialized(MemberName)` to save on calling into the VM. > `Unsafe::ensureClassInitialized()` already has a fast-path check which checks whether the class is fully initialized or not. > > Testing: tier1 - tier6 That's a nice cleanup to a tricky area (one of the few used to trigger an update a final field). In effect we were already relying on that behavior in the `ClassValue` computation. May i suggest that we add some JavaDoc to `ensureClassInitialized` describing the two cases of the calling thread is the initialization thread or not. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5258 From Alan.Bateman at oracle.com Thu Aug 26 15:57:50 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 Aug 2021 16:57:50 +0100 Subject: what does the spec say about file paths that are too long? In-Reply-To: <3B9D5E22-20F2-4CEA-B824-37F421FDFED2@cbfiddle.com> References: <7CBCF03A-AEBA-46EE-BCBD-4ED9D1C97450@cbfiddle.com> <81398B70-EC5E-4E06-9790-85CE56199591@cbfiddle.com> <444a66bd-a4fe-edef-e620-1ff8ddd6b1cc@oracle.com> <3B9D5E22-20F2-4CEA-B824-37F421FDFED2@cbfiddle.com> Message-ID: <868b7850-4104-3491-497e-a437fb43a3a3@oracle.com> On 26/08/2021 15:43, Alan Snyder wrote: > As I said, I think it's great that we agree an exception should be thrown when an over-length path is used in an actual file operation. > > However, would it not be better to have that in the specification, rather than relying on the opinions of individual engineers expressed in a thread on a mailing list? > > And would it not also be better if there were test cases? You are welcome to propose additional tests if you want. > > I also think it would be good to have a specific exception to use for such cases. It would to have optional (see the "Optional Specific Exceptions" sections of the javadoc) as you can't guarantee that ENAMETOOLONG/equivalent would happen in all cases. > Regarding path resolving, I am not surprised that the JDK may have to resolve paths before use in some cases. Your original comment seemed to imply that *all* uses were resolved by the JDK first, and that would surprise me. > > Granted that path operations cannot in general predict when a path will be of usable length in a file operation, the question remains whether path operations should report over-length paths in those cases where it can be determined. Is it not the case that some OS APIs have hard limits on path length (unrelated to limits imposed by the file system itself)? For a file provider using such an API, would throwing an exception when that limit is exceeded be a good idea or a bad idea? I don't think this is feasible or a compatible change. -Alan From naoto at openjdk.java.net Thu Aug 26 16:24:27 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 26 Aug 2021 16:24:27 GMT Subject: Integrated: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. When instant seconds and zone co-exist in parsed data, instant seconds was not resolved correctly from them. This pull request has now been integrated. Changeset: fe7d7088 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/fe7d70886cc9985478c5810eff0790648a9aae41 Stats: 14 lines in 2 files changed: 8 ins; 0 del; 6 mod 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong Reviewed-by: joehw, rriggs, iris, lancea, scolebourne ------------- PR: https://git.openjdk.java.net/jdk/pull/5225 From psandoz at openjdk.java.net Thu Aug 26 18:16:29 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 26 Aug 2021 18:16:29 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 09:31:51 GMT, Vladimir Ivanov wrote: > `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. > > Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. > > The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. > > Testing: tier1 - tier6 Looks good. I guess it is not that common for the soft ref to get instantiated i.e. for the case of the ~common class loader of `type`, MTC say, and the ~common classoader of `newType`, NMTC say, then NMTC is not an ancestor of MTC. It's possible that `asTypeCache` and `asTypeSoftCache` could both be non-null i.e. we don't null out one of them, buy does not seem a problem. src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 869: > 867: } > 868: at = asTypeUncached(newType); > 869: return setAsTypeCache(at); The following may be a little clearer Suggestion: MethodHandle at = asTypeCached(newType); return at != null ? at : setAsTypeCache(asTypeUncached(newType)); src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 953: > 951: > 952: /* Determine whether {@code descendant} keeps {@code ancestor} alive through the loader delegation chain. */ > 953: private static boolean keepsAlive(ClassLoader ancestor, ClassLoader descendant) { Might be clearer to name the method by what it is e.g. isAncestor // Returns true if ancestor can be found descendant's delegation chain. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5246 From sviswanathan at openjdk.java.net Thu Aug 26 18:16:56 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 26 Aug 2021 18:16:56 GMT Subject: RFR: 8272861: Add a micro benchmark for vector api [v4] In-Reply-To: References: Message-ID: > This pull request adds a micro benchmark for Vector API. > The Black Scholes algorithm is implemented with and without Vector API. > We see about ~6x gain with Vector API for this micro benchmark using 256 bit vectors. Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: No need to normalize nextFloat ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5234/files - new: https://git.openjdk.java.net/jdk/pull/5234/files/5b4abbf9..df22def3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5234&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5234&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5234.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5234/head:pull/5234 PR: https://git.openjdk.java.net/jdk/pull/5234 From naoto at openjdk.java.net Thu Aug 26 19:05:29 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 26 Aug 2021 19:05:29 GMT Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v2] In-Reply-To: References: Message-ID: On Wed, 4 Aug 2021 07:25:06 GMT, Masanori Yano wrote: >> Hi all, >> >> Could you please review the 8269373 bug fixes? >> >> These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder. > > Masanori Yano has updated the pull request incrementally with one additional commit since the last revision: > > 8269373: use test opts for process arguments I think implicitly expecting locales to be set to en-US by specifying `test.vm.opts` is fragile which would introduce test instability. In fact, looking at some of the tests, e.g., `HelpFlagsTest` at line 332, the intention is to silently exit in case it is not English. I think it is what the test is intended and it is a bug if it fails with other locales. ------------- PR: https://git.openjdk.java.net/jdk/pull/4594 From github.com+741251+turbanoff at openjdk.java.net Thu Aug 26 20:50:27 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 26 Aug 2021 20:50:27 GMT Subject: Integrated: 8272863: Replace usages of Collections.sort with List.sort call in public java modules In-Reply-To: References: Message-ID: On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. This pull request has now been integrated. Changeset: d732c309 Author: Andrey Turbanov Committer: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/d732c3091fea0a7c6d6767227de89002564504e5 Stats: 27 lines in 10 files changed: 0 ins; 8 del; 19 mod 8272863: Replace usages of Collections.sort with List.sort call in public java modules Reviewed-by: serb, dfuchs, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/5229 From darcy at openjdk.java.net Thu Aug 26 22:42:24 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 26 Aug 2021 22:42:24 GMT Subject: RFR: 8272541: Incorrect overflow test in Toom-Cook branch of BigInteger multiplication In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 21:00:00 GMT, Brian Burkhalter wrote: > Please consider this change which would modify a conditional `a + b > c` where the left side variables are `int`s and the right side is `(long)Integer.MAX_VALUE + 1`. The change is to cast the left side variables to `long`s. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5130 From dholmes at openjdk.java.net Thu Aug 26 23:53:22 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 26 Aug 2021 23:53:22 GMT Subject: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 22:05:24 GMT, Vladimir Ivanov wrote: > Get rid of WeakReference-based logic in DirectMethodHandle::checkInitialized() and reimplement it with `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`. > > The key observation is that `Unsafe::ensureClassInitialized()` does not block the initializing thread. > > Also, removed `Unsafe::shouldBeInitialized()` in `DMH::shouldBeInitialized(MemberName)` to save on calling into the VM. > `Unsafe::ensureClassInitialized()` already has a fast-path check which checks whether the class is fully initialized or not. > > Testing: tier1 - tier6 src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 385: > 383: Class defc = member.getDeclaringClass(); > 384: UNSAFE.ensureClassInitialized(defc); // initialization barrier; blocks unless called by the initializing thread > 385: return !UNSAFE.shouldBeInitialized(defc); // keep the barrier if the initialization is still in progress I think some more elaborate commentary about the possibility of this being called while of defc is already on the call stack, would be worthwhile - the existing comments are a little too subtle IMO. UNSAFE.ensureClassInitialized(defc); // Once we get here either defc was fully initialized by another thread, or // defc was already being initialized by the current thread. In the latter case // the barrier must remain. We can detect this simply by checking if initialization // is still needed. return !UNSAFE.shouldBeInitialized(defc); ------------- PR: https://git.openjdk.java.net/jdk/pull/5258 From fdesu at protonmail.com Fri Aug 27 10:00:37 2021 From: fdesu at protonmail.com (Sergei Ustimenko) Date: Fri, 27 Aug 2021 10:00:37 +0000 Subject: Replace StringBuffers to StringBuilders in tests Message-ID: Hi all, Some tests use StringBuffers instead of StringBuilders where additional thread-safety is not required as e.g. in test/jdk/sun/util/resources/TimeZone/Bug4640234.java:82 : ... StringBuffer errors = new StringBuffer( "" ); StringBuffer warnings = new StringBuffer( "" ); ... There were some efforts to clean up core libs (e.g. java.base module in https://github.com/openjdk/jdk/pull/2922) and I've noticed some tests that could be improved as well. Now there are about 300 tests for different modules that in general use StringBuffers (most probably some of them not without a reason) so is it something worth looking into? What you think about it? Regards, Sergei From daniel.fuchs at oracle.com Fri Aug 27 10:42:05 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 27 Aug 2021 11:42:05 +0100 Subject: Replace StringBuffers to StringBuilders in tests In-Reply-To: References: Message-ID: <6964840b-4d78-3d91-9929-bba740cc0d93@oracle.com> Hi Sergei, I wouldn't bother replacing StringBuffers with StringDuilders in tests. It seems a bit gratuitous - and possibly could complicate future tests backports. But that's my personal opinion. Others might disagree. best regards, -- daniel On 27/08/2021 11:00, Sergei Ustimenko wrote: > Hi all, > > Some tests use StringBuffers instead of StringBuilders where additional thread-safety > is not required as e.g. in test/jdk/sun/util/resources/TimeZone/Bug4640234.java:82 : > ... > > StringBuffer errors > > = > > new > > StringBuffer( > > "" > > ); > > StringBuffer warnings > > = > > new > > StringBuffer( > > "" > > ); > > ... > There were some efforts to clean up core libs (e.g. java.base module in > https://github.com/openjdk/jdk/pull/2922) and I've noticed some tests that could be > improved as well. > > Now there are about 300 tests for different modules that in general use StringBuffers > (most probably some of them not without a reason) so is it something worth looking > into? What you think about it? > > Regards, > Sergei > From david.holmes at oracle.com Fri Aug 27 13:14:37 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Aug 2021 23:14:37 +1000 Subject: Replace StringBuffers to StringBuilders in tests In-Reply-To: <6964840b-4d78-3d91-9929-bba740cc0d93@oracle.com> References: <6964840b-4d78-3d91-9929-bba740cc0d93@oracle.com> Message-ID: On 27/08/2021 8:42 pm, Daniel Fuchs wrote: > Hi Sergei, > > I wouldn't bother replacing StringBuffers with StringDuilders in tests. > It seems a bit gratuitous - and possibly could complicate future > tests backports. > > But that's my personal opinion. Others might disagree. I agree with you. Complete waste of time and effort for zero benefit IMO. Sorry Sergei. Cheers, David > best regards, > > -- daniel > > On 27/08/2021 11:00, Sergei Ustimenko wrote: >> Hi all, >> >> Some tests use StringBuffers instead of StringBuilders where >> additional thread-safety >> is not required as e.g. in >> test/jdk/sun/util/resources/TimeZone/Bug4640234.java:82 : >> ... >> >> StringBuffer errors >> >> = >> >> new >> >> StringBuffer( >> >> "" >> >> ); >> >> StringBuffer warnings >> >> = >> >> new >> >> StringBuffer( >> >> "" >> >> ); >> >> ... >> There were some efforts to clean up core libs (e.g. java.base module in >> https://github.com/openjdk/jdk/pull/2922) and I've noticed some tests >> that could be >> improved as well. >> >> Now there are about 300 tests for different modules that in general >> use StringBuffers >> (most probably some of them not without a reason) so is it something >> worth looking >> into? What you think about it? >> >> Regards, >> Sergei >> > From david.holmes at oracle.com Fri Aug 27 13:25:25 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Aug 2021 23:25:25 +1000 Subject: StringBuilder OOMs earlier with JRE 11 compared to JRE 8 In-Reply-To: References: Message-ID: <99e1fc68-a602-0a31-a98a-03548fa63665@oracle.com> Hi Simeon, Redirecting this to core-libs-dev as it is not a serviceability issue. (bcc serviceabillity-dev) Thanks, David On 27/08/2021 8:53 pm, S A wrote: > Hi all, > > while working on https://bugs.eclipse.org/bugs/show_bug.cgi?id=575641 > , I noticed that > StringBuilder throws an OOM "half as early" in OpenJDK 11 (and 17 early > access), when compared to OpenJDK 8. > > In particular, I ran the following snippet to see where the limit of > appending to a StringBuilder is: > > StringBuilder sb = new StringBuilder(); > long n = 8L * 1024L * 1024L; > for (long i = 0; i < n; ++i) { > int m = 1024; > for (int j = 0; j < m; ++j) { > int length = sb.length(); > try { > sb.append((char) j); > } catch (Error e) { > System.out.println("Error occurred at length=" + length + " [i=" + i + > ", j=" + j + "]"); > throw e; > } > > } > } > > JRE 8: > > Error occurred at length=2147483645 [i=2097151, j=1021] > Exception in thread "main" java.lang.OutOfMemoryError: Requested array > size exceeds VM limit > at java.util.Arrays.copyOf(Arrays.java:3332) > at > java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124) > at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:649) > at java.lang.StringBuilder.append(StringBuilder.java:202) > at > test.stringbuilder.TestStringbuilderOOM.main(TestStringbuilderOOM.java:13) > > JRE 11: > > Error occurred at length=1073741822 [i=1048575, j=1022] > Exception in thread "main" java.lang.OutOfMemoryError: Requested array > size exceeds VM limit > at java.base/java.util.Arrays.copyOf(Arrays.java:3745) > at > java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:172) > at > java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:748) > at java.base/java.lang.StringBuilder.append(StringBuilder.java:241) > at > TestJava11/test.stringbuilder.TestStringbuilderOOM.main(TestStringbuilderOOM.java:13) > > While StringBuilder is not a good choice for holding GBs of text, I > wonder that no effort is made to clamp the capacity to its limit when (I > assume) it is being doubled upon array expansion. > > Is this something that should be looked into or it can be safely ignored > (from JDK users POV)? > > Best regards, > Simeon From mcimadamore at openjdk.java.net Fri Aug 27 13:31:28 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 27 Aug 2021 13:31:28 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Sat, 21 Aug 2021 22:37:05 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Remove separate accessor for static vs instance method > > There is no effective difference when using MethodHandle::dropArgument for static method. Removing Static*Accessor and Instance*Accessor simplifies the implementation. Overall, seems like a solid piece of work. I did not review in full the intricacies with caller sensitive (as I don't know that area too much), but the general rewrite seems solid. One thing I had trouble with was the naming of the various method accessors - for instance, DirectMethodAccessorImpl vs. NativeMethodAccessorImpl vs. DelegatingMethodAccessorImpl vs. AdaptiveMethodAccessor (and there's more). It's not always easy to grasp from the method name which one is new and which one is old. Maybe sprinkling the `Handle` word on any accessor impl would help a bit with that. Similarly, I found the `ClassByteBuilder` name a bit weak, since that is meant to only create instance of custom MHInvokers. A more apt name will help there too. I also had some issues parsing the flow in `ReflectionFactory::newMethodAccessor` (and constructor, has similar issue): if (useNativeAccessor(method)) { return DirectMethodAccessorImpl.nativeAccessor(method, callerSensitive); } return MethodHandleAccessorFactory.newMethodAccessor(method, callerSensitive); ``` Why can't logic like this be encapsulated in a single factory call? E.g. it seems like the code is would like to abstract the differences between the various accessor implementations, but it doesn't seem to get all the way there (it's also possible I'm missing some constraint here). src/java.base/share/classes/jdk/internal/reflect/DirectConstructorAccessorImpl.java line 106: > 104: Object invokeImpl(Object[] args) throws Throwable { > 105: var mhInvoker = mhInvoker(); > 106: return switch (paramCount) { As @plevart observed, I'm also a bit surprised to see this, but I note your comments regarding performance - especially in cold case. Every adaptation counts, I guess, if you're not in the hot path. But let's make sure that the pay off to add the extra hand-specialized cases is worth it - I'd be surprised if spreading arguments is that expensive. src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 200: > 198: return MethodHandleAccessorFactory.newMethodAccessor(method, callerSensitive); > 199: } else { > 200: if (!useDirectMethodHandle && noInflation seems to me that the `!useDirectMethodHandle` is useless here (always false) ? src/java.base/share/classes/jdk/internal/reflect/VarHandleBooleanFieldAccessorImpl.java line 32: > 30: import java.lang.reflect.Modifier; > 31: > 32: abstract class VarHandleBooleanFieldAccessorImpl extends VarHandleFieldAccessorImpl { I wondered if we could avoid these hand specialized versions of VH accessors (one for each carrier type) by instead getting the getter/setter method handle out of the var handle, and adapt that so that its type matches Object... but then I realized that the `Field` API has sharp types in the getter/setters for primitives, so this seems like a forced move (maybe to revisit with Valhalla) :-(. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From shade at redhat.com Fri Aug 27 13:35:37 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 27 Aug 2021 15:35:37 +0200 Subject: StringBuilder OOMs earlier with JRE 11 compared to JRE 8 In-Reply-To: <99e1fc68-a602-0a31-a98a-03548fa63665@oracle.com> References: <99e1fc68-a602-0a31-a98a-03548fa63665@oracle.com> Message-ID: <13f8cc2f-a335-89c6-366f-d08a80507f59@redhat.com> On 8/27/21 3:25 PM, David Holmes wrote: >> Is this something that should be looked into or it can be safely ignored >> (from JDK users POV)? That is the unfortunate but expected trade-off from the Compact Strings work in JDK 9. That reworked the String storage to hold byte[] instead of char[]. When String is in non-Latin1 mode, then 1 character is placed in 2 bytes. But since both arrays can only hold ~2^32 elements, it means that the effective size for a String is twice lower than it used to. $ jdk11u-dev/bin/java TestSB Error occurred at length=1073741822 [i=1048575, j=1022] Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit If you keep the String* in Latin1, then the limit is the same at it "used to be", because every character takes 1 byte: - sb.append((char) j); + sb.append((char) (j & 0xFF)); $ jdk11u-dev/bin/java TestSB Error occurred at length=2147483645 [i=2097151, j=1021] Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit -- Thanks, -Aleksey From forax at univ-mlv.fr Fri Aug 27 13:39:47 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 27 Aug 2021 15:39:47 +0200 (CEST) Subject: StringBuilder OOMs earlier with JRE 11 compared to JRE 8 In-Reply-To: <99e1fc68-a602-0a31-a98a-03548fa63665@oracle.com> References: <99e1fc68-a602-0a31-a98a-03548fa63665@oracle.com> Message-ID: <856993571.668804.1630071587710.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "David Holmes" > To: "S" , "core-libs-dev" > Cc: "Andrey Loskutov" > Sent: Vendredi 27 Ao?t 2021 15:25:25 > Subject: Re: StringBuilder OOMs earlier with JRE 11 compared to JRE 8 > Hi Simeon, > > Redirecting this to core-libs-dev as it is not a serviceability issue. > (bcc serviceabillity-dev) Hi Simeon, in Java 9, the String representation was changed to use less memory if the characters can be encoded in ISO Latin 1, a side effect is that StringBuilder now uses a byte[] instead of a char[], hence the maximum size being half the one it was previously. > > Thanks, > David [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/AbstractStringBuilder.java#L63 > > On 27/08/2021 8:53 pm, S A wrote: >> Hi all, >> >> while working on https://bugs.eclipse.org/bugs/show_bug.cgi?id=575641 >> , I noticed that >> StringBuilder throws an OOM "half as early" in OpenJDK 11 (and 17 early >> access), when compared to OpenJDK 8. >> >> In particular, I ran the following snippet to see where the limit of >> appending to a StringBuilder is: >> >> StringBuilder sb = new StringBuilder(); >> long n = 8L * 1024L * 1024L; >> for (long i = 0; i < n; ++i) { >> int m = 1024; >> for (int j = 0; j < m; ++j) { >> int length = sb.length(); >> try { >> sb.append((char) j); >> } catch (Error e) { >> System.out.println("Error occurred at length=" + length + " [i=" + i + >> ", j=" + j + "]"); >> throw e; >> } >> >> } >> } >> >> JRE 8: >> >> Error occurred at length=2147483645 [i=2097151, j=1021] >> Exception in thread "main" java.lang.OutOfMemoryError: Requested array >> size exceeds VM limit >> at java.util.Arrays.copyOf(Arrays.java:3332) >> at >> java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124) >> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:649) >> at java.lang.StringBuilder.append(StringBuilder.java:202) >> at >> test.stringbuilder.TestStringbuilderOOM.main(TestStringbuilderOOM.java:13) >> >> JRE 11: >> >> Error occurred at length=1073741822 [i=1048575, j=1022] >> Exception in thread "main" java.lang.OutOfMemoryError: Requested array >> size exceeds VM limit >> at java.base/java.util.Arrays.copyOf(Arrays.java:3745) >> at >> java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:172) >> at >> java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:748) >> at java.base/java.lang.StringBuilder.append(StringBuilder.java:241) >> at >> TestJava11/test.stringbuilder.TestStringbuilderOOM.main(TestStringbuilderOOM.java:13) >> >> While StringBuilder is not a good choice for holding GBs of text, I >> wonder that no effort is made to clamp the capacity to its limit when (I >> assume) it is being doubled upon array expansion. >> >> Is this something that should be looked into or it can be safely ignored >> (from JDK users POV)? >> >> Best regards, > > Simeon From jai.forums2013 at gmail.com Fri Aug 27 14:16:55 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 27 Aug 2021 19:46:55 +0530 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> Message-ID: <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> On 26/08/21 5:06 pm, Alan Bateman wrote: > On 25/08/2021 15:57, Jaikiran Pai wrote: >> : >> >> Introducing an overloaded "store" which takes the timestamp or >> implicitly using the SOURCE_DATE_EPOCH environment variable would >> mean that the Properties.store(...) APIs will continue to always >> write out a Date representation into the outputstream. That >> effectively means that there will continue to be no way to disable >> writing out a (date) comment. More specifically, even if a user >> doesn't explicitly specify a comment, we would end up writing a >> default (date) comment. Do we want that? Or while we are doing these >> changes, should we introduce this ability of disabling writing out >> these date comments by default? That, IMO, can only be done by >> introducing new APIs instead of trying to slightly change the spec >> and the implementation of the current "store" APIs. After all, if any >> callers do want a date (and a reproducible one at that), they could >> always do so by passing that as a value for the "comment" parameter >> of these (new) "storeXXX" APIs. > > Properties save/store has always emitted a comment line with the > current date/time, it goes back to JDK 1.0. It's unfortunate that > newer store methods didn't re-examine this, also unfortunate that it > continued with 8859-1. In the discussion on jdk-dev about > reproducibility then I think we concluded that we don't want to change > the behavior of existing methods, hence the discussion on introducing > a new method. > > An new overload of store would give the maximum flexibility to new > code but it would require programs used in builds to use it > consistently. It's possible that libraries or tools that are using > Properties::store have no idea that they will ultimately be used in a > system that is trying to produce reproducible builds. So I have some > sympathy to the argument that there should a way to omit the date or > emit it as the Unix epoch time or a fixed value. This would mean > changing the spec to allow for some implementation means to do this, > and maybe an implNote that documents that it reads SOURCE_DATE_EPOCH. > I think Roger has misgivings about this. > > So let's list the options and the pros/cons and see if we can converge > on an approach. > Keeping aside the discussion about whether to introduce a new API or change the spec of the existing API, just for a moment, I think the main question is whether the current date comment that gets added by the store(...) is being used by anything out there, other than maybe for visual aspects while reading the properties file. From the discussions I have seen so far in the threads on openjdk and other mailing lists, I don't think anyone is using that comment for anything. So if we are indeed willing to change the spec of the store(...) API would it be too big/unacceptable a change to disable writing this date comment, at least in certain specific cases? With my limited usage of this API, my guess is that it's higly unlikely that it will break anything - after all it's a comment that was being added. The only potential breakages perhaps would be some scripts? But even those, I don't know how it would break them since anyway the date comment wasn't a constant value. Having said that, I looked at the patch that you pointed out[1] that got integrated into the JDK shipped in Ubuntu, for introducing reproducibility. I'm a bit surprised that the patched implementation decided to write out a formatted reproducible date instead of patching it to just not write the date. After all that IMO would have been much simpler and it would anyway have changed (removed) the exact same line in the code that was patched. So maybe I'm underestimating the usage of this date comment. So now coming to the API part of it. The potential ways to tackle this, that I could think of are as follows: 1. No new APIs to be added. Instead, the existing "store(...)" APIs specification will be changed to allow for reproducibility of the content that gets stored. The possible specification changes that we could attempt are: ??? 1a. The store(...) APIs by default will continue to write out a date comment, which represents the current date. In the case where SOURCE_DATE_EPOCH environment variable is set, the store(...) APIs will use that value to construct a (UTC) Date and write out the date comment. ??? ??? Pros: ??? ??? ---- ??? ??? - Existing callers of these APIs won't have to change their code to use this new semantics. ??? ??? - Tools/environments where reproducibility is required, can configure their environment (and they probably already would have) to set the SOURCE_DATE_EPOCH value. ??? ??? Cons: ??? ??? ---- ??? ??? - Behaviour of the same API will change dynamically based on the current environment of the process. However, this change in behaviour will not have functional impact on the generated output, since it's just a comment that changes. ??? ??? - There is no way to disable writing out comments to the output. i.e. even if user passes a null "comments" value to the APIs, there will always be the date comment in the output. ??? ??? - Requires spec change ??? OR ??? 1b. The store(...) APIs by default will continue to write out a date comment, which represents the current date. In the case where SOURCE_DATE_EPOCH environment variable is set, the store(...) APIs will _not_ write out any date comment. This is unlike 1a where we use the value of the environment variable to compute the Date. This alternate approach of not using the value but instead considering the presence of the environment variable being set, to not write out any date comment will still provide reproducibility and also will get rid of the unnecessary date comment. ??? ??? Pros: ??? ??? ---- ??? ??? - Existing callers of these APIs won't have to change their code to use this new semantics. ??? ??? - Tools/environments where reproducibility is required, can configure their environment (and they probably already would have) to set the SOURCE_DATE_EPOCH value. ??? ??? - The date comment will no longer end up in the output in environments where SOURCE_DATE_EPOCH is set (to any value). ??? ??? Cons: ??? ??? ---- ??? ??? - Just like 1a, the API output is determined by the current environment of the process. ??? ??? - Requires spec change. ??? ??? - The only way to generate a output without any comments would require setting the SOURCE_DATE_EPOCH even when reproducibility isn't a necessity. ??? ??? - When SOURCE_DATE_EPOCH is set, it will potentially (even if low probability) will breaks existing tools, code(?) or scripts that might be looking for some/any date in the comments of the output. ??? OR ??? 1c. The store(...) APIs which both currently take a "comments" parameter will write out the date comment only if the "comments" parameter is null. If the "comments" value is non-null, then, only that user passed comment will be written out to the output. ??? ??? Pros: ??? ??? ---- ??? ??? - There will now be a way for the callers to decide what exact comment appears in the output. It will either be their explicit comment or a default date comment. ??? ??? - For reproducibility, the callers can pass any reproducible comment of their choice and it no longer will be the responsibility of the store(...) API to decide what values for the comments would provide reproducibility of the output. ??? ??? (Note that the store(...) APIs will still take it upon themselves to write out the property keys in a reproducible order, that's now been decided in this discussion). ??? ??? Cons: ??? ??? ---- ??? ??? - This "may" require source code changes in callers' code. If callers are already passing a comment, they will no longer see the additional default date comment being added. However, if callers are not passing any comment, then they will continue to see the default date comment being added. In essence, callers who aren't passing any comment to the APIs, MUST change their code, if they want to stop seeing the date comment. ??? ??? - There is no way to disable writing out the comment to the output. Every single store(...) output will have a comment, either user supplied or the default date comment. ??? ??? - Requires spec change. ??? ??? - It will potentially (even if low probability) will breaks existing tools, code(?) or scripts that might be looking for some/any date in the comments of the output. ??? OR ??? 1d. Since we are thinking of changing the spec, I will include this option as well. The store(...) APIs which both current take the "comments" parameter will write out the caller passed comment only if the comment is non-null. No default comment will be written out. If the caller passed comment is null, then only the property key and values will be written out and the output will have no comments. ??? ??? Pros: ??? ??? ---- ??? ??? - No code changes needed in callers' code. ??? ??? - Gets rid of the (IMO, unnecessary) date comment from the output. ??? ??? - Callers now have full control over what comment gets written out. ??? ??? - There's now a way to disable writing out any comments to the output. If callers provide no comment, then only the property key values will be written out. ??? ??? - These APIs will now feel much more natural without any "if this, else that" or any "magic/default" comments appearing in the output. ??? ??? - Reproducibility of the comments is now decided by the callers and it no longer will be the responsibility of these store(...) APIs to come up with reproducible comments. ??? ??? (Note that the store(...) APIs will still take it upon themselves to write out the property keys in a reproducible order, that's now been decided in this discussion). ??? ??? Cons: ??? ??? ---- ??? ??? - Requires spec change. ??? ??? - It will potentially (even if low probability) will breaks existing tools, code(?) or scripts that might be looking for some/any date in the comments of the output. 2. Introduce a new (and only one) overloaded API as follows: ??? public void store(Writer writer, String comments, java.time.Instant dateComment) throws IOException; ??? This new API will write out an optional date comment, if the java.time.Instant parameter value is not null. In such a case where the Instant value is non-null, a java.time.ZonedDateTime will be computed out of the Instant value, for the "UTC" ZoneId and the string representation will be written out. In the case where the Instant parameter value is null, no date comment will be added in the output. ??? If the user passes the "comments" value, then that will be written out as the comments in the output. ??? Pros: ??? ---- ??? - No spec change needed ??? - Callers now have control over what date gets written out as a comment ??? - Callers now have control to completely disable writing out any comments, by passing null for both "comments" and the Instant parameters ??? - Reproducibility of the date comment will not be a concern of this new API and instead is controlled by the callers. ??? Cons: ??? ---- ??? - Requires code changes in callers' code. Potentially in much more places than any of other proposed options, since this is a completely new API. ??? - The new API still allows the Date comment to be written out, which IMO adds no value. Furthermore, this now introduces 2 ways to add a comment - one by passing value to the "comments" parameter and the other by passing a value to the "java.time.Instant" parameter. ??? - Introduces/continues with, avoidable, Instant parsing and date formatting logic/complexity into the new API. Let me know if I might have missed any other potential option. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=914278;filename=reproducible-properties-timestamp.patch;msg=5 -Jaikiran From jlaskey at openjdk.java.net Fri Aug 27 14:28:41 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 27 Aug 2021 14:28:41 GMT Subject: RFR: JDK-8272866 java.util.random package summary contains incorrect mixing function in table Message-ID: The table 'LXM Multipliers' at the end of the javadoc for the java.util.random package states that the mixing function is mixLea32 for all the 64/128-bit LCG based generators. This should be updated to mixLea64 for the 64/128-bit LCG generators. Only the L32X64MixRandom which uses a 32-bit LCG will use the mixLea32 mixing function. ------------- Commit messages: - Correct table entries Changes: https://git.openjdk.java.net/jdk/pull/5279/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5279&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272866 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5279.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5279/head:pull/5279 PR: https://git.openjdk.java.net/jdk/pull/5279 From daniel.fuchs at oracle.com Fri Aug 27 14:35:25 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 27 Aug 2021 15:35:25 +0100 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> Message-ID: <0791880f-dc75-8096-53dd-2c46b59c5448@oracle.com> Hi Jaikiran, What about writing the keys in natural ordering? Has that been abandoned, or will the implementation silently do it, or will it require a new API? AFAIU there are two problems that are hostile to reproducible builds: - date comments differ from store to store - property ordering may change from VM to VM due to differences in hashing best regards, -- daniel On 27/08/2021 15:16, Jaikiran Pai wrote: > > On 26/08/21 5:06 pm, Alan Bateman wrote: >> On 25/08/2021 15:57, Jaikiran Pai wrote: >>> : >>> >>> Introducing an overloaded "store" which takes the timestamp or >>> implicitly using the SOURCE_DATE_EPOCH environment variable would >>> mean that the Properties.store(...) APIs will continue to always >>> write out a Date representation into the outputstream. That >>> effectively means that there will continue to be no way to disable >>> writing out a (date) comment. More specifically, even if a user >>> doesn't explicitly specify a comment, we would end up writing a >>> default (date) comment. Do we want that? Or while we are doing these >>> changes, should we introduce this ability of disabling writing out >>> these date comments by default? That, IMO, can only be done by >>> introducing new APIs instead of trying to slightly change the spec >>> and the implementation of the current "store" APIs. After all, if any >>> callers do want a date (and a reproducible one at that), they could >>> always do so by passing that as a value for the "comment" parameter >>> of these (new) "storeXXX" APIs. >> >> Properties save/store has always emitted a comment line with the >> current date/time, it goes back to JDK 1.0. It's unfortunate that >> newer store methods didn't re-examine this, also unfortunate that it >> continued with 8859-1. In the discussion on jdk-dev about >> reproducibility then I think we concluded that we don't want to change >> the behavior of existing methods, hence the discussion on introducing >> a new method. >> >> An new overload of store would give the maximum flexibility to new >> code but it would require programs used in builds to use it >> consistently. It's possible that libraries or tools that are using >> Properties::store have no idea that they will ultimately be used in a >> system that is trying to produce reproducible builds. So I have some >> sympathy to the argument that there should a way to omit the date or >> emit it as the Unix epoch time or a fixed value. This would mean >> changing the spec to allow for some implementation means to do this, >> and maybe an implNote that documents that it reads SOURCE_DATE_EPOCH. >> I think Roger has misgivings about this. >> >> So let's list the options and the pros/cons and see if we can converge >> on an approach. >> > Keeping aside the discussion about whether to introduce a new API or > change the spec of the existing API, just for a moment, I think the main > question is whether the current date comment that gets added by the > store(...) is being used by anything out there, other than maybe for > visual aspects while reading the properties file. From the discussions I > have seen so far in the threads on openjdk and other mailing lists, I > don't think anyone is using that comment for anything. So if we are > indeed willing to change the spec of the store(...) API would it be too > big/unacceptable a change to disable writing this date comment, at least > in certain specific cases? With my limited usage of this API, my guess > is that it's higly unlikely that it will break anything - after all it's > a comment that was being added. The only potential breakages perhaps > would be some scripts? But even those, I don't know how it would break > them since anyway the date comment wasn't a constant value. Having said > that, I looked at the patch that you pointed out[1] that got integrated > into the JDK shipped in Ubuntu, for introducing reproducibility. I'm a > bit surprised that the patched implementation decided to write out a > formatted reproducible date instead of patching it to just not write the > date. After all that IMO would have been much simpler and it would > anyway have changed (removed) the exact same line in the code that was > patched. So maybe I'm underestimating the usage of this date comment. > > So now coming to the API part of it. The potential ways to tackle this, > that I could think of are as follows: > > 1. No new APIs to be added. Instead, the existing "store(...)" APIs > specification will be changed to allow for reproducibility of the > content that gets stored. The possible specification changes that we > could attempt are: > > ??? 1a. The store(...) APIs by default will continue to write out a > date comment, which represents the current date. In the case where > SOURCE_DATE_EPOCH environment variable is set, the store(...) APIs will > use that value to construct a (UTC) Date and write out the date comment. > > ??? ??? Pros: > ??? ??? ---- > ??? ??? - Existing callers of these APIs won't have to change their > code to use this new semantics. > ??? ??? - Tools/environments where reproducibility is required, can > configure their environment (and they probably already would have) to > set the SOURCE_DATE_EPOCH value. > > ??? ??? Cons: > ??? ??? ---- > ??? ??? - Behaviour of the same API will change dynamically based on > the current environment of the process. However, this change in > behaviour will not have functional impact on the generated output, since > it's just a comment that changes. > ??? ??? - There is no way to disable writing out comments to the > output. i.e. even if user passes a null "comments" value to the APIs, > there will always be the date comment in the output. > ??? ??? - Requires spec change > > ??? OR > > ??? 1b. The store(...) APIs by default will continue to write out a > date comment, which represents the current date. In the case where > SOURCE_DATE_EPOCH environment variable is set, the store(...) APIs will > _not_ write out any date comment. This is unlike 1a where we use the > value of the environment variable to compute the Date. This alternate > approach of not using the value but instead considering the presence of > the environment variable being set, to not write out any date comment > will still provide reproducibility and also will get rid of the > unnecessary date comment. > > ??? ??? Pros: > ??? ??? ---- > ??? ??? - Existing callers of these APIs won't have to change their > code to use this new semantics. > ??? ??? - Tools/environments where reproducibility is required, can > configure their environment (and they probably already would have) to > set the SOURCE_DATE_EPOCH value. > ??? ??? - The date comment will no longer end up in the output in > environments where SOURCE_DATE_EPOCH is set (to any value). > > ??? ??? Cons: > ??? ??? ---- > ??? ??? - Just like 1a, the API output is determined by the current > environment of the process. > ??? ??? - Requires spec change. > ??? ??? - The only way to generate a output without any comments would > require setting the SOURCE_DATE_EPOCH even when reproducibility isn't a > necessity. > ??? ??? - When SOURCE_DATE_EPOCH is set, it will potentially (even if > low probability) will breaks existing tools, code(?) or scripts that > might be looking for some/any date in the comments of the output. > > ??? OR > > ??? 1c. The store(...) APIs which both currently take a "comments" > parameter will write out the date comment only if the "comments" > parameter is null. If the "comments" value is non-null, then, only that > user passed comment will be written out to the output. > > ??? ??? Pros: > ??? ??? ---- > ??? ??? - There will now be a way for the callers to decide what exact > comment appears in the output. It will either be their explicit comment > or a default date comment. > ??? ??? - For reproducibility, the callers can pass any reproducible > comment of their choice and it no longer will be the responsibility of > the store(...) API to decide what values for the comments would provide > reproducibility of the output. > > ??? ??? (Note that the store(...) APIs will still take it upon > themselves to write out the property keys in a reproducible order, > that's now been decided in this discussion). > > ??? ??? Cons: > ??? ??? ---- > ??? ??? - This "may" require source code changes in callers' code. If > callers are already passing a comment, they will no longer see the > additional default date comment being added. However, if callers are not > passing any comment, then they will continue to see the default date > comment being added. In essence, callers who aren't passing any comment > to the APIs, MUST change their code, if they want to stop seeing the > date comment. > ??? ??? - There is no way to disable writing out the comment to the > output. Every single store(...) output will have a comment, either user > supplied or the default date comment. > ??? ??? - Requires spec change. > ??? ??? - It will potentially (even if low probability) will breaks > existing tools, code(?) or scripts that might be looking for some/any > date in the comments of the output. > > ??? OR > > ??? 1d. Since we are thinking of changing the spec, I will include this > option as well. The store(...) APIs which both current take the > "comments" parameter will write out the caller passed comment only if > the comment is non-null. No default comment will be written out. If the > caller passed comment is null, then only the property key and values > will be written out and the output will have no comments. > > ??? ??? Pros: > ??? ??? ---- > ??? ??? - No code changes needed in callers' code. > ??? ??? - Gets rid of the (IMO, unnecessary) date comment from the output. > ??? ??? - Callers now have full control over what comment gets written > out. > ??? ??? - There's now a way to disable writing out any comments to the > output. If callers provide no comment, then only the property key values > will be written out. > ??? ??? - These APIs will now feel much more natural without any "if > this, else that" or any "magic/default" comments appearing in the output. > ??? ??? - Reproducibility of the comments is now decided by the callers > and it no longer will be the responsibility of these store(...) APIs to > come up with reproducible comments. > > ??? ??? (Note that the store(...) APIs will still take it upon > themselves to write out the property keys in a reproducible order, > that's now been decided in this discussion). > > ??? ??? Cons: > ??? ??? ---- > ??? ??? - Requires spec change. > ??? ??? - It will potentially (even if low probability) will breaks > existing tools, code(?) or scripts that might be looking for some/any > date in the comments of the output. > > 2. Introduce a new (and only one) overloaded API as follows: > > ??? public void store(Writer writer, String comments, java.time.Instant > dateComment) throws IOException; > > ??? This new API will write out an optional date comment, if the > java.time.Instant parameter value is not null. In such a case where the > Instant value is non-null, a java.time.ZonedDateTime will be computed > out of the Instant value, for the "UTC" ZoneId and the string > representation will be written out. In the case where the Instant > parameter value is null, no date comment will be added in the output. > ??? If the user passes the "comments" value, then that will be written > out as the comments in the output. > > ??? Pros: > ??? ---- > ??? - No spec change needed > ??? - Callers now have control over what date gets written out as a > comment > ??? - Callers now have control to completely disable writing out any > comments, by passing null for both "comments" and the Instant parameters > ??? - Reproducibility of the date comment will not be a concern of this > new API and instead is controlled by the callers. > > ??? Cons: > ??? ---- > ??? - Requires code changes in callers' code. Potentially in much more > places than any of other proposed options, since this is a completely > new API. > ??? - The new API still allows the Date comment to be written out, > which IMO adds no value. Furthermore, this now introduces 2 ways to add > a comment - one by passing value to the "comments" parameter and the > other by passing a value to the "java.time.Instant" parameter. > ??? - Introduces/continues with, avoidable, Instant parsing and date > formatting logic/complexity into the new API. > > Let me know if I might have missed any other potential option. > > [1] > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=914278;filename=reproducible-properties-timestamp.patch;msg=5 > > > -Jaikiran > > From turbanoff at gmail.com Fri Aug 27 14:37:45 2021 From: turbanoff at gmail.com (Andrey Turbanov) Date: Fri, 27 Aug 2021 17:37:45 +0300 Subject: Possible ClassCastException in java.util.regex.Pattern.BmpCharPredicate#union(java.util.regex.Pattern.CharPredicate...) Message-ID: Hello. I found suspicious code in the method "java.util.regex.Pattern.BmpCharPredicate#union(java.util.regex.Pattern.CharPredicate...)" https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/regex/Pattern.java#L5639 static CharPredicate union(CharPredicate... predicates) { CharPredicate cp = ch -> { for (CharPredicate p : predicates) { if (!p.is(ch)) return false; } return true; }; for (CharPredicate p : predicates) { if (! (p instanceof BmpCharPredicate)) return cp; } return (BmpCharPredicate)cp; } Variable `cp` has type CharPredicate initially. And then it's casted to BmpCharPredicate. This cast always fails with ClassCastException when reached. Can reproduced in small sample class: public static void main(String[] args) { CharPredicate result = BmpCharPredicate.union(); System.out.println(result); } interface CharPredicate { boolean is(int ch); } interface BmpCharPredicate extends CharPredicate { static CharPredicate union(CharPredicate... predicates) { CharPredicate cp = ch -> true; for (CharPredicate p : predicates) { if (! (p instanceof BmpCharPredicate)) return cp; } return (BmpCharPredicate)cp; } } Exception in thread "main" java.lang.ClassCastException: class org.RegexpBug$BmpCharPredicate$$Lambda$14/0x0000000800c028f0 cannot be cast to class org.RegexpBug$BmpCharPredicate (org.RegexpBug$BmpCharPredicate$$Lambda$14/0x0000000800c028f0 and org.RegexpBug$BmpCharPredicate are in unnamed module of loader 'app') at org.RegexpBug$BmpCharPredicate.union(RegexpBug.java:20) at org.RegexpBug.main(RegexpBug.java:5) As I can see this method is never used. Perhaps it should be removed? Andrey Turbanov From jai.forums2013 at gmail.com Fri Aug 27 14:42:48 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 27 Aug 2021 20:12:48 +0530 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <0791880f-dc75-8096-53dd-2c46b59c5448@oracle.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> <0791880f-dc75-8096-53dd-2c46b59c5448@oracle.com> Message-ID: Hello Daniel, On 27/08/21 8:05 pm, Daniel Fuchs wrote: > Hi Jaikiran, > > What about writing the keys in natural ordering? > Has that been abandoned, or will the implementation silently do it, > or will it require a new API? > In the discussion so far, there has been no opposition to changing the implementation of these existing store(...) APIs to use natural sorting order for writing out the keys. In fact, there seems to be an agreement that the current 2 store(...) API implementations and any new API that we might introduce to tackle the date comment issue, must use natural key ordering for writing out the properties. Whether or not this implementation detail will be noted/mentioned in the spec of these APIs hasn't yet been decided. So it's just the date comment which requires some kind of agreement on how we deal with it. -Jaikiran From jai.forums2013 at gmail.com Fri Aug 27 14:48:03 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 27 Aug 2021 20:18:03 +0530 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> <0791880f-dc75-8096-53dd-2c46b59c5448@oracle.com> Message-ID: <46c690b2-747e-3f0d-9471-f2cc59875d13@gmail.com> On 27/08/21 8:12 pm, Jaikiran Pai wrote: > Hello Daniel, > > On 27/08/21 8:05 pm, Daniel Fuchs wrote: >> Hi Jaikiran, >> >> What about writing the keys in natural ordering? >> Has that been abandoned, or will the implementation silently do it, >> or will it require a new API? >> > In the discussion so far, there has been no opposition to changing the > implementation of these existing store(...) APIs to use natural > sorting order for writing out the keys. Just to avoid any kind of confusion - when I say natural sorting order of keys, I mean the implementation will be changed to lexicographically compare the keys as noted in the compareTo[1] method of java.lang.String. [1] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/String.html#compareTo(java.lang.String) -Jaikiran From roger.riggs at oracle.com Fri Aug 27 14:53:04 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 27 Aug 2021 10:53:04 -0400 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> Message-ID: Hi, It would seem useful in the long term to move the inclusion of the date to be part of the comment and it would be up to the caller of store() to include a date (as a string) where ever appropriate. And drop the writing hardcoded date; but its not clear how to get there given compatibility concerns. One more option would be to add a separate method on a Properties instance to set or omit the date written by store(). It would not have a global affect on all Properties.store calls but would be specific to an instance. It would still require callers to have access to the instance but not have to modify the immediate caller of store(). Without a better understanding of the uses that affect reproducible builds, this might not be able to address them all. There is likely no good (clean) solution since the reproducible build goal implies a global modification of behavior and all the alternatives that are specific to Properties have only a local effect. $.02, Roger On 8/27/21 10:16 AM, Jaikiran Pai wrote: > > On 26/08/21 5:06 pm, Alan Bateman wrote: >> On 25/08/2021 15:57, Jaikiran Pai wrote: >>> : >>> >>> Introducing an overloaded "store" which takes the timestamp or >>> implicitly using the SOURCE_DATE_EPOCH environment variable would >>> mean that the Properties.store(...) APIs will continue to always >>> write out a Date representation into the outputstream. That >>> effectively means that there will continue to be no way to disable >>> writing out a (date) comment. More specifically, even if a user >>> doesn't explicitly specify a comment, we would end up writing a >>> default (date) comment. Do we want that? Or while we are doing these >>> changes, should we introduce this ability of disabling writing out >>> these date comments by default? That, IMO, can only be done by >>> introducing new APIs instead of trying to slightly change the spec >>> and the implementation of the current "store" APIs. After all, if >>> any callers do want a date (and a reproducible one at that), they >>> could always do so by passing that as a value for the "comment" >>> parameter of these (new) "storeXXX" APIs. >> >> Properties save/store has always emitted a comment line with the >> current date/time, it goes back to JDK 1.0. It's unfortunate that >> newer store methods didn't re-examine this, also unfortunate that it >> continued with 8859-1. In the discussion on jdk-dev about >> reproducibility then I think we concluded that we don't want to >> change the behavior of existing methods, hence the discussion on >> introducing a new method. >> >> An new overload of store would give the maximum flexibility to new >> code but it would require programs used in builds to use it >> consistently. It's possible that libraries or tools that are using >> Properties::store have no idea that they will ultimately be used in a >> system that is trying to produce reproducible builds. So I have some >> sympathy to the argument that there should a way to omit the date or >> emit it as the Unix epoch time or a fixed value. This would mean >> changing the spec to allow for some implementation means to do this, >> and maybe an implNote that documents that it reads SOURCE_DATE_EPOCH. >> I think Roger has misgivings about this. >> >> So let's list the options and the pros/cons and see if we can >> converge on an approach. >> > Keeping aside the discussion about whether to introduce a new API or > change the spec of the existing API, just for a moment, I think the > main question is whether the current date comment that gets added by > the store(...) is being used by anything out there, other than maybe > for visual aspects while reading the properties file. From the > discussions I have seen so far in the threads on openjdk and other > mailing lists, I don't think anyone is using that comment for > anything. So if we are indeed willing to change the spec of the > store(...) API would it be too big/unacceptable a change to disable > writing this date comment, at least in certain specific cases? With my > limited usage of this API, my guess is that it's higly unlikely that > it will break anything - after all it's a comment that was being > added. The only potential breakages perhaps would be some scripts? But > even those, I don't know how it would break them since anyway the date > comment wasn't a constant value. Having said that, I looked at the > patch that you pointed out[1] that got integrated into the JDK shipped > in Ubuntu, for introducing reproducibility. I'm a bit surprised that > the patched implementation decided to write out a formatted > reproducible date instead of patching it to just not write the date. > After all that IMO would have been much simpler and it would anyway > have changed (removed) the exact same line in the code that was > patched. So maybe I'm underestimating the usage of this date comment. > > So now coming to the API part of it. The potential ways to tackle > this, that I could think of are as follows: > > 1. No new APIs to be added. Instead, the existing "store(...)" APIs > specification will be changed to allow for reproducibility of the > content that gets stored. The possible specification changes that we > could attempt are: > > ??? 1a. The store(...) APIs by default will continue to write out a > date comment, which represents the current date. In the case where > SOURCE_DATE_EPOCH environment variable is set, the store(...) APIs > will use that value to construct a (UTC) Date and write out the date > comment. > > ??? ??? Pros: > ??? ??? ---- > ??? ??? - Existing callers of these APIs won't have to change their > code to use this new semantics. > ??? ??? - Tools/environments where reproducibility is required, can > configure their environment (and they probably already would have) to > set the SOURCE_DATE_EPOCH value. > > ??? ??? Cons: > ??? ??? ---- > ??? ??? - Behaviour of the same API will change dynamically based on > the current environment of the process. However, this change in > behaviour will not have functional impact on the generated output, > since it's just a comment that changes. > ??? ??? - There is no way to disable writing out comments to the > output. i.e. even if user passes a null "comments" value to the APIs, > there will always be the date comment in the output. > ??? ??? - Requires spec change > > ??? OR > > ??? 1b. The store(...) APIs by default will continue to write out a > date comment, which represents the current date. In the case where > SOURCE_DATE_EPOCH environment variable is set, the store(...) APIs > will _not_ write out any date comment. This is unlike 1a where we use > the value of the environment variable to compute the Date. This > alternate approach of not using the value but instead considering the > presence of the environment variable being set, to not write out any > date comment will still provide reproducibility and also will get rid > of the unnecessary date comment. > > ??? ??? Pros: > ??? ??? ---- > ??? ??? - Existing callers of these APIs won't have to change their > code to use this new semantics. > ??? ??? - Tools/environments where reproducibility is required, can > configure their environment (and they probably already would have) to > set the SOURCE_DATE_EPOCH value. > ??? ??? - The date comment will no longer end up in the output in > environments where SOURCE_DATE_EPOCH is set (to any value). > > ??? ??? Cons: > ??? ??? ---- > ??? ??? - Just like 1a, the API output is determined by the current > environment of the process. > ??? ??? - Requires spec change. > ??? ??? - The only way to generate a output without any comments would > require setting the SOURCE_DATE_EPOCH even when reproducibility isn't > a necessity. > ??? ??? - When SOURCE_DATE_EPOCH is set, it will potentially (even if > low probability) will breaks existing tools, code(?) or scripts that > might be looking for some/any date in the comments of the output. > > ??? OR > > ??? 1c. The store(...) APIs which both currently take a "comments" > parameter will write out the date comment only if the "comments" > parameter is null. If the "comments" value is non-null, then, only > that user passed comment will be written out to the output. > > ??? ??? Pros: > ??? ??? ---- > ??? ??? - There will now be a way for the callers to decide what exact > comment appears in the output. It will either be their explicit > comment or a default date comment. > ??? ??? - For reproducibility, the callers can pass any reproducible > comment of their choice and it no longer will be the responsibility of > the store(...) API to decide what values for the comments would > provide reproducibility of the output. > > ??? ??? (Note that the store(...) APIs will still take it upon > themselves to write out the property keys in a reproducible order, > that's now been decided in this discussion). > > ??? ??? Cons: > ??? ??? ---- > ??? ??? - This "may" require source code changes in callers' code. If > callers are already passing a comment, they will no longer see the > additional default date comment being added. However, if callers are > not passing any comment, then they will continue to see the default > date comment being added. In essence, callers who aren't passing any > comment to the APIs, MUST change their code, if they want to stop > seeing the date comment. > ??? ??? - There is no way to disable writing out the comment to the > output. Every single store(...) output will have a comment, either > user supplied or the default date comment. > ??? ??? - Requires spec change. > ??? ??? - It will potentially (even if low probability) will breaks > existing tools, code(?) or scripts that might be looking for some/any > date in the comments of the output. > > ??? OR > > ??? 1d. Since we are thinking of changing the spec, I will include > this option as well. The store(...) APIs which both current take the > "comments" parameter will write out the caller passed comment only if > the comment is non-null. No default comment will be written out. If > the caller passed comment is null, then only the property key and > values will be written out and the output will have no comments. > > ??? ??? Pros: > ??? ??? ---- > ??? ??? - No code changes needed in callers' code. > ??? ??? - Gets rid of the (IMO, unnecessary) date comment from the > output. > ??? ??? - Callers now have full control over what comment gets written > out. > ??? ??? - There's now a way to disable writing out any comments to the > output. If callers provide no comment, then only the property key > values will be written out. > ??? ??? - These APIs will now feel much more natural without any "if > this, else that" or any "magic/default" comments appearing in the output. > ??? ??? - Reproducibility of the comments is now decided by the > callers and it no longer will be the responsibility of these > store(...) APIs to come up with reproducible comments. > > ??? ??? (Note that the store(...) APIs will still take it upon > themselves to write out the property keys in a reproducible order, > that's now been decided in this discussion). > > ??? ??? Cons: > ??? ??? ---- > ??? ??? - Requires spec change. > ??? ??? - It will potentially (even if low probability) will breaks > existing tools, code(?) or scripts that might be looking for some/any > date in the comments of the output. > > 2. Introduce a new (and only one) overloaded API as follows: > > ??? public void store(Writer writer, String comments, > java.time.Instant dateComment) throws IOException; > > ??? This new API will write out an optional date comment, if the > java.time.Instant parameter value is not null. In such a case where > the Instant value is non-null, a java.time.ZonedDateTime will be > computed out of the Instant value, for the "UTC" ZoneId and the string > representation will be written out. In the case where the Instant > parameter value is null, no date comment will be added in the output. > ??? If the user passes the "comments" value, then that will be written > out as the comments in the output. > > ??? Pros: > ??? ---- > ??? - No spec change needed > ??? - Callers now have control over what date gets written out as a > comment > ??? - Callers now have control to completely disable writing out any > comments, by passing null for both "comments" and the Instant parameters > ??? - Reproducibility of the date comment will not be a concern of > this new API and instead is controlled by the callers. > > ??? Cons: > ??? ---- > ??? - Requires code changes in callers' code. Potentially in much more > places than any of other proposed options, since this is a completely > new API. > ??? - The new API still allows the Date comment to be written out, > which IMO adds no value. Furthermore, this now introduces 2 ways to > add a comment - one by passing value to the "comments" parameter and > the other by passing a value to the "java.time.Instant" parameter. > ??? - Introduces/continues with, avoidable, Instant parsing and date > formatting logic/complexity into the new API. > > Let me know if I might have missed any other potential option. > > [1] > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=914278;filename=reproducible-properties-timestamp.patch;msg=5 > > -Jaikiran > > From javalists at cbfiddle.com Fri Aug 27 14:55:33 2021 From: javalists at cbfiddle.com (Alan Snyder) Date: Fri, 27 Aug 2021 07:55:33 -0700 Subject: what does the spec say about file paths that are too long? In-Reply-To: <868b7850-4104-3491-497e-a437fb43a3a3@oracle.com> References: <7CBCF03A-AEBA-46EE-BCBD-4ED9D1C97450@cbfiddle.com> <81398B70-EC5E-4E06-9790-85CE56199591@cbfiddle.com> <444a66bd-a4fe-edef-e620-1ff8ddd6b1cc@oracle.com> <3B9D5E22-20F2-4CEA-B824-37F421FDFED2@cbfiddle.com> <868b7850-4104-3491-497e-a437fb43a3a3@oracle.com> Message-ID: <258444D8-9E85-4A2C-998F-0C690F52E1D7@cbfiddle.com> > On Aug 26, 2021, at 8:57 AM, Alan Bateman wrote: > > On 26/08/2021 15:43, Alan Snyder wrote: >> As I said, I think it's great that we agree an exception should be thrown when an over-length path is used in an actual file operation. >> >> However, would it not be better to have that in the specification, rather than relying on the opinions of individual engineers expressed in a thread on a mailing list? >> >> And would it not also be better if there were test cases? > You are welcome to propose additional tests if you want. > Thanks. However, I think the specification issue should be addressed first. One writes test programs to find cases where the code does not obey the specification. It?s hard to do that if the specification does not address the behavior of interest. >> Granted that path operations cannot in general predict when a path will be of usable length in a file operation, the question remains whether path operations should report over-length paths in those cases where it can be determined. Is it not the case that some OS APIs have hard limits on path length (unrelated to limits imposed by the file system itself)? For a file provider using such an API, would throwing an exception when that limit is exceeded be a good idea or a bad idea? > I don't think this is feasible or a compatible change. It seems this case is already covered, at least in part. From the spec for FileSystem.getPath: An implementation may choose to reject path strings that contain names that are longer than those allowed by any file store. All that is missing is the case where the entire path exceeds some hard limit. From mgronlun at openjdk.java.net Fri Aug 27 15:23:35 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 27 Aug 2021 15:23:35 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with three additional commits since the last revision: - localize - cleanup - FinalizerStatistics ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/e6b786f1..fd86899f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=08-09 Stats: 457 lines in 17 files changed: 190 ins; 222 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Fri Aug 27 15:23:36 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 27 Aug 2021 15:23:36 GMT Subject: RFR: 8266936: Add a finalization JFR event [v9] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 12:58:29 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. >> >> We also like to assist users in replacing and mitigating uses in non-JDK code. >> >> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize(). >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > Model as finalizerService Sorry for the wide distribution, but this became necessary as the PR touches many component areas, if only some with minor parts. Below is a high-level description of this suggested PR. // Design Per class statistics about finalizers is implemented by services/finalizerServices. The concept of a "service" is modelled after other management components, such as ClassLoadingService and RuntimeService. Allocation of an object with a class overriding finalize() with a non-empty finalize() method, is hooked by the runtime using bytecode "_return_register_finalizer", which lets it enter InstanceKlass::register_finalizer(). A hook is added to InstanceKlass::register_finalizer() to notify FinalizerService which increments the number of "objects_on_heap" for the corresponding InstanceKlass. The dedicated finalizer thread is responsible for running the finalizer methods for referent objects whose java.lang.ref.Finalizers have been enqueued for finalization by the GC. It will get a native method to report the completion state of a finalizer back to the VM. FinalizerService will then increase the total number of finalizers run and decrease the number of outstanding objects on the heap for the corresponding InstanceKlass. Class Unloading support is in place by adding a hook into SystemDictionary::do_unloading(). The existing JFR class unloading support is extended to also report a FinalizerStatistic event for the class unloading before its corresponding FinalizerEntry is purged. -Xlog:finalize is added for Unified Logging support. // JFR event output jdk.FinalizerStatistics: Event:jdk.FinalizerStatistics { startTime = 14:22:06.683 finalizableClass = jdk.jfr.event.runtime.TestFinalizerStatisticsEvent$TestClassOverridingFinalize (classLoader = app) codeSource = "file:///D:/utilities/jtreg/runtime_artifacts/work/classes/jdk/jfr/event/runtime/TestFinalizerStatisticsEvent.d/" objects = 0 totalFinalizersRun = 2 } Event:jdk.FinalizerStatistics { startTime = 14:22:07.244 finalizableClass = jdk.jfr.internal.RepositoryChunk (classLoader = bootstrap) codeSource = N/A objects = 3 totalFinalizersRun = 0 } // Xlog:finalizer output: [4.517s][info][finalizer] Registered object (0x0000000073fbf594) of class jdk.jfr.internal.RepositoryChunk as finalizable [4.737s][info][finalizer] Registered object (0x000000007ee4f130) of class jdk.jfr.event.runtime.TestFinalizerStatisticsEvent$TestClassOverridingFinalize as finalizable [5.002s][info][finalizer] Finalizer was run for object (0x000000007ee4f130) of class jdk.jfr.event.runtime.TestFinalizerStatisticsEvent$TestClassOverridingFinalize [5.004s][info][finalizer] Registered object (0x0000000056bf003b) of class jdk.jfr.internal.RepositoryChunk as finalizable [5.127s][info][finalizer] Registered object (0x0000000014d51169) of class jdk.jfr.event.runtime.TestFinalizerStatisticsEvent$TestClassOverridingFinalize as finalizable [5.325s][info][finalizer] Finalizer was run for object (0x0000000014d51169) of class jdk.jfr.event.runtime.TestFinalizerStatisticsEvent$TestClassOverridingFinalize [5.691s][info][finalizer] Registered object (0x000000002baaa366) of class jdk.jfr.internal.RepositoryChunk as finalizable [5.696s][info][finalizer] Registered object (0x0000000075b10e10) of class jdk.jfr.event.runtime.TestFinalizerStatisticsEvent$TestClassOverridingFinalize as finalizable [5.891s][info][finalizer] Finalizer was run for object (0x0000000075b10e10) of class jdk.jfr.event.runtime.TestFinalizerStatisticsEvent$TestClassOverridingFinalize [6.121s][info][finalizer] Registered object (0x000000003c036ecb) of class jdk.jfr.internal.ChunksChannel as finalizable [6.342s][info][finalizer] Finalizer was run for object (0x000000003c036ecb) of class jdk.jfr.internal.ChunksChannel // Misc JfrSymbolTable - an existing JFR internal component repackaged and published to let other JFR native components re-use the symbol ids (more specifically for the CodeSource in this case). ClassLoadingService - some parts needed to have better conditional compilation and runtime support for running the JVM when excluding JVM feature 'management'. jmm.h - is a private interface between the JVM and the JDK, so a CSR should not be necessary for the update and version change. // Performance The construction of objects with non-empty finalizers is already relatively slow, in that the VM intercepts the allocation using bytecode _return_register_finalizer, where it has to enter the VM. There, another call is made back into Java to construct a java.lang.ref.Finalizer instance. Therefore, the overhead of placing the hook in InstanceKlass::register_finalizer() is considered minimal from a performance perspective (it performs a lookup in a concurrenthashtable and a CAS). The reporting back to the VM on finalization complete is performed only by the dedicated FinalizerThread. It introduces some additional work, but FinalizerThread is not considered performance-sensitive because of the indeterministic nature of when finalizers are run (if at all). // Extensibility The data saved in FinalizerService can also easily be exposed via JMX (java.lang.Management), but it is not part of this change. The FinalizerEntry struct can also be extended, for example, with performance data. An attempt was made to see if it was possible to attribute CPU time as well. However, the relatively short-lived character of a typical finalize() method combined with existing thread CPU timing APIs, which proved too coarse-grained (at least on some platforms?), did not give valuable data. Another possibility could be to attribute some wall-clock time info, but it is currently unclear how useful that is. Also, the selection of what time source to use is another complexity to consider. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From pavel.rappo at oracle.com Fri Aug 27 15:37:54 2021 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 27 Aug 2021 15:37:54 +0000 Subject: Possible ClassCastException in java.util.regex.Pattern.BmpCharPredicate#union(java.util.regex.Pattern.CharPredicate...) In-Reply-To: References: Message-ID: <9920D921-C228-4C4D-BBEB-B536FD9566B0@oracle.com> Has that method been ever used? If nothing else its name seems strange. To me, a union has OR semantics, not AND. > On 27 Aug 2021, at 15:37, Andrey Turbanov wrote: > > Hello. > I found suspicious code in the method > "java.util.regex.Pattern.BmpCharPredicate#union(java.util.regex.Pattern.CharPredicate...)" > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/regex/Pattern.java#L5639 > > static CharPredicate union(CharPredicate... predicates) { > CharPredicate cp = ch -> { > for (CharPredicate p : predicates) { > if (!p.is(ch)) > return false; > } > return true; > }; > for (CharPredicate p : predicates) { > if (! (p instanceof BmpCharPredicate)) > return cp; > } > return (BmpCharPredicate)cp; > } > > Variable `cp` has type CharPredicate initially. And then it's casted > to BmpCharPredicate. This cast always fails with ClassCastException > when reached. > > Can reproduced in small sample class: > > public static void main(String[] args) { > CharPredicate result = BmpCharPredicate.union(); > System.out.println(result); > } > > interface CharPredicate { > boolean is(int ch); > } > > interface BmpCharPredicate extends CharPredicate { > static CharPredicate union(CharPredicate... predicates) { > CharPredicate cp = ch -> true; > for (CharPredicate p : predicates) { > if (! (p instanceof BmpCharPredicate)) > return cp; > } > return (BmpCharPredicate)cp; > } > } > > > Exception in thread "main" java.lang.ClassCastException: class > org.RegexpBug$BmpCharPredicate$$Lambda$14/0x0000000800c028f0 cannot be > cast to class org.RegexpBug$BmpCharPredicate > (org.RegexpBug$BmpCharPredicate$$Lambda$14/0x0000000800c028f0 and > org.RegexpBug$BmpCharPredicate are in unnamed module of loader 'app') > at org.RegexpBug$BmpCharPredicate.union(RegexpBug.java:20) > at org.RegexpBug.main(RegexpBug.java:5) > > As I can see this method is never used. Perhaps it should be removed? > > > Andrey Turbanov From rriggs at openjdk.java.net Fri Aug 27 15:58:21 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 27 Aug 2021 15:58:21 GMT Subject: RFR: JDK-8272866 java.util.random package summary contains incorrect mixing function in table In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 14:20:32 GMT, Jim Laskey wrote: > The table 'LXM Multipliers' at the end of the javadoc for the java.util.random package states that the mixing function is mixLea32 for all the 64/128-bit LCG based generators. This should be updated to mixLea64 for the 64/128-bit LCG generators. Only the L32X64MixRandom which uses a 32-bit LCG will use the mixLea32 mixing function. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5279 From bpb at openjdk.java.net Fri Aug 27 16:12:33 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 27 Aug 2021 16:12:33 GMT Subject: Integrated: 8272541: Incorrect overflow test in Toom-Cook branch of BigInteger multiplication In-Reply-To: References: Message-ID: On Mon, 16 Aug 2021 21:00:00 GMT, Brian Burkhalter wrote: > Please consider this change which would modify a conditional `a + b > c` where the left side variables are `int`s and the right side is `(long)Integer.MAX_VALUE + 1`. The change is to cast the left side variables to `long`s. This pull request has now been integrated. Changeset: d1aeca11 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/d1aeca117ccc4334d67b2692ff087a9f8d808a59 Stats: 30 lines in 2 files changed: 18 ins; 3 del; 9 mod 8272541: Incorrect overflow test in Toom-Cook branch of BigInteger multiplication Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/5130 From rfscholte at apache.org Fri Aug 27 17:38:28 2021 From: rfscholte at apache.org (Robert Scholte) Date: Fri, 27 Aug 2021 17:38:28 +0000 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> Message-ID: I've dropped this topic on the Maven Dev mailinglist as well[1]. The responses are mixed, so I'd prefer to refer to the mailinglist instead of summarizing the responses here. This will prevent that those opinions are considered my opinions. Thanks, Robert [1] https://lists.apache.org/thread.html/r687bca66bb548d3a13ea665fb7202daf9710564802fa497a4b34d81e%40%3Cdev.maven.apache.org%3E From fdesu at protonmail.com Fri Aug 27 17:39:00 2021 From: fdesu at protonmail.com (Sergei Ustimenko) Date: Fri, 27 Aug 2021 17:39:00 +0000 Subject: Replace StringBuffers to StringBuilders in tests In-Reply-To: References: <6964840b-4d78-3d91-9929-bba740cc0d93@oracle.com> Message-ID: Hi Daniel and David, Thanks for your opinions and for sharing more context - it is definitely clearer now! I am glad that I reached out to the mailing list first instead of going ahead with the changes! :) Regards, Sergei Sent with ProtonMail Secure Email. ??????? Original Message ??????? On Friday, August 27th, 2021 at 15:14, David Holmes wrote: > On 27/08/2021 8:42 pm, Daniel Fuchs wrote: > > > Hi Sergei, > > > > I wouldn't bother replacing StringBuffers with StringDuilders in tests. > > > > It seems a bit gratuitous - and possibly could complicate future > > > > tests backports. > > > > But that's my personal opinion. Others might disagree. > > I agree with you. Complete waste of time and effort for zero benefit > > IMO. Sorry Sergei. > > Cheers, > > David > > > best regards, > > > > -- daniel > > > > On 27/08/2021 11:00, Sergei Ustimenko wrote: > > > > > Hi all, > > > > > > Some tests use StringBuffers instead of StringBuilders where > > > > > > additional thread-safety > > > > > > is not required as e.g. in > > > > > > test/jdk/sun/util/resources/TimeZone/Bug4640234.java:82 : > > > > > > ... > > > > > > StringBuffer errors > > > > > > = > > > > > > new > > > > > > StringBuffer( > > > > > > "" > > > > > > ); > > > > > > StringBuffer warnings > > > > > > = > > > > > > new > > > > > > StringBuffer( > > > > > > "" > > > > > > ); > > > > > > ... > > > > > > There were some efforts to clean up core libs (e.g. java.base module in > > > > > > https://github.com/openjdk/jdk/pull/2922) and I've noticed some tests > > > > > > that could be > > > > > > improved as well. > > > > > > Now there are about 300 tests for different modules that in general > > > > > > use StringBuffers > > > > > > (most probably some of them not without a reason) so is it something > > > > > > worth looking > > > > > > into? What you think about it? > > > > > > Regards, > > > > > > Sergei From roger.riggs at oracle.com Fri Aug 27 18:46:42 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 27 Aug 2021 14:46:42 -0400 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> Message-ID: Hi, I'm finding the idea of removing the hardcoded timestamp and adding a property to restore compatibility strangely attractive.? I don't think we've yet found a case where the timestamp was needed (but need to keep looking). (Adding a timestamp to the comment by the caller of store() is already possible) It will reveal where the timestamp is needed (via some kind of failure, though perhaps not a timely one) and includes a fallback mechanism when needed. It will generally cleanup up the behavior of an old API. The other approaches make new work for developers based on unclear requirements. $.02, Roger On 8/27/21 1:38 PM, Robert Scholte wrote: > I've dropped this topic on the Maven Dev mailinglist as well[1]. > The responses are mixed, so I'd prefer to refer to the mailinglist > instead of summarizing the responses here. > This will prevent that those opinions are considered my opinions. > > Thanks, > Robert > > [1] > https://lists.apache.org/thread.html/r687bca66bb548d3a13ea665fb7202daf9710564802fa497a4b34d81e%40%3Cdev.maven.apache.org%3E > From jlaskey at openjdk.java.net Fri Aug 27 18:49:28 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 27 Aug 2021 18:49:28 GMT Subject: Integrated: JDK-8272866 java.util.random package summary contains incorrect mixing function in table In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 14:20:32 GMT, Jim Laskey wrote: > The table 'LXM Multipliers' at the end of the javadoc for the java.util.random package states that the mixing function is mixLea32 for all the 64/128-bit LCG based generators. This should be updated to mixLea64 for the 64/128-bit LCG generators. Only the L32X64MixRandom which uses a 32-bit LCG will use the mixLea32 mixing function. This pull request has now been integrated. Changeset: e66c8afb Author: Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/e66c8afb59b57c4546656efa97f723f084964330 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod 8272866: java.util.random package summary contains incorrect mixing function in table Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/5279 From github.com+70726043+rgiulietti at openjdk.java.net Fri Aug 27 19:01:38 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Fri, 27 Aug 2021 19:01:38 GMT Subject: RFR: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family Message-ID: Please review this PR to add officially endorsed `ceilDiv()` and `ceilMod()` methods do `j.l.[Strict]Math`. Beside adding fresh tests to `test/jdk/java/lang/Math/DivModTests.java`, this PR also corrects small typos in it and exercises tests that were already present but which were never invoked. Let me know if this is acceptable for a test or if there's a need of a separate issue in the JBS. ------------- Commit messages: - 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family Changes: https://git.openjdk.java.net/jdk/pull/5285/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5285&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271602 Stats: 871 lines in 3 files changed: 850 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/5285.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5285/head:pull/5285 PR: https://git.openjdk.java.net/jdk/pull/5285 From github.com+70726043+rgiulietti at openjdk.java.net Fri Aug 27 20:08:37 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Fri, 27 Aug 2021 20:08:37 GMT Subject: RFR: 8273091: Doc of [Strict]Math.floorDiv(long, int) erroneously documents int in @return tag Message-ID: This PR corrects a typo in the JavaDoc of `[Strict]Math.floorDiv(long,int)`. ------------- Commit messages: - 8273091: Doc of [Strict]Math.floorDiv(long,int) erroneously documents int in @return tag Changes: https://git.openjdk.java.net/jdk/pull/5287/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5287&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273091 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5287.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5287/head:pull/5287 PR: https://git.openjdk.java.net/jdk/pull/5287 From darcy at openjdk.java.net Fri Aug 27 20:16:23 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 27 Aug 2021 20:16:23 GMT Subject: RFR: 8273091: Doc of [Strict]Math.floorDiv(long, int) erroneously documents int in @return tag In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 20:02:48 GMT, Raffaello Giulietti wrote: > This PR corrects a typo in the JavaDoc of `[Strict]Math.floorDiv(long,int)`. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5287 From bpb at openjdk.java.net Fri Aug 27 20:16:23 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 27 Aug 2021 20:16:23 GMT Subject: RFR: 8273091: Doc of [Strict]Math.floorDiv(long, int) erroneously documents int in @return tag In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 20:02:48 GMT, Raffaello Giulietti wrote: > This PR corrects a typo in the JavaDoc of `[Strict]Math.floorDiv(long,int)`. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5287 From darcy at openjdk.java.net Fri Aug 27 20:22:31 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 27 Aug 2021 20:22:31 GMT Subject: RFR: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError [v4] In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 17:53:52 GMT, Sergei Ustimenko wrote: >> Change #3294 helps to avoid `AnnotaionFormatException` in `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. While it fixes the case with e.g. `Runnable` that generates the synthetic method without parameters, validation still fails on synthetic methods that have parameters e.g. `Function`, `BiFunction`, etc. >> >> This change removes the restriction on parameters count to be zero i.e. lambdas with parameters >> would be skipped from validation. > > Sergei Ustimenko 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 two additional commits since the last revision: > > - 8268788: Filter out synthetic methods from the member methods computation > - 8268788: Annotations with lambda expressions can still cause AnnotationFormatError Hello, Thanks for the refined PR. Doing another round of review remain on my to-do list. -Joe ------------- PR: https://git.openjdk.java.net/jdk/pull/4642 From naoto at openjdk.java.net Fri Aug 27 21:59:00 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 27 Aug 2021 21:59:00 GMT Subject: RFR: 8260265: UTF-8 by Default [v8] In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: > This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. > > JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 > CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 Naoto Sato 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 15 additional commits since the last revision: - Removed "default" alias - Merge branch 'master' into JDK-8260265 - Merge branch 'master' into JDK-8260265 - Merge branch 'master' into JDK-8260265 - Merge branch 'master' into JDK-8260265 - Merge branch 'master' into JDK-8260265 - Merge branch 'master' into JDK-8260265 - Refined `file.encoding` description - Merge branch 'master' into JDK-8260265 - Reflects comments - ... and 5 more: https://git.openjdk.java.net/jdk/compare/66c3531f...67e1d4a9 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4733/files - new: https://git.openjdk.java.net/jdk/pull/4733/files/7d5137d3..67e1d4a9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=06-07 Stats: 15450 lines in 595 files changed: 11498 ins; 2067 del; 1885 mod Patch: https://git.openjdk.java.net/jdk/pull/4733.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4733/head:pull/4733 PR: https://git.openjdk.java.net/jdk/pull/4733 From github.com+70726043+rgiulietti at openjdk.java.net Fri Aug 27 22:52:31 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Fri, 27 Aug 2021 22:52:31 GMT Subject: Integrated: 8273091: Doc of [Strict]Math.floorDiv(long, int) erroneously documents int in @return tag In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 20:02:48 GMT, Raffaello Giulietti wrote: > This PR corrects a typo in the JavaDoc of `[Strict]Math.floorDiv(long,int)`. This pull request has now been integrated. Changeset: 51167846 Author: Raffaello Giulietti Committer: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/51167846cb5a60dfb31b4f8dfa214ba26640175c Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8273091: Doc of [Strict]Math.floorDiv(long,int) erroneously documents int in @return tag Reviewed-by: darcy, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/5287 From naoto at openjdk.java.net Fri Aug 27 23:14:58 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 27 Aug 2021 23:14:58 GMT Subject: RFR: 8260265: UTF-8 by Default [v9] In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: > This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. > > JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 > CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Fixed a failing test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4733/files - new: https://git.openjdk.java.net/jdk/pull/4733/files/67e1d4a9..28e79d4e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=07-08 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4733.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4733/head:pull/4733 PR: https://git.openjdk.java.net/jdk/pull/4733 From smarks at openjdk.java.net Fri Aug 27 23:22:30 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 27 Aug 2021 23:22:30 GMT Subject: RFR: 8271302: Regex Test Refresh [v4] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 21:17:50 GMT, Ian Graves wrote: >> 8271302: Regex Test Refresh > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Additional cleanup Marked as reviewed by smarks (Reviewer). Whew! Changes to GraphemeTest.java and NegativeArraySize.java look fine. I finally figured out how to look at RegExTest.java effectively -- none of the diff views were helpful at all. I just brought up the old and new versions in windows side by side and just scrolled through them. Overall it looks good, mostly a replacement of the ad hoc internal framework (failCount++) with assertX from testng, and some minor reorganizations here and there, such as the splitting of `stringBufferSubstitute` into several tests. Overall it looks like most things here got about 15% shorter, which is pretty good since it reduces the overall bulk. (However, there's so much more to do....) One observation about this technique is that using the "failCount++" approach, if there is a failure, the tests in the same method will continue to run. With the assertX approach, the test will stop at that point, and any assertions later in the same method won't get run at all. Since we expect all the tests to pass all the time, this has no effect in the normal case. If there is a bug, though, the assertX approach might result in a single failure whereas the failCount++ approach might result in several failures. While this bothers some people, it doesn't bother me; it's likely only to occur at development time, and it's like to be only a minor impediment to development. Indeed, it's commonly viewed as a testing antipattern to have a single test method test multiple cases. The solution is to fix that, and not worry about failCount++ vs assertX. I think the long run solution here is to continue cleaning up these tests, possibly breaking down test methods further, eventually driving things into a purely table-driven or data generator/provider approach. test/jdk/java/util/regex/RegExTest.java line 85: > 83: import static org.testng.Assert.fail; > 84: import static org.testng.Assert.expectThrows; //Replaced by assertThrows in JUnit5 > 85: Slightly odd to mention JUnit 5 here, since this is being converted to a TestNG test. Are these notes for yourself for future work? ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From rriggs at openjdk.java.net Sat Aug 28 02:34:48 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Sat, 28 Aug 2021 02:34:48 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3] In-Reply-To: References: Message-ID: > The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM > as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . > > There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. > The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Revised to use native /bin/sleep program on Unix* (non-Windows). For Windows, a native "BasicSleep" program is used. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5239/files - new: https://git.openjdk.java.net/jdk/pull/5239/files/7ab6c934..05d009de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5239&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5239&range=01-02 Stats: 44 lines in 2 files changed: 30 ins; 6 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5239.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5239/head:pull/5239 PR: https://git.openjdk.java.net/jdk/pull/5239 From iklam at openjdk.java.net Sat Aug 28 03:05:49 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 28 Aug 2021 03:05:49 GMT Subject: RFR: 8273092: Sort classlist in JDK image Message-ID: When the classlist is generated using build.tools.classlist.HelloClasslist, its contents may be non-deterministic due to Java thread execution order. We should sort the generated classlist to make the JDK image's contents more deterministic. Tested with Mach5 tier1, tier2, builds-tier5 ------------- Commit messages: - 8273092: Sort classlist in JDK image Changes: https://git.openjdk.java.net/jdk/pull/5288/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5288&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273092 Stats: 114 lines in 3 files changed: 102 ins; 6 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5288.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5288/head:pull/5288 PR: https://git.openjdk.java.net/jdk/pull/5288 From jai.forums2013 at gmail.com Sat Aug 28 04:45:04 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 28 Aug 2021 10:15:04 +0530 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> Message-ID: Hello Roger, On 28/08/21 12:16 am, Roger Riggs wrote: > Hi, > > I'm finding the idea of removing the hardcoded timestamp and adding a > property to restore compatibility > strangely attractive.? I don't think we've yet found a case where the > timestamp was needed (but need to keep looking). > (Adding a timestamp to the comment by the caller of store() is already > possible) > > It will reveal where the timestamp is needed (via some kind of > failure, though perhaps not a timely one) > and includes a fallback mechanism when needed. > > It will generally cleanup up the behavior of an old API. > The other approaches make new work for developers based on unclear > requirements. So this is essentially the proposal 1d that I listed in one of my mails, with the added advantage of allowing users to switch back to the old behaviour with a system property setting. I hadn't considered the system property approach to switch to old behaviour in my proposals, so this is a very good input and I personally think the most logical proposals so far. One question that however remains is, how long (how many releases) do we support this new system property? The --illegal-access option (although not a system property) seems to be one such example where after a few releases, that option will no longer be supported and won't play any role. Perhaps this system property too will follow a similar lifetime? One other thing - I believe this new system property must be "set once at launch time" kind of property, whose value can be set at launch time and cannot be changed dynamically in the runtime. That would provide consistency in how the Properties class behaves globally within that runtime, instead of potentially behaving differently in different parts of the code, depending on how the callers set/reset the system property value before calling the "store(...)" APIs. -Jaikiran From alanb at openjdk.java.net Sat Aug 28 06:17:28 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 28 Aug 2021 06:17:28 GMT Subject: RFR: 8260265: UTF-8 by Default [v9] In-Reply-To: References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: <1bMIQg6TIjIphxBiTDBBVEh_l8xXiKpiq3RUmed0d3w=.7322db9b-81bc-4142-b1ae-4a776cfaad9d@github.com> On Fri, 27 Aug 2021 23:14:58 GMT, Naoto Sato wrote: >> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. >> >> JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a failing test Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4733 From github.com+741251+turbanoff at openjdk.java.net Sat Aug 28 09:04:37 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sat, 28 Aug 2021 09:04:37 GMT Subject: RFR: 8273098: Unnecessary Vector usage in java.naming Message-ID: Usage of thread-safe collection Vector is unnecessary. It's recommended to use ArrayList/array if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. I checked only places where Vector was used as local variable. ------------- Commit messages: - [PATCH] Unnecessary Vector usage in java.naming Changes: https://git.openjdk.java.net/jdk/pull/5262/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5262&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273098 Stats: 30 lines in 3 files changed: 1 ins; 2 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/5262.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5262/head:pull/5262 PR: https://git.openjdk.java.net/jdk/pull/5262 From redestad at openjdk.java.net Sat Aug 28 13:21:27 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Sat, 28 Aug 2021 13:21:27 GMT Subject: RFR: 8273092: Sort classlist in JDK image In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 23:12:52 GMT, Ioi Lam wrote: > When the classlist is generated using build.tools.classlist.HelloClasslist, its contents may be non-deterministic due to Java thread execution order. > > We should sort the generated classlist to make the JDK image's contents more deterministic. > > Tested with Mach5 tier1, tier2, builds-tier5 Seems OK. make/jdk/src/classes/build/tools/classlist/SortClasslist.java line 31: > 29: * > 30: * The classlist is produced by adding -XX:DumpLoadedClassList=classlist > 31: */ Looks like a copy-paste error (also redundant) ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5288 From redestad at openjdk.java.net Sat Aug 28 13:29:46 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Sat, 28 Aug 2021 13:29:46 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings Message-ID: Refactor to improve inlining, which helps some microbenchmarks exer StringBuilder.append(String) ------------- Commit messages: - 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings Changes: https://git.openjdk.java.net/jdk/pull/5291/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5291&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273100 Stats: 21 lines in 1 file changed: 11 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5291/head:pull/5291 PR: https://git.openjdk.java.net/jdk/pull/5291 From redestad at openjdk.java.net Sat Aug 28 14:28:22 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Sat, 28 Aug 2021 14:28:22 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings In-Reply-To: References: Message-ID: <_sWAPUWq7NjRgQ5F21Mut8ibmYlL9HCUnifAhHNipn0=.a26f04b8-ca8e-4b1c-82b2-143717e65294@github.com> On Sat, 28 Aug 2021 13:21:24 GMT, Claes Redestad wrote: > Refactor to improve inlining, which helps some microbenchmarks exer StringBuilder.append(String) Microbenchmark results: Baseline Benchmark Mode Cnt Score Error Units # +CompactStrings StringBuilders.appendLoop16 avgt 25 749.861 ? 6.717 ns/op StringBuilders.appendLoop8 avgt 25 382.491 ? 4.603 ns/op # -CompactStrings StringBuilders.appendLoop16 avgt 25 716.850 ? 7.857 ns/op StringBuilders.appendLoop8 avgt 25 374.279 ? 5.793 ns/op # -Xint +CompactStrings: StringBuilders.appendLoop16 avgt 5 23479.176 ? 135.382 ns/op StringBuilders.appendLoop8 avgt 5 12075.346 ? 80.429 ns/op # -Xint -CompactStrings: Benchmark Mode Cnt Score Error Units StringBuilders.appendLoop16 avgt 5 22166.303 ? 295.892 ns/op StringBuilders.appendLoop8 avgt 5 11480.187 ? 710.690 ns/op Patched: Benchmark Mode Cnt Score Error Units # +CompactStrings StringBuilders.appendLoop16 avgt 25 724.803 ? 9.613 ns/op StringBuilders.appendLoop8 avgt 25 374.400 ? 6.368 ns/op # -CompactStrings StringBuilders.appendLoop16 avgt 25 715.314 ? 11.787 ns/op StringBuilders.appendLoop8 avgt 25 377.415 ? 6.089 ns/op # -Xint +CompactStrings StringBuilders.appendLoop16 avgt 5 19794.280 ? 227.033 ns/op StringBuilders.appendLoop8 avgt 5 10200.439 ? 221.899 ns/op # -Xint -CompactStrings StringBuilders.appendLoop16 avgt 5 16855.894 ? 127.499 ns/op StringBuilders.appendLoop8 avgt 5 9004.396 ? 111.427 ns/op ------------- PR: https://git.openjdk.java.net/jdk/pull/5291 From Alan.Bateman at oracle.com Sat Aug 28 15:16:25 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 28 Aug 2021 16:16:25 +0100 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> Message-ID: <983f15b6-96e3-9aeb-c203-baea91dd1b24@oracle.com> On 28/08/2021 05:45, Jaikiran Pai wrote: > I hadn't considered the system property approach to switch to old > behaviour in my proposals, so this is a very good input and I > personally think the most logical proposals so far. Roger may be right that few would care but it would be changing behavior that goes back to JDK 1.0. In your list (and thanks for writing down the options with pros/cons) then your 1a where SOURCE_DATE_EPOCH changes to write the epoch date rather than the current date seems to be most consistent with other tools and the wider eco system. It seems the least disruptive in that it doesn't change existing behavior and would be opt-in when reproducibility is required. Previous discussion was leading towards your option 2 (or variants of) but isn't option doesn't help the cases where build tools use libraries that rely on the older methods. -Alan From filteredaccount1 at gmail.com Sun Aug 29 01:26:43 2021 From: filteredaccount1 at gmail.com (Ben S) Date: Sun, 29 Aug 2021 11:26:43 +1000 Subject: JPackage and ask for microphone permissions broken on OSX... Message-ID: Putting the information how to do this together. Trying to get an existing jpackaged app, that is not signed and is not distributed in the app store, to ask for mike permissions. Does not ever ask for permissions. Not sure how this differs from IntelliJ (which does successfully ask for permissions). Is the problem in Macos or Java or Info.plist? /Applications/SomeAppFolder/SomeApp.app/Contents/Info.plist CFBundleIdentifier com.someorg.someapp.somepackage.random12345 NSMicrophoneUsageDescription Someapp requests access to the device's microphone. You can remove all the microphone permissions and start again - tccutil reset Microphone Could there be some other settings controlling this? Is there a way of getting a debug log? Thanks, Ben S. > On Aug 25, 2021, at 8:40 AM, Alan Snyder wrote: > On Aug 24, 2021, at 6:52 AM, Andy Herrick wrote: > > One final thing to note, MacOS keeps track of what you have ever previously granted microphone permission to (and will never ask again) based on the mac package identifier (which defaults to the main class name), so I explicitly set this using a shell script with jpackage option "--mac-package-identifier audio-$1" option, so I can pass in different values and create a unique one each time. > > I?ve been wondering what you mean here. > > Are you saying that you routinely generate random package identifiers or is this a workaround that you use in special circumstances? > > Alan > > I believe the permission is granted to a bundle idenditifer. I think tccutil can be used to reset > > https://apple.stackexchange.com/questions/384317/how-do-i-reset-camera-and-microphone-permission-on-macos-mojave From github.com+1701815+mkarg at openjdk.java.net Sun Aug 29 11:41:38 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Sun, 29 Aug 2021 11:41:38 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 01:10:15 GMT, Brian Burkhalter wrote: >> 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 > > test/jdk/sun/nio/ch/ChannelInputStream/TransferTo.java line 93: > >> 91: checkTransferredContents(inputStreamProvider, outputStreamProvider, createRandomBytes(1024, 4096)); >> 92: // to span through several batches >> 93: checkTransferredContents(inputStreamProvider, outputStreamProvider, createRandomBytes(16384, 16384)); > > Should some random-sized buffers be tested? (Use `jdk.test.lib.RandomFactory` factory for this, not `j.u.Random`. The existing use of `Random` is fine.) > > Should some testing be done of streams with non-zero initial position? Done in https://github.com/openjdk/jdk/pull/5209, will rebase on that PR once merged. > test/jdk/sun/nio/ch/ChannelInputStream/TransferTo.java line 101: > >> 99: try (InputStream in = inputStreamProvider.input(inBytes); >> 100: OutputStream out = outputStreamProvider.output(recorder::set)) { >> 101: in.transferTo(out); > > The return value of `transferTo()` is not checked. Done in https://github.com/openjdk/jdk/pull/5209, will rebase on that PR once merged. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From jai.forums2013 at gmail.com Sun Aug 29 13:11:42 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sun, 29 Aug 2021 18:41:42 +0530 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <983f15b6-96e3-9aeb-c203-baea91dd1b24@oracle.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> <983f15b6-96e3-9aeb-c203-baea91dd1b24@oracle.com> Message-ID: <9e287e72-42f3-d171-6473-fa3f47435b9f@gmail.com> On 28/08/21 8:46 pm, Alan Bateman wrote: > On 28/08/2021 05:45, Jaikiran Pai wrote: >> I hadn't considered the system property approach to switch to old >> behaviour in my proposals, so this is a very good input and I >> personally think the most logical proposals so far. > > Roger may be right that few would care but it would be changing > behavior that goes back to JDK 1.0. In your list (and thanks for > writing down the options with pros/cons) then your 1a where > SOURCE_DATE_EPOCH changes to write the epoch date rather than the > current date seems to be most consistent with other tools and the > wider eco system. It seems the least disruptive in that it doesn't > change existing behavior and would be opt-in when reproducibility is > required. In that case, I will start work along these lines. -Jaikiran From mchung at openjdk.java.net Mon Aug 30 01:49:24 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 30 Aug 2021 01:49:24 GMT Subject: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v3] In-Reply-To: <4kDnwVGaxMk25dGRb2-wDyT6oeafNFiJoVXTKudTh5E=.082451de-1c6d-4651-92ae-532f15768c2e@github.com> References: <4kDnwVGaxMk25dGRb2-wDyT6oeafNFiJoVXTKudTh5E=.082451de-1c6d-4651-92ae-532f15768c2e@github.com> Message-ID: On Thu, 26 Aug 2021 02:36:47 GMT, Vicente Romero wrote: >> Please review this simple PR along with the associated CSR. The PR is basically adding a line the the specification of method `java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a NPE will be thrown. >> >> TIA >> >> link to the [CSR](https://bugs.openjdk.java.net/browse/JDK-8272852) > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > clarifying that the names parameter is ignored in some cases Marked as reviewed by mchung (Reviewer). src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 345: > 343: Arrays.stream(getters).forEach(Objects::requireNonNull); > 344: MethodType methodType; > 345: if (type instanceof MethodType) Since you are modifying this file, do you mind taking Jesper's suggestion [1] posted in another PR to use pattern matching. Suggestion: if (type instanceof MethodType mt) methodType = mt; [1] https://github.com/openjdk/valhalla/pull/528#discussion_r688100918 ------------- PR: https://git.openjdk.java.net/jdk/pull/5226 From whuang at openjdk.java.net Mon Aug 30 06:26:01 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Mon, 30 Aug 2021 06:26:01 GMT Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v7] In-Reply-To: References: Message-ID: > Dear all, > Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo. > > * We add a JMH test case > * Here is the result of this test case > > Benchmark |(size)| Mode| Cnt|Score | Error |Units > ---------------------------------|------|-----|----|------|--------|----- > StringCompare.compareLL | 64 | avgt| 5 |7.992 | ? 0.005|us/op > StringCompare.compareLL | 72 | avgt| 5 |15.029| ? 0.006|us/op > StringCompare.compareLL | 80 | avgt| 5 |14.655| ? 0.011|us/op > StringCompare.compareLL | 91 | avgt| 5 |16.363| ? 0.12 |us/op > StringCompare.compareLL | 101 | avgt| 5 |16.966| ? 0.007|us/op > StringCompare.compareLL | 121 | avgt| 5 |19.276| ? 0.006|us/op > StringCompare.compareLL | 181 | avgt| 5 |19.002| ? 0.417|us/op > StringCompare.compareLL | 256 | avgt| 5 |24.707| ? 0.041|us/op > StringCompare.compareLLWithLdp| 64 | avgt| 5 |8.001 | ? 0.121|us/op > StringCompare.compareLLWithLdp| 72 | avgt| 5 |11.573| ? 0.003|us/op > StringCompare.compareLLWithLdp| 80 | avgt| 5 |6.861 | ? 0.004|us/op > StringCompare.compareLLWithLdp| 91 | avgt| 5 |12.774| ? 0.201|us/op > StringCompare.compareLLWithLdp| 101 | avgt| 5 |8.691 | ? 0.004|us/op > StringCompare.compareLLWithLdp| 121 | avgt| 5 |11.091| ? 1.342|us/op > StringCompare.compareLLWithLdp| 181 | avgt| 5 |14.64 | ? 0.581|us/op > StringCompare.compareLLWithLdp| 256 | avgt| 5 |25.879| ? 1.775|us/op > StringCompare.compareUU | 64 | avgt| 5 |13.476| ? 0.01 |us/op > StringCompare.compareUU | 72 | avgt| 5 |15.078| ? 0.006|us/op > StringCompare.compareUU | 80 | avgt| 5 |23.512| ? 0.011|us/op > StringCompare.compareUU | 91 | avgt| 5 |24.284| ? 0.008|us/op > StringCompare.compareUU | 101 | avgt| 5 |20.707| ? 0.017|us/op > StringCompare.compareUU | 121 | avgt| 5 |29.302| ? 0.011|us/op > StringCompare.compareUU | 181 | avgt| 5 |39.31 | ? 0.016|us/op > StringCompare.compareUU | 256 | avgt| 5 |54.592| ? 0.392|us/op > StringCompare.compareUUWithLdp| 64 | avgt| 5 |16.389| ? 0.008|us/op > StringCompare.compareUUWithLdp| 72 | avgt| 5 |10.71 | ? 0.158|us/op > StringCompare.compareUUWithLdp| 80 | avgt| 5 |11.488| ? 0.024|us/op > StringCompare.compareUUWithLdp| 91 | avgt| 5 |13.412| ? 0.006|us/op > StringCompare.compareUUWithLdp| 101 | avgt| 5 |16.245| ? 0.434|us/op > StringCompare.compareUUWithLdp| 121 | avgt| 5 |16.597| ? 0.016|us/op > StringCompare.compareUUWithLdp| 181 | avgt| 5 |27.373| ? 0.017|us/op > StringCompare.compareUUWithLdp| 256 | avgt| 5 |41.74 | ? 3.5 |us/op > > From this table, we can see that in most cases, our patch is better than old one. > > Thank you for your review. Any suggestions are welcome. Wang Huang has updated the pull request incrementally with one additional commit since the last revision: fix windows build failed ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4722/files - new: https://git.openjdk.java.net/jdk/pull/4722/files/2f756261..8cf3b2c7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4722&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4722&range=05-06 Stats: 97 lines in 2 files changed: 0 ins; 96 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4722/head:pull/4722 PR: https://git.openjdk.java.net/jdk/pull/4722 From redestad at openjdk.java.net Mon Aug 30 08:50:49 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 30 Aug 2021 08:50:49 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v2] In-Reply-To: References: Message-ID: > Refactor to improve inlining, which helps some microbenchmarks exer StringBuilder.append(String) Claes Redestad 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 two additional commits since the last revision: - Merge branch 'master' into asb_inlining - 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5291/files - new: https://git.openjdk.java.net/jdk/pull/5291/files/56e55c57..e5052256 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5291&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5291&range=00-01 Stats: 152 lines in 4 files changed: 143 ins; 5 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5291/head:pull/5291 PR: https://git.openjdk.java.net/jdk/pull/5291 From aefimov at openjdk.java.net Mon Aug 30 11:32:36 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Mon, 30 Aug 2021 11:32:36 GMT Subject: RFR: 8273098: Unnecessary Vector usage in java.naming In-Reply-To: References: Message-ID: <8a-xQ8AGdviqWgnZydsCqodGaOmsEhtcOhT75MFQ98o=.3a54a0c0-1f38-44e7-a46d-977f22a202ab@github.com> On Thu, 26 Aug 2021 07:04:45 GMT, Andrey Turbanov wrote: > Usage of thread-safe collection Vector is unnecessary. It's recommended to use ArrayList/array if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. > I checked only places where Vector was used as local variable. Hi Andrey, The changes look good to me. I've run your patch through our CI and all JNDI tests are green. Best, Aleksei ------------- Marked as reviewed by aefimov (Committer). PR: https://git.openjdk.java.net/jdk/pull/5262 From dfuchs at openjdk.java.net Mon Aug 30 11:39:28 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 30 Aug 2021 11:39:28 GMT Subject: RFR: 8273098: Unnecessary Vector usage in java.naming In-Reply-To: References: Message-ID: On Thu, 26 Aug 2021 07:04:45 GMT, Andrey Turbanov wrote: > Usage of thread-safe collection Vector is unnecessary. It's recommended to use ArrayList/array if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. > I checked only places where Vector was used as local variable. Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5262 From ihse at openjdk.java.net Mon Aug 30 11:40:28 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 30 Aug 2021 11:40:28 GMT Subject: RFR: 8273092: Sort classlist in JDK image In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 23:12:52 GMT, Ioi Lam wrote: > When the classlist is generated using build.tools.classlist.HelloClasslist, its contents may be non-deterministic due to Java thread execution order. > > We should sort the generated classlist to make the JDK image's contents more deterministic. > > Tested with Mach5 tier1, tier2, builds-tier5 Looks great. Thank you for helping to make the build deterministic! ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5288 From redestad at openjdk.java.net Mon Aug 30 11:49:49 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 30 Aug 2021 11:49:49 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v3] In-Reply-To: References: Message-ID: > Refactor to improve inlining, which helps some microbenchmarks exer StringBuilder.append(String) Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Simplify and call getBytes(String, int, byte) when possible ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5291/files - new: https://git.openjdk.java.net/jdk/pull/5291/files/e5052256..6dfaff5a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5291&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5291&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5291/head:pull/5291 PR: https://git.openjdk.java.net/jdk/pull/5291 From magnus.ihse.bursie at oracle.com Mon Aug 30 11:59:46 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 30 Aug 2021 13:59:46 +0200 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <983f15b6-96e3-9aeb-c203-baea91dd1b24@oracle.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> <983f15b6-96e3-9aeb-c203-baea91dd1b24@oracle.com> Message-ID: On 2021-08-28 17:16, Alan Bateman wrote: > On 28/08/2021 05:45, Jaikiran Pai wrote: >> I hadn't considered the system property approach to switch to old >> behaviour in my proposals, so this is a very good input and I >> personally think the most logical proposals so far. > > Roger may be right that few would care but it would be changing > behavior that goes back to JDK 1.0. In your list (and thanks for > writing down the options with pros/cons) then your 1a where > SOURCE_DATE_EPOCH changes to write the epoch date rather than the > current date seems to be most consistent with other tools and the > wider eco system. It seems the least disruptive in that it doesn't > change existing behavior and would be opt-in when reproducibility is > required. Previous discussion was leading towards your option 2 (or > variants of) but isn't option doesn't help the cases where build tools > use libraries that rely on the older methods. If I understood the numbering and alternatives correctly, I don't think there is a conflict between 1a and 2, and I think both should be implemented, for different reasons. This is my understanding of the options, with the rationale I see for choosing them: * 1a says that we change the store() method to write the date from SOURCE_DATE_EPOCH, if it is set -- otherwise it keeps the old behavior. This allows users who want to use old Java code (or code they can't modify) to produce output in a reproducible way to do so without changing the source code of the product. * 2 says that we add a new override to store() which also takes an Instant. This way programmers who write new code and want to make sure it is always reproducible can send in Instant.EPOCH, and not rely on the user to configure SOURCE_DATE_EPOCH. (In fact, when thinking of it, this seems overly complex. There is no real need to send in a generic Instant, just an override with a boolean skipTimestamp, or something like that. Basically, any solution which allows programmers who write new code to get property files without timestamps easily, is what's needed to fulfill this spot. /Magnus > > -Alan From redestad at openjdk.java.net Mon Aug 30 12:01:29 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 30 Aug 2021 12:01:29 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v3] In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 11:49:49 GMT, Claes Redestad wrote: >> Refactor to improve inlining, which helps some microbenchmarks exer StringBuilder.append(String) > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Simplify and call getBytes(String, int, byte) when possible Simplified further after realizing `putStringAt(int, String)` can use `String.getBytes(String, int, byte)`, improving performance for both modes: # +CompactStrings Benchmark Mode Cnt Score Error Units StringBuilders.appendLoop16 avgt 15 681.778 ? 14.978 ns/op StringBuilders.appendLoop8 avgt 15 358.008 ? 9.230 ns/op # -CompactStrings Benchmark Mode Cnt Score Error Units StringBuilders.appendLoop16 avgt 15 664.591 ? 10.505 ns/op StringBuilders.appendLoop8 avgt 15 351.175 ? 13.282 ns/op ------------- PR: https://git.openjdk.java.net/jdk/pull/5291 From dfuchs at openjdk.java.net Mon Aug 30 12:54:25 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 30 Aug 2021 12:54:25 GMT Subject: RFR: 8273092: Sort classlist in JDK image In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 23:12:52 GMT, Ioi Lam wrote: > When the classlist is generated using build.tools.classlist.HelloClasslist, its contents may be non-deterministic due to Java thread execution order. > > We should sort the generated classlist to make the JDK image's contents more deterministic. > > Tested with Mach5 tier1, tier2, builds-tier5 make/jdk/src/classes/build/tools/classlist/SortClasslist.java line 58: > 56: String line = scanner.nextLine(); > 57: Matcher m = p.matcher(line); > 58: if (m.find()) { Are we sure that a comment line will not match this regexp, or that if it matches, it is not a comment line? ------------- PR: https://git.openjdk.java.net/jdk/pull/5288 From github.com+741251+turbanoff at openjdk.java.net Mon Aug 30 13:16:30 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 30 Aug 2021 13:16:30 GMT Subject: Integrated: 8273098: Unnecessary Vector usage in java.naming In-Reply-To: References: Message-ID: On Thu, 26 Aug 2021 07:04:45 GMT, Andrey Turbanov wrote: > Usage of thread-safe collection Vector is unnecessary. It's recommended to use ArrayList/array if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized. > I checked only places where Vector was used as local variable. This pull request has now been integrated. Changeset: 5185dbde Author: Andrey Turbanov Committer: Aleksei Efimov URL: https://git.openjdk.java.net/jdk/commit/5185dbde67f07ff876305a9568bb5cebb7a7b384 Stats: 30 lines in 3 files changed: 1 ins; 2 del; 27 mod 8273098: Unnecessary Vector usage in java.naming Reviewed-by: aefimov, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5262 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 30 13:18:27 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 30 Aug 2021 13:18:27 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v3] In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 11:49:49 GMT, Claes Redestad wrote: >> Refactor to improve inlining, which helps some microbenchmarks exer StringBuilder.append(String) > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Simplify and call getBytes(String, int, byte) when possible Hi, just curious how have you found out that the code should be extracted into a separate methods? Profiler? ------------- PR: https://git.openjdk.java.net/jdk/pull/5291 From redestad at openjdk.java.net Mon Aug 30 13:26:28 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 30 Aug 2021 13:26:28 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v3] In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 13:15:20 GMT, ?????? ??????? wrote: > Hi, just curious how have you found out that the code should be extracted into a separate methods? Profiler? I saw that `String::length` calls appeared more than once with async-profiler, then did some experiments to see if manually inlining so that only one call was needed helped (and it did). ------------- PR: https://git.openjdk.java.net/jdk/pull/5291 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 30 13:33:30 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 30 Aug 2021 13:33:30 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v3] In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 11:49:49 GMT, Claes Redestad wrote: >> Refactor to improve inlining, which helps some microbenchmarks exer StringBuilder.append(String) > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Simplify and call getBytes(String, int, byte) when possible src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1730: > 1728: } > 1729: > 1730: private void putStringAt(int index, String str) { Can we replace all the calls to this method with calls to previous method as `putStringAt(index, str, 0, str.length())`? ------------- PR: https://git.openjdk.java.net/jdk/pull/5291 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 30 13:38:29 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 30 Aug 2021 13:38:29 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v3] In-Reply-To: References: Message-ID: <4YssNV0TYEU6FwEzH0z-6akk6Z3eD4-EpjrYB6vqljQ=.1e441aba-f431-4303-b69c-f083d4f288f3@github.com> On Mon, 30 Aug 2021 11:49:49 GMT, Claes Redestad wrote: >> Refactor to improve inlining, which helps some microbenchmarks exer StringBuilder.append(String) > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Simplify and call getBytes(String, int, byte) when possible src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1714: > 1712: > 1713: private void inflateIfNeededFor(String input) { > 1714: if (COMPACT_STRINGS && (coder != input.coder())) { I'm not completely sure whether it's a good idea in terms of maintability, but I think this can be simplified a bit more. Currently in both `String` and `ASB` we have implementation of `coder()` very much alike: // ASB final byte getCoder() { return COMPACT_STRINGS ? coder : UTF16; } //String byte getCoder() { return COMPACT_STRINGS ? coder : UTF16; } Here we have this condition if (COMPACT_STRINGS && (coder != input.getCoder())) {} where the right operand of `&&` is evaluated only when `COMPACT_STRINGS` is `true` and hence it always returns the value of `coder` field. This means we can reference it directly as if (COMPACT_STRINGS && (coder != input.coder)) {} ------------- PR: https://git.openjdk.java.net/jdk/pull/5291 From redestad at openjdk.java.net Mon Aug 30 13:57:28 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 30 Aug 2021 13:57:28 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v3] In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 13:29:56 GMT, ?????? ??????? wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify and call getBytes(String, int, byte) when possible > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1730: > >> 1728: } >> 1729: >> 1730: private void putStringAt(int index, String str) { > > Can we replace all the calls to this method with calls to previous method as `putStringAt(index, str, 0, str.length())` taking into account that in all usecases `str.length()` is already calculated into a local var? No, I don't think so. The only use of this I can find is at line 1298 which effectively adds a substring: `putStringAt(dstOffset, (String) s, start, end);` ------------- PR: https://git.openjdk.java.net/jdk/pull/5291 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 30 14:09:31 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 30 Aug 2021 14:09:31 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v3] In-Reply-To: <9MSvoGLvYfFUVxcMTkG1thT0DFrd6dP2Ijc6Bgbmf3U=.12a0ce81-49e7-490c-ba1a-6a51e1134849@github.com> References: <4YssNV0TYEU6FwEzH0z-6akk6Z3eD4-EpjrYB6vqljQ=.1e441aba-f431-4303-b69c-f083d4f288f3@github.com> <9MSvoGLvYfFUVxcMTkG1thT0DFrd6dP2Ijc6Bgbmf3U=.12a0ce81-49e7-490c-ba1a-6a51e1134849@github.com> Message-ID: On Mon, 30 Aug 2021 14:04:27 GMT, Claes Redestad wrote: >> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1714: >> >>> 1712: >>> 1713: private void inflateIfNeededFor(String input) { >>> 1714: if (COMPACT_STRINGS && (coder != input.coder())) { >> >> I'm not completely sure whether it's a good idea in terms of maintainability, but I think this can be simplified a bit more. Currently in both `String` and `ASB` we have implementations of `coder()` very much alike: >> >> // ASB >> final byte getCoder() { >> return COMPACT_STRINGS ? coder : UTF16; >> } >> >> //String >> byte getCoder() { >> return COMPACT_STRINGS ? coder : UTF16; >> } >> >> Here we have this condition >> >> if (COMPACT_STRINGS && (coder != input.getCoder())) {} >> >> where the right operand of `&&` is evaluated only when `COMPACT_STRINGS` is `true` and hence it always returns the value of `coder` field. This means we can reference it directly as >> >> if (COMPACT_STRINGS && (coder != input.coder)) {} > > I'm not sure if this'd give us enough to motivate the refactor, especially since we'd have to widen the visibility of `String.coder`. Maybe startup could be helped a little. Either way it feels out of scope for this change, don't you think? Agree ------------- PR: https://git.openjdk.java.net/jdk/pull/5291 From redestad at openjdk.java.net Mon Aug 30 14:09:31 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 30 Aug 2021 14:09:31 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v3] In-Reply-To: <4YssNV0TYEU6FwEzH0z-6akk6Z3eD4-EpjrYB6vqljQ=.1e441aba-f431-4303-b69c-f083d4f288f3@github.com> References: <4YssNV0TYEU6FwEzH0z-6akk6Z3eD4-EpjrYB6vqljQ=.1e441aba-f431-4303-b69c-f083d4f288f3@github.com> Message-ID: <9MSvoGLvYfFUVxcMTkG1thT0DFrd6dP2Ijc6Bgbmf3U=.12a0ce81-49e7-490c-ba1a-6a51e1134849@github.com> On Mon, 30 Aug 2021 13:35:23 GMT, ?????? ??????? wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify and call getBytes(String, int, byte) when possible > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1714: > >> 1712: >> 1713: private void inflateIfNeededFor(String input) { >> 1714: if (COMPACT_STRINGS && (coder != input.coder())) { > > I'm not completely sure whether it's a good idea in terms of maintainability, but I think this can be simplified a bit more. Currently in both `String` and `ASB` we have implementations of `coder()` very much alike: > > // ASB > final byte getCoder() { > return COMPACT_STRINGS ? coder : UTF16; > } > > //String > byte getCoder() { > return COMPACT_STRINGS ? coder : UTF16; > } > > Here we have this condition > > if (COMPACT_STRINGS && (coder != input.getCoder())) {} > > where the right operand of `&&` is evaluated only when `COMPACT_STRINGS` is `true` and hence it always returns the value of `coder` field. This means we can reference it directly as > > if (COMPACT_STRINGS && (coder != input.coder)) {} I'm not sure if this'd give us enough to motivate the refactor, especially since we'd have to widen the visibility of `String.coder`. Maybe startup could be helped a little. Either way it feels out of scope for this change, don't you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/5291 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 30 14:29:31 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 30 Aug 2021 14:29:31 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v3] In-Reply-To: References: Message-ID: <1Sh2gQzF0qNuzdhiO2RM4fK9uo2Aje2eXmTbVxy6EZE=.ed0e3c17-10aa-4437-b24c-a92dee7d361d@github.com> On Mon, 30 Aug 2021 13:54:13 GMT, Claes Redestad wrote: >> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1730: >> >>> 1728: } >>> 1729: >>> 1730: private void putStringAt(int index, String str) { >> >> Can we replace all the calls to this method with calls to previous method as `putStringAt(index, str, 0, str.length())` taking into account that in all usecases `str.length()` is already calculated into a local var? > > No, I don't think so. The only use of this I can find is at line 1298 which effectively adds a substring: `putStringAt(dstOffset, (String) s, start, end);` What about lines 582, 1003 and 1175? E.g. 582 public AbstractStringBuilder append(String str) { if (str == null) { return appendNull(); } int len = str.length(); ensureCapacityInternal(count + len); putStringAt(count, str); // couldn't it be putStringAt(count, str, 0, len); count += len; return this; } Doing this here and in other places allows to rid `private void putStringAt(int index, String str)` completely and reduce one nested method call, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/5291 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 30 14:36:05 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 30 Aug 2021 14:36:05 GMT Subject: RFR: 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible Message-ID: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> Just a very tiny clean-up. There are some places in JDK code base where we call `Enum.class.getEnumConstants()` to get all the values of the referenced `enum`. This is excessive, less-readable and slower than just calling `Enum.values()` as in `getEnumConstants()` we have volatile access: public T[] getEnumConstants() { T[] values = getEnumConstantsShared(); return (values != null) ? values.clone() : null; } private transient volatile T[] enumConstants; T[] getEnumConstantsShared() { T[] constants = enumConstants; if (constants == null) { /* ... */ } return constants; } Calling values() method is slightly faster: @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class EnumBenchmark { @Benchmark public Enum[] values() { return Enum.values(); } @Benchmark public Enum[] getEnumConstants() { return Enum.class.getEnumConstants(); } private enum Enum { A, B } } Benchmark Mode Cnt Score Error Units EnumBenchmark.getEnumConstants avgt 15 6,265 ? 0,051 ns/op EnumBenchmark.getEnumConstants:?gc.alloc.rate avgt 15 2434,075 ? 19,568 MB/sec EnumBenchmark.getEnumConstants:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space avgt 15 2433,709 ? 70,216 MB/sec EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space.norm avgt 15 23,998 ? 0,659 B/op EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space avgt 15 0,009 ? 0,003 MB/sec EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op EnumBenchmark.getEnumConstants:?gc.count avgt 15 210,000 counts EnumBenchmark.getEnumConstants:?gc.time avgt 15 119,000 ms EnumBenchmark.values avgt 15 4,164 ? 0,134 ns/op EnumBenchmark.values:?gc.alloc.rate avgt 15 3665,341 ? 120,721 MB/sec EnumBenchmark.values:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op EnumBenchmark.values:?gc.churn.G1_Eden_Space avgt 15 3660,512 ? 137,250 MB/sec EnumBenchmark.values:?gc.churn.G1_Eden_Space.norm avgt 15 23,972 ? 0,529 B/op EnumBenchmark.values:?gc.churn.G1_Survivor_Space avgt 15 0,017 ? 0,003 MB/sec EnumBenchmark.values:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op EnumBenchmark.values:?gc.count avgt 15 262,000 counts EnumBenchmark.values:?gc.time avgt 15 155,000 ms ------------- Commit messages: - 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible Changes: https://git.openjdk.java.net/jdk/pull/5303/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5303&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273140 Stats: 13 lines in 4 files changed: 0 ins; 2 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5303.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5303/head:pull/5303 PR: https://git.openjdk.java.net/jdk/pull/5303 From redestad at openjdk.java.net Mon Aug 30 14:55:30 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 30 Aug 2021 14:55:30 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v3] In-Reply-To: <1Sh2gQzF0qNuzdhiO2RM4fK9uo2Aje2eXmTbVxy6EZE=.ed0e3c17-10aa-4437-b24c-a92dee7d361d@github.com> References: <1Sh2gQzF0qNuzdhiO2RM4fK9uo2Aje2eXmTbVxy6EZE=.ed0e3c17-10aa-4437-b24c-a92dee7d361d@github.com> Message-ID: On Mon, 30 Aug 2021 14:26:23 GMT, ?????? ??????? wrote: >> No, I don't think so. The only use of this I can find is at line 1298 which effectively adds a substring: `putStringAt(dstOffset, (String) s, start, end);` > > What about lines 582, 1003 and 1175? E.g. 582 > > public AbstractStringBuilder append(String str) { > if (str == null) { > return appendNull(); > } > int len = str.length(); > ensureCapacityInternal(count + len); > putStringAt(count, str); // couldn't it be putStringAt(count, str, 0, len); > count += len; > return this; > } > > Doing this here and in other places allows to rid `private void putStringAt(int index, String str)` completely and reduce one nested method call, right? I think you've got the wrong idea: We _want_ to use `putStringAt(int, String)` now since it can call into `String.getBytes(String, int, byte)`, which has a simpler and more efficient implementation than `String.getBytes(String, int, int, byte, int)`, since it avoids a couple of `<< coder` operations. This makes up for most of the improvement between my initial and the current version of this patch. (There's also no nested delegation from `putStringAt(int, String)` to `putStringAt(int, String, int, int)` in my proposed patch.) ------------- PR: https://git.openjdk.java.net/jdk/pull/5291 From roger.riggs at oracle.com Mon Aug 30 15:00:14 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 30 Aug 2021 11:00:14 -0400 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> Message-ID: <3a4aafaf-7282-cf8a-4643-1af2d9ac1553@oracle.com> Hi Jaikiran, System properties, especially new ones, should be only settable on the command line and read once. It makes them visible to developers and avoids state-full dependencies and concurrency issues. Retiring system properties is quite difficult because there's no way to know if they are still being used or by whom.? The technique using system properties to revert to previous behavior has been used when API changes are unavoidable and the impact on existing applications is not known. It isn't a good solution but does provide a workaround when an issue is discovered. Better to not introduce them in the first place. The use of SOURCE_DATE_EPOCH as proposed seems better than most, as its definition has a wider scope and longer expected life than most properties. Since SOURCE_DATE_EPOCH is an environment variable, not a system property, it will be less visible to developers, but is already read-once at first use of any environment variable as per System.getenv(). $.02, Roger On 8/28/21 12:45 AM, Jaikiran Pai wrote: > Hello Roger, > > On 28/08/21 12:16 am, Roger Riggs wrote: >> Hi, >> >> I'm finding the idea of removing the hardcoded timestamp and adding a >> property to restore compatibility >> strangely attractive.? I don't think we've yet found a case where the >> timestamp was needed (but need to keep looking). >> (Adding a timestamp to the comment by the caller of store() is >> already possible) >> >> It will reveal where the timestamp is needed (via some kind of >> failure, though perhaps not a timely one) >> and includes a fallback mechanism when needed. >> >> It will generally cleanup up the behavior of an old API. >> The other approaches make new work for developers based on unclear >> requirements. > > So this is essentially the proposal 1d that I listed in one of my > mails, with the added advantage of allowing users to switch back to > the old behaviour with a system property setting. I hadn't considered > the system property approach to switch to old behaviour in my > proposals, so this is a very good input and I personally think the > most logical proposals so far. One question that however remains is, > how long (how many releases) do we support this new system property? > The --illegal-access option (although not a system property) seems to > be one such example where after a few releases, that option will no > longer be supported and won't play any role. Perhaps this system > property too will follow a similar lifetime? > > One other thing - I believe this new system property must be "set once > at launch time" kind of property, whose value can be set at launch > time and cannot be changed dynamically in the runtime. That would > provide consistency in how the Properties class behaves globally > within that runtime, instead of potentially behaving differently in > different parts of the code, depending on how the callers set/reset > the system property value before calling the "store(...)" APIs. > > -Jaikiran > > From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 30 15:21:31 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 30 Aug 2021 15:21:31 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v3] In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 11:49:49 GMT, Claes Redestad wrote: >> Refactor to improve inlining, which helps some microbenchmarks exer StringBuilder.append(String) > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Simplify and call getBytes(String, int, byte) when possible Marked as reviewed by stsypanov at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/5291 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 30 15:21:31 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 30 Aug 2021 15:21:31 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v3] In-Reply-To: References: <1Sh2gQzF0qNuzdhiO2RM4fK9uo2Aje2eXmTbVxy6EZE=.ed0e3c17-10aa-4437-b24c-a92dee7d361d@github.com> Message-ID: On Mon, 30 Aug 2021 14:52:12 GMT, Claes Redestad wrote: >> What about lines 582, 1003 and 1175? E.g. 582 >> >> public AbstractStringBuilder append(String str) { >> if (str == null) { >> return appendNull(); >> } >> int len = str.length(); >> ensureCapacityInternal(count + len); >> putStringAt(count, str); // couldn't it be putStringAt(count, str, 0, len); >> count += len; >> return this; >> } >> >> Doing this here and in other places allows to rid `private void putStringAt(int index, String str)` completely and reduce one nested method call, right? > > I think you've got the wrong idea: We _want_ to use `putStringAt(int, String)` now since it can call into `String.getBytes(String, int, byte)`, which has a simpler and more efficient implementation than `String.getBytes(String, int, int, byte, int)`, since it avoids a couple of `<< coder` operations. This makes up for most of the improvement between my initial and the current version of this patch. > > (There's also no nested delegation from `putStringAt(int, String)` to `putStringAt(int, String, int, int)` in my proposed patch.) You are right, I've applied your patch locally incompletely and misunderstood it, my bad :) ------------- PR: https://git.openjdk.java.net/jdk/pull/5291 From igraves at openjdk.java.net Mon Aug 30 15:44:41 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 30 Aug 2021 15:44:41 GMT Subject: RFR: 8271302: Regex Test Refresh [v4] In-Reply-To: References: Message-ID: <77EKNvY_VzhlqJkpCEg-7pLRuVUu9Gp3__FxxSePCgY=.8b4765bc-332d-4ab4-8907-07b7ac40bc2d@github.com> On Fri, 27 Aug 2021 23:18:34 GMT, Stuart Marks wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Additional cleanup > > test/jdk/java/util/regex/RegExTest.java line 85: > >> 83: import static org.testng.Assert.fail; >> 84: import static org.testng.Assert.expectThrows; //Replaced by assertThrows in JUnit5 >> 85: > > Slightly odd to mention JUnit 5 here, since this is being converted to a TestNG test. Are these notes for yourself for future work? Ah yes. I'll pull that. ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From igraves at openjdk.java.net Mon Aug 30 15:52:05 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 30 Aug 2021 15:52:05 GMT Subject: RFR: 8271302: Regex Test Refresh [v5] In-Reply-To: References: Message-ID: > 8271302: Regex Test Refresh Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Removing some notes re JUnit5 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5092/files - new: https://git.openjdk.java.net/jdk/pull/5092/files/3f01c172..0845a56f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5092&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5092/head:pull/5092 PR: https://git.openjdk.java.net/jdk/pull/5092 From rriggs at openjdk.java.net Mon Aug 30 15:58:33 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 30 Aug 2021 15:58:33 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v3] In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 11:49:49 GMT, Claes Redestad wrote: >> Refactor to improve inlining, which helps some microbenchmarks exer StringBuilder.append(String) > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Simplify and call getBytes(String, int, byte) when possible LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5291 From sviswanathan at openjdk.java.net Mon Aug 30 16:52:37 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Mon, 30 Aug 2021 16:52:37 GMT Subject: Integrated: 8272861: Add a micro benchmark for vector api In-Reply-To: References: Message-ID: <3tEa3yEvMP7XcXZIFQeipV9JugsJniu4uA5Jh9AwNZM=.e3cac4e4-c5d6-4914-8ec8-ac00c443ee75@github.com> On Mon, 23 Aug 2021 23:18:28 GMT, Sandhya Viswanathan wrote: > This pull request adds a micro benchmark for Vector API. > The Black Scholes algorithm is implemented with and without Vector API. > We see about ~6x gain with Vector API for this micro benchmark using 256 bit vectors. This pull request has now been integrated. Changeset: 5aaa20f8 Author: Sandhya Viswanathan URL: https://git.openjdk.java.net/jdk/commit/5aaa20f898e8679ef1c2c36bd01d48c17be0aacf Stats: 189 lines in 1 file changed: 189 ins; 0 del; 0 mod 8272861: Add a micro benchmark for vector api Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/5234 From mchung at openjdk.java.net Mon Aug 30 16:59:28 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 30 Aug 2021 16:59:28 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Fri, 27 Aug 2021 13:28:08 GMT, Maurizio Cimadamore wrote: > Overall, seems like a solid piece of work. I did not review in full the intricacies with caller sensitive (as I don't know that area too much), but the general rewrite seems solid. Thanks for the review. > One thing I had trouble with was the naming of the various method accessors - for instance, DirectMethodAccessorImpl vs. NativeMethodAccessorImpl vs. DelegatingMethodAccessorImpl vs. AdaptiveMethodAccessor (and there's more). It's not always easy to grasp from the method name which one is new and which one is old. Maybe sprinkling the `Handle` word on any accessor impl would help a bit with that. I can see how this could be confusing. Sprinkling the `Handle` word may help. I will try that. > Similarly, I found the `ClassByteBuilder` name a bit weak, since that is meant to only create instance of custom MHInvokers. A more apt name will help there too. What about `InvokerBuilder` (it creates either MHInvoker or VHInvoker)? > I also had some issues parsing the flow in `ReflectionFactory::newMethodAccessor` (and constructor, has similar issue): > > ``` > if (useNativeAccessor(method)) { > return DirectMethodAccessorImpl.nativeAccessor(method, callerSensitive); > } > return MethodHandleAccessorFactory.newMethodAccessor(method, callerSensitive); > ``` > > Why can't logic like this be encapsulated in a single factory call? E.g. it seems like the code is would like to abstract the differences between the various accessor implementations, but it doesn't seem to get all the way there (it's also possible I'm missing some constraint here). We have to avoid to initialize the `MethodHandleAccessorFactory` class until `java.lang.invoke` is initialized. because `MethodHandleAccessorFactory::` creates lookup object and method handles. I agree it's cleaner to encapsulate these in one single factory method. I think moving the the static fields and the initialization to a holder class may be a way to do it. I will give it a try. > src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 200: > >> 198: return MethodHandleAccessorFactory.newMethodAccessor(method, callerSensitive); >> 199: } else { >> 200: if (!useDirectMethodHandle && noInflation > > seems to me that the `!useDirectMethodHandle` is useless here (always false) ? Good catch! Will fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From igraves at openjdk.java.net Mon Aug 30 17:40:40 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 30 Aug 2021 17:40:40 GMT Subject: Integrated: 8271302: Regex Test Refresh In-Reply-To: References: Message-ID: On Wed, 11 Aug 2021 18:22:42 GMT, Ian Graves wrote: > 8271302: Regex Test Refresh This pull request has now been integrated. Changeset: fecefb85 Author: Ian Graves URL: https://git.openjdk.java.net/jdk/commit/fecefb8541d5056b1a8b105126ac9c566875e056 Stats: 2253 lines in 3 files changed: 220 ins; 989 del; 1044 mod 8271302: Regex Test Refresh Reviewed-by: bchristi, smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From darcy at openjdk.java.net Mon Aug 30 17:57:31 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 30 Aug 2021 17:57:31 GMT Subject: RFR: 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible In-Reply-To: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> References: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> Message-ID: On Mon, 30 Aug 2021 14:26:56 GMT, ?????? ??????? wrote: > Just a very tiny clean-up. > > There are some places in JDK code base where we call `Enum.class.getEnumConstants()` to get all the values of the referenced `enum`. This is excessive, less-readable and slower than just calling `Enum.values()` as in `getEnumConstants()` we have volatile access: > > public T[] getEnumConstants() { > T[] values = getEnumConstantsShared(); > return (values != null) ? values.clone() : null; > } > > private transient volatile T[] enumConstants; > > T[] getEnumConstantsShared() { > T[] constants = enumConstants; > if (constants == null) { /* ... */ } > return constants; > } > > Calling values() method is slightly faster: > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class EnumBenchmark { > > @Benchmark > public Enum[] values() { > return Enum.values(); > } > > @Benchmark > public Enum[] getEnumConstants() { > return Enum.class.getEnumConstants(); > } > > private enum Enum { > A, > B > } > } > > > Benchmark Mode Cnt Score Error Units > EnumBenchmark.getEnumConstants avgt 15 6,265 ? 0,051 ns/op > EnumBenchmark.getEnumConstants:?gc.alloc.rate avgt 15 2434,075 ? 19,568 MB/sec > EnumBenchmark.getEnumConstants:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op > EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space avgt 15 2433,709 ? 70,216 MB/sec > EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space.norm avgt 15 23,998 ? 0,659 B/op > EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space avgt 15 0,009 ? 0,003 MB/sec > EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op > EnumBenchmark.getEnumConstants:?gc.count avgt 15 210,000 counts > EnumBenchmark.getEnumConstants:?gc.time avgt 15 119,000 ms > > EnumBenchmark.values avgt 15 4,164 ? 0,134 ns/op > EnumBenchmark.values:?gc.alloc.rate avgt 15 3665,341 ? 120,721 MB/sec > EnumBenchmark.values:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op > EnumBenchmark.values:?gc.churn.G1_Eden_Space avgt 15 3660,512 ? 137,250 MB/sec > EnumBenchmark.values:?gc.churn.G1_Eden_Space.norm avgt 15 23,972 ? 0,529 B/op > EnumBenchmark.values:?gc.churn.G1_Survivor_Space avgt 15 0,017 ? 0,003 MB/sec > EnumBenchmark.values:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op > EnumBenchmark.values:?gc.count avgt 15 262,000 counts > EnumBenchmark.values:?gc.time avgt 15 155,000 ms src/java.desktop/share/classes/sun/font/AttributeValues.java line 2: > 1: /* > 2: * Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved. Per OpenJDK conventions, the original copyright year must be preserved when a file is updated so "Copyright (c) 2004, 2021," in this case. ------------- PR: https://git.openjdk.java.net/jdk/pull/5303 From alanb at openjdk.java.net Mon Aug 30 18:12:33 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 30 Aug 2021 18:12:33 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v3] In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 11:49:49 GMT, Claes Redestad wrote: >> Refactor to improve inlining, which helps some microbenchmarks exer StringBuilder.append(String) > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Simplify and call getBytes(String, int, byte) when possible Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5291 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 30 19:20:53 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 30 Aug 2021 19:20:53 GMT Subject: RFR: 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible [v2] In-Reply-To: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> References: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> Message-ID: > Just a very tiny clean-up. > > There are some places in JDK code base where we call `Enum.class.getEnumConstants()` to get all the values of the referenced `enum`. This is excessive, less-readable and slower than just calling `Enum.values()` as in `getEnumConstants()` we have volatile access: > > public T[] getEnumConstants() { > T[] values = getEnumConstantsShared(); > return (values != null) ? values.clone() : null; > } > > private transient volatile T[] enumConstants; > > T[] getEnumConstantsShared() { > T[] constants = enumConstants; > if (constants == null) { /* ... */ } > return constants; > } > > Calling values() method is slightly faster: > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class EnumBenchmark { > > @Benchmark > public Enum[] values() { > return Enum.values(); > } > > @Benchmark > public Enum[] getEnumConstants() { > return Enum.class.getEnumConstants(); > } > > private enum Enum { > A, > B > } > } > > > Benchmark Mode Cnt Score Error Units > EnumBenchmark.getEnumConstants avgt 15 6,265 ? 0,051 ns/op > EnumBenchmark.getEnumConstants:?gc.alloc.rate avgt 15 2434,075 ? 19,568 MB/sec > EnumBenchmark.getEnumConstants:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op > EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space avgt 15 2433,709 ? 70,216 MB/sec > EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space.norm avgt 15 23,998 ? 0,659 B/op > EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space avgt 15 0,009 ? 0,003 MB/sec > EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op > EnumBenchmark.getEnumConstants:?gc.count avgt 15 210,000 counts > EnumBenchmark.getEnumConstants:?gc.time avgt 15 119,000 ms > > EnumBenchmark.values avgt 15 4,164 ? 0,134 ns/op > EnumBenchmark.values:?gc.alloc.rate avgt 15 3665,341 ? 120,721 MB/sec > EnumBenchmark.values:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op > EnumBenchmark.values:?gc.churn.G1_Eden_Space avgt 15 3660,512 ? 137,250 MB/sec > EnumBenchmark.values:?gc.churn.G1_Eden_Space.norm avgt 15 23,972 ? 0,529 B/op > EnumBenchmark.values:?gc.churn.G1_Survivor_Space avgt 15 0,017 ? 0,003 MB/sec > EnumBenchmark.values:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op > EnumBenchmark.values:?gc.count avgt 15 262,000 counts > EnumBenchmark.values:?gc.time avgt 15 155,000 ms ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8273140: Fix copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5303/files - new: https://git.openjdk.java.net/jdk/pull/5303/files/90319b2f..1cfb0af3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5303&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5303&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5303.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5303/head:pull/5303 PR: https://git.openjdk.java.net/jdk/pull/5303 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 30 19:20:56 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 30 Aug 2021 19:20:56 GMT Subject: RFR: 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible [v2] In-Reply-To: References: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> Message-ID: On Mon, 30 Aug 2021 17:54:45 GMT, Joe Darcy wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8273140: Fix copyright year > > src/java.desktop/share/classes/sun/font/AttributeValues.java line 2: > >> 1: /* >> 2: * Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved. > > Per OpenJDK conventions, the original copyright year must be preserved when a file is updated so > > "Copyright (c) 2004, 2021," > > in this case. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/5303 From github.com+10835776+stsypanov at openjdk.java.net Mon Aug 30 19:23:57 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 30 Aug 2021 19:23:57 GMT Subject: RFR: 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible [v3] In-Reply-To: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> References: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> Message-ID: > Just a very tiny clean-up. > > There are some places in JDK code base where we call `Enum.class.getEnumConstants()` to get all the values of the referenced `enum`. This is excessive, less-readable and slower than just calling `Enum.values()` as in `getEnumConstants()` we have volatile access: > > public T[] getEnumConstants() { > T[] values = getEnumConstantsShared(); > return (values != null) ? values.clone() : null; > } > > private transient volatile T[] enumConstants; > > T[] getEnumConstantsShared() { > T[] constants = enumConstants; > if (constants == null) { /* ... */ } > return constants; > } > > Calling values() method is slightly faster: > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class EnumBenchmark { > > @Benchmark > public Enum[] values() { > return Enum.values(); > } > > @Benchmark > public Enum[] getEnumConstants() { > return Enum.class.getEnumConstants(); > } > > private enum Enum { > A, > B > } > } > > > Benchmark Mode Cnt Score Error Units > EnumBenchmark.getEnumConstants avgt 15 6,265 ? 0,051 ns/op > EnumBenchmark.getEnumConstants:?gc.alloc.rate avgt 15 2434,075 ? 19,568 MB/sec > EnumBenchmark.getEnumConstants:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op > EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space avgt 15 2433,709 ? 70,216 MB/sec > EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space.norm avgt 15 23,998 ? 0,659 B/op > EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space avgt 15 0,009 ? 0,003 MB/sec > EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op > EnumBenchmark.getEnumConstants:?gc.count avgt 15 210,000 counts > EnumBenchmark.getEnumConstants:?gc.time avgt 15 119,000 ms > > EnumBenchmark.values avgt 15 4,164 ? 0,134 ns/op > EnumBenchmark.values:?gc.alloc.rate avgt 15 3665,341 ? 120,721 MB/sec > EnumBenchmark.values:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op > EnumBenchmark.values:?gc.churn.G1_Eden_Space avgt 15 3660,512 ? 137,250 MB/sec > EnumBenchmark.values:?gc.churn.G1_Eden_Space.norm avgt 15 23,972 ? 0,529 B/op > EnumBenchmark.values:?gc.churn.G1_Survivor_Space avgt 15 0,017 ? 0,003 MB/sec > EnumBenchmark.values:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op > EnumBenchmark.values:?gc.count avgt 15 262,000 counts > EnumBenchmark.values:?gc.time avgt 15 155,000 ms ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8273140: Fix copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5303/files - new: https://git.openjdk.java.net/jdk/pull/5303/files/1cfb0af3..171ecd4e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5303&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5303&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5303.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5303/head:pull/5303 PR: https://git.openjdk.java.net/jdk/pull/5303 From kcr at openjdk.java.net Mon Aug 30 19:32:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 30 Aug 2021 19:32:29 GMT Subject: RFR: 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible [v3] In-Reply-To: References: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> Message-ID: On Mon, 30 Aug 2021 19:23:57 GMT, ?????? ??????? wrote: >> Just a very tiny clean-up. >> >> There are some places in JDK code base where we call `Enum.class.getEnumConstants()` to get all the values of the referenced `enum`. This is excessive, less-readable and slower than just calling `Enum.values()` as in `getEnumConstants()` we have volatile access: >> >> public T[] getEnumConstants() { >> T[] values = getEnumConstantsShared(); >> return (values != null) ? values.clone() : null; >> } >> >> private transient volatile T[] enumConstants; >> >> T[] getEnumConstantsShared() { >> T[] constants = enumConstants; >> if (constants == null) { /* ... */ } >> return constants; >> } >> >> Calling values() method is slightly faster: >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class EnumBenchmark { >> >> @Benchmark >> public Enum[] values() { >> return Enum.values(); >> } >> >> @Benchmark >> public Enum[] getEnumConstants() { >> return Enum.class.getEnumConstants(); >> } >> >> private enum Enum { >> A, >> B >> } >> } >> >> >> Benchmark Mode Cnt Score Error Units >> EnumBenchmark.getEnumConstants avgt 15 6,265 ? 0,051 ns/op >> EnumBenchmark.getEnumConstants:?gc.alloc.rate avgt 15 2434,075 ? 19,568 MB/sec >> EnumBenchmark.getEnumConstants:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op >> EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space avgt 15 2433,709 ? 70,216 MB/sec >> EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space.norm avgt 15 23,998 ? 0,659 B/op >> EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space avgt 15 0,009 ? 0,003 MB/sec >> EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op >> EnumBenchmark.getEnumConstants:?gc.count avgt 15 210,000 counts >> EnumBenchmark.getEnumConstants:?gc.time avgt 15 119,000 ms >> >> EnumBenchmark.values avgt 15 4,164 ? 0,134 ns/op >> EnumBenchmark.values:?gc.alloc.rate avgt 15 3665,341 ? 120,721 MB/sec >> EnumBenchmark.values:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op >> EnumBenchmark.values:?gc.churn.G1_Eden_Space avgt 15 3660,512 ? 137,250 MB/sec >> EnumBenchmark.values:?gc.churn.G1_Eden_Space.norm avgt 15 23,972 ? 0,529 B/op >> EnumBenchmark.values:?gc.churn.G1_Survivor_Space avgt 15 0,017 ? 0,003 MB/sec >> EnumBenchmark.values:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op >> EnumBenchmark.values:?gc.count avgt 15 262,000 counts >> EnumBenchmark.values:?gc.time avgt 15 155,000 ms > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8273140: Fix copyright year You missed two of the copyright year problems. src/java.desktop/share/classes/sun/font/EAttribute.java line 2: > 1: /* > 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. You need to also fix this copyright year. It must be `2005, 2021,` src/java.sql/share/classes/java/sql/JDBCType.java line 2: > 1: /* > 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. This one, too. ------------- PR: https://git.openjdk.java.net/jdk/pull/5303 From vromero at openjdk.java.net Mon Aug 30 20:00:53 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 30 Aug 2021 20:00:53 GMT Subject: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v4] In-Reply-To: References: Message-ID: > Please review this simple PR along with the associated CSR. The PR is basically adding a line the the specification of method `java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a NPE will be thrown. > > TIA > > link to the [CSR](https://bugs.openjdk.java.net/browse/JDK-8272852) Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into JDK-8272347 - adding pattern matching - clarifying that the names parameter is ignored in some cases - addressing review comments - 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5226/files - new: https://git.openjdk.java.net/jdk/pull/5226/files/102cd1aa..e0a7f5b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5226&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5226&range=02-03 Stats: 6008 lines in 269 files changed: 4342 ins; 755 del; 911 mod Patch: https://git.openjdk.java.net/jdk/pull/5226.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5226/head:pull/5226 PR: https://git.openjdk.java.net/jdk/pull/5226 From vromero at openjdk.java.net Mon Aug 30 20:00:56 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 30 Aug 2021 20:00:56 GMT Subject: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v3] In-Reply-To: References: <4kDnwVGaxMk25dGRb2-wDyT6oeafNFiJoVXTKudTh5E=.082451de-1c6d-4651-92ae-532f15768c2e@github.com> Message-ID: On Mon, 30 Aug 2021 01:45:49 GMT, Mandy Chung wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> clarifying that the names parameter is ignored in some cases > > src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 345: > >> 343: Arrays.stream(getters).forEach(Objects::requireNonNull); >> 344: MethodType methodType; >> 345: if (type instanceof MethodType) > > Since you are modifying this file, do you mind taking Jesper's suggestion [1] posted in another PR to use pattern matching. > > Suggestion: > > if (type instanceof MethodType mt) > methodType = mt; > > > [1] https://github.com/openjdk/valhalla/pull/528#discussion_r688100918 sure I will do this before pushing, thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/5226 From naoto at openjdk.java.net Mon Aug 30 21:17:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 30 Aug 2021 21:17:41 GMT Subject: Integrated: 8260265: UTF-8 by Default In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: On Thu, 8 Jul 2021 21:23:00 GMT, Naoto Sato wrote: > This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. > > JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 > CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 This pull request has now been integrated. Changeset: 7fc85409 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/7fc8540907e8e7483ad5729ea416167810aa8747 Stats: 409 lines in 22 files changed: 208 ins; 24 del; 177 mod 8260265: UTF-8 by Default Reviewed-by: alanb, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/4733 From darcy at openjdk.java.net Mon Aug 30 21:18:34 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 30 Aug 2021 21:18:34 GMT Subject: RFR: 8214761: Bug in parallel Kahan summation implementation [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 20:19:31 GMT, Ian Graves wrote: >> 8214761: Bug in parallel Kahan summation implementation > > Ian Graves has updated the pull request incrementally with three additional commits since the last revision: > > - Updates with more test coverage > - stashing > - Stashing The code changes look fine, but IMO the comments should be re-worded a bit. Rather text like // Negating this value because low-order bits are in negated form I suggest something like // Subtract compensation bits The main compensation loop also subtracts the compensation bits. A comment like "subtract compensation bits" makes the corrected handling of them seem less anomalous. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4674 From vromero at openjdk.java.net Mon Aug 30 21:21:31 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 30 Aug 2021 21:21:31 GMT Subject: Integrated: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null In-Reply-To: References: Message-ID: <9CEzWi_cBshqR9JK7tX9VpTIi0G8f4JZUTdUQnWr1KI=.9c7dea35-5532-4677-a837-3af6dcffff26@github.com> On Mon, 23 Aug 2021 18:08:02 GMT, Vicente Romero wrote: > Please review this simple PR along with the associated CSR. The PR is basically adding a line the the specification of method `java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a NPE will be thrown. > > TIA > > link to the [CSR](https://bugs.openjdk.java.net/browse/JDK-8272852) This pull request has now been integrated. Changeset: 0609421d Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/0609421d4b824c5642ca75d525bad3edd72cd23a Stats: 32 lines in 2 files changed: 18 ins; 0 del; 14 mod 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null Reviewed-by: mchung, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/5226 From mullan at openjdk.java.net Mon Aug 30 21:46:31 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 30 Aug 2021 21:46:31 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow In-Reply-To: References: Message-ID: <-W4WXNBep4L7wcY6LA010aqPAAyDvIPrXarqzfFe1T4=.987e1141-23a5-4ca2-b88f-6fbc3f3b223d@github.com> On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. > > The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install a `SecurityManager` at runtime. > > Please note that this code change requires jtreg to be upgraded to 6.1, where a security manager [will not be set](https://bugs.openjdk.java.net/browse/CODETOOLS-7902990). In the class description of `java/lang/SecurityManager` I think it would be useful to add a couple of sub-sections, 1. **Setting a Security Manager** just before the paragraph that starts with "Environments using a security manager will typically set the security manager at startup." and ends with "The current security manager is returned by the getSecurityManager method." 2. **Checking permissions** which starts after the section above and continues to the end. The reason I think this is useful is that you can then add a link from `System.setSecurityManager` to the subsection on **Setting a Security Manager** as I think it will be useful to link those together. The best place for that link is probably in the `@implNote` where it describes the JDK behavior for the `java.security.manager` system property. ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From darcy at openjdk.java.net Mon Aug 30 21:54:34 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 30 Aug 2021 21:54:34 GMT Subject: RFR: 8271225: Add floorDivExact() method to java.lang.[Strict]Math [v3] In-Reply-To: References: Message-ID: <6fynA6X_mU4-xuRrd4b1Kq9DNnR1hH6oGwpz-gGWpfg=.d5ae9314-d1f9-422c-bbd8-541b9747f2e8@github.com> On Thu, 5 Aug 2021 18:57:42 GMT, Brian Burkhalter wrote: >> Add methods `floorDivExact(int,int)` and `floorDivExact(long,long)` to `java.lang.Math` and `java.lang.StrictMath`. > > Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - 8271225: Verbiage update after 8271599 > - Merge > - 8271225: Revert drive-by verbiage updates > - 8271225: Some verbiage updates > - 8271225: Add floorDivExact() method to java.lang.[Strict]Math Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4941 From bpb at openjdk.java.net Mon Aug 30 22:33:25 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 30 Aug 2021 22:33:25 GMT Subject: RFR: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 18:53:23 GMT, Raffaello Giulietti wrote: > Please review this PR to add officially endorsed `ceilDiv()` and `ceilMod()` methods do `j.l.[Strict]Math`. > > Beside adding fresh tests to `test/jdk/java/lang/Math/DivModTests.java`, this PR also corrects small typos in it and exercises tests that were already present but which were never invoked. > Let me know if this is acceptable for a test or if there's a need of a separate issue in the JBS. I don't think a separate JBS issue for the extra test changes here is needed. src/java.base/share/classes/java/lang/Math.java line 1501: > 1499: // if the signs are the same and modulo not zero, round up > 1500: if ((x ^ y) >= 0 && (q * y != x)) { > 1501: return q + 1; In `floorDiv()` this line is `r--` and there is only one return statement in the method. I think the accepted convention is to return as soon as possible like is done here, so perhaps it would be good to change `floorDiv()` to match? In any cases the two should be consistent. src/java.base/share/classes/java/lang/Math.java line 1612: > 1610: // if the signs are the same and modulo not zero, adjust result > 1611: if ((x ^ y) >= 0 && r != 0) { > 1612: return r - y; Similar comment as for `floorDIv()` above: `ceilMod()` does `mod += y` and there is only one return. ------------- PR: https://git.openjdk.java.net/jdk/pull/5285 From mchung at openjdk.java.net Mon Aug 30 23:09:26 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 30 Aug 2021 23:09:26 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v4] In-Reply-To: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: <9ST8yxhjd9J21CG3uGtVDkPk3ri1YDtTURXtgvkCqYc=.72a1612a-68e0-40f9-8e04-aedb25d150ef@github.com> > This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. > > The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. > > The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with four additional commits since the last revision: - Rename the accessor classes to make it explicit for method handles - Add a new test for testing methods whose parameter types and return type not visible to the caller - Move the handling of native accessor to the factory method for method/constructor accessor - DirectConstructorAccessorImpl should take the MHInvoker parameter ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5027/files - new: https://git.openjdk.java.net/jdk/pull/5027/files/cff856f9..ba099fb4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=02-03 Stats: 658 lines in 12 files changed: 401 ins; 202 del; 55 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027 From bpb at openjdk.java.net Mon Aug 30 23:11:33 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 30 Aug 2021 23:11:33 GMT Subject: RFR: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 18:53:23 GMT, Raffaello Giulietti wrote: > Please review this PR to add officially endorsed `ceilDiv()` and `ceilMod()` methods do `j.l.[Strict]Math`. > > Beside adding fresh tests to `test/jdk/java/lang/Math/DivModTests.java`, this PR also corrects small typos in it and exercises tests that were already present but which were never invoked. > Let me know if this is acceptable for a test or if there's a need of a separate issue in the JBS. src/java.base/share/classes/java/lang/Math.java line 1589: > 1587: *

    > 1588: *
  • Regardless of the signs of the arguments, {@code ceilMod}(x, y) > 1589: * is zero exactly when {@code x % y} is zero as well.
  • Do you intend to say "`ceilMod(x, y)` is zero if and only if `x % y` is zero"? That is to say "exactly when" intends "if and only if"? src/java.base/share/classes/java/lang/Math.java line 1591: > 1589: * is zero exactly when {@code x % y} is zero as well. > 1590: *
  • If neither of {@code ceilMod}(x, y) or {@code x % y} is zero, > 1591: * their results differ exactly when the signs of the arguments are the same.
    I would say "If neither `ceilMod(x, y)`nor `x % y` is zero". Also same question as above: by "exactly when" do you intend "if any only if"? ------------- PR: https://git.openjdk.java.net/jdk/pull/5285 From mchung at openjdk.java.net Mon Aug 30 23:58:31 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 30 Aug 2021 23:58:31 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading In-Reply-To: References: Message-ID: On Wed, 25 Aug 2021 09:31:51 GMT, Vladimir Ivanov wrote: > `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. > > Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. > > The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. > > Testing: tier1 - tier6 Thanks for fixing this. JEP 416 depends on this. src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 966: > 964: } > 965: > 966: private static boolean isSystemLoader(ClassLoader loader) { These are builtin loaders. This method may be better to rename to `isBuiltinLoader`. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5246 From mchung at openjdk.java.net Mon Aug 30 23:58:32 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 30 Aug 2021 23:58:32 GMT Subject: RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading In-Reply-To: References: Message-ID: On Thu, 26 Aug 2021 17:57:26 GMT, Paul Sandoz wrote: >> `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. >> >> Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. >> >> The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/) made by Peter Levart @plevart back in 2015. >> >> Testing: tier1 - tier6 > > src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 953: > >> 951: >> 952: /* Determine whether {@code descendant} keeps {@code ancestor} alive through the loader delegation chain. */ >> 953: private static boolean keepsAlive(ClassLoader ancestor, ClassLoader descendant) { > > Might be clearer to name the method by what it is e.g. isAncestor > // Returns true if ancestor can be found descendant's delegation chain. This method is not exactly doing `isAncestor` check. It returns true if `ancestor` is a builtin loader even it's not an ancestor of `descendent`. I agree that it would be helpful if the method is named by what it is. Maybe naming it `isAncestor` but move the `isSystemLoader(ancestor)` check out to the caller. Just a thought. ------------- PR: https://git.openjdk.java.net/jdk/pull/5246 From mchung at openjdk.java.net Tue Aug 31 00:05:14 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 31 Aug 2021 00:05:14 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v5] In-Reply-To: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: > This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. > > The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. > > The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Shorten the class name ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5027/files - new: https://git.openjdk.java.net/jdk/pull/5027/files/ba099fb4..475a1be6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=03-04 Stats: 23 lines in 4 files changed: 0 ins; 0 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027 From dholmes at openjdk.java.net Tue Aug 31 01:00:28 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 31 Aug 2021 01:00:28 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3] In-Reply-To: References: Message-ID: On Sat, 28 Aug 2021 02:34:48 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . >> >> There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. >> The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revised to use native /bin/sleep program on Unix* (non-Windows). > For Windows, a native "BasicSleep" program is used. test/jdk/java/lang/ProcessBuilder/exeBasicSleep.c line 37: > 35: * returned from sleep has limited accuracy. > 36: * > 37: * Note: the file name prefix "exe" identifies the source should be built into SleepMillis(.exe). You mean BasicSleep(.exe) ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From iklam at openjdk.java.net Tue Aug 31 01:05:05 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 31 Aug 2021 01:05:05 GMT Subject: RFR: 8273092: Sort classlist in JDK image [v2] In-Reply-To: References: Message-ID: > When the classlist is generated using build.tools.classlist.HelloClasslist, its contents may be non-deterministic due to Java thread execution order. > > We should sort the generated classlist to make the JDK image's contents more deterministic. > > Tested with Mach5 tier1, tier2, builds-tier5 Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @dfuch comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5288/files - new: https://git.openjdk.java.net/jdk/pull/5288/files/dc170ec0..ee710895 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5288&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5288&range=00-01 Stats: 15 lines in 1 file changed: 7 ins; 7 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5288.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5288/head:pull/5288 PR: https://git.openjdk.java.net/jdk/pull/5288 From iklam at openjdk.java.net Tue Aug 31 01:05:08 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 31 Aug 2021 01:05:08 GMT Subject: RFR: 8273092: Sort classlist in JDK image [v2] In-Reply-To: References: Message-ID: <9ebPG5OrKERdJyatYeoTzqkqbaIw9B2Ud61BThP6gE4=.64044a29-0cd4-49c1-9d1a-1fa313412a80@github.com> On Mon, 30 Aug 2021 12:51:43 GMT, Daniel Fuchs wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @dfuch comments > > make/jdk/src/classes/build/tools/classlist/SortClasslist.java line 58: > >> 56: String line = scanner.nextLine(); >> 57: Matcher m = p.matcher(line); >> 58: if (m.find()) { > > Are we sure that a comment line will not match this regexp, or that if it matches, it is not a comment line? Thanks for the comments. I've swapper the matching order to check for leading `#` and `@` characters first. ------------- PR: https://git.openjdk.java.net/jdk/pull/5288 From dholmes at openjdk.java.net Tue Aug 31 01:29:31 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 31 Aug 2021 01:29:31 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3] In-Reply-To: References: Message-ID: On Sat, 28 Aug 2021 02:34:48 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . >> >> There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. >> The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revised to use native /bin/sleep program on Unix* (non-Windows). > For Windows, a native "BasicSleep" program is used. Hi Roger, I think this can be simplified - see comments. Thanks, David test/jdk/java/lang/ProcessBuilder/Basic.java line 2646: > 2644: if (exePath.toFile().canExecute()) { > 2645: return exePath; > 2646: } Not sure why this is so elaborate when elsewhere in the test we just assume `/usr/bin/env` exists? test/jdk/java/lang/ProcessBuilder/Basic.java line 2662: > 2660: // Fallback to the JavaChild sleep does a sleep for 10 minutes. > 2661: // The fallback the Java$Child is used if the test is run without building > 2662: // the BasicSleep native executable (for Windows). The comment doesn't read correctly. test/jdk/java/lang/ProcessBuilder/Basic.java line 2665: > 2663: > 2664: Path exePath = Path.of(TEST_NATIVEPATH).resolve("BasicSleep.exe"); > 2665: System.out.println("exePath: " + exePath + ", canExec: " + exePath.toFile().canExecute()); What is this for?? ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5239 From dholmes at openjdk.java.net Tue Aug 31 01:29:32 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 31 Aug 2021 01:29:32 GMT Subject: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3] In-Reply-To: References: Message-ID: On Tue, 24 Aug 2021 19:06:55 GMT, Roger Riggs wrote: >> test/jdk/java/lang/ProcessBuilder/Basic.java line 30: >> >>> 28: * 6464154 6523983 6206031 4960438 6631352 6631966 6850957 6850958 >>> 29: * 4947220 7018606 7034570 4244896 5049299 8003488 8054494 8058464 >>> 30: * 8067796 8224905 8263729 8265173 8272600 8231297 >> >> The test should also be modified to use `@run main/othervm/native/timeout=300` so that this test will be flagged by jtreg if `-nativepath:` is not specified. > > It should be possible to run this test as a main, without the overhead of building the native image. > The use of a Java child greatly reduces the complexity of the test and improves its maintainability. > Requiring a native special built program raises the overhead considerably. > And all because the VM can't or won't allow its output to be managed. In the same way the test uses: ` private static final String[] winEnvCommand = {"cmd.exe", "/c", "set"};` you could also have: ` private static final String[] winSleepCommand = {"cmd.exe", "/c", "timeout", "/T", "60", "/NOBREAK"};` ------------- PR: https://git.openjdk.java.net/jdk/pull/5239 From weijun at openjdk.java.net Tue Aug 31 02:08:48 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 31 Aug 2021 02:08:48 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow [v2] In-Reply-To: References: Message-ID: > This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. > > The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install a `SecurityManager` at runtime. > > Please note that this code change requires jtreg to be upgraded to 6.1, where a security manager [will not be set](https://bugs.openjdk.java.net/browse/CODETOOLS-7902990). Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: sections etc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5204/files - new: https://git.openjdk.java.net/jdk/pull/5204/files/63b1b7c9..08635b91 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5204&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5204&range=00-01 Stats: 7 lines in 2 files changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5204.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5204/head:pull/5204 PR: https://git.openjdk.java.net/jdk/pull/5204 From weijun at openjdk.java.net Tue Aug 31 02:08:48 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 31 Aug 2021 02:08:48 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. > > The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install a `SecurityManager` at runtime. > > Please note that this code change requires jtreg to be upgraded to 6.1, where a security manager [will not be set](https://bugs.openjdk.java.net/browse/CODETOOLS-7902990). New commit pushed. Sections added. ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From github.com+70726043+rgiulietti at openjdk.java.net Tue Aug 31 07:31:28 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Tue, 31 Aug 2021 07:31:28 GMT Subject: RFR: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family In-Reply-To: References: Message-ID: <-V3AbM9X4ZSU7Xh0VhS3kznTGAAfgdswJoAukPtDzFY=.413dd1e2-2424-46a1-b05e-f080673bbadc@github.com> On Mon, 30 Aug 2021 22:25:09 GMT, Brian Burkhalter wrote: >> Please review this PR to add officially endorsed `ceilDiv()` and `ceilMod()` methods do `j.l.[Strict]Math`. >> >> Beside adding fresh tests to `test/jdk/java/lang/Math/DivModTests.java`, this PR also corrects small typos in it and exercises tests that were already present but which were never invoked. >> Let me know if this is acceptable for a test or if there's a need of a separate issue in the JBS. > > src/java.base/share/classes/java/lang/Math.java line 1501: > >> 1499: // if the signs are the same and modulo not zero, round up >> 1500: if ((x ^ y) >= 0 && (q * y != x)) { >> 1501: return q + 1; > > In `floorDiv()` this line is `r--` and there is only one return statement in the method. I think the accepted convention is to return as soon as possible like is done here, so perhaps it would be good to change `floorDiv()` to match? In any cases the two should be consistent. Yes, I tend to return as soon as possible (btw, it's a q (for quotient) rather than a r (for remainder). I can of course modify the floorDiv() family to match this convention but I would like not to open an issue just for that. What is best? > src/java.base/share/classes/java/lang/Math.java line 1589: > >> 1587: *
      >> 1588: *
    • Regardless of the signs of the arguments, {@code ceilMod}(x, y) >> 1589: * is zero exactly when {@code x % y} is zero as well.
    • > > Do you intend to say "`ceilMod(x, y)` is zero if and only if `x % y` is zero"? That is to say "exactly when" intends "if and only if"? This is the same wording as in floorMod(). "If and only if", "exactly when", "precisely when" are usually regarded the same afaik. (e.g., see https://en.wikipedia.org/wiki/If_and_only_if) > src/java.base/share/classes/java/lang/Math.java line 1591: > >> 1589: * is zero exactly when {@code x % y} is zero as well. >> 1590: *
    • If neither of {@code ceilMod}(x, y) or {@code x % y} is zero, >> 1591: * their results differ exactly when the signs of the arguments are the same.
      > > I would say "If neither `ceilMod(x, y)`nor `x % y` is zero". Also same question as above: by "exactly when" do you intend "if any only if"? OK, but for consistency then even floorMod() should be changed. Would this require another JBS issue (or CSR)? > src/java.base/share/classes/java/lang/Math.java line 1612: > >> 1610: // if the signs are the same and modulo not zero, adjust result >> 1611: if ((x ^ y) >= 0 && r != 0) { >> 1612: return r - y; > > Similar comment as for `floorDIv()` above: `floorMod()` does `mod += y` and there is only one return. Similar comment as for floorDiv() as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5285 From serb at openjdk.java.net Tue Aug 31 08:20:33 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 31 Aug 2021 08:20:33 GMT Subject: RFR: 8271302: Regex Test Refresh [v5] In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 15:52:05 GMT, Ian Graves wrote: >> 8271302: Regex Test Refresh > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Removing some notes re JUnit5 Looks like it was missed that the test fails oi a github actions: https://github.com/igraves/jdk/runs/3463998089 Run if ! grep --include=test-summary.txt -lqr build/*/test-results -e "TEST SUCCESS" ; then newfailures.txt java/util/regex/NegativeArraySize.java Error: Process completed with exit code 1. Invalid initial heap size: -Xms5G The specified size exceeds the maximum representable size. Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From dfuchs at openjdk.java.net Tue Aug 31 09:10:30 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 31 Aug 2021 09:10:30 GMT Subject: RFR: 8273092: Sort classlist in JDK image [v2] In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 01:05:05 GMT, Ioi Lam wrote: >> When the classlist is generated using build.tools.classlist.HelloClasslist, its contents may be non-deterministic due to Java thread execution order. >> >> We should sort the generated classlist to make the JDK image's contents more deterministic. >> >> Tested with Mach5 tier1, tier2, builds-tier5 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @dfuch comments Thanks Ioi! These changes look good to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5288 From github.com+7837910+xpbob at openjdk.java.net Tue Aug 31 09:35:34 2021 From: github.com+7837910+xpbob at openjdk.java.net (xpbob) Date: Tue, 31 Aug 2021 09:35:34 GMT Subject: RFR: 8271302: Regex Test Refresh [v5] In-Reply-To: References: Message-ID: <1GZ2-BKuJbJOZITqE3I_czluAucGXIN8_nL_K8mhhos=.89d087b8-e2d6-434c-a2de-bd0453976bb2@github.com> On Mon, 30 Aug 2021 15:52:05 GMT, Ian Graves wrote: >> 8271302: Regex Test Refresh > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Removing some notes re JUnit5 https://bugs.openjdk.java.net/browse/JDK-8273169 I'd like to fix it. --- a/test/jdk/java/util/regex/NegativeArraySize.java +++ b/test/jdk/java/util/regex/NegativeArraySize.java @@ -25,7 +25,7 @@ * @test * @bug 8223174 * @summary Pattern.compile() can throw confusing NegativeArraySizeException - * @requires os.maxMemory >= 5g + * @requires os.maxMemory >= 5g & vm.bits == 64 * @run testng/othervm -Xms5G -Xmx5G NegativeArraySize */ ------------- PR: https://git.openjdk.java.net/jdk/pull/5092 From github.com+7837910+xpbob at openjdk.java.net Tue Aug 31 09:47:37 2021 From: github.com+7837910+xpbob at openjdk.java.net (xpbob) Date: Tue, 31 Aug 2021 09:47:37 GMT Subject: RFR: 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302 Message-ID: 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302 ------------- Commit messages: - 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302 Changes: https://git.openjdk.java.net/jdk/pull/5315/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5315&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273169 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5315.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5315/head:pull/5315 PR: https://git.openjdk.java.net/jdk/pull/5315 From jiefu at openjdk.java.net Tue Aug 31 10:46:27 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 31 Aug 2021 10:46:27 GMT Subject: RFR: 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302 In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 09:40:14 GMT, xpbob wrote: > 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302 LGTM Thanks for fixing it. ------------- Marked as reviewed by jiefu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5315 From redestad at openjdk.java.net Tue Aug 31 11:35:28 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 31 Aug 2021 11:35:28 GMT Subject: RFR: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings [v3] In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 11:49:49 GMT, Claes Redestad wrote: >> Refactor to improve inlining, which helps some microbenchmarks exer StringBuilder.append(String) > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Simplify and call getBytes(String, int, byte) when possible Thanks for reviews, everyone! ------------- PR: https://git.openjdk.java.net/jdk/pull/5291 From redestad at openjdk.java.net Tue Aug 31 11:35:29 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 31 Aug 2021 11:35:29 GMT Subject: Integrated: 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings In-Reply-To: References: Message-ID: On Sat, 28 Aug 2021 13:21:24 GMT, Claes Redestad wrote: > Refactor to improve inlining, which helps some microbenchmarks exer StringBuilder.append(String) This pull request has now been integrated. Changeset: 98fa5335 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/98fa53357a66f474090304e53959be5d433d5e5f Stats: 17 lines in 1 file changed: 11 ins; 2 del; 4 mod 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings Reviewed-by: rriggs, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5291 From mullan at openjdk.java.net Tue Aug 31 12:02:27 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 31 Aug 2021 12:02:27 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow [v2] In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 02:08:48 GMT, Weijun Wang wrote: >> This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. >> >> The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install a `SecurityManager` at runtime. >> >> Please note that this code change requires jtreg to be upgraded to 6.1, where a security manager [will not be set](https://bugs.openjdk.java.net/browse/CODETOOLS-7902990). > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > sections etc Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From jai.forums2013 at gmail.com Tue Aug 31 13:39:00 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 31 Aug 2021 19:09:00 +0530 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> <983f15b6-96e3-9aeb-c203-baea91dd1b24@oracle.com> Message-ID: Hello Magnus, On 30/08/21 5:29 pm, Magnus Ihse Bursie wrote: > > > On 2021-08-28 17:16, Alan Bateman wrote: >> On 28/08/2021 05:45, Jaikiran Pai wrote: >>> I hadn't considered the system property approach to switch to old >>> behaviour in my proposals, so this is a very good input and I >>> personally think the most logical proposals so far. >> >> Roger may be right that few would care but it would be changing >> behavior that goes back to JDK 1.0. In your list (and thanks for >> writing down the options with pros/cons) then your 1a where >> SOURCE_DATE_EPOCH changes to write the epoch date rather than the >> current date seems to be most consistent with other tools and the >> wider eco system. It seems the least disruptive in that it doesn't >> change existing behavior and would be opt-in when reproducibility is >> required. Previous discussion was leading towards your option 2 (or >> variants of) but isn't option doesn't help the cases where build >> tools use libraries that rely on the older methods. > > If I understood the numbering and alternatives correctly, I don't > think there is a conflict between 1a and 2, and I think both should be > implemented, for different reasons. > > This is my understanding of the options, with the rationale I see for > choosing them: > > * 1a says that we change the store() method to write the date from > SOURCE_DATE_EPOCH, if it is set -- otherwise it keeps the old > behavior. This allows users who want to use old Java code (or code > they can't modify) to produce output in a reproducible way to do so > without changing the source code of the product. > > * 2 says that we add a new override to store() which also takes an > Instant. This way programmers who write new code and want to make sure > it is always reproducible can send in Instant.EPOCH, and not rely on > the user to configure SOURCE_DATE_EPOCH. > > (In fact, when thinking of it, this seems overly complex. There is no > real need to send in a generic Instant, just an override with a > boolean skipTimestamp, or something like that. Basically, any solution > which allows programmers who write new code to get property files > without timestamps easily, is what's needed to fulfill this spot. > I do agree that it would be good to just get rid of the date comment and let callers control what exact comments (if any) get written out. However, I think that having both - a new method (overloaded or named differently) and at the same time changing the implementation of the existing store(...) methods to make the date comment reproducible is a bit of a overkill for a comment that doesn't even play a functional role in that API. I listed that option of a new overloaded API and would have been in favour of it, if that was the only addition/change that we did to support the date comment disabling/reproducibility. Having said that, I will gladly go ahead and include/work on that additional new API, if there is some general agreement on doing so. -Jaikiran From rriggs at openjdk.java.net Tue Aug 31 13:42:30 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 31 Aug 2021 13:42:30 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow [v2] In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 02:08:48 GMT, Weijun Wang wrote: >> This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. >> >> The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install a `SecurityManager` at runtime. >> >> Please note that this code change requires jtreg to be upgraded to 6.1, where a security manager [will not be set](https://bugs.openjdk.java.net/browse/CODETOOLS-7902990). > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > sections etc Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From ecki at zusammenkunft.net Tue Aug 31 14:02:50 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 31 Aug 2021 14:02:50 +0000 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: <3a4aafaf-7282-cf8a-4643-1af2d9ac1553@oracle.com> References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> <3a4aafaf-7282-cf8a-4643-1af2d9ac1553@oracle.com> Message-ID: BTW it is probably not a good idea to overwrite Properties (for example to get a defined store order). Especially since changes in the past already broke this. However the attached discussion shows that people do need insert-order and/or alphabetical ordered properties ? maybe a more general solution would help (and also make sure that existing implementations which subtype Properties and overwrite entrySet() would continue to work? After all properties is/was not final. https://stackoverflow.com/questions/17011108/how-can-i-write-java-properties-in-a-defined-order On a somewhat related note, I think if the Properties class is not deterministic, preserves order and comments, it?s maybe not a good file,creation APi for Maven anyway. What Plug-ins are affected for which operation? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Roger Riggs Gesendet: Monday, August 30, 2021 5:00:14 PM An: Jaikiran Pai ; core-libs-dev at openjdk.java.net Betreff: Re: Proposal: JDK-8231640 - (prop) Canonical property storage Hi Jaikiran, System properties, especially new ones, should be only settable on the command line and read once. It makes them visible to developers and avoids state-full dependencies and concurrency issues. Retiring system properties is quite difficult because there's no way to know if they are still being used or by whom. The technique using system properties to revert to previous behavior has been used when API changes are unavoidable and the impact on existing applications is not known. It isn't a good solution but does provide a workaround when an issue is discovered. Better to not introduce them in the first place. The use of SOURCE_DATE_EPOCH as proposed seems better than most, as its definition has a wider scope and longer expected life than most properties. Since SOURCE_DATE_EPOCH is an environment variable, not a system property, it will be less visible to developers, but is already read-once at first use of any environment variable as per System.getenv(). $.02, Roger On 8/28/21 12:45 AM, Jaikiran Pai wrote: > Hello Roger, > > On 28/08/21 12:16 am, Roger Riggs wrote: >> Hi, >> >> I'm finding the idea of removing the hardcoded timestamp and adding a >> property to restore compatibility >> strangely attractive. I don't think we've yet found a case where the >> timestamp was needed (but need to keep looking). >> (Adding a timestamp to the comment by the caller of store() is >> already possible) >> >> It will reveal where the timestamp is needed (via some kind of >> failure, though perhaps not a timely one) >> and includes a fallback mechanism when needed. >> >> It will generally cleanup up the behavior of an old API. >> The other approaches make new work for developers based on unclear >> requirements. > > So this is essentially the proposal 1d that I listed in one of my > mails, with the added advantage of allowing users to switch back to > the old behaviour with a system property setting. I hadn't considered > the system property approach to switch to old behaviour in my > proposals, so this is a very good input and I personally think the > most logical proposals so far. One question that however remains is, > how long (how many releases) do we support this new system property? > The --illegal-access option (although not a system property) seems to > be one such example where after a few releases, that option will no > longer be supported and won't play any role. Perhaps this system > property too will follow a similar lifetime? > > One other thing - I believe this new system property must be "set once > at launch time" kind of property, whose value can be set at launch > time and cannot be changed dynamically in the runtime. That would > provide consistency in how the Properties class behaves globally > within that runtime, instead of potentially behaving differently in > different parts of the code, depending on how the callers set/reset > the system property value before calling the "store(...)" APIs. > > -Jaikiran > > From bpb at openjdk.java.net Tue Aug 31 14:45:33 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 31 Aug 2021 14:45:33 GMT Subject: Integrated: 8271225: Add floorDivExact() method to java.lang.[Strict]Math In-Reply-To: References: Message-ID: On Thu, 29 Jul 2021 23:27:32 GMT, Brian Burkhalter wrote: > Add methods `floorDivExact(int,int)` and `floorDivExact(long,long)` to `java.lang.Math` and `java.lang.StrictMath`. This pull request has now been integrated. Changeset: e5518528 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/e55185280126e450e31eb65aa8342aebe6f31606 Stats: 205 lines in 3 files changed: 202 ins; 0 del; 3 mod 8271225: Add floorDivExact() method to java.lang.[Strict]Math Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/4941 From mchung at openjdk.java.net Tue Aug 31 15:59:05 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 31 Aug 2021 15:59:05 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v6] In-Reply-To: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: > This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. > > The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. > > The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Fix NativeAccessor.c build issue for the renamed classes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5027/files - new: https://git.openjdk.java.net/jdk/pull/5027/files/475a1be6..df6fb0a2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=04-05 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027 From lancea at openjdk.java.net Tue Aug 31 16:03:28 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 31 Aug 2021 16:03:28 GMT Subject: RFR: 8270380: Change the default value of the java.security.manager system property to disallow [v2] In-Reply-To: References: Message-ID: <47byIM4hmtU_dH2MzOot6eTzqDyjOdG0wkmDo-W0R7g=.05e31ce2-8ea7-47fe-b179-21056ed5be56@github.com> On Tue, 31 Aug 2021 02:08:48 GMT, Weijun Wang wrote: >> This change modifies the default value of the `java.security.manager` system property from "allow" to "disallow". This means unless it's explicitly set to "allow", any call to `System.setSecurityManager()` would throw an UOE. >> >> The `AllowSecurityManager.java` and `SecurityManagerWarnings.java` tests are updated to confirm this behavior change. Two other tests are updated because they were added after JDK-8267184 and do not have `-Djava.security.manager=allow` on its `@run` line even it they need to install a `SecurityManager` at runtime. >> >> Please note that this code change requires jtreg to be upgraded to 6.1, where a security manager [will not be set](https://bugs.openjdk.java.net/browse/CODETOOLS-7902990). > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > sections etc Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5204 From mcimadamore at openjdk.java.net Tue Aug 31 16:04:29 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 31 Aug 2021 16:04:29 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: <5inKJ9PZa8k_mNpNLOhWptRRfCNbczSYwp3ktqBOn7Y=.cef20445-d4e8-4ca2-8ef6-8dfd5dd6ab20@github.com> On Mon, 30 Aug 2021 16:56:20 GMT, Mandy Chung wrote: > What about `InvokerBuilder` (it creates either MHInvoker or VHInvoker)? Please throw a "Reflection" somewhere :-) - e.g. "ReflectionInvokerBuilder" ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From bpb at openjdk.java.net Tue Aug 31 16:20:29 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 31 Aug 2021 16:20:29 GMT Subject: RFR: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family In-Reply-To: <-V3AbM9X4ZSU7Xh0VhS3kznTGAAfgdswJoAukPtDzFY=.413dd1e2-2424-46a1-b05e-f080673bbadc@github.com> References: <-V3AbM9X4ZSU7Xh0VhS3kznTGAAfgdswJoAukPtDzFY=.413dd1e2-2424-46a1-b05e-f080673bbadc@github.com> Message-ID: On Tue, 31 Aug 2021 07:22:17 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/java/lang/Math.java line 1501: >> >>> 1499: // if the signs are the same and modulo not zero, round up >>> 1500: if ((x ^ y) >= 0 && (q * y != x)) { >>> 1501: return q + 1; >> >> In `floorDiv()` this line is `r--` and there is only one return statement in the method. I think the accepted convention is to return as soon as possible like is done here, so perhaps it would be good to change `floorDiv()` to match? In any cases the two should be consistent. > > Yes, I tend to return as soon as possible (btw, it's a q (for quotient) rather than a r (for remainder). > I can of course modify the floorDiv() family to match this convention but I would like not to open an issue just for that. What is best? I think it's fine to make small changes like this without opening another issue. >> src/java.base/share/classes/java/lang/Math.java line 1591: >> >>> 1589: * is zero exactly when {@code x % y} is zero as well.
    • >>> 1590: *
    • If neither of {@code ceilMod}(x, y) or {@code x % y} is zero, >>> 1591: * their results differ exactly when the signs of the arguments are the same.
      >> >> I would say "If neither `ceilMod(x, y)`nor `x % y` is zero". Also same question as above: by "exactly when" do you intend "if any only if"? > > OK, but for consistency then even floorMod() should be changed. Would this require another JBS issue (or CSR)? If the specifications of the new methods are consistent with their respective `floorX()` analogs then they are fine as-is and no need to change the analogs to match. ------------- PR: https://git.openjdk.java.net/jdk/pull/5285 From iklam at openjdk.java.net Tue Aug 31 16:36:35 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 31 Aug 2021 16:36:35 GMT Subject: Integrated: 8273092: Sort classlist in JDK image In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 23:12:52 GMT, Ioi Lam wrote: > When the classlist is generated using build.tools.classlist.HelloClasslist, its contents may be non-deterministic due to Java thread execution order. > > We should sort the generated classlist to make the JDK image's contents more deterministic. > > Tested with Mach5 tier1, tier2, builds-tier5 This pull request has now been integrated. Changeset: 1996f649 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/1996f649a3a30b7ac4b547a762417f807f5fa414 Stats: 114 lines in 3 files changed: 102 ins; 6 del; 6 mod 8273092: Sort classlist in JDK image Reviewed-by: redestad, ihse, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5288 From iklam at openjdk.java.net Tue Aug 31 16:36:33 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 31 Aug 2021 16:36:33 GMT Subject: RFR: 8273092: Sort classlist in JDK image [v2] In-Reply-To: References: Message-ID: On Sat, 28 Aug 2021 13:18:37 GMT, Claes Redestad wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @dfuch comments > > Seems OK. Thanks @cl4es @magicus @dfuch for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/5288 From mchung at openjdk.java.net Tue Aug 31 16:40:29 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 31 Aug 2021 16:40:29 GMT Subject: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation In-Reply-To: References: Message-ID: <1wmLuhorufPdlzthIXbK6mezL8O9FLSWubIkdn7rDxc=.85831b34-cb3a-4b41-998c-c1960a14d1d3@github.com> On Wed, 25 Aug 2021 22:05:24 GMT, Vladimir Ivanov wrote: > Get rid of WeakReference-based logic in DirectMethodHandle::checkInitialized() and reimplement it with `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`. > > The key observation is that `Unsafe::ensureClassInitialized()` does not block the initializing thread. > > Also, removed `Unsafe::shouldBeInitialized()` in `DMH::shouldBeInitialized(MemberName)` to save on calling into the VM. > `Unsafe::ensureClassInitialized()` already has a fast-path check which checks whether the class is fully initialized or not. > > Testing: tier1 - tier6 Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5258 From mchung at openjdk.java.net Tue Aug 31 16:40:29 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 31 Aug 2021 16:40:29 GMT Subject: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation In-Reply-To: References: Message-ID: On Thu, 26 Aug 2021 15:35:44 GMT, Paul Sandoz wrote: > May i suggest that we add some JavaDoc to `ensureClassInitialized` describing the two cases of the calling thread is the initialization thread or not. This is a good suggestion that also applies to `Lookup::ensureInitialized`. I created https://bugs.openjdk.java.net/browse/JDK-8273194 to improve the javadoc for `Lookup::ensureInitialized`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5258 From serb at openjdk.java.net Tue Aug 31 17:02:27 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 31 Aug 2021 17:02:27 GMT Subject: RFR: 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302 In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 09:40:14 GMT, xpbob wrote: > 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302 Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5315 From mchung at openjdk.java.net Tue Aug 31 17:14:05 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 31 Aug 2021 17:14:05 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v7] In-Reply-To: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: > This reimplements core reflection with method handles. > > For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. > > The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. > > The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. > > Ran tier1-tier8 tests. > > [1] https://bugs.openjdk.java.net/browse/JDK-8013527 > [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Rename InvokerBuilder to ReflectionInvokerBuilder ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5027/files - new: https://git.openjdk.java.net/jdk/pull/5027/files/df6fb0a2..68bb9efe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5027&range=05-06 Stats: 12 lines in 3 files changed: 1 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/5027.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5027/head:pull/5027 PR: https://git.openjdk.java.net/jdk/pull/5027 From mchung at openjdk.java.net Tue Aug 31 17:19:25 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 31 Aug 2021 17:19:25 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3] In-Reply-To: <5inKJ9PZa8k_mNpNLOhWptRRfCNbczSYwp3ktqBOn7Y=.cef20445-d4e8-4ca2-8ef6-8dfd5dd6ab20@github.com> References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> <5inKJ9PZa8k_mNpNLOhWptRRfCNbczSYwp3ktqBOn7Y=.cef20445-d4e8-4ca2-8ef6-8dfd5dd6ab20@github.com> Message-ID: On Tue, 31 Aug 2021 16:01:39 GMT, Maurizio Cimadamore wrote: > Please throw a "Reflection" somewhere :-) - e.g. "ReflectionInvokerBuilder" Done. I'm fine with that. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027 From github.com+7837910+xpbob at openjdk.java.net Tue Aug 31 17:34:33 2021 From: github.com+7837910+xpbob at openjdk.java.net (xpbob) Date: Tue, 31 Aug 2021 17:34:33 GMT Subject: Integrated: 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302 In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 09:40:14 GMT, xpbob wrote: > 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302 This pull request has now been integrated. Changeset: 683e30db Author: bobpengxie Committer: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/683e30db79789ee44b3cc0b44c085de4615bca7b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302 Reviewed-by: jiefu, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/5315 From rfscholte at apache.org Tue Aug 31 18:57:33 2021 From: rfscholte at apache.org (Robert Scholte) Date: Tue, 31 Aug 2021 18:57:33 +0000 Subject: Proposal: JDK-8231640 - (prop) Canonical property storage In-Reply-To: References: <9b90a43f-defc-5100-3b5a-0a69214a706c@gmail.com> <86a3469a-7107-8c32-3240-28b10b470f87@oracle.com> <2c98d073-5a22-9732-b828-c1a08314d1a0@gmail.com> <6d97bada-0388-cb5c-bbbc-2712764e559b@gmail.com> <3a4aafaf-7282-cf8a-4643-1af2d9ac1553@oracle.com> Message-ID: There's one important to keep in mind: escaping. To ensure we're reading the properties correctly, we want to write them using Properties. Although the /META-INF/maven///pom.properties is very predictable, others are not. For example the maven-shade-plugin can rewrite properties files for class relocation. (off-topic: this could use a per-line reader, so comments are preserved) These are just examples I know of, there are much more out there other more complex usage of properties. The Maven Project has several places where Properties is extended for reproducibility, whereas this ticket is about making it part of the API itself, so not everybody needs to write their own extended class for the same purpose. thanks, Robert ------ Origineel bericht ------ Van: "Bernd Eckenfels" Aan: "core-libs-dev at openjdk.java.net" Verzonden: 31-8-2021 16:02:50 Onderwerp: Re: Proposal: JDK-8231640 - (prop) Canonical property storage >BTW it is probably not a good idea to overwrite Properties (for example to get a defined store order). Especially since changes in the past already broke this. However the attached discussion shows that people do need insert-order and/or alphabetical ordered properties ? maybe a more general solution would help (and also make sure that existing implementations which subtype Properties and overwrite entrySet() would continue to work? After all properties is/was not final. > >https://stackoverflow.com/questions/17011108/how-can-i-write-java-properties-in-a-defined-order > >On a somewhat related note, I think if the Properties class is not deterministic, preserves order and comments, it?s maybe not a good file,creation APi for Maven anyway. What Plug-ins are affected for which operation? > >Gruss >Bernd >-- >http://bernd.eckenfels.net >________________________________ >Von: core-libs-dev im Auftrag von Roger Riggs >Gesendet: Monday, August 30, 2021 5:00:14 PM >An: Jaikiran Pai ; core-libs-dev at openjdk.java.net >Betreff: Re: Proposal: JDK-8231640 - (prop) Canonical property storage > >Hi Jaikiran, > >System properties, especially new ones, should be only settable on the >command line and read once. >It makes them visible to developers and avoids state-full dependencies >and concurrency issues. > >Retiring system properties is quite difficult because there's no way to >know if they are still being >used or by whom. The technique using system properties to revert to >previous behavior has >been used when API changes are unavoidable and the impact on existing >applications is not known. >It isn't a good solution but does provide a workaround when an issue is >discovered. > >Better to not introduce them in the first place. > > >The use of SOURCE_DATE_EPOCH as proposed seems better than most, as its >definition >has a wider scope and longer expected life than most properties. > >Since SOURCE_DATE_EPOCH is an environment variable, not a system >property, it will be >less visible to developers, but is already read-once at first use of any >environment variable >as per System.getenv(). > >$.02, Roger > > >On 8/28/21 12:45 AM, Jaikiran Pai wrote: >> Hello Roger, >> >> On 28/08/21 12:16 am, Roger Riggs wrote: >>> Hi, >>> >>> I'm finding the idea of removing the hardcoded timestamp and adding a >>> property to restore compatibility >>> strangely attractive. I don't think we've yet found a case where the >>> timestamp was needed (but need to keep looking). >>> (Adding a timestamp to the comment by the caller of store() is >>> already possible) >>> >>> It will reveal where the timestamp is needed (via some kind of >>> failure, though perhaps not a timely one) >>> and includes a fallback mechanism when needed. >>> >>> It will generally cleanup up the behavior of an old API. >>> The other approaches make new work for developers based on unclear >>> requirements. >> >> So this is essentially the proposal 1d that I listed in one of my >> mails, with the added advantage of allowing users to switch back to >> the old behaviour with a system property setting. I hadn't considered >> the system property approach to switch to old behaviour in my >> proposals, so this is a very good input and I personally think the >> most logical proposals so far. One question that however remains is, >> how long (how many releases) do we support this new system property? >> The --illegal-access option (although not a system property) seems to >> be one such example where after a few releases, that option will no >> longer be supported and won't play any role. Perhaps this system >> property too will follow a similar lifetime? >> >> One other thing - I believe this new system property must be "set once >> at launch time" kind of property, whose value can be set at launch >> time and cannot be changed dynamically in the runtime. That would >> provide consistency in how the Properties class behaves globally >> within that runtime, instead of potentially behaving differently in >> different parts of the code, depending on how the callers set/reset >> the system property value before calling the "store(...)" APIs. >> >> -Jaikiran >> >> > From mullan at openjdk.java.net Tue Aug 31 19:03:46 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 31 Aug 2021 19:03:46 GMT Subject: RFR: 8269039: Disable SHA-1 Signed JARs Message-ID: This change will disable JARs signed with algorithms using SHA-1 by default, and treat them as unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. The specific details are more fully described in the CSR: https://bugs.openjdk.java.net/browse/JDK-8272155. Some additional notes about the fix: - This change was previously backed out of JDK 17 and delayed because of performance regressions. The overall performance is still to be verified, but the primary bottlenecks were addressed as follows: - `sun.security.util.DisabledAlgorithmConstraints` no longer depends on `java.text.SimpleDateFormat` to format date fields which is expensive. - the `jdkCA` constraint has been removed as this caused the `cacerts` keystore to be loaded. Applications using SHA-1 JARs signed by certificates that chain back to private CAs and are impacted by the restrictions can, at their own risk, adjust the properties and add back in the `jdkCA` constraint. - `jarsigner` has been enhanced to more accurately warn about algorithms that are disabled based on the constraints specified in the security properties. Previously it had used a simpler scheme which did not take into account constraints such as `Usage` or `DenyAfter`. Similar changes should also be made to `keytool` but that will be addressed in a separate issue. - Some SHA-1 JARs used by tests where it does not affect the results have been re-signed with SHA-2 algorithms. ------------- Commit messages: - Fix trailing whitespace. - Initial revision. Changes: https://git.openjdk.java.net/jdk/pull/5320/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5320&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269039 Stats: 643 lines in 27 files changed: 301 ins; 214 del; 128 mod Patch: https://git.openjdk.java.net/jdk/pull/5320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5320/head:pull/5320 PR: https://git.openjdk.java.net/jdk/pull/5320 From github.com+53162078+shiyuexw at openjdk.java.net Tue Aug 31 20:01:43 2021 From: github.com+53162078+shiyuexw at openjdk.java.net (wxiang) Date: Tue, 31 Aug 2021 20:01:43 GMT Subject: RFR: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing Message-ID: Using jarIndex for Hibench, there is an unexpected behavior with the exception "Exception in thread "main" org.apache.hadoop.fs.UnsupportedFileSystemException: No FileSystem for scheme "hdfs"". After investigating it, it is related to the usage of ServiceLoader with JarIndex. The below stack shows the issue with JDK11: getResource:1016, URLClassPath$JarLoader (jdk.internal.loader) getResource:937, URLClassPath$JarLoader (jdk.internal.loader) findResource:912, URLClassPath$JarLoader (jdk.internal.loader) next:341, URLClassPath$1 (jdk.internal.loader) hasMoreElements:351, URLClassPath$1 (jdk.internal.loader) hasNext:355, BuiltinClassLoader$1 (jdk.internal.loader) hasMoreElements:363, BuiltinClassLoader$1 (jdk.internal.loader) next:3032, CompoundEnumeration (java.lang) hasMoreElements:3041, CompoundEnumeration (java.lang) nextProviderClass:1203, ServiceLoader$LazyClassPathLookupIterator (java.util) hasNextService:1221, ServiceLoader$LazyClassPathLookupIterator (java.util) hasNext:1265, ServiceLoader$LazyClassPathLookupIterator (java.util) hasNext:1300, ServiceLoader$2 (java.util) hasNext:1385, ServiceLoader$3 (java.util) The below API tries to get all the resources with the same name. public Enumeration findResources(final String name, final boolean check) ``` After using JarIndex, URLClassPath.findResources only returns 1 URL. It is the same as the description in JDK-6957241. The issue still exists in JDK18. Root cause: public Enumeration findResources(final String name, final boolean check) { return new Enumeration<>() { private int index = 0; private URL url = null; private boolean next() { if (url != null) { return true; } else { Loader loader; while ((loader = getLoader(index++)) != null) { url = loader.findResource(name, check); if (url != null) { return true; } } return false; } } ... }; } With the JarIndex, there is only one loader which is corresponding to the jar with the index due to the implementation in JarLoader.getResource(final String name, boolean check, Set visited). Loaders corresponding to other jar packages will not appear in this while. So it only returns 1 instance. To solve the issue, I change the implementation "private boolean next()". If the loader has index, traverse the index and get all the resource from the loader. ------------- Commit messages: - solve Whitespace error - 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing Changes: https://git.openjdk.java.net/jdk/pull/5316/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5316&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6957241 Stats: 769 lines in 8 files changed: 763 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5316/head:pull/5316 PR: https://git.openjdk.java.net/jdk/pull/5316 From github.com+10835776+stsypanov at openjdk.java.net Tue Aug 31 20:04:23 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 31 Aug 2021 20:04:23 GMT Subject: RFR: 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible [v4] In-Reply-To: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> References: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> Message-ID: > Just a very tiny clean-up. > > There are some places in JDK code base where we call `Enum.class.getEnumConstants()` to get all the values of the referenced `enum`. This is excessive, less-readable and slower than just calling `Enum.values()` as in `getEnumConstants()` we have volatile access: > > public T[] getEnumConstants() { > T[] values = getEnumConstantsShared(); > return (values != null) ? values.clone() : null; > } > > private transient volatile T[] enumConstants; > > T[] getEnumConstantsShared() { > T[] constants = enumConstants; > if (constants == null) { /* ... */ } > return constants; > } > > Calling values() method is slightly faster: > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class EnumBenchmark { > > @Benchmark > public Enum[] values() { > return Enum.values(); > } > > @Benchmark > public Enum[] getEnumConstants() { > return Enum.class.getEnumConstants(); > } > > private enum Enum { > A, > B > } > } > > > Benchmark Mode Cnt Score Error Units > EnumBenchmark.getEnumConstants avgt 15 6,265 ? 0,051 ns/op > EnumBenchmark.getEnumConstants:?gc.alloc.rate avgt 15 2434,075 ? 19,568 MB/sec > EnumBenchmark.getEnumConstants:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op > EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space avgt 15 2433,709 ? 70,216 MB/sec > EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space.norm avgt 15 23,998 ? 0,659 B/op > EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space avgt 15 0,009 ? 0,003 MB/sec > EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op > EnumBenchmark.getEnumConstants:?gc.count avgt 15 210,000 counts > EnumBenchmark.getEnumConstants:?gc.time avgt 15 119,000 ms > > EnumBenchmark.values avgt 15 4,164 ? 0,134 ns/op > EnumBenchmark.values:?gc.alloc.rate avgt 15 3665,341 ? 120,721 MB/sec > EnumBenchmark.values:?gc.alloc.rate.norm avgt 15 24,002 ? 0,001 B/op > EnumBenchmark.values:?gc.churn.G1_Eden_Space avgt 15 3660,512 ? 137,250 MB/sec > EnumBenchmark.values:?gc.churn.G1_Eden_Space.norm avgt 15 23,972 ? 0,529 B/op > EnumBenchmark.values:?gc.churn.G1_Survivor_Space avgt 15 0,017 ? 0,003 MB/sec > EnumBenchmark.values:?gc.churn.G1_Survivor_Space.norm avgt 15 ? 10?? B/op > EnumBenchmark.values:?gc.count avgt 15 262,000 counts > EnumBenchmark.values:?gc.time avgt 15 155,000 ms ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8273140: Fix copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5303/files - new: https://git.openjdk.java.net/jdk/pull/5303/files/171ecd4e..a5f58fe2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5303&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5303&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5303.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5303/head:pull/5303 PR: https://git.openjdk.java.net/jdk/pull/5303 From github.com+10835776+stsypanov at openjdk.java.net Tue Aug 31 20:04:30 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 31 Aug 2021 20:04:30 GMT Subject: RFR: 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible [v3] In-Reply-To: References: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com> Message-ID: On Mon, 30 Aug 2021 19:28:11 GMT, Kevin Rushforth wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8273140: Fix copyright year > > src/java.desktop/share/classes/sun/font/EAttribute.java line 2: > >> 1: /* >> 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. > > You need to also fix this copyright year. It must be `2005, 2021,` Right! Fixed > src/java.sql/share/classes/java/sql/JDBCType.java line 2: > >> 1: /* >> 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. > > This one, too. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/5303 From dcubed at openjdk.java.net Tue Aug 31 20:16:05 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 31 Aug 2021 20:16:05 GMT Subject: Integrated: 8273197: ProblemList 2 jtools tests due to JDK-8273187 Message-ID: Trivial fixes to reduce the noise in the JDK18 CI: JDK-8273197 ProblemList 2 jtools tests due to JDK-8273187 JDK-8273198 ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188 These failures happen in Tier5 so I'm ProblemListing them now to give @naotoj time to work on the issues introduced by JDK-8260265 UTF-8 by Default. ------------- Commit messages: - 8273198: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188 - 8273197: ProblemList 2 jtools tests due to JDK-8273187 Changes: https://git.openjdk.java.net/jdk/pull/5321/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5321&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273197 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5321.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5321/head:pull/5321 PR: https://git.openjdk.java.net/jdk/pull/5321 From naoto at openjdk.java.net Tue Aug 31 20:16:05 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 31 Aug 2021 20:16:05 GMT Subject: Integrated: 8273197: ProblemList 2 jtools tests due to JDK-8273187 In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 19:44:08 GMT, Daniel D. Daugherty wrote: > Trivial fixes to reduce the noise in the JDK18 CI: > JDK-8273197 ProblemList 2 jtools tests due to JDK-8273187 > JDK-8273198 ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188 > > These failures happen in Tier5 so I'm ProblemListing them now to give @naotoj time to > work on the issues introduced by JDK-8260265 UTF-8 by Default. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5321 From dcubed at openjdk.java.net Tue Aug 31 20:16:06 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 31 Aug 2021 20:16:06 GMT Subject: Integrated: 8273197: ProblemList 2 jtools tests due to JDK-8273187 In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 19:44:08 GMT, Daniel D. Daugherty wrote: > Trivial fixes to reduce the noise in the JDK18 CI: > JDK-8273197 ProblemList 2 jtools tests due to JDK-8273187 > JDK-8273198 ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188 > > These failures happen in Tier5 so I'm ProblemListing them now to give @naotoj time to > work on the issues introduced by JDK-8260265 UTF-8 by Default. This pull request has now been integrated. Changeset: 9c392d00 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/9c392d008a5a34cdc2ed6339a63f1a0d06efe619 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8273197: ProblemList 2 jtools tests due to JDK-8273187 8273198: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188 Reviewed-by: naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/5321 From mcimadamore at openjdk.java.net Tue Aug 31 20:33:47 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 31 Aug 2021 20:33:47 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v7] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: On Tue, 31 Aug 2021 17:14:05 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation uses `MethodHandle`. For `Field` accessor, the new implementation uses `VarHandle`. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target `MethodHandle` or `VarHandle` from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with `@CallerSensitiveAdapter` for better auditing. See the detailed description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Rename InvokerBuilder to ReflectionInvokerBuilder Thanks for the changes - they look good and they make the code initialization logic easier to follow. Looks good to me. ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5027 From redestad at openjdk.java.net Tue Aug 31 21:08:44 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 31 Aug 2021 21:08:44 GMT Subject: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3] In-Reply-To: References: <9COV9HYIPqfgCG4FMMhwVHc5Qdc1-PQrj8i4WvR87IA=.cc596dde-942c-4cca-a255-ceafbb3d6233@github.com> Message-ID: <36dTd50KfPLLe8tsc6eX2WmWnAiTsap2-jiPwdTXdZk=.d6e218db-8a84-4501-9518-e73fbf2501da@github.com> On Fri, 27 Aug 2021 13:12:33 GMT, Maurizio Cimadamore wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove separate accessor for static vs instance method >> >> There is no effective difference when using MethodHandle::dropArgument for static method. Removing Static*Accessor and Instance*Accessor simplifies the implementation. > > src/java.base/share/classes/jdk/internal/reflect/DirectConstructorAccessorImpl.java line 106: > >> 104: Object invokeImpl(Object[] args) throws Throwable { >> 105: var mhInvoker = mhInvoker(); >> 106: return switch (paramCount) { > > As @plevart observed, I'm also a bit surprised to see this, but I note your comments regarding performance - especially in cold case. Every adaptation counts, I guess, if you're not in the hot path. But let's make sure that the pay off to add the extra hand-specialized cases is worth it - I'd be surprised if spreading arguments is that expensive. While I recall it was motivated primarily for startup (note startup numbers for `-Djdk.reflect.useSpreader=true` in @mlchung reply earlier in this PR), the specialization to avoid the spreader for low-arity arguments also improve performance on throughput microbenchmarks. Surprisingly also reduce the per invocation allocation rate. Allocation profiling suggests that with the specialization a varargs array is entirely eliminated. This is of course somewhat fragile and dependent on a number of things - and might ultimately be an artifact of a rather synthetic microbenchmark that will have little benefit in practice, but it's a rather consistent gain for various number of arguments - even when actually going into a spreader (I have some hypotheses as to why this might happen, but most likely we help the JIT to narrow things down for each kind of invocation scheme with the selector): 18 baseline Benchmark Mode Cnt Score Error Units ReflectionMethods.static_method avgt 10 57.329 ? 4.217 ns/op ReflectionMethods.static_method:?gc.alloc.rate.norm avgt 10 72.006 ? 0.001 B/op ReflectionMethods.static_method_3arg avgt 10 70.940 ? 7.457 ns/op ReflectionMethods.static_method_3arg:?gc.alloc.rate.norm avgt 10 96.008 ? 0.002 B/op ReflectionMethods.static_method_4arg avgt 10 90.453 ? 4.252 ns/op ReflectionMethods.static_method_4arg:?gc.alloc.rate.norm avgt 10 112.010 ? 0.001 B/op pull/5027 Benchmark Mode Cnt Score Error Units ReflectionMethods.static_method avgt 10 41.518 ? 2.444 ns/op ReflectionMethods.static_method:?gc.alloc.rate.norm avgt 10 48.004 ? 0.001 B/op ReflectionMethods.static_method_3arg avgt 10 57.603 ? 3.299 ns/op ReflectionMethods.static_method_3arg:?gc.alloc.rate.norm avgt 10 64.006 ? 0.001 B/op ReflectionMethods.static_method_4arg avgt 10 56.772 ? 3.971 ns/op ReflectionMethods.static_method_4arg:?gc.alloc.rate.norm avgt 10 80.007 ? 0.001 B/op On a patch to remove the specialization on top of pull/5027, performance reverts back to numbers very similar to the baseline: remove-spreader-patch: Benchmark Mode Cnt Score Error Units ReflectionMethods.static_method avgt 10 56.644 ? 4.322 ns/op ReflectionMethods.static_method:?gc.alloc.rate.norm avgt 10 72.006 ? 0.001 B/op ReflectionMethods.static_method_3arg avgt 10 72.353 ? 6.815 ns/op ReflectionMethods.static_method_3arg:?gc.alloc.rate.norm avgt 10 96.008 ? 0.001 B/op ReflectionMethods.static_method_4arg avgt 10 82.820 ? 8.303 ns/op ReflectionMethods.static_method_4arg:?gc.alloc.rate.norm avgt 10 112.009 ? 0.002 B/op I think the cold start reduction alone is worth the extra 100 lines or so of code, but if the gain on these microbenchmarks translates to real throughput gains then I think the complexity is more than paid for. Simplifying it while retaining similar characteristics would be great of course, but I think such an exploration should be done as a follow-up. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027