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: <AZ2cA0l1q5QW5ni-nAICe9i9t0cpry0JUecLASkzBH8=.7615cb8b-fe0d-4e03-b106-62b9ddc5845b@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <AZ2cA0l1q5QW5ni-nAICe9i9t0cpry0JUecLASkzBH8=.7615cb8b-fe0d-4e03-b106-62b9ddc5845b@github.com>
Message-ID: <76rgHvkDeWusTPBrU5QdYwCO2mXQB7fWdfSbhXJNzPo=.3af5326a-4300-4bf1-ae24-465575bf56d3@github.com>

On Thu, 29 Jul 2021 06:33:38 GMT, David Holmes <dholmes at openjdk.org> 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=<file>`.
>> - 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_<PID>=<NMT arguments>`. 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 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: <q0uMTkqIIoUJ-tNbreJxKT6tvRlPw84OPD00gqfllpI=.aa38b235-be60-4cab-a51d-f82604868f4e@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <q0uMTkqIIoUJ-tNbreJxKT6tvRlPw84OPD00gqfllpI=.aa38b235-be60-4cab-a51d-f82604868f4e@github.com>
Message-ID: <6J59w66r98AVbITAaSPy-YszXATSSQKNwmoUQUqtB_s=.f74958b0-1c21-4462-a75e-27b65f7b9e0f@github.com>

On Fri, 30 Jul 2021 20:14:04 GMT, Zhengyu Gu <zgu at openjdk.org> 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: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: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
Message-ID: <ulPAvEJaGZNdzM5a6DHy_lU4gaWWrN1c3iuYCc8pkm0=.091c5df6-d4c7-42f3-9f07-5fb12eec4099@github.com>

> 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=<file>`.
> - 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_<PID>=<NMT arguments>`. 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: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: <ulPAvEJaGZNdzM5a6DHy_lU4gaWWrN1c3iuYCc8pkm0=.091c5df6-d4c7-42f3-9f07-5fb12eec4099@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <ulPAvEJaGZNdzM5a6DHy_lU4gaWWrN1c3iuYCc8pkm0=.091c5df6-d4c7-42f3-9f07-5fb12eec4099@github.com>
Message-ID: <Jr-eSs8a-y1vTkMA0zKtP_YqqYIKG1TgX-O5ydNoPoY=.da011247-115f-40fb-854a-54d122573364@github.com>

On Sun, 1 Aug 2021 08:17:08 GMT, Thomas Stuefe <stuefe at openjdk.org> 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=<file>`.
>> - 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_<PID>=<NMT arguments>`. 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 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: <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@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 <iignatyev at openjdk.org> 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: <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
Message-ID: <5SYAFqMrZzYAv1C1HVLm7ehQ22NmC401c5hiRA0KfsY=.bad74f4b-2787-44d8-9639-a809be6133ea@github.com>

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> 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 david.holmes at oracle.com  Mon Aug  2 04:53:19 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 2 Aug 2021 14:53:19 +1000
Subject: RFR: 8271525: ResourceHashtableBase::iterate() should not
 declared as const
In-Reply-To: <iBzfS9IX9q53zQn7llQlGpRoT-XtZIfImxCaJ5W5D4E=.fe0026ad-c8c4-42dd-bc57-bf7b9f1016ac@github.com>
References: <XZWBVU0L6HC-w0CDFcy8h_2fk6zuMOxN6IIWAB9YS9A=.810fdae5-2127-437a-9b0a-1cb79c703289@github.com>
 <sFMFLYDDiz2szWVYuW93_Hn1-ErKbgjtstu0QTe-ZoQ=.2cec06ba-7455-4c13-8a78-07f1362e1a35@github.com>
 <iBzfS9IX9q53zQn7llQlGpRoT-XtZIfImxCaJ5W5D4E=.fe0026ad-c8c4-42dd-bc57-bf7b9f1016ac@github.com>
Message-ID: <8bc55fc5-c1ec-ac04-6809-2c249aa16687@oracle.com>

On 31/07/2021 4:57 am, Ioi Lam wrote:
> On Fri, 30 Jul 2021 16:10:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> 
>> Hi Ioi,
>>
>>> Hi Thomas,
>>> I've added `const V* get(K const& key) const;` as you suggested.
>>> However, I don't think `iterate()` should be const, because we have code that actually modifies the table's contents:
>>
>> I disagree; iterate does not modify the table. Calling it from a const context (eg. to print the table) should be possible.
> 
> It does. The code I pointed below modifies the `counter` which is stored inside the table. It's possible to write a iterator that prints out all the counters, and resets all of them to zero. To me, this is a modification of the table. The current API does not forbid that, so it should not be declared `const`.
> 
> We need to be consistent:
> 
> - `V* get(key)` returns a `V*` that can be used to modify the contents in the table.
> - `iterate(iter)` passes a `V*` that can be used to modify the contents in the table.
> 
> So we should declare both of these functions const (or declare both of them non-const).
> 
> I think non-const makes more sense. I have a hard time understand why add/removing items are considered non-const, but modifying items are considered const.

I'm getting quite confused. We are talking about the const-ness of the 
_table_ right? Not the const-ness of the keys or values in the table. If 
you add/remove/update a mapping/entry that modifies the table and is 
non-const.

If you iterate and access an item what you do with the item is 
completely independent of the table. And the API for the table shouldn't 
be trying to dictate whether or not you can modify something currently 
in the table IMO.

David
----

>>> https://github.com/openjdk/jdk/blob/77fbd99f792c42bb92a240d38f35e3af25500f99/src/hotspot/share/logging/logAsyncWriter.cpp#L98-L107
>>>
>>> I'll try to refactor the code to have a `const_iterate()` which calls `ITER::do_entry(const&K, const &V)`.
>>
>> If ITER were not a template parameter but a real functor, this would make sense since we could say:
>>
>> ```
>> void iterate(iterator& it);
>> void iterate(const_iterator& it) const;
>> ```
>>
>> but with ITER being a template parameter, I don't know of a way to enforce the use of only const ITERs with a const_iterate. Therefore I am not sure a const_iterate would give us that much.
> 
> My current implementation of `const_iterate()` already enforces that `ITER::do_entry()` must be declared with `(K const&, V const&)`, due to this call:
> 
> 
> bool cont = iter->do_entry(const_cast<K const&>(node->_key), const_cast<VALUE>(node->_value));
> 
> 
> That's because `const_iterate()` instantiates `VALUE` as `V const&`.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4942
> 

From stuefe at openjdk.java.net  Mon Aug  2 05:32:32 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 2 Aug 2021 05:32:32 GMT
Subject: RFR: 8271525: ResourceHashtableBase::iterate() should not
 declared as const
In-Reply-To: <XZWBVU0L6HC-w0CDFcy8h_2fk6zuMOxN6IIWAB9YS9A=.810fdae5-2127-437a-9b0a-1cb79c703289@github.com>
References: <XZWBVU0L6HC-w0CDFcy8h_2fk6zuMOxN6IIWAB9YS9A=.810fdae5-2127-437a-9b0a-1cb79c703289@github.com>
Message-ID: <GGKZPb7DKb5znb-wNW9VQqLkpRHQJ3h5y_BsWjqpHds=.bbb3d034-edcc-4ef0-8ad3-b715d295434f@github.com>

On Fri, 30 Jul 2021 04:16:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> `ResourceHashtableBase::iterate()` is declared `const`, but it can actually change the contents of the table. The same is true for `ResourceHashtableBase::get()`, which returns a non-`const` pointer to the value, allowing the caller to modify it.
> 
> We should declare these two functions as non-`const`. This will also remove a lot of ugly `const_cast<>` code.
> 
> The `iterate()` API is tightened such that the `do_entry()` function can modify the `value` but not the `key`.

Hi Ioi,

In my opinion iterate() is not non-const since it in itself does not modify anything. It calls a user provided hook that may do. 

But that's getting philosophical, and separating an non-const iterate from a const const_iterate is fine by me, if the contract is enforcable.

Cheers, Thomas

src/hotspot/share/utilities/resourceHash.hpp line 81:

> 79:   Node const** lookup_node(unsigned hash, K const& key) const {
> 80:     return const_cast<Node const**>(
> 81:         const_cast<ResourceHashtableBase*>(this)->lookup_node(hash, key));

I would keep this the const version of lookup_node(), since that seems more correct. I would use it in contains() instead of using get(), which does too much.

src/hotspot/share/utilities/resourceHash.hpp line 115:

> 113: 
> 114:   bool contains(K const& key) const {
> 115:     return const_cast<ResourceHashtableBase*>(this)->get(key) != NULL;

Wonder if we can macro out the pattern of un-constifying "this". I would hope that C++ develops and gives us a better looking solution.

src/hotspot/share/utilities/resourceHash.hpp line 129:

> 127: 
> 128:   const V* get(K const& key) const {
> 129:     return const_cast<const V*>(const_cast<ResourceHashtableBase*>(this)->get(key));

I don't think the return cast is needed.

src/hotspot/share/utilities/resourceHash.hpp line 212:

> 210:       NODE* node = *bucket;
> 211:       while (node != NULL) {
> 212:         bool cont = iter->do_entry(const_cast<K const&>(node->_key), const_cast<VALUE>(node->_value));

I don't grok the casts, why are they needed? Node is already const type here, no?

-------------

Changes requested by stuefe (Reviewer).

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Mon Aug  2 06:56:53 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Mon, 2 Aug 2021 06:56:53 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v4]
In-Reply-To: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
References: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
Message-ID: <IDlsnuO-fVajeGfo7bfC4q1-rRe0wEmYjk4_lVXGFkk=.82de94b0-a2ac-4f84-8278-7d03765036c3@github.com>

> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
> 
> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
> 
> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

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

  Added VS version check

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4848/files
  - new: https://git.openjdk.java.net/jdk/pull/4848/files/d70eb4a6..f09c7b64

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

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

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Mon Aug  2 07:20:00 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Mon, 2 Aug 2021 07:20:00 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v5]
In-Reply-To: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
References: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
Message-ID: <rrfKVt_Zi6LxVLmExshMdYw1H8RKbnT_v9vusJG1S5I=.c2dfa21c-dbfd-44f6-a410-9c304c456841@github.com>

> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
> 
> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
> 
> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

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

  fix _MSC_VER check

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4848/files
  - new: https://git.openjdk.java.net/jdk/pull/4848/files/f09c7b64..427c46ce

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

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

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

From dholmes at openjdk.java.net  Mon Aug  2 07:35:36 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 2 Aug 2021 07:35:36 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v5]
In-Reply-To: <rrfKVt_Zi6LxVLmExshMdYw1H8RKbnT_v9vusJG1S5I=.c2dfa21c-dbfd-44f6-a410-9c304c456841@github.com>
References: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
 <rrfKVt_Zi6LxVLmExshMdYw1H8RKbnT_v9vusJG1S5I=.c2dfa21c-dbfd-44f6-a410-9c304c456841@github.com>
Message-ID: <CY13xRSK7MtBcy5DA6A3QdweP2Cllh621mhVLR-TAjI=.32970575-8a18-4d55-992f-597f822defa9@github.com>

On Mon, 2 Aug 2021 07:20:00 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
>> 
>> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
>> 
>> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix _MSC_VER check

src/hotspot/os_cpu/windows_x86/orderAccess_windows_x86.hpp line 64:

> 62: #if _MSC_VER >= 1927
> 63: {
> 64: //_serialize() ntrinsic is supported starting from VS2019-16.7.2

16.7.2 is the earliest I could look at, but it could be supported earlier. Also _MSC_VER of 1927 would start with 16.7.0 so it wouldn't quite be right to test for that if it only come in with 16.7.2.

Typo: ntrinsic

src/hotspot/os_cpu/windows_x86/orderAccess_windows_x86.hpp line 66:

> 64: //_serialize() ntrinsic is supported starting from VS2019-16.7.2
> 65:   if (VM_Version::supports_serialize()) {
> 66:     _xxserialize();

_xx ???

-------------

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

From aph at openjdk.java.net  Mon Aug  2 09:08:31 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 2 Aug 2021 09:08:31 GMT
Subject: RFR: 8267356: AArch64: Vector API SVE codegen support [v4]
In-Reply-To: <zVMzpXKcRgj7PDQtvuIWFLaGosHDlJq4RvfzVmJQAOQ=.a1ffc678-bbd8-49e2-a9f9-a7d015b65e29@github.com>
References: <04_lDZDCcLLfXx6XmrbVdGXkPmqNrYzQuHBJzQ9Oa5k=.f3ef1398-c8b4-4162-9631-3dbfb6594250@github.com>
 <zVMzpXKcRgj7PDQtvuIWFLaGosHDlJq4RvfzVmJQAOQ=.a1ffc678-bbd8-49e2-a9f9-a7d015b65e29@github.com>
Message-ID: <qUXWcb5x4xt6h4piLvYLAOaiHxSlsBDY8p9h4nFY0Ik=.3a280d67-aa24-4681-9162-e3769a022cc1@github.com>

On Thu, 29 Jul 2021 08:21:54 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

>> This is the integration of current SVE work done in panama-vector/vectorIntrinscs, which includes:
>> 
>> 1. Code generation for Vector API c2 IR nodes with SVE.
>> 2. Non-max vector size support with SVE, e.g. using *128Vector (and *64Vector) APIs on 256-bit SVE environment could also generate optimized SVE instructions with predicate feature.
>> 3. Some more SVE assemblers (and tests) used by the codegen part.
>> 
>> Note: VectorMask<E\> is still represented in vector register, a further improvement to map mask to predicate register is under development at https://github.com/openjdk/panama-vector/tree/vectorIntrinsics+mask
>> 
>> 
>> Test: tier1-3 with vector api test cases passed on 512-bit SVE hardware with MaxVectorSize=16/32/64.
>
> Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing part

Looks pretty good.
I think we should put all of the SVE assembler into a separate header file, but let's do that after this patch in order to keep the diffs in the history.

-------------

Marked as reviewed by aph (Reviewer).

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

From njian at openjdk.java.net  Mon Aug  2 09:26:32 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Mon, 2 Aug 2021 09:26:32 GMT
Subject: RFR: 8267356: AArch64: Vector API SVE codegen support [v4]
In-Reply-To: <qUXWcb5x4xt6h4piLvYLAOaiHxSlsBDY8p9h4nFY0Ik=.3a280d67-aa24-4681-9162-e3769a022cc1@github.com>
References: <04_lDZDCcLLfXx6XmrbVdGXkPmqNrYzQuHBJzQ9Oa5k=.f3ef1398-c8b4-4162-9631-3dbfb6594250@github.com>
 <zVMzpXKcRgj7PDQtvuIWFLaGosHDlJq4RvfzVmJQAOQ=.a1ffc678-bbd8-49e2-a9f9-a7d015b65e29@github.com>
 <qUXWcb5x4xt6h4piLvYLAOaiHxSlsBDY8p9h4nFY0Ik=.3a280d67-aa24-4681-9162-e3769a022cc1@github.com>
Message-ID: <M1anaCv0Yn3frlzVz709LaIOvpo0qPRn4Pq3EEaRE6k=.a5fdf5f5-8d9c-4b79-88ae-efba577364fd@github.com>

On Mon, 2 Aug 2021 09:05:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I think we should put all of the SVE assembler into a separate header file, but let's do that after this patch in order to keep the diffs in the history.

Thank you for the review, Andrew! I will take care of the header file separation after the integration.

-------------

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

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: <Cuddlk-XPnwxcvd6Y0kZs9jKh6IocZih1gA9njsDFD4=.7c6f04f1-fe9a-42cb-acae-489b76b712b4@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <g4NiARIHx5BTgvq6uoi9LqqcJRkJT2NiK_-qMrrv-H0=.bbbf85f5-8da9-467a-b5e0-b47bc8b73172@github.com>
 <80NDhQE20WOO7LMCDS9C9zYQIRy-YKqNiGgrPQAPI64=.ef6e55d9-8995-4669-9c6f-e10a61bd427f@github.com>
 <wGe0vflu7uZ8O0WsAz2OdkpjtiyXLkafQF-w5x3n1gU=.57343745-db2f-42b9-b1cb-2694a741c7f6@github.com>
 <b3tc72GBp_aSCngNXWbJFncPyTJT3mF-NoSYPqAGGlw=.bf5d98c7-62e9-46f0-bbc4-6aeb86b77a3d@github.com>
 <v5HmhFytrDnyrexCubsJSA0AxT5_FfrWD2yoN_2uRlQ=.a13c4127-46d4-4a94-aeca-31a99549a2bf@github.com>
 <_CXJ5Lcpd7-PqzRzGAtEE4NyZzAGirYGSgVT7KbPyFw=.f2ce7164-7d28-4b6e-9a79-9417054e0113@github.com>
 <Cuddlk-XPnwxcvd6Y0kZs9jKh6IocZih1gA9njsDFD4=.7c6f04f1-fe9a-42cb-acae-489b76b712b4@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 <mbaesken at openjdk.org> 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 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: <eEhXFsXnwTqnIiBC3yAKoXepAmefbQ_nYqUY-HuWcrU=.36c90671-d0c8-43d1-a702-bfe48a76b54c@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <rTeSwF9Asx2ubpKeNiWKyeQimGIueSI891YBrCxf6jQ=.67422d7a-6b38-40d3-ad93-2b333d2eb5f6@github.com>
 <I_H8qAj7GzW14TXK-i3OLvU0UlLnNr27toU60-hyrAc=.1530f028-f77a-40d4-854a-ced3e4cde329@github.com>
 <eEhXFsXnwTqnIiBC3yAKoXepAmefbQ_nYqUY-HuWcrU=.36c90671-d0c8-43d1-a702-bfe48a76b54c@github.com>
Message-ID: <zRgBTbv6Yrvp0h54Us-8DoovVzJbnyQNWujXRB7Bj4w=.784802f1-4c3b-42d4-a9a9-249ec6483a8c@github.com>

On Fri, 30 Jul 2021 09:32:22 GMT, Thomas Stuefe <stuefe at openjdk.org> 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 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: <iZ7WptYlKPCVRXDsu2SsMJhijMkM1DPWzcX9FYct69M=.62d2b846-bda5-47c8-a337-98f77b38e05b@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <rTeSwF9Asx2ubpKeNiWKyeQimGIueSI891YBrCxf6jQ=.67422d7a-6b38-40d3-ad93-2b333d2eb5f6@github.com>
 <iZ7WptYlKPCVRXDsu2SsMJhijMkM1DPWzcX9FYct69M=.62d2b846-bda5-47c8-a337-98f77b38e05b@github.com>
Message-ID: <9fJF6K7k4Pn7Ktu4W9KgcjmekQv3wYfS1pWiA0SlntI=.177a2a19-0639-4a8b-8ed5-f5f3d4030713@github.com>

On Fri, 30 Jul 2021 09:44:57 GMT, Thomas Stuefe <stuefe at openjdk.org> 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: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: <ulPAvEJaGZNdzM5a6DHy_lU4gaWWrN1c3iuYCc8pkm0=.091c5df6-d4c7-42f3-9f07-5fb12eec4099@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <ulPAvEJaGZNdzM5a6DHy_lU4gaWWrN1c3iuYCc8pkm0=.091c5df6-d4c7-42f3-9f07-5fb12eec4099@github.com>
Message-ID: <t3Ztw4M5tB5RsBcK7jnDZIzz0uDYAlkjn5qJ63_BCkU=.d2f9fee4-7e54-4dbb-9873-6e828658679d@github.com>

On Sun, 1 Aug 2021 08:17:08 GMT, Thomas Stuefe <stuefe at openjdk.org> 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=<file>`.
>> - 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_<PID>=<NMT arguments>`. 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 coleenp at openjdk.java.net  Mon Aug  2 14:44:39 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 2 Aug 2021 14:44:39 GMT
Subject: RFR: 8271506: Add ResourceHashtable support for deleting selected
 entries [v2]
In-Reply-To: <abiZ0UbyyWbgW6wKRjNXnz4K_V1QHFnBoapHYr9_bZI=.77dc2045-5e50-4e7c-b2c8-4c7a0e10aace@github.com>
References: <uy8PELNMluNW3W2gbOXHB0lIZerO6ukQJiymf3K2kk4=.d22cf552-3632-4cdd-b67f-bdf7f3df6291@github.com>
 <abiZ0UbyyWbgW6wKRjNXnz4K_V1QHFnBoapHYr9_bZI=.77dc2045-5e50-4e7c-b2c8-4c7a0e10aace@github.com>
Message-ID: <BNAzCYPVbF9pMQaxGBReYFsByyUXy76lQu6lCZ6f4qY=.63620a09-8e37-4887-8771-eaf600d93c50@github.com>

On Fri, 30 Jul 2021 13:42:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The ResourceHashtable doesn't have a way to delete selected entries based on things like their class has been unloaded, which is needed to replace Hashtable with ResourceHashtable.
>> The Nodes of the ResourceHashtable has a Key and Value of  template types.
>> template<typename K, typename V>
>> class ResourceHashtableNode : public ResourceObj {
>> public:
>>   unsigned _hash;
>>   K _key;
>>   V _value;
>> ...
>> But there's no destructor so that ~K and ~V are not called (if I understand C++ correctly).
>> 
>> When instantiated with a value that's not a pointer, calling code does this:
>> 
>>   SourceObjInfo src_info(ref, read_only, follow_mode);
>>   bool created;
>>   SourceObjInfo* p = _src_obj_table.put_if_absent(src_obj, src_info, &created);
>> 
>> So if SourceObjInfo has a destructor, it'll have to have a careful assignment operator so that the value copied into the hashtable doesn't get deleted.
>> 
>> In this patch, I assign the responsibility of deleting the Key and Value of the hashtable to the do_entry function, because it's simple.  If we want to use more advanced unreadable C++ code, someone will have to suggest an alternate set of changes, because my C++ is not up to this.
>> 
>> Tested with tier1-3, gtest, and upcoming patch for JDK-8048190.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make unlink non-const because it's not.

I don't think this should be blocked by JDK-8271525 since there is still discussion on that approach, which doesn't really affect this change.

-------------

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

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: <t3Ztw4M5tB5RsBcK7jnDZIzz0uDYAlkjn5qJ63_BCkU=.d2f9fee4-7e54-4dbb-9873-6e828658679d@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <ulPAvEJaGZNdzM5a6DHy_lU4gaWWrN1c3iuYCc8pkm0=.091c5df6-d4c7-42f3-9f07-5fb12eec4099@github.com>
 <t3Ztw4M5tB5RsBcK7jnDZIzz0uDYAlkjn5qJ63_BCkU=.d2f9fee4-7e54-4dbb-9873-6e828658679d@github.com>
Message-ID: <L4GhigHJd9MSdg-gHiF8xYeo8ZAZ9eo52ZX_3-uolQA=.48b3968c-610b-4f52-9b8b-e0721fb9d5a7@github.com>

On Mon, 2 Aug 2021 14:38:23 GMT, Coleen Phillimore <coleenp at openjdk.org> 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 iklam at openjdk.java.net  Mon Aug  2 15:52:37 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 2 Aug 2021 15:52:37 GMT
Subject: RFR: 8271506: Add ResourceHashtable support for deleting selected
 entries [v2]
In-Reply-To: <abiZ0UbyyWbgW6wKRjNXnz4K_V1QHFnBoapHYr9_bZI=.77dc2045-5e50-4e7c-b2c8-4c7a0e10aace@github.com>
References: <uy8PELNMluNW3W2gbOXHB0lIZerO6ukQJiymf3K2kk4=.d22cf552-3632-4cdd-b67f-bdf7f3df6291@github.com>
 <abiZ0UbyyWbgW6wKRjNXnz4K_V1QHFnBoapHYr9_bZI=.77dc2045-5e50-4e7c-b2c8-4c7a0e10aace@github.com>
Message-ID: <kg0hO3Vh-U3OlNB7siAheKyl08i0IcADG-7kgm-V_lA=.f02d8673-c4b6-438c-a571-7c99f102aaf9@github.com>

On Fri, 30 Jul 2021 13:42:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The ResourceHashtable doesn't have a way to delete selected entries based on things like their class has been unloaded, which is needed to replace Hashtable with ResourceHashtable.
>> The Nodes of the ResourceHashtable has a Key and Value of  template types.
>> template<typename K, typename V>
>> class ResourceHashtableNode : public ResourceObj {
>> public:
>>   unsigned _hash;
>>   K _key;
>>   V _value;
>> ...
>> But there's no destructor so that ~K and ~V are not called (if I understand C++ correctly).
>> 
>> When instantiated with a value that's not a pointer, calling code does this:
>> 
>>   SourceObjInfo src_info(ref, read_only, follow_mode);
>>   bool created;
>>   SourceObjInfo* p = _src_obj_table.put_if_absent(src_obj, src_info, &created);
>> 
>> So if SourceObjInfo has a destructor, it'll have to have a careful assignment operator so that the value copied into the hashtable doesn't get deleted.
>> 
>> In this patch, I assign the responsibility of deleting the Key and Value of the hashtable to the do_entry function, because it's simple.  If we want to use more advanced unreadable C++ code, someone will have to suggest an alternate set of changes, because my C++ is not up to this.
>> 
>> Tested with tier1-3, gtest, and upcoming patch for JDK-8048190.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make unlink non-const because it's not.

LGTM. I agree this shouldn't be blocked by JDK-8271525.

-------------

Marked as reviewed by iklam (Reviewer).

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

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: <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
Message-ID: <Sd7psaMNOzPgXn6MXO4nqbYOar95nebcGeDQ7TUYZCo=.156f24b1-bce1-4ab8-bd21-414aa51d8839@github.com>

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> 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 github.com+58006833+xbzhang99 at openjdk.java.net  Mon Aug  2 16:17:58 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Mon, 2 Aug 2021 16:17:58 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v6]
In-Reply-To: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
References: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
Message-ID: <ncdx-m6-zW2tKZS0atEBKVncHgMlb4YCTCxpISnN71I=.10e7d1e1-d134-4ce2-b7eb-6da2e12af495@github.com>

> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
> 
> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
> 
> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

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

  fix typo and change to require _MSC_VER >= 1928 to be safe

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4848/files
  - new: https://git.openjdk.java.net/jdk/pull/4848/files/427c46ce..e17b37c6

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

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

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Mon Aug  2 16:17:59 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Mon, 2 Aug 2021 16:17:59 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v5]
In-Reply-To: <CY13xRSK7MtBcy5DA6A3QdweP2Cllh621mhVLR-TAjI=.32970575-8a18-4d55-992f-597f822defa9@github.com>
References: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
 <rrfKVt_Zi6LxVLmExshMdYw1H8RKbnT_v9vusJG1S5I=.c2dfa21c-dbfd-44f6-a410-9c304c456841@github.com>
 <CY13xRSK7MtBcy5DA6A3QdweP2Cllh621mhVLR-TAjI=.32970575-8a18-4d55-992f-597f822defa9@github.com>
Message-ID: <yyZjGX3lOArncgt-KMJvlH8QvLFtg-ohnbBoYUuMq4Q=.2e8ae724-b50e-4adc-849f-4498dd12b222@github.com>

On Mon, 2 Aug 2021 07:32:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix _MSC_VER check
>
> src/hotspot/os_cpu/windows_x86/orderAccess_windows_x86.hpp line 64:
> 
>> 62: #if _MSC_VER >= 1927
>> 63: {
>> 64: //_serialize() ntrinsic is supported starting from VS2019-16.7.2
> 
> 16.7.2 is the earliest I could look at, but it could be supported earlier. Also _MSC_VER of 1927 would start with 16.7.0 so it wouldn't quite be right to test for that if it only come in with 16.7.2.
> 
> Typo: ntrinsic

I changed to 1928 to be on the safe side

-------------

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

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: <loW4C0OHE9UVTbpoyDspljVodi4xA8xKi2spS1AALyc=.bff9a367-c923-45ef-a9e5-f5fe8df547af@github.com>

> 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: <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
Message-ID: <gLiHwnjyHZocgtJJSFk1q98oV4Ffqz7e5VWhgI1Ld0o=.8555b8c4-05ca-42bf-96d6-a0e70bd04056@github.com>

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> 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: <Sd7psaMNOzPgXn6MXO4nqbYOar95nebcGeDQ7TUYZCo=.156f24b1-bce1-4ab8-bd21-414aa51d8839@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
 <Sd7psaMNOzPgXn6MXO4nqbYOar95nebcGeDQ7TUYZCo=.156f24b1-bce1-4ab8-bd21-414aa51d8839@github.com>
Message-ID: <h5CHlSF_Cj70P2Y6laxQMT2SpslrjXfEv_jl45W8A_U=.2c44b77c-b57c-4bb1-8f75-db555212e33f@github.com>

On Mon, 2 Aug 2021 15:56:39 GMT, Vladimir Kozlov <kvn at openjdk.org> 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 stuefe at openjdk.java.net  Mon Aug  2 18:49:35 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 2 Aug 2021 18:49:35 GMT
Subject: RFR: 8271506: Add ResourceHashtable support for deleting selected
 entries [v2]
In-Reply-To: <abiZ0UbyyWbgW6wKRjNXnz4K_V1QHFnBoapHYr9_bZI=.77dc2045-5e50-4e7c-b2c8-4c7a0e10aace@github.com>
References: <uy8PELNMluNW3W2gbOXHB0lIZerO6ukQJiymf3K2kk4=.d22cf552-3632-4cdd-b67f-bdf7f3df6291@github.com>
 <abiZ0UbyyWbgW6wKRjNXnz4K_V1QHFnBoapHYr9_bZI=.77dc2045-5e50-4e7c-b2c8-4c7a0e10aace@github.com>
Message-ID: <9yBjX7g559QAY7I0c5LwsUWkhywWJM2aEXLmuXvl9d8=.67fb9233-7c89-4eda-93bd-78ac386dc2e4@github.com>

On Fri, 30 Jul 2021 13:42:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The ResourceHashtable doesn't have a way to delete selected entries based on things like their class has been unloaded, which is needed to replace Hashtable with ResourceHashtable.
>> The Nodes of the ResourceHashtable has a Key and Value of  template types.
>> template<typename K, typename V>
>> class ResourceHashtableNode : public ResourceObj {
>> public:
>>   unsigned _hash;
>>   K _key;
>>   V _value;
>> ...
>> But there's no destructor so that ~K and ~V are not called (if I understand C++ correctly).
>> 
>> When instantiated with a value that's not a pointer, calling code does this:
>> 
>>   SourceObjInfo src_info(ref, read_only, follow_mode);
>>   bool created;
>>   SourceObjInfo* p = _src_obj_table.put_if_absent(src_obj, src_info, &created);
>> 
>> So if SourceObjInfo has a destructor, it'll have to have a careful assignment operator so that the value copied into the hashtable doesn't get deleted.
>> 
>> In this patch, I assign the responsibility of deleting the Key and Value of the hashtable to the do_entry function, because it's simple.  If we want to use more advanced unreadable C++ code, someone will have to suggest an alternate set of changes, because my C++ is not up to this.
>> 
>> Tested with tier1-3, gtest, and upcoming patch for JDK-8048190.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make unlink non-const because it's not.

Hi Coleen, 

looks good to me. One minor remark, but I leave it up to you, this is good as it is.

Thanks, Thomas

src/hotspot/share/utilities/resourceHash.hpp line 230:

> 228:         Node* node = *ptr;
> 229:         // do_entry must clean up the key and value in Node.
> 230:         bool clean = iter->do_entry(node->_key, node->_value);

Unless I miss it, you don't enforce the constness here, no? So, nothing prevents the called hook from modifying key or value. You may do what Ioi did in https://github.com/openjdk/jdk/pull/4942 and const-cast the parameters for the call.

-------------

Marked as reviewed by stuefe (Reviewer).

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

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 <iignatyev at openjdk.org> 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 <iignatyev at openjdk.org>
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: <gLiHwnjyHZocgtJJSFk1q98oV4Ffqz7e5VWhgI1Ld0o=.8555b8c4-05ca-42bf-96d6-a0e70bd04056@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
 <gLiHwnjyHZocgtJJSFk1q98oV4Ffqz7e5VWhgI1Ld0o=.8555b8c4-05ca-42bf-96d6-a0e70bd04056@github.com>
Message-ID: <b3283810-5f7e-7161-3bca-5f064dda8441@oracle.com>

On 3/08/2021 2:25 am, Igor Ignatyev wrote:
> On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> 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 dholmes at openjdk.java.net  Mon Aug  2 22:22:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 2 Aug 2021 22:22:30 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v6]
In-Reply-To: <ncdx-m6-zW2tKZS0atEBKVncHgMlb4YCTCxpISnN71I=.10e7d1e1-d134-4ce2-b7eb-6da2e12af495@github.com>
References: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
 <ncdx-m6-zW2tKZS0atEBKVncHgMlb4YCTCxpISnN71I=.10e7d1e1-d134-4ce2-b7eb-6da2e12af495@github.com>
Message-ID: <p0HWexx5NcLUvOGpE7jQ2EK4HLamlpw7k5iCboKVVjI=.f223f1c4-dfa8-432a-86f4-18dcbfc985ab@github.com>

On Mon, 2 Aug 2021 16:17:58 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
>> 
>> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
>> 
>> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo and change to require _MSC_VER >= 1928 to be safe

Thanks Xubo, I will run this through our test system using VS 2019 and VS 2017 before approving. You will still need a second reviewer after that.

David

-------------

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

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: <x4gxlN2xHvsE06SPR_CBvGX3nJVJSaziK1bUssfkoDM=.d87127af-ccd2-4fe7-b2ef-1d5d8a7a901b@github.com>

> 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: <x4gxlN2xHvsE06SPR_CBvGX3nJVJSaziK1bUssfkoDM=.d87127af-ccd2-4fe7-b2ef-1d5d8a7a901b@github.com>
References: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com>
 <x4gxlN2xHvsE06SPR_CBvGX3nJVJSaziK1bUssfkoDM=.d87127af-ccd2-4fe7-b2ef-1d5d8a7a901b@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 <jwilhelm at openjdk.org> 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 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: <q50Sls0m6fLJKDMqVBPDlAWgKsOEw56pE3dN29kw1Yc=.20bfa085-2669-4d43-b083-d37c4c516afd@github.com>

On Mon, 2 Aug 2021 23:30:55 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: c8add223
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
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 dholmes at openjdk.java.net  Tue Aug  3 01:18:35 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 3 Aug 2021 01:18:35 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v6]
In-Reply-To: <ncdx-m6-zW2tKZS0atEBKVncHgMlb4YCTCxpISnN71I=.10e7d1e1-d134-4ce2-b7eb-6da2e12af495@github.com>
References: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
 <ncdx-m6-zW2tKZS0atEBKVncHgMlb4YCTCxpISnN71I=.10e7d1e1-d134-4ce2-b7eb-6da2e12af495@github.com>
Message-ID: <V7iRVu6_Ppnp_ZoSPJ6EWaHLtkEqKFWPcWbDi58Ba8w=.69b0e425-5fb6-4b36-95a3-9161a1a54e32@github.com>

On Mon, 2 Aug 2021 16:17:58 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
>> 
>> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
>> 
>> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo and change to require _MSC_VER >= 1928 to be safe

@xbzhang99 what testing have you done on this?

All the JVMCI tests are failing as JVMCI needs to know about the new CPU feature bit for some reason:
`JVMCIError: Missing CPU feature constants: [SERIALIZE]`
I'm trying to find out what needs to be done to fix this.

-------------

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

From dholmes at openjdk.java.net  Tue Aug  3 01:57:33 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 3 Aug 2021 01:57:33 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v6]
In-Reply-To: <ncdx-m6-zW2tKZS0atEBKVncHgMlb4YCTCxpISnN71I=.10e7d1e1-d134-4ce2-b7eb-6da2e12af495@github.com>
References: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
 <ncdx-m6-zW2tKZS0atEBKVncHgMlb4YCTCxpISnN71I=.10e7d1e1-d134-4ce2-b7eb-6da2e12af495@github.com>
Message-ID: <9YNJgZpYCz4z9ndc5vsckJLGMY0avkBdYwFYERGKnoA=.c1237b2f-bae1-4bd4-b63f-b2d252ced4a1@github.com>

On Mon, 2 Aug 2021 16:17:58 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
>> 
>> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
>> 
>> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo and change to require _MSC_VER >= 1928 to be safe

You need this additional patch:

diff --git a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java
index 3fc5b6e7936..f22e120ae53 100644
--- a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java
+++ b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java
@@ -220,6 +220,7 @@ public class AMD64 extends Architecture {
         AVX512_VBMI2,
         AVX512_VBMI,
         HV,
+        SERIALIZE,
     }
 
     private final EnumSet<CPUFeature> features;

-------------

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

From dholmes at openjdk.java.net  Tue Aug  3 04:07:33 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 3 Aug 2021 04:07:33 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v6]
In-Reply-To: <ncdx-m6-zW2tKZS0atEBKVncHgMlb4YCTCxpISnN71I=.10e7d1e1-d134-4ce2-b7eb-6da2e12af495@github.com>
References: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
 <ncdx-m6-zW2tKZS0atEBKVncHgMlb4YCTCxpISnN71I=.10e7d1e1-d134-4ce2-b7eb-6da2e12af495@github.com>
Message-ID: <hKxHKqPaT3F-xDUFx-2VCjzgbvL__8zJhLHpyQRrExQ=.2de18359-ee56-46a1-890e-4ca641081584@github.com>

On Mon, 2 Aug 2021 16:17:58 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
>> 
>> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
>> 
>> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo and change to require _MSC_VER >= 1928 to be safe

Our testing passed with the additional patch.

-------------

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Tue Aug  3 06:07:57 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Tue, 3 Aug 2021 06:07:57 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v7]
In-Reply-To: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
References: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
Message-ID: <JjXh5pIfNPmpGjXZ_-dMAnOIgJq9M8GNxJsUkaQn6rI=.f45647ee-2e16-4a04-87e5-283b0e643023@github.com>

> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
> 
> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
> 
> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

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

  fix jvmci

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4848/files
  - new: https://git.openjdk.java.net/jdk/pull/4848/files/e17b37c6..ef649f1d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4848&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4848&range=05-06

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

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

From dholmes at openjdk.java.net  Tue Aug  3 06:17:39 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 3 Aug 2021 06:17:39 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v7]
In-Reply-To: <JjXh5pIfNPmpGjXZ_-dMAnOIgJq9M8GNxJsUkaQn6rI=.f45647ee-2e16-4a04-87e5-283b0e643023@github.com>
References: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
 <JjXh5pIfNPmpGjXZ_-dMAnOIgJq9M8GNxJsUkaQn6rI=.f45647ee-2e16-4a04-87e5-283b0e643023@github.com>
Message-ID: <oUWM4TvSHc0CTahGs1WS_mI45su_E4NPGmqOcvVUeQk=.b15630f3-edc1-443c-8bc8-ac9991622569@github.com>

On Tue, 3 Aug 2021 06:07:57 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
>> 
>> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
>> 
>> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix jvmci

These changes seem fine to me now.

A second review is still needed.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

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

From tschatzl at openjdk.java.net  Tue Aug  3 08:40:33 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 3 Aug 2021 08:40:33 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v7]
In-Reply-To: <JjXh5pIfNPmpGjXZ_-dMAnOIgJq9M8GNxJsUkaQn6rI=.f45647ee-2e16-4a04-87e5-283b0e643023@github.com>
References: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
 <JjXh5pIfNPmpGjXZ_-dMAnOIgJq9M8GNxJsUkaQn6rI=.f45647ee-2e16-4a04-87e5-283b0e643023@github.com>
Message-ID: <n4k5Z0XRSswxurDkiT3QXtYZGlTK3ipRKwql9DIGEsc=.56bafebe-7504-438a-a549-74073c7cd313@github.com>

On Tue, 3 Aug 2021 06:07:57 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
>> 
>> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
>> 
>> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix jvmci

Lgtm apart from the "ntrinsic" typo mentioned by @dholmes

-------------

Marked as reviewed by tschatzl (Reviewer).

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

From aph at openjdk.java.net  Tue Aug  3 10:23:30 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 3 Aug 2021 10:23:30 GMT
Subject: RFR: 8267356: AArch64: Vector API SVE codegen support [v4]
In-Reply-To: <zVMzpXKcRgj7PDQtvuIWFLaGosHDlJq4RvfzVmJQAOQ=.a1ffc678-bbd8-49e2-a9f9-a7d015b65e29@github.com>
References: <04_lDZDCcLLfXx6XmrbVdGXkPmqNrYzQuHBJzQ9Oa5k=.f3ef1398-c8b4-4162-9631-3dbfb6594250@github.com>
 <zVMzpXKcRgj7PDQtvuIWFLaGosHDlJq4RvfzVmJQAOQ=.a1ffc678-bbd8-49e2-a9f9-a7d015b65e29@github.com>
Message-ID: <bGW_m8ggB2GVLPuqut0GOw3I_ZfAvwB3BrrFvRTcTdE=.759104ee-08f4-4b36-9e2a-610773209832@github.com>

On Thu, 29 Jul 2021 08:21:54 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

>> This is the integration of current SVE work done in panama-vector/vectorIntrinscs, which includes:
>> 
>> 1. Code generation for Vector API c2 IR nodes with SVE.
>> 2. Non-max vector size support with SVE, e.g. using *128Vector (and *64Vector) APIs on 256-bit SVE environment could also generate optimized SVE instructions with predicate feature.
>> 3. Some more SVE assemblers (and tests) used by the codegen part.
>> 
>> Note: VectorMask<E\> is still represented in vector register, a further improvement to map mask to predicate register is under development at https://github.com/openjdk/panama-vector/tree/vectorIntrinsics+mask
>> 
>> 
>> Test: tier1-3 with vector api test cases passed on 512-bit SVE hardware with MaxVectorSize=16/32/64.
>
> Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing part

src/hotspot/cpu/aarch64/assembler_aarch64.cpp line 70:

> 68: 
> 69: Assembler::SIMD_Arrangement Assembler::esize2arrangement(unsigned esize, bool isQ) {
> 70:   assert(esize < ARRAY_SIZE(_esize2arrangement_table) &&

Please consider making this a guarantee. The cost is minimal, and we've been saved by guarantees elsewhere in this file.

-------------

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

From aph at openjdk.java.net  Tue Aug  3 10:29:30 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 3 Aug 2021 10:29:30 GMT
Subject: RFR: 8267356: AArch64: Vector API SVE codegen support [v4]
In-Reply-To: <zVMzpXKcRgj7PDQtvuIWFLaGosHDlJq4RvfzVmJQAOQ=.a1ffc678-bbd8-49e2-a9f9-a7d015b65e29@github.com>
References: <04_lDZDCcLLfXx6XmrbVdGXkPmqNrYzQuHBJzQ9Oa5k=.f3ef1398-c8b4-4162-9631-3dbfb6594250@github.com>
 <zVMzpXKcRgj7PDQtvuIWFLaGosHDlJq4RvfzVmJQAOQ=.a1ffc678-bbd8-49e2-a9f9-a7d015b65e29@github.com>
Message-ID: <BnCPDU6ESCd4e3tfbmyijZRH7Gxod9yi1pp70PmuvnU=.3ec1996e-e2f3-4917-952b-5751f1afd547@github.com>

On Thu, 29 Jul 2021 08:21:54 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

>> This is the integration of current SVE work done in panama-vector/vectorIntrinscs, which includes:
>> 
>> 1. Code generation for Vector API c2 IR nodes with SVE.
>> 2. Non-max vector size support with SVE, e.g. using *128Vector (and *64Vector) APIs on 256-bit SVE environment could also generate optimized SVE instructions with predicate feature.
>> 3. Some more SVE assemblers (and tests) used by the codegen part.
>> 
>> Note: VectorMask<E\> is still represented in vector register, a further improvement to map mask to predicate register is under development at https://github.com/openjdk/panama-vector/tree/vectorIntrinsics+mask
>> 
>> 
>> Test: tier1-3 with vector api test cases passed on 512-bit SVE hardware with MaxVectorSize=16/32/64.
>
> Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing part

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 957:

> 955:     case BoolTest::eq: condition = Assembler::EQ; break;
> 956:     case BoolTest::ne: condition = Assembler::NE; break;
> 957:     case BoolTest::le: z1 = zm; z2 = zn;  // Swap the two inputs

This might warn on some targets, so we'd need to fix it anyway, so please do it now. Better to duplicate the action and break.

-------------

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

From shade at openjdk.java.net  Tue Aug  3 12:13:32 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 3 Aug 2021 12:13:32 GMT
Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering [v3]
In-Reply-To: <6m_sTEtwhTj1zH7SK6fdyzjavt9cykNU48ktFB96CmM=.a32e4a69-80b7-42f6-90ca-984a88209211@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
 <OeK5Ff0cZaQ7qV2HFv8IsffVTbME9-ozEXSSu-gWsO8=.72593252-988a-478d-9360-51282530b8a6@github.com>
 <6m_sTEtwhTj1zH7SK6fdyzjavt9cykNU48ktFB96CmM=.a32e4a69-80b7-42f6-90ca-984a88209211@github.com>
Message-ID: <RmbV6o6_ND26X7ORiA1MS9J9APAkiQSnOS9I1m7E-t8=.6c5c98a4-bfef-451d-820d-a0e1bdc5da7a@github.com>

On Fri, 19 Mar 2021 11:32:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase.
>
> Looks good to me.

I actually wanted to see if @rkennke has troubles with keeping current mark word accesses at "relaxed".

-------------

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Tue Aug  3 16:39:56 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Tue, 3 Aug 2021 16:39:56 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v8]
In-Reply-To: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
References: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
Message-ID: <eZUqxWa8oIJRX85OnBrMVHY4Vb_CsOGnLBNmG_e6Zxc=.0c245521-f61d-4591-987c-c9b1c5311088@github.com>

> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
> 
> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
> 
> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

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

  fix a typo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4848/files
  - new: https://git.openjdk.java.net/jdk/pull/4848/files/ef649f1d..ca93ded7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4848&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4848&range=06-07

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

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

From coleenp at openjdk.java.net  Tue Aug  3 17:23:36 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 3 Aug 2021 17:23:36 GMT
Subject: RFR: 8271506: Add ResourceHashtable support for deleting selected
 entries [v2]
In-Reply-To: <abiZ0UbyyWbgW6wKRjNXnz4K_V1QHFnBoapHYr9_bZI=.77dc2045-5e50-4e7c-b2c8-4c7a0e10aace@github.com>
References: <uy8PELNMluNW3W2gbOXHB0lIZerO6ukQJiymf3K2kk4=.d22cf552-3632-4cdd-b67f-bdf7f3df6291@github.com>
 <abiZ0UbyyWbgW6wKRjNXnz4K_V1QHFnBoapHYr9_bZI=.77dc2045-5e50-4e7c-b2c8-4c7a0e10aace@github.com>
Message-ID: <Ho8dAGW4saIObzB0yQ7jfsbGgpqGMq-Sj0BKGwWyYLw=.a26daea4-cd01-4deb-9d2b-0b7caa93dac7@github.com>

On Fri, 30 Jul 2021 13:42:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The ResourceHashtable doesn't have a way to delete selected entries based on things like their class has been unloaded, which is needed to replace Hashtable with ResourceHashtable.
>> The Nodes of the ResourceHashtable has a Key and Value of  template types.
>> template<typename K, typename V>
>> class ResourceHashtableNode : public ResourceObj {
>> public:
>>   unsigned _hash;
>>   K _key;
>>   V _value;
>> ...
>> But there's no destructor so that ~K and ~V are not called (if I understand C++ correctly).
>> 
>> When instantiated with a value that's not a pointer, calling code does this:
>> 
>>   SourceObjInfo src_info(ref, read_only, follow_mode);
>>   bool created;
>>   SourceObjInfo* p = _src_obj_table.put_if_absent(src_obj, src_info, &created);
>> 
>> So if SourceObjInfo has a destructor, it'll have to have a careful assignment operator so that the value copied into the hashtable doesn't get deleted.
>> 
>> In this patch, I assign the responsibility of deleting the Key and Value of the hashtable to the do_entry function, because it's simple.  If we want to use more advanced unreadable C++ code, someone will have to suggest an alternate set of changes, because my C++ is not up to this.
>> 
>> Tested with tier1-3, gtest, and upcoming patch for JDK-8048190.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make unlink non-const because it's not.

Thanks Thomas and Ioi for the code reviews.

Yes, Ioi, hopefully you can just move this unlink function in your changes.

-------------

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

From coleenp at openjdk.java.net  Tue Aug  3 17:23:37 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 3 Aug 2021 17:23:37 GMT
Subject: RFR: 8271506: Add ResourceHashtable support for deleting selected
 entries [v2]
In-Reply-To: <9yBjX7g559QAY7I0c5LwsUWkhywWJM2aEXLmuXvl9d8=.67fb9233-7c89-4eda-93bd-78ac386dc2e4@github.com>
References: <uy8PELNMluNW3W2gbOXHB0lIZerO6ukQJiymf3K2kk4=.d22cf552-3632-4cdd-b67f-bdf7f3df6291@github.com>
 <abiZ0UbyyWbgW6wKRjNXnz4K_V1QHFnBoapHYr9_bZI=.77dc2045-5e50-4e7c-b2c8-4c7a0e10aace@github.com>
 <9yBjX7g559QAY7I0c5LwsUWkhywWJM2aEXLmuXvl9d8=.67fb9233-7c89-4eda-93bd-78ac386dc2e4@github.com>
Message-ID: <YBghHt9f2abzVnrALtC2wT8o6movdbQcbPvWMIKhBzc=.b8c157b6-05e8-49fa-844e-0be0651d68f5@github.com>

On Mon, 2 Aug 2021 18:43:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make unlink non-const because it's not.
>
> src/hotspot/share/utilities/resourceHash.hpp line 230:
> 
>> 228:         Node* node = *ptr;
>> 229:         // do_entry must clean up the key and value in Node.
>> 230:         bool clean = iter->do_entry(node->_key, node->_value);
> 
> Unless I miss it, you don't enforce the constness here, no? So, nothing prevents the called hook from modifying key or value. You may do what Ioi did in https://github.com/openjdk/jdk/pull/4942 and const-cast the parameters for the call.

I thought I answered this in email but I don't see it.  I want the do_entry function to modify the arguments, like calling their destructor or free operators.

-------------

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

From coleenp at openjdk.java.net  Tue Aug  3 17:23:38 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 3 Aug 2021 17:23:38 GMT
Subject: Integrated: 8271506: Add ResourceHashtable support for deleting
 selected entries
In-Reply-To: <uy8PELNMluNW3W2gbOXHB0lIZerO6ukQJiymf3K2kk4=.d22cf552-3632-4cdd-b67f-bdf7f3df6291@github.com>
References: <uy8PELNMluNW3W2gbOXHB0lIZerO6ukQJiymf3K2kk4=.d22cf552-3632-4cdd-b67f-bdf7f3df6291@github.com>
Message-ID: <BDocm6U4uozi60u8cikrKIRlbUcniK3dpIgJOu5h3CA=.e91a101c-e468-4215-b11d-d5e6aa2f9d09@github.com>

On Thu, 29 Jul 2021 21:00:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The ResourceHashtable doesn't have a way to delete selected entries based on things like their class has been unloaded, which is needed to replace Hashtable with ResourceHashtable.
> The Nodes of the ResourceHashtable has a Key and Value of  template types.
> template<typename K, typename V>
> class ResourceHashtableNode : public ResourceObj {
> public:
>   unsigned _hash;
>   K _key;
>   V _value;
> ...
> But there's no destructor so that ~K and ~V are not called (if I understand C++ correctly).
> 
> When instantiated with a value that's not a pointer, calling code does this:
> 
>   SourceObjInfo src_info(ref, read_only, follow_mode);
>   bool created;
>   SourceObjInfo* p = _src_obj_table.put_if_absent(src_obj, src_info, &created);
> 
> So if SourceObjInfo has a destructor, it'll have to have a careful assignment operator so that the value copied into the hashtable doesn't get deleted.
> 
> In this patch, I assign the responsibility of deleting the Key and Value of the hashtable to the do_entry function, because it's simple.  If we want to use more advanced unreadable C++ code, someone will have to suggest an alternate set of changes, because my C++ is not up to this.
> 
> Tested with tier1-3, gtest, and upcoming patch for JDK-8048190.

This pull request has now been integrated.

Changeset: f15d6cbc
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f15d6cbcaf191b9718ab51b1e8b72938c0abdd6b
Stats:     56 lines in 2 files changed: 55 ins; 0 del; 1 mod

8271506: Add ResourceHashtable support for deleting selected entries

Reviewed-by: iklam, stuefe

-------------

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

From sviswanathan at openjdk.java.net  Tue Aug  3 17:46:36 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 3 Aug 2021 17:46:36 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v8]
In-Reply-To: <eZUqxWa8oIJRX85OnBrMVHY4Vb_CsOGnLBNmG_e6Zxc=.0c245521-f61d-4591-987c-c9b1c5311088@github.com>
References: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
 <eZUqxWa8oIJRX85OnBrMVHY4Vb_CsOGnLBNmG_e6Zxc=.0c245521-f61d-4591-987c-c9b1c5311088@github.com>
Message-ID: <jxxogAvYOomH-OwOBEZuyO2-GiIy2elTOrE8XPtca04=.efa13ef5-acdd-4377-8c3a-cc3ddd847e2c@github.com>

On Tue, 3 Aug 2021 16:39:56 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

>> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
>> 
>> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
>> 
>> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
>
> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo

Marked as reviewed by sviswanathan (Reviewer).

The patch looks good to me.

-------------

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

From iignatyev at openjdk.java.net  Wed Aug  4 00:23:41 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 4 Aug 2021 00:23:41 GMT
Subject: RFR: 8271824: mark hotspot runtime/CompressedOops tests which ignore
 external VM flags
Message-ID: <EAI6qhkG3_u9Z-KibwU6ZjO_rNtnqijo96l62h9U_0E=.d3fd82d3-21d8-475f-ab16-f4eefe012cb4@github.com>

Hi all,

could you please review this patch that adds `@requires vm.flagless` to `runtime/CompressedOops/` tests as they ignore external VM flags in the JVMs which perform actual testing actions?

Thanks,
-- Igor

-------------

Commit messages:
 - copyright year
 - 8271824

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

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

From svkamath at openjdk.java.net  Wed Aug  4 02:24:05 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Wed, 4 Aug 2021 02:24:05 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
Message-ID: <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>

> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
> Performance gain of ~1.5x - 2x for message sizes 8k and above.

Smita Kamath has updated the pull request incrementally with five additional commits since the last revision:

 - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
 - Updates, comment and variable cleanup
 - merge rest
 - merge
 - fixes and code comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4019/files
  - new: https://git.openjdk.java.net/jdk/pull/4019/files/0f834eed..69145008

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=05-06

  Stats: 219 lines in 1 file changed: 83 ins; 60 del; 76 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4019.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4019/head:pull/4019

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

From ascarpino at openjdk.java.net  Wed Aug  4 02:55:35 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 4 Aug 2021 02:55:35 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
Message-ID: <8JmsgR04uSH-He_4TmB-wclbo-StWympdRSEclXly5I=.32804f3c-e8fb-461c-96f5-b309614fbd05@github.com>

On Wed, 4 Aug 2021 02:24:05 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>  - Updates, comment and variable cleanup
>  - merge rest
>  - merge
>  - fixes and code comments

The latest changes I just pushed into the repo should address the remaining Java issues.

-------------

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

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: <ulPAvEJaGZNdzM5a6DHy_lU4gaWWrN1c3iuYCc8pkm0=.091c5df6-d4c7-42f3-9f07-5fb12eec4099@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <ulPAvEJaGZNdzM5a6DHy_lU4gaWWrN1c3iuYCc8pkm0=.091c5df6-d4c7-42f3-9f07-5fb12eec4099@github.com>
Message-ID: <kGatKckF7HugxwRcrbFmWhTghfNRbtx9NPr_tVGc40Q=.d8a00a0d-488b-48ec-85f7-c3f96d6fb88f@github.com>

On Sun, 1 Aug 2021 08:17:08 GMT, Thomas Stuefe <stuefe at openjdk.org> 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=<file>`.
>> - 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_<PID>=<NMT arguments>`. 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 dholmes at openjdk.java.net  Wed Aug  4 05:08:34 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 4 Aug 2021 05:08:34 GMT
Subject: RFR: 8271824: mark hotspot runtime/CompressedOops tests which
 ignore external VM flags
In-Reply-To: <EAI6qhkG3_u9Z-KibwU6ZjO_rNtnqijo96l62h9U_0E=.d3fd82d3-21d8-475f-ab16-f4eefe012cb4@github.com>
References: <EAI6qhkG3_u9Z-KibwU6ZjO_rNtnqijo96l62h9U_0E=.d3fd82d3-21d8-475f-ab16-f4eefe012cb4@github.com>
Message-ID: <uOgDnvs-I9hvVlVDLoa_KCcl4GIA2m6ocDI6apP3Xgw=.2ac03934-5adb-4250-9a69-dddedd497313@github.com>

On Wed, 4 Aug 2021 00:16:41 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this patch that adds `@requires vm.flagless` to `runtime/CompressedOops/` tests as they ignore external VM flags in the JVMs which perform actual testing actions?
> 
> Thanks,
> -- Igor

Looks good.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

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

From iignatyev at openjdk.java.net  Wed Aug  4 05:17:34 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 4 Aug 2021 05:17:34 GMT
Subject: RFR: 8271824: mark hotspot runtime/CompressedOops tests which
 ignore external VM flags
In-Reply-To: <EAI6qhkG3_u9Z-KibwU6ZjO_rNtnqijo96l62h9U_0E=.d3fd82d3-21d8-475f-ab16-f4eefe012cb4@github.com>
References: <EAI6qhkG3_u9Z-KibwU6ZjO_rNtnqijo96l62h9U_0E=.d3fd82d3-21d8-475f-ab16-f4eefe012cb4@github.com>
Message-ID: <OtgBbyS2jScUXEEhHR0aDfDnBPEoPeLLEmVdpQzBp4o=.398ef6b5-b94a-4552-ba1f-62dc1f778a71@github.com>

On Wed, 4 Aug 2021 00:16:41 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this patch that adds `@requires vm.flagless` to `runtime/CompressedOops/` tests as they ignore external VM flags in the JVMs which perform actual testing actions?
> 
> Thanks,
> -- Igor

Thanks, David.

-------------

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

From iignatyev at openjdk.java.net  Wed Aug  4 05:24:32 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 4 Aug 2021 05:24:32 GMT
Subject: Integrated: 8271824: mark hotspot runtime/CompressedOops tests which
 ignore external VM flags
In-Reply-To: <EAI6qhkG3_u9Z-KibwU6ZjO_rNtnqijo96l62h9U_0E=.d3fd82d3-21d8-475f-ab16-f4eefe012cb4@github.com>
References: <EAI6qhkG3_u9Z-KibwU6ZjO_rNtnqijo96l62h9U_0E=.d3fd82d3-21d8-475f-ab16-f4eefe012cb4@github.com>
Message-ID: <9Ext0hVGvNUgxJrg8aQUAK2tbhyCJbyTUCvuvD5ubD0=.0bbb6b9c-ea39-476b-addf-e88200d9a280@github.com>

On Wed, 4 Aug 2021 00:16:41 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this patch that adds `@requires vm.flagless` to `runtime/CompressedOops/` tests as they ignore external VM flags in the JVMs which perform actual testing actions?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 9e769090
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9e769090a020d58f2488dd77fb0681aa2d3856db
Stats:     8 lines in 5 files changed: 5 ins; 0 del; 3 mod

8271824: mark hotspot runtime/CompressedOops tests which ignore external VM flags

Reviewed-by: dholmes

-------------

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Wed Aug  4 05:28:27 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Wed, 4 Aug 2021 05:28:27 GMT
Subject: RFR: 8264543: Cross modify fence optimization for x86 [v6]
In-Reply-To: <hKxHKqPaT3F-xDUFx-2VCjzgbvL__8zJhLHpyQRrExQ=.2de18359-ee56-46a1-890e-4ca641081584@github.com>
References: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
 <ncdx-m6-zW2tKZS0atEBKVncHgMlb4YCTCxpISnN71I=.10e7d1e1-d134-4ce2-b7eb-6da2e12af495@github.com>
 <hKxHKqPaT3F-xDUFx-2VCjzgbvL__8zJhLHpyQRrExQ=.2de18359-ee56-46a1-890e-4ca641081584@github.com>
Message-ID: <SglsMPK_Kb0P_CzU1N2Gjd-ZI8F_e0Pepy9n85P73Cs=.a52d9393-ef49-4e33-9df0-037fbb61e49b@github.com>

On Tue, 3 Aug 2021 04:04:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo and change to require _MSC_VER >= 1928 to be safe
>
> Our testing passed with the additional patch.

Hi @dholmes-ora
could you sponsor this PR?
Thanks!

-------------

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

From github.com+58006833+xbzhang99 at openjdk.java.net  Wed Aug  4 05:48:36 2021
From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang)
Date: Wed, 4 Aug 2021 05:48:36 GMT
Subject: Integrated: 8264543: Cross modify fence optimization for x86
In-Reply-To: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
References: <l8JEImIBeMYea5AShZafqN0ARv9xXpZrI6mKrWipqcI=.8bb02e38-2bf0-4de3-b716-7f790ce6688f@github.com>
Message-ID: <pVhz9n3Pnb-9q-nOTBnKEWPXlYc70cau1wNhpUZM3xA=.258c628a-083e-48e9-a840-cfd5cd66906f@github.com>

On Tue, 20 Jul 2021 23:44:58 GMT, Xubo Zhang <github.com+58006833+xbzhang99 at openjdk.org> wrote:

> Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms.
> 
> The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H.
> 
> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

This pull request has now been integrated.

Changeset: 04134fcd
Author:    Xubo Zhang <xubo.zhang at intel.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/04134fcdaaf058429fc4ab109a98005ddce4636d
Stats:     73 lines in 9 files changed: 49 ins; 12 del; 12 mod

8264543: Cross modify fence optimization for x86

Reviewed-by: dholmes, tschatzl, sviswanathan

-------------

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

From dholmes at openjdk.java.net  Wed Aug  4 06:27:45 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 4 Aug 2021 06:27:45 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely
Message-ID: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>

Please review this fix to shutdown cleanly any JVMs created by gtests that aren't aborted.

Testing:
  - manual instrumentation to check all JVM construction and then deletion during gtest runs
  - local gtest testing
  - tiers 1-3 gtest testing

Thanks,
David

-------------

Commit messages:
 - update copyright year
 - 8263567: gtests don't terminate the VM safely

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

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

From stuefe at openjdk.java.net  Wed Aug  4 07:22:30 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 4 Aug 2021 07:22:30 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely
In-Reply-To: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
Message-ID: <hsJ4RD_YAeceTTumehuukQaJBjS8MybpzbHrFa2ls3c=.aa58fd62-c6c6-47cf-832b-1707dd04efac@github.com>

On Wed, 4 Aug 2021 05:55:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this fix to shutdown cleanly any JVMs created by gtests that aren't aborted.
> 
> Testing:
>   - manual instrumentation to check all JVM construction and then deletion during gtest runs
>   - local gtest testing
>   - tiers 1-3 gtest testing
> 
> Thanks,
> David

Hi David,

looks good, small remarks inline and one general remark here:

I wonder whether we should not just always initialize the VM at launch and destroy it after finish, regardless of the tests we run. We even could abolish TEST and just always do TEST_VM.

While in theory TEST (without _VM) is a good idea because we save time on the VM initialization, in practice
1) usually one just runs always the full suite, or a subset of it which includes TEST_VM tests, so most of the time we pay for VM init anyway.
2) tests are done using copy+paste and use TEST_VM unnecessarily. OTOH I also already had TEST tests that needed VM stuff. I mean that maintaining the correct designation for the tests is cumbersome and error-prone.
3) The _VM flexibility, tied to order and selection of tests, means the time VM initialization happens is unpredictable, which makes analysis more difficult and behavior sometimes surprising.

We could simplify all this and the runner code by just unconditionally initializing the VM at start of the gtestlauncher. I think the benefits of differentiating between TEST and TEST_VM are slim in practice.

..Thomas

test/hotspot/gtest/gtestMain.cpp line 113:

> 111:   char** _argv;
> 112:   bool _is_initialized;
> 113:   JavaVM* jvm;

underscore missing?

test/hotspot/gtest/gtestMain.cpp line 127:

> 125:     if (!_is_initialized && is_same_vm_test(name)) {
> 126:       // we want to have hs_err and core files when we execute regular tests
> 127:       int ret_val = init_jvm(_argc, _argv, false, &jvm);

init_jvm should just return the JavaVM pointer instead of a (rather boolean) int. The result int does not carry any information beyond "success". We can do the same with != NULL.

test/hotspot/gtest/gtestMain.cpp line 220:

> 218: 
> 219: // This is generally run once for a set of tests, but if we have vm_assert, or other_vm
> 220: // tests, a new process is forked and this will be called, for each of those tests.

is the comma needed?

test/hotspot/gtest/unittest.hpp line 99:

> 97:         fprintf(stderr, "Warning: DestroyJavaVM error %d\n", ret);  \
> 98:       }                                                             \
> 99:     }                                                               \

For better readibility I'd factor this out to an own function.

-------------

Changes requested by stuefe (Reviewer).

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

From stuefe at openjdk.java.net  Wed Aug  4 07:22:31 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 4 Aug 2021 07:22:31 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely
In-Reply-To: <hsJ4RD_YAeceTTumehuukQaJBjS8MybpzbHrFa2ls3c=.aa58fd62-c6c6-47cf-832b-1707dd04efac@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
 <hsJ4RD_YAeceTTumehuukQaJBjS8MybpzbHrFa2ls3c=.aa58fd62-c6c6-47cf-832b-1707dd04efac@github.com>
Message-ID: <wqf4MGARDf5pG-VrQ0SrfRWt6lz5MiR2YuNbFn02g-U=.4e85ac32-f23d-46df-9d3a-7fd86ca13945@github.com>

On Wed, 4 Aug 2021 07:01:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this fix to shutdown cleanly any JVMs created by gtests that aren't aborted.
>> 
>> Testing:
>>   - manual instrumentation to check all JVM construction and then deletion during gtest runs
>>   - local gtest testing
>>   - tiers 1-3 gtest testing
>> 
>> Thanks,
>> David
>
> test/hotspot/gtest/gtestMain.cpp line 113:
> 
>> 111:   char** _argv;
>> 112:   bool _is_initialized;
>> 113:   JavaVM* jvm;
> 
> underscore missing?

and `_is_initialized` is now redundant and could be aliased to `_jvm != NULL`

-------------

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

From cgo at openjdk.java.net  Wed Aug  4 07:34:27 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Wed, 4 Aug 2021 07:34:27 GMT
Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM
In-Reply-To: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
Message-ID: <iWgW1gg64vb7Gr1Cm1up-SNVO0wcNYcOsHt6lEw7Rc0=.ec2a33b3-ba7c-4c10-8bfc-d444442e00c9@github.com>

On Thu, 29 Jul 2021 09:40:08 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Hi,
> 
> please review this patch, which adds support for InlineIntrinsics to the 32-bit ARM port. The old aarch32 port had this intrinsic implemented and enabled by default.
> 
> Like on many other platforms, the 32-bit ARM port simply calls into the `SharedRuntime` to intrinsify the basic `java.lang.Math` methods. InlineIntrinsics is already implemented for C1 on 32-bit ARM, which does the same thing.
> 
> testing: hotspot tier1 on ARMv5TE (soft-float) and ARMv7-A (hard-float)
> 
> There is already the micro benchmark `test/micro/org/openjdk/bench/java/lang/MathBench.java` which I used. The soft-float benchmarks are not that meaningful, since I performed them in QEMU.
> 
> __hard-float__ `-Xint -XX:+InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 | 1169.574 | +/- 133.694 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  759.902 | +/- 573.852 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  854.753 | +/-  67.217 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  902.034 | +/-  22.413 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  895.470 | +/- 113.811 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  936.136 | +/-  40.661 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  864.670 | +/-  68.329 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 | 1082.589 | +/-  92.570 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  853.715 | +/- 122.427 | ops/ms |
> 
> __hard-float__ `-Xint -XX:-InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  450.907 | +/-  10.402 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  592.242 | +/-  14.011 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  167.614 | +/-   7.530 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  572.099 | +/-  55.089 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  596.588 | +/-  24.976 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  212.673 | +/-   4.060 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  584.873 | +/-  42.774 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  514.690 | +/-  30.568 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  566.586 | +/-  23.995 | ops/ms |
> 
> __soft-float__ `-Xint -XX:+InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  279.575 | +/-  56.455 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  137.005 | +/-  72.561 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  117.778 | +/-  30.186 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  107.957 | +/-  10.158 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  101.341 | +/-   3.914 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  222.220 | +/-   3.854 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  112.715 | +/-   9.088 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  119.341 | +/-  76.528 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  105.224 | +/-  30.477 | ops/ms |
> 
> __soft-float__ `-Xint -XX:-InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  173.150 | +/-  36.279 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  129.774 | +/-   8.795 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |   53.524 | +/-   1.679 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  132.503 | +/-   4.274 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  135.483 | +/-   1.150 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |   54.266 | +/-   0.699 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  105.636 | +/-   4.647 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  204.550 | +/-   7.206 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  101.072 | +/-   3.701 | ops/ms |

`jdk:tier1` tests on soft-float and hard-float are good. `IeeeRecommendedTests` on soft-float has some issues, but this is because I don't use an external soft float library, but the glibc implementation for floating point arithmetic, which doesn't have the required precision. Probably one should pick up [JDK-8215902](https://bugs.openjdk.java.net/browse/JDK-8215902) again and fix this situation.

-------------

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

From shade at openjdk.java.net  Wed Aug  4 07:57:28 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 4 Aug 2021 07:57:28 GMT
Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM
In-Reply-To: <iWgW1gg64vb7Gr1Cm1up-SNVO0wcNYcOsHt6lEw7Rc0=.ec2a33b3-ba7c-4c10-8bfc-d444442e00c9@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
 <iWgW1gg64vb7Gr1Cm1up-SNVO0wcNYcOsHt6lEw7Rc0=.ec2a33b3-ba7c-4c10-8bfc-d444442e00c9@github.com>
Message-ID: <3-ch8irZk1SYxlUBKyFRB34mAtHdBzLC66okTjyMxJ4=.5e1fa9c2-50eb-48b5-96e7-373272c84112@github.com>

On Wed, 4 Aug 2021 07:31:06 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> `jdk:tier1` tests on soft-float and hard-float are good. 

Thanks, we are good then.

> `IeeeRecommendedTests` on soft-float has some issues, but this is because I don't use an external soft float library, but the glibc implementation for floating point arithmetic, which doesn't have the required precision.

This is pre-existing, right? Meaning, it is not worse with this PR?

-------------

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

From shade at openjdk.java.net  Wed Aug  4 08:05:39 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 4 Aug 2021 08:05:39 GMT
Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM
In-Reply-To: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
Message-ID: <zmukkxdrc7rZeihvVdFqOMj0QjGDbpAX0ZfOSq3wDEg=.492330b1-ee01-4e7d-8a77-91f35966b12c@github.com>

On Thu, 29 Jul 2021 09:40:08 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Hi,
> 
> please review this patch, which adds support for InlineIntrinsics to the 32-bit ARM port. The old aarch32 port had this intrinsic implemented and enabled by default.
> 
> Like on many other platforms, the 32-bit ARM port simply calls into the `SharedRuntime` to intrinsify the basic `java.lang.Math` methods. InlineIntrinsics is already implemented for C1 on 32-bit ARM, which does the same thing.
> 
> testing: hotspot tier1 on ARMv5TE (soft-float) and ARMv7-A (hard-float)
> 
> There is already the micro benchmark `test/micro/org/openjdk/bench/java/lang/MathBench.java` which I used. The soft-float benchmarks are not that meaningful, since I performed them in QEMU.
> 
> __hard-float__ `-Xint -XX:+InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 | 1169.574 | +/- 133.694 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  759.902 | +/- 573.852 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  854.753 | +/-  67.217 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  902.034 | +/-  22.413 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  895.470 | +/- 113.811 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  936.136 | +/-  40.661 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  864.670 | +/-  68.329 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 | 1082.589 | +/-  92.570 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  853.715 | +/- 122.427 | ops/ms |
> 
> __hard-float__ `-Xint -XX:-InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  450.907 | +/-  10.402 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  592.242 | +/-  14.011 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  167.614 | +/-   7.530 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  572.099 | +/-  55.089 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  596.588 | +/-  24.976 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  212.673 | +/-   4.060 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  584.873 | +/-  42.774 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  514.690 | +/-  30.568 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  566.586 | +/-  23.995 | ops/ms |
> 
> __soft-float__ `-Xint -XX:+InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  279.575 | +/-  56.455 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  137.005 | +/-  72.561 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  117.778 | +/-  30.186 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  107.957 | +/-  10.158 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  101.341 | +/-   3.914 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  222.220 | +/-   3.854 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  112.715 | +/-   9.088 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  119.341 | +/-  76.528 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  105.224 | +/-  30.477 | ops/ms |
> 
> __soft-float__ `-Xint -XX:-InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  173.150 | +/-  36.279 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  129.774 | +/-   8.795 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |   53.524 | +/-   1.679 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  132.503 | +/-   4.274 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  135.483 | +/-   1.150 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |   54.266 | +/-   0.699 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  105.636 | +/-   4.647 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  204.550 | +/-   7.206 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  101.072 | +/-   3.701 | ops/ms |

Good to go then.

-------------

Marked as reviewed by shade (Reviewer).

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

From cgo at openjdk.java.net  Wed Aug  4 08:05:40 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Wed, 4 Aug 2021 08:05:40 GMT
Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM
In-Reply-To: <3-ch8irZk1SYxlUBKyFRB34mAtHdBzLC66okTjyMxJ4=.5e1fa9c2-50eb-48b5-96e7-373272c84112@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
 <iWgW1gg64vb7Gr1Cm1up-SNVO0wcNYcOsHt6lEw7Rc0=.ec2a33b3-ba7c-4c10-8bfc-d444442e00c9@github.com>
 <3-ch8irZk1SYxlUBKyFRB34mAtHdBzLC66okTjyMxJ4=.5e1fa9c2-50eb-48b5-96e7-373272c84112@github.com>
Message-ID: <9dKS2y4tn_OhYs11qFa1sADWE0EZU6VnqmgPdT5mB10=.2ba035fb-3cda-4875-8e9e-378698770b28@github.com>

On Wed, 4 Aug 2021 07:54:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > `IeeeRecommendedTests` on soft-float has some issues, but this is because I don't use an external soft float library, but the glibc implementation for floating point arithmetic, which doesn't have the required precision.
> 
> This is pre-existing, right? Meaning, it is not worse with this PR?

Yes, this PR doesn't change anything. The test case also uses the `Math` and `StrictMath` functions and the problem is identical for both implementations.

-------------

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

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: <kGatKckF7HugxwRcrbFmWhTghfNRbtx9NPr_tVGc40Q=.d8a00a0d-488b-48ec-85f7-c3f96d6fb88f@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <ulPAvEJaGZNdzM5a6DHy_lU4gaWWrN1c3iuYCc8pkm0=.091c5df6-d4c7-42f3-9f07-5fb12eec4099@github.com>
 <kGatKckF7HugxwRcrbFmWhTghfNRbtx9NPr_tVGc40Q=.d8a00a0d-488b-48ec-85f7-c3f96d6fb88f@github.com>
Message-ID: <e6B8wHqtv0G8BqvYw8SuALFfl8uHgewFWAJizDen1cc=.12146ead-5e10-453b-b30b-443190d783e0@github.com>

On Wed, 4 Aug 2021 03:36:11 GMT, Thomas Stuefe <stuefe at openjdk.org> 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: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
Message-ID: <23V2mAhhsYn7SXfOfL-8FRZY0UCIRutSli-Q8mizBUg=.410c3c0a-5526-42fe-88eb-ffae255159d4@github.com>

On Thu, 22 Jul 2021 14:58:47 GMT, Thomas Stuefe <stuefe at openjdk.org> 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=<file>`.
> - 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_<PID>=<NMT arguments>`. 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 <stuefe at openjdk.org>
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: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <rTeSwF9Asx2ubpKeNiWKyeQimGIueSI891YBrCxf6jQ=.67422d7a-6b38-40d3-ad93-2b333d2eb5f6@github.com>
 <iZ7WptYlKPCVRXDsu2SsMJhijMkM1DPWzcX9FYct69M=.62d2b846-bda5-47c8-a337-98f77b38e05b@github.com>
 <9fJF6K7k4Pn7Ktu4W9KgcjmekQv3wYfS1pWiA0SlntI=.177a2a19-0639-4a8b-8ed5-f5f3d4030713@github.com>
Message-ID: <cTaMs0Rbi3GSCn3cySLyRdt23UbaDN3KGhaO9eoAqDk=.f74d0143-563d-48b4-bc55-84673e56ff85@github.com>

On Mon, 2 Aug 2021 14:24:54 GMT, Coleen Phillimore <coleenp at openjdk.org> 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 chagedorn at openjdk.java.net  Wed Aug  4 13:11:28 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 4 Aug 2021 13:11:28 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail
In-Reply-To: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
Message-ID: <nfzFFbScl6-iIahJU1swihe8XjcRxjr5NS_VtQ61E8A=.049477a2-7453-42da-8fb2-e017e8c97403@github.com>

On Thu, 29 Jul 2021 12:25:27 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> A test VM used by the IR framework sometimes prints `` in the middle of emitting a `PrintIdeal` or `PrintOptoAssembly` output which could lead to IR matching failures:
> https://github.com/openjdk/jdk/blob/489e5fd12a37a45f4f5ea64b05f85c6f99f70811/src/hotspot/share/utilities/ostream.cpp#L918-L927
> 
> I thought about just bailing out of IR matching if this string is found after a failure but this issue also affects internal framework tests (I observed one case locally where this happened in the test `TestIRMatching`, letting it fail).
> 
> Handling `` makes things more complicated for the IR framework tests. I'm not sure about the value of printing this message in the first place. But if nobody objects, I suggest to either remove it or at least guard it with `Verbose`, for example. I went with the latter solution in this PR.
> 
> Thanks,
> Christian

I played around with it and interestingly this code path is hit quite often when just running `java -Xbatch -XX:+PrintIdeal -XX:+PrintOptoAssembly --version`.

I had a closer look at one of these occurrences. In this case, the reason we are executing `break_tty_lock_for_safepoint()` with a tty lock (i.e. at a safepoint while printing) was the following:
At some point, `SharedRuntime::handle_wrong_method_ic_miss` is called in thread X due to having cached the wrong method. This code then creates a new inline cache stub. In the meantime, the VM thread Y is waiting for a next VM operation in the loop. When the VM thread is calling `VMThread::setup_periodic_safepoint_if_needed()` it notices that a cleanup is needed (`SafepointSynchronize::is_cleanup_needed()` is true) due to the new IC stub. The cleanup operation is chosen as next VM operation. To execute this operation, it requires a safepoint. It sets the polling word of all threads, including the C2 compiler thread and `SafepointMechanism::local_poll_armed()` is now true. Unfortunately, the C2 compiler thread is currently printing with a tty lock acquired either at:
https://github.com/openjdk/jdk/blob/eec64f55870cf51746755d8fa59098a82109e826/src/hotspot/share/opto/output.cpp#L1870-L1871
or at
https://github.com/openjdk/jdk/blob/eec64f55870cf51746755d8fa59098a82109e826/src/hotspot/share/opto/compile.cpp#L789-L790
Therefore, we break the lock inside `ThreadInVMfromNative()` at the next print call in the C2 compiler thread because `SafepointMechanism::local_poll_armed()` is true.

To me this seems okay and not a problem but just bad luck due to timing.

-------------

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

From coleenp at openjdk.java.net  Wed Aug  4 18:01:00 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 4 Aug 2021 18:01:00 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError
Message-ID: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>

This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.

Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).

-------------

Commit messages:
 - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError
 - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError

Changes: https://git.openjdk.java.net/jdk/pull/4996/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4996&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8048190
  Stats: 459 lines in 11 files changed: 447 ins; 2 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4996.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4996/head:pull/4996

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

From coleenp at openjdk.java.net  Wed Aug  4 19:59:51 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 4 Aug 2021 19:59:51 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v2]
In-Reply-To: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
Message-ID: <rr4xTD3oiLP4N1P9pOHOXMFnz84exIpHO4F2DdoYBxA=.43d4439c-a6ac-4eb2-bf80-7c1e89cdde01@github.com>

> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
> 
> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).

Coleen Phillimore 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:

 - Merge branch 'master' into init-oom
 - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError
 - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4996/files
  - new: https://git.openjdk.java.net/jdk/pull/4996/files/b280826c..385dc78f

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

  Stats: 884 lines in 49 files changed: 440 ins; 272 del; 172 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4996.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4996/head:pull/4996

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

From mgkwill at openjdk.java.net  Wed Aug  4 20:19:40 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 4 Aug 2021 20:19:40 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86
Message-ID: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>

Intrinsic for Math.copySign is disabled on x86_64.

We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.

**### Math.copySign(double)**
_From:_
  0x00007f7d606e5dac:   vmovq  %xmm1,%r10
  0x00007f7d606e5db1:   vmovq  %xmm0,%r11
  0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
  0x00007f7d606e5dc0:   and    %r8,%r11
  0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
  0x00007f7d606e5dcd:   and    %r8,%r10
  0x00007f7d606e5dd0:   or     %r11,%r10
  0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   

_To:_
  0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
  0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
  0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0

**### Math.copySign(float)**
_From:_
  0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
  0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
  0x00007ff8886e60b6:   and    $0x80000000,%r11d
  0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
  0x00007ff8886e60c4:   or     %r10d,%r11d
  0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
_To:_
  0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
  0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
  0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0

_**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
**BEFORE**
Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op

**PATCH**
Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op

**JTREG that covers this case:**
test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java

Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Commit messages:
 - x86_64 copysign intrinsic

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

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

From mgkwill at openjdk.java.net  Wed Aug  4 21:42:47 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Wed, 4 Aug 2021 21:42:47 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v2]
In-Reply-To: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
Message-ID: <HepC1TEN3yHa8Nofh-NLCqQy2ZfW4dyz4KQDrTntzAY=.0d081927-ca83-4da2-afc6-a5d8777358ba@github.com>

> Intrinsic for Math.copySign is disabled on x86_64.
> 
> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
> 
> ### **Math.copySign(double)**
> _From:_
>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>   0x00007f7d606e5dc0:   and    %r8,%r11
>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>   0x00007f7d606e5dcd:   and    %r8,%r10
>   0x00007f7d606e5dd0:   or     %r11,%r10
>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
> 
> _To:_
>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
> 
> ### **Math.copySign(float)**
> _From:_
>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>   0x00007ff8886e60c4:   or     %r10d,%r11d
>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
> _To:_
>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
> 
> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
> #### **BEFORE**
> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
> 
> #### **PATCH**
> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
> 
> #### **JTREG that covers this case:**
> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
> 
> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:

  Update x86.ad with #ifdef _LP64 for copySign

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5005/files
  - new: https://git.openjdk.java.net/jdk/pull/5005/files/724410ae..68eb2bc4

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

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

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

From dholmes at openjdk.java.net  Thu Aug  5 05:17:32 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 5 Aug 2021 05:17:32 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v2]
In-Reply-To: <rr4xTD3oiLP4N1P9pOHOXMFnz84exIpHO4F2DdoYBxA=.43d4439c-a6ac-4eb2-bf80-7c1e89cdde01@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <rr4xTD3oiLP4N1P9pOHOXMFnz84exIpHO4F2DdoYBxA=.43d4439c-a6ac-4eb2-bf80-7c1e89cdde01@github.com>
Message-ID: <iDNnQdUalEL-NB7j0G99_6D0oAtUXSFrkSEtFjk-ZuY=.3fd94841-9452-4ae3-a7b0-fdf0d770b458@github.com>

On Wed, 4 Aug 2021 19:59:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
>> 
>> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).
>
> Coleen Phillimore 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:
> 
>  - Merge branch 'master' into init-oom
>  - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError
>  - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError

Hi Coleen,

This was not quite what I had envisaged but initially I thought this looked really neat. However on further thought I think there are a number of potential problems with trying to re-create the original type of exception. The "exception" type may not exist or is not known to the current loader, or the "exception" type does not follow convention and have a string-taking constructor. But also for user-defined exception types you have no idea what execution context might be assumed by the exception constructor logic, or what that logic may do. It may be completely wrong/bad to try and create an exception of that type from the current thread in the current context.

Further comments/suggestions below.

Thanks,
David

src/hotspot/share/classfile/javaClasses.cpp line 2671:

> 2669: 
> 2670: objArrayOop java_lang_Throwable::get_stack_trace(Handle throwable, TRAPS) {
> 2671:   // Call to JVM to fill in the stack trace and clear declaringObject to not keep classes alive

declaringClassObject

src/hotspot/share/classfile/javaClasses.cpp line 2677:

> 2675: 
> 2676:   TempNewSymbol sym = SymbolTable::new_symbol("getStackTrace");
> 2677:   TempNewSymbol sig = SymbolTable::new_symbol("()[Ljava/lang/StackTraceElement;");

Should we just add these to vmSymbols to go with the other StackTraceElement related symbols?

src/hotspot/share/classfile/javaClasses.cpp line 2696:

> 2694:     st.print("in thread %s", thread_name);
> 2695:   } else {
> 2696:     st.print("%s in thread %s", message->as_C_string(), thread_name);

I still think this needs highlighting/emphasizing some way eg.

[In thread "name"]

and the name should be in quotes.

src/hotspot/share/classfile/javaClasses.cpp line 2698:

> 2696:     st.print("%s in thread %s", message->as_C_string(), thread_name);
> 2697:   }
> 2698:   Handle h_cause = Exceptions::new_exception(THREAD, exception, st.as_string());

This can fail for many reasons, causing the returned exception to not be an instance of "exception" at all, but an exception that was thrown trying to create an instance of  "exception". If that happens we should just return NULL here.

src/hotspot/share/oops/instanceKlass.cpp line 1067:

> 1065:   MutexLocker ml(THREAD, ClassInitError_lock);
> 1066:   InitErrorElement elem(THREAD, exception, stack_trace);
> 1067:   _initialization_error_table.put_if_absent(this, elem, &created);

As there can only ever be one initialization error for a class, surely we should just be asserting that get(this) is NULL, and then use put(this,elem) rather than putIfAbsent ?

src/hotspot/share/oops/instanceKlass.cpp line 1076:

> 1074:   InitErrorElement* h;
> 1075:   {
> 1076:     MutexLocker ml(ClassInitError_lock);

Pass THREAD.

src/hotspot/share/oops/instanceKlass.cpp line 1081:

> 1079:   if (h != nullptr) {
> 1080:     return java_lang_Throwable::recreate_cause(h->exception(), h->message(), h->thread_name(),
> 1081:                                                Handle(THREAD, h->stack_trace()), CHECK_NULL);

We don't use CHECK macros on a return statement.

test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionTest.java line 27:

> 25:  * @test
> 26:  * @bug 8048190
> 27:  * @summary Test that the CNFE saves original exception during class initialization.

s/CNFE/NCDFE/

test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionTest.java line 28:

> 26:  * @bug 8048190
> 27:  * @summary Test that the CNFE saves original exception during class initialization.
> 28:  * @compile InitNPE.jasm InitOOM.jasm

You don't need jasm files for this but you do need to know a little trick to get around the javac compiler:

public class InitNPE {
  static {
    if (true) throw new NullPointerException();
  }
}

-------------

Changes requested by dholmes (Reviewer).

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

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: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
Message-ID: <vBb-_2EIKz1ov6TfV1NwuZ5vycaRBzCJpQdbRjIJkOc=.6f72aded-e598-4cef-be69-062bbd465010@github.com>

> 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 cgo at openjdk.java.net  Thu Aug  5 09:25:29 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Thu, 5 Aug 2021 09:25:29 GMT
Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM
In-Reply-To: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
Message-ID: <sNmGe8ScyFFppo8oo-INx6hTdzHqHbYSiJVjz2vSDfI=.e4e72fca-3723-4ec8-af20-2d9cc436f61e@github.com>

On Thu, 29 Jul 2021 09:40:08 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Hi,
> 
> please review this patch, which adds support for InlineIntrinsics to the 32-bit ARM port. The old aarch32 port had this intrinsic implemented and enabled by default.
> 
> Like on many other platforms, the 32-bit ARM port simply calls into the `SharedRuntime` to intrinsify the basic `java.lang.Math` methods. InlineIntrinsics is already implemented for C1 on 32-bit ARM, which does the same thing.
> 
> testing: hotspot tier1 on ARMv5TE (soft-float) and ARMv7-A (hard-float)
> 
> There is already the micro benchmark `test/micro/org/openjdk/bench/java/lang/MathBench.java` which I used. The soft-float benchmarks are not that meaningful, since I performed them in QEMU.
> 
> __hard-float__ `-Xint -XX:+InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 | 1169.574 | +/- 133.694 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  759.902 | +/- 573.852 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  854.753 | +/-  67.217 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  902.034 | +/-  22.413 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  895.470 | +/- 113.811 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  936.136 | +/-  40.661 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  864.670 | +/-  68.329 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 | 1082.589 | +/-  92.570 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  853.715 | +/- 122.427 | ops/ms |
> 
> __hard-float__ `-Xint -XX:-InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  450.907 | +/-  10.402 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  592.242 | +/-  14.011 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  167.614 | +/-   7.530 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  572.099 | +/-  55.089 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  596.588 | +/-  24.976 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  212.673 | +/-   4.060 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  584.873 | +/-  42.774 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  514.690 | +/-  30.568 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  566.586 | +/-  23.995 | ops/ms |
> 
> __soft-float__ `-Xint -XX:+InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  279.575 | +/-  56.455 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  137.005 | +/-  72.561 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  117.778 | +/-  30.186 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  107.957 | +/-  10.158 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  101.341 | +/-   3.914 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  222.220 | +/-   3.854 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  112.715 | +/-   9.088 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  119.341 | +/-  76.528 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  105.224 | +/-  30.477 | ops/ms |
> 
> __soft-float__ `-Xint -XX:-InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  173.150 | +/-  36.279 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  129.774 | +/-   8.795 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |   53.524 | +/-   1.679 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  132.503 | +/-   4.274 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  135.483 | +/-   1.150 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |   54.266 | +/-   0.699 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  105.636 | +/-   4.647 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  204.550 | +/-   7.206 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  101.072 | +/-   3.701 | ops/ms |

Thanks for the review Aleksey, very much appreciated.

-------------

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

From shade at openjdk.java.net  Thu Aug  5 09:39:29 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 5 Aug 2021 09:39:29 GMT
Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM
In-Reply-To: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
Message-ID: <rDgqSHQp88hht5ua6jH3a7cRi8q3zZ7Yz9t2Q6YrwLM=.700eac65-d79a-45d4-8d2b-51f4f0de1cdc@github.com>

On Thu, 29 Jul 2021 09:40:08 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Hi,
> 
> please review this patch, which adds support for InlineIntrinsics to the 32-bit ARM port. The old aarch32 port had this intrinsic implemented and enabled by default.
> 
> Like on many other platforms, the 32-bit ARM port simply calls into the `SharedRuntime` to intrinsify the basic `java.lang.Math` methods. InlineIntrinsics is already implemented for C1 on 32-bit ARM, which does the same thing.
> 
> testing: hotspot tier1 on ARMv5TE (soft-float) and ARMv7-A (hard-float)
> 
> There is already the micro benchmark `test/micro/org/openjdk/bench/java/lang/MathBench.java` which I used. The soft-float benchmarks are not that meaningful, since I performed them in QEMU.
> 
> __hard-float__ `-Xint -XX:+InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 | 1169.574 | +/- 133.694 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  759.902 | +/- 573.852 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  854.753 | +/-  67.217 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  902.034 | +/-  22.413 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  895.470 | +/- 113.811 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  936.136 | +/-  40.661 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  864.670 | +/-  68.329 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 | 1082.589 | +/-  92.570 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  853.715 | +/- 122.427 | ops/ms |
> 
> __hard-float__ `-Xint -XX:-InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  450.907 | +/-  10.402 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  592.242 | +/-  14.011 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  167.614 | +/-   7.530 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  572.099 | +/-  55.089 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  596.588 | +/-  24.976 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  212.673 | +/-   4.060 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  584.873 | +/-  42.774 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  514.690 | +/-  30.568 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  566.586 | +/-  23.995 | ops/ms |
> 
> __soft-float__ `-Xint -XX:+InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  279.575 | +/-  56.455 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  137.005 | +/-  72.561 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  117.778 | +/-  30.186 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  107.957 | +/-  10.158 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  101.341 | +/-   3.914 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  222.220 | +/-   3.854 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  112.715 | +/-   9.088 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  119.341 | +/-  76.528 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  105.224 | +/-  30.477 | ops/ms |
> 
> __soft-float__ `-Xint -XX:-InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  173.150 | +/-  36.279 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  129.774 | +/-   8.795 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |   53.524 | +/-   1.679 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  132.503 | +/-   4.274 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  135.483 | +/-   1.150 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |   54.266 | +/-   0.699 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  105.636 | +/-   4.647 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  204.550 | +/-   7.206 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  101.072 | +/-   3.701 | ops/ms |

Sorry for not catching this earlier, but I think `java_lang_math_abs` and `java_lang_math_sqrt` are not transcendental, so it is awkward to call `generate_transcendental_entry` for them? I think that's just a naming problem, maybe call it `generate_math_runtime_entry`? (If you fix this, maybe also pull from master to get clean GHA runs).

-------------

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

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: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
Message-ID: <fpCO3gUF8wIMpbApI2_r_59IKqYaMLvK3EswyU0skRc=.bc9fb87b-588e-439d-91de-701df1e51b61@github.com>

> 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 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: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <g4NiARIHx5BTgvq6uoi9LqqcJRkJT2NiK_-qMrrv-H0=.bbbf85f5-8da9-467a-b5e0-b47bc8b73172@github.com>
 <80NDhQE20WOO7LMCDS9C9zYQIRy-YKqNiGgrPQAPI64=.ef6e55d9-8995-4669-9c6f-e10a61bd427f@github.com>
 <wGe0vflu7uZ8O0WsAz2OdkpjtiyXLkafQF-w5x3n1gU=.57343745-db2f-42b9-b1cb-2694a741c7f6@github.com>
 <b3tc72GBp_aSCngNXWbJFncPyTJT3mF-NoSYPqAGGlw=.bf5d98c7-62e9-46f0-bbc4-6aeb86b77a3d@github.com>
 <v5HmhFytrDnyrexCubsJSA0AxT5_FfrWD2yoN_2uRlQ=.a13c4127-46d4-4a94-aeca-31a99549a2bf@github.com>
 <_CXJ5Lcpd7-PqzRzGAtEE4NyZzAGirYGSgVT7KbPyFw=.f2ce7164-7d28-4b6e-9a79-9417054e0113@github.com>
 <Cuddlk-XPnwxcvd6Y0kZs9jKh6IocZih1gA9njsDFD4=.7c6f04f1-fe9a-42cb-acae-489b76b712b4@github.com>
 <7iBHbVtU_eX1kulxCimscf3qRO213qaZ8fyK2-_aJGA=.c6c9e083-e098-409f-9b8f-685cab8ff977@github.com>
Message-ID: <oAYHQU5Uu_dtEUBd6X8JjKyXuWukAYdvY086PIn5OB8=.4f69b6cf-7a44-4c1b-b542-1d69e113a1f9@github.com>

On Mon, 2 Aug 2021 11:42:33 GMT, Severin Gehwolf <sgehwolf at openjdk.org> 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 rkennke at openjdk.java.net  Thu Aug  5 11:28:37 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 5 Aug 2021 11:28:37 GMT
Subject: RFR: 8271939: Clean up primitive raw accessors in oopDesc
Message-ID: <rPN6z0gQprVXkBVLa42lAJEI8QHTsAoGYHhF4mbUrDI=.c0d5479d-791f-49ff-9a0c-fab66f39b45c@github.com>

We have some _raw accessors in oop.hpp and related code. Those are leftover from when Shenandoah required primitive barriers and are no longer needed. Their uses can be replaced with the regular accessors.

Testing:
 - [x] tier1
 - [x] tier2
 - [x] hotspot_gc

-------------

Commit messages:
 - 8271939: Clean up primitive raw accessors in oopDesc

Changes: https://git.openjdk.java.net/jdk/pull/5017/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5017&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271939
  Stats: 37 lines in 8 files changed: 0 ins; 30 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5017.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5017/head:pull/5017

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

From cgo at openjdk.java.net  Thu Aug  5 12:30:56 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Thu, 5 Aug 2021 12:30:56 GMT
Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM [v2]
In-Reply-To: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
Message-ID: <3aytf74jse6MaVYeuhE8gKEV11D-CduoAwYaquK-074=.6ee7cce5-9d5c-461f-957b-dda1ec886ccc@github.com>

> Hi,
> 
> please review this patch, which adds support for InlineIntrinsics to the 32-bit ARM port. The old aarch32 port had this intrinsic implemented and enabled by default.
> 
> Like on many other platforms, the 32-bit ARM port simply calls into the `SharedRuntime` to intrinsify the basic `java.lang.Math` methods. InlineIntrinsics is already implemented for C1 on 32-bit ARM, which does the same thing.
> 
> testing: hotspot tier1 on ARMv5TE (soft-float) and ARMv7-A (hard-float)
> 
> There is already the micro benchmark `test/micro/org/openjdk/bench/java/lang/MathBench.java` which I used. The soft-float benchmarks are not that meaningful, since I performed them in QEMU.
> 
> __hard-float__ `-Xint -XX:+InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 | 1169.574 | +/- 133.694 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  759.902 | +/- 573.852 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  854.753 | +/-  67.217 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  902.034 | +/-  22.413 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  895.470 | +/- 113.811 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  936.136 | +/-  40.661 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  864.670 | +/-  68.329 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 | 1082.589 | +/-  92.570 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  853.715 | +/- 122.427 | ops/ms |
> 
> __hard-float__ `-Xint -XX:-InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  450.907 | +/-  10.402 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  592.242 | +/-  14.011 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  167.614 | +/-   7.530 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  572.099 | +/-  55.089 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  596.588 | +/-  24.976 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  212.673 | +/-   4.060 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  584.873 | +/-  42.774 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  514.690 | +/-  30.568 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  566.586 | +/-  23.995 | ops/ms |
> 
> __soft-float__ `-Xint -XX:+InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  279.575 | +/-  56.455 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  137.005 | +/-  72.561 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  117.778 | +/-  30.186 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  107.957 | +/-  10.158 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  101.341 | +/-   3.914 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  222.220 | +/-   3.854 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  112.715 | +/-   9.088 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  119.341 | +/-  76.528 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  105.224 | +/-  30.477 | ops/ms |
> 
> __soft-float__ `-Xint -XX:-InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  173.150 | +/-  36.279 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  129.774 | +/-   8.795 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |   53.524 | +/-   1.679 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  132.503 | +/-   4.274 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  135.483 | +/-   1.150 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |   54.266 | +/-   0.699 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  105.636 | +/-   4.647 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  204.550 | +/-   7.206 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  101.072 | +/-   3.701 | ops/ms |

Christoph G?ttschkes 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:

 - Rename generate_transcendental_entry -> generate_math_runtime_call
 - Merge branch 'master' into JDK-8271128-arm32-math-intrinsics
   
   * master: (97 commits)
     8270903: sun.net.httpserver.HttpConnection: Improve toString
     8271722: [TESTBUG] gc/g1/TestMixedGCLiveThreshold.java can fail if G1 Full GC uses >1 workers
     8270058: Use Objects.check{Index,FromIndexSize} for java.desktop
     4819544: SwingSet2 JTable Demo throws NullPointerException
     8271878: UnProblemList jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java in JDK18
     8271895: UnProblemList javax/swing/JComponent/7154030/bug7154030.java in JDK18
     8271863: ProblemList serviceability/sa/TestJmapCore.java on linux-x64 with ZGC
     8271898: disable os.release_multi_mappings_vm on macOS-X64
     8271893: mark hotspot runtime/PerfMemDestroy/PerfMemDestroy.java test as ignoring external VM flags
     8271887: mark hotspot runtime/CDSCompressedKPtrs tests which ignore external VM flags
     8271891: mark hotspot runtime/Safepoint tests which ignore external VM flags
     8271886: mark hotspot runtime/InvocationTests tests which ignore external VM flags
     8271890: mark hotspot runtime/Dictionary tests which ignore external VM flags
     8271894: ProblemList javax/swing/JComponent/7154030/bug7154030.java in JDK17
     8271888: build error after JDK-8271599
     8271456: Avoid looking up standard charsets in "java.desktop" module
     8271589: fatal error with variable shift count integer rotate operation.
     8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places
     8271877: ProblemList jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java in JDK17
     8271217: Fix race between G1PeriodicGCTask checks and GC request
     ...
 - 8271128: InlineIntrinsics support for 32-bit ARM

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4927/files
  - new: https://git.openjdk.java.net/jdk/pull/4927/files/d8926dfe..faadc2d5

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

  Stats: 37172 lines in 345 files changed: 33855 ins; 1917 del; 1400 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4927.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4927/head:pull/4927

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

From cgo at openjdk.java.net  Thu Aug  5 12:30:56 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Thu, 5 Aug 2021 12:30:56 GMT
Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM
In-Reply-To: <rDgqSHQp88hht5ua6jH3a7cRi8q3zZ7Yz9t2Q6YrwLM=.700eac65-d79a-45d4-8d2b-51f4f0de1cdc@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
 <rDgqSHQp88hht5ua6jH3a7cRi8q3zZ7Yz9t2Q6YrwLM=.700eac65-d79a-45d4-8d2b-51f4f0de1cdc@github.com>
Message-ID: <s1zeuKTQIrFbdLkxCWYBky_9XPZ1iJrWfMsmGMJsWwo=.ad96f1d5-0d50-4dfa-94d8-7ae963f01e28@github.com>

On Thu, 5 Aug 2021 09:36:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Sorry for not catching this earlier, but I think `java_lang_math_abs` and `java_lang_math_sqrt` are not transcendental, so it is awkward to call `generate_transcendental_entry` for them? I think that's just a naming problem, maybe call it `generate_math_runtime_entry`? (If you fix this, maybe also pull from master to get clean GHA runs).

I chose that name because of the aarch64 implementation, which uses the same name (but doesn't generate calls for neither `abs`, nor `sqrt`). I renamed it to `generate_math_runtime_call`, since it only generates the call to the runtime function.

-------------

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

From coleenp at openjdk.java.net  Thu Aug  5 13:08:37 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 5 Aug 2021 13:08:37 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v2]
In-Reply-To: <iDNnQdUalEL-NB7j0G99_6D0oAtUXSFrkSEtFjk-ZuY=.3fd94841-9452-4ae3-a7b0-fdf0d770b458@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <rr4xTD3oiLP4N1P9pOHOXMFnz84exIpHO4F2DdoYBxA=.43d4439c-a6ac-4eb2-bf80-7c1e89cdde01@github.com>
 <iDNnQdUalEL-NB7j0G99_6D0oAtUXSFrkSEtFjk-ZuY=.3fd94841-9452-4ae3-a7b0-fdf0d770b458@github.com>
Message-ID: <ggGUw-81ThvCX60CkGQ5DzFlG7wZv7g-qc6h9hwjUgM=.f6e7cf31-de00-4c1d-b3ac-50a4db1b0ef1@github.com>

On Thu, 5 Aug 2021 04:09:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore 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:
>> 
>>  - Merge branch 'master' into init-oom
>>  - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError
>>  - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError
>
> src/hotspot/share/classfile/javaClasses.cpp line 2671:
> 
>> 2669: 
>> 2670: objArrayOop java_lang_Throwable::get_stack_trace(Handle throwable, TRAPS) {
>> 2671:   // Call to JVM to fill in the stack trace and clear declaringObject to not keep classes alive
> 
> declaringClassObject

fixed.

> src/hotspot/share/classfile/javaClasses.cpp line 2677:
> 
>> 2675: 
>> 2676:   TempNewSymbol sym = SymbolTable::new_symbol("getStackTrace");
>> 2677:   TempNewSymbol sig = SymbolTable::new_symbol("()[Ljava/lang/StackTraceElement;");
> 
> Should we just add these to vmSymbols to go with the other StackTraceElement related symbols?

Yes, they should go there. I don't like the big global symbols file, but that's where they should go.

> src/hotspot/share/classfile/javaClasses.cpp line 2696:
> 
>> 2694:     st.print("in thread %s", thread_name);
>> 2695:   } else {
>> 2696:     st.print("%s in thread %s", message->as_C_string(), thread_name);
> 
> I still think this needs highlighting/emphasizing some way eg.
> 
> [In thread "name"]
> 
> and the name should be in quotes.

ok, yes, I agree.

> src/hotspot/share/classfile/javaClasses.cpp line 2698:
> 
>> 2696:     st.print("%s in thread %s", message->as_C_string(), thread_name);
>> 2697:   }
>> 2698:   Handle h_cause = Exceptions::new_exception(THREAD, exception, st.as_string());
> 
> This can fail for many reasons, causing the returned exception to not be an instance of "exception" at all, but an exception that was thrown trying to create an instance of  "exception". If that happens we should just return NULL here.

Yes, regarding your other comment about whether the original exception should be reloaded and reinitialized, and whether its initialization could be the cause of the original exception.  I'll try to find a creative solution here so that the most common cases are still supported because I think this would be a helpful feature most of the time.  If you have some ideas, let me know (either here or offline).  Thanks.

> src/hotspot/share/oops/instanceKlass.cpp line 1067:
> 
>> 1065:   MutexLocker ml(THREAD, ClassInitError_lock);
>> 1066:   InitErrorElement elem(THREAD, exception, stack_trace);
>> 1067:   _initialization_error_table.put_if_absent(this, elem, &created);
> 
> As there can only ever be one initialization error for a class, surely we should just be asserting that get(this) is NULL, and then use put(this,elem) rather than putIfAbsent ?

I was thinking about multi-threading but only one class initialization is happening at once.  It's already not concurrent. I need the lock for concurrent class unloading though.

> src/hotspot/share/oops/instanceKlass.cpp line 1076:
> 
>> 1074:   InitErrorElement* h;
>> 1075:   {
>> 1076:     MutexLocker ml(ClassInitError_lock);
> 
> Pass THREAD.

ok

> src/hotspot/share/oops/instanceKlass.cpp line 1081:
> 
>> 1079:   if (h != nullptr) {
>> 1080:     return java_lang_Throwable::recreate_cause(h->exception(), h->message(), h->thread_name(),
>> 1081:                                                Handle(THREAD, h->stack_trace()), CHECK_NULL);
> 
> We don't use CHECK macros on a return statement.

ok

> test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionTest.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8048190
>> 27:  * @summary Test that the CNFE saves original exception during class initialization.
> 
> s/CNFE/NCDFE/

fixed

> test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionTest.java line 28:
> 
>> 26:  * @bug 8048190
>> 27:  * @summary Test that the CNFE saves original exception during class initialization.
>> 28:  * @compile InitNPE.jasm InitOOM.jasm
> 
> You don't need jasm files for this but you do need to know a little trick to get around the javac compiler:
> 
> public class InitNPE {
>   static {
>     if (true) throw new NullPointerException();
>   }
> }

Oh wow, that's great.  I didn't think javac would fall for that.  Thanks!

-------------

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

From coleenp at openjdk.java.net  Thu Aug  5 13:08:32 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 5 Aug 2021 13:08:32 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v2]
In-Reply-To: <rr4xTD3oiLP4N1P9pOHOXMFnz84exIpHO4F2DdoYBxA=.43d4439c-a6ac-4eb2-bf80-7c1e89cdde01@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <rr4xTD3oiLP4N1P9pOHOXMFnz84exIpHO4F2DdoYBxA=.43d4439c-a6ac-4eb2-bf80-7c1e89cdde01@github.com>
Message-ID: <jArIUQ5j6daSqlEeywFNVke4nN2NMmWAkmDQicVe1eI=.428e3652-fefc-458c-a5c5-37e8ee7cecf5@github.com>

On Wed, 4 Aug 2021 19:59:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
>> 
>> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).
>
> Coleen Phillimore 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:
> 
>  - Merge branch 'master' into init-oom
>  - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError
>  - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError

David, thank you for all the comments.

-------------

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

From coleenp at openjdk.java.net  Thu Aug  5 13:17:00 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 5 Aug 2021 13:17:00 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v3]
In-Reply-To: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
Message-ID: <IjrNVUh-ugqA1wZjkbcxj2eOlP7HRWvk7-a4X0gA0kg=.0ef28a9a-5b38-442c-bebe-f7caa9ca8a78@github.com>

> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
> 
> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).

Coleen Phillimore 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 init-oom
 - David review comments.
 - Merge branch 'master' into init-oom
 - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError
 - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4996/files
  - new: https://git.openjdk.java.net/jdk/pull/4996/files/385dc78f..a8723bab

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

  Stats: 230 lines in 21 files changed: 45 ins; 147 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4996.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4996/head:pull/4996

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

From coleenp at openjdk.java.net  Thu Aug  5 13:17:04 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 5 Aug 2021 13:17:04 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v2]
In-Reply-To: <ggGUw-81ThvCX60CkGQ5DzFlG7wZv7g-qc6h9hwjUgM=.f6e7cf31-de00-4c1d-b3ac-50a4db1b0ef1@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <rr4xTD3oiLP4N1P9pOHOXMFnz84exIpHO4F2DdoYBxA=.43d4439c-a6ac-4eb2-bf80-7c1e89cdde01@github.com>
 <iDNnQdUalEL-NB7j0G99_6D0oAtUXSFrkSEtFjk-ZuY=.3fd94841-9452-4ae3-a7b0-fdf0d770b458@github.com>
 <ggGUw-81ThvCX60CkGQ5DzFlG7wZv7g-qc6h9hwjUgM=.f6e7cf31-de00-4c1d-b3ac-50a4db1b0ef1@github.com>
Message-ID: <mnzMWu9vmF7A6FAnsr-O39sA-cfXkUda-jj425NDX7Y=.bd8b91f4-923a-4391-804e-6c7bde9652d3@github.com>

On Thu, 5 Aug 2021 13:05:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 2698:
>> 
>>> 2696:     st.print("%s in thread %s", message->as_C_string(), thread_name);
>>> 2697:   }
>>> 2698:   Handle h_cause = Exceptions::new_exception(THREAD, exception, st.as_string());
>> 
>> This can fail for many reasons, causing the returned exception to not be an instance of "exception" at all, but an exception that was thrown trying to create an instance of  "exception". If that happens we should just return NULL here.
>
> Yes, regarding your other comment about whether the original exception should be reloaded and reinitialized, and whether its initialization could be the cause of the original exception.  I'll try to find a creative solution here so that the most common cases are still supported because I think this would be a helpful feature most of the time.  If you have some ideas, let me know (either here or offline).  Thanks.

I wonder if I can use a predefined exception like ExceptionInInitializerError and put the original exception in with the message?

-------------

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

From github.com+42899633+eastig at openjdk.java.net  Thu Aug  5 13:56:28 2021
From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich)
Date: Thu, 5 Aug 2021 13:56:28 GMT
Subject: RFR: 8271939: Clean up primitive raw accessors in oopDesc
In-Reply-To: <rPN6z0gQprVXkBVLa42lAJEI8QHTsAoGYHhF4mbUrDI=.c0d5479d-791f-49ff-9a0c-fab66f39b45c@github.com>
References: <rPN6z0gQprVXkBVLa42lAJEI8QHTsAoGYHhF4mbUrDI=.c0d5479d-791f-49ff-9a0c-fab66f39b45c@github.com>
Message-ID: <G7wXp-SDr5TV-pDy2AbjYT3yJq2kHVWAiSUwpgNgaMU=.4217e670-7dd7-4b84-8af3-fe1480e96eef@github.com>

On Thu, 5 Aug 2021 11:20:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We have some _raw accessors in oop.hpp and related code. Those are leftover from when Shenandoah required primitive barriers and are no longer needed. Their uses can be replaced with the regular accessors.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [x] hotspot_gc

LGTM

-------------

Marked as reviewed by eastig at github.com (no known OpenJDK username).

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

From github.com+4146708+a74nh at openjdk.java.net  Thu Aug  5 14:21:39 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Thu, 5 Aug 2021 14:21:39 GMT
Subject: RFR: 8271869: AArch64: build errors with GCC11 in
 frame::saved_oop_result
Message-ID: <-H4Ipq5xE61C6-xDj1vD-_gdEZYQdIeXcAMl0ASu5Rs=.2378487e-0c95-4bf8-a6ee-671dfaef1c00@github.com>

GCC11 warns that r0 is null. It does not complain if r1 is used instead.

AIUI, it is undefined behaviour in C++ to call member functions without
a valid this pointer. So, technically GCC is correct to warn.

-------------

Commit messages:
 - 8271869: AArch64: build errors with GCC11 in frame::saved_oop_result

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

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

From aph-open at littlepinkcloud.com  Thu Aug  5 14:40:44 2021
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Thu, 5 Aug 2021 15:40:44 +0100
Subject: RFR: 8271869: AArch64: build errors with GCC11 in
 frame::saved_oop_result
In-Reply-To: <-H4Ipq5xE61C6-xDj1vD-_gdEZYQdIeXcAMl0ASu5Rs=.2378487e-0c95-4bf8-a6ee-671dfaef1c00@github.com>
References: <-H4Ipq5xE61C6-xDj1vD-_gdEZYQdIeXcAMl0ASu5Rs=.2378487e-0c95-4bf8-a6ee-671dfaef1c00@github.com>
Message-ID: <42e037d5-496c-aa76-17e7-4904b1946257@littlepinkcloud.com>

On 8/5/21 3:21 PM, Alan Hayward wrote:
> GCC11 warns that r0 is null. It does not complain if r1 is used instead.
> 
> AIUI, it is undefined behaviour in C++ to call member functions without
> a valid this pointer. So, technically GCC is correct to warn.

Correct. I have a prototype patch to fix this, but the same undefined
behaviour recurs several times in the code base, not just Assembler.
I think we should fix it properly, but there is some small size  and
space penalty for making the Registers etc valid pointers.

I will approve this now if you really need it, but I wonder if
this should be the spur to actually fixing the bug, not disabling
the warning.

Andrew.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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: <oAYHQU5Uu_dtEUBd6X8JjKyXuWukAYdvY086PIn5OB8=.4f69b6cf-7a44-4c1b-b542-1d69e113a1f9@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <g4NiARIHx5BTgvq6uoi9LqqcJRkJT2NiK_-qMrrv-H0=.bbbf85f5-8da9-467a-b5e0-b47bc8b73172@github.com>
 <80NDhQE20WOO7LMCDS9C9zYQIRy-YKqNiGgrPQAPI64=.ef6e55d9-8995-4669-9c6f-e10a61bd427f@github.com>
 <wGe0vflu7uZ8O0WsAz2OdkpjtiyXLkafQF-w5x3n1gU=.57343745-db2f-42b9-b1cb-2694a741c7f6@github.com>
 <b3tc72GBp_aSCngNXWbJFncPyTJT3mF-NoSYPqAGGlw=.bf5d98c7-62e9-46f0-bbc4-6aeb86b77a3d@github.com>
 <v5HmhFytrDnyrexCubsJSA0AxT5_FfrWD2yoN_2uRlQ=.a13c4127-46d4-4a94-aeca-31a99549a2bf@github.com>
 <_CXJ5Lcpd7-PqzRzGAtEE4NyZzAGirYGSgVT7KbPyFw=.f2ce7164-7d28-4b6e-9a79-9417054e0113@github.com>
 <Cuddlk-XPnwxcvd6Y0kZs9jKh6IocZih1gA9njsDFD4=.7c6f04f1-fe9a-42cb-acae-489b76b712b4@github.com>
 <7iBHbVtU_eX1kulxCimscf3qRO213qaZ8fyK2-_aJGA=.c6c9e083-e098-409f-9b8f-685cab8ff977@github.com>
 <oAYHQU5Uu_dtEUBd6X8JjKyXuWukAYdvY086PIn5OB8=.4f69b6cf-7a44-4c1b-b542-1d69e113a1f9@github.com>
Message-ID: <lQ1hyjlmGnhoURXfyvCU7E5XQgK_8BilsvPN9W4zGLk=.9c6819d8-1b8c-4f57-8878-8edb0579cf91@github.com>

On Thu, 5 Aug 2021 11:19:17 GMT, Matthias Baesken <mbaesken at openjdk.org> 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 shade at openjdk.java.net  Thu Aug  5 15:55:27 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 5 Aug 2021 15:55:27 GMT
Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM
In-Reply-To: <s1zeuKTQIrFbdLkxCWYBky_9XPZ1iJrWfMsmGMJsWwo=.ad96f1d5-0d50-4dfa-94d8-7ae963f01e28@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
 <rDgqSHQp88hht5ua6jH3a7cRi8q3zZ7Yz9t2Q6YrwLM=.700eac65-d79a-45d4-8d2b-51f4f0de1cdc@github.com>
 <s1zeuKTQIrFbdLkxCWYBky_9XPZ1iJrWfMsmGMJsWwo=.ad96f1d5-0d50-4dfa-94d8-7ae963f01e28@github.com>
Message-ID: <6Yq9KRNi0CwdCKREEl2sVEtim6eB9wYerVScH3Keh9U=.ba33ee83-f969-4a69-80f6-a83e4d38d61d@github.com>

On Thu, 5 Aug 2021 12:27:20 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> > Sorry for not catching this earlier, but I think `java_lang_math_abs` and `java_lang_math_sqrt` are not transcendental, so it is awkward to call `generate_transcendental_entry` for them? I think that's just a naming problem, maybe call it `generate_math_runtime_entry`? (If you fix this, maybe also pull from master to get clean GHA runs).
> 
> I chose that name because of the aarch64 implementation, which uses the same name (but doesn't generate calls for neither `abs`, nor `sqrt`). I renamed it to `generate_math_runtime_call`, since it only generates the call to the runtime function.

Thanks, that looks better. `transcendental_entry` local variable too?

-------------

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

From shade at openjdk.java.net  Thu Aug  5 16:11:34 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 5 Aug 2021 16:11:34 GMT
Subject: RFR: 8271939: Clean up primitive raw accessors in oopDesc
In-Reply-To: <rPN6z0gQprVXkBVLa42lAJEI8QHTsAoGYHhF4mbUrDI=.c0d5479d-791f-49ff-9a0c-fab66f39b45c@github.com>
References: <rPN6z0gQprVXkBVLa42lAJEI8QHTsAoGYHhF4mbUrDI=.c0d5479d-791f-49ff-9a0c-fab66f39b45c@github.com>
Message-ID: <5By8v2haGJrhX-3_K3CB7rBxdXaSdsPFpe94WRaS8hM=.415e79a7-8751-45cf-b106-8320ce3aded0@github.com>

On Thu, 5 Aug 2021 11:20:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We have some _raw accessors in oop.hpp and related code. Those are leftover from when Shenandoah required primitive barriers and are no longer needed. Their uses can be replaced with the regular accessors.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [x] hotspot_gc

Looking at the [RFE](http://hg.openjdk.java.net/jdk/jdk/rev/7c3891b9f1e0) that introduced these, I think `loader_data_raw` is also the candidate for removal?

-------------

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

From coleenp at openjdk.java.net  Thu Aug  5 18:30:32 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 5 Aug 2021 18:30:32 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v2]
In-Reply-To: <mnzMWu9vmF7A6FAnsr-O39sA-cfXkUda-jj425NDX7Y=.bd8b91f4-923a-4391-804e-6c7bde9652d3@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <rr4xTD3oiLP4N1P9pOHOXMFnz84exIpHO4F2DdoYBxA=.43d4439c-a6ac-4eb2-bf80-7c1e89cdde01@github.com>
 <iDNnQdUalEL-NB7j0G99_6D0oAtUXSFrkSEtFjk-ZuY=.3fd94841-9452-4ae3-a7b0-fdf0d770b458@github.com>
 <ggGUw-81ThvCX60CkGQ5DzFlG7wZv7g-qc6h9hwjUgM=.f6e7cf31-de00-4c1d-b3ac-50a4db1b0ef1@github.com>
 <mnzMWu9vmF7A6FAnsr-O39sA-cfXkUda-jj425NDX7Y=.bd8b91f4-923a-4391-804e-6c7bde9652d3@github.com>
Message-ID: <w9neoSFLowBKocUguLIkoM9pIMpkJd9NC60rme04iC0=.75c7669d-7ee7-4532-b58a-eaaddbbd161c@github.com>

On Thu, 5 Aug 2021 13:10:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yes, regarding your other comment about whether the original exception should be reloaded and reinitialized, and whether its initialization could be the cause of the original exception.  I'll try to find a creative solution here so that the most common cases are still supported because I think this would be a helpful feature most of the time.  If you have some ideas, let me know (either here or offline).  Thanks.
>
> I wonder if I can use a predefined exception like ExceptionInInitializerError and put the original exception in with the message?

You're right.  new_exception does surprising things.  If it gets an exception during the call, it returns a handle to that exception, which is not what I want at all.  I'll return null in that case.

-------------

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

From sviswanathan at openjdk.java.net  Fri Aug  6 01:32:36 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 6 Aug 2021 01:32:36 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v2]
In-Reply-To: <HepC1TEN3yHa8Nofh-NLCqQy2ZfW4dyz4KQDrTntzAY=.0d081927-ca83-4da2-afc6-a5d8777358ba@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
 <HepC1TEN3yHa8Nofh-NLCqQy2ZfW4dyz4KQDrTntzAY=.0d081927-ca83-4da2-afc6-a5d8777358ba@github.com>
Message-ID: <soyN3-x0c-Gy0WiY8OZbngDS2pcfAG4lY0y32RE1ZpI=.27e61d2d-afb6-498b-bfe4-b3f76052145e@github.com>

On Wed, 4 Aug 2021 21:42:47 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Intrinsic for Math.copySign is disabled on x86_64.
>> 
>> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
>> 
>> ### **Math.copySign(double)**
>> _From:_
>>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>>   0x00007f7d606e5dc0:   and    %r8,%r11
>>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>>   0x00007f7d606e5dcd:   and    %r8,%r10
>>   0x00007f7d606e5dd0:   or     %r11,%r10
>>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
>> 
>> _To:_
>>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
>> 
>> ### **Math.copySign(float)**
>> _From:_
>>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>>   0x00007ff8886e60c4:   or     %r10d,%r11d
>>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
>> _To:_
>>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
>> 
>> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
>> #### **BEFORE**
>> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
>> 
>> #### **PATCH**
>> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
>> 
>> #### **JTREG that covers this case:**
>> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
>> 
>> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update x86.ad with #ifdef _LP64 for copySign

src/hotspot/cpu/x86/x86.ad line 1692:

> 1690:         return false;
> 1691:       }
> 1692:       break;

This should be part of match_rule_supported() method and not match_rule_supported_vector().
Also should return false for non LP_64.

src/hotspot/cpu/x86/x86.ad line 5810:

> 5808: 
> 5809: #ifdef _LP64
> 5810: instruct copySignF_reg(regF dst, regF src, regF tmp1, rRegL tmp2) %{

rRegL tmp2 should be rRegI tmp2 for copySignF.

src/hotspot/cpu/x86/x86.ad line 5814:

> 5812:   match(Set dst (CopySignF dst src));
> 5813:   effect(TEMP tmp1, TEMP tmp2);
> 5814:   format %{ "CopySignF $dst, $src" %}

Please add the tmp registers to the format, something like below:
format %{ "CopySignF $dst, $src\t! using $tmp1 and $tmp2 as TEMP" %}

src/hotspot/cpu/x86/x86.ad line 5828:

> 5826:   ins_cost(125);
> 5827:   effect(TEMP tmp1, TEMP tmp2);
> 5828:   format %{ "CopySignD $dst, $src" %}

Please add the tmp1 and tmp2 registers to the format.

src/hotspot/cpu/x86/x86.ad line 5842:

> 5840:   ins_cost(100);
> 5841:   effect(TEMP tmp1, TEMP tmp2);
> 5842:   format %{ "CopySignD $dst, $src" %}

Please add the tmp1 and tmp2 registers to the format.

-------------

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

From dholmes at openjdk.java.net  Fri Aug  6 04:15:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 Aug 2021 04:15:29 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v2]
In-Reply-To: <w9neoSFLowBKocUguLIkoM9pIMpkJd9NC60rme04iC0=.75c7669d-7ee7-4532-b58a-eaaddbbd161c@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <rr4xTD3oiLP4N1P9pOHOXMFnz84exIpHO4F2DdoYBxA=.43d4439c-a6ac-4eb2-bf80-7c1e89cdde01@github.com>
 <iDNnQdUalEL-NB7j0G99_6D0oAtUXSFrkSEtFjk-ZuY=.3fd94841-9452-4ae3-a7b0-fdf0d770b458@github.com>
 <ggGUw-81ThvCX60CkGQ5DzFlG7wZv7g-qc6h9hwjUgM=.f6e7cf31-de00-4c1d-b3ac-50a4db1b0ef1@github.com>
 <mnzMWu9vmF7A6FAnsr-O39sA-cfXkUda-jj425NDX7Y=.bd8b91f4-923a-4391-804e-6c7bde9652d3@github.com>
 <w9neoSFLowBKocUguLIkoM9pIMpkJd9NC60rme04iC0=.75c7669d-7ee7-4532-b58a-eaaddbbd161c@github.com>
Message-ID: <Gb2fhxQPqK2FLjUUPihssdglm0SlB30atk0T7westZA=.ce573905-ade0-423d-b564-56dad56ba675@github.com>

On Thu, 5 Aug 2021 17:39:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I wonder if I can use a predefined exception like ExceptionInInitializerError and put the original exception in with the message?
>
> You're right.  new_exception does surprising things.  If it gets an exception during the call, it returns a handle to that exception, which is not what I want at all.  I'll return null in that case.

I have to wonder whether `new_exceptions`'s behaviour is what anyone would want! It could lead to some very strange exceptions being thrown - see for example `ConstantPool::throw_resolution_error` where it can throw a resolution error with the wrong cause!

It may be okay to restrict re-creation of the exception to types in java.base as their construction seems benign with no context dependency and they should always have the necessary constructor.

Using ExceptionInInitializerError as the cause of the NCDFE may be okay for other cases.

-------------

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

From dholmes at openjdk.java.net  Fri Aug  6 04:22:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 Aug 2021 04:22:30 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely
In-Reply-To: <wqf4MGARDf5pG-VrQ0SrfRWt6lz5MiR2YuNbFn02g-U=.4e85ac32-f23d-46df-9d3a-7fd86ca13945@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
 <hsJ4RD_YAeceTTumehuukQaJBjS8MybpzbHrFa2ls3c=.aa58fd62-c6c6-47cf-832b-1707dd04efac@github.com>
 <wqf4MGARDf5pG-VrQ0SrfRWt6lz5MiR2YuNbFn02g-U=.4e85ac32-f23d-46df-9d3a-7fd86ca13945@github.com>
Message-ID: <4T1wXCynbQSTJPL1ojUrwMbgR_zUgiroCj8cOk0Ixqg=.7300b774-ccff-4bc6-95ee-206554dfd934@github.com>

On Wed, 4 Aug 2021 07:02:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> test/hotspot/gtest/gtestMain.cpp line 113:
>> 
>>> 111:   char** _argv;
>>> 112:   bool _is_initialized;
>>> 113:   JavaVM* jvm;
>> 
>> underscore missing?
>
> and `_is_initialized` is now redundant and could be aliased to `_jvm != NULL`

Yes good point - fixed.

-------------

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

From dholmes at openjdk.java.net  Fri Aug  6 04:22:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 Aug 2021 04:22:29 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely
In-Reply-To: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
Message-ID: <lwRF0uJrfXC8s7IU_N6QUYOjSHN6AML1ILAM1zuDNIU=.5ad6c92e-692c-4621-a34a-a1e1a9b77977@github.com>

On Wed, 4 Aug 2021 05:55:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this fix to shutdown cleanly any JVMs created by gtests that aren't aborted.
> 
> Testing:
>   - manual instrumentation to check all JVM construction and then deletion during gtest runs
>   - local gtest testing
>   - tiers 1-3 gtest testing
> 
> Thanks,
> David

Hi Thomas,

On 4/08/2021 5:22 pm, Thomas Stuefe wrote:
> On Wed, 4 Aug 2021 05:55:11 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Please review this fix to shutdown cleanly any JVMs created by gtests that aren't aborted.
>>
>> Testing:
>>    - manual instrumentation to check all JVM construction and then deletion during gtest runs
>>    - local gtest testing
>>    - tiers 1-3 gtest testing
>>
>> Thanks,
>> David
> 
> Hi David,
> 
> looks good, small remarks inline and one general remark here:
Thanks for taking a look at this. Sorry for the delayed follow-up. 
> I wonder whether we should not just always initialize the VM at launch and destroy it after finish, regardless of the tests we run. We even could abolish TEST and just always do TEST_VM.
> 
> While in theory TEST (without _VM) is a good idea because we save time on the VM initialization, in practice
> 1) usually one just runs always the full suite, or a subset of it which includes TEST_VM tests, so most of the time we pay for VM init anyway.
> 2) tests are done using copy+paste and use TEST_VM unnecessarily. OTOH I also already had TEST tests that needed VM stuff. I mean that maintaining the correct designation for the tests is cumbersome and error-prone.
> 3) The _VM flexibility, tied to order and selection of tests, means the time VM initialization happens is unpredictable, which makes analysis more difficult and behavior sometimes surprising.
> 
> We could simplify all this and the runner code by just unconditionally initializing the VM at start of the gtestlauncher. I think the benefits of differentiating between TEST and TEST_VM are slim in practice.

That may be true but I don't think it is for this issue/PR to try and address that. I can imagine that some basic TEST() cases assume a pristine environment with no chance of any external perturbation (such as by an initialized and thus operating VM). That said with the way tests get interleaved depending on exactly how you run them, it isn't clear that a TEST() may not run when the VM is already initialized anyway!

Thanks,
David

-------------

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

From dholmes at openjdk.java.net  Fri Aug  6 04:29:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 Aug 2021 04:29:30 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely
In-Reply-To: <hsJ4RD_YAeceTTumehuukQaJBjS8MybpzbHrFa2ls3c=.aa58fd62-c6c6-47cf-832b-1707dd04efac@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
 <hsJ4RD_YAeceTTumehuukQaJBjS8MybpzbHrFa2ls3c=.aa58fd62-c6c6-47cf-832b-1707dd04efac@github.com>
Message-ID: <dmrFVwl0kG4ebC6enw-OG9IGq0Uccwk9nEipS5Vqv9I=.8738576e-3d99-4bfc-b3a0-2feed8dd9fae@github.com>

On Wed, 4 Aug 2021 07:04:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this fix to shutdown cleanly any JVMs created by gtests that aren't aborted.
>> 
>> Testing:
>>   - manual instrumentation to check all JVM construction and then deletion during gtest runs
>>   - local gtest testing
>>   - tiers 1-3 gtest testing
>> 
>> Thanks,
>> David
>
> test/hotspot/gtest/gtestMain.cpp line 127:
> 
>> 125:     if (!_is_initialized && is_same_vm_test(name)) {
>> 126:       // we want to have hs_err and core files when we execute regular tests
>> 127:       int ret_val = init_jvm(_argc, _argv, false, &jvm);
> 
> init_jvm should just return the JavaVM pointer instead of a (rather boolean) int. The result int does not carry any information beyond "success". We can do the same with != NULL.

I think the right thing to do is to report the JNI error that gets returned.

-------------

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

From dholmes at openjdk.java.net  Fri Aug  6 04:37:31 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 Aug 2021 04:37:31 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely
In-Reply-To: <hsJ4RD_YAeceTTumehuukQaJBjS8MybpzbHrFa2ls3c=.aa58fd62-c6c6-47cf-832b-1707dd04efac@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
 <hsJ4RD_YAeceTTumehuukQaJBjS8MybpzbHrFa2ls3c=.aa58fd62-c6c6-47cf-832b-1707dd04efac@github.com>
Message-ID: <tsYuZm14zDuNftPLtHPs5BltGZmYwFtGCHNkIrVgcFE=.66a4195e-0640-4dc6-a253-4b14a1c60002@github.com>

On Wed, 4 Aug 2021 07:05:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this fix to shutdown cleanly any JVMs created by gtests that aren't aborted.
>> 
>> Testing:
>>   - manual instrumentation to check all JVM construction and then deletion during gtest runs
>>   - local gtest testing
>>   - tiers 1-3 gtest testing
>> 
>> Thanks,
>> David
>
> test/hotspot/gtest/gtestMain.cpp line 220:
> 
>> 218: 
>> 219: // This is generally run once for a set of tests, but if we have vm_assert, or other_vm
>> 220: // tests, a new process is forked and this will be called, for each of those tests.
> 
> is the comma needed?

Which one? :) I wanted to convey that the fork and execution of `runUnitTestsInner` is done for each test. I will reword and restructure.

-------------

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

From dholmes at openjdk.java.net  Fri Aug  6 04:43:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 Aug 2021 04:43:30 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely
In-Reply-To: <hsJ4RD_YAeceTTumehuukQaJBjS8MybpzbHrFa2ls3c=.aa58fd62-c6c6-47cf-832b-1707dd04efac@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
 <hsJ4RD_YAeceTTumehuukQaJBjS8MybpzbHrFa2ls3c=.aa58fd62-c6c6-47cf-832b-1707dd04efac@github.com>
Message-ID: <nmxZuQiIEQoJ3MP27aLLoLGMkd2_d4W0UQgEbjaEzEU=.3bd07c1a-30ef-44d1-899e-c6e05906b008@github.com>

On Wed, 4 Aug 2021 07:13:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this fix to shutdown cleanly any JVMs created by gtests that aren't aborted.
>> 
>> Testing:
>>   - manual instrumentation to check all JVM construction and then deletion during gtest runs
>>   - local gtest testing
>>   - tiers 1-3 gtest testing
>> 
>> Thanks,
>> David
>
> test/hotspot/gtest/unittest.hpp line 99:
> 
>> 97:         fprintf(stderr, "Warning: DestroyJavaVM error %d\n", ret);  \
>> 98:       }                                                             \
>> 99:     }                                                               \
> 
> For better readibility I'd factor this out to an own function.

The problem is I don't have anywhere to put that function so that this macro can invoke it.

-------------

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

From dholmes at openjdk.java.net  Fri Aug  6 04:49:36 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 Aug 2021 04:49:36 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely
In-Reply-To: <nmxZuQiIEQoJ3MP27aLLoLGMkd2_d4W0UQgEbjaEzEU=.3bd07c1a-30ef-44d1-899e-c6e05906b008@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
 <hsJ4RD_YAeceTTumehuukQaJBjS8MybpzbHrFa2ls3c=.aa58fd62-c6c6-47cf-832b-1707dd04efac@github.com>
 <nmxZuQiIEQoJ3MP27aLLoLGMkd2_d4W0UQgEbjaEzEU=.3bd07c1a-30ef-44d1-899e-c6e05906b008@github.com>
Message-ID: <gDYDea58SUR65bikmEP42eYYV69FjJKGa7smgY8yCvY=.51a3bea1-a7cc-4c8f-9910-3476b8260b38@github.com>

On Fri, 6 Aug 2021 04:40:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/hotspot/gtest/unittest.hpp line 99:
>> 
>>> 97:         fprintf(stderr, "Warning: DestroyJavaVM error %d\n", ret);  \
>>> 98:       }                                                             \
>>> 99:     }                                                               \
>> 
>> For better readibility I'd factor this out to an own function.
>
> The problem is I don't have anywhere to put that function so that this macro can invoke it.

To be more clear this is a .hpp file included by many .cpp files. If I put the function in the .hpp file and a specific .cpp file does not use the TEST_OTHER_VM macro then we have a function defined but not used and so hit `-Werror=unused-function`.
Is there some .cpp file I can put this in that would be globally accessible to all the test .cpp files?

-------------

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

From dholmes at openjdk.java.net  Fri Aug  6 04:54:53 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 Aug 2021 04:54:53 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely [v2]
In-Reply-To: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
Message-ID: <Btm45ddF_kyLTXgppB8hKSy_GQUbL7oVaqw6ShZPRU4=.cf7a6184-f528-4d0c-b68f-e5fc125bbc72@github.com>

> Please review this fix to shutdown cleanly any JVMs created by gtests that aren't aborted.
> 
> Testing:
>   - manual instrumentation to check all JVM construction and then deletion during gtest runs
>   - local gtest testing
>   - tiers 1-3 gtest testing
> 
> Thanks,
> David

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

  Addressed comments from @tstuefe

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4986/files
  - new: https://git.openjdk.java.net/jdk/pull/4986/files/ae5dc8f0..f9a3bd80

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

  Stats: 21 lines in 1 file changed: 6 ins; 5 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4986.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4986/head:pull/4986

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

From stuefe at openjdk.java.net  Fri Aug  6 05:08:29 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 6 Aug 2021 05:08:29 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely [v2]
In-Reply-To: <tsYuZm14zDuNftPLtHPs5BltGZmYwFtGCHNkIrVgcFE=.66a4195e-0640-4dc6-a253-4b14a1c60002@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
 <hsJ4RD_YAeceTTumehuukQaJBjS8MybpzbHrFa2ls3c=.aa58fd62-c6c6-47cf-832b-1707dd04efac@github.com>
 <tsYuZm14zDuNftPLtHPs5BltGZmYwFtGCHNkIrVgcFE=.66a4195e-0640-4dc6-a253-4b14a1c60002@github.com>
Message-ID: <H5lntvCX-GAC0fbIiqLOZ1YjHTQ1ckLeyT7RzrrSMo4=.9dd39397-f217-416f-bc42-f7d0e249e666@github.com>

On Fri, 6 Aug 2021 04:34:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/hotspot/gtest/gtestMain.cpp line 220:
>> 
>>> 218: 
>>> 219: // This is generally run once for a set of tests, but if we have vm_assert, or other_vm
>>> 220: // tests, a new process is forked and this will be called, for each of those tests.
>> 
>> is the comma needed?
>
> Which one? :) I wanted to convey that the fork and execution of `runUnitTestsInner` is done for each test. I will reword and restructure.

The second one after "called" tickled my comma sense. But I am not a native speaker and may be wrong.

-------------

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

From stuefe at openjdk.java.net  Fri Aug  6 05:11:30 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 6 Aug 2021 05:11:30 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely [v2]
In-Reply-To: <Btm45ddF_kyLTXgppB8hKSy_GQUbL7oVaqw6ShZPRU4=.cf7a6184-f528-4d0c-b68f-e5fc125bbc72@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
 <Btm45ddF_kyLTXgppB8hKSy_GQUbL7oVaqw6ShZPRU4=.cf7a6184-f528-4d0c-b68f-e5fc125bbc72@github.com>
Message-ID: <dgKFJqND4sZzuDeexkKlLPPscxlatV4tSGv0lrtZDJQ=.60aa2b19-931b-4a74-948f-a5ac29346b02@github.com>

On Fri, 6 Aug 2021 04:54:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this fix to shutdown cleanly any JVMs created by gtests that aren't aborted.
>> 
>> Testing:
>>   - manual instrumentation to check all JVM construction and then deletion during gtest runs
>>   - local gtest testing
>>   - tiers 1-3 gtest testing
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed comments from @tstuefe

All good now. The fact that other_vm re-runs VM initialization tripped me off more than once btw :)

test/hotspot/gtest/gtestMain.cpp line 121:

> 119:   virtual void OnTestStart(const ::testing::TestInfo& test_info) {
> 120:     const char* name = test_info.name();
> 121:     if ( _jvm == nullptr && is_same_vm_test(name)) {

superfluous blank? (after first open bracket)

-------------

Marked as reviewed by stuefe (Reviewer).

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

From jbhateja at openjdk.java.net  Fri Aug  6 05:20:37 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 6 Aug 2021 05:20:37 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v2]
In-Reply-To: <HepC1TEN3yHa8Nofh-NLCqQy2ZfW4dyz4KQDrTntzAY=.0d081927-ca83-4da2-afc6-a5d8777358ba@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
 <HepC1TEN3yHa8Nofh-NLCqQy2ZfW4dyz4KQDrTntzAY=.0d081927-ca83-4da2-afc6-a5d8777358ba@github.com>
Message-ID: <l_3nQnsO42l06iZ775AwjN6bZqGorQ5o2OaaSwdrxh8=.3b6a23a3-a48c-4d36-a928-62db6ccbd95f@github.com>

On Wed, 4 Aug 2021 21:42:47 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Intrinsic for Math.copySign is disabled on x86_64.
>> 
>> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
>> 
>> ### **Math.copySign(double)**
>> _From:_
>>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>>   0x00007f7d606e5dc0:   and    %r8,%r11
>>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>>   0x00007f7d606e5dcd:   and    %r8,%r10
>>   0x00007f7d606e5dd0:   or     %r11,%r10
>>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
>> 
>> _To:_
>>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
>> 
>> ### **Math.copySign(float)**
>> _From:_
>>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>>   0x00007ff8886e60c4:   or     %r10d,%r11d
>>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
>> _To:_
>>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
>> 
>> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
>> #### **BEFORE**
>> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
>> 
>> #### **PATCH**
>> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
>> 
>> #### **JTREG that covers this case:**
>> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
>> 
>> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update x86.ad with #ifdef _LP64 for copySign

src/hotspot/cpu/x86/x86.ad line 5811:

> 5809: #ifdef _LP64
> 5810: instruct copySignF_reg(regF dst, regF src, regF tmp1, rRegL tmp2) %{
> 5811:   predicate(UseAVX >= 3 && VM_Version::supports_avx512vl());

Please remove redundant predication check from all new patterns since they are already checked in match_rule_supported.

src/hotspot/cpu/x86/x86.ad line 5846:

> 5844:     __ mov64($tmp2$$Register, 0x7FFFFFFFFFFFFFFF);
> 5845:     __ vmovq($tmp1$$XMMRegister, $tmp2$$Register);
> 5846:     __ vpternlogq($dst$$XMMRegister, 0xE4, $src$$XMMRegister, $tmp1$$XMMRegister, Assembler::AVX_128bit);

No harm in adding a comment describing logic expression encoded by E4.

-------------

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

From dholmes at openjdk.java.net  Fri Aug  6 05:22:51 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 Aug 2021 05:22:51 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely [v3]
In-Reply-To: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
Message-ID: <OqVdBBg5ponJncrQ2O-w_Uqsl77LoDNkNIWqTe2Uv8o=.eb99d722-d179-4e72-a825-b7133b5207c4@github.com>

> Please review this fix to shutdown cleanly any JVMs created by gtests that aren't aborted.
> 
> Testing:
>   - manual instrumentation to check all JVM construction and then deletion during gtest runs
>   - local gtest testing
>   - tiers 1-3 gtest testing
> 
> Thanks,
> David

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

  Fixed superfluous blank

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4986/files
  - new: https://git.openjdk.java.net/jdk/pull/4986/files/f9a3bd80..09bee9b6

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

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

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

From dholmes at openjdk.java.net  Fri Aug  6 05:22:52 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 Aug 2021 05:22:52 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely [v2]
In-Reply-To: <dgKFJqND4sZzuDeexkKlLPPscxlatV4tSGv0lrtZDJQ=.60aa2b19-931b-4a74-948f-a5ac29346b02@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
 <Btm45ddF_kyLTXgppB8hKSy_GQUbL7oVaqw6ShZPRU4=.cf7a6184-f528-4d0c-b68f-e5fc125bbc72@github.com>
 <dgKFJqND4sZzuDeexkKlLPPscxlatV4tSGv0lrtZDJQ=.60aa2b19-931b-4a74-948f-a5ac29346b02@github.com>
Message-ID: <_DBoxmVRjXcGnOweAhl1WJd4i4gWM0FWHFd0X2hEbdE=.aae2eaaf-356a-49e8-a11c-f1c1f43e02f7@github.com>

On Fri, 6 Aug 2021 05:07:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed comments from @tstuefe
>
> test/hotspot/gtest/gtestMain.cpp line 121:
> 
>> 119:   virtual void OnTestStart(const ::testing::TestInfo& test_info) {
>> 120:     const char* name = test_info.name();
>> 121:     if ( _jvm == nullptr && is_same_vm_test(name)) {
> 
> superfluous blank? (after first open bracket)

Fixed. Thanks

-------------

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

From dholmes at openjdk.java.net  Fri Aug  6 06:06:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 Aug 2021 06:06:30 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail
In-Reply-To: <nfzFFbScl6-iIahJU1swihe8XjcRxjr5NS_VtQ61E8A=.049477a2-7453-42da-8fb2-e017e8c97403@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
 <nfzFFbScl6-iIahJU1swihe8XjcRxjr5NS_VtQ61E8A=.049477a2-7453-42da-8fb2-e017e8c97403@github.com>
Message-ID: <xb935hI5n5346d2A8L0pHzG0CGTZfFsJF-ayKGefF-4=.5a94d907-c0de-4a28-b76c-6e012767cc88@github.com>

On Wed, 4 Aug 2021 13:08:13 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> A test VM used by the IR framework sometimes prints `` in the middle of emitting a `PrintIdeal` or `PrintOptoAssembly` output which could lead to IR matching failures:
>> https://github.com/openjdk/jdk/blob/489e5fd12a37a45f4f5ea64b05f85c6f99f70811/src/hotspot/share/utilities/ostream.cpp#L918-L927
>> 
>> I thought about just bailing out of IR matching if this string is found after a failure but this issue also affects internal framework tests (I observed one case locally where this happened in the test `TestIRMatching`, letting it fail).
>> 
>> Handling `` makes things more complicated for the IR framework tests. I'm not sure about the value of printing this message in the first place. But if nobody objects, I suggest to either remove it or at least guard it with `Verbose`, for example. I went with the latter solution in this PR.
>> 
>> Thanks,
>> Christian
>
> I played around with it and interestingly this code path is hit quite often when just running `java -Xbatch -XX:+PrintIdeal -XX:+PrintOptoAssembly --version`.
> 
> I had a closer look at one of these occurrences. In this case, the reason we are executing `break_tty_lock_for_safepoint()` with a tty lock (i.e. at a safepoint while printing) was the following:
> At some point, `SharedRuntime::handle_wrong_method_ic_miss` is called in thread X due to having cached the wrong method. This code then creates a new inline cache stub. In the meantime, the VM thread Y is waiting for a next VM operation in the loop. When the VM thread is calling `VMThread::setup_periodic_safepoint_if_needed()` it notices that a cleanup is needed (`SafepointSynchronize::is_cleanup_needed()` is true) due to the new IC stub. The cleanup operation is chosen as next VM operation. To execute this operation, it requires a safepoint. It sets the polling word of all threads, including the C2 compiler thread and `SafepointMechanism::local_poll_armed()` is now true. Unfortunately, the C2 compiler thread is currently printing with a tty lock acquired either at:
> https://github.com/openjdk/jdk/blob/eec64f55870cf51746755d8fa59098a82109e826/src/hotspot/share/opto/output.cpp#L1870-L1871
> or at
> https://github.com/openjdk/jdk/blob/eec64f55870cf51746755d8fa59098a82109e826/src/hotspot/share/opto/compile.cpp#L789-L790
> Therefore, we break the lock inside `ThreadInVMfromNative()` at the next print call in the C2 compiler thread because `SafepointMechanism::local_poll_armed()` is true.
> 
> To me this seems okay and not a problem but just bad luck due to timing.

Thanks @chhagedorn . I can see that this message is somewhat expected in this context. Is it really that difficult to ignore in the IR matching? This is XML-ouput and it is formatted as a comment, so shouldn't the matching logic ignore XML comments?

-------------

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

From dnsimon at openjdk.java.net  Fri Aug  6 07:36:35 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Fri, 6 Aug 2021 07:36:35 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v3]
In-Reply-To: <IjrNVUh-ugqA1wZjkbcxj2eOlP7HRWvk7-a4X0gA0kg=.0ef28a9a-5b38-442c-bebe-f7caa9ca8a78@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <IjrNVUh-ugqA1wZjkbcxj2eOlP7HRWvk7-a4X0gA0kg=.0ef28a9a-5b38-442c-bebe-f7caa9ca8a78@github.com>
Message-ID: <VqqKk7Ywbj0sUCabExPi-nCAG8cIVvQq9eHM0ZIttcw=.52adcc18-f916-4125-bfb9-e45463eca65d@github.com>

On Thu, 5 Aug 2021 13:17:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
>> 
>> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).
>
> Coleen Phillimore 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 init-oom
>  - David review comments.
>  - Merge branch 'master' into init-oom
>  - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError
>  - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError

src/hotspot/share/oops/instanceKlass.cpp line 1054:

> 1052: 
> 1053: ResizeableResourceHashtable<const InstanceKlass*, InitErrorElement, ResourceObj::C_HEAP, mtClass>
> 1054:       _initialization_error_table(20);

As I understand, the whole point of this table is to save space. Instead, you could repurpose `T[] Class.enumConstants` to be `Object Class.enumConstantsOrInitError`. For a non-enum classes, this field is never used (and thus already "wasted") and for enum classes it will never be successfully initialized if there's a clinit error.

-------------

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

From jbhateja at openjdk.java.net  Fri Aug  6 07:44:29 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 6 Aug 2021 07:44:29 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v2]
In-Reply-To: <HepC1TEN3yHa8Nofh-NLCqQy2ZfW4dyz4KQDrTntzAY=.0d081927-ca83-4da2-afc6-a5d8777358ba@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
 <HepC1TEN3yHa8Nofh-NLCqQy2ZfW4dyz4KQDrTntzAY=.0d081927-ca83-4da2-afc6-a5d8777358ba@github.com>
Message-ID: <eJqLsngP64rIKEOZrLFZlvMqy05HbEoQX1pK3cSZ7Pk=.d10b90a4-12fb-4089-a930-8d81012237ca@github.com>

On Wed, 4 Aug 2021 21:42:47 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Intrinsic for Math.copySign is disabled on x86_64.
>> 
>> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
>> 
>> ### **Math.copySign(double)**
>> _From:_
>>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>>   0x00007f7d606e5dc0:   and    %r8,%r11
>>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>>   0x00007f7d606e5dcd:   and    %r8,%r10
>>   0x00007f7d606e5dd0:   or     %r11,%r10
>>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
>> 
>> _To:_
>>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
>> 
>> ### **Math.copySign(float)**
>> _From:_
>>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>>   0x00007ff8886e60c4:   or     %r10d,%r11d
>>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
>> _To:_
>>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
>> 
>> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
>> #### **BEFORE**
>> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
>> 
>> #### **PATCH**
>> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
>> 
>> #### **JTREG that covers this case:**
>> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
>> 
>> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update x86.ad with #ifdef _LP64 for copySign

src/hotspot/cpu/x86/x86.ad line 5823:

> 5821: %}
> 5822: 
> 5823: instruct copySignD_reg(regD dst, regD src, regD tmp1, rRegL tmp2, regD zero) %{

Graph shape created for this will always pass zero operand as an immediate argument. Do you see any issue if you just keep one pattern (copySignD_imm) ?

-------------

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

From chagedorn at openjdk.java.net  Fri Aug  6 08:03:29 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 6 Aug 2021 08:03:29 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail
In-Reply-To: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
Message-ID: <OcR7pnnjFsrFMxaJZ8L6VJbWz4pvPYHfur2aqE4GFmI=.5a902d47-f7fc-4442-bb2f-2a7232310274@github.com>

On Thu, 29 Jul 2021 12:25:27 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> A test VM used by the IR framework sometimes prints `` in the middle of emitting a `PrintIdeal` or `PrintOptoAssembly` output which could lead to IR matching failures:
> https://github.com/openjdk/jdk/blob/489e5fd12a37a45f4f5ea64b05f85c6f99f70811/src/hotspot/share/utilities/ostream.cpp#L918-L927
> 
> I thought about just bailing out of IR matching if this string is found after a failure but this issue also affects internal framework tests (I observed one case locally where this happened in the test `TestIRMatching`, letting it fail).
> 
> Handling `` makes things more complicated for the IR framework tests. I'm not sure about the value of printing this message in the first place. But if nobody objects, I suggest to either remove it or at least guard it with `Verbose`, for example. I went with the latter solution in this PR.
> 
> Thanks,
> Christian

I can think of a few options:
1. Keep matching code but if we catch an `IRViolationException` we additionally check if this tty message was found on the matched output. If that is the case, we bail out without an exception:
  - +: Easy and works well for normal user written IR tests. We only need to do this tty if there is actually an IR failure being reported. I'd say that it is unlikely that an IR test is written and is not executed a single time successfully without a bailout before integrating it.
  - -: Does not work well with framework internal tests which sometimes expect an exception (to check a few things on it) and sometimes not. Each test somehow needs to check if there was a bailout to reliably work. I guess it is okay to just ignore it for the "no exception expected" cases. We would catch possible errors in the framework the next time. For the "exception expected" tests, it's a little more difficult. The most simple thing to do is probably to just repeat a single test or a group of tests in an internal test file.
2. Change the regex matching code to ignore the tty message:
  - +: No changes to internal tests.
  - -: Given that it occurs very rarely, it has quite an overhead.
3. Strip a tty message when reading the `PrintIdeal`/`PrintOptoAssembly` entries from the log file when setting up the output to be parsed:
  - +: No changes to internal tests.
  - -: Given that it occurs very rarely, it has some overhead but probably less than the second option. We are reading each line anyways (I'm not actually parsing XML).

In terms of performance, it is probably best to bail out and do a one time effort to make the internal framework tests aware of this bailout scenario (option 1). While thinking about it for a second time, it might not be that complicated as I thought before. My original idea was just to first propose a removal of this tty message before going into fixing this rare case. But of course, given that there are concerns, I'm considering one of these options (my favorite is option 1).

-------------

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

From cgo at openjdk.java.net  Fri Aug  6 08:07:54 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Fri, 6 Aug 2021 08:07:54 GMT
Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM
In-Reply-To: <6Yq9KRNi0CwdCKREEl2sVEtim6eB9wYerVScH3Keh9U=.ba33ee83-f969-4a69-80f6-a83e4d38d61d@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
 <rDgqSHQp88hht5ua6jH3a7cRi8q3zZ7Yz9t2Q6YrwLM=.700eac65-d79a-45d4-8d2b-51f4f0de1cdc@github.com>
 <s1zeuKTQIrFbdLkxCWYBky_9XPZ1iJrWfMsmGMJsWwo=.ad96f1d5-0d50-4dfa-94d8-7ae963f01e28@github.com>
 <6Yq9KRNi0CwdCKREEl2sVEtim6eB9wYerVScH3Keh9U=.ba33ee83-f969-4a69-80f6-a83e4d38d61d@github.com>
Message-ID: <VCysjVCpKKtUHETfd0kC1WoKqUWHFsQpHOVViCp3mOg=.9e760437-f083-4c5a-96f0-5f61931d57b4@github.com>

On Thu, 5 Aug 2021 15:52:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Thanks, that looks better. `transcendental_entry` local variable too?

Sorry, should have seen this myself.
Done.

-------------

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

From cgo at openjdk.java.net  Fri Aug  6 08:07:54 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Fri, 6 Aug 2021 08:07:54 GMT
Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM [v3]
In-Reply-To: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
Message-ID: <tmmFC4C2e21MK6VWnQHwm7VHKNX5R33d8ERJy_swFFE=.ca6100e4-604b-4f8d-b5fa-f190d8ba9e16@github.com>

> Hi,
> 
> please review this patch, which adds support for InlineIntrinsics to the 32-bit ARM port. The old aarch32 port had this intrinsic implemented and enabled by default.
> 
> Like on many other platforms, the 32-bit ARM port simply calls into the `SharedRuntime` to intrinsify the basic `java.lang.Math` methods. InlineIntrinsics is already implemented for C1 on 32-bit ARM, which does the same thing.
> 
> testing: hotspot tier1 on ARMv5TE (soft-float) and ARMv7-A (hard-float)
> 
> There is already the micro benchmark `test/micro/org/openjdk/bench/java/lang/MathBench.java` which I used. The soft-float benchmarks are not that meaningful, since I performed them in QEMU.
> 
> __hard-float__ `-Xint -XX:+InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 | 1169.574 | +/- 133.694 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  759.902 | +/- 573.852 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  854.753 | +/-  67.217 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  902.034 | +/-  22.413 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  895.470 | +/- 113.811 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  936.136 | +/-  40.661 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  864.670 | +/-  68.329 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 | 1082.589 | +/-  92.570 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  853.715 | +/- 122.427 | ops/ms |
> 
> __hard-float__ `-Xint -XX:-InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  450.907 | +/-  10.402 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  592.242 | +/-  14.011 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  167.614 | +/-   7.530 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  572.099 | +/-  55.089 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  596.588 | +/-  24.976 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  212.673 | +/-   4.060 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  584.873 | +/-  42.774 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  514.690 | +/-  30.568 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  566.586 | +/-  23.995 | ops/ms |
> 
> __soft-float__ `-Xint -XX:+InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  279.575 | +/-  56.455 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  137.005 | +/-  72.561 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  117.778 | +/-  30.186 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  107.957 | +/-  10.158 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  101.341 | +/-   3.914 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  222.220 | +/-   3.854 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  112.715 | +/-   9.088 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  119.341 | +/-  76.528 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  105.224 | +/-  30.477 | ops/ms |
> 
> __soft-float__ `-Xint -XX:-InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  173.150 | +/-  36.279 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  129.774 | +/-   8.795 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |   53.524 | +/-   1.679 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  132.503 | +/-   4.274 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  135.483 | +/-   1.150 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |   54.266 | +/-   0.699 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  105.636 | +/-   4.647 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  204.550 | +/-   7.206 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  101.072 | +/-   3.701 | ops/ms |

Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:

  Rename transcendental_entry -> use_runtime_function

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4927/files
  - new: https://git.openjdk.java.net/jdk/pull/4927/files/faadc2d5..3c20c980

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

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

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

From shade at openjdk.java.net  Fri Aug  6 08:15:31 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 6 Aug 2021 08:15:31 GMT
Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM [v3]
In-Reply-To: <tmmFC4C2e21MK6VWnQHwm7VHKNX5R33d8ERJy_swFFE=.ca6100e4-604b-4f8d-b5fa-f190d8ba9e16@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
 <tmmFC4C2e21MK6VWnQHwm7VHKNX5R33d8ERJy_swFFE=.ca6100e4-604b-4f8d-b5fa-f190d8ba9e16@github.com>
Message-ID: <kepFr97W7WUKOsraX3Mic7V_hqod2e6ZZcF-Fq0grOE=.75ed2bcd-faf1-4ffe-8755-502c2b205637@github.com>

On Fri, 6 Aug 2021 08:07:54 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

>> Hi,
>> 
>> please review this patch, which adds support for InlineIntrinsics to the 32-bit ARM port. The old aarch32 port had this intrinsic implemented and enabled by default.
>> 
>> Like on many other platforms, the 32-bit ARM port simply calls into the `SharedRuntime` to intrinsify the basic `java.lang.Math` methods. InlineIntrinsics is already implemented for C1 on 32-bit ARM, which does the same thing.
>> 
>> testing: hotspot tier1 on ARMv5TE (soft-float) and ARMv7-A (hard-float)
>> 
>> There is already the micro benchmark `test/micro/org/openjdk/bench/java/lang/MathBench.java` which I used. The soft-float benchmarks are not that meaningful, since I performed them in QEMU.
>> 
>> __hard-float__ `-Xint -XX:+InlineIntrinsics`
>> 
>> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
>> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
>> | MathBench.absDouble           |      0 | thrpt |   5 | 1169.574 | +/- 133.694 | ops/ms |
>> | MathBench.cosDouble           |      0 | thrpt |   5 |  759.902 | +/- 573.852 | ops/ms |
>> | MathBench.expDouble           |      0 | thrpt |   5 |  854.753 | +/-  67.217 | ops/ms |
>> | MathBench.log10Double         |      0 | thrpt |   5 |  902.034 | +/-  22.413 | ops/ms |
>> | MathBench.logDouble           |      0 | thrpt |   5 |  895.470 | +/- 113.811 | ops/ms |
>> | MathBench.powDouble           |      0 | thrpt |   5 |  936.136 | +/-  40.661 | ops/ms |
>> | MathBench.sinDouble           |      0 | thrpt |   5 |  864.670 | +/-  68.329 | ops/ms |
>> | MathBench.sqrtDouble          |      0 | thrpt |   5 | 1082.589 | +/-  92.570 | ops/ms |
>> | MathBench.tanDouble           |      0 | thrpt |   5 |  853.715 | +/- 122.427 | ops/ms |
>> 
>> __hard-float__ `-Xint -XX:-InlineIntrinsics`
>> 
>> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
>> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
>> | MathBench.absDouble           |      0 | thrpt |   5 |  450.907 | +/-  10.402 | ops/ms |
>> | MathBench.cosDouble           |      0 | thrpt |   5 |  592.242 | +/-  14.011 | ops/ms |
>> | MathBench.expDouble           |      0 | thrpt |   5 |  167.614 | +/-   7.530 | ops/ms |
>> | MathBench.log10Double         |      0 | thrpt |   5 |  572.099 | +/-  55.089 | ops/ms |
>> | MathBench.logDouble           |      0 | thrpt |   5 |  596.588 | +/-  24.976 | ops/ms |
>> | MathBench.powDouble           |      0 | thrpt |   5 |  212.673 | +/-   4.060 | ops/ms |
>> | MathBench.sinDouble           |      0 | thrpt |   5 |  584.873 | +/-  42.774 | ops/ms |
>> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  514.690 | +/-  30.568 | ops/ms |
>> | MathBench.tanDouble           |      0 | thrpt |   5 |  566.586 | +/-  23.995 | ops/ms |
>> 
>> __soft-float__ `-Xint -XX:+InlineIntrinsics`
>> 
>> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
>> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
>> | MathBench.absDouble           |      0 | thrpt |   5 |  279.575 | +/-  56.455 | ops/ms |
>> | MathBench.cosDouble           |      0 | thrpt |   5 |  137.005 | +/-  72.561 | ops/ms |
>> | MathBench.expDouble           |      0 | thrpt |   5 |  117.778 | +/-  30.186 | ops/ms |
>> | MathBench.log10Double         |      0 | thrpt |   5 |  107.957 | +/-  10.158 | ops/ms |
>> | MathBench.logDouble           |      0 | thrpt |   5 |  101.341 | +/-   3.914 | ops/ms |
>> | MathBench.powDouble           |      0 | thrpt |   5 |  222.220 | +/-   3.854 | ops/ms |
>> | MathBench.sinDouble           |      0 | thrpt |   5 |  112.715 | +/-   9.088 | ops/ms |
>> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  119.341 | +/-  76.528 | ops/ms |
>> | MathBench.tanDouble           |      0 | thrpt |   5 |  105.224 | +/-  30.477 | ops/ms |
>> 
>> __soft-float__ `-Xint -XX:-InlineIntrinsics`
>> 
>> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
>> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
>> | MathBench.absDouble           |      0 | thrpt |   5 |  173.150 | +/-  36.279 | ops/ms |
>> | MathBench.cosDouble           |      0 | thrpt |   5 |  129.774 | +/-   8.795 | ops/ms |
>> | MathBench.expDouble           |      0 | thrpt |   5 |   53.524 | +/-   1.679 | ops/ms |
>> | MathBench.log10Double         |      0 | thrpt |   5 |  132.503 | +/-   4.274 | ops/ms |
>> | MathBench.logDouble           |      0 | thrpt |   5 |  135.483 | +/-   1.150 | ops/ms |
>> | MathBench.powDouble           |      0 | thrpt |   5 |   54.266 | +/-   0.699 | ops/ms |
>> | MathBench.sinDouble           |      0 | thrpt |   5 |  105.636 | +/-   4.647 | ops/ms |
>> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  204.550 | +/-   7.206 | ops/ms |
>> | MathBench.tanDouble           |      0 | thrpt |   5 |  101.072 | +/-   3.701 | ops/ms |
>
> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename transcendental_entry -> use_runtime_function

I'd prefer `use_runtime_function` to be called `use_runtime_call`, but this is fine as well. I can sponsor this for you.

-------------

Marked as reviewed by shade (Reviewer).

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

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: <fpCO3gUF8wIMpbApI2_r_59IKqYaMLvK3EswyU0skRc=.bc9fb87b-588e-439d-91de-701df1e51b61@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <fpCO3gUF8wIMpbApI2_r_59IKqYaMLvK3EswyU0skRc=.bc9fb87b-588e-439d-91de-701df1e51b61@github.com>
Message-ID: <4Q9NnQH4-CV3Q5F1yGFSZTjRMPpvsnqRFzIZD46C-cM=.2498df3e-ceb8-47a1-9381-019f7b980c75@github.com>

On Thu, 5 Aug 2021 11:21:59 GMT, Matthias Baesken <mbaesken at openjdk.org> 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 cgo at openjdk.java.net  Fri Aug  6 08:49:50 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Fri, 6 Aug 2021 08:49:50 GMT
Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM [v4]
In-Reply-To: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
Message-ID: <VT7StM3kssFf4c_2phPcf3DuJ5tn7IYFYQvkxqzV-gA=.8fcd72e8-16fc-4ab1-be06-f52ebf134787@github.com>

> Hi,
> 
> please review this patch, which adds support for InlineIntrinsics to the 32-bit ARM port. The old aarch32 port had this intrinsic implemented and enabled by default.
> 
> Like on many other platforms, the 32-bit ARM port simply calls into the `SharedRuntime` to intrinsify the basic `java.lang.Math` methods. InlineIntrinsics is already implemented for C1 on 32-bit ARM, which does the same thing.
> 
> testing: hotspot tier1 on ARMv5TE (soft-float) and ARMv7-A (hard-float)
> 
> There is already the micro benchmark `test/micro/org/openjdk/bench/java/lang/MathBench.java` which I used. The soft-float benchmarks are not that meaningful, since I performed them in QEMU.
> 
> __hard-float__ `-Xint -XX:+InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 | 1169.574 | +/- 133.694 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  759.902 | +/- 573.852 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  854.753 | +/-  67.217 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  902.034 | +/-  22.413 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  895.470 | +/- 113.811 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  936.136 | +/-  40.661 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  864.670 | +/-  68.329 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 | 1082.589 | +/-  92.570 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  853.715 | +/- 122.427 | ops/ms |
> 
> __hard-float__ `-Xint -XX:-InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  450.907 | +/-  10.402 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  592.242 | +/-  14.011 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  167.614 | +/-   7.530 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  572.099 | +/-  55.089 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  596.588 | +/-  24.976 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  212.673 | +/-   4.060 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  584.873 | +/-  42.774 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  514.690 | +/-  30.568 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  566.586 | +/-  23.995 | ops/ms |
> 
> __soft-float__ `-Xint -XX:+InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  279.575 | +/-  56.455 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  137.005 | +/-  72.561 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  117.778 | +/-  30.186 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  107.957 | +/-  10.158 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  101.341 | +/-   3.914 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  222.220 | +/-   3.854 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  112.715 | +/-   9.088 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  119.341 | +/-  76.528 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  105.224 | +/-  30.477 | ops/ms |
> 
> __soft-float__ `-Xint -XX:-InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  173.150 | +/-  36.279 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  129.774 | +/-   8.795 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |   53.524 | +/-   1.679 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  132.503 | +/-   4.274 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  135.483 | +/-   1.150 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |   54.266 | +/-   0.699 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  105.636 | +/-   4.647 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  204.550 | +/-   7.206 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  101.072 | +/-   3.701 | ops/ms |

Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:

  Rename use_runtime_function -> use_runtime_call

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4927/files
  - new: https://git.openjdk.java.net/jdk/pull/4927/files/3c20c980..6de922f8

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

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

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

From cgo at openjdk.java.net  Fri Aug  6 08:49:50 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Fri, 6 Aug 2021 08:49:50 GMT
Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM [v3]
In-Reply-To: <kepFr97W7WUKOsraX3Mic7V_hqod2e6ZZcF-Fq0grOE=.75ed2bcd-faf1-4ffe-8755-502c2b205637@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
 <tmmFC4C2e21MK6VWnQHwm7VHKNX5R33d8ERJy_swFFE=.ca6100e4-604b-4f8d-b5fa-f190d8ba9e16@github.com>
 <kepFr97W7WUKOsraX3Mic7V_hqod2e6ZZcF-Fq0grOE=.75ed2bcd-faf1-4ffe-8755-502c2b205637@github.com>
Message-ID: <1MphbU-a307xL94bkjOIxDEyReTw6tWphzFYCm6YU9g=.905e79b6-6ecc-497b-8b83-d77f9b7cf0e2@github.com>

On Fri, 6 Aug 2021 08:12:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I'd prefer `use_runtime_function` to be called `use_runtime_call`

Done.

> I can sponsor this for you.

Thanks, I guess I have to integrate again?

-------------

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

From shade at openjdk.java.net  Fri Aug  6 08:49:51 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 6 Aug 2021 08:49:51 GMT
Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM [v3]
In-Reply-To: <tmmFC4C2e21MK6VWnQHwm7VHKNX5R33d8ERJy_swFFE=.ca6100e4-604b-4f8d-b5fa-f190d8ba9e16@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
 <tmmFC4C2e21MK6VWnQHwm7VHKNX5R33d8ERJy_swFFE=.ca6100e4-604b-4f8d-b5fa-f190d8ba9e16@github.com>
Message-ID: <3Gb6H4AVCP9zVLx7LrZNqGqFzNFBZsuMQp-5HlrAIRc=.0c576181-a581-43e2-ad54-8d73d0695b95@github.com>

On Fri, 6 Aug 2021 08:07:54 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

>> Hi,
>> 
>> please review this patch, which adds support for InlineIntrinsics to the 32-bit ARM port. The old aarch32 port had this intrinsic implemented and enabled by default.
>> 
>> Like on many other platforms, the 32-bit ARM port simply calls into the `SharedRuntime` to intrinsify the basic `java.lang.Math` methods. InlineIntrinsics is already implemented for C1 on 32-bit ARM, which does the same thing.
>> 
>> testing: hotspot tier1 on ARMv5TE (soft-float) and ARMv7-A (hard-float)
>> 
>> There is already the micro benchmark `test/micro/org/openjdk/bench/java/lang/MathBench.java` which I used. The soft-float benchmarks are not that meaningful, since I performed them in QEMU.
>> 
>> __hard-float__ `-Xint -XX:+InlineIntrinsics`
>> 
>> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
>> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
>> | MathBench.absDouble           |      0 | thrpt |   5 | 1169.574 | +/- 133.694 | ops/ms |
>> | MathBench.cosDouble           |      0 | thrpt |   5 |  759.902 | +/- 573.852 | ops/ms |
>> | MathBench.expDouble           |      0 | thrpt |   5 |  854.753 | +/-  67.217 | ops/ms |
>> | MathBench.log10Double         |      0 | thrpt |   5 |  902.034 | +/-  22.413 | ops/ms |
>> | MathBench.logDouble           |      0 | thrpt |   5 |  895.470 | +/- 113.811 | ops/ms |
>> | MathBench.powDouble           |      0 | thrpt |   5 |  936.136 | +/-  40.661 | ops/ms |
>> | MathBench.sinDouble           |      0 | thrpt |   5 |  864.670 | +/-  68.329 | ops/ms |
>> | MathBench.sqrtDouble          |      0 | thrpt |   5 | 1082.589 | +/-  92.570 | ops/ms |
>> | MathBench.tanDouble           |      0 | thrpt |   5 |  853.715 | +/- 122.427 | ops/ms |
>> 
>> __hard-float__ `-Xint -XX:-InlineIntrinsics`
>> 
>> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
>> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
>> | MathBench.absDouble           |      0 | thrpt |   5 |  450.907 | +/-  10.402 | ops/ms |
>> | MathBench.cosDouble           |      0 | thrpt |   5 |  592.242 | +/-  14.011 | ops/ms |
>> | MathBench.expDouble           |      0 | thrpt |   5 |  167.614 | +/-   7.530 | ops/ms |
>> | MathBench.log10Double         |      0 | thrpt |   5 |  572.099 | +/-  55.089 | ops/ms |
>> | MathBench.logDouble           |      0 | thrpt |   5 |  596.588 | +/-  24.976 | ops/ms |
>> | MathBench.powDouble           |      0 | thrpt |   5 |  212.673 | +/-   4.060 | ops/ms |
>> | MathBench.sinDouble           |      0 | thrpt |   5 |  584.873 | +/-  42.774 | ops/ms |
>> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  514.690 | +/-  30.568 | ops/ms |
>> | MathBench.tanDouble           |      0 | thrpt |   5 |  566.586 | +/-  23.995 | ops/ms |
>> 
>> __soft-float__ `-Xint -XX:+InlineIntrinsics`
>> 
>> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
>> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
>> | MathBench.absDouble           |      0 | thrpt |   5 |  279.575 | +/-  56.455 | ops/ms |
>> | MathBench.cosDouble           |      0 | thrpt |   5 |  137.005 | +/-  72.561 | ops/ms |
>> | MathBench.expDouble           |      0 | thrpt |   5 |  117.778 | +/-  30.186 | ops/ms |
>> | MathBench.log10Double         |      0 | thrpt |   5 |  107.957 | +/-  10.158 | ops/ms |
>> | MathBench.logDouble           |      0 | thrpt |   5 |  101.341 | +/-   3.914 | ops/ms |
>> | MathBench.powDouble           |      0 | thrpt |   5 |  222.220 | +/-   3.854 | ops/ms |
>> | MathBench.sinDouble           |      0 | thrpt |   5 |  112.715 | +/-   9.088 | ops/ms |
>> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  119.341 | +/-  76.528 | ops/ms |
>> | MathBench.tanDouble           |      0 | thrpt |   5 |  105.224 | +/-  30.477 | ops/ms |
>> 
>> __soft-float__ `-Xint -XX:-InlineIntrinsics`
>> 
>> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
>> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
>> | MathBench.absDouble           |      0 | thrpt |   5 |  173.150 | +/-  36.279 | ops/ms |
>> | MathBench.cosDouble           |      0 | thrpt |   5 |  129.774 | +/-   8.795 | ops/ms |
>> | MathBench.expDouble           |      0 | thrpt |   5 |   53.524 | +/-   1.679 | ops/ms |
>> | MathBench.log10Double         |      0 | thrpt |   5 |  132.503 | +/-   4.274 | ops/ms |
>> | MathBench.logDouble           |      0 | thrpt |   5 |  135.483 | +/-   1.150 | ops/ms |
>> | MathBench.powDouble           |      0 | thrpt |   5 |   54.266 | +/-   0.699 | ops/ms |
>> | MathBench.sinDouble           |      0 | thrpt |   5 |  105.636 | +/-   4.647 | ops/ms |
>> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  204.550 | +/-   7.206 | ops/ms |
>> | MathBench.tanDouble           |      0 | thrpt |   5 |  101.072 | +/-   3.701 | ops/ms |
>
> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename transcendental_entry -> use_runtime_function

Yup, I'll wait for GHA to clear the ARM build, and then sponsor.

-------------

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

From cgo at openjdk.java.net  Fri Aug  6 10:26:33 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Fri, 6 Aug 2021 10:26:33 GMT
Subject: Integrated: 8271128: InlineIntrinsics support for 32-bit ARM
In-Reply-To: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
Message-ID: <SBWOWg0D1BwMv8ki2GFyprQhbFPGa7A96e4zo1l99mg=.5793576a-bd9b-4ba1-9b40-fc7c523b7ac8@github.com>

On Thu, 29 Jul 2021 09:40:08 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Hi,
> 
> please review this patch, which adds support for InlineIntrinsics to the 32-bit ARM port. The old aarch32 port had this intrinsic implemented and enabled by default.
> 
> Like on many other platforms, the 32-bit ARM port simply calls into the `SharedRuntime` to intrinsify the basic `java.lang.Math` methods. InlineIntrinsics is already implemented for C1 on 32-bit ARM, which does the same thing.
> 
> testing: hotspot tier1 on ARMv5TE (soft-float) and ARMv7-A (hard-float)
> 
> There is already the micro benchmark `test/micro/org/openjdk/bench/java/lang/MathBench.java` which I used. The soft-float benchmarks are not that meaningful, since I performed them in QEMU.
> 
> __hard-float__ `-Xint -XX:+InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 | 1169.574 | +/- 133.694 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  759.902 | +/- 573.852 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  854.753 | +/-  67.217 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  902.034 | +/-  22.413 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  895.470 | +/- 113.811 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  936.136 | +/-  40.661 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  864.670 | +/-  68.329 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 | 1082.589 | +/-  92.570 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  853.715 | +/- 122.427 | ops/ms |
> 
> __hard-float__ `-Xint -XX:-InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  450.907 | +/-  10.402 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  592.242 | +/-  14.011 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  167.614 | +/-   7.530 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  572.099 | +/-  55.089 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  596.588 | +/-  24.976 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  212.673 | +/-   4.060 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  584.873 | +/-  42.774 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  514.690 | +/-  30.568 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  566.586 | +/-  23.995 | ops/ms |
> 
> __soft-float__ `-Xint -XX:+InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  279.575 | +/-  56.455 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  137.005 | +/-  72.561 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |  117.778 | +/-  30.186 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  107.957 | +/-  10.158 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  101.341 | +/-   3.914 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |  222.220 | +/-   3.854 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  112.715 | +/-   9.088 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  119.341 | +/-  76.528 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  105.224 | +/-  30.477 | ops/ms |
> 
> __soft-float__ `-Xint -XX:-InlineIntrinsics`
> 
> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
> | MathBench.absDouble           |      0 | thrpt |   5 |  173.150 | +/-  36.279 | ops/ms |
> | MathBench.cosDouble           |      0 | thrpt |   5 |  129.774 | +/-   8.795 | ops/ms |
> | MathBench.expDouble           |      0 | thrpt |   5 |   53.524 | +/-   1.679 | ops/ms |
> | MathBench.log10Double         |      0 | thrpt |   5 |  132.503 | +/-   4.274 | ops/ms |
> | MathBench.logDouble           |      0 | thrpt |   5 |  135.483 | +/-   1.150 | ops/ms |
> | MathBench.powDouble           |      0 | thrpt |   5 |   54.266 | +/-   0.699 | ops/ms |
> | MathBench.sinDouble           |      0 | thrpt |   5 |  105.636 | +/-   4.647 | ops/ms |
> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  204.550 | +/-   7.206 | ops/ms |
> | MathBench.tanDouble           |      0 | thrpt |   5 |  101.072 | +/-   3.701 | ops/ms |

This pull request has now been integrated.

Changeset: b6a19f17
Author:    Christoph G?ttschkes <cgo at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b6a19f173bc6c07622633c9d6757d96a95b43398
Stats:     111 lines in 4 files changed: 104 ins; 0 del; 7 mod

8271128: InlineIntrinsics support for 32-bit ARM

Reviewed-by: shade

-------------

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

From shade at openjdk.java.net  Fri Aug  6 10:26:32 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 6 Aug 2021 10:26:32 GMT
Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM [v4]
In-Reply-To: <VT7StM3kssFf4c_2phPcf3DuJ5tn7IYFYQvkxqzV-gA=.8fcd72e8-16fc-4ab1-be06-f52ebf134787@github.com>
References: <khz1jDnTvyLxS4c7mDsDksZDEEM3a2NUnych5vfyVAM=.a4b93f6a-3548-4f15-8733-191193a881ca@github.com>
 <VT7StM3kssFf4c_2phPcf3DuJ5tn7IYFYQvkxqzV-gA=.8fcd72e8-16fc-4ab1-be06-f52ebf134787@github.com>
Message-ID: <2TjxZZF9nc3d8UBCf3Co_UzRCaLkDFHrN9Bs6NpIj5Q=.d683c6c1-fce9-4cc7-9928-c354552e63f7@github.com>

On Fri, 6 Aug 2021 08:49:50 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

>> Hi,
>> 
>> please review this patch, which adds support for InlineIntrinsics to the 32-bit ARM port. The old aarch32 port had this intrinsic implemented and enabled by default.
>> 
>> Like on many other platforms, the 32-bit ARM port simply calls into the `SharedRuntime` to intrinsify the basic `java.lang.Math` methods. InlineIntrinsics is already implemented for C1 on 32-bit ARM, which does the same thing.
>> 
>> testing: hotspot tier1 on ARMv5TE (soft-float) and ARMv7-A (hard-float)
>> 
>> There is already the micro benchmark `test/micro/org/openjdk/bench/java/lang/MathBench.java` which I used. The soft-float benchmarks are not that meaningful, since I performed them in QEMU.
>> 
>> __hard-float__ `-Xint -XX:+InlineIntrinsics`
>> 
>> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
>> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
>> | MathBench.absDouble           |      0 | thrpt |   5 | 1169.574 | +/- 133.694 | ops/ms |
>> | MathBench.cosDouble           |      0 | thrpt |   5 |  759.902 | +/- 573.852 | ops/ms |
>> | MathBench.expDouble           |      0 | thrpt |   5 |  854.753 | +/-  67.217 | ops/ms |
>> | MathBench.log10Double         |      0 | thrpt |   5 |  902.034 | +/-  22.413 | ops/ms |
>> | MathBench.logDouble           |      0 | thrpt |   5 |  895.470 | +/- 113.811 | ops/ms |
>> | MathBench.powDouble           |      0 | thrpt |   5 |  936.136 | +/-  40.661 | ops/ms |
>> | MathBench.sinDouble           |      0 | thrpt |   5 |  864.670 | +/-  68.329 | ops/ms |
>> | MathBench.sqrtDouble          |      0 | thrpt |   5 | 1082.589 | +/-  92.570 | ops/ms |
>> | MathBench.tanDouble           |      0 | thrpt |   5 |  853.715 | +/- 122.427 | ops/ms |
>> 
>> __hard-float__ `-Xint -XX:-InlineIntrinsics`
>> 
>> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
>> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
>> | MathBench.absDouble           |      0 | thrpt |   5 |  450.907 | +/-  10.402 | ops/ms |
>> | MathBench.cosDouble           |      0 | thrpt |   5 |  592.242 | +/-  14.011 | ops/ms |
>> | MathBench.expDouble           |      0 | thrpt |   5 |  167.614 | +/-   7.530 | ops/ms |
>> | MathBench.log10Double         |      0 | thrpt |   5 |  572.099 | +/-  55.089 | ops/ms |
>> | MathBench.logDouble           |      0 | thrpt |   5 |  596.588 | +/-  24.976 | ops/ms |
>> | MathBench.powDouble           |      0 | thrpt |   5 |  212.673 | +/-   4.060 | ops/ms |
>> | MathBench.sinDouble           |      0 | thrpt |   5 |  584.873 | +/-  42.774 | ops/ms |
>> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  514.690 | +/-  30.568 | ops/ms |
>> | MathBench.tanDouble           |      0 | thrpt |   5 |  566.586 | +/-  23.995 | ops/ms |
>> 
>> __soft-float__ `-Xint -XX:+InlineIntrinsics`
>> 
>> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
>> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
>> | MathBench.absDouble           |      0 | thrpt |   5 |  279.575 | +/-  56.455 | ops/ms |
>> | MathBench.cosDouble           |      0 | thrpt |   5 |  137.005 | +/-  72.561 | ops/ms |
>> | MathBench.expDouble           |      0 | thrpt |   5 |  117.778 | +/-  30.186 | ops/ms |
>> | MathBench.log10Double         |      0 | thrpt |   5 |  107.957 | +/-  10.158 | ops/ms |
>> | MathBench.logDouble           |      0 | thrpt |   5 |  101.341 | +/-   3.914 | ops/ms |
>> | MathBench.powDouble           |      0 | thrpt |   5 |  222.220 | +/-   3.854 | ops/ms |
>> | MathBench.sinDouble           |      0 | thrpt |   5 |  112.715 | +/-   9.088 | ops/ms |
>> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  119.341 | +/-  76.528 | ops/ms |
>> | MathBench.tanDouble           |      0 | thrpt |   5 |  105.224 | +/-  30.477 | ops/ms |
>> 
>> __soft-float__ `-Xint -XX:-InlineIntrinsics`
>> 
>> | Benchmark                     | (seed) |  Mode | Cnt |    Score |       Error |  Units |
>> | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: |
>> | MathBench.absDouble           |      0 | thrpt |   5 |  173.150 | +/-  36.279 | ops/ms |
>> | MathBench.cosDouble           |      0 | thrpt |   5 |  129.774 | +/-   8.795 | ops/ms |
>> | MathBench.expDouble           |      0 | thrpt |   5 |   53.524 | +/-   1.679 | ops/ms |
>> | MathBench.log10Double         |      0 | thrpt |   5 |  132.503 | +/-   4.274 | ops/ms |
>> | MathBench.logDouble           |      0 | thrpt |   5 |  135.483 | +/-   1.150 | ops/ms |
>> | MathBench.powDouble           |      0 | thrpt |   5 |   54.266 | +/-   0.699 | ops/ms |
>> | MathBench.sinDouble           |      0 | thrpt |   5 |  105.636 | +/-   4.647 | ops/ms |
>> | MathBench.sqrtDouble          |      0 | thrpt |   5 |  204.550 | +/-   7.206 | ops/ms |
>> | MathBench.tanDouble           |      0 | thrpt |   5 |  101.072 | +/-   3.701 | ops/ms |
>
> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename use_runtime_function -> use_runtime_call

ARM builds are clean.

-------------

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

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: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <fpCO3gUF8wIMpbApI2_r_59IKqYaMLvK3EswyU0skRc=.bc9fb87b-588e-439d-91de-701df1e51b61@github.com>
 <4Q9NnQH4-CV3Q5F1yGFSZTjRMPpvsnqRFzIZD46C-cM=.2498df3e-ceb8-47a1-9381-019f7b980c75@github.com>
Message-ID: <ghA3lStsSsHLlTf5ASXEJG8e3m0ky852RR0uVjhbXj0=.e3ffb798-6469-4651-984a-be76d483d402@github.com>

On Fri, 6 Aug 2021 08:29:50 GMT, Severin Gehwolf <sgehwolf at openjdk.org> 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 stefank at openjdk.java.net  Fri Aug  6 11:20:28 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 6 Aug 2021 11:20:28 GMT
Subject: RFR: 8271939: Clean up primitive raw accessors in oopDesc
In-Reply-To: <rPN6z0gQprVXkBVLa42lAJEI8QHTsAoGYHhF4mbUrDI=.c0d5479d-791f-49ff-9a0c-fab66f39b45c@github.com>
References: <rPN6z0gQprVXkBVLa42lAJEI8QHTsAoGYHhF4mbUrDI=.c0d5479d-791f-49ff-9a0c-fab66f39b45c@github.com>
Message-ID: <R4xPfo-gGPS7Vtdl5bIbElWW9v6fIAUYYjU6hnReeak=.87469acc-e3d7-4081-a180-421a725d0672@github.com>

On Thu, 5 Aug 2021 11:20:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We have some _raw accessors in oop.hpp and related code. Those are leftover from when Shenandoah required primitive barriers and are no longer needed. Their uses can be replaced with the regular accessors.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [x] hotspot_gc

Marked as reviewed by stefank (Reviewer).

-------------

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

From rkennke at openjdk.java.net  Fri Aug  6 11:59:59 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 6 Aug 2021 11:59:59 GMT
Subject: RFR: 8271939: Clean up primitive raw accessors in oopDesc [v2]
In-Reply-To: <rPN6z0gQprVXkBVLa42lAJEI8QHTsAoGYHhF4mbUrDI=.c0d5479d-791f-49ff-9a0c-fab66f39b45c@github.com>
References: <rPN6z0gQprVXkBVLa42lAJEI8QHTsAoGYHhF4mbUrDI=.c0d5479d-791f-49ff-9a0c-fab66f39b45c@github.com>
Message-ID: <ZcF14Wy5G2CcjB5_eDoh7dxPPJ_kadmUUSwIEjI1NKs=.c3d52805-f23d-4d06-90c4-291f3f951cf1@github.com>

> We have some _raw accessors in oop.hpp and related code. Those are leftover from when Shenandoah required primitive barriers and are no longer needed. Their uses can be replaced with the regular accessors.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [x] hotspot_gc

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

  Change loader_data_raw() to regular loader_data()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5017/files
  - new: https://git.openjdk.java.net/jdk/pull/5017/files/12b3c772..515c3a8a

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

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

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

From coleenp at openjdk.java.net  Fri Aug  6 13:46:32 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 6 Aug 2021 13:46:32 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v3]
In-Reply-To: <VqqKk7Ywbj0sUCabExPi-nCAG8cIVvQq9eHM0ZIttcw=.52adcc18-f916-4125-bfb9-e45463eca65d@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <IjrNVUh-ugqA1wZjkbcxj2eOlP7HRWvk7-a4X0gA0kg=.0ef28a9a-5b38-442c-bebe-f7caa9ca8a78@github.com>
 <VqqKk7Ywbj0sUCabExPi-nCAG8cIVvQq9eHM0ZIttcw=.52adcc18-f916-4125-bfb9-e45463eca65d@github.com>
Message-ID: <eNqEZMMsCZnd30SMblhJuDZxtKoR2Xr8WTca7o_YTYg=.89a50583-f1b4-47d9-a68d-e40b265e0119@github.com>

On Fri, 6 Aug 2021 07:30:55 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Coleen Phillimore 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 init-oom
>>  - David review comments.
>>  - Merge branch 'master' into init-oom
>>  - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError
>>  - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError
>
> src/hotspot/share/oops/instanceKlass.cpp line 1054:
> 
>> 1052: 
>> 1053: ResizeableResourceHashtable<const InstanceKlass*, InitErrorElement, ResourceObj::C_HEAP, mtClass>
>> 1054:       _initialization_error_table(20);
> 
> As I understand, the whole point of this table is to save space. Instead, you could repurpose `T[] Class.enumConstants` to be `Object Class.enumConstantsOrInitError`. For a non-enum classes, this field is never used (and thus already "wasted") and for enum classes it will never be successfully initialized if there's a clinit error.

It seems like if this field in Class is wasted, it should be used by something more frequent and at the Java level.  I don't want to add some internal implementation dependency to this.  It'll complicate any attempts to change it.
In short, I didn't know about it and in fact, I shouldn't know about it from inside the JVM.

-------------

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

From coleenp at openjdk.java.net  Fri Aug  6 13:50:30 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 6 Aug 2021 13:50:30 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v2]
In-Reply-To: <Gb2fhxQPqK2FLjUUPihssdglm0SlB30atk0T7westZA=.ce573905-ade0-423d-b564-56dad56ba675@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <rr4xTD3oiLP4N1P9pOHOXMFnz84exIpHO4F2DdoYBxA=.43d4439c-a6ac-4eb2-bf80-7c1e89cdde01@github.com>
 <iDNnQdUalEL-NB7j0G99_6D0oAtUXSFrkSEtFjk-ZuY=.3fd94841-9452-4ae3-a7b0-fdf0d770b458@github.com>
 <ggGUw-81ThvCX60CkGQ5DzFlG7wZv7g-qc6h9hwjUgM=.f6e7cf31-de00-4c1d-b3ac-50a4db1b0ef1@github.com>
 <mnzMWu9vmF7A6FAnsr-O39sA-cfXkUda-jj425NDX7Y=.bd8b91f4-923a-4391-804e-6c7bde9652d3@github.com>
 <w9neoSFLowBKocUguLIkoM9pIMpkJd9NC60rme04iC0=.75c7669d-7ee7-4532-b58a-eaaddbbd161c@github.com>
 <Gb2fhxQPqK2FLjUUPihssdglm0SlB30atk0T7westZA=.ce573905-ade0-423d-b564-56dad56ba675@github.com>
Message-ID: <gaFpoTU1SwPvvVBz-n2N_9BS6FOtaIOsgQ6JjN-ODQU=.a1b6a0e5-d83c-4f66-855f-e3b56f6d832f@github.com>

On Fri, 6 Aug 2021 04:12:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> You're right.  new_exception does surprising things.  If it gets an exception during the call, it returns a handle to that exception, which is not what I want at all.  I'll return null in that case.
>
> I have to wonder whether `new_exceptions`'s behaviour is what anyone would want! It could lead to some very strange exceptions being thrown - see for example `ConstantPool::throw_resolution_error` where it can throw a resolution error with the wrong cause!
> 
> It may be okay to restrict re-creation of the exception to types in java.base as their construction seems benign with no context dependency and they should always have the necessary constructor.
> 
> Using ExceptionInInitializerError as the cause of the NCDFE may be okay for other cases.

Thanks David.  I filed an RFE for someone to look at this (maybe me) and write some tests.

I've reworked this patch a bit and will write a test for this case.  I create the new exception when I save it, which seems like a better time to do it, so I only need OopHandle in the table. This is closer to my first prototype now.  Also, if the exception's class loader isn't NULL, I'll do a switcheroo to ExceptionInInitializerError and add the name to the exception message.  Hopefully this makes this feature useful most of the time.

-------------

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

From dnsimon at openjdk.java.net  Fri Aug  6 15:13:33 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Fri, 6 Aug 2021 15:13:33 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v3]
In-Reply-To: <eNqEZMMsCZnd30SMblhJuDZxtKoR2Xr8WTca7o_YTYg=.89a50583-f1b4-47d9-a68d-e40b265e0119@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <IjrNVUh-ugqA1wZjkbcxj2eOlP7HRWvk7-a4X0gA0kg=.0ef28a9a-5b38-442c-bebe-f7caa9ca8a78@github.com>
 <VqqKk7Ywbj0sUCabExPi-nCAG8cIVvQq9eHM0ZIttcw=.52adcc18-f916-4125-bfb9-e45463eca65d@github.com>
 <eNqEZMMsCZnd30SMblhJuDZxtKoR2Xr8WTca7o_YTYg=.89a50583-f1b4-47d9-a68d-e40b265e0119@github.com>
Message-ID: <eViiVovf-UJJ_B161M9fcWvqDSZ2Qb7RAKRuTJnaFZM=.951c2405-28a2-4695-a6ad-abc1956ee3a3@github.com>

On Fri, 6 Aug 2021 13:43:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I shouldn't know about it from inside the JVM

Why not? The JVM already knows about a bunch of other fields in `java.lang.Class`.

That said, I agree that it's probably best left for something more frequent.

-------------

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

From coleenp at openjdk.java.net  Fri Aug  6 18:42:12 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 6 Aug 2021 18:42:12 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v4]
In-Reply-To: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
Message-ID: <A6jfsBBrXc-gXmDe_Ag4Io7k4ZSy4JGkw70JSPxjn7Y=.f71cad65-578f-4764-822b-113e61a6d55a@github.com>

> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
> 
> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).

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

  Create new exception during initialization saving, so only need to save an oop. (Could potentially move to Doug's secret Class location.  If the exception is not bootstrap exception, throw EIIE instead with message of original exception.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4996/files
  - new: https://git.openjdk.java.net/jdk/pull/4996/files/a8723bab..56ff30a1

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

  Stats: 200 lines in 5 files changed: 112 ins; 61 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4996.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4996/head:pull/4996

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

From valeriep at openjdk.java.net  Fri Aug  6 18:43:37 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 6 Aug 2021 18:43:37 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
Message-ID: <-4l1VSolt6v3jMkBH2RqGms3xDIV1j7WnmNQHDeDSqg=.2f399e77-10c7-42ae-9665-ffa227d7b60c@github.com>

On Wed, 4 Aug 2021 02:24:05 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>  - Updates, comment and variable cleanup
>  - merge rest
>  - merge
>  - fixes and code comments

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1473:

> 1471:             if (mismatch != 0) {
> 1472:                 // Clear output data
> 1473:                 Arrays.fill(out, outOfs, outOfs + len, (byte) 0);

Update the javadoc of this method (line 1428-1429) with this change, i.e. clears output data if tag verification fails. Same goes for line 1482-1483.

-------------

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

From valeriep at openjdk.java.net  Fri Aug  6 19:19:37 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 6 Aug 2021 19:19:37 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
Message-ID: <A_dsMP2h3dJxQTH5KhQf_8CNVI3NkJavVsMJWQZvlSM=.52cfb190-f37f-473d-bf2f-20ff97e53d6b@github.com>

On Wed, 4 Aug 2021 02:24:05 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>  - Updates, comment and variable cleanup
>  - merge rest
>  - merge
>  - fixes and code comments

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1779:

> 1777:             int len = 0;
> 1778:             if (inLen >= PARALLEL_LEN) {
> 1779:                 implGCMCrypt(in, inOfs, inLen, in, inOfs, out, outOfs, gctr,

Should save the return value into 'len'?

-------------

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

From ascarpino at openjdk.java.net  Fri Aug  6 19:38:40 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 6 Aug 2021 19:38:40 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <A_dsMP2h3dJxQTH5KhQf_8CNVI3NkJavVsMJWQZvlSM=.52cfb190-f37f-473d-bf2f-20ff97e53d6b@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
 <A_dsMP2h3dJxQTH5KhQf_8CNVI3NkJavVsMJWQZvlSM=.52cfb190-f37f-473d-bf2f-20ff97e53d6b@github.com>
Message-ID: <Wvrw_lfIMcnvvkbb5VchtFjz1azshzL6dh4Qj5cs7Bo=.5520d555-6d6d-4300-9bbc-8fc4889256e1@github.com>

On Fri, 6 Aug 2021 19:16:39 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>>  - Updates, comment and variable cleanup
>>  - merge rest
>>  - merge
>>  - fixes and code comments
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1779:
> 
>> 1777:             int len = 0;
>> 1778:             if (inLen >= PARALLEL_LEN) {
>> 1779:                 implGCMCrypt(in, inOfs, inLen, in, inOfs, out, outOfs, gctr,
> 
> Should save the return value into 'len'? For consistency sake, choose between GaloisCounterMode.implGCMCrypt(...) and implGCMCrypt and not both?

I do not understand this comment

-------------

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

From valeriep at openjdk.java.net  Fri Aug  6 19:38:39 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 6 Aug 2021 19:38:39 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
Message-ID: <v-IOXTUTZ2yzqqeJe4VBWxeE9Mb0DKPRlNily-balpg=.073da99f-8b69-4aa3-91ee-845f619978c7@github.com>

On Wed, 4 Aug 2021 02:24:05 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>  - Updates, comment and variable cleanup
>  - merge rest
>  - merge
>  - fixes and code comments

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1648:

> 1646: 
> 1647:             ghash.doFinal(in, inOfs, inLen);
> 1648:             return len + gctr.doFinal(in, inOfs, inLen, out, outOfs);

Why not just keep "return len + op.doFinal(in, inOfs, inLen, out, outOfs);"?

-------------

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

From valeriep at openjdk.java.net  Fri Aug  6 19:47:38 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 6 Aug 2021 19:47:38 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
Message-ID: <zgp6RY8EMQFaGxyvaDFIQlhIKnrpuxmRfu_FsAL7-yk=.c0b6e553-5915-4f6a-ae32-976b26165cd3@github.com>

On Wed, 4 Aug 2021 02:24:05 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>  - Updates, comment and variable cleanup
>  - merge rest
>  - merge
>  - fixes and code comments

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 87:

> 85:     private static final int MAX_BUF_SIZE = Integer.MAX_VALUE;
> 86:     // data size when buffer is divided up to aid in intrinsics
> 87:     private static final int TRIGGERLEN = 65536;  // 64k

With this interleaved impl, is this TRIGGERLEN still needed? The implGCMCrypt(byte[] in, int inOfs, int inLen,
        byte[] ct, int ctOfs, byte[] out, int outOfs, GCTR gctr, GHASH ghash) method is intrinsified, would there be a difference in increasing the number of gctr/ghash calls inside an already intrinsified method?

-------------

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

From ascarpino at openjdk.java.net  Fri Aug  6 19:51:34 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 6 Aug 2021 19:51:34 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <v-IOXTUTZ2yzqqeJe4VBWxeE9Mb0DKPRlNily-balpg=.073da99f-8b69-4aa3-91ee-845f619978c7@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
 <v-IOXTUTZ2yzqqeJe4VBWxeE9Mb0DKPRlNily-balpg=.073da99f-8b69-4aa3-91ee-845f619978c7@github.com>
Message-ID: <Zj37tg-JZfN_568cXkcE9XyQwto_CBJkw9sw0y6ONDQ=.11a201c2-2857-4993-9ca5-f298d537c1cd@github.com>

On Fri, 6 Aug 2021 19:32:25 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>>  - Updates, comment and variable cleanup
>>  - merge rest
>>  - merge
>>  - fixes and code comments
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1648:
> 
>> 1646: 
>> 1647:             ghash.doFinal(in, inOfs, inLen);
>> 1648:             return len + gctr.doFinal(in, inOfs, inLen, out, outOfs);
> 
> Why not just keep "return len + op.doFinal(in, inOfs, inLen, out, outOfs);"?

It probably got changed because I was cleaning up unused 'op' elsewhere

-------------

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

From ascarpino at openjdk.java.net  Fri Aug  6 19:56:33 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 6 Aug 2021 19:56:33 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <zgp6RY8EMQFaGxyvaDFIQlhIKnrpuxmRfu_FsAL7-yk=.c0b6e553-5915-4f6a-ae32-976b26165cd3@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
 <zgp6RY8EMQFaGxyvaDFIQlhIKnrpuxmRfu_FsAL7-yk=.c0b6e553-5915-4f6a-ae32-976b26165cd3@github.com>
Message-ID: <C7QhlB_cLX1eW-KtzvMC3a1zRzvusBRVi7W-04xE3Ss=.52db0426-86e7-4f40-a10d-2616d0032853@github.com>

On Fri, 6 Aug 2021 19:44:05 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>>  - Updates, comment and variable cleanup
>>  - merge rest
>>  - merge
>>  - fixes and code comments
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 87:
> 
>> 85:     private static final int MAX_BUF_SIZE = Integer.MAX_VALUE;
>> 86:     // data size when buffer is divided up to aid in intrinsics
>> 87:     private static final int TRIGGERLEN = 65536;  // 64k
> 
> With this interleaved impl, is this TRIGGERLEN still needed? The implGCMCrypt(byte[] in, int inOfs, int inLen,
>         byte[] ct, int ctOfs, byte[] out, int outOfs, GCTR gctr, GHASH ghash) method is intrinsified, would there be a difference in increasing the number of gctr/ghash calls inside an already intrinsified method?

Yes, they are two different intrinsics.  The new implGCMCrypt intrinsic is supported by newer processors so there is no guarantee that implGCMCrypt will run the intrinsic.

-------------

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

From valeriep at openjdk.java.net  Fri Aug  6 20:00:38 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 6 Aug 2021 20:00:38 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
Message-ID: <a2FZLCfubSMaeZe3bnSj2rL7_Guh4FkiZqDSvUu0EgE=.9852a252-2715-4ce5-b5f2-75178fc1e2f7@github.com>

On Wed, 4 Aug 2021 02:24:05 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>  - Updates, comment and variable cleanup
>  - merge rest
>  - merge
>  - fixes and code comments

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1120:

> 1118:                 inOfs += r;
> 1119:                 inLen -= r;
> 1120:             }

Have you considered move the "if (inLen >= PARALLEL_LEN) block" into EncryptOp.update() impl (just like the Encrypt.doFinal() impl) ? Even though not all op.update() calls process large data, but it'd reduce code duplication and ensures that all large data processed by EncryptOp.update() calls would call the intrinsified method.

-------------

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

From ascarpino at openjdk.java.net  Fri Aug  6 20:00:39 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 6 Aug 2021 20:00:39 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <-4l1VSolt6v3jMkBH2RqGms3xDIV1j7WnmNQHDeDSqg=.2f399e77-10c7-42ae-9665-ffa227d7b60c@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
 <-4l1VSolt6v3jMkBH2RqGms3xDIV1j7WnmNQHDeDSqg=.2f399e77-10c7-42ae-9665-ffa227d7b60c@github.com>
Message-ID: <OI2ILls6qsBFQ0fToDRQNK2Ts5obWFOyznLcOx8f4r8=.ef0635e2-1175-4755-af5f-4860876bcf48@github.com>

On Fri, 6 Aug 2021 18:40:44 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>>  - Updates, comment and variable cleanup
>>  - merge rest
>>  - merge
>>  - fixes and code comments
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1473:
> 
>> 1471:             if (mismatch != 0) {
>> 1472:                 // Clear output data
>> 1473:                 Arrays.fill(out, outOfs, outOfs + len, (byte) 0);
> 
> Update the javadoc of this method (line 1428-1429) with this change, i.e. clears output data if tag verification fails. Same goes for line 1482-1483.

ok

-------------

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

From valeriep at openjdk.java.net  Fri Aug  6 20:08:34 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 6 Aug 2021 20:08:34 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
Message-ID: <QMmRXPfRNq5kipiZdhOoWoQOmc2d6gej6RUcKSq71r8=.1778eab4-f38d-41a7-b3a4-9c626222acd8@github.com>

On Wed, 4 Aug 2021 02:24:05 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>  - Updates, comment and variable cleanup
>  - merge rest
>  - merge
>  - fixes and code comments

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1608:

> 1606:                 int bufRemainder = bLen - len;
> 1607:                 if (bufRemainder >= blockSize) {
> 1608:                     resultLen = op.update(buffer, len, bufRemainder, out, outOfs);

nit: exceeds 80 chars

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1721:

> 1719: 
> 1720:             if (inLen >= PARALLEL_LEN) {
> 1721:                 len = implGCMCrypt(in, inOfs, inLen, out, outOfs, out, outOfs, gctr, ghash);

nit: exceeds 80 chars

-------------

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

From ascarpino at openjdk.java.net  Fri Aug  6 20:08:36 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 6 Aug 2021 20:08:36 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <QMmRXPfRNq5kipiZdhOoWoQOmc2d6gej6RUcKSq71r8=.1778eab4-f38d-41a7-b3a4-9c626222acd8@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
 <QMmRXPfRNq5kipiZdhOoWoQOmc2d6gej6RUcKSq71r8=.1778eab4-f38d-41a7-b3a4-9c626222acd8@github.com>
Message-ID: <ewWgT0xUO8Ejj0BH4yOkjIBF_LnnpMQN3GJIY4xrRHs=.337cb9a9-e78c-4dce-92e0-61e316142067@github.com>

On Fri, 6 Aug 2021 20:01:00 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>>  - Updates, comment and variable cleanup
>>  - merge rest
>>  - merge
>>  - fixes and code comments
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1721:
> 
>> 1719: 
>> 1720:             if (inLen >= PARALLEL_LEN) {
>> 1721:                 len = implGCMCrypt(in, inOfs, inLen, out, outOfs, out, outOfs, gctr, ghash);
> 
> nit: exceeds 80 chars

The editor keeps reverting these for some reason.. it's very annoying

-------------

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

From ascarpino at openjdk.java.net  Fri Aug  6 20:40:37 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 6 Aug 2021 20:40:37 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <a2FZLCfubSMaeZe3bnSj2rL7_Guh4FkiZqDSvUu0EgE=.9852a252-2715-4ce5-b5f2-75178fc1e2f7@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
 <a2FZLCfubSMaeZe3bnSj2rL7_Guh4FkiZqDSvUu0EgE=.9852a252-2715-4ce5-b5f2-75178fc1e2f7@github.com>
Message-ID: <oXflpZYqIOAYE5h2NicmMtpPIuPuTUMNXj_DrWvQ_rU=.f23ed00c-b757-4bb0-b837-c49a07f5f522@github.com>

On Fri, 6 Aug 2021 19:57:11 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>>  - Updates, comment and variable cleanup
>>  - merge rest
>>  - merge
>>  - fixes and code comments
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1120:
> 
>> 1118:                 inOfs += r;
>> 1119:                 inLen -= r;
>> 1120:             }
> 
> Have you considered move the "if (inLen >= PARALLEL_LEN) block" into EncryptOp.update() impl (just like the Encrypt.doFinal() impl) ? Even though not all op.update() calls process large data, but it'd reduce code duplication and ensures that all large data processed by EncryptOp.update() calls would call the intrinsified method.

There are cases where inLen is known to be smaller than PARALLEL_LEN and is a waste of a check, such as merging with the ibuffer to create one block.  Also moving it into EncryptOp would always mean an additional check and maybe an unnecessary jump to another method.

I did that for doFinal, because gctr/ghash.doFinal() needs to was no extra checks.

-------------

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

From valeriep at openjdk.java.net  Fri Aug  6 21:37:33 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 6 Aug 2021 21:37:33 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
Message-ID: <qND4SOn-meYM406khLAILCpRkIx9YxUFaqfh_7ai4WY=.2a12f7f3-7491-4328-832c-d4530383195e@github.com>

On Wed, 4 Aug 2021 02:24:05 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>  - Updates, comment and variable cleanup
>  - merge rest
>  - merge
>  - fixes and code comments

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1446:

> 1444:                 throw new AEADBadTagException("Input too short - need tag");
> 1445:             }
> 1446: 

Unrelated to your change, but I noticed that the if-block from line 1443-1445 should be moved up before the ArrayUtil.nullAndBoundsCheck(...), otherwise the 3rd argument may be negative and lead to a wrong exception being thrown.

-------------

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

From valeriep at openjdk.java.net  Fri Aug  6 21:41:38 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 6 Aug 2021 21:41:38 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
Message-ID: <z7ZUJfZ9-gB-NrybU5FH9K1YEsesygXr1Sc0VNP1bHM=.aa37d196-be44-4f99-9139-f0491f6ddc97@github.com>

On Wed, 4 Aug 2021 02:24:05 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
>  - Updates, comment and variable cleanup
>  - merge rest
>  - merge
>  - fixes and code comments

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1508:

> 1506:             if (len > dst.remaining()) {
> 1507:                 throw new ShortBufferException("Output buffer too small, must" +
> 1508:                     "be at least " + (len - tagLenBytes) + " bytes long");

nit: add a space between "must" and "be".
Instead of '(len -tagLenBytes)' should just be 'len' as its initial value already deducts tagLenBytes (see line 1495).

-------------

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

From stuefe at openjdk.java.net  Sat Aug  7 05:38:39 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 7 Aug 2021 05:38:39 GMT
Subject: RFR: JDK-8272112: Arena code simplifications
Message-ID: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>

May I please have reviews for this small change. This is pure code cleanup, issues that were identified by code review when working on JDK-8270308. 

The patch results in less code (excluding the new gtest), bit easier to maintain. I have some smaller functional improvements in the pipeline and would like to get this code cleanup out of the way first.

Changes:

- Made `ChunkPool` an automatic object. We can remove `chunkpool_init()` and instead rely on automatic initialization.

- Instead of having four named pools that need to be handled individually and selected via awkward switch constructs (see the old `Chunk::operator new()` and `::operator delete()`), we replace it with an array and a static selector (`ChunkPool* get_pool_for_size(size_t size)`).

- Removed `ChunkPool::_num_used`. It was nowhere queried, and its usefulness was questionable since these numbers don't include chunks with "special" sizes. The easiest way to obtain the footprint of arena chunks is via NMT.

- Before, we had two places where the backing memory of Chunks was allocated: in `ChunkPool::allocate()` and in `Chunk::operator new()`. The former was unnecessary. I streamlined that: removed the ability to allocate from `ChunkPool::allocate()` and renamed it to `ChunkPool::remove_chunk()`. Now Chunks are only allocated in `Chunk::operator new() `and ChunkPool just serves as Chunk cache.

- Renamed `ChunkPool::free_all_but()` to `ChunkPool::prune()` and removed the argument, made it a method-local constant (it had been a constant before in the caller of that function).

- I added a new gtest to test Chunk allocation and pooling a little.


Functionally, nothing should have changed with this patch, this is pure code grooming.

----

Tests: 
- GHA
- I manually tested on 64-bit and 32-bit, with and without UseMallocOnly. I also manually checked that pool usage is as expected.

-------------

Commit messages:
 - arena code grooming

Changes: https://git.openjdk.java.net/jdk/pull/5040/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5040&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272112
  Stats: 148 lines in 3 files changed: 58 ins; 61 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5040.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5040/head:pull/5040

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

From stefank at openjdk.java.net  Sat Aug  7 06:44:30 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Sat, 7 Aug 2021 06:44:30 GMT
Subject: RFR: 8271939: Clean up primitive raw accessors in oopDesc [v2]
In-Reply-To: <ZcF14Wy5G2CcjB5_eDoh7dxPPJ_kadmUUSwIEjI1NKs=.c3d52805-f23d-4d06-90c4-291f3f951cf1@github.com>
References: <rPN6z0gQprVXkBVLa42lAJEI8QHTsAoGYHhF4mbUrDI=.c0d5479d-791f-49ff-9a0c-fab66f39b45c@github.com>
 <ZcF14Wy5G2CcjB5_eDoh7dxPPJ_kadmUUSwIEjI1NKs=.c3d52805-f23d-4d06-90c4-291f3f951cf1@github.com>
Message-ID: <QCiM6W68aTG4ziLfFxkfHSh0Q1zrXhgMNov9llHVMno=.919c46a9-e515-463b-9b3b-0ec259f10258@github.com>

On Fri, 6 Aug 2021 11:59:59 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We have some _raw accessors in oop.hpp and related code. Those are leftover from when Shenandoah required primitive barriers and are no longer needed. Their uses can be replaced with the regular accessors.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] hotspot_gc
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change loader_data_raw() to regular loader_data()

Marked as reviewed by stefank (Reviewer).

-------------

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

From kbarrett at openjdk.java.net  Mon Aug  9 04:29:32 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 9 Aug 2021 04:29:32 GMT
Subject: RFR: JDK-8272112: Arena code simplifications
In-Reply-To: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
References: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
Message-ID: <FfhT13_TsyGE-q87HZhdhpg9iogYjFe4DFrlPlDAlBM=.742315c1-1946-41ca-b540-699ec1e063f6@github.com>

On Sat, 7 Aug 2021 05:30:54 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> May I please have reviews for this small change. This is pure code cleanup, issues that were identified by code review when working on JDK-8270308. 
> 
> The patch results in less code (excluding the new gtest), bit easier to maintain. I have some smaller functional improvements in the pipeline and would like to get this code cleanup out of the way first.
> 
> Changes:
> 
> - Made `ChunkPool` an automatic object. We can remove `chunkpool_init()` and instead rely on automatic initialization.
> 
> - Instead of having four named pools that need to be handled individually and selected via awkward switch constructs (see the old `Chunk::operator new()` and `::operator delete()`), we replace it with an array and a static selector (`ChunkPool* get_pool_for_size(size_t size)`).
> 
> - Removed `ChunkPool::_num_used`. It was nowhere queried, and its usefulness was questionable since these numbers don't include chunks with "special" sizes. The easiest way to obtain the footprint of arena chunks is via NMT.
> 
> - Before, we had two places where the backing memory of Chunks was allocated: in `ChunkPool::allocate()` and in `Chunk::operator new()`. The former was unnecessary. I streamlined that: removed the ability to allocate from `ChunkPool::allocate()` and renamed it to `ChunkPool::remove_chunk()`. Now Chunks are only allocated in `Chunk::operator new() `and ChunkPool just serves as Chunk cache.
> 
> - Renamed `ChunkPool::free_all_but()` to `ChunkPool::prune()` and removed the argument, made it a method-local constant (it had been a constant before in the caller of that function).
> 
> - I added a new gtest to test Chunk allocation and pooling a little.
> 
> 
> Functionally, nothing should have changed with this patch, this is pure code grooming.
> 
> ----
> 
> Tests: 
> - GHA
> - I manually tested on 64-bit and 32-bit, with and without UseMallocOnly. I also manually checked that pool usage is as expected.

Mostly looks good.  One naming issue, and a couple of pre-existing things that could be cleaned up while we're here.

src/hotspot/share/memory/arena.cpp line 62:

> 60: 
> 61:   // Remove a chunk from the pool and return it; NULL if pool is empty.
> 62:   Chunk* remove_chunk() {

I think I prefer the old allocate/free nomenclature.  `remove_chunk` sounds like it should be discarding.  And `return_chunk` is confusing about "return".  I think allocate/free from a pool/free-list is well-understood naming.

src/hotspot/share/memory/arena.cpp line 92:

> 90:         // free chunks at end of queue, for better locality
> 91:         cur = _first;
> 92:         for (size_t i = 0; i < (blocksToKeep - 1) && cur != NULL; i++) {

[pre-existing] Unless there is a bug, `_num_chunks > blocksToKeep` implies `cur != NULL`.  Consider assert instead.

src/hotspot/share/memory/arena.cpp line 96:

> 94:         }
> 95: 
> 96:         if (cur != NULL) {

[pre-existing] This test shouldn't be needed because `_num_chunks > blocksToKeep`.

-------------

Changes requested by kbarrett (Reviewer).

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

From stuefe at openjdk.java.net  Mon Aug  9 04:48:31 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 9 Aug 2021 04:48:31 GMT
Subject: RFR: JDK-8272112: Arena code simplifications
In-Reply-To: <FfhT13_TsyGE-q87HZhdhpg9iogYjFe4DFrlPlDAlBM=.742315c1-1946-41ca-b540-699ec1e063f6@github.com>
References: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
 <FfhT13_TsyGE-q87HZhdhpg9iogYjFe4DFrlPlDAlBM=.742315c1-1946-41ca-b540-699ec1e063f6@github.com>
Message-ID: <vKsADy_Ffbxr77EFmoM0Snb7mRWk2LsxVfl6HdR-P48=.11b25dcc-c951-412d-b06e-ff7632f630b1@github.com>

On Mon, 9 Aug 2021 03:39:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> May I please have reviews for this small change. This is pure code cleanup, issues that were identified by code review when working on JDK-8270308. 
>> 
>> The patch results in less code (excluding the new gtest), bit easier to maintain. I have some smaller functional improvements in the pipeline and would like to get this code cleanup out of the way first.
>> 
>> Changes:
>> 
>> - Made `ChunkPool` an automatic object. We can remove `chunkpool_init()` and instead rely on automatic initialization.
>> 
>> - Instead of having four named pools that need to be handled individually and selected via awkward switch constructs (see the old `Chunk::operator new()` and `::operator delete()`), we replace it with an array and a static selector (`ChunkPool* get_pool_for_size(size_t size)`).
>> 
>> - Removed `ChunkPool::_num_used`. It was nowhere queried, and its usefulness was questionable since these numbers don't include chunks with "special" sizes. The easiest way to obtain the footprint of arena chunks is via NMT.
>> 
>> - Before, we had two places where the backing memory of Chunks was allocated: in `ChunkPool::allocate()` and in `Chunk::operator new()`. The former was unnecessary. I streamlined that: removed the ability to allocate from `ChunkPool::allocate()` and renamed it to `ChunkPool::remove_chunk()`. Now Chunks are only allocated in `Chunk::operator new() `and ChunkPool just serves as Chunk cache.
>> 
>> - Renamed `ChunkPool::free_all_but()` to `ChunkPool::prune()` and removed the argument, made it a method-local constant (it had been a constant before in the caller of that function).
>> 
>> - I added a new gtest to test Chunk allocation and pooling a little.
>> 
>> 
>> Functionally, nothing should have changed with this patch, this is pure code grooming.
>> 
>> ----
>> 
>> Tests: 
>> - GHA
>> - I manually tested on 64-bit and 32-bit, with and without UseMallocOnly. I also manually checked that pool usage is as expected.
>
> src/hotspot/share/memory/arena.cpp line 62:
> 
>> 60: 
>> 61:   // Remove a chunk from the pool and return it; NULL if pool is empty.
>> 62:   Chunk* remove_chunk() {
> 
> I think I prefer the old allocate/free nomenclature.  `remove_chunk` sounds like it should be discarding.  And `return_chunk` is confusing about "return".  I think allocate/free from a pool/free-list is well-understood naming.

I renamed ChunkPool::allocate() because it does not allocate anymore, it just stores existing chunks.

Is it just the naming, or do you also prefer that the old ChunkPool::allocate() actually allocated the Chunks (it called os::malloc)? I found that unnecessary for a pure cache and it duplicated the allocation code in Chunk::operator new().

-------------

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

From haosun at openjdk.java.net  Mon Aug  9 06:35:06 2021
From: haosun at openjdk.java.net (Hao Sun)
Date: Mon, 9 Aug 2021 06:35:06 GMT
Subject: RFR: 8271956: AArch64: C1 build failed after JDK-8270947
Message-ID: <FNUB2Hdjqawx7x3YURmDcTAD4BsjPVpbowOPZ1KrQ7Y=.cc8f9561-8a64-40b9-8e01-c2d74c950bb6@github.com>

C1 build failed on AArch64 with the following error message:

  src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:4642:30: error:
  invalid use of incomplete type 'class CompileTask'


Including the header would fix this error. Note that this header is
included already under COMPILER2 by "opto/compile.hpp".

-------------

Commit messages:
 - 8271956: AArch64: C1 build failed after JDK-8270947

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

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

From kbarrett at openjdk.java.net  Mon Aug  9 06:35:30 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 9 Aug 2021 06:35:30 GMT
Subject: RFR: JDK-8272112: Arena code simplifications
In-Reply-To: <vKsADy_Ffbxr77EFmoM0Snb7mRWk2LsxVfl6HdR-P48=.11b25dcc-c951-412d-b06e-ff7632f630b1@github.com>
References: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
 <FfhT13_TsyGE-q87HZhdhpg9iogYjFe4DFrlPlDAlBM=.742315c1-1946-41ca-b540-699ec1e063f6@github.com>
 <vKsADy_Ffbxr77EFmoM0Snb7mRWk2LsxVfl6HdR-P48=.11b25dcc-c951-412d-b06e-ff7632f630b1@github.com>
Message-ID: <gRr9XmahmJDUdOTqRISE9n1xRJtKxtYdl4Ijh2BJgkc=.e9ff1059-738b-4dea-aee4-bb4042824e61@github.com>

On Mon, 9 Aug 2021 04:45:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/memory/arena.cpp line 62:
>> 
>>> 60: 
>>> 61:   // Remove a chunk from the pool and return it; NULL if pool is empty.
>>> 62:   Chunk* remove_chunk() {
>> 
>> I think I prefer the old allocate/free nomenclature.  `remove_chunk` sounds like it should be discarding.  And `return_chunk` is confusing about "return".  I think allocate/free from a pool/free-list is well-understood naming.
>
> I renamed ChunkPool::allocate() because it does not allocate anymore, it just stores existing chunks.
> 
> Is it just the naming, or do you also prefer that the old ChunkPool::allocate() actually allocated the Chunks (it called os::malloc)? I found that unnecessary for a pure cache and it duplicated the allocation code in Chunk::operator new().

It's the names that I'm not a fan of.  The new implementation is good.  And it _is_ allocating, from a free-list.  I think it's pretty common for a free-list allocator design to have "failure" leave it to the client to decide what to do, rather than having the fallback built into the free-list allocator.

-------------

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

From stuefe at openjdk.java.net  Mon Aug  9 06:43:36 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 9 Aug 2021 06:43:36 GMT
Subject: RFR: JDK-8272112: Arena code simplifications
In-Reply-To: <gRr9XmahmJDUdOTqRISE9n1xRJtKxtYdl4Ijh2BJgkc=.e9ff1059-738b-4dea-aee4-bb4042824e61@github.com>
References: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
 <FfhT13_TsyGE-q87HZhdhpg9iogYjFe4DFrlPlDAlBM=.742315c1-1946-41ca-b540-699ec1e063f6@github.com>
 <vKsADy_Ffbxr77EFmoM0Snb7mRWk2LsxVfl6HdR-P48=.11b25dcc-c951-412d-b06e-ff7632f630b1@github.com>
 <gRr9XmahmJDUdOTqRISE9n1xRJtKxtYdl4Ijh2BJgkc=.e9ff1059-738b-4dea-aee4-bb4042824e61@github.com>
Message-ID: <-z5XyXEO0NRVaUlOV-o1ND32uUPvyL1fjtc6215fWuk=.1d323bff-4912-4755-9140-b6fc8dd077ee@github.com>

On Mon, 9 Aug 2021 06:32:19 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I renamed ChunkPool::allocate() because it does not allocate anymore, it just stores existing chunks.
>> 
>> Is it just the naming, or do you also prefer that the old ChunkPool::allocate() actually allocated the Chunks (it called os::malloc)? I found that unnecessary for a pure cache and it duplicated the allocation code in Chunk::operator new().
>
> It's the names that I'm not a fan of.  The new implementation is good.  And it _is_ allocating, from a free-list.  I think it's pretty common for a free-list allocator design to have "failure" leave it to the client to decide what to do, rather than having the fallback built into the free-list allocator.

Okay, I rename it back. Thanks for confirming!

-------------

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

From thartmann at openjdk.java.net  Mon Aug  9 06:44:32 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 9 Aug 2021 06:44:32 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail
In-Reply-To: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
Message-ID: <DYD7sF4BNnpVmd3bt0LR9gqrM1XQzW2t9tEWaYskTQY=.a297e547-46e9-4561-8a2f-0faee8863ec2@github.com>

On Thu, 29 Jul 2021 12:25:27 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> A test VM used by the IR framework sometimes prints `` in the middle of emitting a `PrintIdeal` or `PrintOptoAssembly` output which could lead to IR matching failures:
> https://github.com/openjdk/jdk/blob/489e5fd12a37a45f4f5ea64b05f85c6f99f70811/src/hotspot/share/utilities/ostream.cpp#L918-L927
> 
> I thought about just bailing out of IR matching if this string is found after a failure but this issue also affects internal framework tests (I observed one case locally where this happened in the test `TestIRMatching`, letting it fail).
> 
> Handling `` makes things more complicated for the IR framework tests. I'm not sure about the value of printing this message in the first place. But if nobody objects, I suggest to either remove it or at least guard it with `Verbose`, for example. I went with the latter solution in this PR.
> 
> Thanks,
> Christian

I would also go with option 1). For the framework internal tests that expect and exception, couldn't you simply add something like a `hitSafepointWhilePrinting()` method to `IRViolationException` that you can use to check if verification of the exception should be skipped?

-------------

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

From shade at openjdk.java.net  Mon Aug  9 06:46:34 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 9 Aug 2021 06:46:34 GMT
Subject: RFR: 8271956: AArch64: C1 build failed after JDK-8270947
In-Reply-To: <FNUB2Hdjqawx7x3YURmDcTAD4BsjPVpbowOPZ1KrQ7Y=.cc8f9561-8a64-40b9-8e01-c2d74c950bb6@github.com>
References: <FNUB2Hdjqawx7x3YURmDcTAD4BsjPVpbowOPZ1KrQ7Y=.cc8f9561-8a64-40b9-8e01-c2d74c950bb6@github.com>
Message-ID: <2xgBtMu4PXo5lfuWW42VaJbAKTv8nAao7JzwEOABlAQ=.15fa269d-6a09-4b3e-9448-3ecaa8aa2b94@github.com>

On Mon, 9 Aug 2021 06:28:35 GMT, Hao Sun <haosun at openjdk.org> wrote:

> C1 build failed on AArch64 with the following error message:
> 
>   src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:4642:30: error:
>   invalid use of incomplete type 'class CompileTask'
> 
> 
> Including the header would fix this error. Note that this header is
> included already under COMPILER2 by "opto/compile.hpp".

Looks fine and trivial.

-------------

Marked as reviewed by shade (Reviewer).

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

From njian at openjdk.java.net  Mon Aug  9 07:16:56 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Mon, 9 Aug 2021 07:16:56 GMT
Subject: RFR: 8267356: AArch64: Vector API SVE codegen support [v5]
In-Reply-To: <04_lDZDCcLLfXx6XmrbVdGXkPmqNrYzQuHBJzQ9Oa5k=.f3ef1398-c8b4-4162-9631-3dbfb6594250@github.com>
References: <04_lDZDCcLLfXx6XmrbVdGXkPmqNrYzQuHBJzQ9Oa5k=.f3ef1398-c8b4-4162-9631-3dbfb6594250@github.com>
Message-ID: <IYfxQPGD5M6uTAbdp17_rhqQBOro1aGR5So-dGlW-uQ=.249babc3-65b0-4008-843a-b0269c3c8cd9@github.com>

> This is the integration of current SVE work done in panama-vector/vectorIntrinscs, which includes:
> 
> 1. Code generation for Vector API c2 IR nodes with SVE.
> 2. Non-max vector size support with SVE, e.g. using *128Vector (and *64Vector) APIs on 256-bit SVE environment could also generate optimized SVE instructions with predicate feature.
> 3. Some more SVE assemblers (and tests) used by the codegen part.
> 
> Note: VectorMask<E\> is still represented in vector register, a further improvement to map mask to predicate register is under development at https://github.com/openjdk/panama-vector/tree/vectorIntrinsics+mask
> 
> 
> Test: tier1-3 with vector api test cases passed on 512-bit SVE hardware with MaxVectorSize=16/32/64.

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

  More comments from Andrew.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4122/files
  - new: https://git.openjdk.java.net/jdk/pull/4122/files/c444dc5a..43d7a5ee

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

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

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

From njian at openjdk.java.net  Mon Aug  9 07:16:58 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Mon, 9 Aug 2021 07:16:58 GMT
Subject: RFR: 8267356: AArch64: Vector API SVE codegen support [v4]
In-Reply-To: <bGW_m8ggB2GVLPuqut0GOw3I_ZfAvwB3BrrFvRTcTdE=.759104ee-08f4-4b36-9e2a-610773209832@github.com>
References: <04_lDZDCcLLfXx6XmrbVdGXkPmqNrYzQuHBJzQ9Oa5k=.f3ef1398-c8b4-4162-9631-3dbfb6594250@github.com>
 <zVMzpXKcRgj7PDQtvuIWFLaGosHDlJq4RvfzVmJQAOQ=.a1ffc678-bbd8-49e2-a9f9-a7d015b65e29@github.com>
 <bGW_m8ggB2GVLPuqut0GOw3I_ZfAvwB3BrrFvRTcTdE=.759104ee-08f4-4b36-9e2a-610773209832@github.com>
Message-ID: <nhofBOqQ19tCFJpFHBc2S_NvX634_9t4htpBhiGUliE=.953102b6-732f-4706-9b26-5cd7ab36133b@github.com>

On Tue, 3 Aug 2021 10:20:56 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing part
>
> src/hotspot/cpu/aarch64/assembler_aarch64.cpp line 70:
> 
>> 68: 
>> 69: Assembler::SIMD_Arrangement Assembler::esize2arrangement(unsigned esize, bool isQ) {
>> 70:   assert(esize < ARRAY_SIZE(_esize2arrangement_table) &&
> 
> Please consider making this a guarantee. The cost is minimal, and we've been saved by guarantees elsewhere in this file.

Done.

> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 957:
> 
>> 955:     case BoolTest::eq: condition = Assembler::EQ; break;
>> 956:     case BoolTest::ne: condition = Assembler::NE; break;
>> 957:     case BoolTest::le: z1 = zm; z2 = zn;  // Swap the two inputs
> 
> This might warn on some targets, so we'd need to fix it anyway, so please do it now. Better to duplicate the action and break.

Addressed in the new commit. Thanks!

-------------

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

From stuefe at openjdk.java.net  Mon Aug  9 08:15:03 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 9 Aug 2021 08:15:03 GMT
Subject: RFR: JDK-8272112: Arena code simplifications [v2]
In-Reply-To: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
References: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
Message-ID: <iVapRCmwRiVEae_Kg3vmOzaNbQqjxIj1Ho4GooeBJak=.db99c810-aa1b-41b0-b10a-caa8ea26511d@github.com>

> May I please have reviews for this small change. This is pure code cleanup, issues that were identified by code review when working on JDK-8270308. 
> 
> The patch results in less code (excluding the new gtest), bit easier to maintain. I have some smaller functional improvements in the pipeline and would like to get this code cleanup out of the way first.
> 
> Changes:
> 
> - Made `ChunkPool` an automatic object. We can remove `chunkpool_init()` and instead rely on automatic initialization.
> 
> - Instead of having four named pools that need to be handled individually and selected via awkward switch constructs (see the old `Chunk::operator new()` and `::operator delete()`), we replace it with an array and a static selector (`ChunkPool* get_pool_for_size(size_t size)`).
> 
> - Removed `ChunkPool::_num_used`. It was nowhere queried, and its usefulness was questionable since these numbers don't include chunks with "special" sizes. The easiest way to obtain the footprint of arena chunks is via NMT.
> 
> - Before, we had two places where the backing memory of Chunks was allocated: in `ChunkPool::allocate()` and in `Chunk::operator new()`. The former was unnecessary. I streamlined that: removed the ability to allocate from `ChunkPool::allocate()` and renamed it to `ChunkPool::remove_chunk()`. Now Chunks are only allocated in `Chunk::operator new() `and ChunkPool just serves as Chunk cache.
> 
> - Renamed `ChunkPool::free_all_but()` to `ChunkPool::prune()` and removed the argument, made it a method-local constant (it had been a constant before in the caller of that function).
> 
> - I added a new gtest to test Chunk allocation and pooling a little.
> 
> 
> Functionally, nothing should have changed with this patch, this is pure code grooming.
> 
> ----
> 
> Tests: 
> - GHA
> - I manually tested on 64-bit and 32-bit, with and without UseMallocOnly. I also manually checked that pool usage is as expected.

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

  feedback kim

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5040/files
  - new: https://git.openjdk.java.net/jdk/pull/5040/files/fb438c86..625df135

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

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

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

From stuefe at openjdk.java.net  Mon Aug  9 08:17:34 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 9 Aug 2021 08:17:34 GMT
Subject: RFR: JDK-8272112: Arena code simplifications
In-Reply-To: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
References: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
Message-ID: <WCa3SO6j-YtE77NeMWb64X_lDNKli2sGQ3VaU79EJu8=.1e399338-c5ce-43e2-8854-0e669d772b6c@github.com>

On Sat, 7 Aug 2021 05:30:54 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> May I please have reviews for this small change. This is pure code cleanup, issues that were identified by code review when working on JDK-8270308. 
> 
> The patch results in less code (excluding the new gtest), bit easier to maintain. I have some smaller functional improvements in the pipeline and would like to get this code cleanup out of the way first.
> 
> Changes:
> 
> - Made `ChunkPool` an automatic object. We can remove `chunkpool_init()` and instead rely on automatic initialization.
> 
> - Instead of having four named pools that need to be handled individually and selected via awkward switch constructs (see the old `Chunk::operator new()` and `::operator delete()`), we replace it with an array and a static selector (`ChunkPool* get_pool_for_size(size_t size)`).
> 
> - Removed `ChunkPool::_num_used`. It was nowhere queried, and its usefulness was questionable since these numbers don't include chunks with "special" sizes. The easiest way to obtain the footprint of arena chunks is via NMT.
> 
> - Before, we had two places where the backing memory of Chunks was allocated: in `ChunkPool::allocate()` and in `Chunk::operator new()`. The former was unnecessary. I streamlined that: removed the ability to allocate from `ChunkPool::allocate()` and renamed it to `ChunkPool::remove_chunk()`. Now Chunks are only allocated in `Chunk::operator new() `and ChunkPool just serves as Chunk cache.
> 
> - Renamed `ChunkPool::free_all_but()` to `ChunkPool::prune()` and removed the argument, made it a method-local constant (it had been a constant before in the caller of that function).
> 
> - I added a new gtest to test Chunk allocation and pooling a little.
> 
> 
> Functionally, nothing should have changed with this patch, this is pure code grooming.
> 
> ----
> 
> Tests: 
> - GHA
> - I manually tested on 64-bit and 32-bit, with and without UseMallocOnly. I also manually checked that pool usage is as expected.

Hi Kim, I addressed your requests with the last commit.

Small remarks:

- `ChunkPool::prune()` will not work with `blocksToKeep=0` (never did). I guess that is okay.

- the pattern "delete chunk and follow-ups" repeats in `Chunk::chop()`. I thought about reusing it in `ChunkPool::prune()` but `Chunk::chop()` sits above the chunk pool and we would have circularities. I then realized that semantically they are different: `Chunk::chop()` prunes an Arena, while `ChunkPool::prune()` prunes the chunk pool below. So I guess it makes sense to have them both.

- I thought about factoring out "free chunk and followers" as a new `ChunkPool::free_list()` from `ChunkPool::prune()` because strictly speaking we should do this also at destruction. But the only instances of `ChunkPool` are globals, and there is no need to spend time on cleanup when the VM exits. Is there a pattern somehow to mark a class as "its okay to leak resources since we only use this class as static globals"?

- The actual allocation of backing memory for chunks is spread over various places (`Chunk::operator new()`, `Chunk::operator delete()`, `ChunkPool::prune()`). I wondered if for clarity we should factor them out into clearly marked functions. I did not do that to keep the patch small.

-------------

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

From kbarrett at openjdk.java.net  Mon Aug  9 08:36:35 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 9 Aug 2021 08:36:35 GMT
Subject: RFR: JDK-8272112: Arena code simplifications [v2]
In-Reply-To: <iVapRCmwRiVEae_Kg3vmOzaNbQqjxIj1Ho4GooeBJak=.db99c810-aa1b-41b0-b10a-caa8ea26511d@github.com>
References: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
 <iVapRCmwRiVEae_Kg3vmOzaNbQqjxIj1Ho4GooeBJak=.db99c810-aa1b-41b0-b10a-caa8ea26511d@github.com>
Message-ID: <G_LeCOjvCvT0Joa4h3wGqXvjBiqmKEVzNEeHFx5Jm94=.f8744735-9d5b-4849-af92-d4461891e0ff@github.com>

On Mon, 9 Aug 2021 08:15:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> May I please have reviews for this small change. This is pure code cleanup, issues that were identified by code review when working on JDK-8270308. 
>> 
>> The patch results in less code (excluding the new gtest), bit easier to maintain. I have some smaller functional improvements in the pipeline and would like to get this code cleanup out of the way first.
>> 
>> Changes:
>> 
>> - Made `ChunkPool` an automatic object. We can remove `chunkpool_init()` and instead rely on automatic initialization.
>> 
>> - Instead of having four named pools that need to be handled individually and selected via awkward switch constructs (see the old `Chunk::operator new()` and `::operator delete()`), we replace it with an array and a static selector (`ChunkPool* get_pool_for_size(size_t size)`).
>> 
>> - Removed `ChunkPool::_num_used`. It was nowhere queried, and its usefulness was questionable since these numbers don't include chunks with "special" sizes. The easiest way to obtain the footprint of arena chunks is via NMT.
>> 
>> - Before, we had two places where the backing memory of Chunks was allocated: in `ChunkPool::allocate()` and in `Chunk::operator new()`. The former was unnecessary. I streamlined that: removed the ability to allocate from `ChunkPool::allocate()` and renamed it to `ChunkPool::remove_chunk()`. Now Chunks are only allocated in `Chunk::operator new() `and ChunkPool just serves as Chunk cache.
>> 
>> - Renamed `ChunkPool::free_all_but()` to `ChunkPool::prune()` and removed the argument, made it a method-local constant (it had been a constant before in the caller of that function).
>> 
>> - I added a new gtest to test Chunk allocation and pooling a little.
>> 
>> 
>> Functionally, nothing should have changed with this patch, this is pure code grooming.
>> 
>> ----
>> 
>> Tests: 
>> - GHA
>> - I manually tested on 64-bit and 32-bit, with and without UseMallocOnly. I also manually checked that pool usage is as expected.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback kim

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

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

From kbarrett at openjdk.java.net  Mon Aug  9 08:40:35 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 9 Aug 2021 08:40:35 GMT
Subject: RFR: JDK-8272112: Arena code simplifications
In-Reply-To: <WCa3SO6j-YtE77NeMWb64X_lDNKli2sGQ3VaU79EJu8=.1e399338-c5ce-43e2-8854-0e669d772b6c@github.com>
References: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
 <WCa3SO6j-YtE77NeMWb64X_lDNKli2sGQ3VaU79EJu8=.1e399338-c5ce-43e2-8854-0e669d772b6c@github.com>
Message-ID: <kWRVX-cmUexWVJthbjDCuBmIfUN7ves32LbhhZB-hPU=.fca7e89d-13c9-44a4-9a31-bbdbc41bedd3@github.com>

On Mon, 9 Aug 2021 08:14:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>     * `ChunkPool::prune()` will not work with `blocksToKeep=0` (never did). I guess that is okay.

Yeah, that seems fine now that it's a constant.  If you want to be paranoid and add a comment or even a static_assert, that would be fine with me, but not necessary.

>     * I thought about factoring out "free chunk and followers" as a new `ChunkPool::free_list()` from `ChunkPool::prune()` because strictly speaking we should do this also at destruction. But the only instances of `ChunkPool` are globals, and there is no need to spend time on cleanup when the VM exits. Is there a pattern somehow to mark a class as "its okay to leak resources since we only use this class as static globals"?

I don't know of any idiom in HotSpot for tagging such places.  Add a comment if you feel the need to do so?

>     * The actual allocation of backing memory for chunks is spread over various places (`Chunk::operator new()`, `Chunk::operator delete()`, `ChunkPool::prune()`). I wondered if for clarity we should factor them out into clearly marked functions. I did not do that to keep the patch small.

It's not obvious that's worth the extra work.  It seems fine as is to me.

-------------

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

From sundar at openjdk.java.net  Mon Aug  9 08:42:34 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Mon, 9 Aug 2021 08:42:34 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v4]
In-Reply-To: <A6jfsBBrXc-gXmDe_Ag4Io7k4ZSy4JGkw70JSPxjn7Y=.f71cad65-578f-4764-822b-113e61a6d55a@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <A6jfsBBrXc-gXmDe_Ag4Io7k4ZSy4JGkw70JSPxjn7Y=.f71cad65-578f-4764-822b-113e61a6d55a@github.com>
Message-ID: <a00dy1Q8-Z6hwgNt5SkXXd9D5Di8t_Y4HzfotjLH0DI=.37a99555-166d-4852-9ee3-69a9051a79e7@github.com>

On Fri, 6 Aug 2021 18:42:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
>> 
>> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Create new exception during initialization saving, so only need to save an oop. (Could potentially move to Doug's secret Class location.  If the exception is not bootstrap exception, throw EIIE instead with message of original exception.

src/hotspot/share/classfile/javaClasses.cpp line 2685:

> 2683:   assert(stack_trace->is_objArray(), "Should be an array");
> 2684: 
> 2685:   // If the original exception was in java.base, then use that otherwise use

comment is about one specific bootstrap module (java.base) but the check is for bootstrap loader.

-------------

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

From stuefe at openjdk.java.net  Mon Aug  9 08:46:30 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 9 Aug 2021 08:46:30 GMT
Subject: RFR: JDK-8272112: Arena code simplifications [v2]
In-Reply-To: <G_LeCOjvCvT0Joa4h3wGqXvjBiqmKEVzNEeHFx5Jm94=.f8744735-9d5b-4849-af92-d4461891e0ff@github.com>
References: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
 <iVapRCmwRiVEae_Kg3vmOzaNbQqjxIj1Ho4GooeBJak=.db99c810-aa1b-41b0-b10a-caa8ea26511d@github.com>
 <G_LeCOjvCvT0Joa4h3wGqXvjBiqmKEVzNEeHFx5Jm94=.f8744735-9d5b-4849-af92-d4461891e0ff@github.com>
Message-ID: <QUq-Ju07t2otENrPzqGIdIH9AsKGgKwj8410-2O3IJ8=.b603c918-7f2f-40fa-8f6a-c0f8d53c753c@github.com>

On Mon, 9 Aug 2021 08:33:04 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Looks good.

Thanks Kim.

-------------

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

From tschatzl at openjdk.java.net  Mon Aug  9 09:01:35 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 9 Aug 2021 09:01:35 GMT
Subject: RFR: 8271939: Clean up primitive raw accessors in oopDesc [v2]
In-Reply-To: <ZcF14Wy5G2CcjB5_eDoh7dxPPJ_kadmUUSwIEjI1NKs=.c3d52805-f23d-4d06-90c4-291f3f951cf1@github.com>
References: <rPN6z0gQprVXkBVLa42lAJEI8QHTsAoGYHhF4mbUrDI=.c0d5479d-791f-49ff-9a0c-fab66f39b45c@github.com>
 <ZcF14Wy5G2CcjB5_eDoh7dxPPJ_kadmUUSwIEjI1NKs=.c3d52805-f23d-4d06-90c4-291f3f951cf1@github.com>
Message-ID: <SW203jzl4E0XihAoIqTbLoPCw5w3p5Lf_6XXmESsxcc=.c7415e47-acc5-43cc-944d-08f3aed46063@github.com>

On Fri, 6 Aug 2021 11:59:59 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We have some _raw accessors in oop.hpp and related code. Those are leftover from when Shenandoah required primitive barriers and are no longer needed. Their uses can be replaced with the regular accessors.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] hotspot_gc
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change loader_data_raw() to regular loader_data()

Marked as reviewed by tschatzl (Reviewer).

-------------

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

From ngasson at openjdk.java.net  Mon Aug  9 09:33:31 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 9 Aug 2021 09:33:31 GMT
Subject: RFR: 8271956: AArch64: C1 build failed after JDK-8270947
In-Reply-To: <FNUB2Hdjqawx7x3YURmDcTAD4BsjPVpbowOPZ1KrQ7Y=.cc8f9561-8a64-40b9-8e01-c2d74c950bb6@github.com>
References: <FNUB2Hdjqawx7x3YURmDcTAD4BsjPVpbowOPZ1KrQ7Y=.cc8f9561-8a64-40b9-8e01-c2d74c950bb6@github.com>
Message-ID: <eoqDfz_AIWYaj59Yg_XbOewQhf9AqydMcOdADC3d8nI=.812e2f6b-d27f-49c5-afdc-f6b14ca968a5@github.com>

On Mon, 9 Aug 2021 06:28:35 GMT, Hao Sun <haosun at openjdk.org> wrote:

> C1 build failed on AArch64 with the following error message:
> 
>   src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:4642:30: error:
>   invalid use of incomplete type 'class CompileTask'
> 
> 
> Including the header would fix this error. Note that this header is
> included already under COMPILER2 by "opto/compile.hpp".

Marked as reviewed by ngasson (Reviewer).

-------------

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

From haosun at openjdk.java.net  Mon Aug  9 09:36:35 2021
From: haosun at openjdk.java.net (Hao Sun)
Date: Mon, 9 Aug 2021 09:36:35 GMT
Subject: RFR: 8271956: AArch64: C1 build failed after JDK-8270947
In-Reply-To: <2xgBtMu4PXo5lfuWW42VaJbAKTv8nAao7JzwEOABlAQ=.15fa269d-6a09-4b3e-9448-3ecaa8aa2b94@github.com>
References: <FNUB2Hdjqawx7x3YURmDcTAD4BsjPVpbowOPZ1KrQ7Y=.cc8f9561-8a64-40b9-8e01-c2d74c950bb6@github.com>
 <2xgBtMu4PXo5lfuWW42VaJbAKTv8nAao7JzwEOABlAQ=.15fa269d-6a09-4b3e-9448-3ecaa8aa2b94@github.com>
Message-ID: <IigRDOlRopbl9N4S_5tWJVQi9aXZjyNoWSH5roiw100=.83ab85a6-a5ff-4421-a185-c8cb493ed67f@github.com>

On Mon, 9 Aug 2021 06:43:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> C1 build failed on AArch64 with the following error message:
>> 
>>   src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:4642:30: error:
>>   invalid use of incomplete type 'class CompileTask'
>> 
>> 
>> Including the header would fix this error. Note that this header is
>> included already under COMPILER2 by "opto/compile.hpp".
>
> Looks fine and trivial.

Thanks for your review. @shipilev  and @nick-arm 
Since all the pre-submit tests pass with this trivial patch, I suppose it is ready to be merged now.

-------------

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

From ngasson at openjdk.java.net  Mon Aug  9 09:38:30 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 9 Aug 2021 09:38:30 GMT
Subject: RFR: 8271869: AArch64: build errors with GCC11 in
 frame::saved_oop_result
In-Reply-To: <-H4Ipq5xE61C6-xDj1vD-_gdEZYQdIeXcAMl0ASu5Rs=.2378487e-0c95-4bf8-a6ee-671dfaef1c00@github.com>
References: <-H4Ipq5xE61C6-xDj1vD-_gdEZYQdIeXcAMl0ASu5Rs=.2378487e-0c95-4bf8-a6ee-671dfaef1c00@github.com>
Message-ID: <PXxZWKqqizXxl_muNqrhKSrrRWG4cLLee9GvCT4_Yfk=.e280317b-f7f5-48b9-9d1f-9cfdabeb555c@github.com>

On Thu, 5 Aug 2021 14:14:38 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> GCC11 warns that r0 is null. It does not complain if r1 is used instead.
> 
> AIUI, it is undefined behaviour in C++ to call member functions without
> a valid this pointer. So, technically GCC is correct to warn.

This looks ok to me as it's the same workaround as JDK-8270083 but @kimbarrett probably ought check it too.

-------------

Marked as reviewed by ngasson (Reviewer).

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

From haosun at openjdk.java.net  Mon Aug  9 09:42:35 2021
From: haosun at openjdk.java.net (Hao Sun)
Date: Mon, 9 Aug 2021 09:42:35 GMT
Subject: Integrated: 8271956: AArch64: C1 build failed after JDK-8270947
In-Reply-To: <FNUB2Hdjqawx7x3YURmDcTAD4BsjPVpbowOPZ1KrQ7Y=.cc8f9561-8a64-40b9-8e01-c2d74c950bb6@github.com>
References: <FNUB2Hdjqawx7x3YURmDcTAD4BsjPVpbowOPZ1KrQ7Y=.cc8f9561-8a64-40b9-8e01-c2d74c950bb6@github.com>
Message-ID: <gzUhwnAAMR8WkybPeSuIEbuwU5qcwdG3F0OusFPRNTY=.4790139d-b592-4441-b5fc-6a2704b0942c@github.com>

On Mon, 9 Aug 2021 06:28:35 GMT, Hao Sun <haosun at openjdk.org> wrote:

> C1 build failed on AArch64 with the following error message:
> 
>   src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:4642:30: error:
>   invalid use of incomplete type 'class CompileTask'
> 
> 
> Including the header would fix this error. Note that this header is
> included already under COMPILER2 by "opto/compile.hpp".

This pull request has now been integrated.

Changeset: b84a9c7b
Author:    Hao Sun <haosun at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b84a9c7b377282bd9b3d9ac78707f0c12f8dc53d
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8271956: AArch64: C1 build failed after JDK-8270947

Reviewed-by: shade, ngasson

-------------

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

From rkennke at openjdk.java.net  Mon Aug  9 10:35:35 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 9 Aug 2021 10:35:35 GMT
Subject: Integrated: 8271939: Clean up primitive raw accessors in oopDesc
In-Reply-To: <rPN6z0gQprVXkBVLa42lAJEI8QHTsAoGYHhF4mbUrDI=.c0d5479d-791f-49ff-9a0c-fab66f39b45c@github.com>
References: <rPN6z0gQprVXkBVLa42lAJEI8QHTsAoGYHhF4mbUrDI=.c0d5479d-791f-49ff-9a0c-fab66f39b45c@github.com>
Message-ID: <E95yaDK_OfqJSGM_gZ2lx03ZUGEh4oEPUtOwBTxLSRY=.3944e754-f113-4b83-b9f9-3de649e2d9ae@github.com>

On Thu, 5 Aug 2021 11:20:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We have some _raw accessors in oop.hpp and related code. Those are leftover from when Shenandoah required primitive barriers and are no longer needed. Their uses can be replaced with the regular accessors.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [x] hotspot_gc

This pull request has now been integrated.

Changeset: a86ac0d1
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a86ac0d1e3a6f02e587362c767abdf62b308d321
Stats:     43 lines in 10 files changed: 0 ins; 30 del; 13 mod

8271939: Clean up primitive raw accessors in oopDesc

Reviewed-by: stefank, tschatzl

-------------

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

From dholmes at openjdk.java.net  Mon Aug  9 12:18:32 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 9 Aug 2021 12:18:32 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely [v3]
In-Reply-To: <OqVdBBg5ponJncrQ2O-w_Uqsl77LoDNkNIWqTe2Uv8o=.eb99d722-d179-4e72-a825-b7133b5207c4@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
 <OqVdBBg5ponJncrQ2O-w_Uqsl77LoDNkNIWqTe2Uv8o=.eb99d722-d179-4e72-a825-b7133b5207c4@github.com>
Message-ID: <N6GETVo2Bpen9YyD3VHPTIMcuqqD6rxRFk5brhAjm0M=.23740d23-486b-475c-89d2-59480bd92f16@github.com>

On Fri, 6 Aug 2021 05:22:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this fix to shutdown cleanly any JVMs created by gtests that aren't aborted.
>> 
>> Testing:
>>   - manual instrumentation to check all JVM construction and then deletion during gtest runs
>>   - local gtest testing
>>   - tiers 1-3 gtest testing
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed superfluous blank

Could I get a second review please.

Thanks.

-------------

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

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: <fpCO3gUF8wIMpbApI2_r_59IKqYaMLvK3EswyU0skRc=.bc9fb87b-588e-439d-91de-701df1e51b61@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <fpCO3gUF8wIMpbApI2_r_59IKqYaMLvK3EswyU0skRc=.bc9fb87b-588e-439d-91de-701df1e51b61@github.com>
Message-ID: <pQGmwcPgV3EFyUg348LCL6MI6c44ELEf0J81K_807NE=.cd6b8914-6ed7-4ad1-8085-4bd0a6ee2e22@github.com>

On Thu, 5 Aug 2021 11:21:59 GMT, Matthias Baesken <mbaesken at openjdk.org> 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 aph at openjdk.java.net  Mon Aug  9 13:05:36 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 9 Aug 2021 13:05:36 GMT
Subject: RFR: 8271869: AArch64: build errors with GCC11 in
 frame::saved_oop_result
In-Reply-To: <-H4Ipq5xE61C6-xDj1vD-_gdEZYQdIeXcAMl0ASu5Rs=.2378487e-0c95-4bf8-a6ee-671dfaef1c00@github.com>
References: <-H4Ipq5xE61C6-xDj1vD-_gdEZYQdIeXcAMl0ASu5Rs=.2378487e-0c95-4bf8-a6ee-671dfaef1c00@github.com>
Message-ID: <ryk2VUOpwITNMoM5f9ZmTQSn_IIu7brtkSGvzSVsMes=.96f663f7-9a2e-4e22-b665-ef2d568fd584@github.com>

On Thu, 5 Aug 2021 14:14:38 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> GCC11 warns that r0 is null. It does not complain if r1 is used instead.
> 
> AIUI, it is undefined behaviour in C++ to call member functions without
> a valid this pointer. So, technically GCC is correct to warn.

Marked as reviewed by aph (Reviewer).

-------------

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

From mgkwill at openjdk.java.net  Mon Aug  9 15:32:56 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Mon, 9 Aug 2021 15:32:56 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v3]
In-Reply-To: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
Message-ID: <baypzqw0UnSeIlYsngEsn6IEIJsFb1ISDJABqa30fnQ=.1f79ed6b-3eea-4a0d-9d8d-32ef60ae0a16@github.com>

> Intrinsic for Math.copySign is disabled on x86_64.
> 
> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
> 
> ### **Math.copySign(double)**
> _From:_
>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>   0x00007f7d606e5dc0:   and    %r8,%r11
>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>   0x00007f7d606e5dcd:   and    %r8,%r10
>   0x00007f7d606e5dd0:   or     %r11,%r10
>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
> 
> _To:_
>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
> 
> ### **Math.copySign(float)**
> _From:_
>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>   0x00007ff8886e60c4:   or     %r10d,%r11d
>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
> _To:_
>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
> 
> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
> #### **BEFORE**
> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
> 
> #### **PATCH**
> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
> 
> #### **JTREG that covers this case:**
> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
> 
> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:

  review updates
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5005/files
  - new: https://git.openjdk.java.net/jdk/pull/5005/files/68eb2bc4..1cb2e53b

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

  Stats: 42 lines in 1 file changed: 28 ins; 9 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5005.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5005/head:pull/5005

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

From mgkwill at openjdk.java.net  Mon Aug  9 15:37:56 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Mon, 9 Aug 2021 15:37:56 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v4]
In-Reply-To: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
Message-ID: <S6hZU5JhBqraE35JIhd9HQerieeln6KHKnzPEpd_lYg=.919c60cc-69eb-4406-aa6f-710bc8d3cee7@github.com>

> Intrinsic for Math.copySign is disabled on x86_64.
> 
> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
> 
> ### **Math.copySign(double)**
> _From:_
>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>   0x00007f7d606e5dc0:   and    %r8,%r11
>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>   0x00007f7d606e5dcd:   and    %r8,%r10
>   0x00007f7d606e5dd0:   or     %r11,%r10
>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
> 
> _To:_
>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
> 
> ### **Math.copySign(float)**
> _From:_
>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>   0x00007ff8886e60c4:   or     %r10d,%r11d
>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
> _To:_
>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
> 
> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
> #### **BEFORE**
> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
> 
> #### **PATCH**
> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
> 
> #### **JTREG that covers this case:**
> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
> 
> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:

  Add not is_LP64 to match case
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5005/files
  - new: https://git.openjdk.java.net/jdk/pull/5005/files/1cb2e53b..9d085e9a

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

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

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

From mgkwill at openjdk.java.net  Mon Aug  9 15:40:59 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Mon, 9 Aug 2021 15:40:59 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v5]
In-Reply-To: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
Message-ID: <CqJMaaQ2ZWaURyfV2WLJg90KA_uf-Stl9cBCxZuctNU=.acddaa5f-790a-4e6e-85dc-9f0e5eb12282@github.com>

> Intrinsic for Math.copySign is disabled on x86_64.
> 
> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
> 
> ### **Math.copySign(double)**
> _From:_
>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>   0x00007f7d606e5dc0:   and    %r8,%r11
>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>   0x00007f7d606e5dcd:   and    %r8,%r10
>   0x00007f7d606e5dd0:   or     %r11,%r10
>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
> 
> _To:_
>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
> 
> ### **Math.copySign(float)**
> _From:_
>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>   0x00007ff8886e60c4:   or     %r10d,%r11d
>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
> _To:_
>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
> 
> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
> #### **BEFORE**
> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
> 
> #### **PATCH**
> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
> 
> #### **JTREG that covers this case:**
> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
> 
> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:

  Remove predicates
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5005/files
  - new: https://git.openjdk.java.net/jdk/pull/5005/files/9d085e9a..2764fa6b

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

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

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

From svkamath at openjdk.java.net  Mon Aug  9 15:49:07 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Mon, 9 Aug 2021 15:49:07 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v8]
In-Reply-To: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
Message-ID: <VWASAkdLb9zt1v6xhyLwTVzM2B3-et1JN1njFlRTy5E=.1a3700ff-5bad-4838-bb53-83b8a3fcf644@github.com>

> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
> Performance gain of ~1.5x - 2x for message sizes 8k and above.

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

  rewiew update

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4019/files
  - new: https://git.openjdk.java.net/jdk/pull/4019/files/69145008..ecf8e6d7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=06-07

  Stats: 29 lines in 1 file changed: 12 ins; 5 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4019.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4019/head:pull/4019

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

From iklam at openjdk.java.net  Mon Aug  9 15:53:38 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 9 Aug 2021 15:53:38 GMT
Subject: RFR: 8271525: ResourceHashtableBase::iterate() should not
 declared as const
In-Reply-To: <XZWBVU0L6HC-w0CDFcy8h_2fk6zuMOxN6IIWAB9YS9A=.810fdae5-2127-437a-9b0a-1cb79c703289@github.com>
References: <XZWBVU0L6HC-w0CDFcy8h_2fk6zuMOxN6IIWAB9YS9A=.810fdae5-2127-437a-9b0a-1cb79c703289@github.com>
Message-ID: <yAnVgQVHgPITfFbKZkGZOajkP4UuJ3sf6YvEHqEf0BY=.3157768c-efc7-4537-a809-41aa2faad512@github.com>

On Fri, 30 Jul 2021 04:16:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> `ResourceHashtableBase::iterate()` is declared `const`, but it can actually change the contents of the table. The same is true for `ResourceHashtableBase::get()`, which returns a non-`const` pointer to the value, allowing the caller to modify it.
> 
> We should declare these two functions as non-`const`. This will also remove a lot of ugly `const_cast<>` code.
> 
> The `iterate()` API is tightened such that the `do_entry()` function can modify the `value` but not the `key`.

I am withdrawing this PR and think about a better approach.

-------------

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

From iklam at openjdk.java.net  Mon Aug  9 15:53:38 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 9 Aug 2021 15:53:38 GMT
Subject: Withdrawn: 8271525: ResourceHashtableBase::iterate() should not
 declared as const
In-Reply-To: <XZWBVU0L6HC-w0CDFcy8h_2fk6zuMOxN6IIWAB9YS9A=.810fdae5-2127-437a-9b0a-1cb79c703289@github.com>
References: <XZWBVU0L6HC-w0CDFcy8h_2fk6zuMOxN6IIWAB9YS9A=.810fdae5-2127-437a-9b0a-1cb79c703289@github.com>
Message-ID: <3nj2sYYGM7xa-w4FcgtkVYDwHv11wYLWeYRMvwF57gA=.a15b439d-58c3-4b81-bb75-b939e947da8e@github.com>

On Fri, 30 Jul 2021 04:16:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> `ResourceHashtableBase::iterate()` is declared `const`, but it can actually change the contents of the table. The same is true for `ResourceHashtableBase::get()`, which returns a non-`const` pointer to the value, allowing the caller to modify it.
> 
> We should declare these two functions as non-`const`. This will also remove a lot of ugly `const_cast<>` code.
> 
> The `iterate()` API is tightened such that the `do_entry()` function can modify the `value` but not the `key`.

This pull request has been closed without being integrated.

-------------

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

From dcubed at openjdk.java.net  Mon Aug  9 16:11:31 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 9 Aug 2021 16:11:31 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely [v3]
In-Reply-To: <OqVdBBg5ponJncrQ2O-w_Uqsl77LoDNkNIWqTe2Uv8o=.eb99d722-d179-4e72-a825-b7133b5207c4@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
 <OqVdBBg5ponJncrQ2O-w_Uqsl77LoDNkNIWqTe2Uv8o=.eb99d722-d179-4e72-a825-b7133b5207c4@github.com>
Message-ID: <kJq2F4xKK1K9q_qj2lwUT9_pPW3X7xsvimgi8QzMqFw=.9daf7ad2-17f3-4918-9eb8-a59af96c22d2@github.com>

On Fri, 6 Aug 2021 05:22:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this fix to shutdown cleanly any JVMs created by gtests that aren't aborted.
>> 
>> Testing:
>>   - manual instrumentation to check all JVM construction and then deletion during gtest runs
>>   - local gtest testing
>>   - tiers 1-3 gtest testing
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed superfluous blank

Thumbs up.

-------------

Marked as reviewed by dcubed (Reviewer).

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

From valeriep at openjdk.java.net  Mon Aug  9 17:17:44 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 9 Aug 2021 17:17:44 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <C7QhlB_cLX1eW-KtzvMC3a1zRzvusBRVi7W-04xE3Ss=.52db0426-86e7-4f40-a10d-2616d0032853@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
 <zgp6RY8EMQFaGxyvaDFIQlhIKnrpuxmRfu_FsAL7-yk=.c0b6e553-5915-4f6a-ae32-976b26165cd3@github.com>
 <C7QhlB_cLX1eW-KtzvMC3a1zRzvusBRVi7W-04xE3Ss=.52db0426-86e7-4f40-a10d-2616d0032853@github.com>
Message-ID: <HyQOGkL5LnsMIpgqJYrHI3QfqkI_ubw0bSYs6_QL438=.29a7eee0-619b-44d1-b09d-6a0b12082300@github.com>

On Fri, 6 Aug 2021 19:53:28 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 87:
>> 
>>> 85:     private static final int MAX_BUF_SIZE = Integer.MAX_VALUE;
>>> 86:     // data size when buffer is divided up to aid in intrinsics
>>> 87:     private static final int TRIGGERLEN = 65536;  // 64k
>> 
>> With this interleaved impl, is this TRIGGERLEN still needed? The implGCMCrypt(byte[] in, int inOfs, int inLen,
>>         byte[] ct, int ctOfs, byte[] out, int outOfs, GCTR gctr, GHASH ghash) method is intrinsified, would there be a difference in increasing the number of gctr/ghash calls inside an already intrinsified method?
>
> Yes, they are two different intrinsics.  The new implGCMCrypt intrinsic is supported by newer processors so there is no guarantee that implGCMCrypt will run the intrinsic.

Hmm, ok. Thanks for the explanation.

-------------

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

From valeriep at openjdk.java.net  Mon Aug  9 17:21:38 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 9 Aug 2021 17:21:38 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <oXflpZYqIOAYE5h2NicmMtpPIuPuTUMNXj_DrWvQ_rU=.f23ed00c-b757-4bb0-b837-c49a07f5f522@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
 <a2FZLCfubSMaeZe3bnSj2rL7_Guh4FkiZqDSvUu0EgE=.9852a252-2715-4ce5-b5f2-75178fc1e2f7@github.com>
 <oXflpZYqIOAYE5h2NicmMtpPIuPuTUMNXj_DrWvQ_rU=.f23ed00c-b757-4bb0-b837-c49a07f5f522@github.com>
Message-ID: <TK7tPbvT_pwmbqHyr-Uj31ubG3M36BuAWoMpumUiAMs=.ed40a816-f842-4b76-8590-ad94e52e122c@github.com>

On Fri, 6 Aug 2021 20:37:22 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1120:
>> 
>>> 1118:                 inOfs += r;
>>> 1119:                 inLen -= r;
>>> 1120:             }
>> 
>> Have you considered move the "if (inLen >= PARALLEL_LEN) block" into EncryptOp.update() impl (just like the Encrypt.doFinal() impl) ? Even though not all op.update() calls process large data, but it'd reduce code duplication and ensures that all large data processed by EncryptOp.update() calls would call the intrinsified method.
>
> There are cases where inLen is known to be smaller than PARALLEL_LEN and is a waste of a check, such as merging with the ibuffer to create one block.  Also moving it into EncryptOp would always mean an additional check and maybe an unnecessary jump to another method.
> 
> I did that for doFinal, because gctr/ghash.doFinal() needs to was no extra checks.

Alright, as long as you did consider that.

-------------

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

From coleenp at openjdk.java.net  Mon Aug  9 17:29:09 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 9 Aug 2021 17:29:09 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v5]
In-Reply-To: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
Message-ID: <Vevmz9N508RUXV13xjraE5lj4OU831p-fxT5lvt3xPs=.5d8a0569-5073-4a64-b821-d6e8fd354c30@github.com>

> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
> 
> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).

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

  Fix java.base/bootstrap class loader comment.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4996/files
  - new: https://git.openjdk.java.net/jdk/pull/4996/files/56ff30a1..e7084b83

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

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

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

From sviswanathan at openjdk.java.net  Mon Aug  9 17:29:35 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Mon, 9 Aug 2021 17:29:35 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v5]
In-Reply-To: <CqJMaaQ2ZWaURyfV2WLJg90KA_uf-Stl9cBCxZuctNU=.acddaa5f-790a-4e6e-85dc-9f0e5eb12282@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
 <CqJMaaQ2ZWaURyfV2WLJg90KA_uf-Stl9cBCxZuctNU=.acddaa5f-790a-4e6e-85dc-9f0e5eb12282@github.com>
Message-ID: <y6d2_GzkVXyLxd99MRbXWLfJwQ-NyLp5iFYVzu-gW6c=.a594e3d0-2bcb-4f82-af19-23654e7ebdc1@github.com>

On Mon, 9 Aug 2021 15:40:59 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Intrinsic for Math.copySign is disabled on x86_64.
>> 
>> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
>> 
>> ### **Math.copySign(double)**
>> _From:_
>>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>>   0x00007f7d606e5dc0:   and    %r8,%r11
>>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>>   0x00007f7d606e5dcd:   and    %r8,%r10
>>   0x00007f7d606e5dd0:   or     %r11,%r10
>>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
>> 
>> _To:_
>>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
>> 
>> ### **Math.copySign(float)**
>> _From:_
>>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>>   0x00007ff8886e60c4:   or     %r10d,%r11d
>>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
>> _To:_
>>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
>> 
>> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
>> #### **BEFORE**
>> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
>> 
>> #### **PATCH**
>> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
>> 
>> #### **JTREG that covers this case:**
>> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
>> 
>> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove predicates
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

src/hotspot/cpu/x86/x86.ad line 5813:

> 5811: // Desired Truth Table: A -> xmm0 bit, B -> xmm1 bit, C -> xmm2 bit
> 5812: // Wherever xmm2 is 0, we want to pick from B (sign)
> 5813: // Wherever xmm2 is 1, we want to pick from A (src)

Good to add then C (xmm2) is set to 0x7FFFFFFF.

src/hotspot/cpu/x86/x86.ad line 5835:

> 5833:   ins_encode %{
> 5834:     __ movl($tmp2$$Register, 0x7FFFFFFF);
> 5835:     __ vmovd($tmp1$$XMMRegister, $tmp2$$Register);

You could use movdl() instead of adding a new vmod instruction.

src/hotspot/cpu/x86/x86.ad line 5848:

> 5846:   ins_encode %{
> 5847:     __ mov64($tmp2$$Register, 0x7FFFFFFFFFFFFFFF);
> 5848:     __ vmovq($tmp1$$XMMRegister, $tmp2$$Register);

You could use movq() instead of adding a new vmovq instruction.

-------------

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

From coleenp at openjdk.java.net  Mon Aug  9 17:36:36 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 9 Aug 2021 17:36:36 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v4]
In-Reply-To: <a00dy1Q8-Z6hwgNt5SkXXd9D5Di8t_Y4HzfotjLH0DI=.37a99555-166d-4852-9ee3-69a9051a79e7@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <A6jfsBBrXc-gXmDe_Ag4Io7k4ZSy4JGkw70JSPxjn7Y=.f71cad65-578f-4764-822b-113e61a6d55a@github.com>
 <a00dy1Q8-Z6hwgNt5SkXXd9D5Di8t_Y4HzfotjLH0DI=.37a99555-166d-4852-9ee3-69a9051a79e7@github.com>
Message-ID: <KZEJYgwH5WrrdN6hdy2tqxhOnSTuohvF3xDTNVnU594=.e4911bb0-4148-4a83-9411-847249bb3f9a@github.com>

On Mon, 9 Aug 2021 08:39:38 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Create new exception during initialization saving, so only need to save an oop. (Could potentially move to Doug's secret Class location.  If the exception is not bootstrap exception, throw EIIE instead with message of original exception.
>
> src/hotspot/share/classfile/javaClasses.cpp line 2685:
> 
>> 2683:   assert(stack_trace->is_objArray(), "Should be an array");
>> 2684: 
>> 2685:   // If the original exception was in java.base, then use that otherwise use
> 
> comment is about one specific bootstrap module (java.base) but the check is for bootstrap loader.

Ok, thanks for pointing that out. I fixed the comment.  I realized that really wanted the bootloader after I wrote the comment.

-------------

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

From valeriep at openjdk.java.net  Mon Aug  9 18:04:36 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 9 Aug 2021 18:04:36 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v8]
In-Reply-To: <VWASAkdLb9zt1v6xhyLwTVzM2B3-et1JN1njFlRTy5E=.1a3700ff-5bad-4838-bb53-83b8a3fcf644@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <VWASAkdLb9zt1v6xhyLwTVzM2B3-et1JN1njFlRTy5E=.1a3700ff-5bad-4838-bb53-83b8a3fcf644@github.com>
Message-ID: <q-ffl1D1kxpviUBODZfpD4IHtg1il9iACJ5hoprdC-s=.571e50e4-24eb-4f3d-b9e7-87ac416b0f5f@github.com>

On Mon, 9 Aug 2021 15:49:07 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewiew update

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1652:

> 1650:                 outOfs += resultLen;
> 1651:                 len += resultLen;
> 1652:             }

Seems redundant since DecryptOp.doFinal(..) already has this check?

-------------

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

From valeriep at openjdk.java.net  Mon Aug  9 18:11:45 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 9 Aug 2021 18:11:45 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <Wvrw_lfIMcnvvkbb5VchtFjz1azshzL6dh4Qj5cs7Bo=.5520d555-6d6d-4300-9bbc-8fc4889256e1@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
 <A_dsMP2h3dJxQTH5KhQf_8CNVI3NkJavVsMJWQZvlSM=.52cfb190-f37f-473d-bf2f-20ff97e53d6b@github.com>
 <Wvrw_lfIMcnvvkbb5VchtFjz1azshzL6dh4Qj5cs7Bo=.5520d555-6d6d-4300-9bbc-8fc4889256e1@github.com>
Message-ID: <Wl0H0VpthBPbKaPkMAtN-wVbkkU1zihX3FOwxFmqk70=.f3531fa7-c0a6-45c7-a7aa-351dae787a93@github.com>

On Fri, 6 Aug 2021 19:35:23 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1779:
>> 
>>> 1777:             int len = 0;
>>> 1778:             if (inLen >= PARALLEL_LEN) {
>>> 1779:                 implGCMCrypt(in, inOfs, inLen, in, inOfs, out, outOfs, gctr,
>> 
>> Should save the return value into 'len'? For consistency sake, choose between GaloisCounterMode.implGCMCrypt(...) and implGCMCrypt and not both?
>
> I do not understand this comment

Doesn't implGCMCrypt(...) return an int telling how much bytes it has processed? Then we adjust the index and remain input length with this value. But here we didn't save the return value which looks wrong. Did I miss something?

Never mind my second comment, I mis-read the code.

-------------

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

From dholmes at openjdk.java.net  Mon Aug  9 21:04:36 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 9 Aug 2021 21:04:36 GMT
Subject: RFR: 8263567: gtests don't terminate the VM safely [v3]
In-Reply-To: <kJq2F4xKK1K9q_qj2lwUT9_pPW3X7xsvimgi8QzMqFw=.9daf7ad2-17f3-4918-9eb8-a59af96c22d2@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
 <OqVdBBg5ponJncrQ2O-w_Uqsl77LoDNkNIWqTe2Uv8o=.eb99d722-d179-4e72-a825-b7133b5207c4@github.com>
 <kJq2F4xKK1K9q_qj2lwUT9_pPW3X7xsvimgi8QzMqFw=.9daf7ad2-17f3-4918-9eb8-a59af96c22d2@github.com>
Message-ID: <Mh0sMxupDFh8u6-YutGIn1fEn4a0yel0XxLIvc6hoog=.96506816-30ce-4c57-907d-b8e02077f829@github.com>

On Mon, 9 Aug 2021 16:08:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed superfluous blank
>
> Thumbs up.

Thanks @dcubed-ojdk !

-------------

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

From dholmes at openjdk.java.net  Mon Aug  9 21:04:37 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 9 Aug 2021 21:04:37 GMT
Subject: Integrated: 8263567: gtests don't terminate the VM safely
In-Reply-To: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
References: <xqsG2RlnGPYMyfnxpSNTsIZXzXuDgGQ03YI72sZ28YA=.aa972b07-64a4-4237-85be-de30c7de590e@github.com>
Message-ID: <UrxdEnWSGOZEL4joDLbrS5X-KfXCIQaMYULeq2cSetA=.bd11e91e-8eec-4704-a97f-313291bc9250@github.com>

On Wed, 4 Aug 2021 05:55:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this fix to shutdown cleanly any JVMs created by gtests that aren't aborted.
> 
> Testing:
>   - manual instrumentation to check all JVM construction and then deletion during gtest runs
>   - local gtest testing
>   - tiers 1-3 gtest testing
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 843943c2
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/843943c204f6e8ca046919eae4e727bef6e3326c
Stats:     61 lines in 2 files changed: 45 ins; 5 del; 11 mod

8263567: gtests don't terminate the VM safely

Reviewed-by: stuefe, dcubed

-------------

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

From dholmes at openjdk.java.net  Mon Aug  9 22:46:42 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 9 Aug 2021 22:46:42 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v5]
In-Reply-To: <Vevmz9N508RUXV13xjraE5lj4OU831p-fxT5lvt3xPs=.5d8a0569-5073-4a64-b821-d6e8fd354c30@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <Vevmz9N508RUXV13xjraE5lj4OU831p-fxT5lvt3xPs=.5d8a0569-5073-4a64-b821-d6e8fd354c30@github.com>
Message-ID: <eE5sZaDEcv1Jm5KjKJlZrK1e2l0jeG8NeT2uY1jI-vM=.036cbc23-2123-4e03-a8a3-c85c7b7800f3@github.com>

On Mon, 9 Aug 2021 17:29:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
>> 
>> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix java.base/bootstrap class loader comment.

Hi Coleen,

Still thinking about the details of this. One concern below, and a few minor comments.

Thanks,
David

src/hotspot/share/classfile/javaClasses.cpp line 2685:

> 2683:   assert(stack_trace->is_objArray(), "Should be an array");
> 2684: 
> 2685:   // If the original exception was in the bootstrap class loader, then use that

Not sure that is a sufficiently strong enough check due to -Xbootclasspath:/a. You may need to check actual java.base module.

src/hotspot/share/classfile/javaClasses.cpp line 2694:

> 2692:                              vmSymbols::java_lang_ExceptionInInitializerError();
> 2693: 
> 2694:   // Now create a the same exception with this stacktrace and thread name.

Typo: a the

src/hotspot/share/classfile/javaClasses.cpp line 2711:

> 2709: 
> 2710:   // If new exception returns a different exception while creating the exception, return null.
> 2711:   if (h_cause->klass()->name() != exception_name) {

Some logging here to show that an exception occurred trying to do this would be useful I think.

test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionTest.java line 43:

> 41: class InitOOM {
> 42:     static {
> 43:         if (true) foo();

I would just throw new OutOfmemoryError. Trying to force an actually OOME is too fragile, depends on heap size and GC etc. and we don't care that it is a real OOME.

test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionUnloadTest.java line 28:

> 26:  * @bug 8048190
> 27:  * @summary Test that the NCDFE saves original exception during class initialization,
> 28:  *          and doesn't cause the classes in the stacktrace to be unloaded.

Don't you mean "and doesn't prevent the classes in the stacktrace from being unloaded"?

test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionUnloadTest.java line 53:

> 51:     }
> 52:     // Has to be in jasm to throw special exception in class initializer.
> 53:     // static public class ThrowsSpecialException

The reason it has to be jasm is because you've made it a checked exception by extending Throwable directly. If you make it an unchecked exception (extend Error or RuntimeException) then you can use the same javac `if (true) throw` trick. Static initializers can never be declared to throw checked exceptions.

-------------

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

From coleenp at openjdk.java.net  Mon Aug  9 23:18:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 9 Aug 2021 23:18:33 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v5]
In-Reply-To: <eE5sZaDEcv1Jm5KjKJlZrK1e2l0jeG8NeT2uY1jI-vM=.036cbc23-2123-4e03-a8a3-c85c7b7800f3@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <Vevmz9N508RUXV13xjraE5lj4OU831p-fxT5lvt3xPs=.5d8a0569-5073-4a64-b821-d6e8fd354c30@github.com>
 <eE5sZaDEcv1Jm5KjKJlZrK1e2l0jeG8NeT2uY1jI-vM=.036cbc23-2123-4e03-a8a3-c85c7b7800f3@github.com>
Message-ID: <1CXx4kZ6rToaHmH34jOEfFAWbOviouVOR9mh2YxXIO0=.39fa5b0d-0a30-4357-808f-d995b8a057e2@github.com>

On Mon, 9 Aug 2021 22:13:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix java.base/bootstrap class loader comment.
>
> src/hotspot/share/classfile/javaClasses.cpp line 2694:
> 
>> 2692:                              vmSymbols::java_lang_ExceptionInInitializerError();
>> 2693: 
>> 2694:   // Now create a the same exception with this stacktrace and thread name.
> 
> Typo: a the

fixed.

> test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionTest.java line 43:
> 
>> 41: class InitOOM {
>> 42:     static {
>> 43:         if (true) foo();
> 
> I would just throw new OutOfmemoryError. Trying to force an actually OOME is too fragile, depends on heap size and GC etc. and we don't care that it is a real OOME.

For this test, I did want to see what happened with a real OOM and whether this condition would get an OOM when creating the stack trace.  In my test, GC collects the allocated array.  If the array is static, the OOM would terminate the program so it wasn't much of a test that way.  I could change it back now that I wasn't able to make it get an OOM in while allocating the stack trace and new exception object.

> test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionUnloadTest.java line 53:
> 
>> 51:     }
>> 52:     // Has to be in jasm to throw special exception in class initializer.
>> 53:     // static public class ThrowsSpecialException
> 
> The reason it has to be jasm is because you've made it a checked exception by extending Throwable directly. If you make it an unchecked exception (extend Error or RuntimeException) then you can use the same javac `if (true) throw` trick. Static initializers can never be declared to throw checked exceptions.

Oh, that's handy.

-------------

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

From coleenp at openjdk.java.net  Mon Aug  9 23:24:32 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 9 Aug 2021 23:24:32 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v5]
In-Reply-To: <eE5sZaDEcv1Jm5KjKJlZrK1e2l0jeG8NeT2uY1jI-vM=.036cbc23-2123-4e03-a8a3-c85c7b7800f3@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <Vevmz9N508RUXV13xjraE5lj4OU831p-fxT5lvt3xPs=.5d8a0569-5073-4a64-b821-d6e8fd354c30@github.com>
 <eE5sZaDEcv1Jm5KjKJlZrK1e2l0jeG8NeT2uY1jI-vM=.036cbc23-2123-4e03-a8a3-c85c7b7800f3@github.com>
Message-ID: <_7fgD_ZPssA2P5noTTV2VQsnOFe4yjgmlPNW-CQ4vTY=.7ee63123-ad68-44c3-81cb-165e4ac6461e@github.com>

On Mon, 9 Aug 2021 22:40:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix java.base/bootstrap class loader comment.
>
> src/hotspot/share/classfile/javaClasses.cpp line 2685:
> 
>> 2683:   assert(stack_trace->is_objArray(), "Should be an array");
>> 2684: 
>> 2685:   // If the original exception was in the bootstrap class loader, then use that
> 
> Not sure that is a sufficiently strong enough check due to -Xbootclasspath:/a. You may need to check actual java.base module.

I don't know.  The worry was that the exception would be unloaded, which it won't if it's in the bootstrap class loader.

> test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionUnloadTest.java line 28:
> 
>> 26:  * @bug 8048190
>> 27:  * @summary Test that the NCDFE saves original exception during class initialization,
>> 28:  *          and doesn't cause the classes in the stacktrace to be unloaded.
> 
> Don't you mean "and doesn't prevent the classes in the stacktrace from being unloaded"?

yes.

-------------

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

From coleenp at openjdk.java.net  Mon Aug  9 23:34:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 9 Aug 2021 23:34:33 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v5]
In-Reply-To: <eE5sZaDEcv1Jm5KjKJlZrK1e2l0jeG8NeT2uY1jI-vM=.036cbc23-2123-4e03-a8a3-c85c7b7800f3@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <Vevmz9N508RUXV13xjraE5lj4OU831p-fxT5lvt3xPs=.5d8a0569-5073-4a64-b821-d6e8fd354c30@github.com>
 <eE5sZaDEcv1Jm5KjKJlZrK1e2l0jeG8NeT2uY1jI-vM=.036cbc23-2123-4e03-a8a3-c85c7b7800f3@github.com>
Message-ID: <NGKOXOCwxwYox7lF2-Il6aJsgnxwfJnykT1c_DTBCxY=.e420e6f9-3547-4be4-9d21-7ff72a8a9df2@github.com>

On Mon, 9 Aug 2021 22:43:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix java.base/bootstrap class loader comment.
>
> Hi Coleen,
> 
> Still thinking about the details of this. One concern below, and a few minor comments.
> 
> Thanks,
> David

@dholmes-ora Thanks for looking at this in detail.  It does a lot during initialization error so useful to be cautious.  I was thinking of maybe having a diagnostic option to turn it off in case some application down the line finds it's doing too much or one that has a lot of initialization errors that blow up the table.

> src/hotspot/share/classfile/javaClasses.cpp line 2711:
> 
>> 2709: 
>> 2710:   // If new exception returns a different exception while creating the exception, return null.
>> 2711:   if (h_cause->klass()->name() != exception_name) {
> 
> Some logging here to show that an exception occurred trying to do this would be useful I think.

ok.  I should probably add back the table printing and logging.  I made it resizeable but I don't think I'll ever have to resize it so didn't put the code for that.

-------------

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

From dholmes at openjdk.java.net  Mon Aug  9 23:44:33 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 9 Aug 2021 23:44:33 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v5]
In-Reply-To: <_7fgD_ZPssA2P5noTTV2VQsnOFe4yjgmlPNW-CQ4vTY=.7ee63123-ad68-44c3-81cb-165e4ac6461e@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <Vevmz9N508RUXV13xjraE5lj4OU831p-fxT5lvt3xPs=.5d8a0569-5073-4a64-b821-d6e8fd354c30@github.com>
 <eE5sZaDEcv1Jm5KjKJlZrK1e2l0jeG8NeT2uY1jI-vM=.036cbc23-2123-4e03-a8a3-c85c7b7800f3@github.com>
 <_7fgD_ZPssA2P5noTTV2VQsnOFe4yjgmlPNW-CQ4vTY=.7ee63123-ad68-44c3-81cb-165e4ac6461e@github.com>
Message-ID: <6r-vdnJt9eg8RiQf4uyInrQWljlCqeRG14h8T1uoAU0=.ea9410b5-ad27-4d97-bcf0-edd3af91ec33@github.com>

On Mon, 9 Aug 2021 23:21:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 2685:
>> 
>>> 2683:   assert(stack_trace->is_objArray(), "Should be an array");
>>> 2684: 
>>> 2685:   // If the original exception was in the bootstrap class loader, then use that
>> 
>> Not sure that is a sufficiently strong enough check due to -Xbootclasspath:/a. You may need to check actual java.base module.
>
> I don't know.  The worry was that the exception would be unloaded, which it won't if it's in the bootstrap class loader.

There are multiple problems with instantiating an unknown instance of an exception type. The unloading aspect is only one of those problems. To be safe you really only want to instantiate a well-defined set of well-behaved exceptions types - and that would be those (or a subset thereof) in the base module.

Maybe the safest thing is to always create an instance of EIIE to hold the original stacktrace and message. I actually find it semantically more appealing to have the NCDFE be caused by an EIIE.

-------------

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

From coleenp at openjdk.java.net  Tue Aug 10 01:14:01 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 10 Aug 2021 01:14:01 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v6]
In-Reply-To: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
Message-ID: <9xBDdIY3cq6Yce5P23VvrV9AmIJI_LmMZFYe1KTcSGY=.35f4293e-9b2f-41a8-9226-da0c9e337a82@github.com>

> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
> 
> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).

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

  Hooray another jasm file gone!

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4996/files
  - new: https://git.openjdk.java.net/jdk/pull/4996/files/e7084b83..256acdd1

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

  Stats: 89 lines in 4 files changed: 12 ins; 74 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4996.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4996/head:pull/4996

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

From coleenp at openjdk.java.net  Tue Aug 10 02:22:34 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 10 Aug 2021 02:22:34 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v5]
In-Reply-To: <6r-vdnJt9eg8RiQf4uyInrQWljlCqeRG14h8T1uoAU0=.ea9410b5-ad27-4d97-bcf0-edd3af91ec33@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <Vevmz9N508RUXV13xjraE5lj4OU831p-fxT5lvt3xPs=.5d8a0569-5073-4a64-b821-d6e8fd354c30@github.com>
 <eE5sZaDEcv1Jm5KjKJlZrK1e2l0jeG8NeT2uY1jI-vM=.036cbc23-2123-4e03-a8a3-c85c7b7800f3@github.com>
 <_7fgD_ZPssA2P5noTTV2VQsnOFe4yjgmlPNW-CQ4vTY=.7ee63123-ad68-44c3-81cb-165e4ac6461e@github.com>
 <6r-vdnJt9eg8RiQf4uyInrQWljlCqeRG14h8T1uoAU0=.ea9410b5-ad27-4d97-bcf0-edd3af91ec33@github.com>
Message-ID: <YBTHuuUFFbxcYgQ8bMveFlfvIbOywWQbtm_UVc480-s=.61633c00-685e-4a24-a8a1-3d9301783244@github.com>

On Mon, 9 Aug 2021 23:41:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I don't know.  The worry was that the exception would be unloaded, which it won't if it's in the bootstrap class loader.
>
> There are multiple problems with instantiating an unknown instance of an exception type. The unloading aspect is only one of those problems. To be safe you really only want to instantiate a well-defined set of well-behaved exceptions types - and that would be those (or a subset thereof) in the base module.
> 
> Maybe the safest thing is to always create an instance of EIIE to hold the original stacktrace and message. I actually find it semantically more appealing to have the NCDFE be caused by an EIIE.

That might make things really simple and nice! I like that idea.

-------------

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

From coleenp at openjdk.java.net  Tue Aug 10 03:04:15 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 10 Aug 2021 03:04:15 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v7]
In-Reply-To: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
Message-ID: <-xlS0q9Q4afbO9BZveTfVaJio68mS20XyArg2d7s_gg=.32b71c3f-2bf7-4359-a985-3d1fe253fee0@github.com>

> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
> 
> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).

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

  Throw EIIE with the original exception as the cause and stack trace. Much safer. Also remove the redundant test and not try to get OOM because that would make the test unreliable.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4996/files
  - new: https://git.openjdk.java.net/jdk/pull/4996/files/256acdd1..0bc9f35f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4996&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4996&range=05-06

  Stats: 129 lines in 3 files changed: 15 ins; 104 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4996.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4996/head:pull/4996

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

From coleenp at openjdk.java.net  Tue Aug 10 03:43:09 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 10 Aug 2021 03:43:09 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v8]
In-Reply-To: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
Message-ID: <PgNTLa8_4pTurJt8TLwLI0RcSN3Lq2feNvvXlFMpZHI=.022472d2-ac37-4e25-87cf-8a9cbfe71cf4@github.com>

> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
> 
> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).

Coleen Phillimore 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 11 additional commits since the last revision:

 - Make Hashtable a fixed size, not resizable and bigger.
 - Merge branch 'master' into init-oom
 - Throw EIIE with the original exception as the cause and stack trace. Much safer. Also remove the redundant test and not try to get OOM because that would make the test unreliable.
 - Hooray another jasm file gone!
 - Fix java.base/bootstrap class loader comment.
 - Create new exception during initialization saving, so only need to save an oop. (Could potentially move to Doug's secret Class location.  If the exception is not bootstrap exception, throw EIIE instead with message of original exception.
 - Merge branch 'master' into init-oom
 - David review comments.
 - Merge branch 'master' into init-oom
 - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/e4d049d1...ffec5bbd

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4996/files
  - new: https://git.openjdk.java.net/jdk/pull/4996/files/0bc9f35f..ffec5bbd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4996&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4996&range=06-07

  Stats: 7148 lines in 175 files changed: 5949 ins; 562 del; 637 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4996.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4996/head:pull/4996

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

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: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
Message-ID: <GmWEo2upeRCl-2Jw8u7VqahjruebvZduXDBhZvvXym0=.78df2151-56bb-4508-9cd6-74a775bb99eb@github.com>

> 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 kbarrett at openjdk.java.net  Tue Aug 10 07:41:35 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 10 Aug 2021 07:41:35 GMT
Subject: RFR: 8271869: AArch64: build errors with GCC11 in
 frame::saved_oop_result
In-Reply-To: <-H4Ipq5xE61C6-xDj1vD-_gdEZYQdIeXcAMl0ASu5Rs=.2378487e-0c95-4bf8-a6ee-671dfaef1c00@github.com>
References: <-H4Ipq5xE61C6-xDj1vD-_gdEZYQdIeXcAMl0ASu5Rs=.2378487e-0c95-4bf8-a6ee-671dfaef1c00@github.com>
Message-ID: <dXni-kbnUWF6V5JdKCfRnEB_PdUID0z78r6YtCVcCNs=.a3ea161e-8ff7-499f-94a9-539eb9a2a44c@github.com>

On Thu, 5 Aug 2021 14:14:38 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> GCC11 warns that r0 is null. It does not complain if r1 is used instead.
> 
> AIUI, it is undefined behaviour in C++ to call member functions without
> a valid this pointer. So, technically GCC is correct to warn.

Yuck!  But I guess we don't have any other quick solution to supporting this compiler version, so as with JDK-8270083 I'm conditionally approving this as a temporary workaround.  I see this bug is already linked to JDK-8270140.

@theRealAph - You mentioned a prototype patch to fix the register definitions (probably addressing JDK-8270140?).  How close are you on that?  Do you need any help?

-------------

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

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: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
Message-ID: <c1BPm11Eai_huR3wwrsVFwVzGgrUdC3GUgzqwimumGE=.045765c1-41f4-4228-b2f5-3cedf8468c6b@github.com>

On Thu, 17 Jun 2021 12:27:25 GMT, Matthias Baesken <mbaesken at openjdk.org> 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 <mbaesken at openjdk.org>
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 dholmes at openjdk.java.net  Tue Aug 10 07:48:42 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 10 Aug 2021 07:48:42 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v8]
In-Reply-To: <PgNTLa8_4pTurJt8TLwLI0RcSN3Lq2feNvvXlFMpZHI=.022472d2-ac37-4e25-87cf-8a9cbfe71cf4@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <PgNTLa8_4pTurJt8TLwLI0RcSN3Lq2feNvvXlFMpZHI=.022472d2-ac37-4e25-87cf-8a9cbfe71cf4@github.com>
Message-ID: <ZnS2cjyXUlIyOQfb6tMd9IkcC9X34VBDdxBCTIy9BOc=.730884f6-9e9a-41a0-b0b5-9d9432f64b6b@github.com>

On Tue, 10 Aug 2021 03:43:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
>> 
>> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).
>
> Coleen Phillimore 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 11 additional commits since the last revision:
> 
>  - Make Hashtable a fixed size, not resizable and bigger.
>  - Merge branch 'master' into init-oom
>  - Throw EIIE with the original exception as the cause and stack trace. Much safer. Also remove the redundant test and not try to get OOM because that would make the test unreliable.
>  - Hooray another jasm file gone!
>  - Fix java.base/bootstrap class loader comment.
>  - Create new exception during initialization saving, so only need to save an oop. (Could potentially move to Doug's secret Class location.  If the exception is not bootstrap exception, throw EIIE instead with message of original exception.
>  - Merge branch 'master' into init-oom
>  - David review comments.
>  - Merge branch 'master' into init-oom
>  - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/2bf5cbe5...ffec5bbd

Hi Coleen,

Functional changes look good!

A couple of nits with the test.

Thanks,
David

src/hotspot/share/classfile/javaClasses.cpp line 2665:

> 2663:   // the message and stack trace.
> 2664: 
> 2665:   // Now create the same exception with this stacktrace and thread name.

Comment needs updating

test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionUnloadTest.java line 53:

> 51:     static public class ThrowsSpecialException {
> 52:         static {
> 53:             if (true) foo();

Not sure why you need to define foo() - and if you use foo() you shouldn't need the "if (true)".

test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionUnloadTest.java line 60:

> 58:     }
> 59: 
> 60:     static public class InitOOM {

Why InitOOM instead of ThrowsOOM?

test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionUnloadTest.java line 112:

> 110:         int i = 0;
> 111:         for (String className : classNames) {
> 112:             for (int tries = 2; tries--> 0; ) {

Nit: need space after --

test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionUnloadTest.java line 135:

> 133:     public static void main(java.lang.String[] unused) throws Throwable {
> 134:         test();
> 135:         test();

Why twice?

-------------

Marked as reviewed by dholmes (Reviewer).

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

From chagedorn at openjdk.java.net  Tue Aug 10 08:01:07 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 10 Aug 2021 08:01:07 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail [v2]
In-Reply-To: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
Message-ID: <NqjapjOK2jZhc2dQ5IqcDzaFh_EEnb4xJm5bEuQnWWc=.936dea3d-37a7-4b71-bdb2-2dac03630e5f@github.com>

> A test VM used by the IR framework sometimes prints `` in the middle of emitting a `PrintIdeal` or `PrintOptoAssembly` output which could lead to IR matching failures:
> https://github.com/openjdk/jdk/blob/489e5fd12a37a45f4f5ea64b05f85c6f99f70811/src/hotspot/share/utilities/ostream.cpp#L918-L927
> 
> I thought about just bailing out of IR matching if this string is found after a failure but this issue also affects internal framework tests (I observed one case locally where this happened in the test `TestIRMatching`, letting it fail).
> 
> Handling `` makes things more complicated for the IR framework tests. I'm not sure about the value of printing this message in the first place. But if nobody objects, I suggest to either remove it or at least guard it with `Verbose`, for example. I went with the latter solution in this PR.
> 
> Thanks,
> Christian

Christian Hagedorn 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:

 - Revert fix and add new fix: add bailout with adaptation to internal tests to handle it (option 1)
 - Merge branch 'master' into JDK-8271471
 - 8271471: [IR Framework] Rare occurrence of "<!-- safepoint while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fai

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4932/files
  - new: https://git.openjdk.java.net/jdk/pull/4932/files/5655433a..9ace95fa

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

  Stats: 40041 lines in 487 files changed: 35634 ins; 2520 del; 1887 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4932.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4932/head:pull/4932

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

From chagedorn at openjdk.java.net  Tue Aug 10 08:01:08 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 10 Aug 2021 08:01:08 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail
In-Reply-To: <DYD7sF4BNnpVmd3bt0LR9gqrM1XQzW2t9tEWaYskTQY=.a297e547-46e9-4561-8a2f-0faee8863ec2@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
 <DYD7sF4BNnpVmd3bt0LR9gqrM1XQzW2t9tEWaYskTQY=.a297e547-46e9-4561-8a2f-0faee8863ec2@github.com>
Message-ID: <5wxzpOvddoxH-iVA-jW0l78O34G-_Qd1aCC4OKtOgQc=.0ffd8915-33e6-4780-877e-cdb98ce58c2f@github.com>

On Mon, 9 Aug 2021 06:41:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> I would also go with option 1). For the framework internal tests that expect and exception, couldn't you simply add something like a `hitSafepointWhilePrinting()` method to `IRViolationException` that you can use to check if verification of the exception should be skipped?

Thanks Tobias, I therefore went with option 1 and reverted the HotSpot change. The problem is when no `IRViolationException` is thrown due to the bailout in the `IRMatcher`. I directly made a check before throwing it (which is probably the same as your suggestion with `hitSafepointWhilePrinting()`). I made the internal framework tests aware the bailout by replacing "shouldNotReach" checks by `shouldHaveCaughtException` methods which check if we had this `tty` message somewhere. If not then the test fails. Normal user written IR tests just pass when an `IRViolationException` would have been thrown but the matched input contained the `tty` message.

-------------

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

From chagedorn at openjdk.java.net  Tue Aug 10 08:18:06 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 10 Aug 2021 08:18:06 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail [v3]
In-Reply-To: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
Message-ID: <dppseNKg8JcKd1XjPgmIXhdNzN9_YsYTVgYlHGZIBCU=.c2422953-374c-4652-909b-84b22d4f11f9@github.com>

> A test VM used by the IR framework sometimes prints `` in the middle of emitting a `PrintIdeal` or `PrintOptoAssembly` output which could lead to IR matching failures:
> https://github.com/openjdk/jdk/blob/489e5fd12a37a45f4f5ea64b05f85c6f99f70811/src/hotspot/share/utilities/ostream.cpp#L918-L927
> 
> I thought about just bailing out of IR matching if this string is found after a failure but this issue also affects internal framework tests (I observed one case locally where this happened in the test `TestIRMatching`, letting it fail).
> 
> Handling `` makes things more complicated for the IR framework tests. I'm not sure about the value of printing this message in the first place. But if nobody objects, I suggest to either remove it or at least guard it with `Verbose`, for example. I went with the latter solution in this PR.
> 
> Thanks,
> Christian

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

  Replace RuntimeException by ShouldHaveCaughtException

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4932/files
  - new: https://git.openjdk.java.net/jdk/pull/4932/files/9ace95fa..ea3b6a6b

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

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

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

From github.com+4146708+a74nh at openjdk.java.net  Tue Aug 10 08:27:33 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Tue, 10 Aug 2021 08:27:33 GMT
Subject: RFR: 8271869: AArch64: build errors with GCC11 in
 frame::saved_oop_result
In-Reply-To: <dXni-kbnUWF6V5JdKCfRnEB_PdUID0z78r6YtCVcCNs=.a3ea161e-8ff7-499f-94a9-539eb9a2a44c@github.com>
References: <-H4Ipq5xE61C6-xDj1vD-_gdEZYQdIeXcAMl0ASu5Rs=.2378487e-0c95-4bf8-a6ee-671dfaef1c00@github.com>
 <dXni-kbnUWF6V5JdKCfRnEB_PdUID0z78r6YtCVcCNs=.a3ea161e-8ff7-499f-94a9-539eb9a2a44c@github.com>
Message-ID: <LxWpkrkh7woNs_rPznJem-U9tJqQQAunmY0zNTmPYGA=.85a11695-4e9e-4370-a9c4-debd65caa875@github.com>

On Tue, 10 Aug 2021 07:38:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> as with JDK-8270083

Ok - that explains why the errors I saw were only in AArch64 files.

-------------

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

From github.com+4146708+a74nh at openjdk.java.net  Tue Aug 10 08:33:33 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Tue, 10 Aug 2021 08:33:33 GMT
Subject: Integrated: 8271869: AArch64: build errors with GCC11 in
 frame::saved_oop_result
In-Reply-To: <-H4Ipq5xE61C6-xDj1vD-_gdEZYQdIeXcAMl0ASu5Rs=.2378487e-0c95-4bf8-a6ee-671dfaef1c00@github.com>
References: <-H4Ipq5xE61C6-xDj1vD-_gdEZYQdIeXcAMl0ASu5Rs=.2378487e-0c95-4bf8-a6ee-671dfaef1c00@github.com>
Message-ID: <0iOPHm5MNZJdUsSz4lhCrUCOT0bScTQ9GyTiSnDselY=.6bee0901-1d1a-47d9-8b2e-bed7d4e0652e@github.com>

On Thu, 5 Aug 2021 14:14:38 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> GCC11 warns that r0 is null. It does not complain if r1 is used instead.
> 
> AIUI, it is undefined behaviour in C++ to call member functions without
> a valid this pointer. So, technically GCC is correct to warn.

This pull request has now been integrated.

Changeset: 1f881349
Author:    Alan Hayward <alan.hayward at arm.com>
Committer: Nick Gasson <ngasson at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1f8813495e8184b6c38319df1c2cb70de7811a76
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8271869: AArch64: build errors with GCC11 in frame::saved_oop_result

Reviewed-by: ngasson, aph

-------------

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

From thartmann at openjdk.java.net  Tue Aug 10 08:35:33 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 10 Aug 2021 08:35:33 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail [v3]
In-Reply-To: <dppseNKg8JcKd1XjPgmIXhdNzN9_YsYTVgYlHGZIBCU=.c2422953-374c-4652-909b-84b22d4f11f9@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
 <dppseNKg8JcKd1XjPgmIXhdNzN9_YsYTVgYlHGZIBCU=.c2422953-374c-4652-909b-84b22d4f11f9@github.com>
Message-ID: <us31o6_Ed19rh-MbZDDWBtqwNriGNKx5EBDTWsLVESE=.c852e152-5ccf-418c-8e6c-f9b3f269ac21@github.com>

On Tue, 10 Aug 2021 08:18:06 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> A test VM used by the IR framework sometimes prints `` in the middle of emitting a `PrintIdeal` or `PrintOptoAssembly` output which could lead to IR matching failures:
>> https://github.com/openjdk/jdk/blob/489e5fd12a37a45f4f5ea64b05f85c6f99f70811/src/hotspot/share/utilities/ostream.cpp#L918-L927
>> 
>> I thought about just bailing out of IR matching if this string is found after a failure but this issue also affects internal framework tests (I observed one case locally where this happened in the test `TestIRMatching`, letting it fail).
>> 
>> Handling `` makes things more complicated for the IR framework tests. I'm not sure about the value of printing this message in the first place. But if nobody objects, I suggest to either remove it or at least guard it with `Verbose`, for example. I went with the latter solution in this PR.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace RuntimeException by ShouldHaveCaughtException

test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/Utils.java line 31:

> 29: 
> 30: public class Utils {
> 31:     public static void shouldHaveCaughtException() {

Should these methods be renamed to `shouldHaveThrownException`? Because that method could also be used in a context where we don't catch.

test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/Utils.java line 48:

> 46:             throw new ShouldHaveCaughtException();
> 47:         }
> 48:     }

Why don't we simply do:

    for (Scenario s : scenarios) {
        shouldHaveCaughtException(s.getTestVMOutput());
    }

-------------

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

From aph-open at littlepinkcloud.com  Tue Aug 10 08:51:25 2021
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Tue, 10 Aug 2021 09:51:25 +0100
Subject: RFR: 8271869: AArch64: build errors with GCC11 in
 frame::saved_oop_result
In-Reply-To: <dXni-kbnUWF6V5JdKCfRnEB_PdUID0z78r6YtCVcCNs=.a3ea161e-8ff7-499f-94a9-539eb9a2a44c@github.com>
References: <-H4Ipq5xE61C6-xDj1vD-_gdEZYQdIeXcAMl0ASu5Rs=.2378487e-0c95-4bf8-a6ee-671dfaef1c00@github.com>
 <dXni-kbnUWF6V5JdKCfRnEB_PdUID0z78r6YtCVcCNs=.a3ea161e-8ff7-499f-94a9-539eb9a2a44c@github.com>
Message-ID: <b7c502e2-7457-ec10-0b47-27fdb2a78956@littlepinkcloud.com>

On 8/10/21 8:41 AM, Kim Barrett wrote:

> Yuck!  But I guess we don't have any other quick solution to
> supporting this compiler version, so as with JDK-8270083 I'm
> conditionally approving this as a temporary workaround.  I see this
> bug is already linked to JDK-8270140.
>
> @theRealAph - You mentioned a prototype patch to fix the register
> definitions (probably addressing JDK-8270140?).

Yes, it fixes that by making Register well-defined behaviour.

> How close are you on that?  Do you need any help?

The patch works just fine, but there is a smallish performance
degradation.  Having said that, the degradation is much less than the
performance gain from 8269122 (The use of "extern const" for Register
definitions generates poor code) so probably no-one would notice, and
we'd get rid of the undefined behaviour.  I didn't submit it because I
thought people rather liked the fake-pointer-to-nothing hack and
didn't care about UB. I can dig the patch out if you like.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From chagedorn at openjdk.java.net  Tue Aug 10 09:33:54 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 10 Aug 2021 09:33:54 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail [v4]
In-Reply-To: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
Message-ID: <iOOl8r2fwYDyK_UJSuFJEbsixzglCsGStX0Bw6nu48g=.8ebd21a0-7eb3-40ef-b654-7b9dfb295fc6@github.com>

> A test VM used by the IR framework sometimes prints `` in the middle of emitting a `PrintIdeal` or `PrintOptoAssembly` output which could lead to IR matching failures:
> https://github.com/openjdk/jdk/blob/489e5fd12a37a45f4f5ea64b05f85c6f99f70811/src/hotspot/share/utilities/ostream.cpp#L918-L927
> 
> I thought about just bailing out of IR matching if this string is found after a failure but this issue also affects internal framework tests (I observed one case locally where this happened in the test `TestIRMatching`, letting it fail).
> 
> Handling `` makes things more complicated for the IR framework tests. I'm not sure about the value of printing this message in the first place. But if nobody objects, I suggest to either remove it or at least guard it with `Verbose`, for example. I went with the latter solution in this PR.
> 
> Thanks,
> Christian

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

  Renaming and change handling for TestScenarios

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4932/files
  - new: https://git.openjdk.java.net/jdk/pull/4932/files/ea3b6a6b..8cc6b667

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

  Stats: 53 lines in 4 files changed: 18 ins; 12 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4932.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4932/head:pull/4932

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

From chagedorn at openjdk.java.net  Tue Aug 10 09:33:55 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 10 Aug 2021 09:33:55 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail [v3]
In-Reply-To: <dppseNKg8JcKd1XjPgmIXhdNzN9_YsYTVgYlHGZIBCU=.c2422953-374c-4652-909b-84b22d4f11f9@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
 <dppseNKg8JcKd1XjPgmIXhdNzN9_YsYTVgYlHGZIBCU=.c2422953-374c-4652-909b-84b22d4f11f9@github.com>
Message-ID: <Lsh7KRBzaP-fMThpHEEdv0IfiON8smsFSCqk5BzLiEA=.5043147c-058e-4ff2-ac6d-10354a653642@github.com>

On Tue, 10 Aug 2021 08:18:06 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> A test VM used by the IR framework sometimes prints `` in the middle of emitting a `PrintIdeal` or `PrintOptoAssembly` output which could lead to IR matching failures:
>> https://github.com/openjdk/jdk/blob/489e5fd12a37a45f4f5ea64b05f85c6f99f70811/src/hotspot/share/utilities/ostream.cpp#L918-L927
>> 
>> I thought about just bailing out of IR matching if this string is found after a failure but this issue also affects internal framework tests (I observed one case locally where this happened in the test `TestIRMatching`, letting it fail).
>> 
>> Handling `` makes things more complicated for the IR framework tests. I'm not sure about the value of printing this message in the first place. But if nobody objects, I suggest to either remove it or at least guard it with `Verbose`, for example. I went with the latter solution in this PR.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace RuntimeException by ShouldHaveCaughtException

I did a renaming and changed the way `TestScenarios` throws exceptions (was wrong how I had it before). `TestScenarios` should actually do some more finegrained checks and depending on which scenarios bailed out do different things. I added some comments for them.

-------------

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

From chagedorn at openjdk.java.net  Tue Aug 10 09:33:57 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 10 Aug 2021 09:33:57 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail [v3]
In-Reply-To: <us31o6_Ed19rh-MbZDDWBtqwNriGNKx5EBDTWsLVESE=.c852e152-5ccf-418c-8e6c-f9b3f269ac21@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
 <dppseNKg8JcKd1XjPgmIXhdNzN9_YsYTVgYlHGZIBCU=.c2422953-374c-4652-909b-84b22d4f11f9@github.com>
 <us31o6_Ed19rh-MbZDDWBtqwNriGNKx5EBDTWsLVESE=.c852e152-5ccf-418c-8e6c-f9b3f269ac21@github.com>
Message-ID: <hybe7kdq8vMZ4KzCyc6EA87zd2b_HFcwp67VKdpUf2Y=.ee0f6616-ecfc-457f-b24e-a8c94e59e114@github.com>

On Tue, 10 Aug 2021 08:25:44 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace RuntimeException by ShouldHaveCaughtException
>
> test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/Utils.java line 31:
> 
>> 29: 
>> 30: public class Utils {
>> 31:     public static void shouldHaveCaughtException() {
> 
> Should these methods be renamed to `shouldHaveThrownException`? Because that method could also be used in a context where we don't catch.

Agreed, that's a better name!

> test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/Utils.java line 48:
> 
>> 46:             throw new ShouldHaveCaughtException();
>> 47:         }
>> 48:     }
> 
> Why don't we simply do:
> 
>     for (Scenario s : scenarios) {
>         shouldHaveCaughtException(s.getTestVMOutput());
>     }

I changed that code, see comment below.

-------------

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

From aph at openjdk.java.net  Tue Aug 10 10:51:39 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 10 Aug 2021 10:51:39 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v8]
In-Reply-To: <VWASAkdLb9zt1v6xhyLwTVzM2B3-et1JN1njFlRTy5E=.1a3700ff-5bad-4838-bb53-83b8a3fcf644@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <VWASAkdLb9zt1v6xhyLwTVzM2B3-et1JN1njFlRTy5E=.1a3700ff-5bad-4838-bb53-83b8a3fcf644@github.com>
Message-ID: <xK12fnvdFWBBwgbjuvfI6zosDL1boQS04QeLkCUx2ws=.120f7e43-df87-496f-900a-c13e3cc2d667@github.com>

On Mon, 9 Aug 2021 15:49:07 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewiew update

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 694:

> 692: 
> 693:         /**
> 694:          *  ByteBuffer wrapper for intrinsic implGCMCrypt.  It will operation

Suggestion:

         *  ByteBuffer wrapper for intrinsic implGCMCrypt.  It will operate

-------------

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

From thartmann at openjdk.java.net  Tue Aug 10 11:33:35 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 10 Aug 2021 11:33:35 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail [v4]
In-Reply-To: <iOOl8r2fwYDyK_UJSuFJEbsixzglCsGStX0Bw6nu48g=.8ebd21a0-7eb3-40ef-b654-7b9dfb295fc6@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
 <iOOl8r2fwYDyK_UJSuFJEbsixzglCsGStX0Bw6nu48g=.8ebd21a0-7eb3-40ef-b654-7b9dfb295fc6@github.com>
Message-ID: <eBJRKsCXyS7NbNtf81N6THAFAxMqDZbZtl_XMkczghg=.2c0d2a32-b3fe-4aec-be30-21e2e48b667f@github.com>

On Tue, 10 Aug 2021 09:33:54 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> A test VM used by the IR framework sometimes prints `` in the middle of emitting a `PrintIdeal` or `PrintOptoAssembly` output which could lead to IR matching failures:
>> https://github.com/openjdk/jdk/blob/489e5fd12a37a45f4f5ea64b05f85c6f99f70811/src/hotspot/share/utilities/ostream.cpp#L918-L927
>> 
>> I thought about just bailing out of IR matching if this string is found after a failure but this issue also affects internal framework tests (I observed one case locally where this happened in the test `TestIRMatching`, letting it fail).
>> 
>> Handling `` makes things more complicated for the IR framework tests. I'm not sure about the value of printing this message in the first place. But if nobody objects, I suggest to either remove it or at least guard it with `Verbose`, for example. I went with the latter solution in this PR.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renaming and change handling for TestScenarios

Looks good to me. I'm just wondering if we need all that `notAllBailedOut`/`noneBailedOut` complexity for handling scenarios. Given that safepoints during printing are rare, couldn't we simply skip verification of the exception message if one scenario hit a bailout?

test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestScenarios.java line 51:

> 49:                 Asserts.fail("Should have thrown an exception");
> 50:             }
> 51: 

Newline can be removed

test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/Utils.java line 52:

> 50:     }
> 51: 
> 52:     private static void shouldHaveThrownException(String testVMOutput) {

Now this method is only used by `shouldHaveThrownException()`. I would remove it.

-------------

Marked as reviewed by thartmann (Reviewer).

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

From chagedorn at openjdk.java.net  Tue Aug 10 12:04:56 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 10 Aug 2021 12:04:56 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail [v5]
In-Reply-To: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
Message-ID: <YRw5msMUkovU4qPzPzvloaLw6jlgKmRSgSi8zemjvx4=.fa642ba6-67d1-4430-9015-a8cb02417dc8@github.com>

> A test VM used by the IR framework sometimes prints `` in the middle of emitting a `PrintIdeal` or `PrintOptoAssembly` output which could lead to IR matching failures:
> https://github.com/openjdk/jdk/blob/489e5fd12a37a45f4f5ea64b05f85c6f99f70811/src/hotspot/share/utilities/ostream.cpp#L918-L927
> 
> I thought about just bailing out of IR matching if this string is found after a failure but this issue also affects internal framework tests (I observed one case locally where this happened in the test `TestIRMatching`, letting it fail).
> 
> Handling `` makes things more complicated for the IR framework tests. I'm not sure about the value of printing this message in the first place. But if nobody objects, I suggest to either remove it or at least guard it with `Verbose`, for example. I went with the latter solution in this PR.
> 
> Thanks,
> Christian

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

  Cleanup & simplify test by using anyMatch

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4932/files
  - new: https://git.openjdk.java.net/jdk/pull/4932/files/8cc6b667..3c12c6b3

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

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

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

From chagedorn at openjdk.java.net  Tue Aug 10 12:04:56 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 10 Aug 2021 12:04:56 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail [v4]
In-Reply-To: <eBJRKsCXyS7NbNtf81N6THAFAxMqDZbZtl_XMkczghg=.2c0d2a32-b3fe-4aec-be30-21e2e48b667f@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
 <iOOl8r2fwYDyK_UJSuFJEbsixzglCsGStX0Bw6nu48g=.8ebd21a0-7eb3-40ef-b654-7b9dfb295fc6@github.com>
 <eBJRKsCXyS7NbNtf81N6THAFAxMqDZbZtl_XMkczghg=.2c0d2a32-b3fe-4aec-be30-21e2e48b667f@github.com>
Message-ID: <ME6Jd0jiRdach9lIBhgDUcHc2V17qdAreBzdR7JKsIo=.90975ca5-aa97-49b7-8e47-cfe7549f9ec8@github.com>

On Tue, 10 Aug 2021 11:31:06 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Looks good to me. I'm just wondering if we need all that `notAllBailedOut`/`noneBailedOut` complexity for handling scenarios. 

I think we need the `notAllBailedOut()` function to verify that there was not a scenario without a bailout (i.e. missed to throw an exception). The code of `notAllBailedOut()` could be simplified to use `anyMatch` instead.

> Given that safepoints during printing are rare, couldn't we simply skip verification of the exception message if one scenario hit a bailout?

Yes, that's probably easier. We can also first check if the expected message was even mismatched in `TestScenarios` before actually doing the `tty` message check. I changed that by turning `noneBailedOut` into `anyBailedOut` which uses `anyMatch`.

But yes, I agree that it's some complexity for a rather rare case. I pushed an updated with these changes.

-------------

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

From thartmann at openjdk.java.net  Tue Aug 10 12:25:36 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 10 Aug 2021 12:25:36 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail [v5]
In-Reply-To: <YRw5msMUkovU4qPzPzvloaLw6jlgKmRSgSi8zemjvx4=.fa642ba6-67d1-4430-9015-a8cb02417dc8@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
 <YRw5msMUkovU4qPzPzvloaLw6jlgKmRSgSi8zemjvx4=.fa642ba6-67d1-4430-9015-a8cb02417dc8@github.com>
Message-ID: <Y-ZajHur5fV3cJckddldFI_uL8pJGKrrTglbhLozYlk=.c2515b97-00cc-4b93-b8cd-ba46d1583f3b@github.com>

On Tue, 10 Aug 2021 12:04:56 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> A test VM used by the IR framework sometimes prints `` in the middle of emitting a `PrintIdeal` or `PrintOptoAssembly` output which could lead to IR matching failures:
>> https://github.com/openjdk/jdk/blob/489e5fd12a37a45f4f5ea64b05f85c6f99f70811/src/hotspot/share/utilities/ostream.cpp#L918-L927
>> 
>> I thought about just bailing out of IR matching if this string is found after a failure but this issue also affects internal framework tests (I observed one case locally where this happened in the test `TestIRMatching`, letting it fail).
>> 
>> Handling `` makes things more complicated for the IR framework tests. I'm not sure about the value of printing this message in the first place. But if nobody objects, I suggest to either remove it or at least guard it with `Verbose`, for example. I went with the latter solution in this PR.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup & simplify test by using anyMatch

Looks good, thanks for making these changes!

-------------

Marked as reviewed by thartmann (Reviewer).

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

From chagedorn at openjdk.java.net  Tue Aug 10 12:38:31 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 10 Aug 2021 12:38:31 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail [v5]
In-Reply-To: <YRw5msMUkovU4qPzPzvloaLw6jlgKmRSgSi8zemjvx4=.fa642ba6-67d1-4430-9015-a8cb02417dc8@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
 <YRw5msMUkovU4qPzPzvloaLw6jlgKmRSgSi8zemjvx4=.fa642ba6-67d1-4430-9015-a8cb02417dc8@github.com>
Message-ID: <hlr42WTg2w3tEGkVPV57xkJ-YuAS52SFZMyqHFNROzM=.feee6469-d413-450a-839b-5a5e61292da5@github.com>

On Tue, 10 Aug 2021 12:04:56 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> A test VM used by the IR framework sometimes prints `` in the middle of emitting a `PrintIdeal` or `PrintOptoAssembly` output which could lead to IR matching failures:
>> https://github.com/openjdk/jdk/blob/489e5fd12a37a45f4f5ea64b05f85c6f99f70811/src/hotspot/share/utilities/ostream.cpp#L918-L927
>> 
>> I thought about just bailing out of IR matching if this string is found after a failure but this issue also affects internal framework tests (I observed one case locally where this happened in the test `TestIRMatching`, letting it fail).
>> 
>> Handling `` makes things more complicated for the IR framework tests. I'm not sure about the value of printing this message in the first place. But if nobody objects, I suggest to either remove it or at least guard it with `Verbose`, for example. I went with the latter solution in this PR.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup & simplify test by using anyMatch

Thank you Tobias for your careful review!

-------------

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

From coleenp at openjdk.java.net  Tue Aug 10 12:50:20 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 10 Aug 2021 12:50:20 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v8]
In-Reply-To: <ZnS2cjyXUlIyOQfb6tMd9IkcC9X34VBDdxBCTIy9BOc=.730884f6-9e9a-41a0-b0b5-9d9432f64b6b@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <PgNTLa8_4pTurJt8TLwLI0RcSN3Lq2feNvvXlFMpZHI=.022472d2-ac37-4e25-87cf-8a9cbfe71cf4@github.com>
 <ZnS2cjyXUlIyOQfb6tMd9IkcC9X34VBDdxBCTIy9BOc=.730884f6-9e9a-41a0-b0b5-9d9432f64b6b@github.com>
Message-ID: <zCc-qp2ri_L34OCmrgwEkjiRUBr_tv8eZIORXyOdmoc=.d86c7235-d60d-4252-8b49-af682159a4c1@github.com>

On Tue, 10 Aug 2021 07:37:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore 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 11 additional commits since the last revision:
>> 
>>  - Make Hashtable a fixed size, not resizable and bigger.
>>  - Merge branch 'master' into init-oom
>>  - Throw EIIE with the original exception as the cause and stack trace. Much safer. Also remove the redundant test and not try to get OOM because that would make the test unreliable.
>>  - Hooray another jasm file gone!
>>  - Fix java.base/bootstrap class loader comment.
>>  - Create new exception during initialization saving, so only need to save an oop. (Could potentially move to Doug's secret Class location.  If the exception is not bootstrap exception, throw EIIE instead with message of original exception.
>>  - Merge branch 'master' into init-oom
>>  - David review comments.
>>  - Merge branch 'master' into init-oom
>>  - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/1de39e8a...ffec5bbd
>
> src/hotspot/share/classfile/javaClasses.cpp line 2665:
> 
>> 2663:   // the message and stack trace.
>> 2664: 
>> 2665:   // Now create the same exception with this stacktrace and thread name.
> 
> Comment needs updating

fixed.

> test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionUnloadTest.java line 53:
> 
>> 51:     static public class ThrowsSpecialException {
>> 52:         static {
>> 53:             if (true) foo();
> 
> Not sure why you need to define foo() - and if you use foo() you shouldn't need the "if (true)".

I've removed the foos.  They made jasm hacking easier when I thought I needed that.

> test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionUnloadTest.java line 60:
> 
>> 58:     }
>> 59: 
>> 60:     static public class InitOOM {
> 
> Why InitOOM instead of ThrowsOOM?

fixed. That's a bit more consistent.

> test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionUnloadTest.java line 135:
> 
>> 133:     public static void main(java.lang.String[] unused) throws Throwable {
>> 134:         test();
>> 135:         test();
> 
> Why twice?

The classes should be unloaded and the message should be the same for each iteration, ie, first call should get EIIE and second should get NCDFE.

-------------

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

From coleenp at openjdk.java.net  Tue Aug 10 12:50:00 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 10 Aug 2021 12:50:00 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v9]
In-Reply-To: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
Message-ID: <FQjLgMJIm8ZkYA8nViBHPlbgcJFJgO_oRm_VC4odgMk=.a38b834d-c08c-4057-a900-ae1a40653cc8@github.com>

> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
> 
> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).

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

  Comment and test fixes.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4996/files
  - new: https://git.openjdk.java.net/jdk/pull/4996/files/ffec5bbd..de7a9999

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4996&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4996&range=07-08

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

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

From coleenp at openjdk.java.net  Tue Aug 10 12:50:09 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 10 Aug 2021 12:50:09 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v8]
In-Reply-To: <PgNTLa8_4pTurJt8TLwLI0RcSN3Lq2feNvvXlFMpZHI=.022472d2-ac37-4e25-87cf-8a9cbfe71cf4@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <PgNTLa8_4pTurJt8TLwLI0RcSN3Lq2feNvvXlFMpZHI=.022472d2-ac37-4e25-87cf-8a9cbfe71cf4@github.com>
Message-ID: <cV2j8OYvZnz_KnnOwwIGPCBxJFn0n8oL62h6VwQxcC8=.1af9772f-4715-44e1-a82c-ccc57cf069d8@github.com>

On Tue, 10 Aug 2021 03:43:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
>> 
>> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).
>
> Coleen Phillimore 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 11 additional commits since the last revision:
> 
>  - Make Hashtable a fixed size, not resizable and bigger.
>  - Merge branch 'master' into init-oom
>  - Throw EIIE with the original exception as the cause and stack trace. Much safer. Also remove the redundant test and not try to get OOM because that would make the test unreliable.
>  - Hooray another jasm file gone!
>  - Fix java.base/bootstrap class loader comment.
>  - Create new exception during initialization saving, so only need to save an oop. (Could potentially move to Doug's secret Class location.  If the exception is not bootstrap exception, throw EIIE instead with message of original exception.
>  - Merge branch 'master' into init-oom
>  - David review comments.
>  - Merge branch 'master' into init-oom
>  - 8048190: NoClassDefFoundError omits original ExceptionInInitializerError
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/605c8a0e...ffec5bbd

Thanks for the review and additional suggestions.

-------------

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

From dholmes at openjdk.java.net  Tue Aug 10 13:03:32 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 10 Aug 2021 13:03:32 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v9]
In-Reply-To: <FQjLgMJIm8ZkYA8nViBHPlbgcJFJgO_oRm_VC4odgMk=.a38b834d-c08c-4057-a900-ae1a40653cc8@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <FQjLgMJIm8ZkYA8nViBHPlbgcJFJgO_oRm_VC4odgMk=.a38b834d-c08c-4057-a900-ae1a40653cc8@github.com>
Message-ID: <OsBVEc7tlSKT6OkKviOI5Pq7p5KlcqJAP4iFUm1kqvU=.040a7ba1-b4c2-426c-82d9-e08c56bef464@github.com>

On Tue, 10 Aug 2021 12:50:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
>> 
>> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment and test fixes.

Marked as reviewed by dholmes (Reviewer).

-------------

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

From hseigel at openjdk.java.net  Tue Aug 10 14:11:50 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 10 Aug 2021 14:11:50 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a dangling
 C++ class
Message-ID: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>

Please review this change to remove the now unused CPSlot class.  Uses of CPSlot have been replaced with Symbol*.  The change was tested by running JCK lang and VM tests, Mach5 tiers 1-2 on Linux, Mac OS, and WIndows and Macn5 tiers 3-5 on Linux x64.

Thanks, Harold

-------------

Commit messages:
 - 8272107: Removal of Unsafe::defineAnonymousClass left a dangling C++ class

Changes: https://git.openjdk.java.net/jdk/pull/5070/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5070&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272107
  Stats: 41 lines in 6 files changed: 0 ins; 25 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5070.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5070/head:pull/5070

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

From lucy at openjdk.java.net  Tue Aug 10 14:58:40 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 10 Aug 2021 14:58:40 GMT
Subject: RFR: 8271490: [ppc] [s390]: Crash in
 JavaThread::pd_get_top_frame_for_profiling
Message-ID: <bD_GSVWnQEH5L4k08xN_CH7jtbpmHl7b5mwhLb_03lo=.81186ce8-3345-498c-934e-c4bf03bf80ab@github.com>

Please review this pull request. It hardens the code on ppc and s390 against crashes while collecting stack traces for JFR. Stack frame collection in prims/forte.cpp will benefit from this fix as well as it uses the same platform-specific code.

Testing:
SAP-internal functional and stress testing. Verifying a positive effect is hard because the targeted crashes occur only very rarely. No negative side effects of the fix have been observed.

-------------

Commit messages:
 - 8271490: [ppc] [s390]: Crash in JavaThread::pd_get_top_frame_for_profiling

Changes: https://git.openjdk.java.net/jdk/pull/5071/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5071&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271490
  Stats: 105 lines in 4 files changed: 76 ins; 12 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5071/head:pull/5071

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

From coleenp at openjdk.java.net  Tue Aug 10 16:40:49 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 10 Aug 2021 16:40:49 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class
In-Reply-To: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
Message-ID: <Mj4Yz85hTIeSI2t4Cse5OzDqyea5ZzOpCJaMg_ys6Co=.c936d3b6-aa3f-423e-a5c2-66b0a62406e2@github.com>

On Tue, 10 Aug 2021 14:06:04 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this change to remove the now unused CPSlot class.  Uses of CPSlot have been replaced with Symbol*.  The change was tested by running JCK lang and VM tests, Mach5 tiers 1-2 on Linux, Mac OS, and WIndows and Macn5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Might be able to make even more changes to this.

src/hotspot/share/oops/constantPool.inline.hpp line 39:

> 37:   intptr_t adr = Atomic::load_acquire(obj_at_addr(which));
> 38:   assert(adr != 0 || which == 0, "cp entry for klass should not be zero");
> 39:   return (Symbol*)adr;

I think you can get rid of all slot_at* and replace them with symbol_at().  Since the symbols don't change after the constant pool is initialized, all this volatile isn't needed.  Used to be used to replace Symbol* with Klass* also.  @iklam can confirm.

-------------

Changes requested by coleenp (Reviewer).

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

From iklam at openjdk.java.net  Tue Aug 10 17:22:52 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 10 Aug 2021 17:22:52 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class
In-Reply-To: <Mj4Yz85hTIeSI2t4Cse5OzDqyea5ZzOpCJaMg_ys6Co=.c936d3b6-aa3f-423e-a5c2-66b0a62406e2@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
 <Mj4Yz85hTIeSI2t4Cse5OzDqyea5ZzOpCJaMg_ys6Co=.c936d3b6-aa3f-423e-a5c2-66b0a62406e2@github.com>
Message-ID: <KJ2mYqQ5kEyuylskOlNE-Hoy5zMtE4gPj28LGLd2LLI=.d5afe9dc-310b-496a-8edb-b07971769025@github.com>

On Tue, 10 Aug 2021 16:37:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to remove the now unused CPSlot class.  Uses of CPSlot have been replaced with Symbol*.  The change was tested by running JCK lang and VM tests, Mach5 tiers 1-2 on Linux, Mac OS, and WIndows and Macn5 tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> src/hotspot/share/oops/constantPool.inline.hpp line 39:
> 
>> 37:   intptr_t adr = Atomic::load_acquire(obj_at_addr(which));
>> 38:   assert(adr != 0 || which == 0, "cp entry for klass should not be zero");
>> 39:   return (Symbol*)adr;
> 
> I think you can get rid of all slot_at* and replace them with symbol_at().  Since the symbols don't change after the constant pool is initialized, all this volatile isn't needed.  Used to be used to replace Symbol* with Klass* also.  @iklam can confirm.

`ConstantPool` objects are no modified after the class is linked, and linking is done single threaded. So there's no need to use the `Atomic::load_acquire` in the above code. I agree with Coleen that the above function can be replaced with symbol_at().

-------------

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

From ascarpino at openjdk.java.net  Tue Aug 10 17:37:26 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Tue, 10 Aug 2021 17:37:26 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v7]
In-Reply-To: <Wl0H0VpthBPbKaPkMAtN-wVbkkU1zihX3FOwxFmqk70=.f3531fa7-c0a6-45c7-a7aa-351dae787a93@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <QAw4vLz-cgTZdqMFCAd92yK9ar1Kp9KmKHebJXsuWZo=.b68ead2c-5340-41d6-b7c6-3a7405d06f12@github.com>
 <A_dsMP2h3dJxQTH5KhQf_8CNVI3NkJavVsMJWQZvlSM=.52cfb190-f37f-473d-bf2f-20ff97e53d6b@github.com>
 <Wvrw_lfIMcnvvkbb5VchtFjz1azshzL6dh4Qj5cs7Bo=.5520d555-6d6d-4300-9bbc-8fc4889256e1@github.com>
 <Wl0H0VpthBPbKaPkMAtN-wVbkkU1zihX3FOwxFmqk70=.f3531fa7-c0a6-45c7-a7aa-351dae787a93@github.com>
Message-ID: <9OXUE3f362JuaCbixQw2F7Xvpff46K-LF3KVLBWeiSI=.247e6477-c27a-4161-892a-024134aa23b2@github.com>

On Mon, 9 Aug 2021 18:08:53 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> I do not understand this comment
>
> Doesn't implGCMCrypt(...) return an int telling how much bytes it has processed? Then we adjust the index and remain input length with this value. But here we didn't save the return value which looks wrong. Did I miss something?
> 
> Never mind my second comment, I mis-read the code.

Ah.. I see.. yes, it should be included in len

-------------

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

From lucy at openjdk.java.net  Tue Aug 10 20:02:28 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 10 Aug 2021 20:02:28 GMT
Subject: RFR: 8271490: [ppc] [s390]: Crash in
 JavaThread::pd_get_top_frame_for_profiling
In-Reply-To: <bD_GSVWnQEH5L4k08xN_CH7jtbpmHl7b5mwhLb_03lo=.81186ce8-3345-498c-934e-c4bf03bf80ab@github.com>
References: <bD_GSVWnQEH5L4k08xN_CH7jtbpmHl7b5mwhLb_03lo=.81186ce8-3345-498c-934e-c4bf03bf80ab@github.com>
Message-ID: <QGwpZPbMeJJWYIo17kDOUPPO0SrFNcftdmXr7jyL3gc=.a53924f3-1bfb-4193-983b-463a62dcf472@github.com>

On Tue, 10 Aug 2021 14:50:34 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> Please review this pull request. It hardens the code on ppc and s390 against crashes while collecting stack traces for JFR. Stack frame collection in prims/forte.cpp will benefit from this fix as well as it uses the same platform-specific code.
> 
> Testing:
> SAP-internal functional and stress testing. Verifying a positive effect is hard because the targeted crashes occur only very rarely. No negative side effects of the fix have been observed.

The failing Pre-submit tests on Windows x64 are unrelated to this fix. Changes for this fix are in platform-specific files only (os_cpu/linux-ppc, os_cpu/linux-s390, cpu/ppc, cpu/s390). They can't impact Windows x64.

-------------

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

From eastig at amazon.co.uk  Tue Aug 10 21:52:17 2021
From: eastig at amazon.co.uk (Astigeevich, Evgeny)
Date: Tue, 10 Aug 2021 21:52:17 +0000
Subject: RFC: AArch64: Implementing spin pauses with ISB
Message-ID: <3FA517F5-3339-4C99-B9B3-15D733033D39@amazon.com>

Hello everyone.

We?d like to discuss a proposal for implementing spin pauses with the ISB instruction:

https://bugs.openjdk.java.net/browse/JDK-8186670 ?Implement _onSpinWait() intrinsic for AArch64?
https://bugs.openjdk.java.net/browse/JDK-8258604 ?Use 'isb' instruction in SpinPause on linux-aarch64?

In 2017, Dmitry Chuyko from BellSoft proposed to implement onSpinWait() on ARM with the help of the YIELD instruction (see JDK-8186670). The contribution was discussed on the mailing list (http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2017-August/004870.html) but never made it into OpenJDK 10 because at that time there were no hardware YIELD implementations and the exact effect was therefore unknown. Dmitry did a nice writeup and produced some benchmark results (http://cr.openjdk.java.net/~dchuyko/8186670/yield/spinwait.html). He was able to test and measure his implementation only on Cavium ThunderX and Raspberry Pi 3, which both implement YIELD as a NOP. Improvements were therefore minimal.

As I am aware the YIELD instruction is still implemented as a NOP by most of AArch64 vendors. There were experiments to use a sequence of NOPs to emulate x86 PAUSE.
At Amazon experiments with the ISB on Graviton 2 showed it can create a small delay without consuming ALU resources. It is more reliable than NOPs. The experiments resulted in contributions of ISB-based spin pauses to MySQL (https://bugs.mysql.com/bug.php?id=100664) and MongoDb (https://jira.mongodb.org/browse/WT-6872).

We have tested the ISB-based spin pauses for JDK11. Internal customer-based benchmarks showed 3% - 7% improvements in latencies and throughput.
We also used https://github.com/ben-manes/caffeine/wiki/Benchmarks microbenchmarks and a SynchronousQueue microbenchmark (you can find it in https://bugs.openjdk.java.net/browse/JDK-8267502). Caffeine GetPutBenchmark for LinkedHashMap_Lru, which has synchronized accesses to a cache, got +14% - +29% improvement in throughput. The SynchronousQueue microbenchmark, which uses Thread.onSpinWait, got 2.9x improvement.

OpenJDK tip with the ISB-based spin pauses gets similar improvements in Caffeine GetPutBenchmark for LinkedHashMap_Lru. OpenJDK tip java.util.concurrent.SynchronousQueue does not use Thread.onSpinWait. Because of this the SynchronousQueue microbenchmark gets no improvements.

We would like to contribute the ISB-based spin pauses implementation to OpenJDK: SpinPause (https://github.com/corretto/corretto-11/commit/dfb4965877a5810011514bd9294175eccd4b6d0d) and intrinsic (https://github.com/corretto/corretto-11/commit/a49a79bb2e7ac4a2265c51c9fb1c3fcf90dc7c9d).
If there is an interest in the contribution, the open question is whether it should be enabled for all AArch64 implementations or only for Neoverse N1.

Comments welcome!

Thanks,
Evgeny



Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.



From iklam at openjdk.java.net  Tue Aug 10 22:05:57 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 10 Aug 2021 22:05:57 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC
Message-ID: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>

**Overview:**

This is the first step for supporting archived heap objects for non-G1 collectors. We are doing it for EpsilonGC first to iron out the API between GC and CDS. Also we can implement most of the common code (such as copying archived objects into heap), without impacting the overall system stability.

- Only G1 can write archive heap objects into the CDS archive.
- Archived objects are "mapped" by G1, but the mapping operation is quite complex.
- All other collectors will "load" the archive objects, which is much simpler to implement. The trade off is a small start-up penalty and no heap sharing.

Most of the loading code is implemented in heapShared.cpp. The collectors just need to implement the following two CollectedHeap::APIs in 


  virtual bool can_load_archived_objects();
  virtual HeapWord* allocate_loaded_archive_space(size_t size); // typically return a block in old gen


**Implementation:**

- Allocate (from the old gen) a buffer that's large enough to contain all the archived heap objects.
- Inside the CDS archive file, the heap objects are usually divided into 2~4 disjoint regions (there are gaps between them).
- Copy every region in to the buffer consecutively, without any gaps.
- Relocate all the oop fields in all the copied objects, taking into account of the gap removal.
- The archived strings may be relocated by a full GC, but the CDS "shared string table" cannot handle relocation, so we copy the archived strings into the dynamic string table.

**Benchmarking:** 

We can see significant start-up improvement because the module graph can be loaded from CDS.


$ perf stat -r 40 java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx256m -version

Before:  43.1ms
After:   30.2ms


Testing:

- Some general clean up of the test cases.
- Added support for `-vmoptions:-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`: we dump the CDS archive with G1 so we have an archived heap, but run with EpsilonGC to test the new loading code.
- Added a mach5 task to run all CDS tests with the above config. Incompatible test cases are tagged with `@require vm.gc == null`. See changes in CDSOption.java and VMProps.java

-------------

Commit messages:
 - fixed whitespaces
 - Add/update test cases
 - 8270489: Support archived heap objects in EpsilonGC

Changes: https://git.openjdk.java.net/jdk/pull/5074/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5074&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270489
  Stats: 876 lines in 54 files changed: 706 ins; 34 del; 136 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5074.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5074/head:pull/5074

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

From david.holmes at oracle.com  Tue Aug 10 22:39:35 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Aug 2021 08:39:35 +1000
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class
In-Reply-To: <KJ2mYqQ5kEyuylskOlNE-Hoy5zMtE4gPj28LGLd2LLI=.d5afe9dc-310b-496a-8edb-b07971769025@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
 <Mj4Yz85hTIeSI2t4Cse5OzDqyea5ZzOpCJaMg_ys6Co=.c936d3b6-aa3f-423e-a5c2-66b0a62406e2@github.com>
 <KJ2mYqQ5kEyuylskOlNE-Hoy5zMtE4gPj28LGLd2LLI=.d5afe9dc-310b-496a-8edb-b07971769025@github.com>
Message-ID: <e16c6860-4222-b37b-9ace-7c5cd9fb07a3@oracle.com>

On 11/08/2021 3:22 am, Ioi Lam wrote:
> On Tue, 10 Aug 2021 16:37:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> 
>>> Please review this change to remove the now unused CPSlot class.  Uses of CPSlot have been replaced with Symbol*.  The change was tested by running JCK lang and VM tests, Mach5 tiers 1-2 on Linux, Mac OS, and WIndows and Macn5 tiers 3-5 on Linux x64.
>>>
>>> Thanks, Harold
>>
>> src/hotspot/share/oops/constantPool.inline.hpp line 39:
>>
>>> 37:   intptr_t adr = Atomic::load_acquire(obj_at_addr(which));
>>> 38:   assert(adr != 0 || which == 0, "cp entry for klass should not be zero");
>>> 39:   return (Symbol*)adr;
>>
>> I think you can get rid of all slot_at* and replace them with symbol_at().  Since the symbols don't change after the constant pool is initialized, all this volatile isn't needed.  Used to be used to replace Symbol* with Klass* also.  @iklam can confirm.
> 
> `ConstantPool` objects are no modified after the class is linked, and linking is done single threaded. So there's no need to use the `Atomic::load_acquire` in the above code. I agree with Coleen that the above function can be replaced with symbol_at().

The load_acquire should be matching a release_store, so does that mean 
those can be removed too? I'm not clear whether all linking must pass 
through a lock, or there are some lock-free fastpaths that might still 
need acquire/release semantics?

Cheers,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/5070
> 

From iignatyev at openjdk.java.net  Tue Aug 10 23:49:26 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 10 Aug 2021 23:49:26 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC
In-Reply-To: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
Message-ID: <S8EHYr_QOgf8FYoXZY3OPAX9SccLsT0o3aMOweCMx8A=.6e25c4bf-d923-48f2-b7d5-d610fdd9d3a4@github.com>

On Tue, 10 Aug 2021 19:57:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> **Overview:**
> 
> This is the first step for supporting archived heap objects for non-G1 collectors. We are doing it for EpsilonGC first to iron out the API between GC and CDS. Also we can implement most of the common code (such as copying archived objects into heap), without impacting the overall system stability.
> 
> - Only G1 can write archive heap objects into the CDS archive.
> - Archived objects are "mapped" by G1, but the mapping operation is quite complex.
> - All other collectors will "load" the archive objects, which is much simpler to implement. The trade off is a small start-up penalty and no heap sharing.
> 
> Most of the loading code is implemented in heapShared.cpp. The collectors just need to implement the following two CollectedHeap::APIs in 
> 
> 
>   virtual bool can_load_archived_objects();
>   virtual HeapWord* allocate_loaded_archive_space(size_t size); // typically return a block in old gen
> 
> 
> **Implementation:**
> 
> - Allocate (from the old gen) a buffer that's large enough to contain all the archived heap objects.
> - Inside the CDS archive file, the heap objects are usually divided into 2~4 disjoint regions (there are gaps between them).
> - Copy every region in to the buffer consecutively, without any gaps.
> - Relocate all the oop fields in all the copied objects, taking into account of the gap removal.
> - The archived strings may be relocated by a full GC, but the CDS "shared string table" cannot handle relocation, so we copy the archived strings into the dynamic string table.
> 
> **Benchmarking:** 
> 
> We can see significant start-up improvement because the module graph can be loaded from CDS.
> 
> 
> $ perf stat -r 40 java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx256m -version
> 
> Before:  43.1ms
> After:   30.2ms
> 
> 
> Testing:
> 
> - Some general clean up of the test cases.
> - Added support for `-vmoptions:-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`: we dump the CDS archive with G1 so we have an archived heap, but run with EpsilonGC to test the new loading code.
> - Added a mach5 task to run all CDS tests with the above config. Incompatible test cases are tagged with `@require vm.gc == null`. See changes in CDSOption.java and VMProps.java

Changes requested by iignatyev (Reviewer).

test/jtreg-ext/requires/VMProps.java line 303:

> 301:      * @param map - property-value pairs
> 302:      */
> 303:     protected void vmGCforCDS(SafeMap map) {

as this might impact any tests which use `vm.gc` and not just CDS tests, I think it would be better to first check if `vm.gc` is(will be) set to non-null value. given it's done by jtreg in another class and using another instance of Map, we can't just call `Map::contains` and have to check if GC has been explicitly selected by smth like `GC.selected().isSelectedErgonomically()`.

it also might be a good idea to comment at L#124 to indicate that this method overrides `vm.gc` value.

-------------

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

From iklam at openjdk.java.net  Wed Aug 11 06:07:50 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 Aug 2021 06:07:50 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC [v2]
In-Reply-To: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
Message-ID: <j-lv0HkKkf13P3MrGOXwBFs9WQgVjfjZ7FwLCVarqqU=.c1a192ef-3e4b-4cd9-946a-cf2e06a43f73@github.com>

> **Overview:**
> 
> This is the first step for supporting archived heap objects for non-G1 collectors. We are doing it for EpsilonGC first to iron out the API between GC and CDS. Also we can implement most of the common code (such as copying archived objects into heap), without impacting the overall system stability.
> 
> - Only G1 can write archive heap objects into the CDS archive.
> - Archived objects are "mapped" by G1, but the mapping operation is quite complex.
> - All other collectors will "load" the archive objects, which is much simpler to implement. The trade off is a small start-up penalty and no heap sharing.
> 
> Most of the loading code is implemented in heapShared.cpp. The collectors just need to implement the following two CollectedHeap::APIs in 
> 
> 
>   virtual bool can_load_archived_objects();
>   virtual HeapWord* allocate_loaded_archive_space(size_t size); // typically return a block in old gen
> 
> 
> **Implementation:**
> 
> - Allocate (from the old gen) a buffer that's large enough to contain all the archived heap objects.
> - Inside the CDS archive file, the heap objects are usually divided into 2~4 disjoint regions (there are gaps between them).
> - Copy every region in to the buffer consecutively, without any gaps.
> - Relocate all the oop fields in all the copied objects, taking into account of the gap removal.
> - The archived strings may be relocated by a full GC, but the CDS "shared string table" cannot handle relocation, so we copy the archived strings into the dynamic string table.
> 
> **Benchmarking:** 
> 
> We can see significant start-up improvement because the module graph can be loaded from CDS.
> 
> 
> $ perf stat -r 40 java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx256m -version
> 
> Before:  43.1ms
> After:   30.2ms
> 
> 
> Testing:
> 
> - Some general clean up of the test cases.
> - Added support for `-vmoptions:-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`: we dump the CDS archive with G1 so we have an archived heap, but run with EpsilonGC to test the new loading code.
> - Added a mach5 task to run all CDS tests with the above config. Incompatible test cases are tagged with `@require vm.gc == null`. See changes in CDSOption.java and VMProps.java

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

  @iignatev comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5074/files
  - new: https://git.openjdk.java.net/jdk/pull/5074/files/4598d731..503501b8

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

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

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

From iklam at openjdk.java.net  Wed Aug 11 06:07:52 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 Aug 2021 06:07:52 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC [v2]
In-Reply-To: <S8EHYr_QOgf8FYoXZY3OPAX9SccLsT0o3aMOweCMx8A=.6e25c4bf-d923-48f2-b7d5-d610fdd9d3a4@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
 <S8EHYr_QOgf8FYoXZY3OPAX9SccLsT0o3aMOweCMx8A=.6e25c4bf-d923-48f2-b7d5-d610fdd9d3a4@github.com>
Message-ID: <L_isbww4QZu-dqX-ZPsR1-AuZhp6Dpvch8ccew1vNY0=.17680bab-97f9-46a3-af4c-cf22ab93ef94@github.com>

On Tue, 10 Aug 2021 23:45:06 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @iignatev comments
>
> test/jtreg-ext/requires/VMProps.java line 303:
> 
>> 301:      * @param map - property-value pairs
>> 302:      */
>> 303:     protected void vmGCforCDS(SafeMap map) {
> 
> as this might impact any tests which use `vm.gc` and not just CDS tests, I think it would be better to first check if `vm.gc` is(will be) set to non-null value. given it's done by jtreg in another class and using another instance of Map, we can't just call `Map::contains` and have to check if GC has been explicitly selected by smth like `GC.selected().isSelectedErgonomically()`.
> 
> it also might be a good idea to comment at L#124 to indicate that this method overrides `vm.gc` value.

Thanks for the review. I've fixed it as you suggested.

-------------

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

From david.holmes at oracle.com  Wed Aug 11 06:29:50 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Aug 2021 16:29:50 +1000
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class
In-Reply-To: <e16c6860-4222-b37b-9ace-7c5cd9fb07a3@oracle.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
 <Mj4Yz85hTIeSI2t4Cse5OzDqyea5ZzOpCJaMg_ys6Co=.c936d3b6-aa3f-423e-a5c2-66b0a62406e2@github.com>
 <KJ2mYqQ5kEyuylskOlNE-Hoy5zMtE4gPj28LGLd2LLI=.d5afe9dc-310b-496a-8edb-b07971769025@github.com>
 <e16c6860-4222-b37b-9ace-7c5cd9fb07a3@oracle.com>
Message-ID: <b30b819b-58de-a2c3-732a-53f2fb8cb41d@oracle.com>

On 11/08/2021 8:39 am, David Holmes wrote:
> On 11/08/2021 3:22 am, Ioi Lam wrote:
>> On Tue, 10 Aug 2021 16:37:44 GMT, Coleen Phillimore 
>> <coleenp at openjdk.org> wrote:
>>
>>>> Please review this change to remove the now unused CPSlot class.  
>>>> Uses of CPSlot have been replaced with Symbol*.? The change was 
>>>> tested by running JCK lang and VM tests, Mach5 tiers 1-2 on Linux, 
>>>> Mac OS, and WIndows and Macn5 tiers 3-5 on Linux x64.
>>>>
>>>> Thanks, Harold
>>>
>>> src/hotspot/share/oops/constantPool.inline.hpp line 39:
>>>
>>>> 37:?? intptr_t adr = Atomic::load_acquire(obj_at_addr(which));
>>>> 38:?? assert(adr != 0 || which == 0, "cp entry for klass should not 
>>>> be zero");
>>>> 39:?? return (Symbol*)adr;
>>>
>>> I think you can get rid of all slot_at* and replace them with 
>>> symbol_at().? Since the symbols don't change after the constant pool 
>>> is initialized, all this volatile isn't needed.? Used to be used to 
>>> replace Symbol* with Klass* also.? @iklam can confirm.
>>
>> `ConstantPool` objects are no modified after the class is linked, and 
>> linking is done single threaded. So there's no need to use the 
>> `Atomic::load_acquire` in the above code. I agree with Coleen that the 
>> above function can be replaced with symbol_at().
> 
> The load_acquire should be matching a release_store, so does that mean 
> those can be removed too? I'm not clear whether all linking must pass 
> through a lock, or there are some lock-free fastpaths that might still 
> need acquire/release semantics?

Re-sending to see if email breakage is fixed in PR.

David

> Cheers,
> David
> 
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/5070
>>

From shade at openjdk.java.net  Wed Aug 11 08:45:31 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 11 Aug 2021 08:45:31 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC [v2]
In-Reply-To: <j-lv0HkKkf13P3MrGOXwBFs9WQgVjfjZ7FwLCVarqqU=.c1a192ef-3e4b-4cd9-946a-cf2e06a43f73@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
 <j-lv0HkKkf13P3MrGOXwBFs9WQgVjfjZ7FwLCVarqqU=.c1a192ef-3e4b-4cd9-946a-cf2e06a43f73@github.com>
Message-ID: <T2Us2bJw_Mz11vp1C8uJi-0blh7h6Odk66ghjCBAjfk=.8cc5d3e9-f64d-40fb-a067-c4993a2d5c1f@github.com>

On Wed, 11 Aug 2021 06:07:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> **Overview:**
>> 
>> This is the first step for supporting archived heap objects for non-G1 collectors. We are doing it for EpsilonGC first to iron out the API between GC and CDS. Also we can implement most of the common code (such as copying archived objects into heap), without impacting the overall system stability.
>> 
>> - Only G1 can write archive heap objects into the CDS archive.
>> - Archived objects are "mapped" by G1, but the mapping operation is quite complex.
>> - All other collectors will "load" the archive objects, which is much simpler to implement. The trade off is a small start-up penalty and no heap sharing.
>> 
>> Most of the loading code is implemented in heapShared.cpp. The collectors just need to implement the following two CollectedHeap::APIs in 
>> 
>> 
>>   virtual bool can_load_archived_objects();
>>   virtual HeapWord* allocate_loaded_archive_space(size_t size); // typically return a block in old gen
>> 
>> 
>> **Implementation:**
>> 
>> - Allocate (from the old gen) a buffer that's large enough to contain all the archived heap objects.
>> - Inside the CDS archive file, the heap objects are usually divided into 2~4 disjoint regions (there are gaps between them).
>> - Copy every region in to the buffer consecutively, without any gaps.
>> - Relocate all the oop fields in all the copied objects, taking into account of the gap removal.
>> - The archived strings may be relocated by a full GC, but the CDS "shared string table" cannot handle relocation, so we copy the archived strings into the dynamic string table.
>> 
>> **Benchmarking:** 
>> 
>> We can see significant start-up improvement because the module graph can be loaded from CDS.
>> 
>> 
>> $ perf stat -r 40 java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx256m -version
>> 
>> Before:  43.1ms
>> After:   30.2ms
>> 
>> 
>> Testing:
>> 
>> - Some general clean up of the test cases.
>> - Added support for `-vmoptions:-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`: we dump the CDS archive with G1 so we have an archived heap, but run with EpsilonGC to test the new loading code.
>> - Added a mach5 task to run all CDS tests with the above config. Incompatible test cases are tagged with `@require vm.gc == null`. See changes in CDSOption.java and VMProps.java
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @iignatev comments

Interesting! Cursory review follows.

src/hotspot/share/cds/heapShared.hpp line 152:

> 150:   // - Mapped: (G1 only) the regions are directly mapped into the heap
> 151:   // - Loaded: At VM start-up, the objects in the heap regions are copied into the
> 152:   //           heap's old generation. This is easier to implement than mapping but

I'd refrain from saying "heap's old generation", as the interface apparently gives the GC freedom in putting the things where it can.

src/hotspot/share/gc/epsilon/epsilonHeap.cpp line 3:

> 1: /*
> 2:  * Copyright (c) 2017, 2020, Red Hat, Inc. All rights reserved.
> 3:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.

Here and later: please update Red Hat's copyright year instead. (Like we do for mostly-Oracle files in other cases).

src/hotspot/share/gc/epsilon/epsilonHeap.cpp line 155:

> 153: 
> 154:   // Allocation successful, update counters
> 155:   if (Metaspace::initialized()) {

Feels odd to protect this entire block. It handles generic allocations, not only the metaspace. (I suspect this is only relevant during the initial allocation at startup, but it still looks weird). Would moving a check to `EpsilonMonitoringSupport::update_counters()` and protecting `MetaspaceCounters::update_performance_counters();` there be enough?

src/hotspot/share/gc/epsilon/epsilonHeap.cpp line 163:

> 161: 
> 162:   // ...and print the occupancy line, if needed
> 163:   if (Metaspace::initialized()) {

Ditto here. Maybe moving this check to `EpsilonHeap::print_metaspace_info()` and printing a relevant `log_info(gc, metaspace)` is better.

test/hotspot/jtreg/runtime/cds/appcds/TestEpsilonGCWithCDS.java line 28:

> 26:  * @bug 8234679
> 27:  * @requires vm.cds
> 28:  * @requires vm.bits == 64

Is this test/support really 64-bit specific? I think GHA would test 32-bit Epsilon in `tier1`, not sure about this test, though.

test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.

Here and later: for the files with no changes, no need to update this line, I think.

test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/FlagCombo.java line 29:

> 27:  * @summary Test relevant combinations of command line flags with shared strings
> 28:  * @requires vm.cds.archived.java.heap & vm.hasJFR
> 29:  * @requires vm.gc == null

Here and later: feels like these changes can be forked out into a separate testbug-only PR? Igor did quite a few touchups already for the tests that set their own options.

-------------

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

From aph at openjdk.java.net  Wed Aug 11 13:39:43 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 11 Aug 2021 13:39:43 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v8]
In-Reply-To: <VWASAkdLb9zt1v6xhyLwTVzM2B3-et1JN1njFlRTy5E=.1a3700ff-5bad-4838-bb53-83b8a3fcf644@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <VWASAkdLb9zt1v6xhyLwTVzM2B3-et1JN1njFlRTy5E=.1a3700ff-5bad-4838-bb53-83b8a3fcf644@github.com>
Message-ID: <9yDdae086hUOXw_NhC2a2oMICfUToBTw_hP5TmlFKlM=.991d5969-f196-46c4-98fd-050ff14f45a8@github.com>

On Mon, 9 Aug 2021 15:49:07 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewiew update

src/hotspot/cpu/x86/macroAssembler_x86_aes.cpp line 1682:

> 1680:     vpshufb(AAD_HASHx, AAD_HASHx, xmm24, Assembler::AVX_128bit);
> 1681: 
> 1682:     // Compute #rounds for AES based on the length of the key array

This is a bit of a hack. Wouldn't it make more sense to pass in the array oop, then derive both the length and the address of the base of the key array from the oop, rather than using a negative offset from the base address?

-------------

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

From aph at openjdk.java.net  Wed Aug 11 14:18:30 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 11 Aug 2021 14:18:30 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v8]
In-Reply-To: <VWASAkdLb9zt1v6xhyLwTVzM2B3-et1JN1njFlRTy5E=.1a3700ff-5bad-4838-bb53-83b8a3fcf644@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <VWASAkdLb9zt1v6xhyLwTVzM2B3-et1JN1njFlRTy5E=.1a3700ff-5bad-4838-bb53-83b8a3fcf644@github.com>
Message-ID: <TAnQZuCU-rVz34SVEbfv1rIk07wPYCmV9MmuXPDwhOk=.8862a1f7-fa1d-49c3-bb65-48b7c1407671@github.com>

On Mon, 9 Aug 2021 15:49:07 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewiew update

src/hotspot/cpu/x86/macroAssembler_x86_aes.cpp line 1682:

> 1680:     vpshufb(AAD_HASHx, AAD_HASHx, xmm24, Assembler::AVX_128bit);
> 1681: 
> 1682:     // Compute #rounds for AES based on the length of the key array

Forget that, it's done everywhere. Deleted.

-------------

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

From coleenp at openjdk.java.net  Wed Aug 11 16:32:51 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 11 Aug 2021 16:32:51 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v10]
In-Reply-To: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
Message-ID: <FA4UIaAKvYoDhG9R_tE0Y8DXD_ZuutvmjzX3JNv1Vwg=.387569b8-5fd4-4649-bfdd-e6c29c122ff4@github.com>

> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
> 
> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).

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

  fix typo in EIIE message.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4996/files
  - new: https://git.openjdk.java.net/jdk/pull/4996/files/de7a9999..e7b739ae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4996&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4996&range=08-09

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

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

From hseigel at openjdk.java.net  Wed Aug 11 16:44:48 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 11 Aug 2021 16:44:48 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class [v2]
In-Reply-To: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
Message-ID: <EgUoha3S3UBqYA6g1hqtPaZ7aYuuzCa8sfBiWs1Lots=.2d0958eb-e9d4-4efb-af54-499afac280ab@github.com>

> Please review this change to remove the now unused CPSlot class.  Uses of CPSlot have been replaced with Symbol*.  The change was tested by running JCK lang and VM tests, Mach5 tiers 1-2 on Linux, Mac OS, and WIndows and Macn5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

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

  Remove slot_at()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5070/files
  - new: https://git.openjdk.java.net/jdk/pull/5070/files/024d16f6..324677d2

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

  Stats: 26 lines in 3 files changed: 4 ins; 17 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5070.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5070/head:pull/5070

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

From hseigel at openjdk.java.net  Wed Aug 11 16:47:24 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 11 Aug 2021 16:47:24 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class [v2]
In-Reply-To: <EgUoha3S3UBqYA6g1hqtPaZ7aYuuzCa8sfBiWs1Lots=.2d0958eb-e9d4-4efb-af54-499afac280ab@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
 <EgUoha3S3UBqYA6g1hqtPaZ7aYuuzCa8sfBiWs1Lots=.2d0958eb-e9d4-4efb-af54-499afac280ab@github.com>
Message-ID: <Oy4NNPtPUrlzu1QBTgGsjbjxov8zVDG0PBctvgweOIE=.32fc756e-9125-45dc-b962-00cd49168c19@github.com>

On Wed, 11 Aug 2021 16:44:48 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this change to remove the now unused CPSlot class.  Uses of CPSlot have been replaced with Symbol*.  The change was tested by running JCK lang and VM tests, Mach5 tiers 1-2 on Linux, Mac OS, and WIndows and Macn5 tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove slot_at()

Thanks Coleen, Ioi, and David for looking at this.
Please review this new commit that removes function slot_at() and, in most cases, replaces calls to slot_at() with calls to symbol_at().  Note that unresolved_strings functions need to call symbol_at_addr(), instead of symbol_at() because symbol_at() asserts if the cp tag is not utf8.

Thanks, Harold

-------------

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

From svkamath at openjdk.java.net  Wed Aug 11 17:49:57 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Wed, 11 Aug 2021 17:49:57 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v9]
In-Reply-To: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
Message-ID: <EXV5ixX0HPmleB3jvoPCAwv69v-JdFPlK8XZwI5Sa0w=.a1ea2f7f-9bcb-42c8-9293-2b9d9c7c9927@github.com>

> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
> Performance gain of ~1.5x - 2x for message sizes 8k and above.

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

  comment update

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4019/files
  - new: https://git.openjdk.java.net/jdk/pull/4019/files/ecf8e6d7..112e3fce

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=07-08

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

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

From iklam at openjdk.java.net  Wed Aug 11 18:24:27 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 Aug 2021 18:24:27 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class [v2]
In-Reply-To: <EgUoha3S3UBqYA6g1hqtPaZ7aYuuzCa8sfBiWs1Lots=.2d0958eb-e9d4-4efb-af54-499afac280ab@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
 <EgUoha3S3UBqYA6g1hqtPaZ7aYuuzCa8sfBiWs1Lots=.2d0958eb-e9d4-4efb-af54-499afac280ab@github.com>
Message-ID: <glvU-SPVOkZC-BYqVirK7BqF1F-CLDsJMiApWDND-HM=.57300e32-f8e1-4175-9879-668db35a1e32@github.com>

On Wed, 11 Aug 2021 16:44:48 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this change to remove the now unused CPSlot class.  Uses of CPSlot have been replaced with Symbol*.  The change was tested by running JCK lang and VM tests, Mach5 tiers 1-2 on Linux, Mac OS, and WIndows and Macn5 tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove slot_at()

LGTM.

src/hotspot/share/memory/metaspaceClosure.hpp line 132:

> 130:     address obj() const {
> 131:       // In some rare cases we store some flags in the lowest 2 bits of a
> 132:       // MetaspaceObj pointer. Unmask these when manipulating the pointer.

I think `FLAG_MASK` and `flag_bits()` can be removed completely. It was used only for handling the CPSlot during CDS dump. I added the following and all CDS tests passed.


       uintx p = (uintx)*mpp();
+      assert((p & FLAG_MASK) == 0, "must be");
       return (address)(p & (~FLAG_MASK));


If you want, I can do the removal in a separate PR.

src/hotspot/share/oops/constantPool.hpp line 324:

> 322:   void unresolved_string_at_put(int which, Symbol* s) {
> 323:     assert(s->refcount() != 0, "should have nonzero refcount");
> 324:     tag_at_put(which, JVM_CONSTANT_String);

Maybe a comment here that release_tag_at_put is not needed here because this happens only when constructing a ConstantPool in a single thread, with no possibility of concurrent access?

-------------

Marked as reviewed by iklam (Reviewer).

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

From coleenp at openjdk.java.net  Wed Aug 11 18:47:26 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 11 Aug 2021 18:47:26 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class [v2]
In-Reply-To: <EgUoha3S3UBqYA6g1hqtPaZ7aYuuzCa8sfBiWs1Lots=.2d0958eb-e9d4-4efb-af54-499afac280ab@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
 <EgUoha3S3UBqYA6g1hqtPaZ7aYuuzCa8sfBiWs1Lots=.2d0958eb-e9d4-4efb-af54-499afac280ab@github.com>
Message-ID: <h1p7Zmcc0OBju2HD733hlKfvuZaHPqDUThkZbwf7TzA=.2bf665b3-6d34-4e5d-a58a-7300f100f47a@github.com>

On Wed, 11 Aug 2021 16:44:48 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this change to remove the now unused CPSlot class.  Uses of CPSlot have been replaced with Symbol*.  The change was tested by running JCK lang and VM tests, Mach5 tiers 1-2 on Linux, Mac OS, and WIndows and Macn5 tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove slot_at()

Looks good! So happy to see the slot_at code go away.

-------------

Marked as reviewed by coleenp (Reviewer).

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

From hseigel at openjdk.java.net  Wed Aug 11 19:29:42 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 11 Aug 2021 19:29:42 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class [v2]
In-Reply-To: <EgUoha3S3UBqYA6g1hqtPaZ7aYuuzCa8sfBiWs1Lots=.2d0958eb-e9d4-4efb-af54-499afac280ab@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
 <EgUoha3S3UBqYA6g1hqtPaZ7aYuuzCa8sfBiWs1Lots=.2d0958eb-e9d4-4efb-af54-499afac280ab@github.com>
Message-ID: <1gYECfmIVnJbRDjEsFSwpb6Kaaq1smrOUqVEtPS32mw=.ebba2819-d47c-4d8e-bfe3-80ae6c7cbcc3@github.com>

On Wed, 11 Aug 2021 16:44:48 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this change to remove the now unused CPSlot class.  Uses of CPSlot have been replaced with Symbol*.  The change was tested by running JCK lang and VM tests, Mach5 tiers 1-2 on Linux, Mac OS, and WIndows and Macn5 tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove slot_at()

Thanks Ioi and Coleen for reviewing this.

-------------

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

From hseigel at openjdk.java.net  Wed Aug 11 19:29:41 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 11 Aug 2021 19:29:41 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class [v3]
In-Reply-To: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
Message-ID: <0XzPVfLD9XfdYfCa5TlYYJyPs9czdupMp_e2GrGNabE=.38451d7f-2a56-4656-a78c-6597fec9503b@github.com>

> Please review this change to remove the now unused CPSlot class.  Uses of CPSlot have been replaced with Symbol*.  The change was tested by running JCK lang and VM tests, Mach5 tiers 1-2 on Linux, Mac OS, and WIndows and Macn5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

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

  add comment for unresolved_string_at_put()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5070/files
  - new: https://git.openjdk.java.net/jdk/pull/5070/files/324677d2..42afa811

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

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

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

From hseigel at openjdk.java.net  Wed Aug 11 19:29:44 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 11 Aug 2021 19:29:44 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class [v2]
In-Reply-To: <glvU-SPVOkZC-BYqVirK7BqF1F-CLDsJMiApWDND-HM=.57300e32-f8e1-4175-9879-668db35a1e32@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
 <EgUoha3S3UBqYA6g1hqtPaZ7aYuuzCa8sfBiWs1Lots=.2d0958eb-e9d4-4efb-af54-499afac280ab@github.com>
 <glvU-SPVOkZC-BYqVirK7BqF1F-CLDsJMiApWDND-HM=.57300e32-f8e1-4175-9879-668db35a1e32@github.com>
Message-ID: <_JNaKOqu2vX6aMwA_dLv84zY4YlGnFHxB40r-nre50o=.a1a71810-9e9c-41be-8bd6-68b88ffa4b0e@github.com>

On Wed, 11 Aug 2021 18:15:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove slot_at()
>
> src/hotspot/share/memory/metaspaceClosure.hpp line 132:
> 
>> 130:     address obj() const {
>> 131:       // In some rare cases we store some flags in the lowest 2 bits of a
>> 132:       // MetaspaceObj pointer. Unmask these when manipulating the pointer.
> 
> I think `FLAG_MASK` and `flag_bits()` can be removed completely. It was used only for handling the CPSlot during CDS dump. I added the following and all CDS tests passed.
> 
> 
>        uintx p = (uintx)*mpp();
> +      assert((p & FLAG_MASK) == 0, "must be");
>        return (address)(p & (~FLAG_MASK));
> 
> 
> If you want, I can do the removal in a separate PR.

I like the idea of doing this as a separate PR.

> src/hotspot/share/oops/constantPool.hpp line 324:
> 
>> 322:   void unresolved_string_at_put(int which, Symbol* s) {
>> 323:     assert(s->refcount() != 0, "should have nonzero refcount");
>> 324:     tag_at_put(which, JVM_CONSTANT_String);
> 
> Maybe a comment here that release_tag_at_put is not needed here because this happens only when constructing a ConstantPool in a single thread, with no possibility of concurrent access?

done.

-------------

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

From iklam at openjdk.java.net  Wed Aug 11 19:55:24 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 Aug 2021 19:55:24 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class [v3]
In-Reply-To: <0XzPVfLD9XfdYfCa5TlYYJyPs9czdupMp_e2GrGNabE=.38451d7f-2a56-4656-a78c-6597fec9503b@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
 <0XzPVfLD9XfdYfCa5TlYYJyPs9czdupMp_e2GrGNabE=.38451d7f-2a56-4656-a78c-6597fec9503b@github.com>
Message-ID: <ldrnSFt8R-MS595eNsCY3xul9rBYk-avJCTlNReLXE8=.a8f76ab6-86c5-4068-b3f1-44058e83b217@github.com>

On Wed, 11 Aug 2021 19:29:41 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this change to remove the now unused CPSlot class.  Uses of CPSlot have been replaced with Symbol*.  The change was tested by running JCK lang and VM tests, Mach5 tiers 1-2 on Linux, Mac OS, and WIndows and Macn5 tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comment for unresolved_string_at_put()

Marked as reviewed by iklam (Reviewer).

-------------

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

From iklam at openjdk.java.net  Wed Aug 11 19:59:25 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 Aug 2021 19:59:25 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class [v2]
In-Reply-To: <_JNaKOqu2vX6aMwA_dLv84zY4YlGnFHxB40r-nre50o=.a1a71810-9e9c-41be-8bd6-68b88ffa4b0e@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
 <EgUoha3S3UBqYA6g1hqtPaZ7aYuuzCa8sfBiWs1Lots=.2d0958eb-e9d4-4efb-af54-499afac280ab@github.com>
 <glvU-SPVOkZC-BYqVirK7BqF1F-CLDsJMiApWDND-HM=.57300e32-f8e1-4175-9879-668db35a1e32@github.com>
 <_JNaKOqu2vX6aMwA_dLv84zY4YlGnFHxB40r-nre50o=.a1a71810-9e9c-41be-8bd6-68b88ffa4b0e@github.com>
Message-ID: <npKp-Nm0bVUL7laSn7mSRkGPYp66VZYHjneBGCgegoY=.8aee8d27-9192-4a0a-a769-3eb99e3513df@github.com>

On Wed, 11 Aug 2021 19:26:15 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> src/hotspot/share/memory/metaspaceClosure.hpp line 132:
>> 
>>> 130:     address obj() const {
>>> 131:       // In some rare cases we store some flags in the lowest 2 bits of a
>>> 132:       // MetaspaceObj pointer. Unmask these when manipulating the pointer.
>> 
>> I think `FLAG_MASK` and `flag_bits()` can be removed completely. It was used only for handling the CPSlot during CDS dump. I added the following and all CDS tests passed.
>> 
>> 
>>        uintx p = (uintx)*mpp();
>> +      assert((p & FLAG_MASK) == 0, "must be");
>>        return (address)(p & (~FLAG_MASK));
>> 
>> 
>> If you want, I can do the removal in a separate PR.
>
> I like the idea of doing this as a separate PR.

I created https://bugs.openjdk.java.net/browse/JDK-8272343.

-------------

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

From iklam at openjdk.java.net  Wed Aug 11 20:49:29 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 Aug 2021 20:49:29 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v10]
In-Reply-To: <FA4UIaAKvYoDhG9R_tE0Y8DXD_ZuutvmjzX3JNv1Vwg=.387569b8-5fd4-4649-bfdd-e6c29c122ff4@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <FA4UIaAKvYoDhG9R_tE0Y8DXD_ZuutvmjzX3JNv1Vwg=.387569b8-5fd4-4649-bfdd-e6c29c122ff4@github.com>
Message-ID: <ILa4QgyCKM0_DxuDu7NyPzlTJN_rkhMyElUxTN8UEDg=.ec76e723-d3f1-4ffe-b319-7e39c758b162@github.com>

On Wed, 11 Aug 2021 16:32:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
>> 
>> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo in EIIE message.

Looks good overall. Some minor nits.

src/hotspot/share/oops/instanceKlass.cpp line 1022:

> 1020: 
> 1021: void InstanceKlass::add_initialization_error(Handle exception, TRAPS) {
> 1022:   bool created = false;

Since this function will never throw, by our new convention, it should not be declared TRAPS, and the thread parameter should not be the last.

src/hotspot/share/oops/instanceKlass.cpp line 1028:

> 1026:   // this would be still be helpful.
> 1027:   Handle cause = java_lang_Throwable::get_cause_with_stack_trace(exception, THREAD);
> 1028:   CLEAR_PENDING_EXCEPTION;

If new exceptions happened inside `get_cause_with_stack_trace`, `cause` will be null here. Maybe proceed to the following only if `cause` is not null?

src/hotspot/share/oops/instanceKlass.cpp line 1109:

> 1107:       ResourceMark rm(THREAD);
> 1108:       Handle cause(THREAD, get_initialization_error(THREAD));
> 1109:       CLEAR_PENDING_EXCEPTION; // ignore any OOM here.

`get_initialization_error()` doesn't throw any error. Is `CLEAR_PENDING_EXCEPTION` really needed here?

-------------

Changes requested by iklam (Reviewer).

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

From valeriep at openjdk.java.net  Wed Aug 11 21:46:30 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 11 Aug 2021 21:46:30 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v9]
In-Reply-To: <EXV5ixX0HPmleB3jvoPCAwv69v-JdFPlK8XZwI5Sa0w=.a1ea2f7f-9bcb-42c8-9293-2b9d9c7c9927@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <EXV5ixX0HPmleB3jvoPCAwv69v-JdFPlK8XZwI5Sa0w=.a1ea2f7f-9bcb-42c8-9293-2b9d9c7c9927@github.com>
Message-ID: <IzDiOgXTWvoVNMmTZkugg4OOcbX2P8tosp4zUv2pFts=.50f551f0-b69a-4ca3-bac7-8a774b390c54@github.com>

On Wed, 11 Aug 2021 17:49:57 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment update

Java changes look good. Thanks.

-------------

Marked as reviewed by valeriep (Reviewer).

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

From iklam at openjdk.java.net  Wed Aug 11 23:34:09 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 Aug 2021 23:34:09 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC [v3]
In-Reply-To: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
Message-ID: <_J0BNLWCxKDLB_3avbkI4xnyHkFNk6vysVyrrc11Q3Q=.444a6d80-c734-4e71-9892-5046b166cc29@github.com>

> **Overview:**
> 
> This is the first step for supporting archived heap objects for non-G1 collectors. We are doing it for EpsilonGC first to iron out the API between GC and CDS. Also we can implement most of the common code (such as copying archived objects into heap), without impacting the overall system stability.
> 
> - Only G1 can write archive heap objects into the CDS archive.
> - Archived objects are "mapped" by G1, but the mapping operation is quite complex.
> - All other collectors will "load" the archive objects, which is much simpler to implement. The trade off is a small start-up penalty and no heap sharing.
> 
> Most of the loading code is implemented in heapShared.cpp. The collectors just need to implement the following two CollectedHeap::APIs in 
> 
> 
>   virtual bool can_load_archived_objects();
>   virtual HeapWord* allocate_loaded_archive_space(size_t size); // typically return a block in old gen
> 
> 
> **Implementation:**
> 
> - Allocate (from the old gen) a buffer that's large enough to contain all the archived heap objects.
> - Inside the CDS archive file, the heap objects are usually divided into 2~4 disjoint regions (there are gaps between them).
> - Copy every region in to the buffer consecutively, without any gaps.
> - Relocate all the oop fields in all the copied objects, taking into account of the gap removal.
> - The archived strings may be relocated by a full GC, but the CDS "shared string table" cannot handle relocation, so we copy the archived strings into the dynamic string table.
> 
> **Benchmarking:** 
> 
> We can see significant start-up improvement because the module graph can be loaded from CDS.
> 
> 
> $ perf stat -r 40 java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx256m -version
> 
> Before:  43.1ms
> After:   30.2ms
> 
> 
> Testing:
> 
> - Some general clean up of the test cases.
> - Added support for `-vmoptions:-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`: we dump the CDS archive with G1 so we have an archived heap, but run with EpsilonGC to test the new loading code.
> - Added a mach5 task to run all CDS tests with the above config. Incompatible test cases are tagged with `@require vm.gc == null`. See changes in CDSOption.java and VMProps.java

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

  @shipilev comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5074/files
  - new: https://git.openjdk.java.net/jdk/pull/5074/files/503501b8..ae354070

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

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

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

From iklam at openjdk.java.net  Wed Aug 11 23:34:16 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 Aug 2021 23:34:16 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC [v2]
In-Reply-To: <T2Us2bJw_Mz11vp1C8uJi-0blh7h6Odk66ghjCBAjfk=.8cc5d3e9-f64d-40fb-a067-c4993a2d5c1f@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
 <j-lv0HkKkf13P3MrGOXwBFs9WQgVjfjZ7FwLCVarqqU=.c1a192ef-3e4b-4cd9-946a-cf2e06a43f73@github.com>
 <T2Us2bJw_Mz11vp1C8uJi-0blh7h6Odk66ghjCBAjfk=.8cc5d3e9-f64d-40fb-a067-c4993a2d5c1f@github.com>
Message-ID: <J6oVuxwmM5kW6az_-4AUDegJFfNjQJJBfxlY894TlbY=.2090005c-c7d5-43f0-8b8c-6817818b3a06@github.com>

On Wed, 11 Aug 2021 08:31:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @iignatev comments
>
> src/hotspot/share/cds/heapShared.hpp line 152:
> 
>> 150:   // - Mapped: (G1 only) the regions are directly mapped into the heap
>> 151:   // - Loaded: At VM start-up, the objects in the heap regions are copied into the
>> 152:   //           heap's old generation. This is easier to implement than mapping but
> 
> I'd refrain from saying "heap's old generation", as the interface apparently gives the GC freedom in putting the things where it can.

I've updated the comments.

> src/hotspot/share/gc/epsilon/epsilonHeap.cpp line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2017, 2020, Red Hat, Inc. All rights reserved.
>> 3:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
> 
> Here and later: please update Red Hat's copyright year instead. (Like we do for mostly-Oracle files in other cases).

Changed as you requested.

> src/hotspot/share/gc/epsilon/epsilonHeap.cpp line 155:
> 
>> 153: 
>> 154:   // Allocation successful, update counters
>> 155:   if (Metaspace::initialized()) {
> 
> Feels odd to protect this entire block. It handles generic allocations, not only the metaspace. (I suspect this is only relevant during the initial allocation at startup, but it still looks weird). Would moving a check to `EpsilonMonitoringSupport::update_counters()` and protecting `MetaspaceCounters::update_performance_counters();` there be enough?

I can't move `if (Metaspace::initialized())` into `EpsilonMonitoringSupport::update_counters()` because the code in this function also updates the global variable `_last_counter_update`.

> test/hotspot/jtreg/runtime/cds/appcds/TestEpsilonGCWithCDS.java line 28:
> 
>> 26:  * @bug 8234679
>> 27:  * @requires vm.cds
>> 28:  * @requires vm.bits == 64
> 
> Is this test/support really 64-bit specific? I think GHA would test 32-bit Epsilon in `tier1`, not sure about this test, though.

I removed this line. 64 bit is not required by this test.

> test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
> 
> Here and later: for the files with no changes, no need to update this line, I think.

I reverted the files with only copyright year changes.

> test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/FlagCombo.java line 29:
> 
>> 27:  * @summary Test relevant combinations of command line flags with shared strings
>> 28:  * @requires vm.cds.archived.java.heap & vm.hasJFR
>> 29:  * @requires vm.gc == null
> 
> Here and later: feels like these changes can be forked out into a separate testbug-only PR? Igor did quite a few touchups already for the tests that set their own options.

I will move most of the test file changes into a separate RFE. [JDK-8272348](https://bugs.openjdk.java.net/browse/JDK-8272348): Update CDS tests in anticipation of JDK-8270489

-------------

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

From dholmes at openjdk.java.net  Thu Aug 12 00:33:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 12 Aug 2021 00:33:28 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC [v3]
In-Reply-To: <_J0BNLWCxKDLB_3avbkI4xnyHkFNk6vysVyrrc11Q3Q=.444a6d80-c734-4e71-9892-5046b166cc29@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
 <_J0BNLWCxKDLB_3avbkI4xnyHkFNk6vysVyrrc11Q3Q=.444a6d80-c734-4e71-9892-5046b166cc29@github.com>
Message-ID: <0yJnNw_Y6euJ7FyDFhQ-qM1YgotNM0bYdhU6BRD7X8I=.8fca68e8-445a-40d4-88e2-b84bdee3d5cd@github.com>

On Wed, 11 Aug 2021 23:34:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> **Overview:**
>> 
>> This is the first step for supporting archived heap objects for non-G1 collectors. We are doing it for EpsilonGC first to iron out the API between GC and CDS. Also we can implement most of the common code (such as copying archived objects into heap), without impacting the overall system stability.
>> 
>> - Only G1 can write archive heap objects into the CDS archive.
>> - Archived objects are "mapped" by G1, but the mapping operation is quite complex.
>> - All other collectors will "load" the archive objects, which is much simpler to implement. The trade off is a small start-up penalty and no heap sharing.
>> 
>> Most of the loading code is implemented in heapShared.cpp. The collectors just need to implement the following two `CollectedHeap` APIs in 
>> 
>> 
>>   virtual bool can_load_archived_objects();
>>   virtual HeapWord* allocate_loaded_archive_space(size_t size); // typically return a block in old gen
>> 
>> 
>> **Implementation:**
>> 
>> - Allocate (from the old gen) a buffer that's large enough to contain all the archived heap objects.
>> - Inside the CDS archive file, the heap objects are usually divided into 2~4 disjoint regions (there are gaps between them).
>> - Copy every region in to the buffer consecutively, without any gaps.
>> - Relocate all the oop fields in all the copied objects, taking into account of the gap removal.
>> - The archived strings may be relocated by a full GC, but the CDS "shared string table" cannot handle relocation, so we copy the archived strings into the dynamic string table.
>> 
>> **Benchmarking:** 
>> 
>> We can see significant start-up improvement because the module graph can be loaded from CDS.
>> 
>> 
>> $ perf stat -r 40 java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx256m -version
>> 
>> Before:  43.1ms
>> After:   30.2ms
>> 
>> 
>> Testing:
>> 
>> - Some general clean up of the test cases.
>> - Added support for `-vmoptions:-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`: we dump the CDS archive with G1 so we have an archived heap, but run with EpsilonGC to test the new loading code.
>> - Added a mach5 task to run all CDS tests with the above config. Incompatible test cases are tagged with `@require vm.gc == null`. See changes in CDSOption.java and VMProps.java
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @shipilev comments

test/hotspot/jtreg/runtime/cds/ServiceLoaderTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.

Incorrect copyright change: should be 2020, 2021,

-------------

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

From dholmes at openjdk.java.net  Thu Aug 12 00:52:23 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 12 Aug 2021 00:52:23 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class [v3]
In-Reply-To: <0XzPVfLD9XfdYfCa5TlYYJyPs9czdupMp_e2GrGNabE=.38451d7f-2a56-4656-a78c-6597fec9503b@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
 <0XzPVfLD9XfdYfCa5TlYYJyPs9czdupMp_e2GrGNabE=.38451d7f-2a56-4656-a78c-6597fec9503b@github.com>
Message-ID: <jsc7pVv7RI74Uw7K7Qcj9LIy0DhrnvEILGo1z3p6Llk=.a335646b-d252-4f6c-8573-c424d690a14d@github.com>

On Wed, 11 Aug 2021 19:29:41 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this change to remove the now unused CPSlot class.  Uses of CPSlot have been replaced with Symbol*.  The change was tested by running JCK lang and VM tests, Mach5 tiers 1-2 on Linux, Mac OS, and WIndows and Macn5 tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comment for unresolved_string_at_put()

Hi Harold,

Cleanup looks good. A couple of minor items below.

Thanks,
David

src/hotspot/share/memory/iterator.hpp line 347:

> 345:   static Symbol* load_symbol(Symbol** p) {
> 346:     return *p;
> 347:   }

Do we even need load_symbol now?

src/hotspot/share/oops/constantPool.hpp line 323:

> 321: 
> 322:   // Note that release_tag_at_put is not needed here because this is called only when
> 323:   // constructing a ConstantPool in a single thread, with no possibility of concurrent access.

Can we put the comment inside the method please, prior to the `tag_at_put` call.

src/hotspot/share/oops/symbol.hpp line 48:

> 46: // in the SymbolTable bucket (the _literal field in HashtableEntry)
> 47: // that points to the Symbol.  All other stores of a Symbol*
> 48: // to a field of a persistent variable (e.g., the _name filed in

Can you fix the typo here please: filed -> field

-------------

Marked as reviewed by dholmes (Reviewer).

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

From coleenp at openjdk.java.net  Thu Aug 12 00:53:30 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 12 Aug 2021 00:53:30 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v10]
In-Reply-To: <ILa4QgyCKM0_DxuDu7NyPzlTJN_rkhMyElUxTN8UEDg=.ec76e723-d3f1-4ffe-b319-7e39c758b162@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <FA4UIaAKvYoDhG9R_tE0Y8DXD_ZuutvmjzX3JNv1Vwg=.387569b8-5fd4-4649-bfdd-e6c29c122ff4@github.com>
 <ILa4QgyCKM0_DxuDu7NyPzlTJN_rkhMyElUxTN8UEDg=.ec76e723-d3f1-4ffe-b319-7e39c758b162@github.com>
Message-ID: <S0gDlSNVKVeAOGLh0uYtSWRpj_XASNGpI2hh3w4C3F8=.87d6915e-0b3a-4344-a9d2-d17eb5888189@github.com>

On Wed, 11 Aug 2021 20:33:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo in EIIE message.
>
> src/hotspot/share/oops/instanceKlass.cpp line 1109:
> 
>> 1107:       ResourceMark rm(THREAD);
>> 1108:       Handle cause(THREAD, get_initialization_error(THREAD));
>> 1109:       CLEAR_PENDING_EXCEPTION; // ignore any OOM here.
> 
> `get_initialization_error()` doesn't throw any error. Is `CLEAR_PENDING_EXCEPTION` really needed here?

It does not throw any error anymore.  Removed that line.

-------------

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

From coleenp at openjdk.java.net  Thu Aug 12 00:58:32 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 12 Aug 2021 00:58:32 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v10]
In-Reply-To: <ILa4QgyCKM0_DxuDu7NyPzlTJN_rkhMyElUxTN8UEDg=.ec76e723-d3f1-4ffe-b319-7e39c758b162@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <FA4UIaAKvYoDhG9R_tE0Y8DXD_ZuutvmjzX3JNv1Vwg=.387569b8-5fd4-4649-bfdd-e6c29c122ff4@github.com>
 <ILa4QgyCKM0_DxuDu7NyPzlTJN_rkhMyElUxTN8UEDg=.ec76e723-d3f1-4ffe-b319-7e39c758b162@github.com>
Message-ID: <QVZpkIf1vHzOrf6DAqFH1-Gc9fQg1AQDiK0Cr-l90zM=.8479285f-fe2a-4ce1-87e3-9eb31c01f280@github.com>

On Wed, 11 Aug 2021 20:38:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo in EIIE message.
>
> src/hotspot/share/oops/instanceKlass.cpp line 1022:
> 
>> 1020: 
>> 1021: void InstanceKlass::add_initialization_error(Handle exception, TRAPS) {
>> 1022:   bool created = false;
> 
> Since this function will never throw, by our new convention, it should not be declared TRAPS, and the thread parameter should not be the last.

Ok, I changed it around.

-------------

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

From coleenp at openjdk.java.net  Thu Aug 12 01:03:30 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 12 Aug 2021 01:03:30 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v10]
In-Reply-To: <ILa4QgyCKM0_DxuDu7NyPzlTJN_rkhMyElUxTN8UEDg=.ec76e723-d3f1-4ffe-b319-7e39c758b162@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <FA4UIaAKvYoDhG9R_tE0Y8DXD_ZuutvmjzX3JNv1Vwg=.387569b8-5fd4-4649-bfdd-e6c29c122ff4@github.com>
 <ILa4QgyCKM0_DxuDu7NyPzlTJN_rkhMyElUxTN8UEDg=.ec76e723-d3f1-4ffe-b319-7e39c758b162@github.com>
Message-ID: <Rt35VGNekzRrQj9JcwbkdR89TJ1fgwICdmhAGtY32bo=.6e27bdef-3998-4d25-9eab-0e12cad85759@github.com>

On Wed, 11 Aug 2021 20:45:30 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo in EIIE message.
>
> src/hotspot/share/oops/instanceKlass.cpp line 1028:
> 
>> 1026:   // this would be still be helpful.
>> 1027:   Handle cause = java_lang_Throwable::get_cause_with_stack_trace(exception, THREAD);
>> 1028:   CLEAR_PENDING_EXCEPTION;
> 
> If new exceptions happened inside `get_cause_with_stack_trace`, `cause` will be null here. Maybe proceed to the following only if `cause` is not null?

I thought of doing that also, but now can't remember why I didn't do it that way.  Fixed.

-------------

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

From coleenp at openjdk.java.net  Thu Aug 12 01:28:54 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 12 Aug 2021 01:28:54 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v11]
In-Reply-To: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
Message-ID: <CFvnAYse_HAPguivIJs61D6aSFKQQWzsSNIiPVUXPOk=.b15f7265-9385-462e-b344-8288596f435d@github.com>

> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
> 
> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).

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

  Ioi's review comments and fix typo in test.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4996/files
  - new: https://git.openjdk.java.net/jdk/pull/4996/files/e7b739ae..7d686231

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4996&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4996&range=09-10

  Stats: 16 lines in 3 files changed: 5 ins; 2 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4996.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4996/head:pull/4996

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

From dholmes at openjdk.java.net  Thu Aug 12 01:37:22 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 12 Aug 2021 01:37:22 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v11]
In-Reply-To: <CFvnAYse_HAPguivIJs61D6aSFKQQWzsSNIiPVUXPOk=.b15f7265-9385-462e-b344-8288596f435d@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <CFvnAYse_HAPguivIJs61D6aSFKQQWzsSNIiPVUXPOk=.b15f7265-9385-462e-b344-8288596f435d@github.com>
Message-ID: <pkgW0uW5EKx56YyplvnU221BssjwMa8Q8X2xg1KjvE8=.c56cd0de-62b1-49f5-8998-b0d632233ba7@github.com>

On Thu, 12 Aug 2021 01:28:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
>> 
>> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ioi's review comments and fix typo in test.

Updates look good.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

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

From iklam at openjdk.java.net  Thu Aug 12 04:43:26 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 12 Aug 2021 04:43:26 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v11]
In-Reply-To: <CFvnAYse_HAPguivIJs61D6aSFKQQWzsSNIiPVUXPOk=.b15f7265-9385-462e-b344-8288596f435d@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <CFvnAYse_HAPguivIJs61D6aSFKQQWzsSNIiPVUXPOk=.b15f7265-9385-462e-b344-8288596f435d@github.com>
Message-ID: <0EMS_y4EYg1PzhcqtB_rZgjb3vJAG0VzYbMd__p_1gM=.321d9948-ffc2-4eeb-bfe8-0089967453c4@github.com>

On Thu, 12 Aug 2021 01:28:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
>> 
>> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ioi's review comments and fix typo in test.

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

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

From shade at openjdk.java.net  Thu Aug 12 09:32:25 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 12 Aug 2021 09:32:25 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC [v2]
In-Reply-To: <J6oVuxwmM5kW6az_-4AUDegJFfNjQJJBfxlY894TlbY=.2090005c-c7d5-43f0-8b8c-6817818b3a06@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
 <j-lv0HkKkf13P3MrGOXwBFs9WQgVjfjZ7FwLCVarqqU=.c1a192ef-3e4b-4cd9-946a-cf2e06a43f73@github.com>
 <T2Us2bJw_Mz11vp1C8uJi-0blh7h6Odk66ghjCBAjfk=.8cc5d3e9-f64d-40fb-a067-c4993a2d5c1f@github.com>
 <J6oVuxwmM5kW6az_-4AUDegJFfNjQJJBfxlY894TlbY=.2090005c-c7d5-43f0-8b8c-6817818b3a06@github.com>
Message-ID: <OX6w3H68MEyBMxlX5NltiGOC5VOVqDrQEOfZr_3ib0M=.1f0154b8-97e4-4672-872a-1ef0f7923117@github.com>

On Wed, 11 Aug 2021 23:29:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/gc/epsilon/epsilonHeap.cpp line 155:
>> 
>>> 153: 
>>> 154:   // Allocation successful, update counters
>>> 155:   if (Metaspace::initialized()) {
>> 
>> Feels odd to protect this entire block. It handles generic allocations, not only the metaspace. (I suspect this is only relevant during the initial allocation at startup, but it still looks weird). Would moving a check to `EpsilonMonitoringSupport::update_counters()` and protecting `MetaspaceCounters::update_performance_counters();` there be enough?
>
> I can't move `if (Metaspace::initialized())` into `EpsilonMonitoringSupport::update_counters()` because the code in this function also updates the global variable `_last_counter_update`.

Yes, I understand that sacrifices the logging accuracy a bit: the `_last_counter_update` would include the initial CDS allocation. At the same time, I would not like to put `Metaspace::initialized()` checks on this (hot-when-not-TLAB) path, only to catch that initial allocation. So I suggest we add a boolean parameter like `allocate_work(size_t size, bool verbose)`, and call it with `false` from `allocate_loaded_archive_space`.

-------------

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

From coleenp at openjdk.java.net  Thu Aug 12 13:49:37 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 12 Aug 2021 13:49:37 GMT
Subject: RFR: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError [v11]
In-Reply-To: <CFvnAYse_HAPguivIJs61D6aSFKQQWzsSNIiPVUXPOk=.b15f7265-9385-462e-b344-8288596f435d@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
 <CFvnAYse_HAPguivIJs61D6aSFKQQWzsSNIiPVUXPOk=.b15f7265-9385-462e-b344-8288596f435d@github.com>
Message-ID: <h5yztqC-pNRPcja-jbRf9587wznZdwSTEzQU349UjXU=.68e0d444-4597-470b-a16d-abfe2511c150@github.com>

On Thu, 12 Aug 2021 01:28:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
>> 
>> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ioi's review comments and fix typo in test.

Thank you David and Ioi for your reviews and comments!

-------------

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

From coleenp at openjdk.java.net  Thu Aug 12 13:49:40 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 12 Aug 2021 13:49:40 GMT
Subject: Integrated: 8048190: NoClassDefFoundError omits original
 ExceptionInInitializerError
In-Reply-To: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
References: <qYw844yJELTKG1F9Vxe002jY20wUZHzbmcwp7baL4ro=.3f589fd5-4781-45d5-a2e8-c2e94595296b@github.com>
Message-ID: <TsmdKW8orhbYVePfHiz9pChl-TvvV5CkNOuCikl57i0=.764cb640-d235-4666-a956-8ad29740c900@github.com>

On Wed, 4 Aug 2021 17:55:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a change to save the class initialization error stack trace in a hashtable and return it as the cause when NoClassDefFoundError is thrown.  The first commit is a more limited version of this that just changes the message, by adding to the message string.  The second commit is getting and saving the stack trace for the original exception, and using the thread in the message.  See CR for more details about how the message looks.
> 
> Tested with tier1-3 tests on 3 platforms.  Tier 4-6 in progress (all but two done and passed).

This pull request has now been integrated.

Changeset: 464e874a
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/464e874a5c6b46fcc729227764d07feb1801314d
Stats:     258 lines in 9 files changed: 245 ins; 3 del; 10 mod

8048190: NoClassDefFoundError omits original ExceptionInInitializerError

Reviewed-by: dholmes, iklam

-------------

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

From hseigel at openjdk.java.net  Thu Aug 12 13:54:45 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 12 Aug 2021 13:54:45 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class [v4]
In-Reply-To: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
Message-ID: <aIEELjdKaSmVh_pvvQqp4CpxYNOmaMYz37w8GXSJBbc=.8e718c49-9abb-4910-8933-1a18dbe89c0d@github.com>

> Please review this change to remove the now unused CPSlot class.  Uses of CPSlot have been replaced with Symbol*.  The change was tested by running JCK lang and VM tests, Mach5 tiers 1-2 on Linux, Mac OS, and WIndows and Macn5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

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

  remove load_symbol(), fix comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5070/files
  - new: https://git.openjdk.java.net/jdk/pull/5070/files/42afa811..383a02a7

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

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

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

From hseigel at openjdk.java.net  Thu Aug 12 13:54:47 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 12 Aug 2021 13:54:47 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class [v3]
In-Reply-To: <jsc7pVv7RI74Uw7K7Qcj9LIy0DhrnvEILGo1z3p6Llk=.a335646b-d252-4f6c-8573-c424d690a14d@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
 <0XzPVfLD9XfdYfCa5TlYYJyPs9czdupMp_e2GrGNabE=.38451d7f-2a56-4656-a78c-6597fec9503b@github.com>
 <jsc7pVv7RI74Uw7K7Qcj9LIy0DhrnvEILGo1z3p6Llk=.a335646b-d252-4f6c-8573-c424d690a14d@github.com>
Message-ID: <A-zsWmzlt99pZf8vFoZenz6QLM0-qm2_qXsh-uw0yk8=.abca0833-d450-4353-b062-14242470a04c@github.com>

On Thu, 12 Aug 2021 00:40:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add comment for unresolved_string_at_put()
>
> src/hotspot/share/memory/iterator.hpp line 347:
> 
>> 345:   static Symbol* load_symbol(Symbol** p) {
>> 346:     return *p;
>> 347:   }
> 
> Do we even need load_symbol now?

It's not needed.  I removed it.

> src/hotspot/share/oops/symbol.hpp line 48:
> 
>> 46: // in the SymbolTable bucket (the _literal field in HashtableEntry)
>> 47: // that points to the Symbol.  All other stores of a Symbol*
>> 48: // to a field of a persistent variable (e.g., the _name filed in
> 
> Can you fix the typo here please: filed -> field

done

-------------

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

From hseigel at openjdk.java.net  Thu Aug 12 13:54:47 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 12 Aug 2021 13:54:47 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class [v2]
In-Reply-To: <npKp-Nm0bVUL7laSn7mSRkGPYp66VZYHjneBGCgegoY=.8aee8d27-9192-4a0a-a769-3eb99e3513df@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
 <EgUoha3S3UBqYA6g1hqtPaZ7aYuuzCa8sfBiWs1Lots=.2d0958eb-e9d4-4efb-af54-499afac280ab@github.com>
 <glvU-SPVOkZC-BYqVirK7BqF1F-CLDsJMiApWDND-HM=.57300e32-f8e1-4175-9879-668db35a1e32@github.com>
 <_JNaKOqu2vX6aMwA_dLv84zY4YlGnFHxB40r-nre50o=.a1a71810-9e9c-41be-8bd6-68b88ffa4b0e@github.com>
 <npKp-Nm0bVUL7laSn7mSRkGPYp66VZYHjneBGCgegoY=.8aee8d27-9192-4a0a-a769-3eb99e3513df@github.com>
Message-ID: <1cFm_pvNW_R6MPLoDscrPrQUZOIJ4LbttWXQo5qtbUc=.b0bdeaeb-0f30-4c74-82ba-af0903abb62b@github.com>

On Wed, 11 Aug 2021 19:56:42 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I like the idea of doing this as a separate PR.
>
> I created https://bugs.openjdk.java.net/browse/JDK-8272343.

Thanks!

-------------

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

From hseigel at openjdk.java.net  Thu Aug 12 14:01:30 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 12 Aug 2021 14:01:30 GMT
Subject: RFR: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class [v4]
In-Reply-To: <aIEELjdKaSmVh_pvvQqp4CpxYNOmaMYz37w8GXSJBbc=.8e718c49-9abb-4910-8933-1a18dbe89c0d@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
 <aIEELjdKaSmVh_pvvQqp4CpxYNOmaMYz37w8GXSJBbc=.8e718c49-9abb-4910-8933-1a18dbe89c0d@github.com>
Message-ID: <9ZWCf8AnY_5r2uN7RDrV-4fA0MPzXccoUeRq0cJas6k=.6afd6ddd-cdeb-4668-aa5a-eea24fe391a7@github.com>

On Thu, 12 Aug 2021 13:54:45 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this change to remove the now unused CPSlot class.  Uses of CPSlot have been replaced with Symbol*.  The change was tested by running JCK lang and VM tests, Mach5 tiers 1-2 on Linux, Mac OS, and WIndows and Macn5 tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove load_symbol(), fix comments

Thanks Coleen, Ioi, and David for your reviews and comments!

-------------

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

From hseigel at openjdk.java.net  Thu Aug 12 14:01:31 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 12 Aug 2021 14:01:31 GMT
Subject: Integrated: 8272107: Removal of Unsafe::defineAnonymousClass left a
 dangling C++ class
In-Reply-To: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
References: <OvdGvjtNjIeGpjvFv7HJ0-KtInecWbp1-uMvPwM6-_M=.fee8f966-0ff5-46ec-bb9d-6c42c89002f4@github.com>
Message-ID: <b8VMV7je5MT7IjNlOX-4EYUA-hZzg7sc5br3cz1UCIo=.4f0284bb-ddac-42e0-a35d-66903828b17e@github.com>

On Tue, 10 Aug 2021 14:06:04 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this change to remove the now unused CPSlot class.  Uses of CPSlot have been replaced with Symbol*.  The change was tested by running JCK lang and VM tests, Mach5 tiers 1-2 on Linux, Mac OS, and WIndows and Macn5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: 9980b413
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9980b413da47ac7dff74e66aaf12833e48fcce1d
Stats:     61 lines in 7 files changed: 4 ins; 44 del; 13 mod

8272107: Removal of Unsafe::defineAnonymousClass left a dangling C++ class

Reviewed-by: coleenp, iklam, dholmes

-------------

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

From coleenp at openjdk.java.net  Thu Aug 12 16:44:24 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 12 Aug 2021 16:44:24 GMT
Subject: RFR: JDK-8272112: Arena code simplifications [v2]
In-Reply-To: <iVapRCmwRiVEae_Kg3vmOzaNbQqjxIj1Ho4GooeBJak=.db99c810-aa1b-41b0-b10a-caa8ea26511d@github.com>
References: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
 <iVapRCmwRiVEae_Kg3vmOzaNbQqjxIj1Ho4GooeBJak=.db99c810-aa1b-41b0-b10a-caa8ea26511d@github.com>
Message-ID: <Qu9fqrNONMpeGuxkkMQugNKoempEKdD3XpbkSaHZxqo=.7da36c6a-e1df-4151-bc6d-c45fa4dda05d@github.com>

On Mon, 9 Aug 2021 08:15:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> May I please have reviews for this small change. This is pure code cleanup, issues that were identified by code review when working on JDK-8270308. 
>> 
>> The patch results in less code (excluding the new gtest), bit easier to maintain. I have some smaller functional improvements in the pipeline and would like to get this code cleanup out of the way first.
>> 
>> Changes:
>> 
>> - Made `ChunkPool` an automatic object. We can remove `chunkpool_init()` and instead rely on automatic initialization.
>> 
>> - Instead of having four named pools that need to be handled individually and selected via awkward switch constructs (see the old `Chunk::operator new()` and `::operator delete()`), we replace it with an array and a static selector (`ChunkPool* get_pool_for_size(size_t size)`).
>> 
>> - Removed `ChunkPool::_num_used`. It was nowhere queried, and its usefulness was questionable since these numbers don't include chunks with "special" sizes. The easiest way to obtain the footprint of arena chunks is via NMT.
>> 
>> - Before, we had two places where the backing memory of Chunks was allocated: in `ChunkPool::allocate()` and in `Chunk::operator new()`. The former was unnecessary. I streamlined that: removed the ability to allocate from `ChunkPool::allocate()` and renamed it to `ChunkPool::remove_chunk()`. Now Chunks are only allocated in `Chunk::operator new() `and ChunkPool just serves as Chunk cache.
>> 
>> - Renamed `ChunkPool::free_all_but()` to `ChunkPool::prune()` and removed the argument, made it a method-local constant (it had been a constant before in the caller of that function).
>> 
>> - I added a new gtest to test Chunk allocation and pooling a little.
>> 
>> 
>> Functionally, nothing should have changed with this patch, this is pure code grooming.
>> 
>> ----
>> 
>> Tests: 
>> - GHA
>> - I manually tested on 64-bit and 32-bit, with and without UseMallocOnly. I also manually checked that pool usage is as expected.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback kim

This looks good modulo trivial comments.

src/hotspot/share/memory/arena.cpp line 65:

> 63:     ThreadCritical tc;
> 64:     Chunk* c = _first;
> 65:     if (_first) {

Preexisting, should be: if (_first != nullptr)

src/hotspot/share/memory/arena.cpp line 171:

> 169:   assert(is_aligned(length, ARENA_AMALLOC_ALIGNMENT), "chunk payload length misaligned: "
> 170:          SIZE_FORMAT ".", length);
> 171:   // Try to reuse a cached chunk from the pool

Can you modify this comment as:
// Try to reuse a freed chunk from the pool
For some reason, I was confused about which chunks were on the chunk pool.

-------------

Marked as reviewed by coleenp (Reviewer).

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

From mgkwill at openjdk.java.net  Fri Aug 13 03:47:40 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 13 Aug 2021 03:47:40 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v6]
In-Reply-To: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
Message-ID: <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>

> Intrinsic for Math.copySign is disabled on x86_64.
> 
> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
> 
> ### **Math.copySign(double)**
> _From:_
>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>   0x00007f7d606e5dc0:   and    %r8,%r11
>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>   0x00007f7d606e5dcd:   and    %r8,%r10
>   0x00007f7d606e5dd0:   or     %r11,%r10
>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
> 
> _To:_
>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
> 
> ### **Math.copySign(float)**
> _From:_
>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>   0x00007ff8886e60c4:   or     %r10d,%r11d
>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
> _To:_
>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
> 
> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
> #### **BEFORE**
> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
> 
> #### **PATCH**
> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
> 
> #### **JTREG that covers this case:**
> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
> 
> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:

  Remove vmovq vmovd
  
  Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5005/files
  - new: https://git.openjdk.java.net/jdk/pull/5005/files/2764fa6b..1399d579

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

  Stats: 34 lines in 3 files changed: 1 ins; 31 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5005.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5005/head:pull/5005

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

From stuefe at openjdk.java.net  Fri Aug 13 04:06:41 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 13 Aug 2021 04:06:41 GMT
Subject: RFR: JDK-8272112: Arena code simplifications [v3]
In-Reply-To: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
References: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
Message-ID: <q4G9HVQg6np0XJ1UvMyP0hRAwqmpYqwaGUlVwXfexMU=.0a63f265-65c0-4cc7-b960-a5866829731c@github.com>

> May I please have reviews for this small change. This is pure code cleanup, issues that were identified by code review when working on JDK-8270308. 
> 
> The patch results in less code (excluding the new gtest), bit easier to maintain. I have some smaller functional improvements in the pipeline and would like to get this code cleanup out of the way first.
> 
> Changes:
> 
> - Made `ChunkPool` an automatic object. We can remove `chunkpool_init()` and instead rely on automatic initialization.
> 
> - Instead of having four named pools that need to be handled individually and selected via awkward switch constructs (see the old `Chunk::operator new()` and `::operator delete()`), we replace it with an array and a static selector (`ChunkPool* get_pool_for_size(size_t size)`).
> 
> - Removed `ChunkPool::_num_used`. It was nowhere queried, and its usefulness was questionable since these numbers don't include chunks with "special" sizes. The easiest way to obtain the footprint of arena chunks is via NMT.
> 
> - Before, we had two places where the backing memory of Chunks was allocated: in `ChunkPool::allocate()` and in `Chunk::operator new()`. The former was unnecessary. I streamlined that: removed the ability to allocate from `ChunkPool::allocate()` and renamed it to `ChunkPool::remove_chunk()`. Now Chunks are only allocated in `Chunk::operator new() `and ChunkPool just serves as Chunk cache.
> 
> - Renamed `ChunkPool::free_all_but()` to `ChunkPool::prune()` and removed the argument, made it a method-local constant (it had been a constant before in the caller of that function).
> 
> - I added a new gtest to test Chunk allocation and pooling a little.
> 
> 
> Functionally, nothing should have changed with this patch, this is pure code grooming.
> 
> ----
> 
> Tests: 
> - GHA
> - I manually tested on 64-bit and 32-bit, with and without UseMallocOnly. I also manually checked that pool usage is as expected.

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

  feedback coleen

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5040/files
  - new: https://git.openjdk.java.net/jdk/pull/5040/files/625df135..52295624

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

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

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

From stuefe at openjdk.java.net  Fri Aug 13 04:06:42 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 13 Aug 2021 04:06:42 GMT
Subject: RFR: JDK-8272112: Arena code simplifications [v2]
In-Reply-To: <Qu9fqrNONMpeGuxkkMQugNKoempEKdD3XpbkSaHZxqo=.7da36c6a-e1df-4151-bc6d-c45fa4dda05d@github.com>
References: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
 <iVapRCmwRiVEae_Kg3vmOzaNbQqjxIj1Ho4GooeBJak=.db99c810-aa1b-41b0-b10a-caa8ea26511d@github.com>
 <Qu9fqrNONMpeGuxkkMQugNKoempEKdD3XpbkSaHZxqo=.7da36c6a-e1df-4151-bc6d-c45fa4dda05d@github.com>
Message-ID: <mQ6aW47pb3poAuCVNoT6Y3h_99QztCxvAxnzDFieOnI=.1749c3e4-2142-444d-bb92-3ccd93adb62c@github.com>

On Thu, 12 Aug 2021 16:41:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This looks good modulo trivial comments.

Thank you @coleenp!

-------------

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

From jbhateja at openjdk.java.net  Fri Aug 13 04:18:24 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 13 Aug 2021 04:18:24 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v2]
In-Reply-To: <eJqLsngP64rIKEOZrLFZlvMqy05HbEoQX1pK3cSZ7Pk=.d10b90a4-12fb-4089-a930-8d81012237ca@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
 <HepC1TEN3yHa8Nofh-NLCqQy2ZfW4dyz4KQDrTntzAY=.0d081927-ca83-4da2-afc6-a5d8777358ba@github.com>
 <eJqLsngP64rIKEOZrLFZlvMqy05HbEoQX1pK3cSZ7Pk=.d10b90a4-12fb-4089-a930-8d81012237ca@github.com>
Message-ID: <EF88fy3aaqjmT7sbjBEFLGNHYiK-mqHYuUrLWmMwASg=.6bbd8754-1268-40ff-b32e-eb0b2305adfb@github.com>

On Fri, 6 Aug 2021 07:41:49 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update x86.ad with #ifdef _LP64 for copySign
>
> src/hotspot/cpu/x86/x86.ad line 5823:
> 
>> 5821: %}
>> 5822: 
>> 5823: instruct copySignD_reg(regD dst, regD src, regD tmp1, rRegL tmp2, regD zero) %{
> 
> Graph shape created for this will always pass zero operand as an immediate argument. Do you see any issue if you just keep one pattern (copySignD_imm) ?

@mgkwill , haven't seen your response on this.

-------------

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

From stuefe at openjdk.java.net  Fri Aug 13 06:41:25 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 13 Aug 2021 06:41:25 GMT
Subject: Integrated: JDK-8272112: Arena code simplifications
In-Reply-To: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
References: <jorfCJBuoMofLbswLcl2OSnq4ChH6MsU_ol2ZUOHnJY=.20a5dd03-e1f1-4caf-8b52-6d45fb604e68@github.com>
Message-ID: <vd-VngvDqLd7njDVeAW8rnK5UunQ1p45nu8tMNlyFhA=.a916cba2-91c0-404f-810e-5ca0f1892fc2@github.com>

On Sat, 7 Aug 2021 05:30:54 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> May I please have reviews for this small change. This is pure code cleanup, issues that were identified by code review when working on JDK-8270308. 
> 
> The patch results in less code (excluding the new gtest), bit easier to maintain. I have some smaller functional improvements in the pipeline and would like to get this code cleanup out of the way first.
> 
> Changes:
> 
> - Made `ChunkPool` an automatic object. We can remove `chunkpool_init()` and instead rely on automatic initialization.
> 
> - Instead of having four named pools that need to be handled individually and selected via awkward switch constructs (see the old `Chunk::operator new()` and `::operator delete()`), we replace it with an array and a static selector (`ChunkPool* get_pool_for_size(size_t size)`).
> 
> - Removed `ChunkPool::_num_used`. It was nowhere queried, and its usefulness was questionable since these numbers don't include chunks with "special" sizes. The easiest way to obtain the footprint of arena chunks is via NMT.
> 
> - Before, we had two places where the backing memory of Chunks was allocated: in `ChunkPool::allocate()` and in `Chunk::operator new()`. The former was unnecessary. I streamlined that: removed the ability to allocate from `ChunkPool::allocate()` and renamed it to `ChunkPool::remove_chunk()`. Now Chunks are only allocated in `Chunk::operator new() `and ChunkPool just serves as Chunk cache.
> 
> - Renamed `ChunkPool::free_all_but()` to `ChunkPool::prune()` and removed the argument, made it a method-local constant (it had been a constant before in the caller of that function).
> 
> - I added a new gtest to test Chunk allocation and pooling a little.
> 
> 
> Functionally, nothing should have changed with this patch, this is pure code grooming.
> 
> ----
> 
> Tests: 
> - GHA
> - I manually tested on 64-bit and 32-bit, with and without UseMallocOnly. I also manually checked that pool usage is as expected.

This pull request has now been integrated.

Changeset: d06d0b9e
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d06d0b9e9d9d27aa549455f19b9803752431bcbb
Stats:     166 lines in 3 files changed: 56 ins; 61 del; 49 mod

8272112: Arena code simplifications

Reviewed-by: kbarrett, coleenp

-------------

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

From mgkwill at openjdk.java.net  Fri Aug 13 15:09:26 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 13 Aug 2021 15:09:26 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v2]
In-Reply-To: <EF88fy3aaqjmT7sbjBEFLGNHYiK-mqHYuUrLWmMwASg=.6bbd8754-1268-40ff-b32e-eb0b2305adfb@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
 <HepC1TEN3yHa8Nofh-NLCqQy2ZfW4dyz4KQDrTntzAY=.0d081927-ca83-4da2-afc6-a5d8777358ba@github.com>
 <eJqLsngP64rIKEOZrLFZlvMqy05HbEoQX1pK3cSZ7Pk=.d10b90a4-12fb-4089-a930-8d81012237ca@github.com>
 <EF88fy3aaqjmT7sbjBEFLGNHYiK-mqHYuUrLWmMwASg=.6bbd8754-1268-40ff-b32e-eb0b2305adfb@github.com>
Message-ID: <ymJGXjBpaJJTVaCH6Gr4PlQ_F-PXvuoiPyRvsaOqusw=.4a67f975-d43f-4e0b-8c63-8328e9e30b85@github.com>

On Fri, 13 Aug 2021 04:15:46 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86.ad line 5823:
>> 
>>> 5821: %}
>>> 5822: 
>>> 5823: instruct copySignD_reg(regD dst, regD src, regD tmp1, rRegL tmp2, regD zero) %{
>> 
>> Graph shape created for this will always pass zero operand as an immediate argument. Do you see any issue if you just keep one pattern (copySignD_imm) ?
>
> @mgkwill , haven't seen your response on this.

@jatin-bhateja, @sviswa7 told me that you and her discussed it and decided that removing copySignD_reg was appropriate as it is not needed. I've removed copySignD_reg.

-------------

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

From kvn at openjdk.java.net  Fri Aug 13 16:09:24 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 13 Aug 2021 16:09:24 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail [v5]
In-Reply-To: <YRw5msMUkovU4qPzPzvloaLw6jlgKmRSgSi8zemjvx4=.fa642ba6-67d1-4430-9015-a8cb02417dc8@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
 <YRw5msMUkovU4qPzPzvloaLw6jlgKmRSgSi8zemjvx4=.fa642ba6-67d1-4430-9015-a8cb02417dc8@github.com>
Message-ID: <WYKjo5ad8cV3wA0vxRdYvUCMjvt5G6ScV6G23YpATxc=.bb7919af-95b5-47b6-8667-6e656cd1f38c@github.com>

On Tue, 10 Aug 2021 12:04:56 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> A test VM used by the IR framework sometimes prints `` in the middle of emitting a `PrintIdeal` or `PrintOptoAssembly` output which could lead to IR matching failures:
>> https://github.com/openjdk/jdk/blob/489e5fd12a37a45f4f5ea64b05f85c6f99f70811/src/hotspot/share/utilities/ostream.cpp#L918-L927
>> 
>> I thought about just bailing out of IR matching if this string is found after a failure but this issue also affects internal framework tests (I observed one case locally where this happened in the test `TestIRMatching`, letting it fail).
>> 
>> Handling `` makes things more complicated for the IR framework tests. I'm not sure about the value of printing this message in the first place. But if nobody objects, I suggest to either remove it or at least guard it with `Verbose`, for example. I went with the latter solution in this PR.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup & simplify test by using anyMatch

Good

-------------

Marked as reviewed by kvn (Reviewer).

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

From jbhateja at openjdk.java.net  Fri Aug 13 16:24:23 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 13 Aug 2021 16:24:23 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v2]
In-Reply-To: <ymJGXjBpaJJTVaCH6Gr4PlQ_F-PXvuoiPyRvsaOqusw=.4a67f975-d43f-4e0b-8c63-8328e9e30b85@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
 <HepC1TEN3yHa8Nofh-NLCqQy2ZfW4dyz4KQDrTntzAY=.0d081927-ca83-4da2-afc6-a5d8777358ba@github.com>
 <eJqLsngP64rIKEOZrLFZlvMqy05HbEoQX1pK3cSZ7Pk=.d10b90a4-12fb-4089-a930-8d81012237ca@github.com>
 <EF88fy3aaqjmT7sbjBEFLGNHYiK-mqHYuUrLWmMwASg=.6bbd8754-1268-40ff-b32e-eb0b2305adfb@github.com>
 <ymJGXjBpaJJTVaCH6Gr4PlQ_F-PXvuoiPyRvsaOqusw=.4a67f975-d43f-4e0b-8c63-8328e9e30b85@github.com>
Message-ID: <X4TFlSnLtSUMJxkAXm7xrvt_gNTjsDHMHCPwLcr_2t0=.46124df0-947d-42bd-959f-e9ffac135d70@github.com>

On Fri, 13 Aug 2021 15:06:24 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> @mgkwill , haven't seen your response on this.
>
> @jatin-bhateja, @sviswa7 told me that you and her discussed it and decided that removing copySignD_reg was appropriate as it is not needed. I've removed copySignD_reg.

Thanks! patch looks good otherwise.

-------------

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

From sviswanathan at openjdk.java.net  Fri Aug 13 16:30:24 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 13 Aug 2021 16:30:24 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v6]
In-Reply-To: <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
 <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>
Message-ID: <9NmO724dMUA9Q44Rj9n2urmgOh5xi8SWWf0HOmSJBkU=.73687985-bf14-4d1e-bd8b-bf7e2a4cfe48@github.com>

On Fri, 13 Aug 2021 03:47:40 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Intrinsic for Math.copySign is disabled on x86_64.
>> 
>> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
>> 
>> ### **Math.copySign(double)**
>> _From:_
>>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>>   0x00007f7d606e5dc0:   and    %r8,%r11
>>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>>   0x00007f7d606e5dcd:   and    %r8,%r10
>>   0x00007f7d606e5dd0:   or     %r11,%r10
>>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
>> 
>> _To:_
>>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
>> 
>> ### **Math.copySign(float)**
>> _From:_
>>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>>   0x00007ff8886e60c4:   or     %r10d,%r11d
>>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
>> _To:_
>>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
>> 
>> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
>> #### **BEFORE**
>> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
>> 
>> #### **PATCH**
>> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
>> 
>> #### **JTREG that covers this case:**
>> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
>> 
>> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove vmovq vmovd
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Marked as reviewed by sviswanathan (Reviewer).

-------------

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

From jbhateja at openjdk.java.net  Fri Aug 13 16:30:23 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 13 Aug 2021 16:30:23 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v6]
In-Reply-To: <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
 <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>
Message-ID: <MlLE47qpjKZM5SVsR40RvEWHgwS-_kcrilh5NstIdOk=.9bf564b5-425a-4069-af77-a9a5b162b0da@github.com>

On Fri, 13 Aug 2021 03:47:40 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Intrinsic for Math.copySign is disabled on x86_64.
>> 
>> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
>> 
>> ### **Math.copySign(double)**
>> _From:_
>>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>>   0x00007f7d606e5dc0:   and    %r8,%r11
>>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>>   0x00007f7d606e5dcd:   and    %r8,%r10
>>   0x00007f7d606e5dd0:   or     %r11,%r10
>>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
>> 
>> _To:_
>>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
>> 
>> ### **Math.copySign(float)**
>> _From:_
>>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>>   0x00007ff8886e60c4:   or     %r10d,%r11d
>>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
>> _To:_
>>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
>> 
>> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
>> #### **BEFORE**
>> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
>> 
>> #### **PATCH**
>> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
>> 
>> #### **JTREG that covers this case:**
>> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
>> 
>> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove vmovq vmovd
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Marked as reviewed by jbhateja (Committer).

-------------

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

From sviswanathan at openjdk.java.net  Fri Aug 13 16:35:29 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 13 Aug 2021 16:35:29 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v6]
In-Reply-To: <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
 <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>
Message-ID: <DYxCgpH5ORcfeD3QF5R5ZEmSlYORkLanAa-iCAvXTks=.48826fc7-3055-407f-9aa0-fd0f2676a102@github.com>

On Fri, 13 Aug 2021 03:47:40 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Intrinsic for Math.copySign is disabled on x86_64.
>> 
>> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
>> 
>> ### **Math.copySign(double)**
>> _From:_
>>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>>   0x00007f7d606e5dc0:   and    %r8,%r11
>>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>>   0x00007f7d606e5dcd:   and    %r8,%r10
>>   0x00007f7d606e5dd0:   or     %r11,%r10
>>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
>> 
>> _To:_
>>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
>> 
>> ### **Math.copySign(float)**
>> _From:_
>>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>>   0x00007ff8886e60c4:   or     %r10d,%r11d
>>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
>> _To:_
>>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
>> 
>> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
>> #### **BEFORE**
>> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
>> 
>> #### **PATCH**
>> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
>> 
>> #### **JTREG that covers this case:**
>> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
>> 
>> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove vmovq vmovd
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Could we please get second review from a reviewer? Also need help running this through Oracle's testing.

-------------

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

From mgkwill at openjdk.java.net  Fri Aug 13 16:42:26 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 13 Aug 2021 16:42:26 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v6]
In-Reply-To: <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
 <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>
Message-ID: <OrnOhT5evwi7iT2soJk-Kj2gd0U4AjqwBvnYoy--_24=.a8229ffe-a676-4c58-bde0-65fb99a4a7e7@github.com>

On Fri, 13 Aug 2021 03:47:40 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Intrinsic for Math.copySign is disabled on x86_64.
>> 
>> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
>> 
>> ### **Math.copySign(double)**
>> _From:_
>>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>>   0x00007f7d606e5dc0:   and    %r8,%r11
>>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>>   0x00007f7d606e5dcd:   and    %r8,%r10
>>   0x00007f7d606e5dd0:   or     %r11,%r10
>>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
>> 
>> _To:_
>>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
>> 
>> ### **Math.copySign(float)**
>> _From:_
>>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>>   0x00007ff8886e60c4:   or     %r10d,%r11d
>>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
>> _To:_
>>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
>> 
>> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
>> #### **BEFORE**
>> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
>> 
>> #### **PATCH**
>> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
>> 
>> #### **JTREG that covers this case:**
>> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
>> 
>> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove vmovq vmovd
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

@vnkozlov any chance you have time to run this through Oracle Testing?

I tested tier1-3 on cascade lake Linux x86_64.

-------------

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

From kvn at openjdk.java.net  Fri Aug 13 19:48:22 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 13 Aug 2021 19:48:22 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v6]
In-Reply-To: <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
 <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>
Message-ID: <8dJP7UUv1kQ5ap3zUwWuQDUMdELNzM1nHr_u_pte-Dc=.9fdbef12-d2fe-42a5-9311-4a912eff5b75@github.com>

On Fri, 13 Aug 2021 03:47:40 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Intrinsic for Math.copySign is disabled on x86_64.
>> 
>> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
>> 
>> ### **Math.copySign(double)**
>> _From:_
>>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>>   0x00007f7d606e5dc0:   and    %r8,%r11
>>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>>   0x00007f7d606e5dcd:   and    %r8,%r10
>>   0x00007f7d606e5dd0:   or     %r11,%r10
>>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
>> 
>> _To:_
>>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
>> 
>> ### **Math.copySign(float)**
>> _From:_
>>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>>   0x00007ff8886e60c4:   or     %r10d,%r11d
>>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
>> _To:_
>>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
>> 
>> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
>> #### **BEFORE**
>> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
>> 
>> #### **PATCH**
>> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
>> 
>> #### **JTREG that covers this case:**
>> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
>> 
>> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove vmovq vmovd
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

I started our testing.

-------------

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

From kvn at openjdk.java.net  Fri Aug 13 21:45:24 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 13 Aug 2021 21:45:24 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v6]
In-Reply-To: <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
 <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>
Message-ID: <uA5DNVQGYNNJfkpQExVg7BClpHAYbPmiAktaVAHFDcQ=.7e6f0a5f-7e60-4122-969a-934bd078ef66@github.com>

On Fri, 13 Aug 2021 03:47:40 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Intrinsic for Math.copySign is disabled on x86_64.
>> 
>> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
>> 
>> ### **Math.copySign(double)**
>> _From:_
>>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>>   0x00007f7d606e5dc0:   and    %r8,%r11
>>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>>   0x00007f7d606e5dcd:   and    %r8,%r10
>>   0x00007f7d606e5dd0:   or     %r11,%r10
>>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
>> 
>> _To:_
>>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
>> 
>> ### **Math.copySign(float)**
>> _From:_
>>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>>   0x00007ff8886e60c4:   or     %r10d,%r11d
>>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
>> _To:_
>>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
>> 
>> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
>> #### **BEFORE**
>> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
>> 
>> #### **PATCH**
>> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
>> 
>> #### **JTREG that covers this case:**
>> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
>> 
>> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove vmovq vmovd
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Testing passed clean.

-------------

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

From sviswanathan at openjdk.java.net  Fri Aug 13 21:45:25 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 13 Aug 2021 21:45:25 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v6]
In-Reply-To: <uA5DNVQGYNNJfkpQExVg7BClpHAYbPmiAktaVAHFDcQ=.7e6f0a5f-7e60-4122-969a-934bd078ef66@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
 <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>
 <uA5DNVQGYNNJfkpQExVg7BClpHAYbPmiAktaVAHFDcQ=.7e6f0a5f-7e60-4122-969a-934bd078ef66@github.com>
Message-ID: <ZyaE3_YH5Ih3PwAf6WRVKW_WxaWTJLYrTJDHbijyYlo=.7ac0dc64-4b47-4c7e-8df7-2f7034212993@github.com>

On Fri, 13 Aug 2021 21:39:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove vmovq vmovd
>>   
>>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> Testing passed clean.

@vnkozlov Thanks a lot Vladimir.  Jatin and I have reviewed the patch. Could we integrate or should we wait for another review.

-------------

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

From mgkwill at openjdk.java.net  Fri Aug 13 22:30:27 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Fri, 13 Aug 2021 22:30:27 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v6]
In-Reply-To: <uA5DNVQGYNNJfkpQExVg7BClpHAYbPmiAktaVAHFDcQ=.7e6f0a5f-7e60-4122-969a-934bd078ef66@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
 <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>
 <uA5DNVQGYNNJfkpQExVg7BClpHAYbPmiAktaVAHFDcQ=.7e6f0a5f-7e60-4122-969a-934bd078ef66@github.com>
Message-ID: <g-W5lOTviH3Dr5oNJ9zAbG6iqGYAdZG-xsfzYP_VIww=.a8ea7622-9907-4ead-94ad-f9bc4e182abe@github.com>

On Fri, 13 Aug 2021 21:39:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Testing passed clean.

Thanks @vnkozlov!

-------------

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

From kvn at openjdk.java.net  Sat Aug 14 00:31:25 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 14 Aug 2021 00:31:25 GMT
Subject: RFR: 8271883: Math CopySign optimization for x86 [v6]
In-Reply-To: <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
 <Vj_dDvcwg97Fp6epd2X5cCCydxDu4AH0rn4RT9vnXrs=.dfe6335b-be8d-4e5b-a4ba-4f93059a2d9d@github.com>
Message-ID: <SPXzW8uYuNNUuzTfFTF0w3-XeKDUlsGSnhpiwCjVS9o=.8239e151-ac11-47eb-a841-cf4b73754bf0@github.com>

On Fri, 13 Aug 2021 03:47:40 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

>> Intrinsic for Math.copySign is disabled on x86_64.
>> 
>> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
>> 
>> ### **Math.copySign(double)**
>> _From:_
>>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>>   0x00007f7d606e5dc0:   and    %r8,%r11
>>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>>   0x00007f7d606e5dcd:   and    %r8,%r10
>>   0x00007f7d606e5dd0:   or     %r11,%r10
>>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
>> 
>> _To:_
>>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
>> 
>> ### **Math.copySign(float)**
>> _From:_
>>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>>   0x00007ff8886e60c4:   or     %r10d,%r11d
>>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
>> _To:_
>>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
>> 
>> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
>> #### **BEFORE**
>> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
>> 
>> #### **PATCH**
>> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
>> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
>> 
>> #### **JTREG that covers this case:**
>> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
>> 
>> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>
>
> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove vmovq vmovd
>   
>   Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

Yes, you can push it,

-------------

Marked as reviewed by kvn (Reviewer).

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

From mgkwill at openjdk.java.net  Sat Aug 14 00:38:27 2021
From: mgkwill at openjdk.java.net (Marcus G K Williams)
Date: Sat, 14 Aug 2021 00:38:27 GMT
Subject: Integrated: 8271883: Math CopySign optimization for x86
In-Reply-To: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
References: <qX45WxGzHmdulxN9sR1aY5WPBtk0ynQmXIBjVzktP_g=.d4144022-7f3b-4ff4-83db-3b42e6a183ab@github.com>
Message-ID: <wOqXvhmDC9-qB6bVuCwSjR9RicMIZzSrgJ-fLWIhR-g=.a3a6d006-8e9b-4fbd-aff9-8af5a44830e2@github.com>

On Wed, 4 Aug 2021 20:12:41 GMT, Marcus G K Williams <mgkwill at openjdk.org> wrote:

> Intrinsic for Math.copySign is disabled on x86_64.
> 
> We can improve on generated c2 instructions for float and double, and this change adds optimized intrinsics for float and double Math.copySign.
> 
> ### **Math.copySign(double)**
> _From:_
>   0x00007f7d606e5dac:   vmovq  %xmm1,%r10
>   0x00007f7d606e5db1:   vmovq  %xmm0,%r11
>   0x00007f7d606e5db6:   movabs $0x7fffffffffffffff,%r8
>   0x00007f7d606e5dc0:   and    %r8,%r11
>   0x00007f7d606e5dc3:   movabs $0x8000000000000000,%r8
>   0x00007f7d606e5dcd:   and    %r8,%r10
>   0x00007f7d606e5dd0:   or     %r11,%r10
>   0x00007f7d606e5dd3:   vmovq  %r10,%xmm0                   
> 
> _To:_
>   0x00007fc3c14c63ac:   movabs $0x7fffffffffffffff,%r10
>   0x00007fc3c14c63b6:   vmovq  %r10,%xmm2
>   0x00007fc3c14c63bb:   vpternlogq $0xe4,%xmm2,%xmm1,%xmm0
> 
> ### **Math.copySign(float)**
> _From:_
>   0x00007ff8886e60ac:   vmovd  %xmm1,%r11d
>   0x00007ff8886e60b1:   vmovd  %xmm0,%r10d
>   0x00007ff8886e60b6:   and    $0x80000000,%r11d
>   0x00007ff8886e60bd:   and    $0x7fffffff,%r10d
>   0x00007ff8886e60c4:   or     %r10d,%r11d
>   0x00007ff8886e60c7:   vmovd  %r11d,%xmm0
> _To:_
>   0x00007fc7d94c63ac:   mov    $0x7fffffff,%r10d
>   0x00007fc7d94c63b2:   vmovd  %r10d,%xmm3
>   0x00007fc7d94c63b7:   vpternlogd $0xe4,%xmm3,%xmm1,%xmm0
> 
> #### _**Performance of patch using updated test/micro/org/openjdk/bench/vm/compiler/Signum.java:**_
> #### **BEFORE**
> Signum._5_copySignFloatTest       avgt    5  2.442 ? 0.024  ns/op
> Signum._7_copySignDoubleTest      avgt    5  2.400 ? 0.033  ns/op
> 
> #### **PATCH**
> Signum._5_copySignFloatTest       avgt    5  2.029 ? 0.011  ns/op
> Signum._7_copySignDoubleTest      avgt    5  2.029 ? 0.024  ns/op
> 
> #### **JTREG that covers this case:**
> test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java
> 
> Signed-off-by: Marcus G K Williams <marcus.williams at intel.com>

This pull request has now been integrated.

Changeset: 87d2761f
Author:    Marcus G K Williams <mgkwill at openjdk.org>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/87d2761f1b4572633de020b2d4681918c6f10f06
Stats:     111 lines in 3 files changed: 110 ins; 0 del; 1 mod

8271883: Math CopySign optimization for x86

Reviewed-by: jbhateja, sviswanathan, kvn

-------------

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

From aph-open at littlepinkcloud.com  Sat Aug 14 09:28:34 2021
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Sat, 14 Aug 2021 10:28:34 +0100
Subject: Not-yet-discussed in HotSpot style guide: C++ Lambdas
Message-ID: <ac2cc5fd-574e-0634-900c-2f1bae0df517@littlepinkcloud.com>

https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md says:

"Undecided Features

This list is incomplete; it serves to explicitly call out some
features that have not yet been discussed.  ...  Lambdas"

I can't see any reason to forbid Lambdas from a performance point of
view, and they can add to readability and maintainability in C++ for
the same reasons that they do in Java.

I have a job I'm working on (in the AArch64 back end) where Lambdas
would be very useful.  How about I give it a try, and I'll produce the
patch for review, as an initial proposal? Then anyone can put in their
2c worth.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From kim.barrett at oracle.com  Sat Aug 14 18:25:40 2021
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sat, 14 Aug 2021 18:25:40 +0000
Subject: Not-yet-discussed in HotSpot style guide: C++ Lambdas
In-Reply-To: <ac2cc5fd-574e-0634-900c-2f1bae0df517@littlepinkcloud.com>
References: <ac2cc5fd-574e-0634-900c-2f1bae0df517@littlepinkcloud.com>
Message-ID: <B944A2D3-38DD-4E94-A4A3-959B4A1D5F14@oracle.com>

> On Aug 14, 2021, at 5:28 AM, Andrew Haley <aph-open at littlepinkcloud.com> wrote:
> 
> https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md says:
> 
> "Undecided Features
> 
> This list is incomplete; it serves to explicitly call out some
> features that have not yet been discussed.  ...  Lambdas"
> 
> I can't see any reason to forbid Lambdas from a performance point of
> view, and they can add to readability and maintainability in C++ for
> the same reasons that they do in Java.
> 
> I have a job I'm working on (in the AArch64 back end) where Lambdas
> would be very useful.  How about I give it a try, and I'll produce the
> patch for review, as an initial proposal? Then anyone can put in their
> 2c worth.

Funny you should mention lambdas.  There has been a fair amount of
discussion around them internally here at Oracle.  And there are some
folks trying them out in not-yet-ready-for-production work.  I?ve drafted
a style-guide modification reflecting that discussion, along with a couple
examples, and am planning to open a PR in the next few days.

You can see the current work in progress here:

https://github.com/kimbarrett/openjdk-jdk/tree/permit_lambda

Note that I'm planning to rebase and do some commit refactoring / reordering
before opening the PR.

There is one downside that has recently been noted.  Stack frame names
in stack traces where lambdas are involved are pretty indecipherable.


From kbarrett at openjdk.java.net  Sun Aug 15 00:05:33 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 15 Aug 2021 00:05:33 GMT
Subject: RFR: 8221360: Eliminate Shared_DirtyCardQ_lock
Message-ID: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>

Please review this change to the handling of a very rare race condition in
concurrent refinement.  There is a situation where we many be unable to
process a card and need to re-dirty and re-enqueue it for later processing.

The old code handled this using a shared dirty card queue, which various
other places needed to know about as well.  This was the user of the
Shared_DirtyCardQ_lock.  It was the only remaining Mutex whose rank is based
on Mutex::access.

An option for eliminating that lock was to use a lock-free queue.  But
rather than take on that complexity, we instead brute-force the problem.
The new implementation simply allocates and enqueues an entire buffer for
the one card that needs to be reprocessed.  Those operations are already
lock-free.  The extra cost doesn't really matter, since this situation
almost never arises.

This is now done inline in refine_card_concurrently.  It's not worth the
overhead of a class for what is now just a few lines of code needed in
exactly one place.  Places that knew about the shared queue in order to
flush/reset it at certain points no longer have such responsibilities.

This change also renders JDK-8214997 moot, since there aren't any 'access'
locks.
https://bugs.openjdk.java.net/browse/JDK-8214997
Crash holding 'access' lock can deadlock in JVMCI compiler thread

This change also allows the removal of Mutex::access.  That's being left to
a new enhancement, since I think it also allows removing Mutex::tty,
reverting back to using Mutex::event for the tty_lock.  That is, essentially
undo JDK-8214315.
https://bugs.openjdk.java.net/browse/JDK-8272480

Testing:
mach5 tier1-5

-------------

Commit messages:
 - don't use shared dirty card queue

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

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

From iklam at openjdk.java.net  Mon Aug 16 04:16:48 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 16 Aug 2021 04:16:48 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC [v4]
In-Reply-To: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
Message-ID: <fbr9wMVNs5Iqd_m8tPMu8TgwwQIKq082dhV4233gdMM=.aa94fd84-e527-4192-82be-2042be530f87@github.com>

> **Overview:**
> 
> This is the first step for supporting archived heap objects for non-G1 collectors. We are doing it for EpsilonGC first to iron out the API between GC and CDS. Also we can implement most of the common code (such as copying archived objects into heap), without impacting the overall system stability.
> 
> - Only G1 can write archive heap objects into the CDS archive.
> - Archived objects are "mapped" by G1, but the mapping operation is quite complex.
> - All other collectors will "load" the archive objects, which is much simpler to implement. The trade off is a small start-up penalty and no heap sharing.
> 
> Most of the loading code is implemented in heapShared.cpp. The collectors just need to implement the following two `CollectedHeap` APIs in 
> 
> 
>   virtual bool can_load_archived_objects();
>   virtual HeapWord* allocate_loaded_archive_space(size_t size); // typically return a block in old gen
> 
> 
> **Implementation:**
> 
> - Allocate (from the old gen) a buffer that's large enough to contain all the archived heap objects.
> - Inside the CDS archive file, the heap objects are usually divided into 2~4 disjoint regions (there are gaps between them).
> - Copy every region in to the buffer consecutively, without any gaps.
> - Relocate all the oop fields in all the copied objects, taking into account of the gap removal.
> - The archived strings may be relocated by a full GC, but the CDS "shared string table" cannot handle relocation, so we copy the archived strings into the dynamic string table.
> 
> **Benchmarking:** 
> 
> We can see significant start-up improvement because the module graph can be loaded from CDS.
> 
> 
> $ perf stat -r 40 java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx256m -version
> 
> Before:  43.1ms
> After:   30.2ms
> 
> 
> Testing:
> 
> - Some general clean up of the test cases.
> - Added support for `-vmoptions:-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`: we dump the CDS archive with G1 so we have an archived heap, but run with EpsilonGC to test the new loading code.
> - Added a mach5 task to run all CDS tests with the above config. Incompatible test cases are tagged with `@require vm.gc == null`. See changes in CDSOption.java and VMProps.java

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - @shipilev review -- add verbose param to allocate_work()
 - Merge branch 'master' into 8270489-archived-heap-objects-for-epsilon-gc
 - @shipilev comments
 - @iignatev comments
 - fixed whitespaces
 - Add/update test cases
 - 8270489: Support archived heap objects in EpsilonGC

-------------

Changes: https://git.openjdk.java.net/jdk/pull/5074/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5074&range=03
  Stats: 800 lines in 31 files changed: 682 ins; 34 del; 84 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5074.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5074/head:pull/5074

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

From iklam at openjdk.java.net  Mon Aug 16 04:16:49 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 16 Aug 2021 04:16:49 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC [v2]
In-Reply-To: <OX6w3H68MEyBMxlX5NltiGOC5VOVqDrQEOfZr_3ib0M=.1f0154b8-97e4-4672-872a-1ef0f7923117@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
 <j-lv0HkKkf13P3MrGOXwBFs9WQgVjfjZ7FwLCVarqqU=.c1a192ef-3e4b-4cd9-946a-cf2e06a43f73@github.com>
 <T2Us2bJw_Mz11vp1C8uJi-0blh7h6Odk66ghjCBAjfk=.8cc5d3e9-f64d-40fb-a067-c4993a2d5c1f@github.com>
 <J6oVuxwmM5kW6az_-4AUDegJFfNjQJJBfxlY894TlbY=.2090005c-c7d5-43f0-8b8c-6817818b3a06@github.com>
 <OX6w3H68MEyBMxlX5NltiGOC5VOVqDrQEOfZr_3ib0M=.1f0154b8-97e4-4672-872a-1ef0f7923117@github.com>
Message-ID: <qdTpnoYOJ0Juz6ml6RyLN_hRlOxEqTsuP3UVw9_63ao=.cbea45a1-edf4-4b0f-939f-f951632a53a6@github.com>

On Thu, 12 Aug 2021 09:29:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I can't move `if (Metaspace::initialized())` into `EpsilonMonitoringSupport::update_counters()` because the code in this function also updates the global variable `_last_counter_update`.
>
> Yes, I understand that sacrifices the logging accuracy a bit: the `_last_counter_update` would include the initial CDS allocation. At the same time, I would not like to put `Metaspace::initialized()` checks on this (hot-when-not-TLAB) path, only to catch that initial allocation. So I suggest we add a boolean parameter like `allocate_work(size_t size, bool verbose)`, and call it with `false` from `allocate_loaded_archive_space`.

Fixed as you suggested in version  71c2aec.

-------------

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

From iklam at openjdk.java.net  Mon Aug 16 04:16:50 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 16 Aug 2021 04:16:50 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC [v3]
In-Reply-To: <0yJnNw_Y6euJ7FyDFhQ-qM1YgotNM0bYdhU6BRD7X8I=.8fca68e8-445a-40d4-88e2-b84bdee3d5cd@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
 <_J0BNLWCxKDLB_3avbkI4xnyHkFNk6vysVyrrc11Q3Q=.444a6d80-c734-4e71-9892-5046b166cc29@github.com>
 <0yJnNw_Y6euJ7FyDFhQ-qM1YgotNM0bYdhU6BRD7X8I=.8fca68e8-445a-40d4-88e2-b84bdee3d5cd@github.com>
Message-ID: <oIDvuNuZeXgZxfEKIzMZViJoG49pXWUx8TOhy6R3qTg=.d2801608-e7cf-42ff-b7ce-8507c83ac173@github.com>

On Thu, 12 Aug 2021 00:30:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @shipilev comments
>
> test/hotspot/jtreg/runtime/cds/ServiceLoaderTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
> 
> Incorrect copyright change: should be 2020, 2021,

This has been fixed in a separate PR (https://github.com/openjdk/jdk/pull/5095) and merged into this PR.

-------------

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

From shade at openjdk.java.net  Mon Aug 16 05:31:29 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 16 Aug 2021 05:31:29 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC [v4]
In-Reply-To: <fbr9wMVNs5Iqd_m8tPMu8TgwwQIKq082dhV4233gdMM=.aa94fd84-e527-4192-82be-2042be530f87@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
 <fbr9wMVNs5Iqd_m8tPMu8TgwwQIKq082dhV4233gdMM=.aa94fd84-e527-4192-82be-2042be530f87@github.com>
Message-ID: <YaiN2xJvcujdiuJyEztgzrRbXqS146HBUUZEB3I3tRg=.8bce7650-d0e7-4b8f-9519-0c2134b8adc3@github.com>

On Mon, 16 Aug 2021 04:16:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> **Overview:**
>> 
>> This is the first step for supporting archived heap objects for non-G1 collectors. We are doing it for EpsilonGC first to iron out the API between GC and CDS. Also we can implement most of the common code (such as copying archived objects into heap), without impacting the overall system stability.
>> 
>> - Only G1 can write archive heap objects into the CDS archive.
>> - Archived objects are "mapped" by G1, but the mapping operation is quite complex.
>> - All other collectors will "load" the archive objects, which is much simpler to implement. The trade off is a small start-up penalty and no heap sharing.
>> 
>> Most of the loading code is implemented in heapShared.cpp. The collectors just need to implement the following two `CollectedHeap` APIs in 
>> 
>> 
>>   virtual bool can_load_archived_objects();
>>   virtual HeapWord* allocate_loaded_archive_space(size_t size); // typically return a block in old gen
>> 
>> 
>> **Implementation:**
>> 
>> - Allocate (from the old gen) a buffer that's large enough to contain all the archived heap objects.
>> - Inside the CDS archive file, the heap objects are usually divided into 2~4 disjoint regions (there are gaps between them).
>> - Copy every region in to the buffer consecutively, without any gaps.
>> - Relocate all the oop fields in all the copied objects, taking into account of the gap removal.
>> - The archived strings may be relocated by a full GC, but the CDS "shared string table" cannot handle relocation, so we copy the archived strings into the dynamic string table.
>> 
>> **Benchmarking:** 
>> 
>> We can see significant start-up improvement because the module graph can be loaded from CDS.
>> 
>> 
>> $ perf stat -r 40 java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx256m -version
>> 
>> Before:  43.1ms
>> After:   30.2ms
>> 
>> 
>> Testing:
>> 
>> - Some general clean up of the test cases.
>> - Added support for `-vmoptions:-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`: we dump the CDS archive with G1 so we have an archived heap, but run with EpsilonGC to test the new loading code.
>> - Added a mach5 task to run all CDS tests with the above config. Incompatible test cases are tagged with `@require vm.gc == null`. See changes in CDSOption.java and VMProps.java
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - @shipilev review -- add verbose param to allocate_work()
>  - Merge branch 'master' into 8270489-archived-heap-objects-for-epsilon-gc
>  - @shipilev comments
>  - @iignatev comments
>  - fixed whitespaces
>  - Add/update test cases
>  - 8270489: Support archived heap objects in EpsilonGC

Epsilon parts look good to me.

src/hotspot/share/gc/epsilon/epsilonHeap.cpp line 268:

> 266: HeapWord* EpsilonHeap::allocate_loaded_archive_space(size_t size) {
> 267:   // Cannot use verbose=true because Metaspace is not initialized
> 268:   return allocate_work(size, /*verbose=*/false);

Suggestion:

  return allocate_work(size, /* verbose = */ false);

src/hotspot/share/gc/epsilon/epsilonHeap.hpp line 91:

> 89: 
> 90:   // Allocation
> 91:   HeapWord* allocate_work(size_t size, bool verbose=true);

Suggestion:

  HeapWord* allocate_work(size_t size, bool verbose = true);

-------------

Marked as reviewed by shade (Reviewer).

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

From stefan.karlsson at oracle.com  Mon Aug 16 06:19:43 2021
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 16 Aug 2021 08:19:43 +0200
Subject: Not-yet-discussed in HotSpot style guide: C++ Lambdas
In-Reply-To: <B944A2D3-38DD-4E94-A4A3-959B4A1D5F14@oracle.com>
References: <ac2cc5fd-574e-0634-900c-2f1bae0df517@littlepinkcloud.com>
 <B944A2D3-38DD-4E94-A4A3-959B4A1D5F14@oracle.com>
Message-ID: <78fa5233-c08a-384a-4689-0c7b6be97849@oracle.com>



On 2021-08-14 20:25, Kim Barrett wrote:
>> On Aug 14, 2021, at 5:28 AM, Andrew Haley <aph-open at littlepinkcloud.com> wrote:
>>
>> https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md says:
>>
>> "Undecided Features
>>
>> This list is incomplete; it serves to explicitly call out some
>> features that have not yet been discussed.  ...  Lambdas"
>>
>> I can't see any reason to forbid Lambdas from a performance point of
>> view, and they can add to readability and maintainability in C++ for
>> the same reasons that they do in Java.
>>
>> I have a job I'm working on (in the AArch64 back end) where Lambdas
>> would be very useful.  How about I give it a try, and I'll produce the
>> patch for review, as an initial proposal? Then anyone can put in their
>> 2c worth.
> Funny you should mention lambdas.  There has been a fair amount of
> discussion around them internally here at Oracle.  And there are some
> folks trying them out in not-yet-ready-for-production work.

We've been trying this out in the zgc_generational branch:

https://github.com/openjdk/zgc/tree/zgc_generational

For anyone that wants to take a look, search for [&].

>    I?ve drafted
> a style-guide modification reflecting that discussion, along with a couple
> examples, and am planning to open a PR in the next few days.
>
> You can see the current work in progress here:
>
> https://github.com/kimbarrett/openjdk-jdk/tree/permit_lambda
>
> Note that I'm planning to rebase and do some commit refactoring / reordering
> before opening the PR.
>
> There is one downside that has recently been noted.  Stack frame names
> in stack traces where lambdas are involved are pretty indecipherable.

Just to give an example what the frames sometimes look like in the debugger:

#3 
ZPageTableParallelIterator::do_pages<ZGenerationPagesParallelIterator::do_pages<ZRememberScanPageTask::work()::{lambda(ZPage*)#1}>(ZRememberScanPageTask::work()::{lambda(ZPage*)#1})::{lambda(ZPage*)#1}>(ZGenerationPagesParallelIterator::do_pages<ZRememberScanPageTask::work()::{lambda(ZPage*)#1}>(ZRememberScanPageTask::work()::{lambda(ZPage*)#1})::{lambda(ZPage*)#1})::{lambda(int)#1}::operator()(int) 
const (index=<optimized out>, this=<optimized out>) at 
/home/stefank/git/alt/open/src/hotspot/share/gc/z/zPageTable.inline.hpp:75

It's not this bad all the time, but it seems easy to end up in this 
situation when you write generic iterator code that accepts lambdas.

StefanK

>


From aph at openjdk.java.net  Mon Aug 16 09:12:34 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 16 Aug 2021 09:12:34 GMT
Subject: RFR: 8271869: AArch64: build errors with GCC11 in
 frame::saved_oop_result
In-Reply-To: <-H4Ipq5xE61C6-xDj1vD-_gdEZYQdIeXcAMl0ASu5Rs=.2378487e-0c95-4bf8-a6ee-671dfaef1c00@github.com>
References: <-H4Ipq5xE61C6-xDj1vD-_gdEZYQdIeXcAMl0ASu5Rs=.2378487e-0c95-4bf8-a6ee-671dfaef1c00@github.com>
Message-ID: <iaRVXKG8KXwmaNOPk8lJwsMjwGr-o2fNR2e8nGhneqM=.8d4fe008-4652-42ae-aad7-f088db0969ff@github.com>

On Thu, 5 Aug 2021 14:14:38 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> GCC11 warns that r0 is null. It does not complain if r1 is used instead.
> 
> AIUI, it is undefined behaviour in C++ to call member functions without
> a valid this pointer. So, technically GCC is correct to warn.

On 8/10/21 8:41 AM, Kim Barrett wrote:

> Yuck!  But I guess we don't have any other quick solution to
> supporting this compiler version, so as with JDK-8270083 I'm
> conditionally approving this as a temporary workaround.  I see this
> bug is already linked to JDK-8270140.
>
> @theRealAph - You mentioned a prototype patch to fix the register
> definitions (probably addressing JDK-8270140?).

Yes, it fixes that by making Register well-defined behaviour.

> How close are you on that?  Do you need any help?

The patch works just fine, but there is a smallish performance
degradation.  Having said that, the degradation is much less than the
performance gain from 8269122 (The use of "extern const" for Register
definitions generates poor code) so probably no-one would notice, and
we'd get rid of the undefined behaviour.  I didn't submit it because I
thought people rather liked the fake-pointer-to-nothing hack and
didn't care about UB. I can dig the patch out if you like.

-------------

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

From chagedorn at openjdk.java.net  Mon Aug 16 14:54:34 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 16 Aug 2021 14:54:34 GMT
Subject: Integrated: 8271471: [IR Framework] Rare occurrence of "<!--
 safepoint while printing -->" in PrintIdeal/PrintOptoAssembly can let tests
 fail
In-Reply-To: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
Message-ID: <F3RnnE1krqo-vPEx1QnF4PxLpJ5VmxRZqfkI2-ZZgbY=.b2a64cee-ebcc-4090-966c-cf47d92f096f@github.com>

On Thu, 29 Jul 2021 12:25:27 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> A test VM used by the IR framework sometimes prints `` in the middle of emitting a `PrintIdeal` or `PrintOptoAssembly` output which could lead to IR matching failures:
> https://github.com/openjdk/jdk/blob/489e5fd12a37a45f4f5ea64b05f85c6f99f70811/src/hotspot/share/utilities/ostream.cpp#L918-L927
> 
> I thought about just bailing out of IR matching if this string is found after a failure but this issue also affects internal framework tests (I observed one case locally where this happened in the test `TestIRMatching`, letting it fail).
> 
> Handling `` makes things more complicated for the IR framework tests. I'm not sure about the value of printing this message in the first place. But if nobody objects, I suggest to either remove it or at least guard it with `Verbose`, for example. I went with the latter solution in this PR.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 36777345
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3677734584859e1b4bea65f6719e839f949c9236
Stats:     102 lines in 5 files changed: 78 ins; 11 del; 13 mod

8271471: [IR Framework] Rare occurrence of "<!-- safepoint while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail

Reviewed-by: kvn, thartmann

-------------

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

From chagedorn at openjdk.java.net  Mon Aug 16 14:54:31 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 16 Aug 2021 14:54:31 GMT
Subject: RFR: 8271471: [IR Framework] Rare occurrence of "<!-- safepoint
 while printing -->" in PrintIdeal/PrintOptoAssembly can let tests fail [v5]
In-Reply-To: <YRw5msMUkovU4qPzPzvloaLw6jlgKmRSgSi8zemjvx4=.fa642ba6-67d1-4430-9015-a8cb02417dc8@github.com>
References: <MB6GKa5kwyPntgyY2gxjutz2MFI-UU7SRAYlxFuJNnI=.6681250b-ed13-4702-a4b8-b2831e1ebfa5@github.com>
 <YRw5msMUkovU4qPzPzvloaLw6jlgKmRSgSi8zemjvx4=.fa642ba6-67d1-4430-9015-a8cb02417dc8@github.com>
Message-ID: <ixEvk956dlhmFrKagZiE3j03dCJR921KRLIdNCoIX54=.9cafb336-7674-439a-8a20-cd8c7a5989f0@github.com>

On Tue, 10 Aug 2021 12:04:56 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> A test VM used by the IR framework sometimes prints `` in the middle of emitting a `PrintIdeal` or `PrintOptoAssembly` output which could lead to IR matching failures:
>> https://github.com/openjdk/jdk/blob/489e5fd12a37a45f4f5ea64b05f85c6f99f70811/src/hotspot/share/utilities/ostream.cpp#L918-L927
>> 
>> I thought about just bailing out of IR matching if this string is found after a failure but this issue also affects internal framework tests (I observed one case locally where this happened in the test `TestIRMatching`, letting it fail).
>> 
>> Handling `` makes things more complicated for the IR framework tests. I'm not sure about the value of printing this message in the first place. But if nobody objects, I suggest to either remove it or at least guard it with `Verbose`, for example. I went with the latter solution in this PR.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup & simplify test by using anyMatch

Thanks Vladimir for your review!

-------------

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

From stuart.monteith at arm.com  Mon Aug 16 22:39:28 2021
From: stuart.monteith at arm.com (Stuart Monteith)
Date: Mon, 16 Aug 2021 23:39:28 +0100
Subject: RFC: AArch64: Implementing spin pauses with ISB
In-Reply-To: <3FA517F5-3339-4C99-B9B3-15D733033D39@amazon.com>
References: <3FA517F5-3339-4C99-B9B3-15D733033D39@amazon.com>
Message-ID: <7b844fb8-4819-5f83-382c-f621a2794bd8@arm.com>

On 10/08/2021 22:52, Astigeevich, Evgeny wrote:
> Hello everyone.
> 
> We?d like to discuss a proposal for implementing spin pauses with the ISB instruction:
> 
> https://bugs.openjdk.java.net/browse/JDK-8186670 ?Implement _onSpinWait() intrinsic for AArch64?
> https://bugs.openjdk.java.net/browse/JDK-8258604 ?Use 'isb' instruction in SpinPause on linux-aarch64?
> 
> In 2017, Dmitry Chuyko from BellSoft proposed to implement onSpinWait() on ARM with the help of the YIELD instruction (see JDK-8186670). The contribution was discussed on the mailing list (http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2017-August/004870.html) but never made it into OpenJDK 10 because at that time there were no hardware YIELD implementations and the exact effect was therefore unknown. Dmitry did a nice writeup and produced some benchmark results (http://cr.openjdk.java.net/~dchuyko/8186670/yield/spinwait.html). He was able to test and measure his implementation only on Cavium ThunderX and Raspberry Pi 3, which both implement YIELD as a NOP. Improvements were therefore minimal.
> 
> As I am aware the YIELD instruction is still implemented as a NOP by most of AArch64 vendors. There were experiments to use a sequence of NOPs to emulate x86 PAUSE.
> At Amazon experiments with the ISB on Graviton 2 showed it can create a small delay without consuming ALU resources. It is more reliable than NOPs. The experiments resulted in contributions of ISB-based spin pauses to MySQL (https://bugs.mysql.com/bug.php?id=100664) and MongoDb (https://jira.mongodb.org/browse/WT-6872).
> 
> We have tested the ISB-based spin pauses for JDK11. Internal customer-based benchmarks showed 3% - 7% improvements in latencies and throughput.
> We also used https://github.com/ben-manes/caffeine/wiki/Benchmarks microbenchmarks and a SynchronousQueue microbenchmark (you can find it in https://bugs.openjdk.java.net/browse/JDK-8267502). Caffeine GetPutBenchmark for LinkedHashMap_Lru, which has synchronized accesses to a cache, got +14% - +29% improvement in throughput. The SynchronousQueue microbenchmark, which uses Thread.onSpinWait, got 2.9x improvement.
> 
> OpenJDK tip with the ISB-based spin pauses gets similar improvements in Caffeine GetPutBenchmark for LinkedHashMap_Lru. OpenJDK tip java.util.concurrent.SynchronousQueue does not use Thread.onSpinWait. Because of this the SynchronousQueue microbenchmark gets no improvements.
> 
> We would like to contribute the ISB-based spin pauses implementation to OpenJDK: SpinPause (https://github.com/corretto/corretto-11/commit/dfb4965877a5810011514bd9294175eccd4b6d0d) and intrinsic (https://github.com/corretto/corretto-11/commit/a49a79bb2e7ac4a2265c51c9fb1c3fcf90dc7c9d).
> If there is an interest in the contribution, the open question is whether it should be enabled for all AArch64 implementations or only for Neoverse N1.
> 
> Comments welcome!
> 
> Thanks,
> Evgeny
> 
> 
> 
> Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.
> 
> 

Hello Evgeny,
	This is interesting, and thank you for bringing it up for discussion here. The ISB instruction wasn't intended to be 
used for that purpose, so while you can measure a benefit for now, there is no guarantee that it would continue to be 
beneficial in the future. I hate to suggest adding more flags, but we ought to consider adding one to disable the ISB 
instruction in the spins. The counter argument is of course that we'd update the implementation as new cores come out.

Your experiments were with one ISB - did you experiment at all with multiple ISBs? I'm curious as to what the overall 
effect would be.

BR,
	Stuart

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 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: <UStqqHBtpUriKdou0OYnJnIPd0puWyqCUonD5DTs8pY=.2752bf5c-c2ee-448f-b672-99e51ab0a700@github.com>

On Mon, 16 Aug 2021 23:31:41 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> 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 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: <jnrub-odrT4PdXJ90nAdfKuZNIwK1xWMhiwiPrIZHGI=.76f4d360-13e1-4705-8cf8-460712032bce@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
 <jnrub-odrT4PdXJ90nAdfKuZNIwK1xWMhiwiPrIZHGI=.76f4d360-13e1-4705-8cf8-460712032bce@github.com>
Message-ID: <pHyfQWjFBkJ4GndKWANhdMmWMjIvsLixQe-ooDybmfc=.4bb5517f-60d4-46d0-821b-a19e8bafc2df@github.com>

On Mon, 16 Aug 2021 23:47:04 GMT, Igor Ignatyev <iignatyev at openjdk.org> 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: <jnrub-odrT4PdXJ90nAdfKuZNIwK1xWMhiwiPrIZHGI=.76f4d360-13e1-4705-8cf8-460712032bce@github.com>

On Mon, 16 Aug 2021 23:31:41 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> 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 github.com+2249648+johntortugo at openjdk.java.net  Tue Aug 17 00:44:14 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Tue, 17 Aug 2021 00:44:14 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2 IGV
 transformations
Message-ID: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>

Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:

- Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
- Add more default IR regex's to IR-based test framework.
- Changes to Sub, Div and Add Ideal nodes to that transformations on Int and Long types are the whenever possible same.
- Changes to Sub*Node, Div*Node and Add*Node Ideal methods to fix some bugs and include new transformations.
- New JTREG "ir_transformations" test group under test/hotspot/jtreg.

-------------

Commit messages:
 - Fix carriage returns one more time.
 - Fix more carriage returns.
 - Fixing carriage return chars.
 - Adding some tests for Ideal transformations.

Changes: https://git.openjdk.java.net/jdk/pull/5135/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5135&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267265
  Stats: 1889 lines in 15 files changed: 1833 ins; 45 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5135/head:pull/5135

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

From github.com+2249648+johntortugo at openjdk.java.net  Tue Aug 17 00:46:29 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Tue, 17 Aug 2021 00:46:29 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 IGV transformations
In-Reply-To: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
References: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
Message-ID: <4gZ8CY_yHgLXsiO53UEhV5iWB3PFlq0NbEnOeMY7XGg=.6657b9b7-2f9a-43f0-8737-1dfe937b4d62@github.com>

On Tue, 17 Aug 2021 00:20:13 GMT, John Tortugo <github.com+2249648+JohnTortugo at openjdk.org> wrote:

> Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:
> 
> - Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
> - Add more default IR regex's to IR-based test framework.
> - Changes to Sub, Div and Add Ideal nodes to that transformations on Int and Long types are the whenever possible same.
> - Changes to Sub*Node, Div*Node and Add*Node Ideal methods to fix some bugs and include new transformations.
> - New JTREG "ir_transformations" test group under test/hotspot/jtreg.

@chhagedorn - I finally managed to get some time to work again on this. Can you please take a look?

-------------

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

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: <jnrub-odrT4PdXJ90nAdfKuZNIwK1xWMhiwiPrIZHGI=.76f4d360-13e1-4705-8cf8-460712032bce@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
 <jnrub-odrT4PdXJ90nAdfKuZNIwK1xWMhiwiPrIZHGI=.76f4d360-13e1-4705-8cf8-460712032bce@github.com>
Message-ID: <LOccRDfJbpa2gbpdDW-qmb_kHSmxvLiERRZDayfDTx4=.e5323e1c-4bed-42d7-ab4a-e43d12d4f757@github.com>

On Mon, 16 Aug 2021 23:48:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> 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 stuefe at openjdk.java.net  Tue Aug 17 03:41:27 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 17 Aug 2021 03:41:27 GMT
Subject: RFR: 8271490: [ppc] [s390]: Crash in
 JavaThread::pd_get_top_frame_for_profiling
In-Reply-To: <bD_GSVWnQEH5L4k08xN_CH7jtbpmHl7b5mwhLb_03lo=.81186ce8-3345-498c-934e-c4bf03bf80ab@github.com>
References: <bD_GSVWnQEH5L4k08xN_CH7jtbpmHl7b5mwhLb_03lo=.81186ce8-3345-498c-934e-c4bf03bf80ab@github.com>
Message-ID: <fNuYmXCXTEQdRlNAvOXG6pnIfi7-_PYhSvtxjiDQnB0=.0d065e3d-7698-4b16-b82a-584f04168bff@github.com>

On Tue, 10 Aug 2021 14:50:34 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> Please review this pull request. It hardens the code on ppc and s390 against crashes while collecting stack traces for JFR. Stack frame collection in prims/forte.cpp will benefit from this fix as well as it uses the same platform-specific code.
> 
> Testing:
> SAP-internal functional and stress testing. Verifying a positive effect is hard because the targeted crashes occur only very rarely. No negative side effects of the fix have been observed.

LGTM. Minor comment nits.

src/hotspot/os_cpu/linux_s390/thread_linux_s390.cpp line 97:

> 95:       //  - ijava_state_unchecked() calculates it's result as
> 96:       //      istate = fp() - z_ijava_state_size() = NULL - 0x68 DEBUG_ONLY(-8)
> 97:       //  - istate->method dereferences memory at offset 8 from istate

I think a reference to the JBS issue would suffice as a comment here.

-------------

Marked as reviewed by stuefe (Reviewer).

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

From lucy at openjdk.java.net  Tue Aug 17 07:39:26 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 17 Aug 2021 07:39:26 GMT
Subject: RFR: 8271490: [ppc] [s390]: Crash in
 JavaThread::pd_get_top_frame_for_profiling
In-Reply-To: <fNuYmXCXTEQdRlNAvOXG6pnIfi7-_PYhSvtxjiDQnB0=.0d065e3d-7698-4b16-b82a-584f04168bff@github.com>
References: <bD_GSVWnQEH5L4k08xN_CH7jtbpmHl7b5mwhLb_03lo=.81186ce8-3345-498c-934e-c4bf03bf80ab@github.com>
 <fNuYmXCXTEQdRlNAvOXG6pnIfi7-_PYhSvtxjiDQnB0=.0d065e3d-7698-4b16-b82a-584f04168bff@github.com>
Message-ID: <H8PAnYbxxh0RJBAl9PasUCxtS_GvZvuxvwtVgheLxI0=.f695d0b4-9e8f-497e-9c2f-56f25178e93a@github.com>

On Tue, 17 Aug 2021 03:37:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this pull request. It hardens the code on ppc and s390 against crashes while collecting stack traces for JFR. Stack frame collection in prims/forte.cpp will benefit from this fix as well as it uses the same platform-specific code.
>> 
>> Testing:
>> SAP-internal functional and stress testing. Verifying a positive effect is hard because the targeted crashes occur only very rarely. No negative side effects of the fix have been observed.
>
> src/hotspot/os_cpu/linux_s390/thread_linux_s390.cpp line 97:
> 
>> 95:       //  - ijava_state_unchecked() calculates it's result as
>> 96:       //      istate = fp() - z_ijava_state_size() = NULL - 0x68 DEBUG_ONLY(-8)
>> 97:       //  - istate->method dereferences memory at offset 8 from istate
> 
> I think a reference to the JBS issue would suffice as a comment here.

Years ago, I was told that direct references to JBS bugs in the code are strongly discouraged. On the other hand, I regard it as very important to have a detailed description available. So what to do? I need a second review anyway. Maybe she has a third opinion on that.

-------------

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

From lucy at openjdk.java.net  Tue Aug 17 07:39:27 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 17 Aug 2021 07:39:27 GMT
Subject: RFR: 8271490: [ppc] [s390]: Crash in
 JavaThread::pd_get_top_frame_for_profiling
In-Reply-To: <H8PAnYbxxh0RJBAl9PasUCxtS_GvZvuxvwtVgheLxI0=.f695d0b4-9e8f-497e-9c2f-56f25178e93a@github.com>
References: <bD_GSVWnQEH5L4k08xN_CH7jtbpmHl7b5mwhLb_03lo=.81186ce8-3345-498c-934e-c4bf03bf80ab@github.com>
 <fNuYmXCXTEQdRlNAvOXG6pnIfi7-_PYhSvtxjiDQnB0=.0d065e3d-7698-4b16-b82a-584f04168bff@github.com>
 <H8PAnYbxxh0RJBAl9PasUCxtS_GvZvuxvwtVgheLxI0=.f695d0b4-9e8f-497e-9c2f-56f25178e93a@github.com>
Message-ID: <V5AFxKa25DFtQeNctWtpeDt6BhhmKpDGcvyAGZ2UxbE=.e682278c-c7d3-4903-b0b7-836c88370a77@github.com>

On Tue, 17 Aug 2021 07:35:54 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> src/hotspot/os_cpu/linux_s390/thread_linux_s390.cpp line 97:
>> 
>>> 95:       //  - ijava_state_unchecked() calculates it's result as
>>> 96:       //      istate = fp() - z_ijava_state_size() = NULL - 0x68 DEBUG_ONLY(-8)
>>> 97:       //  - istate->method dereferences memory at offset 8 from istate
>> 
>> I think a reference to the JBS issue would suffice as a comment here.
>
> Years ago, I was told that direct references to JBS bugs in the code are strongly discouraged. On the other hand, I regard it as very important to have a detailed description available. So what to do? I need a second review anyway. Maybe she has a third opinion on that.

By the way: Thanks a lot for the review!!!

-------------

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

From aph-open at littlepinkcloud.com  Tue Aug 17 08:23:50 2021
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Tue, 17 Aug 2021 09:23:50 +0100
Subject: RFC: AArch64: Implementing spin pauses with ISB
In-Reply-To: <7b844fb8-4819-5f83-382c-f621a2794bd8@arm.com>
References: <3FA517F5-3339-4C99-B9B3-15D733033D39@amazon.com>
 <7b844fb8-4819-5f83-382c-f621a2794bd8@arm.com>
Message-ID: <052f9107-f4d7-9d90-bb49-9d1d43e5bdba@littlepinkcloud.com>

On 8/16/21 11:39 PM, Stuart Monteith wrote:

> 	This is interesting, and thank you for bringing it up for discussion here. The ISB instruction wasn't intended to be 
> used for that purpose, so while you can measure a benefit for now, there is no guarantee that it would continue to be 
> beneficial in the future. I hate to suggest adding more flags, but we ought to consider adding one to disable the ISB 
> instruction in the spins. The counter argument is of course that we'd update the implementation as new cores come out.

Indeed. It all sounds a bit like witchcraft to me. I guess that any instruction
which caused a significant stall would reduce contention, but it'd take some
experiments to confirm that.

Evgeny, did anyone try waiting on the monitor location with a WFE? That'd at
least be using an instruction as intended, and would certainly reduce contention,
but WFE might be too drastic for a brief spin lock.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From hirt at openjdk.java.net  Tue Aug 17 08:37:25 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Tue, 17 Aug 2021 08:37:25 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v3]
In-Reply-To: <eebr3nRX7hK2JWexDfv8WJD4f6w-YzBPZ-A2ps3RquU=.1b6132d6-0c47-4b07-9e66-e1563b2b0b5c@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <jfohRNi3z8LnjHcxEzmJNhuO7nKKEtBY5bhR-8uycVI=.b410939d-7166-4ea7-a046-c8ca8f2dcc93@github.com>
 <eebr3nRX7hK2JWexDfv8WJD4f6w-YzBPZ-A2ps3RquU=.1b6132d6-0c47-4b07-9e66-e1563b2b0b5c@github.com>
Message-ID: <O5qloDOgFuIb1VcZdbACL83pQhZZ124SBMVBx0brZGM=.58cd0ee3-84cb-4c49-adaf-7544dd9c8d47@github.com>

On Wed, 30 Jun 2021 09:17:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comments
>
> Hi Ludovic,
> You need two reviews including one (R)eviewer before integration of your fix.
> Thanks,
> Serguei

Hi @sspitsyn! Will you be the one reviewing this?

-------------

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

From aph-open at littlepinkcloud.com  Tue Aug 17 09:44:44 2021
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Tue, 17 Aug 2021 10:44:44 +0100
Subject: RFC: AArch64: Implementing spin pauses with ISB
In-Reply-To: <052f9107-f4d7-9d90-bb49-9d1d43e5bdba@littlepinkcloud.com>
References: <3FA517F5-3339-4C99-B9B3-15D733033D39@amazon.com>
 <7b844fb8-4819-5f83-382c-f621a2794bd8@arm.com>
 <052f9107-f4d7-9d90-bb49-9d1d43e5bdba@littlepinkcloud.com>
Message-ID: <c18b06cb-729b-628e-a1ba-a1d4d921c6c5@littlepinkcloud.com>

On 8/17/21 9:23 AM, Andrew Haley wrote:
> On 8/16/21 11:39 PM, Stuart Monteith wrote:
>
>> 	This is interesting, and thank you for bringing it up for discussion here. The ISB instruction wasn't intended to be
>> used for that purpose, so while you can measure a benefit for now, there is no guarantee that it would continue to be
>> beneficial in the future. I hate to suggest adding more flags, but we ought to consider adding one to disable the ISB
>> instruction in the spins. The counter argument is of course that we'd update the implementation as new cores come out.
>
> Indeed. It all sounds a bit like witchcraft to me. I guess that any instruction
> which caused a significant stall would reduce contention, but it'd take some
> experiments to confirm that.

One other thing: I'm a bit wary of all this, given that Intel had a
bit of a hiccup with PAUSE. On Skylake, the latency of PAUSE was
suddenly increased, causing a slowdown in some software:

---------------------------------------------------------------------
8.4.7  Pause Latency in Skylake Microarchitecture

The PAUSE instruction is typically used with software threads
executing on two logical processors located in the same processor
core, waiting for a lock to be released. Such short wait loops tend to
last between tens and a few hundreds of cycles, so performance-wise it
is more beneficial to wait while occupying the CPU than yielding to
the OS. ...

The latency of PAUSE instruction in prior generation microarchitecture
is about 10 cycles, whereas on Skylake microarchitecture it has been
extended to as many as 140 cycles.  The increased latency (allowing
more effective utilization of competitively-shared microarchitectural
resources to the logical processor ready to make forward progress) has
a small positive performance impact of 1-2% on highly threaded
applications. It is expected to have negligible impact on less
threaded applications if forward progress is not blocked on executing
a fixed number of looped PAUSE instructions.  There's also a small
power benefit in 2-core and 4-core systems.  As the PAUSE latency has
been increased significantly, workloads that are sensitive to PAUSE
latency will suffer some performance loss.
---------------------------------------------------------------------

So, what seems to have happened is that new deployments can have a
preformance reduction of unpredicatble duration, depending on what
Intel choose do next time.

Unless we can predict what a YIELD will actually do, it's a bit risky
to use it in highly-contended applications. I guess ISB is a bit more
predictable, in that we know what it does in theory, although not in
detail for each design. I wonder if we could find some kind of
pluggable design, perhaps along the lines of -XX:UseOnSpinWait=ISB.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From chagedorn at openjdk.java.net  Tue Aug 17 11:18:26 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 17 Aug 2021 11:18:26 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 IGV transformations
In-Reply-To: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
References: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
Message-ID: <q4yXuw6KCd6stuAmLaNdI891rKOeN08TjMrXeXkiBkw=.aec2b77b-e487-4cd4-88e0-7b01ecc18eaf@github.com>

On Tue, 17 Aug 2021 00:20:13 GMT, John Tortugo <github.com+2249648+JohnTortugo at openjdk.org> wrote:

> Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:
> 
> - Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
> - Add more default IR regex's to IR-based test framework.
> - Changes to Sub, Div and Add Ideal nodes to that transformations on Int and Long types are the whenever possible same.
> - Changes to Sub*Node, Div*Node and Add*Node Ideal methods to fix some bugs and include new transformations.
> - New JTREG "ir_transformations" test group under test/hotspot/jtreg.

First of all, thanks a lot for diving into the various C2 IR transformations and creating IR tests for them! It's valuable to have a test for each of them. Some general points:

- I think you should split the work into the creation of new IR tests of existing transformations (this RFE) and changing actual C2 IR transformations. I suggest to file a new RFE or bug for missing/potential wrong transformations with the corresponding IR tests for them.
- I have only skimmed through the IR tests, yet. I will wait with reviewing them closer in case you decide to transform some of them into custom run tests (see comments in files).
- You should add the `hotspot-compiler` label to the PR as the tests are for C2.

Thanks,
Christian

src/hotspot/share/opto/divnode.cpp line 481:

> 479:   if (op1 == Op_MulI && in1->in(1) == in2) {
> 480:     return new AddINode(in1->in(2), phase->intcon(0));
> 481:   }

I don't think that these transformations are valid due to overflow/underflow. Example:

int x = 1_000_000;
int y = 10_000;
System.out.println((x * y) / x); // Output: 1410 (!= 1_000_000)

You might come up with some special case handling where it applies without an overflow/underflow but I'm not sure if it's worth to do it while not being fragile.

src/hotspot/share/opto/divnode.cpp line 601:

> 599:   if (op1 == Op_MulL && in1->in(1) == in2) {
> 600:     return new AddLNode(in1->in(2), phase->longcon(0));
> 601:   }

Same problem as above.

test/hotspot/jtreg/TEST.groups line 76:

> 74: hotspot_ir_transformations = \
> 75:   ir_transformations
> 76: 

It would be better to move IR tests into a folder within `compiler`. These tests will then always be executed together with the other compiler tests. Then you can remove these lines. 

It might be a good idea in general to collect IR tests in a separate folder to have more control over them or run them with stress flags in the future etc. As you are the first one to add any IR tests with the new framework, we have some freedom to do a choice now where to put such IR tests in the future. I might suggest `compiler/ir_framework` as location, also with the option to add subfolders there, but maybe @iignatev can provide some more insights/better suggestions on this topic.

test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 47:

> 45:  * @see IR
> 46:  */
> 47: public class IRNode {

I guess your IDE has applied an alphabetical sorting? I think it's better to keep the old sorting by categories which makes it easier to find specific regexes or to check if a regex is supported or not.

test/hotspot/jtreg/ir_transformations/AddINodeIdealizationTests.java line 23:

> 21:  * questions.
> 22:  */
> 23: package ir_transformations;

Needs to be changed accordingly when updating the test location (see comments above).

test/hotspot/jtreg/ir_transformations/AddINodeIdealizationTests.java line 45:

> 43:     public int simpleZero(int x) {
> 44:         return (x + x) + (x + x);
> 45:     }

This test is named `simpleZero` but the result is `4*x`. Is the method name wrong or is there a mistake in the test itself?

test/hotspot/jtreg/ir_transformations/AddINodeIdealizationTests.java line 53:

> 51:     public int simpleZeroSub(int x) {
> 52:         return (x - x) + (x - x);
> 53:     }

Just an idea: You could also think about transforming some of these base tests into [custom run tests](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/lib/ir_framework/test/CustomRunTest.java) or [checked tests](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/lib/ir_framework/test/CheckedTest.java) (might be enough for simple tests). This could not only verify the correct IR transformations but also that these tests compute the correct results, especially for edge case values (if it makes sense in a particular test). 

A custom run test could look something like this:


    @Test
    @IR(failOn = {IRNode.LOAD, IRNode.STORE, IRNode.MUL, IRNode.DIV, IRNode.SUB})
    // Checks (x - x) => 0 and 0 - 0 => 0
    public int simpleZeroSub(int x) {
        return (x - x) + (x - x);
    }

    @Run(test = "simpleZeroSub")
    public void runSimpleZeroSub() { // Run methods are not compiled and thus run in interpreter
        // This getRandom() call is only supported once JDK-8272567 is in for which a PR is currently open.
        int x = RunInfo.getRandom().nextInt(); // Some random value 
        Asserts.assertEQ(0, simpleZeroSub(x)); // Result check done in interpreter
        x = Integer.MAX_VALUE; // Some edge value
        Asserts.assertEQ(0, simpleZeroSub(x));
        // ...
    }

It might not provide additional value for all your tests but I guess that some of these tests would benefit from additional result checking. I leave it up to you to decide where and if you want to apply these changes.

-------------

Changes requested by chagedorn (Reviewer).

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

From hohensee at amazon.com  Tue Aug 17 13:22:43 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 17 Aug 2021 13:22:43 +0000
Subject: RFC: AArch64: Implementing spin pauses with ISB
Message-ID: <D6E01255-FBBA-4092-8AA6-86BF2255FA08@amazon.com>

What if we made using ISB conditional on the implementation, in this case N1?

Thanks,
Paul

?-----Original Message-----
From: hotspot-dev <hotspot-dev-retn at openjdk.java.net> on behalf of Andrew Haley <aph-open at littlepinkcloud.com>
Date: Tuesday, August 17, 2021 at 1:26 AM
To: "hotspot-dev at openjdk.java.net" <hotspot-dev at openjdk.java.net>
Subject: Re: RFC: AArch64: Implementing spin pauses with ISB

On 8/16/21 11:39 PM, Stuart Monteith wrote:

>       This is interesting, and thank you for bringing it up for discussion here. The ISB instruction wasn't intended to be
> used for that purpose, so while you can measure a benefit for now, there is no guarantee that it would continue to be
> beneficial in the future. I hate to suggest adding more flags, but we ought to consider adding one to disable the ISB
> instruction in the spins. The counter argument is of course that we'd update the implementation as new cores come out.

Indeed. It all sounds a bit like witchcraft to me. I guess that any instruction
which caused a significant stall would reduce contention, but it'd take some
experiments to confirm that.

Evgeny, did anyone try waiting on the monitor location with a WFE? That'd at
least be using an instruction as intended, and would certainly reduce contention,
but WFE might be too drastic for a brief spin lock.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From kbarrett at openjdk.java.net  Tue Aug 17 13:56:42 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 17 Aug 2021 13:56:42 GMT
Subject: RFR: 8264707: HotSpot Style Guide should permit use of lambda
Message-ID: <ClF_S5jjfQ911hsUdbxKkaXjVyJ1euXgkDT8JB5fkSs=.42f08fe5-abd8-4839-858b-036e3012ba6b@github.com>

Please review this proposal to permit the use of lambda expressions in
HotSpot code, with some restrictions and suggestions for good usage within
HotSpot code.  Lambda expressions were added in C++11, and provide a more
expressive syntax for local functions, with a number of use-cases where they
can improve readability by eliminating a lot of uninteresting boilerplate.

Some example uses are included, but are not part of the proposed change.
They will be removed from the PR before it is pushed.  (In particular, the
ScopeGuard utility uses move semantics, the use of which hasn't been
approved or even discussed.)  They are given to show some of the benefits
that might accrue from permitting the use of lambdas. In particular, they
highlight some of the code reduction that is possible. Some of these code
changes might be proposed in the future, using the normal PR process.

This is a modification of the Style Guide, so rough consensus among the
HotSpot Group members is required to make this change.  Only Group members
should vote for approval (via the github PR), though reasoned objections or
comments from anyone will be considered.  A decision on this proposal will
not be made before Wednesday 1-Sep-2021 at 12h00 UTC.

Since we're piggybacking on github PRs here, please use the PR review
process to approve (click on Review Changes > Approve), rather than sending
a "vote: yes" email reply that would be normal for a CFV.

-------------

Commit messages:
 - add scope guard and some example uses
 - G1 SATB filter lambda
 - new local functions section

Changes: https://git.openjdk.java.net/jdk/pull/5144/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5144&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264707
  Stats: 406 lines in 5 files changed: 354 ins; 40 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5144.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5144/head:pull/5144

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

From kim.barrett at oracle.com  Tue Aug 17 14:00:51 2021
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 17 Aug 2021 14:00:51 +0000
Subject: Not-yet-discussed in HotSpot style guide: C++ Lambdas
In-Reply-To: <B944A2D3-38DD-4E94-A4A3-959B4A1D5F14@oracle.com>
References: <ac2cc5fd-574e-0634-900c-2f1bae0df517@littlepinkcloud.com>
 <B944A2D3-38DD-4E94-A4A3-959B4A1D5F14@oracle.com>
Message-ID: <7CA77D40-F95D-43C2-9748-E62C4F8D12D2@oracle.com>

> On Aug 14, 2021, at 2:25 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
>> On Aug 14, 2021, at 5:28 AM, Andrew Haley <aph-open at littlepinkcloud.com> wrote:
>> 
>> https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md says:
>> 
>> "Undecided Features
>> 
>> This list is incomplete; it serves to explicitly call out some
>> features that have not yet been discussed.  ...  Lambdas"
>> 
> 
> Funny you should mention lambdas.  There has been a fair amount of
> discussion around them internally here at Oracle.  And there are some
> folks trying them out in not-yet-ready-for-production work.  I?ve drafted
> a style-guide modification reflecting that discussion, along with a couple
> examples, and am planning to open a PR in the next few days.
> 
> You can see the current work in progress here:
> 
> https://github.com/kimbarrett/openjdk-jdk/tree/permit_lambda
> 
> Note that I'm planning to rebase and do some commit refactoring / reordering
> before opening the PR.

https://github.com/openjdk/jdk/pull/5144


From stefank at openjdk.java.net  Tue Aug 17 14:12:22 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 17 Aug 2021 14:12:22 GMT
Subject: RFR: 8264707: HotSpot Style Guide should permit use of lambda
In-Reply-To: <ClF_S5jjfQ911hsUdbxKkaXjVyJ1euXgkDT8JB5fkSs=.42f08fe5-abd8-4839-858b-036e3012ba6b@github.com>
References: <ClF_S5jjfQ911hsUdbxKkaXjVyJ1euXgkDT8JB5fkSs=.42f08fe5-abd8-4839-858b-036e3012ba6b@github.com>
Message-ID: <ISNk7ZEjcUlt1m70HG3dtFTd3nIMKQhY-LWB1-Uw4Hs=.a7412fd9-6c2a-4762-b88c-8c3e57782d7d@github.com>

On Tue, 17 Aug 2021 13:49:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this proposal to permit the use of lambda expressions in
> HotSpot code, with some restrictions and suggestions for good usage within
> HotSpot code.  Lambda expressions were added in C++11, and provide a more
> expressive syntax for local functions, with a number of use-cases where they
> can improve readability by eliminating a lot of uninteresting boilerplate.
> 
> Some example uses are included, but are not part of the proposed change.
> They will be removed from the PR before it is pushed.  (In particular, the
> ScopeGuard utility uses move semantics, the use of which hasn't been
> approved or even discussed.)  They are given to show some of the benefits
> that might accrue from permitting the use of lambdas. In particular, they
> highlight some of the code reduction that is possible. Some of these code
> changes might be proposed in the future, using the normal PR process.
> 
> This is a modification of the Style Guide, so rough consensus among the
> HotSpot Group members is required to make this change.  Only Group members
> should vote for approval (via the github PR), though reasoned objections or
> comments from anyone will be considered.  A decision on this proposal will
> not be made before Wednesday 1-Sep-2021 at 12h00 UTC.
> 
> Since we're piggybacking on github PRs here, please use the PR review
> process to approve (click on Review Changes > Approve), rather than sending
> a "vote: yes" email reply that would be normal for a CFV.

Marked as reviewed by stefank (Reviewer).

-------------

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

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: <NPi2G0bRVmGneWyQAy8r2kp4zJDWsVw0Y69humawy9M=.1d234686-5053-4727-8b31-48c7796bb635@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()

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 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: <NPi2G0bRVmGneWyQAy8r2kp4zJDWsVw0Y69humawy9M=.1d234686-5053-4727-8b31-48c7796bb635@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
 <NPi2G0bRVmGneWyQAy8r2kp4zJDWsVw0Y69humawy9M=.1d234686-5053-4727-8b31-48c7796bb635@github.com>
Message-ID: <tTL-Jc27gD1qm3Jm9Bu1NPRjH_BoAjEIG2eFPheqgPA=.301b2c1e-8fb9-491f-a30b-ff00d41a042b@github.com>

On Tue, 17 Aug 2021 14:58:48 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> 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 iignatyev at openjdk.java.net  Tue Aug 17 15:39:26 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 17 Aug 2021 15:39:26 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 IGV transformations
In-Reply-To: <q4yXuw6KCd6stuAmLaNdI891rKOeN08TjMrXeXkiBkw=.aec2b77b-e487-4cd4-88e0-7b01ecc18eaf@github.com>
References: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
 <q4yXuw6KCd6stuAmLaNdI891rKOeN08TjMrXeXkiBkw=.aec2b77b-e487-4cd4-88e0-7b01ecc18eaf@github.com>
Message-ID: <XgfE5LZPC81gHqf2GuBZ59PylILUaDNS68H2Jl52TvQ=.efdbc2a5-9bc0-4044-9f3e-408cbf8cc64e@github.com>

On Tue, 17 Aug 2021 07:50:55 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:
>> 
>> - Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
>> - Add more default IR regex's to IR-based test framework.
>> - Changes to Sub, Div and Add Ideal nodes to that transformations on Int and Long types are the whenever possible same.
>> - Changes to Sub*Node, Div*Node and Add*Node Ideal methods to fix some bugs and include new transformations.
>> - New JTREG "ir_transformations" test group under test/hotspot/jtreg.
>
> test/hotspot/jtreg/TEST.groups line 76:
> 
>> 74: hotspot_ir_transformations = \
>> 75:   ir_transformations
>> 76: 
> 
> It would be better to move IR tests into a folder within `compiler`. These tests will then always be executed together with the other compiler tests. Then you can remove these lines. 
> 
> It might be a good idea in general to collect IR tests in a separate folder to have more control over them or run them with stress flags in the future etc. As you are the first one to add any IR tests with the new framework, we have some freedom to do a choice now where to put such IR tests in the future. I might suggest `compiler/ir_framework` as location, also with the option to add subfolders there, but maybe @iignatev can provide some more insights/better suggestions on this topic.

as these tests are c2 tests, they are to be inside `test/hotspot/jtreg/compiler/c2`. I don't think `ir_framework` is a good directory name, as they aren't tests for `ir_framework`, nor `ir_framework` itself,  so I'd suggest `test/hotspot/jtreg/compiler/c2/ir_transformations`, or `test/hotspot/jtreg/compiler/c2/idealization`.

on a separate note, @JohnTortugo why have you added a dedicated group for these tests?

-- Igor

-------------

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

From chagedorn at openjdk.java.net  Tue Aug 17 15:55:28 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 17 Aug 2021 15:55:28 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 IGV transformations
In-Reply-To: <XgfE5LZPC81gHqf2GuBZ59PylILUaDNS68H2Jl52TvQ=.efdbc2a5-9bc0-4044-9f3e-408cbf8cc64e@github.com>
References: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
 <q4yXuw6KCd6stuAmLaNdI891rKOeN08TjMrXeXkiBkw=.aec2b77b-e487-4cd4-88e0-7b01ecc18eaf@github.com>
 <XgfE5LZPC81gHqf2GuBZ59PylILUaDNS68H2Jl52TvQ=.efdbc2a5-9bc0-4044-9f3e-408cbf8cc64e@github.com>
Message-ID: <BKEtTh_TfaN9GtjQJeDpjEy-icmG6F1XTwuRtaMndqo=.46ed7685-23bf-4774-b337-c77c101d4585@github.com>

On Tue, 17 Aug 2021 15:36:20 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> test/hotspot/jtreg/TEST.groups line 76:
>> 
>>> 74: hotspot_ir_transformations = \
>>> 75:   ir_transformations
>>> 76: 
>> 
>> It would be better to move IR tests into a folder within `compiler`. These tests will then always be executed together with the other compiler tests. Then you can remove these lines. 
>> 
>> It might be a good idea in general to collect IR tests in a separate folder to have more control over them or run them with stress flags in the future etc. As you are the first one to add any IR tests with the new framework, we have some freedom to do a choice now where to put such IR tests in the future. I might suggest `compiler/ir_framework` as location, also with the option to add subfolders there, but maybe @iignatev can provide some more insights/better suggestions on this topic.
>
> as these tests are c2 tests, they are to be inside `test/hotspot/jtreg/compiler/c2`. I don't think `ir_framework` is a good directory name, as they aren't tests for `ir_framework`, nor `ir_framework` itself,  so I'd suggest `test/hotspot/jtreg/compiler/c2/ir_transformations`, or `test/hotspot/jtreg/compiler/c2/idealization`.
> 
> on a separate note, @JohnTortugo why have you added a dedicated group for these tests?
> 
> -- Igor

Thanks Igor for your input!

> as they aren't tests for `ir_framework`

Right. This might be misleading. 

>  so I'd suggest test/hotspot/jtreg/compiler/c2/ir_transformations, or test/hotspot/jtreg/compiler/c2/idealization.

Could we also choose `test/hotspot/jtreg/compiler/c2/ir_tests` (should we use camel case or underscore?) as top folder for any kinds of IR tests? Then we could still add a subfolder like `ideal_transformations` to it (`test/hotspot/jtreg/compiler/c2/ir_tests/ideal_transformations`). If there are other IR tests later, for example for string opts, we can add a `stringopts` subfolder into the `ir_tests` top folder and so on.

-------------

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

From iignatyev at openjdk.java.net  Tue Aug 17 16:02:25 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 17 Aug 2021 16:02:25 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 IGV transformations
In-Reply-To: <BKEtTh_TfaN9GtjQJeDpjEy-icmG6F1XTwuRtaMndqo=.46ed7685-23bf-4774-b337-c77c101d4585@github.com>
References: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
 <q4yXuw6KCd6stuAmLaNdI891rKOeN08TjMrXeXkiBkw=.aec2b77b-e487-4cd4-88e0-7b01ecc18eaf@github.com>
 <XgfE5LZPC81gHqf2GuBZ59PylILUaDNS68H2Jl52TvQ=.efdbc2a5-9bc0-4044-9f3e-408cbf8cc64e@github.com>
 <BKEtTh_TfaN9GtjQJeDpjEy-icmG6F1XTwuRtaMndqo=.46ed7685-23bf-4774-b337-c77c101d4585@github.com>
Message-ID: <USUsq40B5NKY9bMPl2YNHhhOUItCkXx_vvU0v_bU1R0=.549e9028-60a4-4345-8964-95f65df317d0@github.com>

On Tue, 17 Aug 2021 15:52:50 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> as these tests are c2 tests, they are to be inside `test/hotspot/jtreg/compiler/c2`. I don't think `ir_framework` is a good directory name, as they aren't tests for `ir_framework`, nor `ir_framework` itself,  so I'd suggest `test/hotspot/jtreg/compiler/c2/ir_transformations`, or `test/hotspot/jtreg/compiler/c2/idealization`.
>> 
>> on a separate note, @JohnTortugo why have you added a dedicated group for these tests?
>> 
>> -- Igor
>
> Thanks Igor for your input!
> 
>> as they aren't tests for `ir_framework`
> 
> Right. This might be misleading. 
> 
>>  so I'd suggest test/hotspot/jtreg/compiler/c2/ir_transformations, or test/hotspot/jtreg/compiler/c2/idealization.
> 
> Could we also choose `test/hotspot/jtreg/compiler/c2/ir_tests` (should we use camel case or underscore?) as top folder for any kinds of IR tests? Then we could still add a subfolder like `ideal_transformations` to it (`test/hotspot/jtreg/compiler/c2/ir_tests/ideal_transformations`). If there are other IR tests later, for example for string opts, we can add a `stringopts` subfolder into the `ir_tests` top folder and so on.

> Could we also choose `test/hotspot/jtreg/compiler/c2/ir_tests` as top folder for any kinds of IR tests? 

sounds good to me. 

> should we use camel case or underscore?

given it's java code, and the directory names are part of a package name, we should use lowerCamelCase.

-------------

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

From kvn at openjdk.java.net  Tue Aug 17 16:27:26 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 17 Aug 2021 16:27:26 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 IGV transformations
In-Reply-To: <USUsq40B5NKY9bMPl2YNHhhOUItCkXx_vvU0v_bU1R0=.549e9028-60a4-4345-8964-95f65df317d0@github.com>
References: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
 <q4yXuw6KCd6stuAmLaNdI891rKOeN08TjMrXeXkiBkw=.aec2b77b-e487-4cd4-88e0-7b01ecc18eaf@github.com>
 <XgfE5LZPC81gHqf2GuBZ59PylILUaDNS68H2Jl52TvQ=.efdbc2a5-9bc0-4044-9f3e-408cbf8cc64e@github.com>
 <BKEtTh_TfaN9GtjQJeDpjEy-icmG6F1XTwuRtaMndqo=.46ed7685-23bf-4774-b337-c77c101d4585@github.com>
 <USUsq40B5NKY9bMPl2YNHhhOUItCkXx_vvU0v_bU1R0=.549e9028-60a4-4345-8964-95f65df317d0@github.com>
Message-ID: <2uRU0b0fCTLTdN6jsB9mNpM_3BEgFZz7q4xHWnNG79I=.16186f49-c220-4bf7-aee1-c18f820e92a5@github.com>

On Tue, 17 Aug 2021 15:59:05 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Thanks Igor for your input!
>> 
>>> as they aren't tests for `ir_framework`
>> 
>> Right. This might be misleading. 
>> 
>>>  so I'd suggest test/hotspot/jtreg/compiler/c2/ir_transformations, or test/hotspot/jtreg/compiler/c2/idealization.
>> 
>> Could we also choose `test/hotspot/jtreg/compiler/c2/ir_tests` (should we use camel case or underscore?) as top folder for any kinds of IR tests? Then we could still add a subfolder like `ideal_transformations` to it (`test/hotspot/jtreg/compiler/c2/ir_tests/ideal_transformations`). If there are other IR tests later, for example for string opts, we can add a `stringopts` subfolder into the `ir_tests` top folder and so on.
>
>> Could we also choose `test/hotspot/jtreg/compiler/c2/ir_tests` as top folder for any kinds of IR tests? 
> 
> sounds good to me. 
> 
>> should we use camel case or underscore?
> 
> given it's java code, and the directory names are part of a package name, we should use lowerCamelCase.

I am **against** moving tests under `/c2` directory. This directory was created to split original set of tests to run in parallel and not related to C2 compiler. I want to have directories in `/compiler` per optimization/transformation type as we have now. For example, `/loopopts` is for C2 only but it is not under `/c2`.

Actually I want to clear `c2` and `c1` directories eventually to move tests to corresponding category directories instead.

So I am for `/compiler/irTests`.

-------------

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

From iignatyev at openjdk.java.net  Tue Aug 17 17:02:26 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 17 Aug 2021 17:02:26 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 IGV transformations
In-Reply-To: <2uRU0b0fCTLTdN6jsB9mNpM_3BEgFZz7q4xHWnNG79I=.16186f49-c220-4bf7-aee1-c18f820e92a5@github.com>
References: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
 <q4yXuw6KCd6stuAmLaNdI891rKOeN08TjMrXeXkiBkw=.aec2b77b-e487-4cd4-88e0-7b01ecc18eaf@github.com>
 <XgfE5LZPC81gHqf2GuBZ59PylILUaDNS68H2Jl52TvQ=.efdbc2a5-9bc0-4044-9f3e-408cbf8cc64e@github.com>
 <BKEtTh_TfaN9GtjQJeDpjEy-icmG6F1XTwuRtaMndqo=.46ed7685-23bf-4774-b337-c77c101d4585@github.com>
 <USUsq40B5NKY9bMPl2YNHhhOUItCkXx_vvU0v_bU1R0=.549e9028-60a4-4345-8964-95f65df317d0@github.com>
 <2uRU0b0fCTLTdN6jsB9mNpM_3BEgFZz7q4xHWnNG79I=.16186f49-c220-4bf7-aee1-c18f820e92a5@github.com>
Message-ID: <cpQ56g49aFl4tHUaFXgyObZewh1djLYR8r5QRgBWyLU=.e09e10fc-533c-4f2a-9bf3-6570b09508fd@github.com>

On Tue, 17 Aug 2021 16:24:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> This directory was created to split original set of tests to run in parallel and not related to C2 compiler

aren't you mixing this up w/ `tier1_compiler_[1-3]` test group? if you aren't, this was the wrong way to split tests and we need to fix that.

>  I want to have directories in `/compiler` per `optimization/transformation` type as we have now. For example, `/loopopts` is for C2 only but it is not under `/c2`.
> Actually I want to clear `c2` and `c1` directories eventually to move tests to corresponding category directories instead.

I would prefer to clear `/compiler` directory and move c1-specific tests into `/compiler/c1` directory and c2-specific tests into `/compiler/c2` with optimization/transformation type being subdirectories inside `/compiler/c[12]` (and shared/common tests moved to `/compiler/shared`), so `loopopts` tests are to moved to `/compiler/c2/loopopts`. one of the reasons, most of optimizations tests will be compiler-specific and having them together in `/compiler` doesn't make much sense and just makes it harder to navigate/use test base. e.g. if we have all c2 tests in `/compiler/c2`, one can easily run them together to test c2 changes, if c2-specific tests are in several directories in `/compiler`, so one will have to have intrinsic knowledge about all tests in `/compiler` to select the right one.

-------------

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

From eastig at amazon.co.uk  Tue Aug 17 17:13:13 2021
From: eastig at amazon.co.uk (Astigeevich, Evgeny)
Date: Tue, 17 Aug 2021 17:13:13 +0000
Subject: [UNVERIFIED SENDER] Re: RFC: AArch64: Implementing spin pauses
 with ISB
In-Reply-To: <052f9107-f4d7-9d90-bb49-9d1d43e5bdba@littlepinkcloud.com>
References: <3FA517F5-3339-4C99-B9B3-15D733033D39@amazon.com>
 <7b844fb8-4819-5f83-382c-f621a2794bd8@arm.com>
 <052f9107-f4d7-9d90-bb49-9d1d43e5bdba@littlepinkcloud.com>
Message-ID: <15247F2B-9CEA-441F-95C9-BDD2E0DD7F32@amazon.com>

Hi Andrew,

> I guess that any instruction which caused a significant stall would reduce contention,
> but it'd take some experiments to confirm that.

There are not many candidates for this: x-form of DIV up to 20 clocks, FSQRT up to 17 clocks. A sequence of them might work. ISB replaces such a sequence.
ISB has a nice feature of flushing the pipeline which in theory means a delay without using ALU.

> Evgeny, did anyone try waiting on the monitor location with a WFE?

I am not aware of anyone tried WFE. IMHO WFE might be too complicated. It needs wakeup events.
Armv8.7-A has WFE/WFI with timeouts. See https://static.linaro.org/connect/lvc20/presentations/LVC20-214-0.pdf  slide 10. They might be worth to try when WFET/WFIT appear in hardware.

Thanks,
Evgeny

?On 17/08/2021, 09:25, "hotspot-dev on behalf of Andrew Haley" <hotspot-dev-retn at openjdk.java.net on behalf of aph-open at littlepinkcloud.com> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



    On 8/16/21 11:39 PM, Stuart Monteith wrote:

    >       This is interesting, and thank you for bringing it up for discussion here. The ISB instruction wasn't intended to be
    > used for that purpose, so while you can measure a benefit for now, there is no guarantee that it would continue to be
    > beneficial in the future. I hate to suggest adding more flags, but we ought to consider adding one to disable the ISB
    > instruction in the spins. The counter argument is of course that we'd update the implementation as new cores come out.

    Indeed. It all sounds a bit like witchcraft to me. I guess that any instruction
    which caused a significant stall would reduce contention, but it'd take some
    experiments to confirm that.

    Evgeny, did anyone try waiting on the monitor location with a WFE? That'd at
    least be using an instruction as intended, and would certainly reduce contention,
    but WFE might be too drastic for a brief spin lock.

    --
    Andrew Haley  (he/him)
    Java Platform Lead Engineer
    Red Hat UK Ltd. <https://www.redhat.com>
    https://keybase.io/andrewhaley
    EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671




Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.



From 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: <NPi2G0bRVmGneWyQAy8r2kp4zJDWsVw0Y69humawy9M=.1d234686-5053-4727-8b31-48c7796bb635@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
 <NPi2G0bRVmGneWyQAy8r2kp4zJDWsVw0Y69humawy9M=.1d234686-5053-4727-8b31-48c7796bb635@github.com>
Message-ID: <L6DLEN-Wi6AM69qAXtWawEwgjsQsb-hE0XLwaxq10yw=.f397b447-be29-48fd-8c38-b859999fda4c@github.com>

On Tue, 17 Aug 2021 14:58:48 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> 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 eastig at amazon.co.uk  Tue Aug 17 20:42:52 2021
From: eastig at amazon.co.uk (Astigeevich, Evgeny)
Date: Tue, 17 Aug 2021 20:42:52 +0000
Subject: RFC: AArch64: Implementing spin pauses with ISB
Message-ID: <5C928C8E-BCF5-4A22-BFA6-261CBDBA0361@amazon.com>

Hi Stuart,

> The ISB instruction wasn't intended to be used for that purpose...

It might be a time for YIELD to be a real instruction, especially on Neoverse. High thread contention is a typical situation in server workloads.
If it would be great if Neoverse architects consider this.

> Your experiments were with one ISB - did you experiment at all with multiple ISBs? I'm curious as to what the overall effect would be.

Yes, there were experiments with 2 ISBs. With 2 ISBs the performance improvements were less. Graviton 2 performance engineers' explanation of this is that spins should target 15-30ns. One ISB allows to be within these limits. Two and more ISBs get longer spins. It increases chances of an expensive code path and the OS to reschedule threads.

Thanks,
Evgeny


?On 16/08/2021, 23:43, "hotspot-dev on behalf of Stuart Monteith" <hotspot-dev-retn at openjdk.java.net on behalf of stuart.monteith at arm.com> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



    On 10/08/2021 22:52, Astigeevich, Evgeny wrote:
    > Hello everyone.
    >
    > We?d like to discuss a proposal for implementing spin pauses with the ISB instruction:
    >
    > https://bugs.openjdk.java.net/browse/JDK-8186670 ?Implement _onSpinWait() intrinsic for AArch64?
    > https://bugs.openjdk.java.net/browse/JDK-8258604 ?Use 'isb' instruction in SpinPause on linux-aarch64?
    >
    > In 2017, Dmitry Chuyko from BellSoft proposed to implement onSpinWait() on ARM with the help of the YIELD instruction (see JDK-8186670). The contribution was discussed on the mailing list (http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2017-August/004870.html) but never made it into OpenJDK 10 because at that time there were no hardware YIELD implementations and the exact effect was therefore unknown. Dmitry did a nice writeup and produced some benchmark results (http://cr.openjdk.java.net/~dchuyko/8186670/yield/spinwait.html). He was able to test and measure his implementation only on Cavium ThunderX and Raspberry Pi 3, which both implement YIELD as a NOP. Improvements were therefore minimal.
    >
    > As I am aware the YIELD instruction is still implemented as a NOP by most of AArch64 vendors. There were experiments to use a sequence of NOPs to emulate x86 PAUSE.
    > At Amazon experiments with the ISB on Graviton 2 showed it can create a small delay without consuming ALU resources. It is more reliable than NOPs. The experiments resulted in contributions of ISB-based spin pauses to MySQL (https://bugs.mysql.com/bug.php?id=100664) and MongoDb (https://jira.mongodb.org/browse/WT-6872).
    >
    > We have tested the ISB-based spin pauses for JDK11. Internal customer-based benchmarks showed 3% - 7% improvements in latencies and throughput.
    > We also used https://github.com/ben-manes/caffeine/wiki/Benchmarks microbenchmarks and a SynchronousQueue microbenchmark (you can find it in https://bugs.openjdk.java.net/browse/JDK-8267502). Caffeine GetPutBenchmark for LinkedHashMap_Lru, which has synchronized accesses to a cache, got +14% - +29% improvement in throughput. The SynchronousQueue microbenchmark, which uses Thread.onSpinWait, got 2.9x improvement.
    >
    > OpenJDK tip with the ISB-based spin pauses gets similar improvements in Caffeine GetPutBenchmark for LinkedHashMap_Lru. OpenJDK tip java.util.concurrent.SynchronousQueue does not use Thread.onSpinWait. Because of this the SynchronousQueue microbenchmark gets no improvements.
    >
    > We would like to contribute the ISB-based spin pauses implementation to OpenJDK: SpinPause (https://github.com/corretto/corretto-11/commit/dfb4965877a5810011514bd9294175eccd4b6d0d) and intrinsic (https://github.com/corretto/corretto-11/commit/a49a79bb2e7ac4a2265c51c9fb1c3fcf90dc7c9d).
    > If there is an interest in the contribution, the open question is whether it should be enabled for all AArch64 implementations or only for Neoverse N1.
    >
    > Comments welcome!
    >
    > Thanks,
    > Evgeny
    >
    >
    >
    > Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.
    >
    >

    Hello Evgeny,
            This is interesting, and thank you for bringing it up for discussion here. The ISB instruction wasn't intended to be
    used for that purpose, so while you can measure a benefit for now, there is no guarantee that it would continue to be
    beneficial in the future. I hate to suggest adding more flags, but we ought to consider adding one to disable the ISB
    instruction in the spins. The counter argument is of course that we'd update the implementation as new cores come out.

    Your experiments were with one ISB - did you experiment at all with multiple ISBs? I'm curious as to what the overall
    effect would be.

    BR,
            Stuart




Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.



From eastig at amazon.co.uk  Tue Aug 17 21:22:29 2021
From: eastig at amazon.co.uk (Astigeevich, Evgeny)
Date: Tue, 17 Aug 2021 21:22:29 +0000
Subject: RFC: AArch64: Implementing spin pauses with ISB
Message-ID: <5F41B1BB-BDFB-4F2C-A179-9FE413DA2A44@amazon.com>

Hi Andrew,

> I wonder if we could find some kind of pluggable design, perhaps along the lines of -XX:UseOnSpinWait=ISB.

I think it is doable.

Regarding the ISB latency and its impact I ran BellSoft SpinWaitBench JMH benchmark mentioned on http://cr.openjdk.java.net/~dchuyko/8186670/yield/spinwait.html.

The results below are for jdk11. I think it should be similar for jdk tip.

SpinWaitBench.java???2 threads volatile ping-pong similar to Gil?s approach
SpinWaitOpBench.java???calculates cost of Thread.onSpinWait() and infra cost

Base
Benchmark                       		Mode  Cnt    Score   Error   Units
SpinWaitBench.pong             		thrpt  100    8.318 ? 0.451  ops/us
SpinWaitBench.pong:consume     	thrpt  100    4.158 ? 0.225  ops/us
SpinWaitBench.pong:produce     	thrpt  100    4.160 ? 0.225  ops/us
SpinWaitBench.pong:totalSpins  	thrpt  100  440.050 ? 9.325  ops/us
SpinWaitOpBench.empty       		avgt  100  0.631 ? 0.017  ns/op
SpinWaitOpBench.onSpinWait  	avgt  100  0.628 ? 0.016  ns/op

ISB onSpinWait intrinsic
Benchmark                       		Mode  Cnt   Score   Error   Units
SpinWaitBench.pong             		thrpt  100   8.410 ? 0.493  ops/us
SpinWaitBench.pong:consume     	thrpt  100   4.205 ? 0.246  ops/us
SpinWaitBench.pong:produce     	thrpt  100   4.205 ? 0.247  ops/us
SpinWaitBench.pong:totalSpins  	thrpt  100  24.762 ? 0.447  ops/us
SpinWaitOpBench.empty      		avgt  100   0.628 ? 0.016  ns/op
SpinWaitOpBench.onSpinWait  	avgt  100  15.722 ? 0.095  ns/op

Linux perf data showed ISB behaved like a pause.

Base
81,673,217,533      	cycles:u
   100,225,949,148      instructions:u
       225,001,616      	branch-misses:u
    67,790,831,471      	L1-dcache-loads:u
       421,532,038      	L1-dcache-load-misses:u
    33,194,790,430      	L1-icache-loads:u
         3,769,948      	L1-icache-load-misses:u
    78,948,807,553      	dTLB-loads:u
         1,243,372      	dTLB-load-misses:u
    38,397,808,950      	iTLB-loads:u
           526,111      	iTLB-load-misses:u

ISB onSpinWait intrinsic
81,764,424,001      	cycles:u
     8,046,371,250      	instructions:u
         1,645,436      	branch-misses:u
     4,253,977,620      	L1-dcache-loads:u
       271,345,727      	L1-dcache-load-misses:u
     6,853,406,932      	L1-icache-loads:u
         4,068,136      	L1-icache-load-misses:u
     4,968,555,409      	dTLB-loads:u
         1,351,687      	dTLB-load-misses:u
    17,468,421,421      	iTLB-loads:u
           531,842      	iTLB-load-misses:u


Thanks,
Evgeny

?On 17/08/2021, 10:45, "hotspot-dev on behalf of Andrew Haley" <hotspot-dev-retn at openjdk.java.net on behalf of aph-open at littlepinkcloud.com> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



    On 8/17/21 9:23 AM, Andrew Haley wrote:
    > On 8/16/21 11:39 PM, Stuart Monteith wrote:
    >
    >>      This is interesting, and thank you for bringing it up for discussion here. The ISB instruction wasn't intended to be
    >> used for that purpose, so while you can measure a benefit for now, there is no guarantee that it would continue to be
    >> beneficial in the future. I hate to suggest adding more flags, but we ought to consider adding one to disable the ISB
    >> instruction in the spins. The counter argument is of course that we'd update the implementation as new cores come out.
    >
    > Indeed. It all sounds a bit like witchcraft to me. I guess that any instruction
    > which caused a significant stall would reduce contention, but it'd take some
    > experiments to confirm that.

    One other thing: I'm a bit wary of all this, given that Intel had a
    bit of a hiccup with PAUSE. On Skylake, the latency of PAUSE was
    suddenly increased, causing a slowdown in some software:

    ---------------------------------------------------------------------
    8.4.7  Pause Latency in Skylake Microarchitecture

    The PAUSE instruction is typically used with software threads
    executing on two logical processors located in the same processor
    core, waiting for a lock to be released. Such short wait loops tend to
    last between tens and a few hundreds of cycles, so performance-wise it
    is more beneficial to wait while occupying the CPU than yielding to
    the OS. ...

    The latency of PAUSE instruction in prior generation microarchitecture
    is about 10 cycles, whereas on Skylake microarchitecture it has been
    extended to as many as 140 cycles.  The increased latency (allowing
    more effective utilization of competitively-shared microarchitectural
    resources to the logical processor ready to make forward progress) has
    a small positive performance impact of 1-2% on highly threaded
    applications. It is expected to have negligible impact on less
    threaded applications if forward progress is not blocked on executing
    a fixed number of looped PAUSE instructions.  There's also a small
    power benefit in 2-core and 4-core systems.  As the PAUSE latency has
    been increased significantly, workloads that are sensitive to PAUSE
    latency will suffer some performance loss.
    ---------------------------------------------------------------------

    So, what seems to have happened is that new deployments can have a
    preformance reduction of unpredicatble duration, depending on what
    Intel choose do next time.

    Unless we can predict what a YIELD will actually do, it's a bit risky
    to use it in highly-contended applications. I guess ISB is a bit more
    predictable, in that we know what it does in theory, although not in
    detail for each design. I wonder if we could find some kind of
    pluggable design, perhaps along the lines of -XX:UseOnSpinWait=ISB.

    --
    Andrew Haley  (he/him)
    Java Platform Lead Engineer
    Red Hat UK Ltd. <https://www.redhat.com>
    https://keybase.io/andrewhaley
    EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671





Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.



From 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: <L6DLEN-Wi6AM69qAXtWawEwgjsQsb-hE0XLwaxq10yw=.f397b447-be29-48fd-8c38-b859999fda4c@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
 <NPi2G0bRVmGneWyQAy8r2kp4zJDWsVw0Y69humawy9M=.1d234686-5053-4727-8b31-48c7796bb635@github.com>
 <L6DLEN-Wi6AM69qAXtWawEwgjsQsb-hE0XLwaxq10yw=.f397b447-be29-48fd-8c38-b859999fda4c@github.com>
Message-ID: <WUpJx86v6gR5GPPGGaM3lVfu-b5HgyN27pTozir0IEM=.090086ea-d037-47a9-b8d1-f51da1b5d150@github.com>

On Tue, 17 Aug 2021 20:30:04 GMT, Harold Seigel <hseigel at openjdk.org> 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: <egat4OkVTZK7SpgD2-oEYhghFqpdke-nwRJbGP95I00=.87444341-45de-453a-ab8a-713a591a2603@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()

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 <mseledtsov at openjdk.org> 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 <mseledtsov at openjdk.org>
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: <egat4OkVTZK7SpgD2-oEYhghFqpdke-nwRJbGP95I00=.87444341-45de-453a-ab8a-713a591a2603@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
 <egat4OkVTZK7SpgD2-oEYhghFqpdke-nwRJbGP95I00=.87444341-45de-453a-ab8a-713a591a2603@github.com>
Message-ID: <6nxeZAJ9wzVs6WB41Jcfx-4d3iQ24BJ78aPLA6Mmdpc=.e1298d97-a3cd-44b0-a482-3f51c90b3532@github.com>

On Tue, 17 Aug 2021 22:13:54 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> 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 svkamath at openjdk.java.net  Tue Aug 17 23:37:55 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Tue, 17 Aug 2021 23:37:55 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v10]
In-Reply-To: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
Message-ID: <eKaq1bBaVIuMD1VJMpCJWpKOTw7hx2kWDVSyykvCyTE=.ddf0ad8c-df1e-44af-8621-5283ce08d1de@github.com>

> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
> Performance gain of ~1.5x - 2x for message sizes 8k and above.

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

  Moved declaration in vmStructs.cpp to other AESCrypt declarations

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4019/files
  - new: https://git.openjdk.java.net/jdk/pull/4019/files/112e3fce..d8e56447

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=08-09

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

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

From iklam at openjdk.java.net  Wed Aug 18 00:12:54 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 18 Aug 2021 00:12:54 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC [v5]
In-Reply-To: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
Message-ID: <wqNzq04QzDkkpRm1794wOaSMMqCvxTxsER17ypC48xk=.f26776a6-6026-4eac-b999-cf0964b6196e@github.com>

> **Overview:**
> 
> This is the first step for supporting archived heap objects for non-G1 collectors. We are doing it for EpsilonGC first to iron out the API between GC and CDS. Also we can implement most of the common code (such as copying archived objects into heap), without impacting the overall system stability.
> 
> - Only G1 can write archive heap objects into the CDS archive.
> - Archived objects are "mapped" by G1, but the mapping operation is quite complex.
> - All other collectors will "load" the archive objects, which is much simpler to implement. The trade off is a small start-up penalty and no heap sharing.
> 
> Most of the loading code is implemented in heapShared.cpp. The collectors just need to implement the following two `CollectedHeap` APIs in 
> 
> 
>   virtual bool can_load_archived_objects();
>   virtual HeapWord* allocate_loaded_archive_space(size_t size); // typically return a block in old gen
> 
> 
> **Implementation:**
> 
> - Allocate (from the old gen) a buffer that's large enough to contain all the archived heap objects.
> - Inside the CDS archive file, the heap objects are usually divided into 2~4 disjoint regions (there are gaps between them).
> - Copy every region in to the buffer consecutively, without any gaps.
> - Relocate all the oop fields in all the copied objects, taking into account of the gap removal.
> - The archived strings may be relocated by a full GC, but the CDS "shared string table" cannot handle relocation, so we copy the archived strings into the dynamic string table.
> 
> **Benchmarking:** 
> 
> We can see significant start-up improvement because the module graph can be loaded from CDS.
> 
> 
> $ perf stat -r 40 java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx256m -version
> 
> Before:  43.1ms
> After:   30.2ms
> 
> 
> Testing:
> 
> - Some general clean up of the test cases.
> - Added support for `-vmoptions:-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`: we dump the CDS archive with G1 so we have an archived heap, but run with EpsilonGC to test the new loading code.
> - Added a mach5 task to run all CDS tests with the above config. Incompatible test cases are tagged with `@require vm.gc == null`. See changes in CDSOption.java and VMProps.java

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

  @shipilev review - fixed whitespaces

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5074/files
  - new: https://git.openjdk.java.net/jdk/pull/5074/files/71c2aec5..1d309451

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

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

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

From iklam at openjdk.java.net  Wed Aug 18 00:13:00 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 18 Aug 2021 00:13:00 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC [v4]
In-Reply-To: <YaiN2xJvcujdiuJyEztgzrRbXqS146HBUUZEB3I3tRg=.8bce7650-d0e7-4b8f-9519-0c2134b8adc3@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
 <fbr9wMVNs5Iqd_m8tPMu8TgwwQIKq082dhV4233gdMM=.aa94fd84-e527-4192-82be-2042be530f87@github.com>
 <YaiN2xJvcujdiuJyEztgzrRbXqS146HBUUZEB3I3tRg=.8bce7650-d0e7-4b8f-9519-0c2134b8adc3@github.com>
Message-ID: <RJuiqvyX7-AnRlgFrliRtJPkEOZnR5Q3_6IOGmC4ILQ=.acdc52e6-9c4d-400c-8e35-0f8203253362@github.com>

On Mon, 16 Aug 2021 05:27:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - @shipilev review -- add verbose param to allocate_work()
>>  - Merge branch 'master' into 8270489-archived-heap-objects-for-epsilon-gc
>>  - @shipilev comments
>>  - @iignatev comments
>>  - fixed whitespaces
>>  - Add/update test cases
>>  - 8270489: Support archived heap objects in EpsilonGC
>
> src/hotspot/share/gc/epsilon/epsilonHeap.cpp line 268:
> 
>> 266: HeapWord* EpsilonHeap::allocate_loaded_archive_space(size_t size) {
>> 267:   // Cannot use verbose=true because Metaspace is not initialized
>> 268:   return allocate_work(size, /*verbose=*/false);
> 
> Suggestion:
> 
>   return allocate_work(size, /* verbose = */ false);

Fixed. Thanks for the review.

> src/hotspot/share/gc/epsilon/epsilonHeap.hpp line 91:
> 
>> 89: 
>> 90:   // Allocation
>> 91:   HeapWord* allocate_work(size_t size, bool verbose=true);
> 
> Suggestion:
> 
>   HeapWord* allocate_work(size_t size, bool verbose = true);

Fixed.

-------------

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

From kvn at openjdk.java.net  Wed Aug 18 01:19:36 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 18 Aug 2021 01:19:36 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v10]
In-Reply-To: <eKaq1bBaVIuMD1VJMpCJWpKOTw7hx2kWDVSyykvCyTE=.ddf0ad8c-df1e-44af-8621-5283ce08d1de@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <eKaq1bBaVIuMD1VJMpCJWpKOTw7hx2kWDVSyykvCyTE=.ddf0ad8c-df1e-44af-8621-5283ce08d1de@github.com>
Message-ID: <KwQ0lNjlK_fduaGfr3PxZn11fg3do2ps3lOv09ClubU=.7e1ecfde-c667-48d5-b9a7-f80ab65a297c@github.com>

On Tue, 17 Aug 2021 23:37:55 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved declaration in vmStructs.cpp to other AESCrypt declarations

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7712:

> 7710:         StubRoutines::x86::_counter_mask_addr = counter_mask_addr();
> 7711:         StubRoutines::x86::_ghash_poly512_addr = ghash_polynomial512_addr();
> 7712:         StubRoutines::x86::_ghash_long_swap_mask_addr = generate_ghash_long_swap_mask();

`_counter_mask_addr = counter_mask_addr()` and `_ghash_long_swap_mask_addr = generate_ghash_long_swap_mask()` are called by other intrinsics too. Which duplicates code in codeCache.
They should be called only once when they are used. May be `counter_mask_addr()` and `generate_ghash_long_swap_mask()` method should check that addresses already recorded and return it.

-------------

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

From kvn at openjdk.java.net  Wed Aug 18 01:29:33 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 18 Aug 2021 01:29:33 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v10]
In-Reply-To: <eKaq1bBaVIuMD1VJMpCJWpKOTw7hx2kWDVSyykvCyTE=.ddf0ad8c-df1e-44af-8621-5283ce08d1de@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <eKaq1bBaVIuMD1VJMpCJWpKOTw7hx2kWDVSyykvCyTE=.ddf0ad8c-df1e-44af-8621-5283ce08d1de@github.com>
Message-ID: <mrgt1Wkdr9KrOgVE37YRTnorvoDgxJtvL7wE4X4fJcw=.c4fa63b6-c1f5-4dbb-a718-1ff0388e9451@github.com>

On Tue, 17 Aug 2021 23:37:55 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved declaration in vmStructs.cpp to other AESCrypt declarations

For the record, I withdraw my request to put this on hold until [Lazy stub generation](https://bugs.openjdk.java.net/browse/JDK-8231349) is complete.
As discussed offline I agree with pushing this changes first.

Second, when final changes are ready before push, please, ask Oracle engineer to run tier1-3 in our testing infrastructure.

-------------

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

From dholmes at openjdk.java.net  Wed Aug 18 02:16:26 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 18 Aug 2021 02:16:26 GMT
Subject: RFR: 8264707: HotSpot Style Guide should permit use of lambda
In-Reply-To: <ClF_S5jjfQ911hsUdbxKkaXjVyJ1euXgkDT8JB5fkSs=.42f08fe5-abd8-4839-858b-036e3012ba6b@github.com>
References: <ClF_S5jjfQ911hsUdbxKkaXjVyJ1euXgkDT8JB5fkSs=.42f08fe5-abd8-4839-858b-036e3012ba6b@github.com>
Message-ID: <OSK3nNKuYjsfMhseY5E09TWAxmn7HuwDIQpqwhLXlIM=.c2b4a7b6-f11b-4f0a-a057-ee9008f16118@github.com>

On Tue, 17 Aug 2021 13:49:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this proposal to permit the use of lambda expressions in
> HotSpot code, with some restrictions and suggestions for good usage within
> HotSpot code.  Lambda expressions were added in C++11, and provide a more
> expressive syntax for local functions, with a number of use-cases where they
> can improve readability by eliminating a lot of uninteresting boilerplate.
> 
> Some example uses are included, but are not part of the proposed change.
> They will be removed from the PR before it is pushed.  (In particular, the
> ScopeGuard utility uses move semantics, the use of which hasn't been
> approved or even discussed.)  They are given to show some of the benefits
> that might accrue from permitting the use of lambdas. In particular, they
> highlight some of the code reduction that is possible. Some of these code
> changes might be proposed in the future, using the normal PR process.
> 
> This is a modification of the Style Guide, so rough consensus among the
> HotSpot Group members is required to make this change.  Only Group members
> should vote for approval (via the github PR), though reasoned objections or
> comments from anyone will be considered.  A decision on this proposal will
> not be made before Wednesday 1-Sep-2021 at 12h00 UTC.
> 
> Since we're piggybacking on github PRs here, please use the PR review
> process to approve (click on Review Changes > Approve), rather than sending
> a "vote: yes" email reply that would be normal for a CFV.

Marked as reviewed by dholmes (Reviewer).

doc/hotspot-style.md line 721:

> 719: is an alternative to having a function or function object class defined at
> 720: class or namespace scope.  Instead, a function class definition is placed
> 721: directly at the point of use.

Suggested rewording:

> ... namespace scope, instead placing it directly at the point of use.

-------------

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

From sspitsyn at openjdk.java.net  Wed Aug 18 06:54:34 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 18 Aug 2021 06:54:34 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
Message-ID: <MsTynAoBTqtmuCJKHJPQrQ-hyr6mvHzfRkujqMNgjHs=.4bb5ffeb-4958-4018-8e22-ee4733698258@github.com>

On Mon, 19 Jul 2021 09:25:59 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime stub (like arraycopy), a vtable stub, or the prolog of a compiled method,  it wouldn't be able to detect the sender (caller) frame for multiple reasons. This patch fixes these cases through adding CodeBlob-specific frame parser which are in the best position to know how a frame is setup.
>> 
>> The following examples have been profiled with honest-profiler which uses `AsyncGetCallTrace`.
>> 
>> # `Prof1`
>> 
>> public class Prof1 {
>> 
>>     public static void main(String[] args) {
>>         StringBuilder sb = new StringBuilder();
>>         for (int i = 0; i < 1000000; i++) {
>>             sb.append("ab");
>>             sb.delete(0, 1);
>>         }
>>         System.out.println(sb.length());
>>     }
>> }
>> 
>> 
>> - Baseline:
>> 
>> Flat Profile (by method):
>>         (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>>         (t  0.5,s  0.2) Prof1::main
>>         (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>>         (t  0.0,s  0.0) java.lang.String::getBytes
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>>         (t  0.0,s  0.0) java.lang.StringBuilder::delete
>>         (t  0.2,s  0.0) java.lang.StringBuilder::append
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>> 
>> - With `StubRoutinesBlob::FrameParser`:
>> 
>> Flat Profile (by method):
>>         (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>         (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>>         (t 99.8,s  0.2) Prof1::main
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>>         (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>>         (t 98.8,s  0.0) java.lang.StringBuilder::append
>>         (t  0.9,s  0.0) java.lang.StringBuilder::delete
>> 
>> 
>> # `Prof2`
>> 
>> import java.util.function.Supplier;
>> 
>> public class Prof2 {
>> 
>>     public static void main(String[] args) {
>>         var rand = new java.util.Random(0);
>>         Supplier[] suppliers = {
>>                 () -> 0,
>>                 () -> 1,
>>                 () -> 2,
>>                 () -> 3,
>>         };
>> 
>>         long sum = 0;
>>         for (int i = 0; i >= 0; i++) {
>>             sum += (int)suppliers[i % suppliers.length].get();
>>         }
>>     }
>> }
>> 
>> 
>> - Baseline:
>> 
>> Flat Profile (by method):
>>         (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>>         (t 39.2,s 35.2) Prof2::main
>>         (t  1.4,s  1.4) Prof2::lambda$main$3
>>         (t  1.0,s  1.0) Prof2::lambda$main$2
>>         (t  0.9,s  0.9) Prof2::lambda$main$1
>>         (t  0.7,s  0.7) Prof2::lambda$main$0
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) java.lang.Thread::exit
>>         (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>>         (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>>         (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>>         (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
>> 
>> 
>> - With `VtableBlob::FrameParser` and `nmethod::FrameParser`:
>> 
>> Flat Profile (by method):
>>         (t 74.1,s 70.3) Prof2::main
>>         (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>>         (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>>         (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>>         (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>>         (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>>         (t  1.2,s  1.2) Prof2::lambda$main$2
>>         (t  0.9,s  0.9) Prof2::lambda$main$3
>>         (t  0.9,s  0.9) Prof2::lambda$main$1
>>         (t  0.7,s  0.7) Prof2::lambda$main$0
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>
> Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Remove FrameParser and the required allocation
>    
>    The need for the allocation would be it non async-safe. However,
>    AsyncGetCallTrace is async-safe and thus can't allow for allocations.
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix-8178287
>  - Fix comments
>  - Disable checks in FrameParser when known to be safe
>  - Allow AsyncGetCallTrace and JFR to unwind stack from vtable stub
>    
>    The program is the following:
>    
>    ```
>    import java.util.function.Supplier;
>    
>    public class Prof2 {
>    
>        public static void main(String[] args) {
>            var rand = new java.util.Random(0);
>            Supplier[] suppliers = {
>                    () -> 0,
>                    () -> 1,
>                    () -> 2,
>                    () -> 3,
>            };
>    
>            long sum = 0;
>            for (int i = 0; i >= 0; i++) {
>                sum += (int)suppliers[i % suppliers.length].get();
>            }
>        }
>    }
>    ```
>    
>    The results are as follows:
>    
>    - Baseline (from previous commit):
>    
>    Flat Profile (by method):
>                (t 39.3,s 39.3) AGCT::Unknown Java[ERR=-5]
>                (t 40.3,s 36.1) Prof2::main
>                (t  6.4,s  5.3) Prof2$$Lambda$28.0x0000000800081000::get
>                (t  6.1,s  5.1) Prof2$$Lambda$29.0x0000000800081220::get
>                (t  6.0,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>                (t  6.1,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>                (t  1.1,s  1.1) Prof2::lambda$main$2
>                (t  1.1,s  1.1) Prof2::lambda$main$0
>                (t  1.0,s  1.0) Prof2::lambda$main$1
>                (t  0.9,s  0.9) Prof2::lambda$main$3
>                (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>    
>    - With unwind from vtable stub
>    
>    Flat Profile (by method):
>            (t 74.1,s 70.3) Prof2::main
>            (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>            (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>            (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>            (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>            (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>            (t  1.2,s  1.2) Prof2::lambda$main$2
>            (t  0.9,s  0.9) Prof2::lambda$main$3
>            (t  0.9,s  0.9) Prof2::lambda$main$1
>            (t  0.7,s  0.7) Prof2::lambda$main$0
>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>    
>    We attribute the vtable stub to the caller and not the callee, which is
>    already an improvement from the existing case.
>  - Allow AsyncGetCallTrace and JFR to unwind stack from nmethod's prolog
>    
>    When sampling hits the prolog of a method, Hotspot assumes it's unable
>    to parse the frame. This change allows to parse such frame on x86 by
>    specializing which instruction it's hitting in the prolog.
>    
>    The results are as follows:
>    
>    - Baseline:
>    
>    Flat Profile (by method):
>            (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>            (t 39.2,s 35.2) Prof2::main
>            (t  1.4,s  1.4) Prof2::lambda$main$3
>            (t  1.0,s  1.0) Prof2::lambda$main$2
>            (t  0.9,s  0.9) Prof2::lambda$main$1
>            (t  0.7,s  0.7) Prof2::lambda$main$0
>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>            (t  0.0,s  0.0) java.lang.Thread::exit
>            (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>            (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>            (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>            (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
>    
>    - With incomplete frame parsing:
>    
>    Flat Profile (by method):
>            (t 39.3,s 39.3) AGCT::Unknown Java[ERR=-5]
>            (t 40.3,s 36.1) Prof2::main
>            (t  6.4,s  5.3) Prof2$$Lambda$28.0x0000000800081000::get
>            (t  6.1,s  5.1) Prof2$$Lambda$29.0x0000000800081220::get
>            (t  6.0,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>            (t  6.1,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>            (t  1.1,s  1.1) Prof2::lambda$main$2
>            (t  1.1,s  1.1) Prof2::lambda$main$0
>            (t  1.0,s  1.0) Prof2::lambda$main$1
>            (t  0.9,s  0.9) Prof2::lambda$main$3
>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>            (t  0.0,s  0.0) java.util.Locale::getInstance
>            (t  0.0,s  0.0) AGCT::Not walkable Java[ERR=-6]
>            (t  0.0,s  0.0) jdk.internal.loader.BuiltinClassLoader::loadClassOrNull
>            (t  0.0,s  0.0) java.lang.ClassLoader::loadClass
>            (t  0.0,s  0.0) sun.net.util.URLUtil::urlNoFragString
>            (t  0.0,s  0.0) java.lang.Class::forName0
>            (t  0.0,s  0.0) java.util.Locale::initDefault
>            (t  0.0,s  0.0) jdk.internal.loader.BuiltinClassLoader::loadClass
>            (t  0.0,s  0.0) jdk.internal.loader.URLClassPath::getLoader
>            (t  0.0,s  0.0) jdk.internal.loader.URLClassPath::getResource
>            (t  0.0,s  0.0) java.lang.String::toLowerCase
>            (t  0.0,s  0.0) sun.launcher.LauncherHelper::loadMainClass
>            (t  0.0,s  0.0) sun.launcher.LauncherHelper::checkAndLoadMain
>            (t  0.0,s  0.0) java.util.Locale::<clinit>
>            (t  0.0,s  0.0) jdk.internal.loader.BuiltinClassLoader::findClassOnClassPathOrNull
>            (t  0.0,s  0.0) jdk.internal.loader.ClassLoaders$AppClassLoader::loadClass
>            (t  0.0,s  0.0) java.lang.Class::forName
>    
>    The program is as follows:
>    
>    ```
>    import java.util.function.Supplier;
>    
>    public class Prof2 {
>    
>        public static void main(String[] args) {
>            var rand = new java.util.Random(0);
>            Supplier[] suppliers = {
>                    () -> 0,
>                    () -> 1,
>                    () -> 2,
>                    () -> 3,
>            };
>    
>            long sum = 0;
>            for (int i = 0; i >= 0; i++) {
>                sum += (int)suppliers[i % suppliers.length].get();
>            }
>        }
>    }
>    ```
>    
>    We see that the results are particularely useful in this case as the
>    methods are very short (it only returns an integer), and the probability
>    of hitting the prolog is then very high.
>  - Allow AsyncGetCallTrace and JFR to walk a stub frame
>    
>    When the signal sent for AsyncGetCallTrace or JFR would land on a stub
>    (like arraycopy), it wouldn't be able to detect the sender (caller)
>    frame because `_cb->frame_size() == 0`.
>    
>    Because we fully control how the prolog and epilog of stub code is
>    generated, we know there are two cases:
>    1. A stack frame is allocated via macroAssembler->enter(), and consists
>    in `push rbp; mov rsp, rbp;`.
>    2. No stack frames are allocated and rbp is left unchanged and rsp is
>    decremented with the `call` instruction that push the return `pc` on the
>    stack.
>    
>    For case 1., we can easily know the sender frame by simply looking at
>    rbp, especially since we know that all stubs preserve the frame pointer
>    (on x86 at least).
>    
>    For case 2., we end up returning the sender's sender, but that already
>    gives us more information than what we have today.
>    
>    The results are as follows:
>    
>    - Baseline:
>    
>    Flat Profile (by method):
>            (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>            (t  0.5,s  0.2) Prof1::main
>            (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>            (t  0.0,s  0.0) java.lang.String::getBytes
>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>            (t  0.0,s  0.0) java.lang.StringBuilder::delete
>            (t  0.2,s  0.0) java.lang.StringBuilder::append
>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>    
>    - With StubRoutinesBlob::FrameParser
>    
>    Flat Profile (by method):
>            (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
>            (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>            (t 99.8,s  0.2) Prof1::main
>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>            (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>            (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>            (t 98.8,s  0.0) java.lang.StringBuilder::append
>            (t  0.9,s  0.0) java.lang.StringBuilder::delete
>    
>    The program is as follows:
>    
>    ```
>    public class Prof1 {
>    
>        public static void main(String[] args) {
>            StringBuilder sb = new StringBuilder();
>            for (int i = 0; i < 1000000; i++) {
>                sb.append("ab");
>                sb.delete(0, 1);
>            }
>            System.out.println(sb.length());
>        }
>    }
>    ```
>    
>    We now account for the arraycopy stub which is called by
>    AbstractStringBuilder::ensureCapacityInternal. It was previously ignored
>    because it would not know how to parse the frame for the arraycopy stub
>    and would fall in the AGCT::Unknown Java[ERR=-5] section.
>    
>    However, it still isn't perfect since it doesn't point to the arraycopy stub
>    directly.
>  - Extract sender frame parsing to CodeBlock::FrameParser
>    
>    Whether and how a frame is setup is controlled by the code generator
>    for the specific CodeBlock. The CodeBlock is then in the best place to know how
>    to parse the sender's frame from the current frame in the given CodeBlock.
>    
>    This refactoring proposes to extract this parsing out of `frame` and into a
>    `CodeBlock::FrameParser`. This FrameParser is then specialized in the relevant
>    inherited children of CodeBlock.
>    
>    This change is to largely facilitate adding new supported cases for JDK-8252417
>    like runtime stubs.

Hi Markus! I have a lack of expertize in this area and can't be the primary reviewer.
The problem is we have no test coverage to verify fixes.

-------------

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

From aph-open at littlepinkcloud.com  Wed Aug 18 09:18:27 2021
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Wed, 18 Aug 2021 10:18:27 +0100
Subject: RFC: AArch64: Implementing spin pauses with ISB
In-Reply-To: <15247F2B-9CEA-441F-95C9-BDD2E0DD7F32@amazon.com>
References: <3FA517F5-3339-4C99-B9B3-15D733033D39@amazon.com>
 <7b844fb8-4819-5f83-382c-f621a2794bd8@arm.com>
 <052f9107-f4d7-9d90-bb49-9d1d43e5bdba@littlepinkcloud.com>
 <15247F2B-9CEA-441F-95C9-BDD2E0DD7F32@amazon.com>
Message-ID: <41350d03-1b8c-8558-5391-dfd1a918e7d5@littlepinkcloud.com>

On 8/17/21 6:13 PM, Astigeevich, Evgeny wrote:
> I am not aware of anyone tried WFE. IMHO WFE might be too complicated. It needs wakeup events.
> Armv8.7-A has WFE/WFI with timeouts. See https://static.linaro.org/connect/lvc20/presentations/LVC20-214-0.pdf  slide 10. They might be worth to try when WFET/WFIT appear in hardware.

AFAIK it needs no more than a write to the location being monitored.

"The following are WFE wake-up events:

   ... An event caused by the clearing of the global monitor for the PE."

That looks like exactly the right thing, assuming that the wait state doesn't
take too long to enter and exit. We'd have to wait on whatever location the
code was spinning on. Any write to that location by any PE would clear the
global monitor, I think.

Anyway, OK, we could do this, if we at least had the opportunity to switch
to PAUSE with an command-line option. And be aware that at any time any
manufacturer could mess this up, so it's dangerous to have it on by default.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph-open at littlepinkcloud.com  Wed Aug 18 09:21:28 2021
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Wed, 18 Aug 2021 10:21:28 +0100
Subject: RFC: AArch64: Implementing spin pauses with ISB
In-Reply-To: <41350d03-1b8c-8558-5391-dfd1a918e7d5@littlepinkcloud.com>
References: <3FA517F5-3339-4C99-B9B3-15D733033D39@amazon.com>
 <7b844fb8-4819-5f83-382c-f621a2794bd8@arm.com>
 <052f9107-f4d7-9d90-bb49-9d1d43e5bdba@littlepinkcloud.com>
 <15247F2B-9CEA-441F-95C9-BDD2E0DD7F32@amazon.com>
 <41350d03-1b8c-8558-5391-dfd1a918e7d5@littlepinkcloud.com>
Message-ID: <f64009de-9d60-12e2-1156-b6d217d81448@littlepinkcloud.com>

On 8/18/21 10:18 AM, Andrew Haley wrote:
> Anyway, OK, we could do this, if we at least had the opportunity to switch
> to PAUSE with an command-line option. And be aware that at any time any
> manufacturer could mess this up, so it's dangerous to have it on by default.

Sorry, that's ambiguous.

I mean, it's fine to support spin pauses with USB, but please support PAUSE
as well, and I'm not keen on having it on by default. Maybe on Neoverse N1
we could do that, but it might make things worse in some cases; and how would
we know?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From kbarrett at openjdk.java.net  Wed Aug 18 11:30:28 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 18 Aug 2021 11:30:28 GMT
Subject: RFR: 8264707: HotSpot Style Guide should permit use of lambda
In-Reply-To: <OSK3nNKuYjsfMhseY5E09TWAxmn7HuwDIQpqwhLXlIM=.c2b4a7b6-f11b-4f0a-a057-ee9008f16118@github.com>
References: <ClF_S5jjfQ911hsUdbxKkaXjVyJ1euXgkDT8JB5fkSs=.42f08fe5-abd8-4839-858b-036e3012ba6b@github.com>
 <OSK3nNKuYjsfMhseY5E09TWAxmn7HuwDIQpqwhLXlIM=.c2b4a7b6-f11b-4f0a-a057-ee9008f16118@github.com>
Message-ID: <9VuNIpQL04HwYIa2b4TTpgr5IPdcthN2m0afysCfei4=.7fb1c71f-ac68-4eca-959e-873184ea8a66@github.com>

On Wed, 18 Aug 2021 02:09:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this proposal to permit the use of lambda expressions in
>> HotSpot code, with some restrictions and suggestions for good usage within
>> HotSpot code.  Lambda expressions were added in C++11, and provide a more
>> expressive syntax for local functions, with a number of use-cases where they
>> can improve readability by eliminating a lot of uninteresting boilerplate.
>> 
>> Some example uses are included, but are not part of the proposed change.
>> They will be removed from the PR before it is pushed.  (In particular, the
>> ScopeGuard utility uses move semantics, the use of which hasn't been
>> approved or even discussed.)  They are given to show some of the benefits
>> that might accrue from permitting the use of lambdas. In particular, they
>> highlight some of the code reduction that is possible. Some of these code
>> changes might be proposed in the future, using the normal PR process.
>> 
>> This is a modification of the Style Guide, so rough consensus among the
>> HotSpot Group members is required to make this change.  Only Group members
>> should vote for approval (via the github PR), though reasoned objections or
>> comments from anyone will be considered.  A decision on this proposal will
>> not be made before Wednesday 1-Sep-2021 at 12h00 UTC.
>> 
>> Since we're piggybacking on github PRs here, please use the PR review
>> process to approve (click on Review Changes > Approve), rather than sending
>> a "vote: yes" email reply that would be normal for a CFV.
>
> doc/hotspot-style.md line 721:
> 
>> 719: is an alternative to having a function or function object class defined at
>> 720: class or namespace scope.  Instead, a function class definition is placed
>> 721: directly at the point of use.
> 
> Suggested rewording:
> 
>> ... namespace scope, instead placing it directly at the point of use.

The wording was intentional; "it" would refer to "a function or function object class", but a *function* can't be locally defined.  But it should be consistent about "function object class" vs "function class".  The former is the terminology used by the Standard.

-------------

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

From fmatte at openjdk.java.net  Wed Aug 18 12:45:41 2021
From: fmatte at openjdk.java.net (Fairoz Matte)
Date: Wed, 18 Aug 2021 12:45:41 GMT
Subject: RFR: 8272563: Possible assertion failure in CardTableBarrierSetC1
Message-ID: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>

This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp

The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
> __ move(addr, tmp);
However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
The fix is to check if it is is_oop() and call the mov appropriately.

No issues found in local testing and Mach5 tier1-3

-------------

Commit messages:
 - 8272563: Possible assertion failure in CardTableBarrierSetC1

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

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

From rkennke at openjdk.java.net  Wed Aug 18 18:25:28 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 18 Aug 2021 18:25:28 GMT
Subject: RFR: 8266519: Cleanup resolve() leftovers from BarrierSet et al
In-Reply-To: <JSk0y-ZZLSvWGEjxfyhkgoKp330enVAJ4e3RUKHtiEA=.bb50eb5a-b94e-44c9-bec0-c3f06e0a4f22@github.com>
References: <JSk0y-ZZLSvWGEjxfyhkgoKp330enVAJ4e3RUKHtiEA=.bb50eb5a-b94e-44c9-bec0-c3f06e0a4f22@github.com>
Message-ID: <ehPGpHuV4kzePJsnVl1WTL2owch305X7mTajypjtEJY=.9d240fc5-7e14-49e3-b8fe-425476de781e@github.com>

On Tue, 4 May 2021 16:38:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Shenandoah used to require a way to resolve oops, but it's long unused the the corresponding code in the access machinery is obsolete. Let's remove it.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1
>  - [x] tier2

Ping? Any takers?

-------------

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

From rkennke at openjdk.java.net  Wed Aug 18 18:42:38 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 18 Aug 2021 18:42:38 GMT
Subject: RFR: 8270041: Consolidate oopDesc::cas_forward_to() and
 oopDesc::forward_to_atomic()
Message-ID: <3xGT20phR8n05MxmosIRONZDUtn8T2WTL4uz5MO7FqE=.13e2c107-34ec-4f1d-ba51-f4d21021cea9@github.com>

The two methods do exactly the same, except one returns a bool, the other a value. The only use of cas_forward_to() can be consolidated to use forward_to_atomic() instead.

Testing:
 - [ ] hotspot_gc
 - [ ] tier1
 - [ ] tier2

-------------

Commit messages:
 - 8270041: Consolidate oopDesc::cas_forward_to() and oopDesc::forward_to_atomic()

Changes: https://git.openjdk.java.net/jdk/pull/5167/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5167&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270041
  Stats: 10 lines in 3 files changed: 0 ins; 9 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5167/head:pull/5167

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

From rkennke at openjdk.java.net  Wed Aug 18 18:58:26 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 18 Aug 2021 18:58:26 GMT
Subject: RFR: 8270554: Shenandoah: Optimize heap scan loop
In-Reply-To: <eADDeXXW0aSHzwkJ4PaUKFDSZTBOlI33lEYI2gfl1RQ=.d288baea-4f1a-4c7b-862e-0b2904be1df7@github.com>
References: <eADDeXXW0aSHzwkJ4PaUKFDSZTBOlI33lEYI2gfl1RQ=.d288baea-4f1a-4c7b-862e-0b2904be1df7@github.com>
Message-ID: <CDkToQsNfh8BeZ54eAijnjvwdG001NE6xg0nuPQzBrA=.8d675e8b-7b73-4ba4-87cc-f96615689aa2@github.com>

On Thu, 15 Jul 2021 14:37:26 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This is a fall-out from Lilliput. I noticed that in the heap scan loop, we load the size of objects in the size-based object scanner, even though all of the object closures already load the size, or at least in some cases, the Klass* which is necessary to determine the size. We can optimize that by making the scan loop co-operate with the closures. In other words, this changes the loop to avoid double-loading the Klass* in most cases in the size-based part of the scan loop.
> 
> Note: the motivation in Lilliput is not performance, but correctness, because there loading the Klass* means loading the header, and this needs to be done carefully because of concurrent evacuation and concurrent locking code both messing with the header, and thus depends a lot on the actual closures to do it correctly. 
> 
> Implementation notes:
> - SH::evacuate_object() has been changed so that it can return both the forwardee and the size. I opted to return the size as return-value because otherwise I'd have to null check an incoming pointer in the cases when we're not interested in the size. The way it is done, it can simply be ignored (and optimized-out) by the compiler.
> - I added a do_object_size() variant to all affected iterators. I tried to do it with templates, but could not figure out how to please the compiler.
> - While I was at it, I marked all do_object() methods as 'inline'.
> - I ran some benchmarks. I think I see consistent but small improvements in evac and update-refs times, but it's not large enough to say that it is a definite improvement.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1 (+UseShenandoahGC)
>  - [x] specjvm testing

Ping? Any opinions?

-------------

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

From hirt at openjdk.java.net  Wed Aug 18 19:19:33 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 18 Aug 2021 19:19:33 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
Message-ID: <DGifHTg7nIn5v9jLtDHTWvj1SxNfv3DxVz5Y4FaRCxY=.7f279e15-526c-469b-8872-4504fde721bd@github.com>

On Mon, 19 Jul 2021 09:25:59 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime stub (like arraycopy), a vtable stub, or the prolog of a compiled method,  it wouldn't be able to detect the sender (caller) frame for multiple reasons. This patch fixes these cases through adding CodeBlob-specific frame parser which are in the best position to know how a frame is setup.
>> 
>> The following examples have been profiled with honest-profiler which uses `AsyncGetCallTrace`.
>> 
>> # `Prof1`
>> 
>> public class Prof1 {
>> 
>>     public static void main(String[] args) {
>>         StringBuilder sb = new StringBuilder();
>>         for (int i = 0; i < 1000000; i++) {
>>             sb.append("ab");
>>             sb.delete(0, 1);
>>         }
>>         System.out.println(sb.length());
>>     }
>> }
>> 
>> 
>> - Baseline:
>> 
>> Flat Profile (by method):
>>         (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>>         (t  0.5,s  0.2) Prof1::main
>>         (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>>         (t  0.0,s  0.0) java.lang.String::getBytes
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>>         (t  0.0,s  0.0) java.lang.StringBuilder::delete
>>         (t  0.2,s  0.0) java.lang.StringBuilder::append
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>> 
>> - With `StubRoutinesBlob::FrameParser`:
>> 
>> Flat Profile (by method):
>>         (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>         (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>>         (t 99.8,s  0.2) Prof1::main
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>>         (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>>         (t 98.8,s  0.0) java.lang.StringBuilder::append
>>         (t  0.9,s  0.0) java.lang.StringBuilder::delete
>> 
>> 
>> # `Prof2`
>> 
>> import java.util.function.Supplier;
>> 
>> public class Prof2 {
>> 
>>     public static void main(String[] args) {
>>         var rand = new java.util.Random(0);
>>         Supplier[] suppliers = {
>>                 () -> 0,
>>                 () -> 1,
>>                 () -> 2,
>>                 () -> 3,
>>         };
>> 
>>         long sum = 0;
>>         for (int i = 0; i >= 0; i++) {
>>             sum += (int)suppliers[i % suppliers.length].get();
>>         }
>>     }
>> }
>> 
>> 
>> - Baseline:
>> 
>> Flat Profile (by method):
>>         (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>>         (t 39.2,s 35.2) Prof2::main
>>         (t  1.4,s  1.4) Prof2::lambda$main$3
>>         (t  1.0,s  1.0) Prof2::lambda$main$2
>>         (t  0.9,s  0.9) Prof2::lambda$main$1
>>         (t  0.7,s  0.7) Prof2::lambda$main$0
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) java.lang.Thread::exit
>>         (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>>         (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>>         (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>>         (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
>> 
>> 
>> - With `VtableBlob::FrameParser` and `nmethod::FrameParser`:
>> 
>> Flat Profile (by method):
>>         (t 74.1,s 70.3) Prof2::main
>>         (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>>         (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>>         (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>>         (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>>         (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>>         (t  1.2,s  1.2) Prof2::lambda$main$2
>>         (t  0.9,s  0.9) Prof2::lambda$main$3
>>         (t  0.9,s  0.9) Prof2::lambda$main$1
>>         (t  0.7,s  0.7) Prof2::lambda$main$0
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>
> Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Remove FrameParser and the required allocation
>    
>    The need for the allocation would be it non async-safe. However,
>    AsyncGetCallTrace is async-safe and thus can't allow for allocations.
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix-8178287
>  - Fix comments
>  - Disable checks in FrameParser when known to be safe
>  - Allow AsyncGetCallTrace and JFR to unwind stack from vtable stub
>    
>    The program is the following:
>    
>    ```
>    import java.util.function.Supplier;
>    
>    public class Prof2 {
>    
>        public static void main(String[] args) {
>            var rand = new java.util.Random(0);
>            Supplier[] suppliers = {
>                    () -> 0,
>                    () -> 1,
>                    () -> 2,
>                    () -> 3,
>            };
>    
>            long sum = 0;
>            for (int i = 0; i >= 0; i++) {
>                sum += (int)suppliers[i % suppliers.length].get();
>            }
>        }
>    }
>    ```
>    
>    The results are as follows:
>    
>    - Baseline (from previous commit):
>    
>    Flat Profile (by method):
>                (t 39.3,s 39.3) AGCT::Unknown Java[ERR=-5]
>                (t 40.3,s 36.1) Prof2::main
>                (t  6.4,s  5.3) Prof2$$Lambda$28.0x0000000800081000::get
>                (t  6.1,s  5.1) Prof2$$Lambda$29.0x0000000800081220::get
>                (t  6.0,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>                (t  6.1,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>                (t  1.1,s  1.1) Prof2::lambda$main$2
>                (t  1.1,s  1.1) Prof2::lambda$main$0
>                (t  1.0,s  1.0) Prof2::lambda$main$1
>                (t  0.9,s  0.9) Prof2::lambda$main$3
>                (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>    
>    - With unwind from vtable stub
>    
>    Flat Profile (by method):
>            (t 74.1,s 70.3) Prof2::main
>            (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>            (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>            (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>            (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>            (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>            (t  1.2,s  1.2) Prof2::lambda$main$2
>            (t  0.9,s  0.9) Prof2::lambda$main$3
>            (t  0.9,s  0.9) Prof2::lambda$main$1
>            (t  0.7,s  0.7) Prof2::lambda$main$0
>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>    
>    We attribute the vtable stub to the caller and not the callee, which is
>    already an improvement from the existing case.
>  - Allow AsyncGetCallTrace and JFR to unwind stack from nmethod's prolog
>    
>    When sampling hits the prolog of a method, Hotspot assumes it's unable
>    to parse the frame. This change allows to parse such frame on x86 by
>    specializing which instruction it's hitting in the prolog.
>    
>    The results are as follows:
>    
>    - Baseline:
>    
>    Flat Profile (by method):
>            (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>            (t 39.2,s 35.2) Prof2::main
>            (t  1.4,s  1.4) Prof2::lambda$main$3
>            (t  1.0,s  1.0) Prof2::lambda$main$2
>            (t  0.9,s  0.9) Prof2::lambda$main$1
>            (t  0.7,s  0.7) Prof2::lambda$main$0
>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>            (t  0.0,s  0.0) java.lang.Thread::exit
>            (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>            (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>            (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>            (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
>    
>    - With incomplete frame parsing:
>    
>    Flat Profile (by method):
>            (t 39.3,s 39.3) AGCT::Unknown Java[ERR=-5]
>            (t 40.3,s 36.1) Prof2::main
>            (t  6.4,s  5.3) Prof2$$Lambda$28.0x0000000800081000::get
>            (t  6.1,s  5.1) Prof2$$Lambda$29.0x0000000800081220::get
>            (t  6.0,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>            (t  6.1,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>            (t  1.1,s  1.1) Prof2::lambda$main$2
>            (t  1.1,s  1.1) Prof2::lambda$main$0
>            (t  1.0,s  1.0) Prof2::lambda$main$1
>            (t  0.9,s  0.9) Prof2::lambda$main$3
>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>            (t  0.0,s  0.0) java.util.Locale::getInstance
>            (t  0.0,s  0.0) AGCT::Not walkable Java[ERR=-6]
>            (t  0.0,s  0.0) jdk.internal.loader.BuiltinClassLoader::loadClassOrNull
>            (t  0.0,s  0.0) java.lang.ClassLoader::loadClass
>            (t  0.0,s  0.0) sun.net.util.URLUtil::urlNoFragString
>            (t  0.0,s  0.0) java.lang.Class::forName0
>            (t  0.0,s  0.0) java.util.Locale::initDefault
>            (t  0.0,s  0.0) jdk.internal.loader.BuiltinClassLoader::loadClass
>            (t  0.0,s  0.0) jdk.internal.loader.URLClassPath::getLoader
>            (t  0.0,s  0.0) jdk.internal.loader.URLClassPath::getResource
>            (t  0.0,s  0.0) java.lang.String::toLowerCase
>            (t  0.0,s  0.0) sun.launcher.LauncherHelper::loadMainClass
>            (t  0.0,s  0.0) sun.launcher.LauncherHelper::checkAndLoadMain
>            (t  0.0,s  0.0) java.util.Locale::<clinit>
>            (t  0.0,s  0.0) jdk.internal.loader.BuiltinClassLoader::findClassOnClassPathOrNull
>            (t  0.0,s  0.0) jdk.internal.loader.ClassLoaders$AppClassLoader::loadClass
>            (t  0.0,s  0.0) java.lang.Class::forName
>    
>    The program is as follows:
>    
>    ```
>    import java.util.function.Supplier;
>    
>    public class Prof2 {
>    
>        public static void main(String[] args) {
>            var rand = new java.util.Random(0);
>            Supplier[] suppliers = {
>                    () -> 0,
>                    () -> 1,
>                    () -> 2,
>                    () -> 3,
>            };
>    
>            long sum = 0;
>            for (int i = 0; i >= 0; i++) {
>                sum += (int)suppliers[i % suppliers.length].get();
>            }
>        }
>    }
>    ```
>    
>    We see that the results are particularely useful in this case as the
>    methods are very short (it only returns an integer), and the probability
>    of hitting the prolog is then very high.
>  - Allow AsyncGetCallTrace and JFR to walk a stub frame
>    
>    When the signal sent for AsyncGetCallTrace or JFR would land on a stub
>    (like arraycopy), it wouldn't be able to detect the sender (caller)
>    frame because `_cb->frame_size() == 0`.
>    
>    Because we fully control how the prolog and epilog of stub code is
>    generated, we know there are two cases:
>    1. A stack frame is allocated via macroAssembler->enter(), and consists
>    in `push rbp; mov rsp, rbp;`.
>    2. No stack frames are allocated and rbp is left unchanged and rsp is
>    decremented with the `call` instruction that push the return `pc` on the
>    stack.
>    
>    For case 1., we can easily know the sender frame by simply looking at
>    rbp, especially since we know that all stubs preserve the frame pointer
>    (on x86 at least).
>    
>    For case 2., we end up returning the sender's sender, but that already
>    gives us more information than what we have today.
>    
>    The results are as follows:
>    
>    - Baseline:
>    
>    Flat Profile (by method):
>            (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>            (t  0.5,s  0.2) Prof1::main
>            (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>            (t  0.0,s  0.0) java.lang.String::getBytes
>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>            (t  0.0,s  0.0) java.lang.StringBuilder::delete
>            (t  0.2,s  0.0) java.lang.StringBuilder::append
>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>    
>    - With StubRoutinesBlob::FrameParser
>    
>    Flat Profile (by method):
>            (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
>            (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>            (t 99.8,s  0.2) Prof1::main
>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>            (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>            (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>            (t 98.8,s  0.0) java.lang.StringBuilder::append
>            (t  0.9,s  0.0) java.lang.StringBuilder::delete
>    
>    The program is as follows:
>    
>    ```
>    public class Prof1 {
>    
>        public static void main(String[] args) {
>            StringBuilder sb = new StringBuilder();
>            for (int i = 0; i < 1000000; i++) {
>                sb.append("ab");
>                sb.delete(0, 1);
>            }
>            System.out.println(sb.length());
>        }
>    }
>    ```
>    
>    We now account for the arraycopy stub which is called by
>    AbstractStringBuilder::ensureCapacityInternal. It was previously ignored
>    because it would not know how to parse the frame for the arraycopy stub
>    and would fall in the AGCT::Unknown Java[ERR=-5] section.
>    
>    However, it still isn't perfect since it doesn't point to the arraycopy stub
>    directly.
>  - Extract sender frame parsing to CodeBlock::FrameParser
>    
>    Whether and how a frame is setup is controlled by the code generator
>    for the specific CodeBlock. The CodeBlock is then in the best place to know how
>    to parse the sender's frame from the current frame in the given CodeBlock.
>    
>    This refactoring proposes to extract this parsing out of `frame` and into a
>    `CodeBlock::FrameParser`. This FrameParser is then specialized in the relevant
>    inherited children of CodeBlock.
>    
>    This change is to largely facilitate adding new supported cases for JDK-8252417
>    like runtime stubs.

Ok. Do you know who should be the primary reviewer? Rickard B?ckman? Nils Eliasson?

-------------

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

From stuart.monteith at arm.com  Wed Aug 18 22:22:32 2021
From: stuart.monteith at arm.com (Stuart Monteith)
Date: Wed, 18 Aug 2021 23:22:32 +0100
Subject: RFC: AArch64: Implementing spin pauses with ISB
In-Reply-To: <15247F2B-9CEA-441F-95C9-BDD2E0DD7F32@amazon.com>
References: <3FA517F5-3339-4C99-B9B3-15D733033D39@amazon.com>
 <7b844fb8-4819-5f83-382c-f621a2794bd8@arm.com>
 <052f9107-f4d7-9d90-bb49-9d1d43e5bdba@littlepinkcloud.com>
 <15247F2B-9CEA-441F-95C9-BDD2E0DD7F32@amazon.com>
Message-ID: <7d08685f-41a4-99e9-a29a-0fea2ed3b62d@arm.com>

Hello,


On 17/08/2021 18:13, Astigeevich, Evgeny wrote:
> Hi Andrew,
> 
>> I guess that any instruction which caused a significant stall would reduce contention,
>> but it'd take some experiments to confirm that.
> 
> There are not many candidates for this: x-form of DIV up to 20 clocks, FSQRT up to 17 clocks. A sequence of them might work. ISB replaces such a sequence.
> ISB has a nice feature of flushing the pipeline which in theory means a delay without using ALU.
> 
>> Evgeny, did anyone try waiting on the monitor location with a WFE?
> 
> I am not aware of anyone tried WFE. IMHO WFE might be too complicated. It needs wakeup events.
> Armv8.7-A has WFE/WFI with timeouts. See https://static.linaro.org/connect/lvc20/presentations/LVC20-214-0.pdf  slide 10. They might be worth to try when WFET/WFIT appear in hardware.
> 
> Thanks,
> Evgeny
> 
> ?On 17/08/2021, 09:25, "hotspot-dev on behalf of Andrew Haley" <hotspot-dev-retn at openjdk.java.net on behalf of aph-open at littlepinkcloud.com> wrote:
> 
>      CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
>      On 8/16/21 11:39 PM, Stuart Monteith wrote:
> 
>      >       This is interesting, and thank you for bringing it up for discussion here. The ISB instruction wasn't intended to be
>      > used for that purpose, so while you can measure a benefit for now, there is no guarantee that it would continue to be
>      > beneficial in the future. I hate to suggest adding more flags, but we ought to consider adding one to disable the ISB
>      > instruction in the spins. The counter argument is of course that we'd update the implementation as new cores come out.
> 
>      Indeed. It all sounds a bit like witchcraft to me. I guess that any instruction
>      which caused a significant stall would reduce contention, but it'd take some
>      experiments to confirm that.
> 
>      Evgeny, did anyone try waiting on the monitor location with a WFE? That'd at
>      least be using an instruction as intended, and would certainly reduce contention,
>      but WFE might be too drastic for a brief spin lock.
> 
>      --
>      Andrew Haley  (he/him)
>      Java Platform Lead Engineer
>      Red Hat UK Ltd. <https://www.redhat.com>
>      https://keybase.io/andrewhaley
>      EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 
> 
> 
> 
> Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.
> 
> 

I don't think WFE will work for you - I found on at least one machine the cpu will pause more or less indefinitely. The 
SEV instruction may be a blunt weapon as it applies to all cores on the CPU.

This discussion appears split between the Spin Pause review and this email thread, but the idea of the implementation 
being switchable is appealing. Hypothetically the options might be NONE, NOP, ISB, YIELD. With the current semantics, 
YIELD could be theoretically useful on SMT cores, but I don't know if that would change in the future to be applicable 
more widely.


BR,
	Stuart

From kbarrett at openjdk.java.net  Thu Aug 19 00:11:25 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 19 Aug 2021 00:11:25 GMT
Subject: RFR: 8266519: Cleanup resolve() leftovers from BarrierSet et al
In-Reply-To: <ehPGpHuV4kzePJsnVl1WTL2owch305X7mTajypjtEJY=.9d240fc5-7e14-49e3-b8fe-425476de781e@github.com>
References: <JSk0y-ZZLSvWGEjxfyhkgoKp330enVAJ4e3RUKHtiEA=.bb50eb5a-b94e-44c9-bec0-c3f06e0a4f22@github.com>
 <ehPGpHuV4kzePJsnVl1WTL2owch305X7mTajypjtEJY=.9d240fc5-7e14-49e3-b8fe-425476de781e@github.com>
Message-ID: <qwPPiyR552DRxyx41d32Xw7zBSxl9Pv-p5uxfj4ohG4=.3df74cc6-1d17-4a20-ae66-76919aaed43e@github.com>

On Wed, 18 Aug 2021 18:22:09 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Ping? Any takers?

The only email for this PR I have any record of is the auto-withdraw at the end of June.  Weird!  I'll have a look.

-------------

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

From kbarrett at openjdk.java.net  Thu Aug 19 00:20:25 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 19 Aug 2021 00:20:25 GMT
Subject: RFR: 8266519: Cleanup resolve() leftovers from BarrierSet et al
In-Reply-To: <JSk0y-ZZLSvWGEjxfyhkgoKp330enVAJ4e3RUKHtiEA=.bb50eb5a-b94e-44c9-bec0-c3f06e0a4f22@github.com>
References: <JSk0y-ZZLSvWGEjxfyhkgoKp330enVAJ4e3RUKHtiEA=.bb50eb5a-b94e-44c9-bec0-c3f06e0a4f22@github.com>
Message-ID: <hK1I7GlBtWRgYrghFT6MSJaBqG0G9j53Z6MQfKGMwDg=.6cde77ae-4e65-4a2c-8ec7-b39d8538c0b5@github.com>

On Tue, 4 May 2021 16:38:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Shenandoah used to require a way to resolve oops, but it's long unused the the corresponding code in the access machinery is obsolete. Let's remove it.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1
>  - [x] tier2

Looks good.

The initial RFR email made it into the hotspot-dev mail.openjdk.java.net archive.  But it doesn't look like it made it to me for some reason.  Was there some kind of email outage around that time?

-------------

Marked as reviewed by kbarrett (Reviewer).

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

From stefank at openjdk.java.net  Thu Aug 19 07:21:23 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 19 Aug 2021 07:21:23 GMT
Subject: RFR: 8270041: Consolidate oopDesc::cas_forward_to() and
 oopDesc::forward_to_atomic()
In-Reply-To: <3xGT20phR8n05MxmosIRONZDUtn8T2WTL4uz5MO7FqE=.13e2c107-34ec-4f1d-ba51-f4d21021cea9@github.com>
References: <3xGT20phR8n05MxmosIRONZDUtn8T2WTL4uz5MO7FqE=.13e2c107-34ec-4f1d-ba51-f4d21021cea9@github.com>
Message-ID: <OwfYIUyvfcWnux6iCIPPI1LxSQG73cfigC2fqYcEP4Q=.687d028b-223d-44a0-b8c0-dd8ec7b2d3e4@github.com>

On Wed, 18 Aug 2021 18:36:11 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> The two methods do exactly the same, except one returns a bool, the other a value. The only use of cas_forward_to() can be consolidated to use forward_to_atomic() instead.
> 
> Testing:
>  - [ ] hotspot_gc
>  - [ ] tier1
>  - [ ] tier2

Marked as reviewed by stefank (Reviewer).

-------------

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

From aph-open at littlepinkcloud.com  Thu Aug 19 07:23:45 2021
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Thu, 19 Aug 2021 08:23:45 +0100
Subject: RFC: AArch64: Implementing spin pauses with ISB
In-Reply-To: <7d08685f-41a4-99e9-a29a-0fea2ed3b62d@arm.com>
References: <3FA517F5-3339-4C99-B9B3-15D733033D39@amazon.com>
 <7b844fb8-4819-5f83-382c-f621a2794bd8@arm.com>
 <052f9107-f4d7-9d90-bb49-9d1d43e5bdba@littlepinkcloud.com>
 <15247F2B-9CEA-441F-95C9-BDD2E0DD7F32@amazon.com>
 <7d08685f-41a4-99e9-a29a-0fea2ed3b62d@arm.com>
Message-ID: <36ceb710-5b40-e118-7617-fddaf6fdefbc@littlepinkcloud.com>

On 8/18/21 11:22 PM, Stuart Monteith wrote:
> I don't think WFE will work for you - I found on at least one machine the cpu will pause more or less indefinitely.

That's a shame. I thought it was specified to awaken when the exclusive monitor
was cleared, which will happen when the exclusive location is written to, won't
it?

> The 
> SEV instruction may be a blunt weapon as it applies to all cores on the CPU.
> 
> This discussion appears split between the Spin Pause review and this email thread, but the idea of the implementation 
> being switchable is appealing. Hypothetically the options might be NONE, NOP, ISB, YIELD. With the current semantics, 
> YIELD could be theoretically useful on SMT cores, but I don't know if that would change in the future to be applicable 
> more widely.

Mmm, yes. I think it should be easy enough to make it switchable. I'd
support that, I think.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From stefank at openjdk.java.net  Thu Aug 19 07:43:24 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 19 Aug 2021 07:43:24 GMT
Subject: RFR: 8266519: Cleanup resolve() leftovers from BarrierSet et al
In-Reply-To: <JSk0y-ZZLSvWGEjxfyhkgoKp330enVAJ4e3RUKHtiEA=.bb50eb5a-b94e-44c9-bec0-c3f06e0a4f22@github.com>
References: <JSk0y-ZZLSvWGEjxfyhkgoKp330enVAJ4e3RUKHtiEA=.bb50eb5a-b94e-44c9-bec0-c3f06e0a4f22@github.com>
Message-ID: <QhLJz5NRVpn_S_o3xY5uYnCPQ-zMf83lybw08Dt2t1Q=.5e8dd3bd-e380-4c6d-b36f-2d087f52391c@github.com>

On Tue, 4 May 2021 16:38:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Shenandoah used to require a way to resolve oops, but it's long unused the the corresponding code in the access machinery is obsolete. Let's remove it.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1
>  - [x] tier2

Marked as reviewed by stefank (Reviewer).

-------------

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

From kbarrett at openjdk.java.net  Thu Aug 19 07:50:25 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 19 Aug 2021 07:50:25 GMT
Subject: RFR: 8270041: Consolidate oopDesc::cas_forward_to() and
 oopDesc::forward_to_atomic()
In-Reply-To: <3xGT20phR8n05MxmosIRONZDUtn8T2WTL4uz5MO7FqE=.13e2c107-34ec-4f1d-ba51-f4d21021cea9@github.com>
References: <3xGT20phR8n05MxmosIRONZDUtn8T2WTL4uz5MO7FqE=.13e2c107-34ec-4f1d-ba51-f4d21021cea9@github.com>
Message-ID: <Ozt-v3ANVH5_Co6pkeQkq0NPjwSf7CBGyWnBB9yxB40=.7d688ba9-2040-49ec-91b6-9852773c097e@github.com>

On Wed, 18 Aug 2021 18:36:11 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> The two methods do exactly the same, except one returns a bool, the other a value. The only use of cas_forward_to() can be consolidated to use forward_to_atomic() instead.
> 
> Testing:
>  - [ ] hotspot_gc
>  - [ ] tier1
>  - [ ] tier2

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

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

From dholmes at openjdk.java.net  Thu Aug 19 07:52:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 19 Aug 2021 07:52:25 GMT
Subject: RFR: 8264707: HotSpot Style Guide should permit use of lambda
In-Reply-To: <9VuNIpQL04HwYIa2b4TTpgr5IPdcthN2m0afysCfei4=.7fb1c71f-ac68-4eca-959e-873184ea8a66@github.com>
References: <ClF_S5jjfQ911hsUdbxKkaXjVyJ1euXgkDT8JB5fkSs=.42f08fe5-abd8-4839-858b-036e3012ba6b@github.com>
 <OSK3nNKuYjsfMhseY5E09TWAxmn7HuwDIQpqwhLXlIM=.c2b4a7b6-f11b-4f0a-a057-ee9008f16118@github.com>
 <9VuNIpQL04HwYIa2b4TTpgr5IPdcthN2m0afysCfei4=.7fb1c71f-ac68-4eca-959e-873184ea8a66@github.com>
Message-ID: <wpNAeJn4bQ4QltCjvdo8z71crgGQnGZ4Ggunn-bMQzM=.4fb786c8-35c6-44a5-a684-29976a3f9cea@github.com>

On Wed, 18 Aug 2021 11:27:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> doc/hotspot-style.md line 721:
>> 
>>> 719: is an alternative to having a function or function object class defined at
>>> 720: class or namespace scope.  Instead, a function class definition is placed
>>> 721: directly at the point of use.
>> 
>> Suggested rewording:
>> 
>>> ... namespace scope, instead placing it directly at the point of use.
>
> The wording was intentional; "it" would refer to "a function or function object class", but a *function* can't be locally defined.  But it should be consistent about "function object class" vs "function class".  The former is the terminology used by the Standard.

There should be a consistent subject for each of those sentences, such that "it" would unambiguously be that subject, and then you can combine the second and third sentences into one.

-------------

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

From shade at openjdk.java.net  Thu Aug 19 08:32:34 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 19 Aug 2021 08:32:34 GMT
Subject: RFR: 8272654: Mark word accesses should not use Access API
Message-ID: <vum0UT8aC9qODMBROffPwkfA0CGYcpVi_WnPULU4JyE=.8e66d748-6d1a-46b4-909c-4ce2fdf7d74b@github.com>

See the bug for discussion.

-------------

Commit messages:
 - Initial change

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

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

From kbarrett at openjdk.java.net  Thu Aug 19 08:45:24 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 19 Aug 2021 08:45:24 GMT
Subject: RFR: 8264707: HotSpot Style Guide should permit use of lambda
In-Reply-To: <wpNAeJn4bQ4QltCjvdo8z71crgGQnGZ4Ggunn-bMQzM=.4fb786c8-35c6-44a5-a684-29976a3f9cea@github.com>
References: <ClF_S5jjfQ911hsUdbxKkaXjVyJ1euXgkDT8JB5fkSs=.42f08fe5-abd8-4839-858b-036e3012ba6b@github.com>
 <OSK3nNKuYjsfMhseY5E09TWAxmn7HuwDIQpqwhLXlIM=.c2b4a7b6-f11b-4f0a-a057-ee9008f16118@github.com>
 <9VuNIpQL04HwYIa2b4TTpgr5IPdcthN2m0afysCfei4=.7fb1c71f-ac68-4eca-959e-873184ea8a66@github.com>
 <wpNAeJn4bQ4QltCjvdo8z71crgGQnGZ4Ggunn-bMQzM=.4fb786c8-35c6-44a5-a684-29976a3f9cea@github.com>
Message-ID: <5nzNLXTtJbBMJXKbHpK5VoQpKgGfu7_wopCQZStgNAk=.e166cd7a-b5cf-443f-9eff-a65ba83559f4@github.com>

On Thu, 19 Aug 2021 07:49:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The wording was intentional; "it" would refer to "a function or function object class", but a *function* can't be locally defined.  But it should be consistent about "function object class" vs "function class".  The former is the terminology used by the Standard.
>
> There should be a consistent subject for each of those sentences, such that "it" would unambiguously be that subject, and then you can combine the second and third sentences into one.

Changing the paragraph to this is probably better.  The third sentence didn't really add anything.

"Single-use function objects can be defined locally within a function, directly at the point of use.  This is an alternative to having a function or function object class defined at class or namespace scope."

-------------

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

From stefank at openjdk.java.net  Thu Aug 19 09:04:26 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 19 Aug 2021 09:04:26 GMT
Subject: RFR: 8272654: Mark word accesses should not use Access API
In-Reply-To: <vum0UT8aC9qODMBROffPwkfA0CGYcpVi_WnPULU4JyE=.8e66d748-6d1a-46b4-909c-4ce2fdf7d74b@github.com>
References: <vum0UT8aC9qODMBROffPwkfA0CGYcpVi_WnPULU4JyE=.8e66d748-6d1a-46b4-909c-4ce2fdf7d74b@github.com>
Message-ID: <1ZtyAVU1-mDdvv53tVd39dyhztjnTze77fkmKMeFK_c=.b9bdd1ee-fc03-47bb-93be-e254582abfa3@github.com>

On Wed, 18 Aug 2021 15:36:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for discussion.

Marked as reviewed by stefank (Reviewer).

-------------

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

From rkennke at openjdk.java.net  Thu Aug 19 10:05:29 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 19 Aug 2021 10:05:29 GMT
Subject: Withdrawn: 8270911: Don't use Access API to access object header word
In-Reply-To: <4_GETFuyze8Bs77RVU6GiHXPfNL0W9UVAjQbhj0dXic=.658c3fdf-074e-492c-8940-b96214979770@github.com>
References: <4_GETFuyze8Bs77RVU6GiHXPfNL0W9UVAjQbhj0dXic=.658c3fdf-074e-492c-8940-b96214979770@github.com>
Message-ID: <L3N4kjhC_FwLAbu0DprKJhYfbX9zngEkQC-nokWFDQ0=.62ebbc2a-b403-488f-8dc2-81bbc607e4fa@github.com>

On Mon, 19 Jul 2021 14:04:27 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Back when Shenandoah required read- and write-barriers on all object accesses, we introduced using the HeapAccess API to access object header words, too. Since JDK 13 (introduction of Shenandoah LRB), this is no longer necessary. I propose to simplify header access by not using the Access API but use ordinary C++ instead.
> 
> (N.b: do we want to get rid of all primitive Access API, too? I would do it.)
> 
> Testing:
>  - [x] tier1
>  - [ ] tier2

This pull request has been closed without being integrated.

-------------

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

From rkennke at openjdk.java.net  Thu Aug 19 10:05:29 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 19 Aug 2021 10:05:29 GMT
Subject: RFR: 8270911: Don't use Access API to access object header word
In-Reply-To: <4_GETFuyze8Bs77RVU6GiHXPfNL0W9UVAjQbhj0dXic=.658c3fdf-074e-492c-8940-b96214979770@github.com>
References: <4_GETFuyze8Bs77RVU6GiHXPfNL0W9UVAjQbhj0dXic=.658c3fdf-074e-492c-8940-b96214979770@github.com>
Message-ID: <BIQdnwG1HmNRpKFL9RNOXing7WiqXadrjqsVCezn764=.4588b0d9-756a-4ca6-bbaf-cef79c2bac52@github.com>

On Mon, 19 Jul 2021 14:04:27 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Back when Shenandoah required read- and write-barriers on all object accesses, we introduced using the HeapAccess API to access object header words, too. Since JDK 13 (introduction of Shenandoah LRB), this is no longer necessary. I propose to simplify header access by not using the Access API but use ordinary C++ instead.
> 
> (N.b: do we want to get rid of all primitive Access API, too? I would do it.)
> 
> Testing:
>  - [x] tier1
>  - [ ] tier2

Closing this in favour of #5166

-------------

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

From rkennke at openjdk.java.net  Thu Aug 19 11:04:24 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 19 Aug 2021 11:04:24 GMT
Subject: RFR: 8272654: Mark word accesses should not use Access API
In-Reply-To: <vum0UT8aC9qODMBROffPwkfA0CGYcpVi_WnPULU4JyE=.8e66d748-6d1a-46b4-909c-4ce2fdf7d74b@github.com>
References: <vum0UT8aC9qODMBROffPwkfA0CGYcpVi_WnPULU4JyE=.8e66d748-6d1a-46b4-909c-4ce2fdf7d74b@github.com>
Message-ID: <dhyQtwkgxZzWpX5jNeW-OQIiFobWe1Z7D_3PYMQbFsc=.426d0832-0ed8-4224-8ffe-2b45a819b006@github.com>

On Wed, 18 Aug 2021 15:36:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for discussion.

Looks good to me. Thanks!

-------------

Marked as reviewed by rkennke (Reviewer).

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

From shade at openjdk.java.net  Thu Aug 19 11:11:22 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 19 Aug 2021 11:11:22 GMT
Subject: RFR: 8272654: Mark word accesses should not use Access API
In-Reply-To: <vum0UT8aC9qODMBROffPwkfA0CGYcpVi_WnPULU4JyE=.8e66d748-6d1a-46b4-909c-4ce2fdf7d74b@github.com>
References: <vum0UT8aC9qODMBROffPwkfA0CGYcpVi_WnPULU4JyE=.8e66d748-6d1a-46b4-909c-4ce2fdf7d74b@github.com>
Message-ID: <UOqw2UDQgdpQqCWxQ2lxICzx3go2uThr2ZZ389u_NXk=.b810774e-36b2-46b0-ab23-77608b124b02@github.com>

On Wed, 18 Aug 2021 15:36:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for discussion.

Thanks, folks! @fisk, what do you think?

-------------

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

From eosterlund at openjdk.java.net  Thu Aug 19 13:00:25 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 19 Aug 2021 13:00:25 GMT
Subject: RFR: 8272654: Mark word accesses should not use Access API
In-Reply-To: <vum0UT8aC9qODMBROffPwkfA0CGYcpVi_WnPULU4JyE=.8e66d748-6d1a-46b4-909c-4ce2fdf7d74b@github.com>
References: <vum0UT8aC9qODMBROffPwkfA0CGYcpVi_WnPULU4JyE=.8e66d748-6d1a-46b4-909c-4ce2fdf7d74b@github.com>
Message-ID: <2GIDCjbQIE4L6qLjG9-WtondG2_gKOEzcLK_3axbd34=.eb5c7c93-b5c4-4cc9-ad7e-f611c130c578@github.com>

On Wed, 18 Aug 2021 15:36:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for discussion.

That should speed up compile times a bit. Looks good!

-------------

Marked as reviewed by eosterlund (Reviewer).

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

From shade at openjdk.java.net  Thu Aug 19 14:11:25 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 19 Aug 2021 14:11:25 GMT
Subject: RFR: 8272654: Mark word accesses should not use Access API
In-Reply-To: <2GIDCjbQIE4L6qLjG9-WtondG2_gKOEzcLK_3axbd34=.eb5c7c93-b5c4-4cc9-ad7e-f611c130c578@github.com>
References: <vum0UT8aC9qODMBROffPwkfA0CGYcpVi_WnPULU4JyE=.8e66d748-6d1a-46b4-909c-4ce2fdf7d74b@github.com>
 <2GIDCjbQIE4L6qLjG9-WtondG2_gKOEzcLK_3axbd34=.eb5c7c93-b5c4-4cc9-ad7e-f611c130c578@github.com>
Message-ID: <4o68xZzJ17IZ44PMf6iUi6JNh6FV3q6Y7RVc7qaNT4A=.d80b8e2f-9c11-499a-b4bc-024612a9f84c@github.com>

On Thu, 19 Aug 2021 12:57:49 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> That should speed up compile times a bit. Looks good!

True, it does improves build times a bit:


Before:

real	1m3.142s
user	40m15.343s
sys	2m42.962s

After:

real	1m2.036s
user	39m16.664s
sys	2m40.801s


I'll wait a bit more and then integrate.

-------------

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

From rkennke at openjdk.java.net  Thu Aug 19 14:36:37 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 19 Aug 2021 14:36:37 GMT
Subject: RFR: 8272723: Don't use Access API to access primitive fields
Message-ID: <iq1VnWQc1KuwmmeOnxL2D8NQBqVhxOG5hsyKpZj6mOQ=.81bc39b8-5162-4a05-b5a7-f275bfb12994@github.com>

For earlier incarnations of Shenandoah, we needed to put barriers before accessing primitive fields. This is no longer necessary nor implemented/used by any GC, and we should simplify the code to do plain access instead.

(We may want to remove remaining primitive access machinery in the Access API soon)

Testing:
 - [ ] tier1
 - [ ] tier2
 - [ ] hotspot_gc

-------------

Commit messages:
 - 8272723: Don't use Access API to access primitive fields

Changes: https://git.openjdk.java.net/jdk/pull/5187/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5187&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272723
  Stats: 24 lines in 2 files changed: 6 ins; 0 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5187.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5187/head:pull/5187

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

From shade at openjdk.java.net  Thu Aug 19 14:47:26 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 19 Aug 2021 14:47:26 GMT
Subject: RFR: 8272723: Don't use Access API to access primitive fields
In-Reply-To: <iq1VnWQc1KuwmmeOnxL2D8NQBqVhxOG5hsyKpZj6mOQ=.81bc39b8-5162-4a05-b5a7-f275bfb12994@github.com>
References: <iq1VnWQc1KuwmmeOnxL2D8NQBqVhxOG5hsyKpZj6mOQ=.81bc39b8-5162-4a05-b5a7-f275bfb12994@github.com>
Message-ID: <TxRRpYzsazjWWwIWLY4gIQun7iyFnOFMDHDWEsty7T8=.d7af32e8-90a6-4e7a-8c4a-e85a5123082a@github.com>

On Thu, 19 Aug 2021 14:27:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> For earlier incarnations of Shenandoah, we needed to put barriers before accessing primitive fields. This is no longer necessary nor implemented/used by any GC, and we should simplify the code to do plain access instead.
> 
> (We may want to remove remaining primitive access machinery in the Access API soon)
> 
> Testing:
>  - [ ] tier1
>  - [ ] tier2
>  - [ ] hotspot_gc

I think you missed the spots at least in in `oop.cpp` and `typeArrayOop.inline.hpp` too. Need to grep for `HeapAccess` in the entire Hotspot?

-------------

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

From rkennke at openjdk.java.net  Thu Aug 19 16:05:54 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 19 Aug 2021 16:05:54 GMT
Subject: RFR: 8272723: Don't use Access API to access primitive fields [v2]
In-Reply-To: <iq1VnWQc1KuwmmeOnxL2D8NQBqVhxOG5hsyKpZj6mOQ=.81bc39b8-5162-4a05-b5a7-f275bfb12994@github.com>
References: <iq1VnWQc1KuwmmeOnxL2D8NQBqVhxOG5hsyKpZj6mOQ=.81bc39b8-5162-4a05-b5a7-f275bfb12994@github.com>
Message-ID: <7CVJFJkayM3FxOWa5i6ZuwZHo9K0EMJ-w9I5WnwOT8c=.9c65f300-132d-4d61-be85-8652c2910916@github.com>

> For earlier incarnations of Shenandoah, we needed to put barriers before accessing primitive fields. This is no longer necessary nor implemented/used by any GC, and we should simplify the code to do plain access instead.
> 
> (We may want to remove remaining primitive access machinery in the Access API soon)
> 
> Testing:
>  - [ ] tier1
>  - [ ] tier2
>  - [ ] hotspot_gc

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

  Remove remaining primitive Access API uses

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5187/files
  - new: https://git.openjdk.java.net/jdk/pull/5187/files/beb6b9c8..82366c30

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

  Stats: 136 lines in 5 files changed: 4 ins; 62 del; 70 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5187.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5187/head:pull/5187

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

From github.com+2249648+johntortugo at openjdk.java.net  Thu Aug 19 18:17:26 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Thu, 19 Aug 2021 18:17:26 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 IGV transformations
In-Reply-To: <q4yXuw6KCd6stuAmLaNdI891rKOeN08TjMrXeXkiBkw=.aec2b77b-e487-4cd4-88e0-7b01ecc18eaf@github.com>
References: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
 <q4yXuw6KCd6stuAmLaNdI891rKOeN08TjMrXeXkiBkw=.aec2b77b-e487-4cd4-88e0-7b01ecc18eaf@github.com>
Message-ID: <Iczb6q-7XraOcIMfjHrpn7j4aJvRg2yuGnqI-wXir8s=.a3a457c6-793c-4815-b7df-52fbe35390ab@github.com>

On Tue, 17 Aug 2021 08:01:01 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:
>> 
>> - Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
>> - Add more default IR regex's to IR-based test framework.
>> - Changes to Sub, Div and Add Ideal nodes to that transformations on Int and Long types are the whenever possible same.
>> - Changes to Sub*Node, Div*Node and Add*Node Ideal methods to fix some bugs and include new transformations.
>> - New JTREG "ir_transformations" test group under test/hotspot/jtreg.
>
> src/hotspot/share/opto/divnode.cpp line 481:
> 
>> 479:   if (op1 == Op_MulI && in1->in(1) == in2) {
>> 480:     return new AddINode(in1->in(2), phase->intcon(0));
>> 481:   }
> 
> I don't think that these transformations are valid due to overflow/underflow. Example:
> 
> int x = 1_000_000;
> int y = 10_000;
> System.out.println((x * y) / x); // Output: 1410 (!= 10_000)
> 
> You might come up with some special case handling where it applies without an overflow/underflow but I'm not sure if it's worth to do it while not being fragile.

Oops! Thanks for catching that. I'll remove it and the test.

> test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 47:
> 
>> 45:  * @see IR
>> 46:  */
>> 47: public class IRNode {
> 
> I guess your IDE has applied an alphabetical sorting? I think it's better to keep the old sorting by categories which makes it easier to find specific regexes or to check if a regex is supported or not.

Sounds good to me!

> test/hotspot/jtreg/ir_transformations/AddINodeIdealizationTests.java line 45:
> 
>> 43:     public int simpleZero(int x) {
>> 44:         return (x + x) + (x + x);
>> 45:     }
> 
> This test is named `simpleZero` but the result is `4*x`. Is the method name wrong or is there a mistake in the test itself?

I think the "Zero" suffix was actually an index, as in "simple-0", "simple-1", etc. Clearly not a good name in this case. I'll rename it. Thanks.

> test/hotspot/jtreg/ir_transformations/AddINodeIdealizationTests.java line 53:
> 
>> 51:     public int simpleZeroSub(int x) {
>> 52:         return (x - x) + (x - x);
>> 53:     }
> 
> Just an idea: You could also think about transforming some of these base tests into [custom run tests](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/lib/ir_framework/test/CustomRunTest.java) or [checked tests](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/lib/ir_framework/test/CheckedTest.java) (might be enough for simple tests). This could not only verify the correct IR transformations but also that these tests compute the correct results, especially for edge case values (if it makes sense in a particular test). 
> 
> A custom run test could look something like this:
> 
> 
>     @Test
>     @IR(failOn = {IRNode.LOAD, IRNode.STORE, IRNode.MUL, IRNode.DIV, IRNode.SUB})
>     // Checks (x - x) => 0 and 0 - 0 => 0
>     public int simpleZeroSub(int x) {
>         return (x - x) + (x - x);
>     }
> 
>     @Run(test = "simpleZeroSub")
>     public void runSimpleZeroSub() { // Run methods are not compiled and thus run in interpreter
>         // This getRandom() call is only supported once JDK-8272567 is in for which a PR is currently open.
>         int x = RunInfo.getRandom().nextInt(); // Some random value 
>         Asserts.assertEQ(0, simpleZeroSub(x)); // Result check done in interpreter
>         x = Integer.MAX_VALUE; // Some edge value
>         Asserts.assertEQ(0, simpleZeroSub(x));
>         // ...
>     }
> 
> It might not provide additional value for all your tests but I guess that some of these tests would benefit from additional result checking. I leave it up to you to decide where and if you want to apply these changes.

Thank you @chhagedorn , I think this is a good idea. I'll follow your suggestion and transform some tests into `custom run tests`.

-------------

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

From github.com+2249648+johntortugo at openjdk.java.net  Thu Aug 19 19:25:28 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Thu, 19 Aug 2021 19:25:28 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 IGV transformations
In-Reply-To: <q4yXuw6KCd6stuAmLaNdI891rKOeN08TjMrXeXkiBkw=.aec2b77b-e487-4cd4-88e0-7b01ecc18eaf@github.com>
References: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
 <q4yXuw6KCd6stuAmLaNdI891rKOeN08TjMrXeXkiBkw=.aec2b77b-e487-4cd4-88e0-7b01ecc18eaf@github.com>
Message-ID: <KsiXc77rCdQlMB4Mgt92wsY6dECtRVWyUxnYbW17wy8=.d2465c2d-fbb6-4788-a209-916652b091f7@github.com>

On Tue, 17 Aug 2021 11:15:43 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>     * I think you should split the work into the creation of new IR tests of existing transformations (this RFE) and changing actual C2 IR transformations. I suggest to file a new RFE or bug for missing/potential wrong transformations with the corresponding IR tests for them.

I just created [this RFE](https://bugs.openjdk.java.net/browse/JDK-8272735) for the discussion/work on adjusting the Ideal transformations.

-------------

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

From never at openjdk.java.net  Thu Aug 19 19:35:37 2021
From: never at openjdk.java.net (Tom Rodriguez)
Date: Thu, 19 Aug 2021 19:35:37 GMT
Subject: RFR: 8272736: [JVMCI] Add API for reading and writing JVMCI thread
 locals
Message-ID: <2wNNn6-jgpJE9sKYjwaCt2R-GtD9qdCpkDJN2pq1Ras=.4154e88e-2047-4d85-990d-b774efdf148c@github.com>

8272736: [JVMCI] Add API for reading and writing JVMCI thread locals

-------------

Commit messages:
 - 8272736: [JVMCI] Add API for reading and writing JVMCI thread locals

Changes: https://git.openjdk.java.net/jdk/pull/5192/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5192&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272736
  Stats: 137 lines in 6 files changed: 131 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5192.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5192/head:pull/5192

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

From rkennke at openjdk.java.net  Thu Aug 19 19:53:28 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 19 Aug 2021 19:53:28 GMT
Subject: Integrated: 8266519: Cleanup resolve() leftovers from BarrierSet et al
In-Reply-To: <JSk0y-ZZLSvWGEjxfyhkgoKp330enVAJ4e3RUKHtiEA=.bb50eb5a-b94e-44c9-bec0-c3f06e0a4f22@github.com>
References: <JSk0y-ZZLSvWGEjxfyhkgoKp330enVAJ4e3RUKHtiEA=.bb50eb5a-b94e-44c9-bec0-c3f06e0a4f22@github.com>
Message-ID: <uEVTXhh5wR9aD8kbCyGg4JMjxg94wWexUz7uhX5aOlA=.c12bd412-0b81-4ce8-8ba3-6059fceea738@github.com>

On Tue, 4 May 2021 16:38:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Shenandoah used to require a way to resolve oops, but it's long unused the the corresponding code in the access machinery is obsolete. Let's remove it.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1
>  - [x] tier2

This pull request has now been integrated.

Changeset: 7eccbd4f
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7eccbd4fde58ea36d6a21a2c4ffa3bc5d0b38c10
Stats:     41 lines in 4 files changed: 0 ins; 40 del; 1 mod

8266519: Cleanup resolve() leftovers from BarrierSet et al

Reviewed-by: kbarrett, stefank

-------------

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

From rkennke at openjdk.java.net  Thu Aug 19 19:57:28 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 19 Aug 2021 19:57:28 GMT
Subject: Integrated: 8270041: Consolidate oopDesc::cas_forward_to() and
 oopDesc::forward_to_atomic()
In-Reply-To: <3xGT20phR8n05MxmosIRONZDUtn8T2WTL4uz5MO7FqE=.13e2c107-34ec-4f1d-ba51-f4d21021cea9@github.com>
References: <3xGT20phR8n05MxmosIRONZDUtn8T2WTL4uz5MO7FqE=.13e2c107-34ec-4f1d-ba51-f4d21021cea9@github.com>
Message-ID: <C3rQ69eGWwqfZEzERvtP2otnHDpj5WZ2__ShM03vzZE=.3aaaa622-2c60-4f4f-a114-17eee5907bd9@github.com>

On Wed, 18 Aug 2021 18:36:11 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> The two methods do exactly the same, except one returns a bool, the other a value. The only use of cas_forward_to() can be consolidated to use forward_to_atomic() instead.
> 
> Testing:
>  - [ ] hotspot_gc
>  - [ ] tier1
>  - [ ] tier2

This pull request has now been integrated.

Changeset: f4be211a
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f4be211ae290824cb6c678dcdff0df91a20117d6
Stats:     10 lines in 3 files changed: 0 ins; 9 del; 1 mod

8270041: Consolidate oopDesc::cas_forward_to() and oopDesc::forward_to_atomic()

Reviewed-by: stefank, kbarrett

-------------

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

From svkamath at openjdk.java.net  Thu Aug 19 20:42:51 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Thu, 19 Aug 2021 20:42:51 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v11]
In-Reply-To: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
Message-ID: <d6Dpj5ZQLqPr3Lh4spBoLKq-KNRqYvC8wxSfppsh9bY=.cdbb3b1a-1f12-4555-af27-b14d27d01901@github.com>

> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
> Performance gain of ~1.5x - 2x for message sizes 8k and above.

Smita Kamath has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' of https://git.openjdk.java.net/jdk into aes-gcm
 - Moved declaration in vmStructs.cpp to other AESCrypt declarations
 - comment update
 - rewiew update
 - Merge branch 'aes-gcm' of github.com:smita-kamath/jdk into aes-gcm
 - changed file property of GaloisCounterMode.java
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into aes-gcm
 - Updates, comment and variable cleanup
 - merge rest
 - merge
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/f4be211a...94e46aae

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4019/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=10
  Stats: 1430 lines in 21 files changed: 1186 ins; 118 del; 126 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4019.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4019/head:pull/4019

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

From kvn at openjdk.java.net  Thu Aug 19 21:23:22 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 19 Aug 2021 21:23:22 GMT
Subject: RFR: 8272736: [JVMCI] Add API for reading and writing JVMCI
 thread locals
In-Reply-To: <2wNNn6-jgpJE9sKYjwaCt2R-GtD9qdCpkDJN2pq1Ras=.4154e88e-2047-4d85-990d-b774efdf148c@github.com>
References: <2wNNn6-jgpJE9sKYjwaCt2R-GtD9qdCpkDJN2pq1Ras=.4154e88e-2047-4d85-990d-b774efdf148c@github.com>
Message-ID: <EMqmZOvp6LO_sGsozY-4FkDtIF91tDNNA9ywIJHxzUc=.03a6c017-2c1f-4c3c-8dc8-5f153698def4@github.com>

On Thu, 19 Aug 2021 19:27:54 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> 8272736: [JVMCI] Add API for reading and writing JVMCI thread locals

Looks good.

Please, test before push.

-------------

Marked as reviewed by kvn (Reviewer).

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

From scott.gibbons at intel.com  Fri Aug 20 00:10:04 2021
From: scott.gibbons at intel.com (Gibbons, Scott)
Date: Fri, 20 Aug 2021 00:10:04 +0000
Subject: RFC: x86_64: Fixing the align() macro
Message-ID: <CY4PR11MB00372DFF085FDF1ECEC8E705E2C19@CY4PR11MB0037.namprd11.prod.outlook.com>

Hi, everyone.  This is my first post to this forum, so please let me know if this type of discussion is welcome here, and an alternative forum if it's not :).

I ran into an issue where align(64) breaks on the x86_64 platform within stubGenerator_x86_64.cpp.  I would like input on a fix *AND* how the community would like to see it tested.

There are occasions where I need to align certain data to a 64-byte boundary for AVX-512 aligned instructions.  The issue that I uncovered was that the single-parameter align(int modulus) would sometimes not align properly with align(64).  Unwinding this, I found that align(int modulus) calls align(int modulus, int target) with the target parameter as offset() (i.e., align(modulus, offset());).  Further exploration showed that offset() was 'return _end - _start', which is effectively the size of the code segment and not the offset of the PC.  So align(64) would align the PC to a multiple of 64 bytes from the start of the segment, and not to a pure 64-byte boundary as requested.

The workaround that I implemented was to use the two-parameter version of align(), passing pc() as the target.  This fixed the specific issue I was encountering, and now I'd like to implement a general solution.

One solution would be to change the single-parameter align() to use pc() instead of offset() in the call to the two-parameter align() function.  I believe this would solve the issue, however the single-parameter align() is used very frequently, and I'd like to minimize the number of potential issues this change could trigger.

The second solution (my preferred) is to change the allocation alignment of code segments to 64-bytes.  This would effectively make the size equivalent to the PC for purposes of the modular arithmetic for alignment.  That is, _start % 64 is zero, so (_end - _start) % 64 is equivalent to (_end % 64), achieving the desired result.

I would really like to hear others' opinions and possible alternative approaches.  I'm also not sure how this change would affect relocation, so I'd like to hear that as well.

I also would like to know how the community would approach creating an appropriate test for this to be included in the regression suites.

Thanks,
--Scott Gibbons
Software Development Engineer, Runtime Engineering
[cid:image003.jpg at 01D7951D.0C49EAC0]  DEVELOPER SOFTWARE ENGINEERING
Ph: 1-503-456-7756
Cell: 1-469-450-8390
2501 NE Century Blvd
Hillsboro, OR 97124
Intel Corporation | www.intel.com<https://webmail.intel.com/owa/redir.aspx?SURL=WYr7qZDpIv3m1SKFmeHJuzsfCBuGN-jwkBYQUSRR6yrupkscpgzUCGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAG4AdABlAGwALgBjAG8AbQA.&URL=http%3a%2f%2fwww.intel.com>


From dean.long at oracle.com  Fri Aug 20 01:54:00 2021
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Thu, 19 Aug 2021 18:54:00 -0700
Subject: RFC: x86_64: Fixing the align() macro
In-Reply-To: <CY4PR11MB00372DFF085FDF1ECEC8E705E2C19@CY4PR11MB0037.namprd11.prod.outlook.com>
References: <CY4PR11MB00372DFF085FDF1ECEC8E705E2C19@CY4PR11MB0037.namprd11.prod.outlook.com>
Message-ID: <bd46f335-a977-3679-8cc5-d39a5b391db6@oracle.com>

Hi Scott,

On 8/19/21 5:10 PM, Gibbons, Scott wrote:
> Hi, everyone.  This is my first post to this forum, so please let me know if this type of discussion is welcome here, and an alternative forum if it's not :).
>
> I ran into an issue where align(64) breaks on the x86_64 platform within stubGenerator_x86_64.cpp.  I would like input on a fix *AND* how the community would like to see it tested.
>
> There are occasions where I need to align certain data to a 64-byte boundary for AVX-512 aligned instructions.  The issue that I uncovered was that the single-parameter align(int modulus) would sometimes not align properly with align(64).  Unwinding this, I found that align(int modulus) calls align(int modulus, int target) with the target parameter as offset() (i.e., align(modulus, offset());).  Further exploration showed that offset() was 'return _end - _start', which is effectively the size of the code segment and not the offset of the PC.  So align(64) would align the PC to a multiple of 64 bytes from the start of the segment, and not to a pure 64-byte boundary as requested.
>
> The workaround that I implemented was to use the two-parameter version of align(), passing pc() as the target.  This fixed the specific issue I was encountering, and now I'd like to implement a general solution.


The problem with using pc() is when the code buffer gets copied to a 
different location.


> One solution would be to change the single-parameter align() to use pc() instead of offset() in the call to the two-parameter align() function.  I believe this would solve the issue, however the single-parameter align() is used very frequently, and I'd like to minimize the number of potential issues this change could trigger.
>
> The second solution (my preferred) is to change the allocation alignment of code segments to 64-bytes.  This would effectively make the size equivalent to the PC for purposes of the modular arithmetic for alignment.  That is, _start % 64 is zero, so (_end - _start) % 64 is equivalent to (_end % 64), achieving the desired result.


The disadvantage to this is wasting space when extra alignment isn't 
needed.? How about the following compromise:

1. keep the default alignment as 32 bytes

2. keep using offset() for alignment

3. if align(x) is used with x > default allocation alignment (32), then 
make a note of that in the code buffer

4. if the code buffer is copied, use the max required alignment from 3) 
and the PC of the old code buffer to compute the required allocation 
alignment of the new code buffer.? For align(64), no adjustment would be 
needed 50% of the time.

dl


> I would really like to hear others' opinions and possible alternative approaches.  I'm also not sure how this change would affect relocation, so I'd like to hear that as well.
>
> I also would like to know how the community would approach creating an appropriate test for this to be included in the regression suites.
>
> Thanks,
> --Scott Gibbons
> Software Development Engineer, Runtime Engineering
> [cid:image003.jpg at 01D7951D.0C49EAC0]  DEVELOPER SOFTWARE ENGINEERING
> Ph: 1-503-456-7756
> Cell: 1-469-450-8390
> 2501 NE Century Blvd
> Hillsboro, OR 97124
> Intel Corporation | www.intel.com<https://webmail.intel.com/owa/redir.aspx?SURL=WYr7qZDpIv3m1SKFmeHJuzsfCBuGN-jwkBYQUSRR6yrupkscpgzUCGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAG4AdABlAGwALgBjAG8AbQA.&URL=http%3a%2f%2fwww.intel.com>
>

From dholmes at openjdk.java.net  Fri Aug 20 02:48:22 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 20 Aug 2021 02:48:22 GMT
Subject: RFR: 8272736: [JVMCI] Add API for reading and writing JVMCI
 thread locals
In-Reply-To: <2wNNn6-jgpJE9sKYjwaCt2R-GtD9qdCpkDJN2pq1Ras=.4154e88e-2047-4d85-990d-b774efdf148c@github.com>
References: <2wNNn6-jgpJE9sKYjwaCt2R-GtD9qdCpkDJN2pq1Ras=.4154e88e-2047-4d85-990d-b774efdf148c@github.com>
Message-ID: <qo8Dhnw_p8q4Dq5OGztnK5XYLGNgxIb2AX816EzJevw=.3aec804f-efa0-4171-b365-de042161b9e3@github.com>

On Thu, 19 Aug 2021 19:27:54 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> 8272736: [JVMCI] Add API for reading and writing JVMCI thread locals

src/hotspot/share/runtime/thread.hpp line 961:

> 959: 
> 960:   // Fast thread locals for use by JVMCI
> 961:   jlong      _jvmci_reserved0;

Update: please ignore (hit wrong button) I now see this coming from Java.

We are trying to avoid use of Java types in code that does not directly interact with Java. Does this really need to be a jlong or does it just need to be 64-bit? Or does it need to be the same size as a ptr whatever that may be?

-------------

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

From never at openjdk.java.net  Fri Aug 20 04:48:23 2021
From: never at openjdk.java.net (Tom Rodriguez)
Date: Fri, 20 Aug 2021 04:48:23 GMT
Subject: RFR: 8272736: [JVMCI] Add API for reading and writing JVMCI
 thread locals
In-Reply-To: <qo8Dhnw_p8q4Dq5OGztnK5XYLGNgxIb2AX816EzJevw=.3aec804f-efa0-4171-b365-de042161b9e3@github.com>
References: <2wNNn6-jgpJE9sKYjwaCt2R-GtD9qdCpkDJN2pq1Ras=.4154e88e-2047-4d85-990d-b774efdf148c@github.com>
 <qo8Dhnw_p8q4Dq5OGztnK5XYLGNgxIb2AX816EzJevw=.3aec804f-efa0-4171-b365-de042161b9e3@github.com>
Message-ID: <5sCO9mXPcTK8KJKFbTBCRBofKJ9iK9B6pDNe0XD3r7Y=.7b2d2db6-97e7-4cf2-aed7-49a2c915dd0e@github.com>

On Fri, 20 Aug 2021 02:43:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 8272736: [JVMCI] Add API for reading and writing JVMCI thread locals
>
> src/hotspot/share/runtime/thread.hpp line 961:
> 
>> 959: 
>> 960:   // Fast thread locals for use by JVMCI
>> 961:   jlong      _jvmci_reserved0;
> 
> Update: please ignore (hit wrong button) I now see this coming from Java.
> 
> We are trying to avoid use of Java types in code that does not directly interact with Java. Does this really need to be a jlong or does it just need to be 64-bit? Or does it need to be the same size as a ptr whatever that may be?

Yes that's right.  Since it's now exposed through Java it really needs to be a Java compatible type.

-------------

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

From never at openjdk.java.net  Fri Aug 20 05:23:49 2021
From: never at openjdk.java.net (Tom Rodriguez)
Date: Fri, 20 Aug 2021 05:23:49 GMT
Subject: RFR: 8272736: [JVMCI] Add API for reading and writing JVMCI
 thread locals [v2]
In-Reply-To: <2wNNn6-jgpJE9sKYjwaCt2R-GtD9qdCpkDJN2pq1Ras=.4154e88e-2047-4d85-990d-b774efdf148c@github.com>
References: <2wNNn6-jgpJE9sKYjwaCt2R-GtD9qdCpkDJN2pq1Ras=.4154e88e-2047-4d85-990d-b774efdf148c@github.com>
Message-ID: <Ug2gd6Ka0FnWzz3cEENZas7BO4XvGtRA3WJ4oSTB5FU=.2161022d-6c43-4fdf-ba1d-ef2ec1525087@github.com>

> 8272736: [JVMCI] Add API for reading and writing JVMCI thread locals

Tom Rodriguez 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:

  8272736: [JVMCI] Add API for reading and writing JVMCI thread locals

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5192/files
  - new: https://git.openjdk.java.net/jdk/pull/5192/files/60a1b4ca..fdddf672

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

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

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

From thartmann at openjdk.java.net  Fri Aug 20 06:28:25 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 20 Aug 2021 06:28:25 GMT
Subject: RFR: 8272563: Possible assertion failure in CardTableBarrierSetC1
In-Reply-To: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
Message-ID: <fusGi655in3RtNuh945sQEdwRZ_WbLG8C-YHanxwHBI=.574ba781-2e8e-40f3-a6c1-6c79363792a8@github.com>

On Wed, 18 Aug 2021 12:37:00 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
> 
> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>> __ move(addr, tmp);
> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
> The fix is to check if it is is_oop() and call the mov appropriately.
> 
> No issues found in local testing and Mach5 tier1-3

Using an additional register + move does not seem right to fix this.

The problem is that `addr->type()` is `T_OBJECT` and the type of the virtual register `tmp` is `T_LONG`, right?

What about this?

LIR_Opr tmp = gen->new_register(addr->type());

Could the reporter provide a reproducer?

-------------

Changes requested by thartmann (Reviewer).

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

From stefank at openjdk.java.net  Fri Aug 20 06:32:33 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 20 Aug 2021 06:32:33 GMT
Subject: RFR: 8272723: Don't use Access API to access primitive fields [v2]
In-Reply-To: <7CVJFJkayM3FxOWa5i6ZuwZHo9K0EMJ-w9I5WnwOT8c=.9c65f300-132d-4d61-be85-8652c2910916@github.com>
References: <iq1VnWQc1KuwmmeOnxL2D8NQBqVhxOG5hsyKpZj6mOQ=.81bc39b8-5162-4a05-b5a7-f275bfb12994@github.com>
 <7CVJFJkayM3FxOWa5i6ZuwZHo9K0EMJ-w9I5WnwOT8c=.9c65f300-132d-4d61-be85-8652c2910916@github.com>
Message-ID: <f-8dOtAtHgzTso6Gqnic_PdHkkpgVZZc4b8HEO2feKM=.ff9cfa9b-9992-4787-aa36-5c5665209adf@github.com>

On Thu, 19 Aug 2021 16:05:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> For earlier incarnations of Shenandoah, we needed to put barriers before accessing primitive fields. This is no longer necessary nor implemented/used by any GC, and we should simplify the code to do plain access instead.
>> 
>> (We may want to remove remaining primitive access machinery in the Access API soon)
>> 
>> Testing:
>>  - [x] tier1
>>  - [ ] tier2
>>  - [ ] hotspot_gc
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove remaining primitive Access API uses

src/hotspot/share/jvmci/jvmciJavaClasses.cpp line 234:

> 232:       InstanceKlass* ik = className::klass();                                                                             \
> 233:       oop base = ik->static_field_base_raw();                                                                             \
> 234:       return *base->field_addr<jtypename>(className::_##name##_offset);                                                    \

Need to align the right end.

src/hotspot/share/jvmci/jvmciJavaClasses.cpp line 240:

> 238:       InstanceKlass* ik = className::klass();                                                                             \
> 239:       oop base = ik->static_field_base_raw();                                                                             \
> 240:       *base->field_addr<jtypename>(className::_##name##_offset) = x;                                                       \

alignment

src/hotspot/share/oops/oop.hpp line 125:

> 123: 
> 124:   // Need this as public for garbage collection.
> 125:   template <class T> inline T* obj_field_addr(int offset) const;

The `template<typename T>` doesn't match the style used for obj_field_addr.

-------------

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

From stefank at openjdk.java.net  Fri Aug 20 06:36:23 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 20 Aug 2021 06:36:23 GMT
Subject: RFR: 8272723: Don't use Access API to access primitive fields [v2]
In-Reply-To: <7CVJFJkayM3FxOWa5i6ZuwZHo9K0EMJ-w9I5WnwOT8c=.9c65f300-132d-4d61-be85-8652c2910916@github.com>
References: <iq1VnWQc1KuwmmeOnxL2D8NQBqVhxOG5hsyKpZj6mOQ=.81bc39b8-5162-4a05-b5a7-f275bfb12994@github.com>
 <7CVJFJkayM3FxOWa5i6ZuwZHo9K0EMJ-w9I5WnwOT8c=.9c65f300-132d-4d61-be85-8652c2910916@github.com>
Message-ID: <RY_TjYWtCb_vOzZFgBuas9pQx2E46d0zSWiPyu--Brg=.54fab99b-ed21-4eaa-8d63-fb05a5c36dc5@github.com>

On Thu, 19 Aug 2021 16:05:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> For earlier incarnations of Shenandoah, we needed to put barriers before accessing primitive fields. This is no longer necessary nor implemented/used by any GC, and we should simplify the code to do plain access instead.
>> 
>> (We may want to remove remaining primitive access machinery in the Access API soon)
>> 
>> Testing:
>>  - [x] tier1
>>  - [ ] tier2
>>  - [ ] hotspot_gc
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove remaining primitive Access API uses

src/hotspot/share/oops/oop.inline.hpp line 220:

> 218: 
> 219: template <class T>
> 220: T*       oopDesc::obj_field_addr(int offset) const { return (T*) field_addr(offset); }

The `template<typename T>` doesn't match the style used for obj_field_addr.

Could/should we consolidate the three functions?:

void*    oopDesc::field_addr(int offset)     const { return reinterpret_cast<void*>(cast_from_oop<intptr_t>(as_oop()) + offset); }

template <typename T>
T*       oopDesc::field_addr(int offset)     const { return reinterpret_cast<T*>(field_addr(offset)); }

template <typename T>
T*       oopDesc::obj_field_addr(int offset) const { return field_addr<T>(offset); }

-------------

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

From stefank at openjdk.java.net  Fri Aug 20 06:41:22 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 20 Aug 2021 06:41:22 GMT
Subject: RFR: 8272723: Don't use Access API to access primitive fields [v2]
In-Reply-To: <7CVJFJkayM3FxOWa5i6ZuwZHo9K0EMJ-w9I5WnwOT8c=.9c65f300-132d-4d61-be85-8652c2910916@github.com>
References: <iq1VnWQc1KuwmmeOnxL2D8NQBqVhxOG5hsyKpZj6mOQ=.81bc39b8-5162-4a05-b5a7-f275bfb12994@github.com>
 <7CVJFJkayM3FxOWa5i6ZuwZHo9K0EMJ-w9I5WnwOT8c=.9c65f300-132d-4d61-be85-8652c2910916@github.com>
Message-ID: <mdR7Gmo8an2Fr4nfnFcBBKJjVawgBGsBLPnyXnOOlVY=.9fe820e6-1e1d-4f91-93c3-a792c3f53d93@github.com>

On Thu, 19 Aug 2021 16:05:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> For earlier incarnations of Shenandoah, we needed to put barriers before accessing primitive fields. This is no longer necessary nor implemented/used by any GC, and we should simplify the code to do plain access instead.
>> 
>> (We may want to remove remaining primitive access machinery in the Access API soon)
>> 
>> Testing:
>>  - [x] tier1
>>  - [ ] tier2
>>  - [ ] hotspot_gc
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove remaining primitive Access API uses

src/hotspot/share/oops/oop.inline.hpp line 240:

> 238: inline void     oopDesc::bool_field_put(int offset, jboolean value) { *field_addr<jboolean>(offset) = jboolean(value & 1); }
> 239: inline jboolean oopDesc::bool_field_volatile(int offset) const      { return Atomic::load_acquire(field_addr<jboolean>(offset)); }
> 240: inline void     oopDesc::bool_field_put_volatile(int offset, jboolean value) { Atomic::release_store_fence(field_addr<jboolean>(offset), jboolean(value & 1)); }

bool_field_volatile doesn't match the old HeapAccess<MO_SEQ_CST::load_at:

RawAccessBarrier<decorators>::load_internal(void* addr) {
  if (support_IRIW_for_not_multiple_copy_atomic_cpu) {
    OrderAccess::fence();
  }
  return Atomic::load_acquire(reinterpret_cast<const volatile T*>(addr));
}

src/hotspot/share/oops/typeArrayOop.inline.hpp line 93:

> 91: 
> 92: inline jbyte typeArrayOopDesc::byte_at(int which) const {
> 93:   assert(is_within_bounds(which), "index %d out of bounds %d", which, length());

byte_at_addr already asserts this.

-------------

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

From stefank at openjdk.java.net  Fri Aug 20 06:46:26 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 20 Aug 2021 06:46:26 GMT
Subject: RFR: 8272723: Don't use Access API to access primitive fields [v2]
In-Reply-To: <7CVJFJkayM3FxOWa5i6ZuwZHo9K0EMJ-w9I5WnwOT8c=.9c65f300-132d-4d61-be85-8652c2910916@github.com>
References: <iq1VnWQc1KuwmmeOnxL2D8NQBqVhxOG5hsyKpZj6mOQ=.81bc39b8-5162-4a05-b5a7-f275bfb12994@github.com>
 <7CVJFJkayM3FxOWa5i6ZuwZHo9K0EMJ-w9I5WnwOT8c=.9c65f300-132d-4d61-be85-8652c2910916@github.com>
Message-ID: <MtrzSoEjiI7jQ8jHZGhInutpgZAedrBgfNHLVFRUhyU=.890402a8-9519-4520-8452-a349d83dba25@github.com>

On Thu, 19 Aug 2021 16:05:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> For earlier incarnations of Shenandoah, we needed to put barriers before accessing primitive fields. This is no longer necessary nor implemented/used by any GC, and we should simplify the code to do plain access instead.
>> 
>> (We may want to remove remaining primitive access machinery in the Access API soon)
>> 
>> Testing:
>>  - [x] tier1
>>  - [ ] tier2
>>  - [ ] hotspot_gc
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove remaining primitive Access API uses

Thanks for cleaning this up. I do have a few comments that I'd like to get addressed.

src/hotspot/share/prims/unsafe.cpp line 233:

> 231:   T get_volatile() {
> 232:     GuardUnsafeAccess guard(_thread);
> 233:     volatile T ret = Atomic::load_acquire(addr());

Is MO_SEQ_CST to load_acquire mapping correct?

-------------

Changes requested by stefank (Reviewer).

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

From eosterlund at openjdk.java.net  Fri Aug 20 07:38:31 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 20 Aug 2021 07:38:31 GMT
Subject: RFR: 8272723: Don't use Access API to access primitive fields [v2]
In-Reply-To: <MtrzSoEjiI7jQ8jHZGhInutpgZAedrBgfNHLVFRUhyU=.890402a8-9519-4520-8452-a349d83dba25@github.com>
References: <iq1VnWQc1KuwmmeOnxL2D8NQBqVhxOG5hsyKpZj6mOQ=.81bc39b8-5162-4a05-b5a7-f275bfb12994@github.com>
 <7CVJFJkayM3FxOWa5i6ZuwZHo9K0EMJ-w9I5WnwOT8c=.9c65f300-132d-4d61-be85-8652c2910916@github.com>
 <MtrzSoEjiI7jQ8jHZGhInutpgZAedrBgfNHLVFRUhyU=.890402a8-9519-4520-8452-a349d83dba25@github.com>
Message-ID: <I5MG3FtXWywiNB2j6omV_AA8T0J2gzTI7GSysWSj-Cc=.b3614115-b845-410f-911a-0426ec31cf11@github.com>

On Fri, 20 Aug 2021 06:41:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove remaining primitive Access API uses
>
> src/hotspot/share/prims/unsafe.cpp line 233:
> 
>> 231:   T get_volatile() {
>> 232:     GuardUnsafeAccess guard(_thread);
>> 233:     volatile T ret = Atomic::load_acquire(addr());
> 
> Is MO_SEQ_CST to load_acquire mapping correct?

No it is not.

-------------

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

From eosterlund at openjdk.java.net  Fri Aug 20 07:38:32 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 20 Aug 2021 07:38:32 GMT
Subject: RFR: 8272723: Don't use Access API to access primitive fields [v2]
In-Reply-To: <I5MG3FtXWywiNB2j6omV_AA8T0J2gzTI7GSysWSj-Cc=.b3614115-b845-410f-911a-0426ec31cf11@github.com>
References: <iq1VnWQc1KuwmmeOnxL2D8NQBqVhxOG5hsyKpZj6mOQ=.81bc39b8-5162-4a05-b5a7-f275bfb12994@github.com>
 <7CVJFJkayM3FxOWa5i6ZuwZHo9K0EMJ-w9I5WnwOT8c=.9c65f300-132d-4d61-be85-8652c2910916@github.com>
 <MtrzSoEjiI7jQ8jHZGhInutpgZAedrBgfNHLVFRUhyU=.890402a8-9519-4520-8452-a349d83dba25@github.com>
 <I5MG3FtXWywiNB2j6omV_AA8T0J2gzTI7GSysWSj-Cc=.b3614115-b845-410f-911a-0426ec31cf11@github.com>
Message-ID: <zObtttYptrF5FXUy2sM-VtbL1TrdrEZnbXnpO5ltn0g=.56f8f8d1-09d3-4e88-a078-4e339bf61c17@github.com>

On Fri, 20 Aug 2021 07:33:07 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/share/prims/unsafe.cpp line 233:
>> 
>>> 231:   T get_volatile() {
>>> 232:     GuardUnsafeAccess guard(_thread);
>>> 233:     volatile T ret = Atomic::load_acquire(addr());
>> 
>> Is MO_SEQ_CST to load_acquire mapping correct?
>
> No it is not.

> Is MO_SEQ_CST to load_acquire mapping correct?

We should probably retain RawAccess<MO_SEQ_CST> here to get the right semantics.

-------------

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

From shade at openjdk.java.net  Fri Aug 20 07:39:29 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 20 Aug 2021 07:39:29 GMT
Subject: Integrated: 8272654: Mark word accesses should not use Access API
In-Reply-To: <vum0UT8aC9qODMBROffPwkfA0CGYcpVi_WnPULU4JyE=.8e66d748-6d1a-46b4-909c-4ce2fdf7d74b@github.com>
References: <vum0UT8aC9qODMBROffPwkfA0CGYcpVi_WnPULU4JyE=.8e66d748-6d1a-46b4-909c-4ce2fdf7d74b@github.com>
Message-ID: <SMUL813j4tXwCWrIYAes8azs2h0Z2s4dHCgwI6OGpuE=.f2d80252-c4fc-484a-a067-33f88ecc9145@github.com>

On Wed, 18 Aug 2021 15:36:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for discussion.

This pull request has now been integrated.

Changeset: a81e5e93
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a81e5e9353a635a2307ff4e5de8a304c14f08047
Stats:     8 lines in 1 file changed: 0 ins; 3 del; 5 mod

8272654: Mark word accesses should not use Access API

Reviewed-by: stefank, rkennke, eosterlund

-------------

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

From rkennke at openjdk.java.net  Fri Aug 20 08:39:27 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 20 Aug 2021 08:39:27 GMT
Subject: RFR: 8272723: Don't use Access API to access primitive fields [v2]
In-Reply-To: <zObtttYptrF5FXUy2sM-VtbL1TrdrEZnbXnpO5ltn0g=.56f8f8d1-09d3-4e88-a078-4e339bf61c17@github.com>
References: <iq1VnWQc1KuwmmeOnxL2D8NQBqVhxOG5hsyKpZj6mOQ=.81bc39b8-5162-4a05-b5a7-f275bfb12994@github.com>
 <7CVJFJkayM3FxOWa5i6ZuwZHo9K0EMJ-w9I5WnwOT8c=.9c65f300-132d-4d61-be85-8652c2910916@github.com>
 <MtrzSoEjiI7jQ8jHZGhInutpgZAedrBgfNHLVFRUhyU=.890402a8-9519-4520-8452-a349d83dba25@github.com>
 <I5MG3FtXWywiNB2j6omV_AA8T0J2gzTI7GSysWSj-Cc=.b3614115-b845-410f-911a-0426ec31cf11@github.com>
 <zObtttYptrF5FXUy2sM-VtbL1TrdrEZnbXnpO5ltn0g=.56f8f8d1-09d3-4e88-a078-4e339bf61c17@github.com>
Message-ID: <HcHC9D2ZHdB_89sBDaojRvo2eGM8ELRWSnE25uSq20o=.f78c08fa-3e62-4a8e-9ecf-e8deec044ef3@github.com>

On Fri, 20 Aug 2021 07:35:40 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> No it is not.
>
>> Is MO_SEQ_CST to load_acquire mapping correct?
> 
> We should probably retain RawAccess<MO_SEQ_CST> here to get the right semantics.

I'll restore the volatile accesses to use RawAccess<MO_SEQ_CST> for now, but maybe it would be better in the long run to have simpler Atomic::load<MO_SEQ_CST> accessors?

-------------

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

From rkennke at openjdk.java.net  Fri Aug 20 08:51:54 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 20 Aug 2021 08:51:54 GMT
Subject: RFR: 8272723: Don't use Access API to access primitive fields [v3]
In-Reply-To: <iq1VnWQc1KuwmmeOnxL2D8NQBqVhxOG5hsyKpZj6mOQ=.81bc39b8-5162-4a05-b5a7-f275bfb12994@github.com>
References: <iq1VnWQc1KuwmmeOnxL2D8NQBqVhxOG5hsyKpZj6mOQ=.81bc39b8-5162-4a05-b5a7-f275bfb12994@github.com>
Message-ID: <UolCxvbtWTVgIPlTCem9zbln2xnjCZjo99DGHUt9mB8=.7710e81a-6fb4-4fec-8b13-48763cd133d3@github.com>

> For earlier incarnations of Shenandoah, we needed to put barriers before accessing primitive fields. This is no longer necessary nor implemented/used by any GC, and we should simplify the code to do plain access instead.
> 
> (We may want to remove remaining primitive access machinery in the Access API soon)
> 
> Testing:
>  - [x] tier1
>  - [ ] tier2
>  - [ ] hotspot_gc

Roman Kennke 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 branch 'master' into JDK-8272723
 - Remove redundant asserts
 - Revert to use RawAccess<MO_SEQ_CST> for volatile accesses
 - Fix alignment
 - Consolidate (obj)field_addr() variants
 - Remove remaining primitive Access API uses
 - 8272723: Don't use Access API to access primitive fields

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5187/files
  - new: https://git.openjdk.java.net/jdk/pull/5187/files/82366c30..3aff84ab

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

  Stats: 273 lines in 22 files changed: 115 ins; 110 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5187.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5187/head:pull/5187

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

From github.com+4146708+a74nh at openjdk.java.net  Fri Aug 20 08:54:36 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Fri, 20 Aug 2021 08:54:36 GMT
Subject: RFR: 8269687: pauth_aarch64.hpp include name is incorrect
Message-ID: <mn_iAE8Z2n_DqxM1srOaitn7qJMnn1GCLb78b418jgw=.bc3fde65-3616-4223-b3b4-eb36aa125920@github.com>

Quick fix to correct the include guards.

-------------

Commit messages:
 - 8269687: pauth_aarch64.hpp include name is incorrect

Changes: https://git.openjdk.java.net/jdk/pull/5196/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5196&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269687
  Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5196.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5196/head:pull/5196

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

From chagedorn at openjdk.java.net  Fri Aug 20 09:03:27 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 20 Aug 2021 09:03:27 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 IGV transformations
In-Reply-To: <Iczb6q-7XraOcIMfjHrpn7j4aJvRg2yuGnqI-wXir8s=.a3a457c6-793c-4815-b7df-52fbe35390ab@github.com>
References: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
 <q4yXuw6KCd6stuAmLaNdI891rKOeN08TjMrXeXkiBkw=.aec2b77b-e487-4cd4-88e0-7b01ecc18eaf@github.com>
 <Iczb6q-7XraOcIMfjHrpn7j4aJvRg2yuGnqI-wXir8s=.a3a457c6-793c-4815-b7df-52fbe35390ab@github.com>
Message-ID: <xLl-QD7wNk7nruzhBVUtrQWADiehmCHWghbXcCa3Akc=.f68c8f60-803f-4a40-8208-3753dc8d400c@github.com>

On Thu, 19 Aug 2021 18:14:50 GMT, John Tortugo <github.com+2249648+JohnTortugo at openjdk.org> wrote:

>> src/hotspot/share/opto/divnode.cpp line 481:
>> 
>>> 479:   if (op1 == Op_MulI && in1->in(1) == in2) {
>>> 480:     return new AddINode(in1->in(2), phase->intcon(0));
>>> 481:   }
>> 
>> I don't think that these transformations are valid due to overflow/underflow. Example:
>> 
>> int x = 1_000_000;
>> int y = 10_000;
>> System.out.println((x * y) / x); // Output: 1410 (!= 10_000)
>> 
>> You might come up with some special case handling where it applies without an overflow/underflow but I'm not sure if it's worth to do it while not being fragile.
>
> Oops! Thanks for catching that. I'll remove it and the test.

Sounds good, thanks!

>> test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 47:
>> 
>>> 45:  * @see IR
>>> 46:  */
>>> 47: public class IRNode {
>> 
>> I guess your IDE has applied an alphabetical sorting? I think it's better to keep the old sorting by categories which makes it easier to find specific regexes or to check if a regex is supported or not.
>
> Sounds good to me!

Thanks!

>> test/hotspot/jtreg/ir_transformations/AddINodeIdealizationTests.java line 45:
>> 
>>> 43:     public int simpleZero(int x) {
>>> 44:         return (x + x) + (x + x);
>>> 45:     }
>> 
>> This test is named `simpleZero` but the result is `4*x`. Is the method name wrong or is there a mistake in the test itself?
>
> I think the "Zero" suffix was actually an index, as in "simple-0", "simple-1", etc. Clearly not a good name in this case. I'll rename it. Thanks.

Ah I see, it was a little bit confusing :-)

>> test/hotspot/jtreg/ir_transformations/AddINodeIdealizationTests.java line 53:
>> 
>>> 51:     public int simpleZeroSub(int x) {
>>> 52:         return (x - x) + (x - x);
>>> 53:     }
>> 
>> Just an idea: You could also think about transforming some of these base tests into [custom run tests](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/lib/ir_framework/test/CustomRunTest.java) or [checked tests](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/lib/ir_framework/test/CheckedTest.java) (might be enough for simple tests). This could not only verify the correct IR transformations but also that these tests compute the correct results, especially for edge case values (if it makes sense in a particular test). 
>> 
>> A custom run test could look something like this:
>> 
>> 
>>     @Test
>>     @IR(failOn = {IRNode.LOAD, IRNode.STORE, IRNode.MUL, IRNode.DIV, IRNode.SUB})
>>     // Checks (x - x) => 0 and 0 - 0 => 0
>>     public int simpleZeroSub(int x) {
>>         return (x - x) + (x - x);
>>     }
>> 
>>     @Run(test = "simpleZeroSub")
>>     public void runSimpleZeroSub() { // Run methods are not compiled and thus run in interpreter
>>         // This getRandom() call is only supported once JDK-8272567 is in for which a PR is currently open.
>>         int x = RunInfo.getRandom().nextInt(); // Some random value 
>>         Asserts.assertEQ(0, simpleZeroSub(x)); // Result check done in interpreter
>>         x = Integer.MAX_VALUE; // Some edge value
>>         Asserts.assertEQ(0, simpleZeroSub(x));
>>         // ...
>>     }
>> 
>> It might not provide additional value for all your tests but I guess that some of these tests would benefit from additional result checking. I leave it up to you to decide where and if you want to apply these changes.
>
> Thank you @chhagedorn , I think this is a good idea. I'll follow your suggestion and transform some tests into `custom run tests`.

Great, thanks! Btw, you can merge and now use `RunInfo.getRandom().XX()` for a handy access to random values (if needed) as the PR for JDK-8272567 was integrated in the meantime.

-------------

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

From rbackman at openjdk.java.net  Fri Aug 20 09:18:21 2021
From: rbackman at openjdk.java.net (Rickard =?UTF-8?B?QsOkY2ttYW4=?=)
Date: Fri, 20 Aug 2021 09:18:21 GMT
Subject: RFR: 8269687: pauth_aarch64.hpp include name is incorrect
In-Reply-To: <mn_iAE8Z2n_DqxM1srOaitn7qJMnn1GCLb78b418jgw=.bc3fde65-3616-4223-b3b4-eb36aa125920@github.com>
References: <mn_iAE8Z2n_DqxM1srOaitn7qJMnn1GCLb78b418jgw=.bc3fde65-3616-4223-b3b4-eb36aa125920@github.com>
Message-ID: <Cc2VB22o4hjME1DlL5501L6uYZhMQ_haKauxGHa9bj8=.eb577522-ba3c-4f15-94af-42c32185db20@github.com>

On Fri, 20 Aug 2021 08:48:19 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> Quick fix to correct the include guards.

Marked as reviewed by rbackman (Reviewer).

-------------

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

From ngasson at openjdk.java.net  Fri Aug 20 10:07:24 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 20 Aug 2021 10:07:24 GMT
Subject: RFR: 8269687: pauth_aarch64.hpp include name is incorrect
In-Reply-To: <mn_iAE8Z2n_DqxM1srOaitn7qJMnn1GCLb78b418jgw=.bc3fde65-3616-4223-b3b4-eb36aa125920@github.com>
References: <mn_iAE8Z2n_DqxM1srOaitn7qJMnn1GCLb78b418jgw=.bc3fde65-3616-4223-b3b4-eb36aa125920@github.com>
Message-ID: <vL1IBbbwHjVywZOiirBxgnJJZpqAOZqwHLEUqw3DvlI=.49bd54ab-8415-4b33-8e81-eec997fcde7f@github.com>

On Fri, 20 Aug 2021 08:48:19 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> Quick fix to correct the include guards.

Marked as reviewed by ngasson (Reviewer).

-------------

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

From dnsimon at openjdk.java.net  Fri Aug 20 10:42:27 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Fri, 20 Aug 2021 10:42:27 GMT
Subject: RFR: 8272736: [JVMCI] Add API for reading and writing JVMCI
 thread locals [v2]
In-Reply-To: <Ug2gd6Ka0FnWzz3cEENZas7BO4XvGtRA3WJ4oSTB5FU=.2161022d-6c43-4fdf-ba1d-ef2ec1525087@github.com>
References: <2wNNn6-jgpJE9sKYjwaCt2R-GtD9qdCpkDJN2pq1Ras=.4154e88e-2047-4d85-990d-b774efdf148c@github.com>
 <Ug2gd6Ka0FnWzz3cEENZas7BO4XvGtRA3WJ4oSTB5FU=.2161022d-6c43-4fdf-ba1d-ef2ec1525087@github.com>
Message-ID: <aKwnctI_Ia_-2mbWsnW09zCvRoTkFJsDYwKsh4y4iCw=.c313aefa-3fcc-4dfe-8a7e-6e0463a41c45@github.com>

On Fri, 20 Aug 2021 05:23:49 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> 8272736: [JVMCI] Add API for reading and writing JVMCI thread locals
>
> Tom Rodriguez 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.

Marked as reviewed by dnsimon (Committer).

-------------

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

From eastig at amazon.co.uk  Fri Aug 20 10:54:53 2021
From: eastig at amazon.co.uk (Astigeevich, Evgeny)
Date: Fri, 20 Aug 2021 10:54:53 +0000
Subject: RFC: AArch64: Implementing spin pauses with ISB
Message-ID: <285C1B5E-B9FF-484C-A103-B7C2F9BF5269@amazon.com>

Thank you, Andrew and Stuart, for your comments. They are very useful. I'll be updating the implementation.


?On 19/08/2021, 08:34, "hotspot-dev on behalf of Andrew Haley" <hotspot-dev-retn at openjdk.java.net on behalf of aph-open at littlepinkcloud.com> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



    On 8/18/21 11:22 PM, Stuart Monteith wrote:
    > I don't think WFE will work for you - I found on at least one machine the cpu will pause more or less indefinitely.

    That's a shame. I thought it was specified to awaken when the exclusive monitor
    was cleared, which will happen when the exclusive location is written to, won't
    it?

    > The
    > SEV instruction may be a blunt weapon as it applies to all cores on the CPU.
    >
    > This discussion appears split between the Spin Pause review and this email thread, but the idea of the implementation
    > being switchable is appealing. Hypothetically the options might be NONE, NOP, ISB, YIELD. With the current semantics,
    > YIELD could be theoretically useful on SMT cores, but I don't know if that would change in the future to be applicable
    > more widely.

    Mmm, yes. I think it should be easy enough to make it switchable. I'd
    support that, I think.

    --
    Andrew Haley  (he/him)
    Java Platform Lead Engineer
    Red Hat UK Ltd. <https://www.redhat.com>
    https://keybase.io/andrewhaley
    EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671




Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.



From ludovic at datadoghq.com  Fri Aug 20 12:59:43 2021
From: ludovic at datadoghq.com (Ludovic Henry)
Date: Fri, 20 Aug 2021 14:59:43 +0200
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <CAFR8T3tSR-yA901Tskwt-OrZaeuupBfdUQ+r2y4gmsde1Sj=3w@mail.gmail.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
 <DGifHTg7nIn5v9jLtDHTWvj1SxNfv3DxVz5Y4FaRCxY=.7f279e15-526c-469b-8872-4504fde721bd@github.com>
 <CAFR8T3tSR-yA901Tskwt-OrZaeuupBfdUQ+r2y4gmsde1Sj=3w@mail.gmail.com>
Message-ID: <CAFR8T3t9EWN9sELWEymptaR5-NooGeFVRpO9oQdjYg3V__rJ2Q@mail.gmail.com>

[Sending again now with the email address properly registered to the
mailing lists]

Hello,

As it's been quite a while already, I wanted to nudge this RFR forward. Who
would be best qualified to review this PR?

Thank you!
Ludovic

On Fri, Aug 20, 2021 at 8:49 AM Ludovic Henry <ludovic at datadoghq.com> wrote:

> Hello,
>
> As it's been quite a while already, I wanted to nudge this RFR forward.
> Who would be best qualified to review this PR?
>
> Thank you!
> Ludovic
>
> On Wed, Aug 18, 2021 at 9:21 PM Marcus Hirt <hirt at openjdk.java.net> wrote:
>
>> On Mon, 19 Jul 2021 09:25:59 GMT, Ludovic Henry <luhenry at openjdk.org>
>> wrote:
>>
>> >> When the signal sent for AsyncGetCallTrace or JFR would land on a
>> runtime stub (like arraycopy), a vtable stub, or the prolog of a compiled
>> method,  it wouldn't be able to detect the sender (caller) frame for
>> multiple reasons. This patch fixes these cases through adding
>> CodeBlob-specific frame parser which are in the best position to know how a
>> frame is setup.
>> >>
>> >> The following examples have been profiled with honest-profiler which
>> uses `AsyncGetCallTrace`.
>> >>
>> >> # `Prof1`
>> >>
>> >> public class Prof1 {
>> >>
>> >>     public static void main(String[] args) {
>> >>         StringBuilder sb = new StringBuilder();
>> >>         for (int i = 0; i < 1000000; i++) {
>> >>             sb.append("ab");
>> >>             sb.delete(0, 1);
>> >>         }
>> >>         System.out.println(sb.length());
>> >>     }
>> >> }
>> >>
>> >>
>> >> - Baseline:
>> >>
>> >> Flat Profile (by method):
>> >>         (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>> >>         (t  0.5,s  0.2) Prof1::main
>> >>         (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>> >>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>> >>         (t  0.0,s  0.0)
>> java.lang.AbstractStringBuilder::ensureCapacityInternal
>> >>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>> >>         (t  0.0,s  0.0) java.lang.String::getBytes
>> >>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>> >>         (t  0.0,s  0.0) java.lang.StringBuilder::delete
>> >>         (t  0.2,s  0.0) java.lang.StringBuilder::append
>> >>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>> >>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>> >>
>> >> - With `StubRoutinesBlob::FrameParser`:
>> >>
>> >> Flat Profile (by method):
>> >>         (t 98.7,s 98.7)
>> java.lang.AbstractStringBuilder::ensureCapacityInternal
>> >>         (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>> >>         (t 99.8,s  0.2) Prof1::main
>> >>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>> >>         (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>> >>         (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>> >>         (t 98.8,s  0.0) java.lang.StringBuilder::append
>> >>         (t  0.9,s  0.0) java.lang.StringBuilder::delete
>> >>
>> >>
>> >> # `Prof2`
>> >>
>> >> import java.util.function.Supplier;
>> >>
>> >> public class Prof2 {
>> >>
>> >>     public static void main(String[] args) {
>> >>         var rand = new java.util.Random(0);
>> >>         Supplier[] suppliers = {
>> >>                 () -> 0,
>> >>                 () -> 1,
>> >>                 () -> 2,
>> >>                 () -> 3,
>> >>         };
>> >>
>> >>         long sum = 0;
>> >>         for (int i = 0; i >= 0; i++) {
>> >>             sum += (int)suppliers[i % suppliers.length].get();
>> >>         }
>> >>     }
>> >> }
>> >>
>> >>
>> >> - Baseline:
>> >>
>> >> Flat Profile (by method):
>> >>         (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>> >>         (t 39.2,s 35.2) Prof2::main
>> >>         (t  1.4,s  1.4) Prof2::lambda$main$3
>> >>         (t  1.0,s  1.0) Prof2::lambda$main$2
>> >>         (t  0.9,s  0.9) Prof2::lambda$main$1
>> >>         (t  0.7,s  0.7) Prof2::lambda$main$0
>> >>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>> >>         (t  0.0,s  0.0) java.lang.Thread::exit
>> >>         (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>> >>         (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>> >>         (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>> >>         (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
>> >>
>> >>
>> >> - With `VtableBlob::FrameParser` and `nmethod::FrameParser`:
>> >>
>> >> Flat Profile (by method):
>> >>         (t 74.1,s 70.3) Prof2::main
>> >>         (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>> >>         (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>> >>         (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>> >>         (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>> >>         (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>> >>         (t  1.2,s  1.2) Prof2::lambda$main$2
>> >>         (t  0.9,s  0.9) Prof2::lambda$main$3
>> >>         (t  0.9,s  0.9) Prof2::lambda$main$1
>> >>         (t  0.7,s  0.7) Prof2::lambda$main$0
>> >>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>> >
>> > Ludovic Henry has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains eight
>> additional commits since the last revision:
>> >
>> >  - Remove FrameParser and the required allocation
>> >
>> >    The need for the allocation would be it non async-safe. However,
>> >    AsyncGetCallTrace is async-safe and thus can't allow for allocations.
>> >  - Merge branch 'master' of https://github.com/openjdk/jdk into
>> fix-8178287
>> >  - Fix comments
>> >  - Disable checks in FrameParser when known to be safe
>> >  - Allow AsyncGetCallTrace and JFR to unwind stack from vtable stub
>> >
>> >    The program is the following:
>> >
>> >    ```
>> >    import java.util.function.Supplier;
>> >
>> >    public class Prof2 {
>> >
>> >        public static void main(String[] args) {
>> >            var rand = new java.util.Random(0);
>> >            Supplier[] suppliers = {
>> >                    () -> 0,
>> >                    () -> 1,
>> >                    () -> 2,
>> >                    () -> 3,
>> >            };
>> >
>> >            long sum = 0;
>> >            for (int i = 0; i >= 0; i++) {
>> >                sum += (int)suppliers[i % suppliers.length].get();
>> >            }
>> >        }
>> >    }
>> >    ```
>> >
>> >    The results are as follows:
>> >
>> >    - Baseline (from previous commit):
>> >
>> >    Flat Profile (by method):
>> >                (t 39.3,s 39.3) AGCT::Unknown Java[ERR=-5]
>> >                (t 40.3,s 36.1) Prof2::main
>> >                (t  6.4,s  5.3) Prof2$$Lambda$28.0x0000000800081000::get
>> >                (t  6.1,s  5.1) Prof2$$Lambda$29.0x0000000800081220::get
>> >                (t  6.0,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>> >                (t  6.1,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>> >                (t  1.1,s  1.1) Prof2::lambda$main$2
>> >                (t  1.1,s  1.1) Prof2::lambda$main$0
>> >                (t  1.0,s  1.0) Prof2::lambda$main$1
>> >                (t  0.9,s  0.9) Prof2::lambda$main$3
>> >                (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>> >
>> >    - With unwind from vtable stub
>> >
>> >    Flat Profile (by method):
>> >            (t 74.1,s 70.3) Prof2::main
>> >            (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>> >            (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>> >            (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>> >            (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>> >            (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>> >            (t  1.2,s  1.2) Prof2::lambda$main$2
>> >            (t  0.9,s  0.9) Prof2::lambda$main$3
>> >            (t  0.9,s  0.9) Prof2::lambda$main$1
>> >            (t  0.7,s  0.7) Prof2::lambda$main$0
>> >            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>> >
>> >    We attribute the vtable stub to the caller and not the callee, which
>> is
>> >    already an improvement from the existing case.
>> >  - Allow AsyncGetCallTrace and JFR to unwind stack from nmethod's prolog
>> >
>> >    When sampling hits the prolog of a method, Hotspot assumes it's
>> unable
>> >    to parse the frame. This change allows to parse such frame on x86 by
>> >    specializing which instruction it's hitting in the prolog.
>> >
>> >    The results are as follows:
>> >
>> >    - Baseline:
>> >
>> >    Flat Profile (by method):
>> >            (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>> >            (t 39.2,s 35.2) Prof2::main
>> >            (t  1.4,s  1.4) Prof2::lambda$main$3
>> >            (t  1.0,s  1.0) Prof2::lambda$main$2
>> >            (t  0.9,s  0.9) Prof2::lambda$main$1
>> >            (t  0.7,s  0.7) Prof2::lambda$main$0
>> >            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>> >            (t  0.0,s  0.0) java.lang.Thread::exit
>> >            (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>> >            (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>> >            (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>> >            (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
>> >
>> >    - With incomplete frame parsing:
>> >
>> >    Flat Profile (by method):
>> >            (t 39.3,s 39.3) AGCT::Unknown Java[ERR=-5]
>> >            (t 40.3,s 36.1) Prof2::main
>> >            (t  6.4,s  5.3) Prof2$$Lambda$28.0x0000000800081000::get
>> >            (t  6.1,s  5.1) Prof2$$Lambda$29.0x0000000800081220::get
>> >            (t  6.0,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>> >            (t  6.1,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>> >            (t  1.1,s  1.1) Prof2::lambda$main$2
>> >            (t  1.1,s  1.1) Prof2::lambda$main$0
>> >            (t  1.0,s  1.0) Prof2::lambda$main$1
>> >            (t  0.9,s  0.9) Prof2::lambda$main$3
>> >            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>> >            (t  0.0,s  0.0) java.util.Locale::getInstance
>> >            (t  0.0,s  0.0) AGCT::Not walkable Java[ERR=-6]
>> >            (t  0.0,s  0.0)
>> jdk.internal.loader.BuiltinClassLoader::loadClassOrNull
>> >            (t  0.0,s  0.0) java.lang.ClassLoader::loadClass
>> >            (t  0.0,s  0.0) sun.net.util.URLUtil::urlNoFragString
>> >            (t  0.0,s  0.0) java.lang.Class::forName0
>> >            (t  0.0,s  0.0) java.util.Locale::initDefault
>> >            (t  0.0,s  0.0)
>> jdk.internal.loader.BuiltinClassLoader::loadClass
>> >            (t  0.0,s  0.0) jdk.internal.loader.URLClassPath::getLoader
>> >            (t  0.0,s  0.0) jdk.internal.loader.URLClassPath::getResource
>> >            (t  0.0,s  0.0) java.lang.String::toLowerCase
>> >            (t  0.0,s  0.0) sun.launcher.LauncherHelper::loadMainClass
>> >            (t  0.0,s  0.0) sun.launcher.LauncherHelper::checkAndLoadMain
>> >            (t  0.0,s  0.0) java.util.Locale::<clinit>
>> >            (t  0.0,s  0.0)
>> jdk.internal.loader.BuiltinClassLoader::findClassOnClassPathOrNull
>> >            (t  0.0,s  0.0)
>> jdk.internal.loader.ClassLoaders$AppClassLoader::loadClass
>> >            (t  0.0,s  0.0) java.lang.Class::forName
>> >
>> >    The program is as follows:
>> >
>> >    ```
>> >    import java.util.function.Supplier;
>> >
>> >    public class Prof2 {
>> >
>> >        public static void main(String[] args) {
>> >            var rand = new java.util.Random(0);
>> >            Supplier[] suppliers = {
>> >                    () -> 0,
>> >                    () -> 1,
>> >                    () -> 2,
>> >                    () -> 3,
>> >            };
>> >
>> >            long sum = 0;
>> >            for (int i = 0; i >= 0; i++) {
>> >                sum += (int)suppliers[i % suppliers.length].get();
>> >            }
>> >        }
>> >    }
>> >    ```
>> >
>> >    We see that the results are particularely useful in this case as the
>> >    methods are very short (it only returns an integer), and the
>> probability
>> >    of hitting the prolog is then very high.
>> >  - Allow AsyncGetCallTrace and JFR to walk a stub frame
>> >
>> >    When the signal sent for AsyncGetCallTrace or JFR would land on a
>> stub
>> >    (like arraycopy), it wouldn't be able to detect the sender (caller)
>> >    frame because `_cb->frame_size() == 0`.
>> >
>> >    Because we fully control how the prolog and epilog of stub code is
>> >    generated, we know there are two cases:
>> >    1. A stack frame is allocated via macroAssembler->enter(), and
>> consists
>> >    in `push rbp; mov rsp, rbp;`.
>> >    2. No stack frames are allocated and rbp is left unchanged and rsp is
>> >    decremented with the `call` instruction that push the return `pc` on
>> the
>> >    stack.
>> >
>> >    For case 1., we can easily know the sender frame by simply looking at
>> >    rbp, especially since we know that all stubs preserve the frame
>> pointer
>> >    (on x86 at least).
>> >
>> >    For case 2., we end up returning the sender's sender, but that
>> already
>> >    gives us more information than what we have today.
>> >
>> >    The results are as follows:
>> >
>> >    - Baseline:
>> >
>> >    Flat Profile (by method):
>> >            (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>> >            (t  0.5,s  0.2) Prof1::main
>> >            (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>> >            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>> >            (t  0.0,s  0.0)
>> java.lang.AbstractStringBuilder::ensureCapacityInternal
>> >            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>> >            (t  0.0,s  0.0) java.lang.String::getBytes
>> >            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>> >            (t  0.0,s  0.0) java.lang.StringBuilder::delete
>> >            (t  0.2,s  0.0) java.lang.StringBuilder::append
>> >            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>> >            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>> >
>> >    - With StubRoutinesBlob::FrameParser
>> >
>> >    Flat Profile (by method):
>> >            (t 98.7,s 98.7)
>> java.lang.AbstractStringBuilder::ensureCapacityInternal
>> >            (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>> >            (t 99.8,s  0.2) Prof1::main
>> >            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>> >            (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>> >            (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>> >            (t 98.8,s  0.0) java.lang.StringBuilder::append
>> >            (t  0.9,s  0.0) java.lang.StringBuilder::delete
>> >
>> >    The program is as follows:
>> >
>> >    ```
>> >    public class Prof1 {
>> >
>> >        public static void main(String[] args) {
>> >            StringBuilder sb = new StringBuilder();
>> >            for (int i = 0; i < 1000000; i++) {
>> >                sb.append("ab");
>> >                sb.delete(0, 1);
>> >            }
>> >            System.out.println(sb.length());
>> >        }
>> >    }
>> >    ```
>> >
>> >    We now account for the arraycopy stub which is called by
>> >    AbstractStringBuilder::ensureCapacityInternal. It was previously
>> ignored
>> >    because it would not know how to parse the frame for the arraycopy
>> stub
>> >    and would fall in the AGCT::Unknown Java[ERR=-5] section.
>> >
>> >    However, it still isn't perfect since it doesn't point to the
>> arraycopy stub
>> >    directly.
>> >  - Extract sender frame parsing to CodeBlock::FrameParser
>> >
>> >    Whether and how a frame is setup is controlled by the code generator
>> >    for the specific CodeBlock. The CodeBlock is then in the best place
>> to know how
>> >    to parse the sender's frame from the current frame in the given
>> CodeBlock.
>> >
>> >    This refactoring proposes to extract this parsing out of `frame` and
>> into a
>> >    `CodeBlock::FrameParser`. This FrameParser is then specialized in
>> the relevant
>> >    inherited children of CodeBlock.
>> >
>> >    This change is to largely facilitate adding new supported cases for
>> JDK-8252417
>> >    like runtime stubs.
>>
>> Ok. Do you know who should be the primary reviewer? Rickard B?ckman? Nils
>> Eliasson?
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/4436
>>
>

From ayang at openjdk.java.net  Fri Aug 20 13:37:34 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 20 Aug 2021 13:37:34 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
Message-ID: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>

Simple change of merging `is_instance` and `is_instance_inlined`.

Test: build

-------------

Commit messages:
 - inline

Changes: https://git.openjdk.java.net/jdk/pull/5201/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5201&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272778
  Stats: 14 lines in 9 files changed: 0 ins; 4 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5201.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5201/head:pull/5201

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

From redestad at openjdk.java.net  Fri Aug 20 14:19:21 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 20 Aug 2021 14:19:21 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
In-Reply-To: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
Message-ID: <iHf3PiQ0Cf3NZJmwyHjHIrq2gVYAZRi4nMYN8pQmJGM=.b0a86042-0fbf-4dbc-b1c4-df04bcfa172b@github.com>

On Fri, 20 Aug 2021 13:31:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of merging `is_instance` and `is_instance_inlined`.
> 
> Test: build

It seems the split between `is_instance` and `is_instance_inlined` was introduced recently (5314d28f8412e9c993880884a3b626f05b590743) and I think the point to actively opt-out of inlining in performance-insensitive places (also makes the generated code a bit less noisy and easier to debug, by some accounts). 

Since it was done intentionally I'd check we don't lose something by consolidating these into a single inlined version. E.g. measure that the static size of libjvm doesn't grow by much.

-------------

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

From coleenp at openjdk.java.net  Fri Aug 20 15:24:24 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 20 Aug 2021 15:24:24 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
In-Reply-To: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
Message-ID: <BzNn4LDLe5I7717pVPBp8aPOmqNMoKvtLJNItwZjJQE=.a8c3e232-bf98-4967-a967-9da2f105d208@github.com>

On Fri, 20 Aug 2021 13:31:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of merging `is_instance` and `is_instance_inlined`.
> 
> Test: build

src/hotspot/share/classfile/javaClasses.inline.hpp line 126:

> 124: }
> 125: 
> 126: bool java_lang_String::is_instance(oop obj) {

I don't really see anything wrong with this.  is_instance() is called above in asserts but that shouldn't affect performance by increasing the size of generated code.

-------------

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

From coleenp at openjdk.java.net  Fri Aug 20 15:27:23 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 20 Aug 2021 15:27:23 GMT
Subject: RFR: 8272736: [JVMCI] Add API for reading and writing JVMCI
 thread locals [v2]
In-Reply-To: <5sCO9mXPcTK8KJKFbTBCRBofKJ9iK9B6pDNe0XD3r7Y=.7b2d2db6-97e7-4cf2-aed7-49a2c915dd0e@github.com>
References: <2wNNn6-jgpJE9sKYjwaCt2R-GtD9qdCpkDJN2pq1Ras=.4154e88e-2047-4d85-990d-b774efdf148c@github.com>
 <qo8Dhnw_p8q4Dq5OGztnK5XYLGNgxIb2AX816EzJevw=.3aec804f-efa0-4171-b365-de042161b9e3@github.com>
 <5sCO9mXPcTK8KJKFbTBCRBofKJ9iK9B6pDNe0XD3r7Y=.7b2d2db6-97e7-4cf2-aed7-49a2c915dd0e@github.com>
Message-ID: <u_DLSq2_2JcNIOqK_VmDE7Xtv2qbUdlXFEKcy8Uu97s=.a1a00f64-fe19-4004-ac45-2faf70080e6b@github.com>

On Fri, 20 Aug 2021 04:45:31 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.hpp line 961:
>> 
>>> 959: 
>>> 960:   // Fast thread locals for use by JVMCI
>>> 961:   jlong      _jvmci_reserved0;
>> 
>> Update: please ignore (hit wrong button) I now see this coming from Java.
>> 
>> We are trying to avoid use of Java types in code that does not directly interact with Java. Does this really need to be a jlong or does it just need to be 64-bit? Or does it need to be the same size as a ptr whatever that may be?
>
> Yes that's right.  Since it's now exposed through Java it really needs to be a Java compatible type.

I had that same thought but I agree with Tom.  We want a Java type here.

-------------

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

From coleenp at openjdk.java.net  Fri Aug 20 15:27:24 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 20 Aug 2021 15:27:24 GMT
Subject: RFR: 8272736: [JVMCI] Add API for reading and writing JVMCI
 thread locals [v2]
In-Reply-To: <Ug2gd6Ka0FnWzz3cEENZas7BO4XvGtRA3WJ4oSTB5FU=.2161022d-6c43-4fdf-ba1d-ef2ec1525087@github.com>
References: <2wNNn6-jgpJE9sKYjwaCt2R-GtD9qdCpkDJN2pq1Ras=.4154e88e-2047-4d85-990d-b774efdf148c@github.com>
 <Ug2gd6Ka0FnWzz3cEENZas7BO4XvGtRA3WJ4oSTB5FU=.2161022d-6c43-4fdf-ba1d-ef2ec1525087@github.com>
Message-ID: <FJIXpoEfIfba_hq0LdZLQ1bUeiXUEy2WebyW66VIhAk=.7b3b3e30-3d5b-4118-b839-4944d18f469e@github.com>

On Fri, 20 Aug 2021 05:23:49 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> 8272736: [JVMCI] Add API for reading and writing JVMCI thread locals
>
> Tom Rodriguez 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:
> 
>   8272736: [JVMCI] Add API for reading and writing JVMCI thread locals

src/hotspot/share/runtime/thread.hpp line 996:

> 994:     return _jvmci_reserved1;
> 995:   }
> 996: 

This makes me reprise my wish that this code was in jvmciThread.hpp and you indirect from thread to there.  Can you do that?  There's already an RFE somewhere.

-------------

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

From coleenp at openjdk.java.net  Fri Aug 20 16:48:41 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 20 Aug 2021 16:48:41 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be safepoint_check_never
Message-ID: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>

I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
Tested with tier1-3.  Tier 4-6 testing in progress.

-------------

Commit messages:
 - 8272788: Nonleaf ranked locks should not be safepoint_check_neve

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

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

From scott.gibbons at intel.com  Fri Aug 20 16:49:56 2021
From: scott.gibbons at intel.com (Gibbons, Scott)
Date: Fri, 20 Aug 2021 16:49:56 +0000
Subject: RFC: x86_64: Fixing the align() macro
In-Reply-To: <bd46f335-a977-3679-8cc5-d39a5b391db6@oracle.com>
References: <CY4PR11MB00372DFF085FDF1ECEC8E705E2C19@CY4PR11MB0037.namprd11.prod.outlook.com>
 <bd46f335-a977-3679-8cc5-d39a5b391db6@oracle.com>
Message-ID: <CY4PR11MB0037C15CE06EDF928B1BA33DE2C19@CY4PR11MB0037.namprd11.prod.outlook.com>

Thanks, Dean, for the comments.  I'm relatively new to this codebase and admittedly don't know the details, but the compromise you're suggesting seems like a lot of added complexity for a savings of ~16 bytes per code segment.  Let me explain, and you can point out where I misunderstand.

The align() is used to manipulate the address bits of the data that follows in order to meet architectural requirements or performance.  So if we copy one code buffer to another with different moduli of starting addresses (i.e., addr % 64 == 0 to addr % 64 != 0) it would seem to me that structures within the code buffer with 64-bit alignment requirements would need to be moved such that their addresses are correct for the architecture.  This means that padding will need to be added or removed within the code buffer to account for the different address alignments.  This would also necessitate fixups to all instructions which use the address (say, as a literal).  Adding or removing padding also has the effect of moving all other data at higher addresses which cascades the effect.  There may be enough information available to make all these fixups, but this seems to be an extraordinary amount of effort and highly error prone.

It feels more straightforward to me to sacrifice the address space than attack this complexity.  Are we really so tight on address space?  We could limit this to 64-bit architectures, if that would help.

Thanks,
--Scott Gibbons
Software Development Engineer, Runtime Engineering
  DEVELOPER SOFTWARE ENGINEERING
Ph: 1-503-456-7756
Cell: 1-469-450-8390
2501 NE Century Blvd
Hillsboro, OR 97124
Intel Corporation | www.intel.com

-----Original Message-----
From: hotspot-dev <hotspot-dev-retn at openjdk.java.net> On Behalf Of dean.long at oracle.com
Sent: Thursday, August 19, 2021 6:54 PM
To: hotspot-dev at openjdk.java.net
Subject: Re: RFC: x86_64: Fixing the align() macro

Hi Scott,

On 8/19/21 5:10 PM, Gibbons, Scott wrote:
> Hi, everyone.  This is my first post to this forum, so please let me know if this type of discussion is welcome here, and an alternative forum if it's not :).
>
> I ran into an issue where align(64) breaks on the x86_64 platform within stubGenerator_x86_64.cpp.  I would like input on a fix *AND* how the community would like to see it tested.
>
> There are occasions where I need to align certain data to a 64-byte boundary for AVX-512 aligned instructions.  The issue that I uncovered was that the single-parameter align(int modulus) would sometimes not align properly with align(64).  Unwinding this, I found that align(int modulus) calls align(int modulus, int target) with the target parameter as offset() (i.e., align(modulus, offset());).  Further exploration showed that offset() was 'return _end - _start', which is effectively the size of the code segment and not the offset of the PC.  So align(64) would align the PC to a multiple of 64 bytes from the start of the segment, and not to a pure 64-byte boundary as requested.
>
> The workaround that I implemented was to use the two-parameter version of align(), passing pc() as the target.  This fixed the specific issue I was encountering, and now I'd like to implement a general solution.


The problem with using pc() is when the code buffer gets copied to a different location.


> One solution would be to change the single-parameter align() to use pc() instead of offset() in the call to the two-parameter align() function.  I believe this would solve the issue, however the single-parameter align() is used very frequently, and I'd like to minimize the number of potential issues this change could trigger.
>
> The second solution (my preferred) is to change the allocation alignment of code segments to 64-bytes.  This would effectively make the size equivalent to the PC for purposes of the modular arithmetic for alignment.  That is, _start % 64 is zero, so (_end - _start) % 64 is equivalent to (_end % 64), achieving the desired result.


The disadvantage to this is wasting space when extra alignment isn't 
needed.? How about the following compromise:

1. keep the default alignment as 32 bytes

2. keep using offset() for alignment

3. if align(x) is used with x > default allocation alignment (32), then 
make a note of that in the code buffer

4. if the code buffer is copied, use the max required alignment from 3) 
and the PC of the old code buffer to compute the required allocation 
alignment of the new code buffer.? For align(64), no adjustment would be 
needed 50% of the time.

dl


> I would really like to hear others' opinions and possible alternative approaches.  I'm also not sure how this change would affect relocation, so I'd like to hear that as well.
>
> I also would like to know how the community would approach creating an appropriate test for this to be included in the regression suites.
>
> Thanks,
> --Scott Gibbons
> Software Development Engineer, Runtime Engineering
> [cid:image003.jpg at 01D7951D.0C49EAC0]  DEVELOPER SOFTWARE ENGINEERING
> Ph: 1-503-456-7756
> Cell: 1-469-450-8390
> 2501 NE Century Blvd
> Hillsboro, OR 97124
> Intel Corporation | www.intel.com<https://webmail.intel.com/owa/redir.aspx?SURL=WYr7qZDpIv3m1SKFmeHJuzsfCBuGN-jwkBYQUSRR6yrupkscpgzUCGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAG4AdABlAGwALgBjAG8AbQA.&URL=http%3a%2f%2fwww.intel.com>
>

From xliu at openjdk.java.net  Fri Aug 20 17:32:25 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 20 Aug 2021 17:32:25 GMT
Subject: RFR: 8264707: HotSpot Style Guide should permit use of lambda
In-Reply-To: <ClF_S5jjfQ911hsUdbxKkaXjVyJ1euXgkDT8JB5fkSs=.42f08fe5-abd8-4839-858b-036e3012ba6b@github.com>
References: <ClF_S5jjfQ911hsUdbxKkaXjVyJ1euXgkDT8JB5fkSs=.42f08fe5-abd8-4839-858b-036e3012ba6b@github.com>
Message-ID: <I77VX0YVaoi1uXeTpzBoKx-R2DFoqV4UtHtW5txjYmw=.bb9e11ac-30d4-49e0-b43d-dedabb5e472c@github.com>

On Tue, 17 Aug 2021 13:49:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this proposal to permit the use of lambda expressions in
> HotSpot code, with some restrictions and suggestions for good usage within
> HotSpot code.  Lambda expressions were added in C++11, and provide a more
> expressive syntax for local functions, with a number of use-cases where they
> can improve readability by eliminating a lot of uninteresting boilerplate.
> 
> Some example uses are included, but are not part of the proposed change.
> They will be removed from the PR before it is pushed.  (In particular, the
> ScopeGuard utility uses move semantics, the use of which hasn't been
> approved or even discussed.)  They are given to show some of the benefits
> that might accrue from permitting the use of lambdas. In particular, they
> highlight some of the code reduction that is possible. Some of these code
> changes might be proposed in the future, using the normal PR process.
> 
> This is a modification of the Style Guide, so rough consensus among the
> HotSpot Group members is required to make this change.  Only Group members
> should vote for approval (via the github PR), though reasoned objections or
> comments from anyone will be considered.  A decision on this proposal will
> not be made before Wednesday 1-Sep-2021 at 12h00 UTC.
> 
> Since we're piggybacking on github PRs here, please use the PR review
> process to approve (click on Review Changes > Approve), rather than sending
> a "vote: yes" email reply that would be normal for a CFV.

doc/hotspot-style.md line 708:

> 706: * Local function objects, including lambda expressions, may be used.
> 707: * Lambda expressions must only be used as a downward value.
> 708: * Prefer `[&]` as the capture list of a lambda expression.

hi, @kimbarrett , 
Why does it sound like a suggestion instead of a mandate? 
You explain why we should use [&] and all your examples are implicit capture reference.

-------------

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

From ayang at openjdk.java.net  Fri Aug 20 18:24:28 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 20 Aug 2021 18:24:28 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
In-Reply-To: <iHf3PiQ0Cf3NZJmwyHjHIrq2gVYAZRi4nMYN8pQmJGM=.b0a86042-0fbf-4dbc-b1c4-df04bcfa172b@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
 <iHf3PiQ0Cf3NZJmwyHjHIrq2gVYAZRi4nMYN8pQmJGM=.b0a86042-0fbf-4dbc-b1c4-df04bcfa172b@github.com>
Message-ID: <dj7A-OjMV6aOOISqvf68m8zKjHidhJyuc_KuPEN7HjA=.ee305dcd-7044-42df-8bb4-079c9356ecf7@github.com>

On Fri, 20 Aug 2021 14:15:59 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> It seems the split between is_instance and is_instance_inlined was introduced recently (5314d28)

I believe the split was introduced in [8072911: Remove includes of oop.inline.hpp from .hpp files](https://github.com/openjdk/jdk/commit/4913ad5d7dcc8ae4e034aa110a97ea8313b2b3ee) to address potential circular dependencies.

> measure that the static size of libjvm doesn't grow by much.

Before:


ls -l build/*/images/jdk/lib/server/libjvm.so
-rw-r--r-- 1 albert albert 213664560 Aug 20 19:01 build/linux-x64-debug/images/jdk/lib/server/libjvm.so
-rw-r--r-- 1 albert albert  24243456 Aug 20 19:11 build/linux-x64-release/images/jdk/lib/server/libjvm.so


After:


ls -l build/*/images/jdk/lib/server/libjvm.so
-rw-r--r-- 1 albert albert 213727136 Aug 20 19:12 build/linux-x64-debug/images/jdk/lib/server/libjvm.so
-rw-r--r-- 1 albert albert  24247552 Aug 20 19:12 build/linux-x64-release/images/jdk/lib/server/libjvm.so


In summary:

for fastdebug: 213664560 -> 213727136, +62576 bytes, +0.03%
for release: 24243456 -> 24247552, +4096 bytes, +0.02%

-------------

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

From ayang at openjdk.java.net  Fri Aug 20 18:24:30 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 20 Aug 2021 18:24:30 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
In-Reply-To: <BzNn4LDLe5I7717pVPBp8aPOmqNMoKvtLJNItwZjJQE=.a8c3e232-bf98-4967-a967-9da2f105d208@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
 <BzNn4LDLe5I7717pVPBp8aPOmqNMoKvtLJNItwZjJQE=.a8c3e232-bf98-4967-a967-9da2f105d208@github.com>
Message-ID: <J6afu4W5Vo8H-R1cu7vRXoeGJtpF0P-ADvMNykVMiyc=.6c04d601-7ffb-4310-8b09-50c124c56eae@github.com>

On Fri, 20 Aug 2021 15:20:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Simple change of merging `is_instance` and `is_instance_inlined`.
>> 
>> Test: build
>
> src/hotspot/share/classfile/javaClasses.inline.hpp line 126:
> 
>> 124: }
>> 125: 
>> 126: bool java_lang_String::is_instance(oop obj) {
> 
> I don't really see anything wrong with this.  is_instance() is called above in asserts but that shouldn't affect performance by increasing the size of generated code.

`is_instance()` is called in non-assertion code as well, e.g. `ConstantPool::add_dumped_interned_strings`. By merging the two versions, one wouldn't use the potentially slower version by accident, and it's also more consistent with `is_instance` of other classes (e.g. `java_lang_Class`) in the same file.

-------------

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

From redestad at openjdk.java.net  Fri Aug 20 19:12:23 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 20 Aug 2021 19:12:23 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
In-Reply-To: <J6afu4W5Vo8H-R1cu7vRXoeGJtpF0P-ADvMNykVMiyc=.6c04d601-7ffb-4310-8b09-50c124c56eae@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
 <BzNn4LDLe5I7717pVPBp8aPOmqNMoKvtLJNItwZjJQE=.a8c3e232-bf98-4967-a967-9da2f105d208@github.com>
 <J6afu4W5Vo8H-R1cu7vRXoeGJtpF0P-ADvMNykVMiyc=.6c04d601-7ffb-4310-8b09-50c124c56eae@github.com>
Message-ID: <rUn_fQvPClB4ACP81NE56uXif52bWulw-B614d5Ab8Q=.4e50fdda-bff4-41a4-b6be-5f97ea3ae9ca@github.com>

On Fri, 20 Aug 2021 18:20:57 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.inline.hpp line 126:
>> 
>>> 124: }
>>> 125: 
>>> 126: bool java_lang_String::is_instance(oop obj) {
>> 
>> I don't really see anything wrong with this.  is_instance() is called above in asserts but that shouldn't affect performance by increasing the size of generated code.
>
> `is_instance()` is called in non-assertion code as well, e.g. `ConstantPool::add_dumped_interned_strings`. By merging the two versions, one wouldn't use the potentially slower version by accident, and it's also more consistent with `is_instance` of other classes (e.g. `java_lang_Class`) in the same file.

While `ConstantPool::add_dumped_interned_strings` might be an example of something that's not performance sensitive (even with dynamic CDS), the 0.02%/4Kb static size increase is less than concerning. Thanks for checking!

-------------

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

From coleenp at openjdk.java.net  Fri Aug 20 19:35:27 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 20 Aug 2021 19:35:27 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
In-Reply-To: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
Message-ID: <-v-YxlutPfjTiwZXazD1wN5ksWkVlkGqCa2Oe4cNYfM=.11450c35-a870-466f-b5fe-987b1c6cbb05@github.com>

On Fri, 20 Aug 2021 13:31:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of merging `is_instance` and `is_instance_inlined`.
> 
> Test: build

Looks good! Thanks for checking for the non-inlined version of is_instance.

-------------

Marked as reviewed by coleenp (Reviewer).

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

From redestad at openjdk.java.net  Fri Aug 20 19:41:26 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 20 Aug 2021 19:41:26 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
In-Reply-To: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
Message-ID: <CIzxUnx85HAmevygZLQ0zK7qMmamG9spgwQhpTWOihc=.de53e41c-5ed4-4b57-87cb-177352a54975@github.com>

On Fri, 20 Aug 2021 13:31:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of merging `is_instance` and `is_instance_inlined`.
> 
> Test: build

FWIW this looks good to me too. ????

-------------

Marked as reviewed by redestad (Reviewer).

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

From svkamath at openjdk.java.net  Fri Aug 20 22:43:55 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Fri, 20 Aug 2021 22:43:55 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v12]
In-Reply-To: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
Message-ID: <zFyCyUjEg9tNFEzslX1ZLt97hCKkdoxNk9ciNloCabU=.fdbd5340-908a-49bf-b6b7-7ee17f2407ab@github.com>

> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
> Performance gain of ~1.5x - 2x for message sizes 8k and above.

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

  changes to make sure that ghash_long_swap_mask and counter_mask_addr calls are not duplicated

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4019/files
  - new: https://git.openjdk.java.net/jdk/pull/4019/files/94e46aae..c31bfe9a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=10-11

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

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

From kvn at openjdk.java.net  Sat Aug 21 00:44:36 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 21 Aug 2021 00:44:36 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v12]
In-Reply-To: <zFyCyUjEg9tNFEzslX1ZLt97hCKkdoxNk9ciNloCabU=.fdbd5340-908a-49bf-b6b7-7ee17f2407ab@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <zFyCyUjEg9tNFEzslX1ZLt97hCKkdoxNk9ciNloCabU=.fdbd5340-908a-49bf-b6b7-7ee17f2407ab@github.com>
Message-ID: <uFGsqRswsg7i2NP15tJr65Isulr-_BpL2WsgpZ5EJV8=.1d526ba3-2a31-4e03-b456-b309a3e0e5c3@github.com>

On Fri, 20 Aug 2021 22:43:55 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes to make sure that ghash_long_swap_mask and counter_mask_addr calls are not duplicated

Good.

I will test it.

-------------

Marked as reviewed by kvn (Reviewer).

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

From dean.long at oracle.com  Sat Aug 21 00:51:35 2021
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Fri, 20 Aug 2021 17:51:35 -0700
Subject: [External] : RE: RFC: x86_64: Fixing the align() macro
In-Reply-To: <CY4PR11MB0037C15CE06EDF928B1BA33DE2C19@CY4PR11MB0037.namprd11.prod.outlook.com>
References: <CY4PR11MB00372DFF085FDF1ECEC8E705E2C19@CY4PR11MB0037.namprd11.prod.outlook.com>
 <bd46f335-a977-3679-8cc5-d39a5b391db6@oracle.com>
 <CY4PR11MB0037C15CE06EDF928B1BA33DE2C19@CY4PR11MB0037.namprd11.prod.outlook.com>
Message-ID: <2b389666-a268-41f4-6d72-46c7278ff566@oracle.com>

On 8/20/21 9:49 AM, Gibbons, Scott wrote:

> So if we copy one code buffer to another with different moduli of starting addresses

Sorry if I wasn't clear.? The idea is to make sure the destination code 
buffer has the same alignment as the source.? Any padding would be 
adding when the code buffer is allocated (which is why I said 
"allocation alignment"), not for individual instructions.

dl


From kbarrett at openjdk.java.net  Sat Aug 21 07:10:29 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 21 Aug 2021 07:10:29 GMT
Subject: RFR: 8264707: HotSpot Style Guide should permit use of lambda
In-Reply-To: <I77VX0YVaoi1uXeTpzBoKx-R2DFoqV4UtHtW5txjYmw=.bb9e11ac-30d4-49e0-b43d-dedabb5e472c@github.com>
References: <ClF_S5jjfQ911hsUdbxKkaXjVyJ1euXgkDT8JB5fkSs=.42f08fe5-abd8-4839-858b-036e3012ba6b@github.com>
 <I77VX0YVaoi1uXeTpzBoKx-R2DFoqV4UtHtW5txjYmw=.bb9e11ac-30d4-49e0-b43d-dedabb5e472c@github.com>
Message-ID: <DZLISTTb2aNASmgYX8t60Ksy4tBlxAmvDrLhDP5nIaM=.3a090aaa-24f0-4d33-beb3-9bfc1aee4ae8@github.com>

On Fri, 20 Aug 2021 17:29:12 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Please review this proposal to permit the use of lambda expressions in
>> HotSpot code, with some restrictions and suggestions for good usage within
>> HotSpot code.  Lambda expressions were added in C++11, and provide a more
>> expressive syntax for local functions, with a number of use-cases where they
>> can improve readability by eliminating a lot of uninteresting boilerplate.
>> 
>> Some example uses are included, but are not part of the proposed change.
>> They will be removed from the PR before it is pushed.  (In particular, the
>> ScopeGuard utility uses move semantics, the use of which hasn't been
>> approved or even discussed.)  They are given to show some of the benefits
>> that might accrue from permitting the use of lambdas. In particular, they
>> highlight some of the code reduction that is possible. Some of these code
>> changes might be proposed in the future, using the normal PR process.
>> 
>> This is a modification of the Style Guide, so rough consensus among the
>> HotSpot Group members is required to make this change.  Only Group members
>> should vote for approval (via the github PR), though reasoned objections or
>> comments from anyone will be considered.  A decision on this proposal will
>> not be made before Wednesday 1-Sep-2021 at 12h00 UTC.
>> 
>> Since we're piggybacking on github PRs here, please use the PR review
>> process to approve (click on Review Changes > Approve), rather than sending
>> a "vote: yes" email reply that would be normal for a CFV.
>
> doc/hotspot-style.md line 708:
> 
>> 706: * Local function objects, including lambda expressions, may be used.
>> 707: * Lambda expressions must only be used as a downward value.
>> 708: * Prefer `[&]` as the capture list of a lambda expression.
> 
> hi, @kimbarrett , 
> Why does it sound like a suggestion instead of a mandate? 
> You explain why we should use [&] and all your examples are implicit capture reference.

That's intentional. Capture lists were by far the single most contentious part
of the Oracle-internal discussions about lambda usage. Making this a
suggestion rather than a mandate, along with the rationale, leaves open the
possibility of using other forms *with good reason*, and preferably after a
period of folks getting used to the "usual" form. There are HotSpot developers
who aren't familiar with lambda-like constructs, or are not comfortable with
the introduction of yet more non-alphanumeric syntax that resembles line
noise; limiting the capture list features being used helps them. On the other
hand, there have been proponents of nearly every capture list feature for some
use case or another.

-------------

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

From aph at openjdk.java.net  Sat Aug 21 08:48:25 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Sat, 21 Aug 2021 08:48:25 GMT
Subject: RFR: 8264707: HotSpot Style Guide should permit use of lambda
In-Reply-To: <ClF_S5jjfQ911hsUdbxKkaXjVyJ1euXgkDT8JB5fkSs=.42f08fe5-abd8-4839-858b-036e3012ba6b@github.com>
References: <ClF_S5jjfQ911hsUdbxKkaXjVyJ1euXgkDT8JB5fkSs=.42f08fe5-abd8-4839-858b-036e3012ba6b@github.com>
Message-ID: <G6oRq_uC1Pr2nO-351VMcVKuM6d9ZLSFp4vdThNEqj0=.47627fd6-5004-4423-80d3-e5ef7a74e226@github.com>

On Tue, 17 Aug 2021 13:49:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this proposal to permit the use of lambda expressions in
> HotSpot code, with some restrictions and suggestions for good usage within
> HotSpot code.  Lambda expressions were added in C++11, and provide a more
> expressive syntax for local functions, with a number of use-cases where they
> can improve readability by eliminating a lot of uninteresting boilerplate.
> 
> Some example uses are included, but are not part of the proposed change.
> They will be removed from the PR before it is pushed.  (In particular, the
> ScopeGuard utility uses move semantics, the use of which hasn't been
> approved or even discussed.)  They are given to show some of the benefits
> that might accrue from permitting the use of lambdas. In particular, they
> highlight some of the code reduction that is possible. Some of these code
> changes might be proposed in the future, using the normal PR process.
> 
> This is a modification of the Style Guide, so rough consensus among the
> HotSpot Group members is required to make this change.  Only Group members
> should vote for approval (via the github PR), though reasoned objections or
> comments from anyone will be considered.  A decision on this proposal will
> not be made before Wednesday 1-Sep-2021 at 12h00 UTC.
> 
> Since we're piggybacking on github PRs here, please use the PR review
> process to approve (click on Review Changes > Approve), rather than sending
> a "vote: yes" email reply that would be normal for a CFV.

So here's an oink in the flightment:


macroAssembler_aarch64_aes.o: Error: Use of global operators new and delete is not allowed in Hotspot:
                 U operator delete(void*)
                 U operator new(unsigned long)
See: /Users/aph/theRealAph-jdk/make/hotspot/lib/CompileJvm.gmk



This happened on MacOS/AArch64, and was caused by an apparently innocuous Lambda. GCC doesn't generate new and delete for this construct, but AArch64 clang does for some reason. And I guess it's true that C++ compilers are free to do this, and even if one compiler doesn't do so today, it might tomorrow.

What should we do? At least for my application, it doesn't matter if new and delete are used, but in some cases it might. Do we need a blanket prohibition against new and delete, when the programmer has no control over it?

-------------

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

From aph-open at littlepinkcloud.com  Sat Aug 21 10:05:19 2021
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Sat, 21 Aug 2021 11:05:19 +0100
Subject: RFC: AArch64: Implementing spin pauses with ISB
In-Reply-To: <5C928C8E-BCF5-4A22-BFA6-261CBDBA0361@amazon.com>
References: <5C928C8E-BCF5-4A22-BFA6-261CBDBA0361@amazon.com>
Message-ID: <b83cd3bf-5025-7f2f-5523-15825a75e600@littlepinkcloud.com>

On 8/17/21 9:42 PM, Astigeevich, Evgeny wrote:
> 
>> The ISB instruction wasn't intended to be used for that purpose...
> 
> It might be a time for YIELD to be a real instruction, especially on Neoverse. High thread contention is a typical situation in server workloads.
> If it would be great if Neoverse architects consider this.

Maybe, but recent experience from Intel (where the delay was changed from 20-30
clocks to 200) causing regressions in some areas, suggests it's very problematic.

>> Your experiments were with one ISB - did you experiment at all with multiple ISBs? I'm curious as to what the overall effect would be.
> 
> Yes, there were experiments with 2 ISBs. With 2 ISBs the performance improvements were less. Graviton 2 performance engineers' explanation of this is that spins should target 15-30ns. One ISB allows to be within these limits. Two and more ISBs get longer spins. It increases chances of an expensive code path and the OS to reschedule threads.

How application dependent is this? Does it depend on how many threads are
contending for a lock? Are there other places (intrinsic monitors, say)
where we should do this?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From kbarrett at openjdk.java.net  Sat Aug 21 16:48:21 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 21 Aug 2021 16:48:21 GMT
Subject: RFR: 8264707: HotSpot Style Guide should permit use of lambda
In-Reply-To: <G6oRq_uC1Pr2nO-351VMcVKuM6d9ZLSFp4vdThNEqj0=.47627fd6-5004-4423-80d3-e5ef7a74e226@github.com>
References: <ClF_S5jjfQ911hsUdbxKkaXjVyJ1euXgkDT8JB5fkSs=.42f08fe5-abd8-4839-858b-036e3012ba6b@github.com>
 <G6oRq_uC1Pr2nO-351VMcVKuM6d9ZLSFp4vdThNEqj0=.47627fd6-5004-4423-80d3-e5ef7a74e226@github.com>
Message-ID: <X2eJZs0CkukL6lXZXsoucOLRTCQGjd7S565Onqc8MXM=.e1fa4a4c-4d3c-4c36-9258-10e53faedb49@github.com>

On Sat, 21 Aug 2021 08:45:48 GMT, Andrew Haley <aph at openjdk.org> wrote:

> So here's an oink in the flightment:
> 
> ```
> macroAssembler_aarch64_aes.o: Error: Use of global operators new and delete is not allowed in Hotspot:
>                  U operator delete(void*)
>                  U operator new(unsigned long)
> See: /Users/aph/theRealAph-jdk/make/hotspot/lib/CompileJvm.gmk
> ```
> 
> This happened on MacOS/AArch64, and was caused by an apparently innocuous Lambda. GCC doesn't generate new and delete for this construct, but AArch64 clang does for some reason. And I guess it's true that C++ compilers are free to do this, and even if one compiler doesn't do so today, it might tomorrow.
> 
> What should we do? At least for my application, it doesn't matter if new and delete are used, but in some cases it might. Do we need a blanket prohibition against new and delete, when the programmer has no control over it?

Bleh!  Why would a lambda need new/delete?

Can you give more details about how you encountered this?  I've not seen
anything of the sort.

The purpose of that error is to prevent HotSpot code from bypassing NMT. NMT
can't just override the global operator new/delete because an application
might want to use its own for its native code.

-------------

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

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: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>

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: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <0eO4SD_N9lrP5k5bhEejUKXeMauRC8zuc_slUJSrc5c=.c886ae36-5039-450f-9293-5f9910ce432d@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> 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 alanb at openjdk.java.net  Sun Aug 22 15:12:26 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 22 Aug 2021 15:12:26 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <OvTvFnSa61RYUr_VO3fRcnjTkxDwYX0VdqwiiGnveBs=.78ea3741-9e90-447b-909c-be7fedf40f8f@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> 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.

src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 342:

> 340: 
> 341:         try {
> 342:             for (String line : Files.readAllLines(statusPath, UTF_8)) {

The 1-arg readAllLines is specified to use UTF-8 so you can drop the second parameter here if you want.

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Aug 22 18:34:26 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 22 Aug 2021 18:34:26 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <Ng1z8PAjPNJ8IC8xxYp_Px4NlXJ8DWqs6e12eGb5wP0=.09ad1ed7-2788-48cb-a067-76955b5e912c@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> 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.

I think it's worth to update _static_ initializer in `sun.datatransfer.DataFlavorUtil.CharsetComparator` too.
![???????????](https://user-images.githubusercontent.com/741251/130366051-ef093bf1-d7d9-4ad1-91e7-5df5af8678af.png)

-------------

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

From serb at openjdk.java.net  Sun Aug 22 23:02:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 22 Aug 2021 23:02:06 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>

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

Sergey Bylokhov 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 14 additional commits since the last revision:

 - Update the usage of Files.readAllLines()
 - Update datatransfer
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - 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
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/37357100...e7127644

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5210/files
  - new: https://git.openjdk.java.net/jdk/pull/5210/files/2d9c80b8..e7127644

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

  Stats: 3598 lines in 210 files changed: 2055 ins; 1115 del; 428 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 naoto at openjdk.java.net  Mon Aug 23 00:26:31 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 23 Aug 2021 00:26:31 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <YDjqMHQFk2IHLNrmd3MahBp6vvL4D3x4ncTa3PvvQWY=.39eace25-57d6-4981-a1ad-31901c061b25@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> 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.
>
> Sergey Bylokhov 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 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - 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
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/c262b06f...e7127644

Looks good.

-------------

Marked as reviewed by naoto (Reviewer).

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

From github.com+4146708+a74nh at openjdk.java.net  Mon Aug 23 01:44:30 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Mon, 23 Aug 2021 01:44:30 GMT
Subject: Integrated: 8269687: pauth_aarch64.hpp include name is incorrect
In-Reply-To: <mn_iAE8Z2n_DqxM1srOaitn7qJMnn1GCLb78b418jgw=.bc3fde65-3616-4223-b3b4-eb36aa125920@github.com>
References: <mn_iAE8Z2n_DqxM1srOaitn7qJMnn1GCLb78b418jgw=.bc3fde65-3616-4223-b3b4-eb36aa125920@github.com>
Message-ID: <PJAdtWuWAUbncyYYLQoMOyHcHo4PoMReUuSSFca_bYo=.50bc6d32-ac9a-42ec-8352-f51d3bffe2e0@github.com>

On Fri, 20 Aug 2021 08:48:19 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> Quick fix to correct the include guards.

This pull request has now been integrated.

Changeset: b690f296
Author:    Alan Hayward <alan.hayward at arm.com>
Committer: Nick Gasson <ngasson at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b690f29699180149d33b6a83de10697790587a87
Stats:     9 lines in 3 files changed: 0 ins; 0 del; 9 mod

8269687: pauth_aarch64.hpp include name is incorrect

Reviewed-by: rbackman, ngasson

-------------

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

From sakatakui at oss.nttdata.com  Mon Aug 23 03:29:20 2021
From: sakatakui at oss.nttdata.com (Koichi Sakata)
Date: Mon, 23 Aug 2021 12:29:20 +0900
Subject: Regarding options of error and dump file paths
Message-ID: <92708e25-331f-f832-144b-eb00e2b0a4ac@oss.nttdata.com>

Hi all,

I'm writing to get feedback on my idea about options for error and dump 
file paths.

First of all, we can specify several options related to error and dump 
files. For example, the HeapDumpPath option sets the heap dump file and 
the ErrorFile option sets the hs_error file.

I've felt inconvenience about that because we need to write all path 
options to put those files in a specific directory. I also recognize 
that they are outputted in the working directory when I run an 
application with no options. But I'd like to keep them in any directory. 
So the new option that sets the directory where those files are 
outputted would be useful, I think.

The new option helps us especially to run applications on containers 
like Docker, Kubernetes etc. If we run them without those existing 
options on containers, files will be put in the local directory of each 
container. We lose files after we operate the container such as deleting 
it. The option enables us to keep certainly all error and dump files if 
we just specify the path of the persistent volume for the new option.

As a concrete example, when we specify -XX:ErrorAndDumpPath=/foo/bar/ 
(This option name is tentative), -XX:+HeapDumpOnOutOfMemoryError and 
-XX:StartFlightRecording etc., files are generated in the /foo/bar 
directory. From my point of view, the option will deal with the 
following files:
- heap dump file (java_pid%p.hprof)
- error log file (hs_err_pid%p.log)
- JFR emergency dumps (hs_err_pid%p.jfr, hs_oom_pid%p.jfr, hs_soe_pid%p.jfr)
- replay file (replay_pid%p.log)

The existing path options should override the new option. If I set 
-XX:ErrorAndDumpPath=/foo/bar/ and -XX:HeapDumpPath=/foo/baz/, a heap 
dump file will be in the /foo/baz directory and other files will be 
created in the /foo/bar.

I would like to hear your point of view. If some people agree to this 
idea, I will write a patch.

Regards,
Koichi

From thomas.stuefe at gmail.com  Mon Aug 23 04:54:30 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 23 Aug 2021 06:54:30 +0200
Subject: Regarding options of error and dump file paths
In-Reply-To: <92708e25-331f-f832-144b-eb00e2b0a4ac@oss.nttdata.com>
References: <92708e25-331f-f832-144b-eb00e2b0a4ac@oss.nttdata.com>
Message-ID: <CAA-vtUxVP1xMwzZvCue4=feMvzqB2nWPxcdWhGrVBYSGgw0w9w@mail.gmail.com>

Hi Koichi,

Would it not be way less complex to just set the current working directory
to wherever you want to direct the output?

We even could give the VM a new option to let it cwd into a specific
directory after launching.

Cheers, Thomas





On Mon, Aug 23, 2021 at 5:29 AM Koichi Sakata <sakatakui at oss.nttdata.com>
wrote:

> Hi all,
>
> I'm writing to get feedback on my idea about options for error and dump
> file paths.
>
> First of all, we can specify several options related to error and dump
> files. For example, the HeapDumpPath option sets the heap dump file and
> the ErrorFile option sets the hs_error file.
>
> I've felt inconvenience about that because we need to write all path
> options to put those files in a specific directory. I also recognize
> that they are outputted in the working directory when I run an
> application with no options. But I'd like to keep them in any directory.
> So the new option that sets the directory where those files are
> outputted would be useful, I think.
>
> The new option helps us especially to run applications on containers
> like Docker, Kubernetes etc. If we run them without those existing
> options on containers, files will be put in the local directory of each
> container. We lose files after we operate the container such as deleting
> it. The option enables us to keep certainly all error and dump files if
> we just specify the path of the persistent volume for the new option.
>
> As a concrete example, when we specify -XX:ErrorAndDumpPath=/foo/bar/
> (This option name is tentative), -XX:+HeapDumpOnOutOfMemoryError and
> -XX:StartFlightRecording etc., files are generated in the /foo/bar
> directory. From my point of view, the option will deal with the
> following files:
> - heap dump file (java_pid%p.hprof)
> - error log file (hs_err_pid%p.log)
> - JFR emergency dumps (hs_err_pid%p.jfr, hs_oom_pid%p.jfr,
> hs_soe_pid%p.jfr)
> - replay file (replay_pid%p.log)
>
> The existing path options should override the new option. If I set
> -XX:ErrorAndDumpPath=/foo/bar/ and -XX:HeapDumpPath=/foo/baz/, a heap
> dump file will be in the /foo/baz directory and other files will be
> created in the /foo/bar.
>
> I would like to hear your point of view. If some people agree to this
> idea, I will write a patch.
>
> Regards,
> Koichi
>

From xliu at openjdk.java.net  Mon Aug 23 06:15:26 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 23 Aug 2021 06:15:26 GMT
Subject: RFR: 8264707: HotSpot Style Guide should permit use of lambda
In-Reply-To: <DZLISTTb2aNASmgYX8t60Ksy4tBlxAmvDrLhDP5nIaM=.3a090aaa-24f0-4d33-beb3-9bfc1aee4ae8@github.com>
References: <ClF_S5jjfQ911hsUdbxKkaXjVyJ1euXgkDT8JB5fkSs=.42f08fe5-abd8-4839-858b-036e3012ba6b@github.com>
 <I77VX0YVaoi1uXeTpzBoKx-R2DFoqV4UtHtW5txjYmw=.bb9e11ac-30d4-49e0-b43d-dedabb5e472c@github.com>
 <DZLISTTb2aNASmgYX8t60Ksy4tBlxAmvDrLhDP5nIaM=.3a090aaa-24f0-4d33-beb3-9bfc1aee4ae8@github.com>
Message-ID: <25LiYPpKZpt5BZmkWPZmoiYub3GDKEszgo3ILb0Hurc=.cb6e6e42-6f62-4563-955a-e1ac2bb34b6d@github.com>

On Sat, 21 Aug 2021 07:06:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> doc/hotspot-style.md line 708:
>> 
>>> 706: * Local function objects, including lambda expressions, may be used.
>>> 707: * Lambda expressions must only be used as a downward value.
>>> 708: * Prefer `[&]` as the capture list of a lambda expression.
>> 
>> hi, @kimbarrett , 
>> Why does it sound like a suggestion instead of a mandate? 
>> You explain why we should use [&] and all your examples are implicit capture reference.
>
> That's intentional. Capture lists were by far the single most contentious part
> of the Oracle-internal discussions about lambda usage. Making this a
> suggestion rather than a mandate, along with the rationale, leaves open the
> possibility of using other forms *with good reason*, and preferably after a
> period of folks getting used to the "usual" form. There are HotSpot developers
> who aren't familiar with lambda-like constructs, or are not comfortable with
> the introduction of yet more non-alphanumeric syntax that resembles line
> noise; limiting the capture list features being used helps them. On the other
> hand, there have been proponents of nearly every capture list feature for some
> use case or another.

Got it. Thanks for the explanation.

-------------

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

From dholmes at openjdk.java.net  Mon Aug 23 06:39:27 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 23 Aug 2021 06:39:27 GMT
Subject: RFR: 8272554: Add help message about the named pipe support of UL.
In-Reply-To: <PumJUqzmFfNGHg7GALm4JQje4rlRUldqqp2hjTgKDNM=.972d6873-2f1a-46b5-b8e7-b2972e371ed7@github.com>
References: <PumJUqzmFfNGHg7GALm4JQje4rlRUldqqp2hjTgKDNM=.972d6873-2f1a-46b5-b8e7-b2972e371ed7@github.com>
Message-ID: <r6QRCBb_3hpbQQKMsaOZC-2hauQF2x37HgcBJjKhQ9E=.5f93726b-a7a9-4653-9f8a-1bb7d96a37a4@github.com>

On Fri, 20 Aug 2021 22:52:05 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This patch adds a help message about the named pipe support of the Unified Logging to -Xlog:help and manpage.
> 
> For -Xlog:help, here is the new help message:
> 
> Available log outputs:
>  stdout/stderr
>  file=<filename>
>   If the filename contains %p and/or %t, they will expand to the JVM's PID and startup timestamp, respectively. The filename can be a named pipe when log rotation is disabled.  
> 
> 
> Here is the new manpage content.
> 
>  When using file=filename, specifying %p and/or %t in the file name expands to the JVM's PID and startup timestamp, respectively.  You can also configure text files to handle file rotation based on file size and a number of files to rotate.  For example, to rotate the log file every 10 MB and  keep  5
>  files  in rotation, specify the options filesize=10M, filecount=5.  The target size of the files isn't guaranteed to be exact, it's just an approximate value.  Files are rotated by default with up to 5 rotated files of target size 20 MB, unless configured otherwise.  Specifying filecount=0 means that
>  the log file shouldn't be rotated.  The filename can be a named pipe when log rotation is disabled.  There's a possibility of the pre-existing log file getting overwritten.

Hi Xin,

I'm opening up the discussion to hotspot-dev as all the teams use UL. I'm not at all sure this is the right way to introduce the ability to use named pipes here. I'd probably prefer to see something under the "file=" section to expand on what kinds of "file" are supported; then the other sections would list any constraints in relation to the different kinds of "file".

The problem with any kind of documentation change like this is that when people examine the documentation they always tend to find more problems with it, and containing the scope of the change can be a challenge.

Thanks,
David

-------------

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

From ayang at openjdk.java.net  Mon Aug 23 08:57:01 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 23 Aug 2021 08:57:01 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
In-Reply-To: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
Message-ID: <mTQrAQLbwaof6-BFlIvNDgUQ30QPdSN3CVobE0iDQJw=.052bc1ae-75fd-4115-831c-def7a02acf31@github.com>

On Fri, 20 Aug 2021 13:31:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of merging `is_instance` and `is_instance_inlined`.
> 
> Test: build

More renaming because of new code from master branch.

-------------

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

From ayang at openjdk.java.net  Mon Aug 23 08:56:59 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 23 Aug 2021 08:56:59 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String [v2]
In-Reply-To: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
Message-ID: <7Ad-ey2I75iDXYQbxxeOlV4jpBmfJ07kOuc5oPFp70Y=.6075d8d0-6591-463d-a546-a40375ac9e30@github.com>

> Simple change of merging `is_instance` and `is_instance_inlined`.
> 
> Test: build

Albert Mingkun Yang 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:

 - more rename
 - Merge branch 'master' into inline
 - inline

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5201/files
  - new: https://git.openjdk.java.net/jdk/pull/5201/files/883cc213..84b218a1

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

  Stats: 721 lines in 34 files changed: 581 ins; 73 del; 67 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5201.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5201/head:pull/5201

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

From dfuchs at openjdk.java.net  Mon Aug 23 09:36:40 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 23 Aug 2021 09:36:40 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <iwz79djzNlUzGYlpBbrLcycsmNcDy3bZF7qc4vozQAI=.e4aa79aa-f9cd-413a-bb5a-dc95023dc410@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> 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.
>
> Sergey Bylokhov 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 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - 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
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/db47f6e1...e7127644

Changes to http server look good to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

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

From redestad at openjdk.java.net  Mon Aug 23 09:57:32 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 23 Aug 2021 09:57:32 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String [v2]
In-Reply-To: <7Ad-ey2I75iDXYQbxxeOlV4jpBmfJ07kOuc5oPFp70Y=.6075d8d0-6591-463d-a546-a40375ac9e30@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
 <7Ad-ey2I75iDXYQbxxeOlV4jpBmfJ07kOuc5oPFp70Y=.6075d8d0-6591-463d-a546-a40375ac9e30@github.com>
Message-ID: <FafGw1a9CaLjZMUNcxm3g1fZ0h5bT8X1AEl0jGHwdfY=.ed402447-3145-443a-9e47-206de4ceee73@github.com>

On Mon, 23 Aug 2021 08:56:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of merging `is_instance` and `is_instance_inlined`.
>> 
>> Test: build
>
> Albert Mingkun Yang 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:
> 
>  - more rename
>  - Merge branch 'master' into inline
>  - inline

Marked as reviewed by redestad (Reviewer).

-------------

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

From jbachorik at openjdk.java.net  Mon Aug 23 10:31:36 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Mon, 23 Aug 2021 10:31:36 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
Message-ID: <BWanYitzfyqkvmVIKndceXJDtbA5lBDxKA94gsMt9hY=.4d5d7dc0-e763-499b-9a3c-8ac75f4415e4@github.com>

On Mon, 19 Jul 2021 09:25:59 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime stub (like arraycopy), a vtable stub, or the prolog of a compiled method,  it wouldn't be able to detect the sender (caller) frame for multiple reasons. This patch fixes these cases through adding CodeBlob-specific frame parser which are in the best position to know how a frame is setup.
>> 
>> The following examples have been profiled with honest-profiler which uses `AsyncGetCallTrace`.
>> 
>> # `Prof1`
>> 
>> public class Prof1 {
>> 
>>     public static void main(String[] args) {
>>         StringBuilder sb = new StringBuilder();
>>         for (int i = 0; i < 1000000; i++) {
>>             sb.append("ab");
>>             sb.delete(0, 1);
>>         }
>>         System.out.println(sb.length());
>>     }
>> }
>> 
>> 
>> - Baseline:
>> 
>> Flat Profile (by method):
>>         (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>>         (t  0.5,s  0.2) Prof1::main
>>         (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>>         (t  0.0,s  0.0) java.lang.String::getBytes
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>>         (t  0.0,s  0.0) java.lang.StringBuilder::delete
>>         (t  0.2,s  0.0) java.lang.StringBuilder::append
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>> 
>> - With `StubRoutinesBlob::FrameParser`:
>> 
>> Flat Profile (by method):
>>         (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>         (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>>         (t 99.8,s  0.2) Prof1::main
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>>         (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>>         (t 98.8,s  0.0) java.lang.StringBuilder::append
>>         (t  0.9,s  0.0) java.lang.StringBuilder::delete
>> 
>> 
>> # `Prof2`
>> 
>> import java.util.function.Supplier;
>> 
>> public class Prof2 {
>> 
>>     public static void main(String[] args) {
>>         var rand = new java.util.Random(0);
>>         Supplier[] suppliers = {
>>                 () -> 0,
>>                 () -> 1,
>>                 () -> 2,
>>                 () -> 3,
>>         };
>> 
>>         long sum = 0;
>>         for (int i = 0; i >= 0; i++) {
>>             sum += (int)suppliers[i % suppliers.length].get();
>>         }
>>     }
>> }
>> 
>> 
>> - Baseline:
>> 
>> Flat Profile (by method):
>>         (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>>         (t 39.2,s 35.2) Prof2::main
>>         (t  1.4,s  1.4) Prof2::lambda$main$3
>>         (t  1.0,s  1.0) Prof2::lambda$main$2
>>         (t  0.9,s  0.9) Prof2::lambda$main$1
>>         (t  0.7,s  0.7) Prof2::lambda$main$0
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) java.lang.Thread::exit
>>         (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>>         (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>>         (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>>         (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
>> 
>> 
>> - With `VtableBlob::FrameParser` and `nmethod::FrameParser`:
>> 
>> Flat Profile (by method):
>>         (t 74.1,s 70.3) Prof2::main
>>         (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>>         (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>>         (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>>         (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>>         (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>>         (t  1.2,s  1.2) Prof2::lambda$main$2
>>         (t  0.9,s  0.9) Prof2::lambda$main$3
>>         (t  0.9,s  0.9) Prof2::lambda$main$1
>>         (t  0.7,s  0.7) Prof2::lambda$main$0
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>
> Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Remove FrameParser and the required allocation
>    
>    The need for the allocation would be it non async-safe. However,
>    AsyncGetCallTrace is async-safe and thus can't allow for allocations.
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix-8178287
>  - Fix comments
>  - Disable checks in FrameParser when known to be safe
>  - Allow AsyncGetCallTrace and JFR to unwind stack from vtable stub
>    
>    The program is the following:
>    
>    ```
>    import java.util.function.Supplier;
>    
>    public class Prof2 {
>    
>        public static void main(String[] args) {
>            var rand = new java.util.Random(0);
>            Supplier[] suppliers = {
>                    () -> 0,
>                    () -> 1,
>                    () -> 2,
>                    () -> 3,
>            };
>    
>            long sum = 0;
>            for (int i = 0; i >= 0; i++) {
>                sum += (int)suppliers[i % suppliers.length].get();
>            }
>        }
>    }
>    ```
>    
>    The results are as follows:
>    
>    - Baseline (from previous commit):
>    
>    Flat Profile (by method):
>                (t 39.3,s 39.3) AGCT::Unknown Java[ERR=-5]
>                (t 40.3,s 36.1) Prof2::main
>                (t  6.4,s  5.3) Prof2$$Lambda$28.0x0000000800081000::get
>                (t  6.1,s  5.1) Prof2$$Lambda$29.0x0000000800081220::get
>                (t  6.0,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>                (t  6.1,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>                (t  1.1,s  1.1) Prof2::lambda$main$2
>                (t  1.1,s  1.1) Prof2::lambda$main$0
>                (t  1.0,s  1.0) Prof2::lambda$main$1
>                (t  0.9,s  0.9) Prof2::lambda$main$3
>                (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>    
>    - With unwind from vtable stub
>    
>    Flat Profile (by method):
>            (t 74.1,s 70.3) Prof2::main
>            (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>            (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>            (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>            (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>            (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>            (t  1.2,s  1.2) Prof2::lambda$main$2
>            (t  0.9,s  0.9) Prof2::lambda$main$3
>            (t  0.9,s  0.9) Prof2::lambda$main$1
>            (t  0.7,s  0.7) Prof2::lambda$main$0
>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>    
>    We attribute the vtable stub to the caller and not the callee, which is
>    already an improvement from the existing case.
>  - Allow AsyncGetCallTrace and JFR to unwind stack from nmethod's prolog
>    
>    When sampling hits the prolog of a method, Hotspot assumes it's unable
>    to parse the frame. This change allows to parse such frame on x86 by
>    specializing which instruction it's hitting in the prolog.
>    
>    The results are as follows:
>    
>    - Baseline:
>    
>    Flat Profile (by method):
>            (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>            (t 39.2,s 35.2) Prof2::main
>            (t  1.4,s  1.4) Prof2::lambda$main$3
>            (t  1.0,s  1.0) Prof2::lambda$main$2
>            (t  0.9,s  0.9) Prof2::lambda$main$1
>            (t  0.7,s  0.7) Prof2::lambda$main$0
>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>            (t  0.0,s  0.0) java.lang.Thread::exit
>            (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>            (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>            (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>            (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
>    
>    - With incomplete frame parsing:
>    
>    Flat Profile (by method):
>            (t 39.3,s 39.3) AGCT::Unknown Java[ERR=-5]
>            (t 40.3,s 36.1) Prof2::main
>            (t  6.4,s  5.3) Prof2$$Lambda$28.0x0000000800081000::get
>            (t  6.1,s  5.1) Prof2$$Lambda$29.0x0000000800081220::get
>            (t  6.0,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>            (t  6.1,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>            (t  1.1,s  1.1) Prof2::lambda$main$2
>            (t  1.1,s  1.1) Prof2::lambda$main$0
>            (t  1.0,s  1.0) Prof2::lambda$main$1
>            (t  0.9,s  0.9) Prof2::lambda$main$3
>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>            (t  0.0,s  0.0) java.util.Locale::getInstance
>            (t  0.0,s  0.0) AGCT::Not walkable Java[ERR=-6]
>            (t  0.0,s  0.0) jdk.internal.loader.BuiltinClassLoader::loadClassOrNull
>            (t  0.0,s  0.0) java.lang.ClassLoader::loadClass
>            (t  0.0,s  0.0) sun.net.util.URLUtil::urlNoFragString
>            (t  0.0,s  0.0) java.lang.Class::forName0
>            (t  0.0,s  0.0) java.util.Locale::initDefault
>            (t  0.0,s  0.0) jdk.internal.loader.BuiltinClassLoader::loadClass
>            (t  0.0,s  0.0) jdk.internal.loader.URLClassPath::getLoader
>            (t  0.0,s  0.0) jdk.internal.loader.URLClassPath::getResource
>            (t  0.0,s  0.0) java.lang.String::toLowerCase
>            (t  0.0,s  0.0) sun.launcher.LauncherHelper::loadMainClass
>            (t  0.0,s  0.0) sun.launcher.LauncherHelper::checkAndLoadMain
>            (t  0.0,s  0.0) java.util.Locale::<clinit>
>            (t  0.0,s  0.0) jdk.internal.loader.BuiltinClassLoader::findClassOnClassPathOrNull
>            (t  0.0,s  0.0) jdk.internal.loader.ClassLoaders$AppClassLoader::loadClass
>            (t  0.0,s  0.0) java.lang.Class::forName
>    
>    The program is as follows:
>    
>    ```
>    import java.util.function.Supplier;
>    
>    public class Prof2 {
>    
>        public static void main(String[] args) {
>            var rand = new java.util.Random(0);
>            Supplier[] suppliers = {
>                    () -> 0,
>                    () -> 1,
>                    () -> 2,
>                    () -> 3,
>            };
>    
>            long sum = 0;
>            for (int i = 0; i >= 0; i++) {
>                sum += (int)suppliers[i % suppliers.length].get();
>            }
>        }
>    }
>    ```
>    
>    We see that the results are particularely useful in this case as the
>    methods are very short (it only returns an integer), and the probability
>    of hitting the prolog is then very high.
>  - Allow AsyncGetCallTrace and JFR to walk a stub frame
>    
>    When the signal sent for AsyncGetCallTrace or JFR would land on a stub
>    (like arraycopy), it wouldn't be able to detect the sender (caller)
>    frame because `_cb->frame_size() == 0`.
>    
>    Because we fully control how the prolog and epilog of stub code is
>    generated, we know there are two cases:
>    1. A stack frame is allocated via macroAssembler->enter(), and consists
>    in `push rbp; mov rsp, rbp;`.
>    2. No stack frames are allocated and rbp is left unchanged and rsp is
>    decremented with the `call` instruction that push the return `pc` on the
>    stack.
>    
>    For case 1., we can easily know the sender frame by simply looking at
>    rbp, especially since we know that all stubs preserve the frame pointer
>    (on x86 at least).
>    
>    For case 2., we end up returning the sender's sender, but that already
>    gives us more information than what we have today.
>    
>    The results are as follows:
>    
>    - Baseline:
>    
>    Flat Profile (by method):
>            (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>            (t  0.5,s  0.2) Prof1::main
>            (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>            (t  0.0,s  0.0) java.lang.String::getBytes
>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>            (t  0.0,s  0.0) java.lang.StringBuilder::delete
>            (t  0.2,s  0.0) java.lang.StringBuilder::append
>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>    
>    - With StubRoutinesBlob::FrameParser
>    
>    Flat Profile (by method):
>            (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
>            (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>            (t 99.8,s  0.2) Prof1::main
>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>            (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>            (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>            (t 98.8,s  0.0) java.lang.StringBuilder::append
>            (t  0.9,s  0.0) java.lang.StringBuilder::delete
>    
>    The program is as follows:
>    
>    ```
>    public class Prof1 {
>    
>        public static void main(String[] args) {
>            StringBuilder sb = new StringBuilder();
>            for (int i = 0; i < 1000000; i++) {
>                sb.append("ab");
>                sb.delete(0, 1);
>            }
>            System.out.println(sb.length());
>        }
>    }
>    ```
>    
>    We now account for the arraycopy stub which is called by
>    AbstractStringBuilder::ensureCapacityInternal. It was previously ignored
>    because it would not know how to parse the frame for the arraycopy stub
>    and would fall in the AGCT::Unknown Java[ERR=-5] section.
>    
>    However, it still isn't perfect since it doesn't point to the arraycopy stub
>    directly.
>  - Extract sender frame parsing to CodeBlock::FrameParser
>    
>    Whether and how a frame is setup is controlled by the code generator
>    for the specific CodeBlock. The CodeBlock is then in the best place to know how
>    to parse the sender's frame from the current frame in the given CodeBlock.
>    
>    This refactoring proposes to extract this parsing out of `frame` and into a
>    `CodeBlock::FrameParser`. This FrameParser is then specialized in the relevant
>    inherited children of CodeBlock.
>    
>    This change is to largely facilitate adding new supported cases for JDK-8252417
>    like runtime stubs.

@dcubed-ojdk , @dholmes-ora would you be willing/able to take a look at this change, pretty please?

-------------

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

From dholmes at openjdk.java.net  Mon Aug 23 10:56:24 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 23 Aug 2021 10:56:24 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be
 safepoint_check_never
In-Reply-To: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
References: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
Message-ID: <b_IR_9FEkLjUSpmh7f0_pdZnRPGdLUa8p52EsZhcW2w=.d5abd930-dc03-485a-927e-a62161ee3eb2@github.com>

On Fri, 20 Aug 2021 16:41:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
> Tested with tier1-3.  Tier 4-6 testing in progress.

Hi Coleen,

Sorry I'm struggling to interpret exactly what these changes mean.  You're redefining the ranking for some locks so that you can then declare that nonleaf locks should not be safepoint-check-never. But in changing those rankings you are also potentially reducing the set of lock nestings that are permitted - so for example a lock that was Barrier and is now leaf+1 can no longer be locked before locking a leaf+2, 3...9. That might be valid but it is not at all obvious how to verify that - testing alone will only cover the common code paths, not necessarily those rarely taken e.g for debugging, logging, exceptional conditions, event processing, non-default flag values ...

It is not at all clear to me that the ranking strategy and the safepoint-checking strategy align in the way you are implying.

Could you elaborate on how you expect this to end up looking please.

Thanks,
David

-------------

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

From dholmes at openjdk.java.net  Mon Aug 23 11:00:36 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 23 Aug 2021 11:00:36 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <BWanYitzfyqkvmVIKndceXJDtbA5lBDxKA94gsMt9hY=.4d5d7dc0-e763-499b-9a3c-8ac75f4415e4@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
 <BWanYitzfyqkvmVIKndceXJDtbA5lBDxKA94gsMt9hY=.4d5d7dc0-e763-499b-9a3c-8ac75f4415e4@github.com>
Message-ID: <APS6H9AlsHSVKx62JWEAfdZjjbSJ58Wor7GHYPyhe74=.0c65e5fe-848e-42e9-b61b-890f81a5e1c2@github.com>

On Mon, 23 Aug 2021 10:28:36 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Remove FrameParser and the required allocation
>>    
>>    The need for the allocation would be it non async-safe. However,
>>    AsyncGetCallTrace is async-safe and thus can't allow for allocations.
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix-8178287
>>  - Fix comments
>>  - Disable checks in FrameParser when known to be safe
>>  - Allow AsyncGetCallTrace and JFR to unwind stack from vtable stub
>>    
>>    The program is the following:
>>    
>>    ```
>>    import java.util.function.Supplier;
>>    
>>    public class Prof2 {
>>    
>>        public static void main(String[] args) {
>>            var rand = new java.util.Random(0);
>>            Supplier[] suppliers = {
>>                    () -> 0,
>>                    () -> 1,
>>                    () -> 2,
>>                    () -> 3,
>>            };
>>    
>>            long sum = 0;
>>            for (int i = 0; i >= 0; i++) {
>>                sum += (int)suppliers[i % suppliers.length].get();
>>            }
>>        }
>>    }
>>    ```
>>    
>>    The results are as follows:
>>    
>>    - Baseline (from previous commit):
>>    
>>    Flat Profile (by method):
>>                (t 39.3,s 39.3) AGCT::Unknown Java[ERR=-5]
>>                (t 40.3,s 36.1) Prof2::main
>>                (t  6.4,s  5.3) Prof2$$Lambda$28.0x0000000800081000::get
>>                (t  6.1,s  5.1) Prof2$$Lambda$29.0x0000000800081220::get
>>                (t  6.0,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>>                (t  6.1,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>>                (t  1.1,s  1.1) Prof2::lambda$main$2
>>                (t  1.1,s  1.1) Prof2::lambda$main$0
>>                (t  1.0,s  1.0) Prof2::lambda$main$1
>>                (t  0.9,s  0.9) Prof2::lambda$main$3
>>                (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>    
>>    - With unwind from vtable stub
>>    
>>    Flat Profile (by method):
>>            (t 74.1,s 70.3) Prof2::main
>>            (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>>            (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>>            (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>>            (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>>            (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>>            (t  1.2,s  1.2) Prof2::lambda$main$2
>>            (t  0.9,s  0.9) Prof2::lambda$main$3
>>            (t  0.9,s  0.9) Prof2::lambda$main$1
>>            (t  0.7,s  0.7) Prof2::lambda$main$0
>>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>    
>>    We attribute the vtable stub to the caller and not the callee, which is
>>    already an improvement from the existing case.
>>  - Allow AsyncGetCallTrace and JFR to unwind stack from nmethod's prolog
>>    
>>    When sampling hits the prolog of a method, Hotspot assumes it's unable
>>    to parse the frame. This change allows to parse such frame on x86 by
>>    specializing which instruction it's hitting in the prolog.
>>    
>>    The results are as follows:
>>    
>>    - Baseline:
>>    
>>    Flat Profile (by method):
>>            (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>>            (t 39.2,s 35.2) Prof2::main
>>            (t  1.4,s  1.4) Prof2::lambda$main$3
>>            (t  1.0,s  1.0) Prof2::lambda$main$2
>>            (t  0.9,s  0.9) Prof2::lambda$main$1
>>            (t  0.7,s  0.7) Prof2::lambda$main$0
>>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>            (t  0.0,s  0.0) java.lang.Thread::exit
>>            (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>>            (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>>            (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>>            (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
>>    
>>    - With incomplete frame parsing:
>>    
>>    Flat Profile (by method):
>>            (t 39.3,s 39.3) AGCT::Unknown Java[ERR=-5]
>>            (t 40.3,s 36.1) Prof2::main
>>            (t  6.4,s  5.3) Prof2$$Lambda$28.0x0000000800081000::get
>>            (t  6.1,s  5.1) Prof2$$Lambda$29.0x0000000800081220::get
>>            (t  6.0,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>>            (t  6.1,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>>            (t  1.1,s  1.1) Prof2::lambda$main$2
>>            (t  1.1,s  1.1) Prof2::lambda$main$0
>>            (t  1.0,s  1.0) Prof2::lambda$main$1
>>            (t  0.9,s  0.9) Prof2::lambda$main$3
>>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>            (t  0.0,s  0.0) java.util.Locale::getInstance
>>            (t  0.0,s  0.0) AGCT::Not walkable Java[ERR=-6]
>>            (t  0.0,s  0.0) jdk.internal.loader.BuiltinClassLoader::loadClassOrNull
>>            (t  0.0,s  0.0) java.lang.ClassLoader::loadClass
>>            (t  0.0,s  0.0) sun.net.util.URLUtil::urlNoFragString
>>            (t  0.0,s  0.0) java.lang.Class::forName0
>>            (t  0.0,s  0.0) java.util.Locale::initDefault
>>            (t  0.0,s  0.0) jdk.internal.loader.BuiltinClassLoader::loadClass
>>            (t  0.0,s  0.0) jdk.internal.loader.URLClassPath::getLoader
>>            (t  0.0,s  0.0) jdk.internal.loader.URLClassPath::getResource
>>            (t  0.0,s  0.0) java.lang.String::toLowerCase
>>            (t  0.0,s  0.0) sun.launcher.LauncherHelper::loadMainClass
>>            (t  0.0,s  0.0) sun.launcher.LauncherHelper::checkAndLoadMain
>>            (t  0.0,s  0.0) java.util.Locale::<clinit>
>>            (t  0.0,s  0.0) jdk.internal.loader.BuiltinClassLoader::findClassOnClassPathOrNull
>>            (t  0.0,s  0.0) jdk.internal.loader.ClassLoaders$AppClassLoader::loadClass
>>            (t  0.0,s  0.0) java.lang.Class::forName
>>    
>>    The program is as follows:
>>    
>>    ```
>>    import java.util.function.Supplier;
>>    
>>    public class Prof2 {
>>    
>>        public static void main(String[] args) {
>>            var rand = new java.util.Random(0);
>>            Supplier[] suppliers = {
>>                    () -> 0,
>>                    () -> 1,
>>                    () -> 2,
>>                    () -> 3,
>>            };
>>    
>>            long sum = 0;
>>            for (int i = 0; i >= 0; i++) {
>>                sum += (int)suppliers[i % suppliers.length].get();
>>            }
>>        }
>>    }
>>    ```
>>    
>>    We see that the results are particularely useful in this case as the
>>    methods are very short (it only returns an integer), and the probability
>>    of hitting the prolog is then very high.
>>  - Allow AsyncGetCallTrace and JFR to walk a stub frame
>>    
>>    When the signal sent for AsyncGetCallTrace or JFR would land on a stub
>>    (like arraycopy), it wouldn't be able to detect the sender (caller)
>>    frame because `_cb->frame_size() == 0`.
>>    
>>    Because we fully control how the prolog and epilog of stub code is
>>    generated, we know there are two cases:
>>    1. A stack frame is allocated via macroAssembler->enter(), and consists
>>    in `push rbp; mov rsp, rbp;`.
>>    2. No stack frames are allocated and rbp is left unchanged and rsp is
>>    decremented with the `call` instruction that push the return `pc` on the
>>    stack.
>>    
>>    For case 1., we can easily know the sender frame by simply looking at
>>    rbp, especially since we know that all stubs preserve the frame pointer
>>    (on x86 at least).
>>    
>>    For case 2., we end up returning the sender's sender, but that already
>>    gives us more information than what we have today.
>>    
>>    The results are as follows:
>>    
>>    - Baseline:
>>    
>>    Flat Profile (by method):
>>            (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>>            (t  0.5,s  0.2) Prof1::main
>>            (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>>            (t  0.0,s  0.0) java.lang.String::getBytes
>>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>>            (t  0.0,s  0.0) java.lang.StringBuilder::delete
>>            (t  0.2,s  0.0) java.lang.StringBuilder::append
>>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>>            (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>>    
>>    - With StubRoutinesBlob::FrameParser
>>    
>>    Flat Profile (by method):
>>            (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>            (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>>            (t 99.8,s  0.2) Prof1::main
>>            (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>            (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>>            (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>>            (t 98.8,s  0.0) java.lang.StringBuilder::append
>>            (t  0.9,s  0.0) java.lang.StringBuilder::delete
>>    
>>    The program is as follows:
>>    
>>    ```
>>    public class Prof1 {
>>    
>>        public static void main(String[] args) {
>>            StringBuilder sb = new StringBuilder();
>>            for (int i = 0; i < 1000000; i++) {
>>                sb.append("ab");
>>                sb.delete(0, 1);
>>            }
>>            System.out.println(sb.length());
>>        }
>>    }
>>    ```
>>    
>>    We now account for the arraycopy stub which is called by
>>    AbstractStringBuilder::ensureCapacityInternal. It was previously ignored
>>    because it would not know how to parse the frame for the arraycopy stub
>>    and would fall in the AGCT::Unknown Java[ERR=-5] section.
>>    
>>    However, it still isn't perfect since it doesn't point to the arraycopy stub
>>    directly.
>>  - Extract sender frame parsing to CodeBlock::FrameParser
>>    
>>    Whether and how a frame is setup is controlled by the code generator
>>    for the specific CodeBlock. The CodeBlock is then in the best place to know how
>>    to parse the sender's frame from the current frame in the given CodeBlock.
>>    
>>    This refactoring proposes to extract this parsing out of `frame` and into a
>>    `CodeBlock::FrameParser`. This FrameParser is then specialized in the relevant
>>    inherited children of CodeBlock.
>>    
>>    This change is to largely facilitate adding new supported cases for JDK-8252417
>>    like runtime stubs.
>
> @dcubed-ojdk , @dholmes-ora would you be willing/able to take a look at this change, pretty please?

Sorry @jbachorik  but frames and code-blobs are not an area I know.

David

-------------

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

From coleenp at openjdk.java.net  Mon Aug 23 12:17:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 23 Aug 2021 12:17:33 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String [v2]
In-Reply-To: <7Ad-ey2I75iDXYQbxxeOlV4jpBmfJ07kOuc5oPFp70Y=.6075d8d0-6591-463d-a546-a40375ac9e30@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
 <7Ad-ey2I75iDXYQbxxeOlV4jpBmfJ07kOuc5oPFp70Y=.6075d8d0-6591-463d-a546-a40375ac9e30@github.com>
Message-ID: <haiYwcwzzzPZNb88Xd_j6fiWUiCXW6OOOZMAm9G0DR8=.a711b7e1-6314-4f76-9f24-72f13f7ddeb4@github.com>

On Mon, 23 Aug 2021 08:56:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of merging `is_instance` and `is_instance_inlined`.
>> 
>> Test: build
>
> Albert Mingkun Yang 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:
> 
>  - more rename
>  - Merge branch 'master' into inline
>  - inline

Ok.

-------------

Marked as reviewed by coleenp (Reviewer).

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

From coleenp at openjdk.java.net  Mon Aug 23 12:26:30 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 23 Aug 2021 12:26:30 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be
 safepoint_check_never
In-Reply-To: <b_IR_9FEkLjUSpmh7f0_pdZnRPGdLUa8p52EsZhcW2w=.d5abd930-dc03-485a-927e-a62161ee3eb2@github.com>
References: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
 <b_IR_9FEkLjUSpmh7f0_pdZnRPGdLUa8p52EsZhcW2w=.d5abd930-dc03-485a-927e-a62161ee3eb2@github.com>
Message-ID: <K4TB4kb3ruROU-Ntev5JKMP3FKfhfj_5NJgiMMeNHyM=.2c58fce6-4f1a-473c-aba8-d5bb348d09a7@github.com>

On Mon, 23 Aug 2021 10:53:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
>> Tested with tier1-3.  Tier 4-6 testing in progress.
>
> Hi Coleen,
> 
> Sorry I'm struggling to interpret exactly what these changes mean.  You're redefining the ranking for some locks so that you can then declare that nonleaf locks should not be safepoint-check-never. But in changing those rankings you are also potentially reducing the set of lock nestings that are permitted - so for example a lock that was Barrier and is now leaf+1 can no longer be locked before locking a leaf+2, 3...9. That might be valid but it is not at all obvious how to verify that - testing alone will only cover the common code paths, not necessarily those rarely taken e.g for debugging, logging, exceptional conditions, event processing, non-default flag values ...
> 
> It is not at all clear to me that the ranking strategy and the safepoint-checking strategy align in the way you are implying.
> 
> Could you elaborate on how you expect this to end up looking please.
> 
> Thanks,
> David

@dholmes-ora I put some comments in the main bug (this is a subtask) about what I'm trying to do.  Please comment there and make suggestions that you believe in. If you'd like to discuss, we can do that also.  These subtasks are cleanups that break up the larger problem into smaller pieces. I could share a patch of the whole cleanup with you but I don't think you want that in a pull request!

-------------

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

From tschatzl at openjdk.java.net  Mon Aug 23 12:33:36 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 23 Aug 2021 12:33:36 GMT
Subject: RFR: 8221360: Eliminate Shared_DirtyCardQ_lock
In-Reply-To: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>
References: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>
Message-ID: <40A3rn1zRkqFmSWboq3x6SKGNwG1zLfH3v8NqGacryI=.897a21a1-7504-48c6-84de-e3b6bb2b3a99@github.com>

On Sat, 14 Aug 2021 23:57:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the handling of a very rare race condition in
> concurrent refinement.  There is a situation where we many be unable to
> process a card and need to re-dirty and re-enqueue it for later processing.
> 
> The old code handled this using a shared dirty card queue, which various
> other places needed to know about as well.  This was the user of the
> Shared_DirtyCardQ_lock.  It was the only remaining Mutex whose rank is based
> on Mutex::access.
> 
> An option for eliminating that lock was to use a lock-free queue.  But
> rather than take on that complexity, we instead brute-force the problem.
> The new implementation simply allocates and enqueues an entire buffer for
> the one card that needs to be reprocessed.  Those operations are already
> lock-free.  The extra cost doesn't really matter, since this situation
> almost never arises.
> 
> This is now done inline in refine_card_concurrently.  It's not worth the
> overhead of a class for what is now just a few lines of code needed in
> exactly one place.  Places that knew about the shared queue in order to
> flush/reset it at certain points no longer have such responsibilities.
> 
> This change also renders JDK-8214997 moot, since there aren't any 'access'
> locks.
> https://bugs.openjdk.java.net/browse/JDK-8214997
> Crash holding 'access' lock can deadlock in JVMCI compiler thread
> 
> This change also allows the removal of Mutex::access.  That's being left to
> a new enhancement, since I think it also allows removing Mutex::tty,
> reverting back to using Mutex::event for the tty_lock.  That is, essentially
> undo JDK-8214315.
> https://bugs.openjdk.java.net/browse/JDK-8272480
> 
> Testing:
> mach5 tier1-5

Another reason probably why these cards are put into the shared DCQS was that that card will be processed at a time when that situation can't re-occur. So this change might cause that card (buffer) to be re-enqueued and reprocessed many times while waiting for that object to get fully visible.
One option to avoid this would be to temporarily raise the refinement threshold to avoid reprocessing, but it is very hard to know when it can be lowered (apart from complications actually doing that).
Another would be to use a non-dcqs lock-free container (e.g. a segmented array) to store all these entries (there may be some implementations around), but that's probably not worth it either, and somewhat ugly to transfer to actual dcqs later for processing.
I assume and I agree that this is a very rare occurrence, so we probably get away with this solution.

src/hotspot/share/gc/g1/g1RemSet.cpp line 1699:

> 1697:   // enqueuing an entire buffer for just this card.
> 1698:   *card_ptr = G1CardTable::dirty_card_val();
> 1699:   G1DirtyCardQueueSet& dcqs = G1BarrierSet::dirty_card_queue_set();

This is just a suggestion: maybe put this code to put and enqueue that card into an extra buffer into an extra method. It does not seem to fit just here.

-------------

Marked as reviewed by tschatzl (Reviewer).

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

From coleenp at openjdk.java.net  Mon Aug 23 12:36:30 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 23 Aug 2021 12:36:30 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be
 safepoint_check_never
In-Reply-To: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
References: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
Message-ID: <_yvAqBNWPO9gt0XX0lFRm4PDetoZDQ0YhrUFvzOPnx4=.6f1c8917-2169-4494-93f4-a87af5a2e31e@github.com>

On Fri, 20 Aug 2021 16:41:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
> Tested with tier1-3.  Tier 4-6 testing in progress.

src/hotspot/share/prims/jvmtiTagMap.cpp line 75:

> 73: JvmtiTagMap::JvmtiTagMap(JvmtiEnv* env) :
> 74:   _env(env),
> 75:   _lock(Mutex::leaf, "JvmtiTagMap_lock", Mutex::_allow_vm_block_flag,

David, note this lock.  Since it allows the VM to block, then making it non-leaf is meaningless, since allowing the VM to block means that once you take this lock, you may NOT take another lock that blocks for safepoint.

src/hotspot/share/runtime/mutexLocker.cpp line 289:

> 287:   def(JfieldIdCreation_lock        , PaddedMutex  , nonleaf+1,   true,  _safepoint_check_always); // jfieldID, Used in VM_Operation
> 288: 
> 289:   def(CompiledIC_lock              , PaddedMutex  , leaf+2,      false, _safepoint_check_never);      // locks VtableStubs_lock, InlineCacheBuffer_lock

In my testing, the CompiledIC_lock only takes other locks that never safepoint check, so this should be at the top of the hierarchy of locks that do that.  OR it can safepoint_check_always.  That might make sense, but I'd rather not change the safepoint checking properties with this change.

src/hotspot/share/runtime/mutexLocker.cpp line 318:

> 316:   def(JfrMsg_lock                  , PaddedMonitor, leaf,        true,  _safepoint_check_always);
> 317:   def(JfrBuffer_lock               , PaddedMutex  , leaf,        true,  _safepoint_check_never);
> 318:   def(JfrStream_lock               , PaddedMutex  , leaf+1,      false, _safepoint_check_never);

This lock is actually unused.

-------------

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

From coleenp at openjdk.java.net  Mon Aug 23 13:03:10 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 23 Aug 2021 13:03:10 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be
 safepoint_check_never [v2]
In-Reply-To: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
References: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
Message-ID: <c9XP_Cq6DAIS35iekHb0Sm6VRJDUKcjamXNeoiHvQsw=.68afb9c7-c4a8-44cc-af2c-1ca118b3b56a@github.com>

> I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
> Tested with tier1-3.  Tier 4-6 testing in progress.

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

  Remove JfrSream_lock and rerun JFR tests.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5203/files
  - new: https://git.openjdk.java.net/jdk/pull/5203/files/fb80fe6c..7aba7c3c

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

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

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

From coleenp at openjdk.java.net  Mon Aug 23 13:27:43 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 23 Aug 2021 13:27:43 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block
Message-ID: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>

See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
Tested with tier1-6.

-------------

Commit messages:
 - 8272797: Mutex with rank safepoint_check_never imply allow_vm_block

Changes: https://git.openjdk.java.net/jdk/pull/5218/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5218&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272797
  Stats: 28 lines in 9 files changed: 5 ins; 0 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5218.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5218/head:pull/5218

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

From kbarrett at openjdk.java.net  Mon Aug 23 13:58:32 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 23 Aug 2021 13:58:32 GMT
Subject: RFR: 8221360: Eliminate Shared_DirtyCardQ_lock
In-Reply-To: <40A3rn1zRkqFmSWboq3x6SKGNwG1zLfH3v8NqGacryI=.897a21a1-7504-48c6-84de-e3b6bb2b3a99@github.com>
References: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>
 <40A3rn1zRkqFmSWboq3x6SKGNwG1zLfH3v8NqGacryI=.897a21a1-7504-48c6-84de-e3b6bb2b3a99@github.com>
Message-ID: <rUlsT8NVOCtfTYNUyagsQTT10o81qk95tuLLE8e79TQ=.04018892-b94c-460f-a0ed-be38b37788ea@github.com>

On Mon, 23 Aug 2021 12:30:16 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Another reason probably why these cards are put into the shared DCQS was that that card will be processed at a time when that situation can't re-occur. So this change might cause that card (buffer) to be re-enqueued and reprocessed many times while waiting for that object to get fully visible.

Dirty card buffers are processed in fifo order, so this single-card buffer
starts at the end of the line. Also, we generally keep some number of cards in
the queue. So it's going to take some time for this card to make it through
all that and be reconsidered.

-------------

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

From ayang at openjdk.java.net  Mon Aug 23 14:04:35 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 23 Aug 2021 14:04:35 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String [v2]
In-Reply-To: <7Ad-ey2I75iDXYQbxxeOlV4jpBmfJ07kOuc5oPFp70Y=.6075d8d0-6591-463d-a546-a40375ac9e30@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
 <7Ad-ey2I75iDXYQbxxeOlV4jpBmfJ07kOuc5oPFp70Y=.6075d8d0-6591-463d-a546-a40375ac9e30@github.com>
Message-ID: <lOW5QtSUTgNJbdBsI4mJq0G68t7Jsj76_0TYE-trD8A=.19173f4b-63f1-44f9-9e71-d60a1c696096@github.com>

On Mon, 23 Aug 2021 08:56:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of merging `is_instance` and `is_instance_inlined`.
>> 
>> Test: build
>
> Albert Mingkun Yang 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:
> 
>  - more rename
>  - Merge branch 'master' into inline
>  - inline

Thank you for the review.

-------------

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

From ayang at openjdk.java.net  Mon Aug 23 14:04:36 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 23 Aug 2021 14:04:36 GMT
Subject: Integrated: 8272778: Consolidate is_instance and is_instance_inlined
 in java_lang_String
In-Reply-To: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
Message-ID: <5YN5gtbgZuu0Es0_0EMWUtYZpxTuRpLBbsw-9T-CTuI=.ef2547fa-98c5-416d-9942-ae22933df8e7@github.com>

On Fri, 20 Aug 2021 13:31:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of merging `is_instance` and `is_instance_inlined`.
> 
> Test: build

This pull request has now been integrated.

Changeset: 594e5161
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/594e5161b48382d61509b4969bc8f52c3c076452
Stats:     16 lines in 11 files changed: 0 ins; 4 del; 12 mod

8272778: Consolidate is_instance and is_instance_inlined in java_lang_String

Reviewed-by: coleenp, redestad

-------------

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

From tschatzl at openjdk.java.net  Mon Aug 23 14:05:34 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 23 Aug 2021 14:05:34 GMT
Subject: RFR: 8221360: Eliminate Shared_DirtyCardQ_lock
In-Reply-To: <rUlsT8NVOCtfTYNUyagsQTT10o81qk95tuLLE8e79TQ=.04018892-b94c-460f-a0ed-be38b37788ea@github.com>
References: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>
 <40A3rn1zRkqFmSWboq3x6SKGNwG1zLfH3v8NqGacryI=.897a21a1-7504-48c6-84de-e3b6bb2b3a99@github.com>
 <rUlsT8NVOCtfTYNUyagsQTT10o81qk95tuLLE8e79TQ=.04018892-b94c-460f-a0ed-be38b37788ea@github.com>
Message-ID: <p7E_50u8KvPgmtSffz8WZ2KDLrKldqqoi61xHODXBVs=.6c112ba5-3edf-406c-94aa-d81ae1d1427a@github.com>

On Mon, 23 Aug 2021 13:55:11 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > Another reason probably why these cards are put into the shared DCQS was that that card will be processed at a time when that situation can't re-occur. So this change might cause that card (buffer) to be re-enqueued and reprocessed many times while waiting for that object to get fully visible.
> 
> Dirty card buffers are processed in fifo order, so this single-card buffer
> starts at the end of the line. Also, we generally keep some number of cards in
> the queue. So it's going to take some time for this card to make it through
> all that and be reconsidered.

I agree that there should typically be enough delay until that buffer/card gets reprocessed.

-------------

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

From shade at openjdk.java.net  Mon Aug 23 14:10:50 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 23 Aug 2021 14:10:50 GMT
Subject: RFR: 8272838: Remove CriticalJNI tests from tier1
Message-ID: <G0YRVmfZwtC0ZABcgkEE-nBwHRu7XLc1WoFkHn4wArc=.9cc5f88e-ead0-4a1a-bc67-729934217905@github.com>

See the bug report for more discussion. These tests are tied in Epsilon and Shenandoah test groups, so I rehashed those a bit. Note there are no `tier2` or `tier3` test groups in Hotspot yet, which means these tests would only run as part of Epsilon and Shenandoah test suites. I would rehash tier2/3 in the later RFR, while hooking up more runtime and GC tests there.

Motivational run time improvements:


$  make run-test TEST=hotspot:tier1

# Before
real	8m9.678s
user	289m59.304s
sys	27m46.347s

# After
real	7m53.359s    # 15 seconds saved
user	278m49.104s  # 11 minutes saved
sys	28m2.516s


Additional testing:
 - [x] Checked `hotspot:tier1` run test lists before/after the patch, the difference is only these two lists
 - [x] Some test performance measurements.

-------------

Commit messages:
 - 8272838: Remove CriticalJNI tests from tier1

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

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

From shade at openjdk.java.net  Mon Aug 23 15:19:46 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 23 Aug 2021 15:19:46 GMT
Subject: RFR: 8272846: Move some runtime/Metaspace/elastic/ tests out of tier1
Message-ID: <u0J-YJ8NjWb9Q3-mc_PZsYF5jRrtCmOLJiVAJPPOsLU=.ac7fb5fe-40e2-4f46-994d-786d033985f7@github.com>

See the bug report for more discussion. Attention @tstuefe -- is it time yet to do this?

Motivational run time improvements:


$  make run-test TEST=hotspot:tier1

# Before
real	8m9.678s
user	289m59.304s
sys	27m46.347s

# After
real	7m27.566s
user	284m4.947s
sys	27m33.724s


Additional testing:
 - [x] `tier1` no longer runs these tests
 - [x] `hotspot_tier2_runtime` runs these tests

-------------

Commit messages:
 - Move

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

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

From never at openjdk.java.net  Mon Aug 23 18:27:29 2021
From: never at openjdk.java.net (Tom Rodriguez)
Date: Mon, 23 Aug 2021 18:27:29 GMT
Subject: RFR: 8272736: [JVMCI] Add API for reading and writing JVMCI
 thread locals [v2]
In-Reply-To: <FJIXpoEfIfba_hq0LdZLQ1bUeiXUEy2WebyW66VIhAk=.7b3b3e30-3d5b-4118-b839-4944d18f469e@github.com>
References: <2wNNn6-jgpJE9sKYjwaCt2R-GtD9qdCpkDJN2pq1Ras=.4154e88e-2047-4d85-990d-b774efdf148c@github.com>
 <Ug2gd6Ka0FnWzz3cEENZas7BO4XvGtRA3WJ4oSTB5FU=.2161022d-6c43-4fdf-ba1d-ef2ec1525087@github.com>
 <FJIXpoEfIfba_hq0LdZLQ1bUeiXUEy2WebyW66VIhAk=.7b3b3e30-3d5b-4118-b839-4944d18f469e@github.com>
Message-ID: <Qr4MFi8If0-U9_evQd8dhymlNT-LkRT6lCLUKQ1bIQs=.75538a8f-73aa-4a51-adef-c5a58548a68d@github.com>

On Fri, 20 Aug 2021 15:24:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Tom Rodriguez 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.
>
> src/hotspot/share/runtime/thread.hpp line 996:
> 
>> 994:     return _jvmci_reserved1;
>> 995:   }
>> 996: 
> 
> This makes me reprise my wish that this code was in jvmciThread.hpp and you indirect from thread to there.  Can you do that?  There's already an RFE somewhere.

I hadn't forgotten about that but I have been putting it off a bit.  I'll prioritize it.  The RFE is https://bugs.openjdk.java.net/browse/JDK-8137018

-------------

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

From never at openjdk.java.net  Mon Aug 23 18:42:34 2021
From: never at openjdk.java.net (Tom Rodriguez)
Date: Mon, 23 Aug 2021 18:42:34 GMT
Subject: RFR: 8272736: [JVMCI] Add API for reading and writing JVMCI
 thread locals [v2]
In-Reply-To: <Ug2gd6Ka0FnWzz3cEENZas7BO4XvGtRA3WJ4oSTB5FU=.2161022d-6c43-4fdf-ba1d-ef2ec1525087@github.com>
References: <2wNNn6-jgpJE9sKYjwaCt2R-GtD9qdCpkDJN2pq1Ras=.4154e88e-2047-4d85-990d-b774efdf148c@github.com>
 <Ug2gd6Ka0FnWzz3cEENZas7BO4XvGtRA3WJ4oSTB5FU=.2161022d-6c43-4fdf-ba1d-ef2ec1525087@github.com>
Message-ID: <12TkWZ_uRiv0YGdrwO6Dc5kW3QgItJjQmSjpKxZ4bmw=.4e89133a-b86d-437a-a615-89d8eed42ba2@github.com>

On Fri, 20 Aug 2021 05:23:49 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> 8272736: [JVMCI] Add API for reading and writing JVMCI thread locals
>
> Tom Rodriguez 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.

testing was clean.

-------------

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

From never at openjdk.java.net  Mon Aug 23 18:46:32 2021
From: never at openjdk.java.net (Tom Rodriguez)
Date: Mon, 23 Aug 2021 18:46:32 GMT
Subject: Integrated: 8272736: [JVMCI] Add API for reading and writing JVMCI
 thread locals
In-Reply-To: <2wNNn6-jgpJE9sKYjwaCt2R-GtD9qdCpkDJN2pq1Ras=.4154e88e-2047-4d85-990d-b774efdf148c@github.com>
References: <2wNNn6-jgpJE9sKYjwaCt2R-GtD9qdCpkDJN2pq1Ras=.4154e88e-2047-4d85-990d-b774efdf148c@github.com>
Message-ID: <fT9NCo61UOAVdNa4SiKqJcSGYwfna35XhjlLNcCHFos=.c87e38c1-dd95-4a2d-90c4-9d19616df2bd@github.com>

On Thu, 19 Aug 2021 19:27:54 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> 8272736: [JVMCI] Add API for reading and writing JVMCI thread locals

This pull request has now been integrated.

Changeset: ad92033f
Author:    Tom Rodriguez <never at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ad92033fccbf4ec9310ea5b3024be61c082ee5bb
Stats:     137 lines in 6 files changed: 131 ins; 0 del; 6 mod

8272736: [JVMCI] Add API for reading and writing JVMCI thread locals

Reviewed-by: kvn, dnsimon

-------------

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

From serb at openjdk.java.net  Mon Aug 23 19:34:34 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 23 Aug 2021 19:34:34 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <Ng1z8PAjPNJ8IC8xxYp_Px4NlXJ8DWqs6e12eGb5wP0=.09ad1ed7-2788-48cb-a067-76955b5e912c@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <Ng1z8PAjPNJ8IC8xxYp_Px4NlXJ8DWqs6e12eGb5wP0=.09ad1ed7-2788-48cb-a067-76955b5e912c@github.com>
Message-ID: <KyQxSd0IYEEoEC0acPE16G5CIvwqPTVGVZOP1M9Me8o=.f1d93383-8174-4731-8e16-ef72b415b34a@github.com>

On Sun, 22 Aug 2021 18:31:02 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I think it's worth to update _static_ initializer in `sun.datatransfer.DataFlavorUtil.CharsetComparator` too.

Updated as suggested.

-------------

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

From serb at openjdk.java.net  Mon Aug 23 19:34:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 23 Aug 2021 19:34:38 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <OvTvFnSa61RYUr_VO3fRcnjTkxDwYX0VdqwiiGnveBs=.78ea3741-9e90-447b-909c-be7fedf40f8f@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <OvTvFnSa61RYUr_VO3fRcnjTkxDwYX0VdqwiiGnveBs=.78ea3741-9e90-447b-909c-be7fedf40f8f@github.com>
Message-ID: <aKpPQPgoXRthV1BM7HdtVLagya1bBbQnwQNj68kW_q8=.12c01c5d-b0d5-42a7-b7ce-6a03b5d05b59@github.com>

On Sun, 22 Aug 2021 15:09:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sergey Bylokhov 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 14 additional commits since the last revision:
>> 
>>  - Update the usage of Files.readAllLines()
>>  - Update datatransfer
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - 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
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/465eb90c...e7127644
>
> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 342:
> 
>> 340: 
>> 341:         try {
>> 342:             for (String line : Files.readAllLines(statusPath, UTF_8)) {
> 
> The 1-arg readAllLines is specified to use UTF-8 so you can drop the second parameter here if you want.

Thank you for the suggestion, I have fixed this and a few other places as well.

-------------

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

From coleen.phillimore at oracle.com  Mon Aug 23 20:08:34 2021
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 23 Aug 2021 16:08:34 -0400
Subject: RFR: 8272736: [JVMCI] Add API for reading and writing JVMCI
 thread locals [v2]
In-Reply-To: <Qr4MFi8If0-U9_evQd8dhymlNT-LkRT6lCLUKQ1bIQs=.75538a8f-73aa-4a51-adef-c5a58548a68d@github.com>
References: <2wNNn6-jgpJE9sKYjwaCt2R-GtD9qdCpkDJN2pq1Ras=.4154e88e-2047-4d85-990d-b774efdf148c@github.com>
 <Ug2gd6Ka0FnWzz3cEENZas7BO4XvGtRA3WJ4oSTB5FU=.2161022d-6c43-4fdf-ba1d-ef2ec1525087@github.com>
 <FJIXpoEfIfba_hq0LdZLQ1bUeiXUEy2WebyW66VIhAk=.7b3b3e30-3d5b-4118-b839-4944d18f469e@github.com>
 <Qr4MFi8If0-U9_evQd8dhymlNT-LkRT6lCLUKQ1bIQs=.75538a8f-73aa-4a51-adef-c5a58548a68d@github.com>
Message-ID: <66299d67-b420-233a-34d5-5df668ab58d0@oracle.com>


On 8/23/21 2:27 PM, Tom Rodriguez wrote:
> On Fri, 20 Aug 2021 15:24:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>
>>> Tom Rodriguez 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.
>> src/hotspot/share/runtime/thread.hpp line 996:
>>
>>> 994:     return _jvmci_reserved1;
>>> 995:   }
>>> 996:
>> This makes me reprise my wish that this code was in jvmciThread.hpp and you indirect from thread to there.  Can you do that?  There's already an RFE somewhere.
> I hadn't forgotten about that but I have been putting it off a bit.  I'll prioritize it.  The RFE is https://bugs.openjdk.java.net/browse/JDK-8137018
Thank you!
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/5192

From ascarpino at openjdk.java.net  Mon Aug 23 20:07:33 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Mon, 23 Aug 2021 20:07:33 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v12]
In-Reply-To: <zFyCyUjEg9tNFEzslX1ZLt97hCKkdoxNk9ciNloCabU=.fdbd5340-908a-49bf-b6b7-7ee17f2407ab@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <zFyCyUjEg9tNFEzslX1ZLt97hCKkdoxNk9ciNloCabU=.fdbd5340-908a-49bf-b6b7-7ee17f2407ab@github.com>
Message-ID: <eP7iOibLrxlja0xvbiOapwCwGit7AAtbXHOi_aHwQeA=.f58da58e-fd5c-4b34-847b-861bf7afea1c@github.com>

On Fri, 20 Aug 2021 22:43:55 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes to make sure that ghash_long_swap_mask and counter_mask_addr calls are not duplicated

Tier 1-3 passed on linux-x64, windows-x64, macosx-x64, linux-aarch64

-------------

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

From coleenp at openjdk.java.net  Mon Aug 23 20:09:31 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 23 Aug 2021 20:09:31 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be
 safepoint_check_never [v2]
In-Reply-To: <_yvAqBNWPO9gt0XX0lFRm4PDetoZDQ0YhrUFvzOPnx4=.6f1c8917-2169-4494-93f4-a87af5a2e31e@github.com>
References: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
 <_yvAqBNWPO9gt0XX0lFRm4PDetoZDQ0YhrUFvzOPnx4=.6f1c8917-2169-4494-93f4-a87af5a2e31e@github.com>
Message-ID: <kcXG6zNE3-kYGxJAi3Tg-_8cwbfDGDEUlASZj9tSgtM=.b04d1f1e-8664-4cde-8c81-ac5087fd3b2e@github.com>

On Mon, 23 Aug 2021 12:27:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove JfrSream_lock and rerun JFR tests.
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 75:
> 
>> 73: JvmtiTagMap::JvmtiTagMap(JvmtiEnv* env) :
>> 74:   _env(env),
>> 75:   _lock(Mutex::leaf, "JvmtiTagMap_lock", Mutex::_allow_vm_block_flag,
> 
> David, note this lock.  Since it allows the VM to block, then making it non-leaf is meaningless, since allowing the VM to block means that once you take this lock, you may NOT take another lock that blocks for safepoint.

Let me add more detail here.  This code only takes out the oopstorage ranked lock while this lock is held. I don't know why I made it nonleaf+1. Our testing covers this code really well with the jvmti and jdi tests, which are run in the tiered testing.

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Aug 23 20:54:36 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 23 Aug 2021 20:54:36 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <N67-urPlw_TC9qhch8RkndEzRrP3vUMmVDk-e_nEt-g=.b05fa6c6-04b4-449b-8f93-b00ce5f3e81e@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> 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.
>
> Sergey Bylokhov 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 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - 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
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/aaa7beaf...e7127644

Marked as reviewed by turbanoff at github.com (no known OpenJDK username).

-------------

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

From github.com+2249648+johntortugo at openjdk.java.net  Mon Aug 23 22:42:31 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Mon, 23 Aug 2021 22:42:31 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 IGV transformations
In-Reply-To: <cpQ56g49aFl4tHUaFXgyObZewh1djLYR8r5QRgBWyLU=.e09e10fc-533c-4f2a-9bf3-6570b09508fd@github.com>
References: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
 <q4yXuw6KCd6stuAmLaNdI891rKOeN08TjMrXeXkiBkw=.aec2b77b-e487-4cd4-88e0-7b01ecc18eaf@github.com>
 <XgfE5LZPC81gHqf2GuBZ59PylILUaDNS68H2Jl52TvQ=.efdbc2a5-9bc0-4044-9f3e-408cbf8cc64e@github.com>
 <BKEtTh_TfaN9GtjQJeDpjEy-icmG6F1XTwuRtaMndqo=.46ed7685-23bf-4774-b337-c77c101d4585@github.com>
 <USUsq40B5NKY9bMPl2YNHhhOUItCkXx_vvU0v_bU1R0=.549e9028-60a4-4345-8964-95f65df317d0@github.com>
 <2uRU0b0fCTLTdN6jsB9mNpM_3BEgFZz7q4xHWnNG79I=.16186f49-c220-4bf7-aee1-c18f820e92a5@github.com>
 <cpQ56g49aFl4tHUaFXgyObZewh1djLYR8r5QRgBWyLU=.e09e10fc-533c-4f2a-9bf3-6570b09508fd@github.com>
Message-ID: <Y00AhlwMF0CkTa_RgOkEgcsx2P1xNpRN9m1qj0QTIm8=.2f8221ca-87a6-4d88-b0c1-6d5100dcd62b@github.com>

On Tue, 17 Aug 2021 16:59:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> I am **against** moving tests under `/c2` directory. This directory was created to split original set of tests to run in parallel and not related to C2 compiler. I want to have directories in `/compiler` per optimization/transformation type as we have now. For example, `/loopopts` is for C2 only but it is not under `/c2`.
>> 
>> Actually I want to clear `c2` and `c1` directories eventually to move tests to corresponding category directories instead.
>> 
>> So I am for `/compiler/irTests`.
>
>> This directory was created to split original set of tests to run in parallel and not related to C2 compiler
> 
> aren't you mixing this up w/ `tier1_compiler_[1-3]` test group? if you aren't, this was the wrong way to split tests and we need to fix that.
> 
>>  I want to have directories in `/compiler` per `optimization/transformation` type as we have now. For example, `/loopopts` is for C2 only but it is not under `/c2`.
>> Actually I want to clear `c2` and `c1` directories eventually to move tests to corresponding category directories instead.
> 
> I would prefer to clear `/compiler` directory and move c1-specific tests into `/compiler/c1` directory and c2-specific tests into `/compiler/c2` with optimization/transformation type being subdirectories inside `/compiler/c[12]` (and shared/common tests moved to `/compiler/shared`), so `loopopts` tests are to moved to `/compiler/c2/loopopts`. one of the reasons, most of optimizations tests will be compiler-specific and having them together in `/compiler` doesn't make much sense and just makes it harder to navigate/use test base. e.g. if we have all c2 tests in `/compiler/c2`, one can easily run them together to test c2 changes, if c2-specific tests are in several directories in `/compiler`, so one will have to have intrinsic knowledge about all tests in `/compiler` to select the right one.

Should I move all  tests created in this PR to folders under `/compiler/c2/`? Separated by type of optimization - loopOpts, scalarReplacement, etc?

-------------

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

From mseledtsov at openjdk.java.net  Mon Aug 23 22:54:30 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Mon, 23 Aug 2021 22:54:30 GMT
Subject: RFR: 8272846: Move some runtime/Metaspace/elastic/ tests out of
 tier1
In-Reply-To: <u0J-YJ8NjWb9Q3-mc_PZsYF5jRrtCmOLJiVAJPPOsLU=.ac7fb5fe-40e2-4f46-994d-786d033985f7@github.com>
References: <u0J-YJ8NjWb9Q3-mc_PZsYF5jRrtCmOLJiVAJPPOsLU=.ac7fb5fe-40e2-4f46-994d-786d033985f7@github.com>
Message-ID: <syvYn-6CgZaMJdy_poaBEPF9ytmSmsodkBrjvXP7pDY=.940f94c6-a631-4daf-9859-79f5bb2d0b08@github.com>

On Mon, 23 Aug 2021 15:12:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug report for more discussion. Attention @tstuefe -- is it time yet to do this?
> 
> Motivational run time improvements:
> 
> 
> $  make run-test TEST=hotspot:tier1
> 
> # Before
> real	8m9.678s
> user	289m59.304s
> sys	27m46.347s
> 
> # After
> real	7m27.566s
> user	284m4.947s
> sys	27m33.724s
> 
> 
> Additional testing:
>  - [x] `tier1` no longer runs these tests
>  - [x] `hotspot_tier2_runtime` runs these tests

Change looks good to me, thank you. Good improvement in tier1 turn around time.

-------------

Marked as reviewed by mseledtsov (Committer).

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

From hirt at openjdk.java.net  Mon Aug 23 23:40:27 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 23 Aug 2021 23:40:27 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <APS6H9AlsHSVKx62JWEAfdZjjbSJ58Wor7GHYPyhe74=.0c65e5fe-848e-42e9-b61b-890f81a5e1c2@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
 <BWanYitzfyqkvmVIKndceXJDtbA5lBDxKA94gsMt9hY=.4d5d7dc0-e763-499b-9a3c-8ac75f4415e4@github.com>
 <APS6H9AlsHSVKx62JWEAfdZjjbSJ58Wor7GHYPyhe74=.0c65e5fe-848e-42e9-b61b-890f81a5e1c2@github.com>
Message-ID: <bAYTfa-yS2001C0o8PEv6Mc67LU9eTgAe-6GMReuJEY=.92fce6f1-086f-4ce6-97d9-b8aed3321b37@github.com>

On Mon, 23 Aug 2021 10:57:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @dcubed-ojdk , @dholmes-ora would you be willing/able to take a look at this change, pretty please?
>
> Sorry @jbachorik  but frames and code-blobs are not an area I know.
> 
> David

@dholmes-ora, do you know anyone who could be the primary reviewer for this?

@neliasso? @rickard?

-------------

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

From apangin at openjdk.java.net  Tue Aug 24 00:28:31 2021
From: apangin at openjdk.java.net (Andrei Pangin)
Date: Tue, 24 Aug 2021 00:28:31 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v3]
In-Reply-To: <U5QTRyN0fSEVSnt6Dlwtjk8QYbQAXRYFFUN6fJTEvXk=.7bea3615-4fd5-4e3a-bbb4-5c9b4bfe76c2@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <jfohRNi3z8LnjHcxEzmJNhuO7nKKEtBY5bhR-8uycVI=.b410939d-7166-4ea7-a046-c8ca8f2dcc93@github.com>
 <zEfeAKmEcH3klTLjoOc4ww7yMMlaQmasB0LGXYFREDM=.911f044b-665a-4ca1-a604-66e1270ef191@github.com>
 <U5QTRyN0fSEVSnt6Dlwtjk8QYbQAXRYFFUN6fJTEvXk=.7bea3615-4fd5-4e3a-bbb4-5c9b4bfe76c2@github.com>
Message-ID: <2b10zJmYvua1kRntBFLHbMlbetwJEYuviNJ4GN9z9Ko=.d117de14-6e85-4aa3-84c7-e7d88490f9cf@github.com>

On Mon, 19 Jul 2021 07:07:04 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Hi Ludovic,
>> 
>> Thank you for working on this long-standing bug.
>> I like the idea of the proposed solution, but unfortunately it cannot be applied as is. Since the stack walking code runs inside a signal handler, it is very limited in things it can do. In particular, it must not allocate, acquire locks, etc. In your implementation, FrameParser does allocate though.
>> 
>> The issue is not just theoretical: when I ran JDK with this patch with async-profiler, I immediately got the following deadlock:
>> 
>> 
>> (gdb) bt
>> #0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
>> #1  0x00007fa2363ca025 in __GI___pthread_mutex_lock (mutex=0x7fa235da5440 <tc_mutex>)
>>     at ../nptl/pthread_mutex_lock.c:80
>> #2  0x00007fa235696cb6 in ThreadCritical::ThreadCritical() () from /usr/java/jdk-18/lib/server/libjvm.so
>> #3  0x00007fa234b6fe53 in Chunk::next_chop() () from /usr/java/jdk-18/lib/server/libjvm.so
>> #4  0x00007fa234e88523 in frame::safe_for_sender(JavaThread*) () from /usr/java/jdk-18/lib/server/libjvm.so
>> #5  0x00007fa234e838f2 in vframeStreamForte::forte_next() () from /usr/java/jdk-18/lib/server/libjvm.so
>> #6  0x00007fa2349fbb9b in forte_fill_call_trace_given_top(JavaThread*, ASGCT_CallTrace*, int, frame) [clone .isra.20]
>>     () from /usr/java/jdk-18/lib/server/libjvm.so
>> #7  0x00007fa234e8426e in AsyncGetCallTrace () from /usr/java/jdk-18/lib/server/libjvm.so
>> #8  0x00007fa228519312 in Profiler::getJavaTraceAsync(void*, ASGCT_CallFrame*, int) ()
>>    from /mnt/c/Users/Andrei/java/async-profiler/build/libasyncProfiler.so
>> #9  0x00007fa228519c72 in Profiler::recordSample(void*, unsigned long long, int, Event*) ()
>>    from /mnt/c/Users/Andrei/java/async-profiler/build/libasyncProfiler.so
>> #10 0x00007fa2285164f8 in WallClock::signalHandler(int, siginfo_t*, void*) ()
>>    from /mnt/c/Users/Andrei/java/async-profiler/build/libasyncProfiler.so
>> #11 <signal handler called>
>> #12 __pthread_mutex_unlock_usercnt (decr=1, mutex=0x7fa235da5440 <tc_mutex>) at pthread_mutex_unlock.c:41
>> #13 __GI___pthread_mutex_unlock (mutex=0x7fa235da5440 <tc_mutex>) at pthread_mutex_unlock.c:356
>> #14 0x00007fa235696d3b in ThreadCritical::~ThreadCritical() () from /usr/java/jdk-18/lib/server/libjvm.so
>> #15 0x00007fa234b6fe71 in Chunk::next_chop() () from /usr/java/jdk-18/lib/server/libjvm.so
>> #16 0x00007fa234d1ca62 in ClassFileParser::parse_method(ClassFileStream const*, bool, ConstantPool const*, AccessFlags*, JavaThread*) () from /usr/java/jdk-18/lib/server/libjvm.so
>> #17 0x00007fa234d1e338 in ClassFileParser::parse_methods(ClassFileStream const*, bool, AccessFlags*, bool*, bool*, JavaThread*) () from /usr/java/jdk-18/lib/server/libjvm.so
>> #18 0x00007fa234d22459 in ClassFileParser::parse_stream(ClassFileStream const*, JavaThread*) ()
>>    from /usr/java/jdk-18/lib/server/libjvm.so
>> #19 0x00007fa234d2291c in ClassFileParser::ClassFileParser(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const*, ClassFileParser::Publicity, JavaThread*) () from /usr/java/jdk-18/lib/server/libjvm.so
>> #20 0x00007fa2351febb6 in KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const&, JavaThread*) ()
>>    from /usr/java/jdk-18/lib/server/libjvm.so
>> #21 0x00007fa235645b40 in SystemDictionary::resolve_class_from_stream(ClassFileStream*, Symbol*, Handle, ClassLoadInfo const&, JavaThread*) ()
>>    from /usr/java/jdk-18/lib/server/libjvm.so
>> #22 0x00007fa2350bad0a in jvm_define_class_common(char const*, _jobject*, signed char const*, int, _jobject*, char const*, JavaThread*) [clone .constprop.299] ()
>>    from /usr/java/jdk-18/lib/server/libjvm.so
>> #23 0x00007fa2350bae6d in JVM_DefineClassWithSource () from /usr/java/jdk-18/lib/server/libjvm.so
>> #24 0x00007fa236a0ee12 in Java_java_lang_ClassLoader_defineClass1 () from /usr/java/jdk-18/lib/libjava.so
>
> @apangin Thanks for pointing that out! I'm updating it right now and should be pushing an update very soon. I'll also add examples on how it impacts JFR.

Hi @luhenry,
I had a chance to test your patch on realistic applications, and here are my observations:
1. JVM does not crash or hang, which is already a good sign.
2. The amount of `unknown_Java` samples indeed decreased, roughly by a factor of 2.
3. Now the bad news: with this patch, AsyncGetCallTrace starts returning many orphaned (truncated) stack traces that consist of just one or a few top frames.

For example, here are the results of profiling spring-petclinic application startup.
I summarized the amount of AsyncGetCallTrace failures by type in the following table.
Click on the links in the left column to open the entire flame graphs.

? | Success | Failures | unknown_Java | not_walkable_Java | unknown_not_Java | not_walkable_not_Java | Truncated
-- | -- | -- | -- | -- | -- | -- | --
[Baseline](https://cr.openjdk.java.net/~apangin/8178287/flamegraph/baseline.html) | 86.17% | 13.83% | 7.55% | 1.54% | 2.28% | 2.45% | 0.01%
[AGCT patch](https://cr.openjdk.java.net/~apangin/8178287/flamegraph/agct-patch.html) | 89.75% | 10.25% | 3.77% | 1.02% | 2.26% | - | 3.20%
[Async-profiler](https://cr.openjdk.java.net/~apangin/8178287/flamegraph/async-profiler.html) | 98.12% | 1.88% | 1.45% | 0.29% | 0.09% | - | 0.05%
[Async-profiler with?patch](https://cr.openjdk.java.net/~apangin/8178287/flamegraph/async-profiler-patch.html) | 94.95% | 5.05% | 1.21% | 0.05% | 0.10% | - | 3.69%

My biggest concern is the large number (>3%) of truncated stack traces. The probem is, such stack traces are indistinguishable (by the tools) from normal stack traces, and therefore the tools will display misleading information to a user, without even knowing that something went wrong. In this sense I'd prefer to return an error code rather than an invalid stack trace.

The above table illustrates the problem in practice. With the proposed patch, async-profiler actually performs worse than without it, because async-profiler can recover from most AGCT failures on its own, but not when AGCT returns an invalid stack trace instead of an error code.

In view of the aforementioned, I'll ask not to commit this patch before the problem of truncated stack traces is fixed. Thank you.

-------------

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

From github.com+2249648+johntortugo at openjdk.java.net  Tue Aug 24 01:04:23 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Tue, 24 Aug 2021 01:04:23 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 IGV transformations [v2]
In-Reply-To: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
References: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
Message-ID: <d4EmanEIJdKp3MxC6_DONcsJDds1H-j0EdcCQk145mQ=.2ce8dcf9-a8b5-4198-9272-2236733b5605@github.com>

> Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:
> 
> - Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
> - Add more default IR regex's to IR-based test framework.
> - Changes to Sub, Div and Add Ideal nodes to that transformations on Int and Long types are the whenever possible same.
> - Changes to Sub*Node, Div*Node and Add*Node Ideal methods to fix some bugs and include new transformations.
> - New JTREG "ir_transformations" test group under test/hotspot/jtreg.

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

  Reverting changes to Ideal transformations. Removing failing tests. Reverting order of nodes in IRNode.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5135/files
  - new: https://git.openjdk.java.net/jdk/pull/5135/files/dabaf8fb..22565304

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

  Stats: 266 lines in 8 files changed: 70 ins; 184 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5135/head:pull/5135

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

From sspitsyn at openjdk.java.net  Tue Aug 24 05:39:29 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 Aug 2021 05:39:29 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <DGifHTg7nIn5v9jLtDHTWvj1SxNfv3DxVz5Y4FaRCxY=.7f279e15-526c-469b-8872-4504fde721bd@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
 <DGifHTg7nIn5v9jLtDHTWvj1SxNfv3DxVz5Y4FaRCxY=.7f279e15-526c-469b-8872-4504fde721bd@github.com>
Message-ID: <ZInvKtjBA0wKEQm2RO1rkIXHwl70SiHRsPKzt6Lyjm4=.28e867f1-9864-456e-93d0-bf575ff67fd5@github.com>

On Wed, 18 Aug 2021 19:16:39 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Ok. Do you know who should be the primary reviewer? Rickard B?ckman? Nils Eliasson?

Markus,
There is no primary reviewer for this area as it is officially unsupported.
Also, the problem is that we have no test coverage in this area.
It is not easy to take a responsibility without it.

-------------

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

From stuefe at openjdk.java.net  Tue Aug 24 05:44:26 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 24 Aug 2021 05:44:26 GMT
Subject: RFR: 8272846: Move some runtime/Metaspace/elastic/ tests out of
 tier1
In-Reply-To: <u0J-YJ8NjWb9Q3-mc_PZsYF5jRrtCmOLJiVAJPPOsLU=.ac7fb5fe-40e2-4f46-994d-786d033985f7@github.com>
References: <u0J-YJ8NjWb9Q3-mc_PZsYF5jRrtCmOLJiVAJPPOsLU=.ac7fb5fe-40e2-4f46-994d-786d033985f7@github.com>
Message-ID: <7qeOERBH0ax0KSYm3U7vKJYjUezoIM8EgDtmsObrCAs=.b3f7f944-6424-4cd0-a148-9107c4581559@github.com>

On Mon, 23 Aug 2021 15:12:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug report for more discussion. Attention @tstuefe -- is it time yet to do this?
> 
> Motivational run time improvements:
> 
> 
> $  make run-test TEST=hotspot:tier1
> 
> # Before
> real	8m9.678s
> user	289m59.304s
> sys	27m46.347s
> 
> # After
> real	7m27.566s
> user	284m4.947s
> sys	27m33.724s
> 
> 
> Additional testing:
>  - [x] `tier1` no longer runs these tests
>  - [x] `hotspot_tier2_runtime` runs these tests

Looks good. They still would be run as part of tier2, right? Speaking of which, is there a description somewhere what the tiers  mean and what the rules are for adding things to them?

-------------

Marked as reviewed by stuefe (Reviewer).

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

From david.holmes at oracle.com  Tue Aug 24 07:43:36 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Aug 2021 17:43:36 +1000
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <bAYTfa-yS2001C0o8PEv6Mc67LU9eTgAe-6GMReuJEY=.92fce6f1-086f-4ce6-97d9-b8aed3321b37@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
 <BWanYitzfyqkvmVIKndceXJDtbA5lBDxKA94gsMt9hY=.4d5d7dc0-e763-499b-9a3c-8ac75f4415e4@github.com>
 <APS6H9AlsHSVKx62JWEAfdZjjbSJ58Wor7GHYPyhe74=.0c65e5fe-848e-42e9-b61b-890f81a5e1c2@github.com>
 <bAYTfa-yS2001C0o8PEv6Mc67LU9eTgAe-6GMReuJEY=.92fce6f1-086f-4ce6-97d9-b8aed3321b37@github.com>
Message-ID: <64a8287e-f8e9-aed7-b870-f08d16af74af@oracle.com>

On 24/08/2021 9:40 am, Marcus Hirt wrote:
> On Mon, 23 Aug 2021 10:57:54 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> @dcubed-ojdk , @dholmes-ora would you be willing/able to take a look at this change, pretty please?
>>
>> Sorry @jbachorik  but frames and code-blobs are not an area I know.
>>
>> David
> 
> @dholmes-ora, do you know anyone who could be the primary reviewer for this?

I don't know sorry.

David

> @neliasso? @rickard?
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4436
> 

From iwalulya at openjdk.java.net  Tue Aug 24 10:08:27 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 24 Aug 2021 10:08:27 GMT
Subject: RFR: 8221360: Eliminate Shared_DirtyCardQ_lock
In-Reply-To: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>
References: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>
Message-ID: <u-0fgNMg1FVHACV6tPOpIIP9Gy1AOaFkJXokI4XEqy8=.ff5bbe0c-82de-49ea-88aa-70cb22665589@github.com>

On Sat, 14 Aug 2021 23:57:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the handling of a very rare race condition in
> concurrent refinement.  There is a situation where we many be unable to
> process a card and need to re-dirty and re-enqueue it for later processing.
> 
> The old code handled this using a shared dirty card queue, which various
> other places needed to know about as well.  This was the user of the
> Shared_DirtyCardQ_lock.  It was the only remaining Mutex whose rank is based
> on Mutex::access.
> 
> An option for eliminating that lock was to use a lock-free queue.  But
> rather than take on that complexity, we instead brute-force the problem.
> The new implementation simply allocates and enqueues an entire buffer for
> the one card that needs to be reprocessed.  Those operations are already
> lock-free.  The extra cost doesn't really matter, since this situation
> almost never arises.
> 
> This is now done inline in refine_card_concurrently.  It's not worth the
> overhead of a class for what is now just a few lines of code needed in
> exactly one place.  Places that knew about the shared queue in order to
> flush/reset it at certain points no longer have such responsibilities.
> 
> This change also renders JDK-8214997 moot, since there aren't any 'access'
> locks.
> https://bugs.openjdk.java.net/browse/JDK-8214997
> Crash holding 'access' lock can deadlock in JVMCI compiler thread
> 
> This change also allows the removal of Mutex::access.  That's being left to
> a new enhancement, since I think it also allows removing Mutex::tty,
> reverting back to using Mutex::event for the tty_lock.  That is, essentially
> undo JDK-8214315.
> https://bugs.openjdk.java.net/browse/JDK-8272480
> 
> Testing:
> mach5 tier1-5

Marked as reviewed by iwalulya (Committer).

-------------

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

From kbarrett at openjdk.java.net  Tue Aug 24 11:37:53 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 24 Aug 2021 11:37:53 GMT
Subject: RFR: 8221360: Eliminate Shared_DirtyCardQ_lock [v2]
In-Reply-To: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>
References: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>
Message-ID: <V43FgHCCnYJ7gwmuO4bghzAUgxkZSM6cjhw6oeyn3rE=.dad6ddd5-9d16-4e5a-ad71-330d8e85a0b1@github.com>

> Please review this change to the handling of a very rare race condition in
> concurrent refinement.  There is a situation where we many be unable to
> process a card and need to re-dirty and re-enqueue it for later processing.
> 
> The old code handled this using a shared dirty card queue, which various
> other places needed to know about as well.  This was the user of the
> Shared_DirtyCardQ_lock.  It was the only remaining Mutex whose rank is based
> on Mutex::access.
> 
> An option for eliminating that lock was to use a lock-free queue.  But
> rather than take on that complexity, we instead brute-force the problem.
> The new implementation simply allocates and enqueues an entire buffer for
> the one card that needs to be reprocessed.  Those operations are already
> lock-free.  The extra cost doesn't really matter, since this situation
> almost never arises.
> 
> This is now done inline in refine_card_concurrently.  It's not worth the
> overhead of a class for what is now just a few lines of code needed in
> exactly one place.  Places that knew about the shared queue in order to
> flush/reset it at certain points no longer have such responsibilities.
> 
> This change also renders JDK-8214997 moot, since there aren't any 'access'
> locks.
> https://bugs.openjdk.java.net/browse/JDK-8214997
> Crash holding 'access' lock can deadlock in JVMCI compiler thread
> 
> This change also allows the removal of Mutex::access.  That's being left to
> a new enhancement, since I think it also allows removing Mutex::tty,
> reverting back to using Mutex::event for the tty_lock.  That is, essentially
> undo JDK-8214315.
> https://bugs.openjdk.java.net/browse/JDK-8272480
> 
> Testing:
> mach5 tier1-5

Kim Barrett 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 remove_shared_dcq_lock
 - don't use shared dirty card queue

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5118/files
  - new: https://git.openjdk.java.net/jdk/pull/5118/files/7a3d31c3..c8a28ee9

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

  Stats: 6042 lines in 375 files changed: 3855 ins; 1198 del; 989 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5118.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5118/head:pull/5118

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

From kbarrett at openjdk.java.net  Tue Aug 24 11:37:53 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 24 Aug 2021 11:37:53 GMT
Subject: RFR: 8221360: Eliminate Shared_DirtyCardQ_lock [v2]
In-Reply-To: <p7E_50u8KvPgmtSffz8WZ2KDLrKldqqoi61xHODXBVs=.6c112ba5-3edf-406c-94aa-d81ae1d1427a@github.com>
References: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>
 <40A3rn1zRkqFmSWboq3x6SKGNwG1zLfH3v8NqGacryI=.897a21a1-7504-48c6-84de-e3b6bb2b3a99@github.com>
 <rUlsT8NVOCtfTYNUyagsQTT10o81qk95tuLLE8e79TQ=.04018892-b94c-460f-a0ed-be38b37788ea@github.com>
 <p7E_50u8KvPgmtSffz8WZ2KDLrKldqqoi61xHODXBVs=.6c112ba5-3edf-406c-94aa-d81ae1d1427a@github.com>
Message-ID: <DXpcqsOSi60wKXHCnEf15YDInEkhR_SyOjAHt9HUIvE=.a03a452f-f43d-4774-bb7f-4ff0f6e01d45@github.com>

On Mon, 23 Aug 2021 14:02:32 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>>> Another reason probably why these cards are put into the shared DCQS was that that card will be processed at a time when that situation can't re-occur. So this change might cause that card (buffer) to be re-enqueued and reprocessed many times while waiting for that object to get fully visible.
>> 
>> Dirty card buffers are processed in fifo order, so this single-card buffer
>> starts at the end of the line. Also, we generally keep some number of cards in
>> the queue. So it's going to take some time for this card to make it through
>> all that and be reconsidered.
>
>> > Another reason probably why these cards are put into the shared DCQS was that that card will be processed at a time when that situation can't re-occur. So this change might cause that card (buffer) to be re-enqueued and reprocessed many times while waiting for that object to get fully visible.
>> 
>> Dirty card buffers are processed in fifo order, so this single-card buffer
>> starts at the end of the line. Also, we generally keep some number of cards in
>> the queue. So it's going to take some time for this card to make it through
>> all that and be reconsidered.
> 
> I agree that there should typically be enough delay until that buffer/card gets reprocessed.

Thanks @tschatzl and @walulyai for reviews.

-------------

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

From azvegint at openjdk.java.net  Tue Aug 24 13:09:37 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 24 Aug 2021 13:09:37 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <cI5w9AqyTY2y-cy5LJA9fbGFkB2s_-hhoVOCP6w0CaE=.d56a95c4-0a92-45e2-944b-0d0e3dce165e@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> 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.
>
> Sergey Bylokhov 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 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - 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
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/8c6e27c3...e7127644

Marked as reviewed by azvegint (Reviewer).

-------------

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

From kbarrett at openjdk.java.net  Tue Aug 24 13:09:54 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 24 Aug 2021 13:09:54 GMT
Subject: RFR: 8221360: Eliminate Shared_DirtyCardQ_lock [v3]
In-Reply-To: <40A3rn1zRkqFmSWboq3x6SKGNwG1zLfH3v8NqGacryI=.897a21a1-7504-48c6-84de-e3b6bb2b3a99@github.com>
References: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>
 <40A3rn1zRkqFmSWboq3x6SKGNwG1zLfH3v8NqGacryI=.897a21a1-7504-48c6-84de-e3b6bb2b3a99@github.com>
Message-ID: <fbNgmQzTZo6JLe9H1-ltDtSR4SKTrZp1-ovi4aApom8=.81442787-24da-452a-9dc4-a1c06f4c4eca@github.com>

On Mon, 23 Aug 2021 12:15:37 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   helper function for re-enqueue
>
> src/hotspot/share/gc/g1/g1RemSet.cpp line 1699:
> 
>> 1697:   // enqueuing an entire buffer for just this card.
>> 1698:   *card_ptr = G1CardTable::dirty_card_val();
>> 1699:   G1DirtyCardQueueSet& dcqs = G1BarrierSet::dirty_card_queue_set();
> 
> This is just a suggestion: maybe put this code block to put and enqueue that card into an extra buffer into an extra method. It does not seem to fit just here (i.e. all that gory details how to handle a buffer).

I split that out into new helper function enqueue_for_reprocessing.

-------------

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

From kbarrett at openjdk.java.net  Tue Aug 24 13:09:52 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 24 Aug 2021 13:09:52 GMT
Subject: RFR: 8221360: Eliminate Shared_DirtyCardQ_lock [v3]
In-Reply-To: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>
References: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>
Message-ID: <iy0XWz0yGo9cmLBmuvPeL5uC2nkgkqijeckEmRf1iec=.d8776f8a-22e5-4883-a297-2fd5f5755b8d@github.com>

> Please review this change to the handling of a very rare race condition in
> concurrent refinement.  There is a situation where we many be unable to
> process a card and need to re-dirty and re-enqueue it for later processing.
> 
> The old code handled this using a shared dirty card queue, which various
> other places needed to know about as well.  This was the user of the
> Shared_DirtyCardQ_lock.  It was the only remaining Mutex whose rank is based
> on Mutex::access.
> 
> An option for eliminating that lock was to use a lock-free queue.  But
> rather than take on that complexity, we instead brute-force the problem.
> The new implementation simply allocates and enqueues an entire buffer for
> the one card that needs to be reprocessed.  Those operations are already
> lock-free.  The extra cost doesn't really matter, since this situation
> almost never arises.
> 
> This is now done inline in refine_card_concurrently.  It's not worth the
> overhead of a class for what is now just a few lines of code needed in
> exactly one place.  Places that knew about the shared queue in order to
> flush/reset it at certain points no longer have such responsibilities.
> 
> This change also renders JDK-8214997 moot, since there aren't any 'access'
> locks.
> https://bugs.openjdk.java.net/browse/JDK-8214997
> Crash holding 'access' lock can deadlock in JVMCI compiler thread
> 
> This change also allows the removal of Mutex::access.  That's being left to
> a new enhancement, since I think it also allows removing Mutex::tty,
> reverting back to using Mutex::event for the tty_lock.  That is, essentially
> undo JDK-8214315.
> https://bugs.openjdk.java.net/browse/JDK-8272480
> 
> Testing:
> mach5 tier1-5

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

  helper function for re-enqueue

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5118/files
  - new: https://git.openjdk.java.net/jdk/pull/5118/files/c8a28ee9..3b632fe0

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

  Stats: 21 lines in 2 files changed: 11 ins; 1 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5118.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5118/head:pull/5118

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

From tschatzl at openjdk.java.net  Tue Aug 24 13:15:26 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 24 Aug 2021 13:15:26 GMT
Subject: RFR: 8221360: Eliminate Shared_DirtyCardQ_lock [v3]
In-Reply-To: <iy0XWz0yGo9cmLBmuvPeL5uC2nkgkqijeckEmRf1iec=.d8776f8a-22e5-4883-a297-2fd5f5755b8d@github.com>
References: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>
 <iy0XWz0yGo9cmLBmuvPeL5uC2nkgkqijeckEmRf1iec=.d8776f8a-22e5-4883-a297-2fd5f5755b8d@github.com>
Message-ID: <ZcsjZXKkQ_yG3rx32UiYdurPO2aOGtVnqat2LhCLjLU=.d4292edd-bbee-4005-9636-4b8b36c389af@github.com>

On Tue, 24 Aug 2021 13:09:52 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the handling of a very rare race condition in
>> concurrent refinement.  There is a situation where we many be unable to
>> process a card and need to re-dirty and re-enqueue it for later processing.
>> 
>> The old code handled this using a shared dirty card queue, which various
>> other places needed to know about as well.  This was the user of the
>> Shared_DirtyCardQ_lock.  It was the only remaining Mutex whose rank is based
>> on Mutex::access.
>> 
>> An option for eliminating that lock was to use a lock-free queue.  But
>> rather than take on that complexity, we instead brute-force the problem.
>> The new implementation simply allocates and enqueues an entire buffer for
>> the one card that needs to be reprocessed.  Those operations are already
>> lock-free.  The extra cost doesn't really matter, since this situation
>> almost never arises.
>> 
>> This is now done inline in refine_card_concurrently.  It's not worth the
>> overhead of a class for what is now just a few lines of code needed in
>> exactly one place.  Places that knew about the shared queue in order to
>> flush/reset it at certain points no longer have such responsibilities.
>> 
>> This change also renders JDK-8214997 moot, since there aren't any 'access'
>> locks.
>> https://bugs.openjdk.java.net/browse/JDK-8214997
>> Crash holding 'access' lock can deadlock in JVMCI compiler thread
>> 
>> This change also allows the removal of Mutex::access.  That's being left to
>> a new enhancement, since I think it also allows removing Mutex::tty,
>> reverting back to using Mutex::event for the tty_lock.  That is, essentially
>> undo JDK-8214315.
>> https://bugs.openjdk.java.net/browse/JDK-8272480
>> 
>> Testing:
>> mach5 tier1-5
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   helper function for re-enqueue

Still good, thanks.

-------------

Marked as reviewed by tschatzl (Reviewer).

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

From iwalulya at openjdk.java.net  Tue Aug 24 13:15:27 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 24 Aug 2021 13:15:27 GMT
Subject: RFR: 8221360: Eliminate Shared_DirtyCardQ_lock [v3]
In-Reply-To: <iy0XWz0yGo9cmLBmuvPeL5uC2nkgkqijeckEmRf1iec=.d8776f8a-22e5-4883-a297-2fd5f5755b8d@github.com>
References: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>
 <iy0XWz0yGo9cmLBmuvPeL5uC2nkgkqijeckEmRf1iec=.d8776f8a-22e5-4883-a297-2fd5f5755b8d@github.com>
Message-ID: <6cbFegAmnen0nm4pY_l8cmgP3hBydysxpuQ_wKAQE_E=.e8b6acbf-760b-41d4-bff2-1ae4ede08b82@github.com>

On Tue, 24 Aug 2021 13:09:52 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the handling of a very rare race condition in
>> concurrent refinement.  There is a situation where we many be unable to
>> process a card and need to re-dirty and re-enqueue it for later processing.
>> 
>> The old code handled this using a shared dirty card queue, which various
>> other places needed to know about as well.  This was the user of the
>> Shared_DirtyCardQ_lock.  It was the only remaining Mutex whose rank is based
>> on Mutex::access.
>> 
>> An option for eliminating that lock was to use a lock-free queue.  But
>> rather than take on that complexity, we instead brute-force the problem.
>> The new implementation simply allocates and enqueues an entire buffer for
>> the one card that needs to be reprocessed.  Those operations are already
>> lock-free.  The extra cost doesn't really matter, since this situation
>> almost never arises.
>> 
>> This is now done inline in refine_card_concurrently.  It's not worth the
>> overhead of a class for what is now just a few lines of code needed in
>> exactly one place.  Places that knew about the shared queue in order to
>> flush/reset it at certain points no longer have such responsibilities.
>> 
>> This change also renders JDK-8214997 moot, since there aren't any 'access'
>> locks.
>> https://bugs.openjdk.java.net/browse/JDK-8214997
>> Crash holding 'access' lock can deadlock in JVMCI compiler thread
>> 
>> This change also allows the removal of Mutex::access.  That's being left to
>> a new enhancement, since I think it also allows removing Mutex::tty,
>> reverting back to using Mutex::event for the tty_lock.  That is, essentially
>> undo JDK-8214315.
>> https://bugs.openjdk.java.net/browse/JDK-8272480
>> 
>> Testing:
>> mach5 tier1-5
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   helper function for re-enqueue

Marked as reviewed by iwalulya (Committer).

-------------

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

From kbarrett at openjdk.java.net  Tue Aug 24 13:22:28 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 24 Aug 2021 13:22:28 GMT
Subject: Integrated: 8221360: Eliminate Shared_DirtyCardQ_lock
In-Reply-To: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>
References: <kZ8OK1vcOW3Oo3-ltu0fmoDcvZIXUD4ddVrxXjaS9cU=.e1b2e872-2f83-4e20-915c-b96c1c5364a0@github.com>
Message-ID: <i2nEJt9fWTQ_N260mjdKR5OCZV-XcGtzgzzp_3Z4WUY=.842cc14a-3338-4ec4-9af7-b9f2f7b9b8ad@github.com>

On Sat, 14 Aug 2021 23:57:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the handling of a very rare race condition in
> concurrent refinement.  There is a situation where we many be unable to
> process a card and need to re-dirty and re-enqueue it for later processing.
> 
> The old code handled this using a shared dirty card queue, which various
> other places needed to know about as well.  This was the user of the
> Shared_DirtyCardQ_lock.  It was the only remaining Mutex whose rank is based
> on Mutex::access.
> 
> An option for eliminating that lock was to use a lock-free queue.  But
> rather than take on that complexity, we instead brute-force the problem.
> The new implementation simply allocates and enqueues an entire buffer for
> the one card that needs to be reprocessed.  Those operations are already
> lock-free.  The extra cost doesn't really matter, since this situation
> almost never arises.
> 
> This is now done inline in refine_card_concurrently.  It's not worth the
> overhead of a class for what is now just a few lines of code needed in
> exactly one place.  Places that knew about the shared queue in order to
> flush/reset it at certain points no longer have such responsibilities.
> 
> This change also renders JDK-8214997 moot, since there aren't any 'access'
> locks.
> https://bugs.openjdk.java.net/browse/JDK-8214997
> Crash holding 'access' lock can deadlock in JVMCI compiler thread
> 
> This change also allows the removal of Mutex::access.  That's being left to
> a new enhancement, since I think it also allows removing Mutex::tty,
> reverting back to using Mutex::event for the tty_lock.  That is, essentially
> undo JDK-8214315.
> https://bugs.openjdk.java.net/browse/JDK-8272480
> 
> Testing:
> mach5 tier1-5

This pull request has now been integrated.

Changeset: 0597cde8
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0597cde87deb5ba7bcd84e47b3c10329f758067d
Stats:     176 lines in 9 files changed: 19 ins; 149 del; 8 mod

8221360: Eliminate Shared_DirtyCardQ_lock

Reviewed-by: tschatzl, iwalulya

-------------

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

From scott.gibbons at intel.com  Tue Aug 24 15:07:38 2021
From: scott.gibbons at intel.com (Gibbons, Scott)
Date: Tue, 24 Aug 2021 15:07:38 +0000
Subject: [External] : RE: RFC: x86_64: Fixing the align() macro
In-Reply-To: <2b389666-a268-41f4-6d72-46c7278ff566@oracle.com>
References: <CY4PR11MB00372DFF085FDF1ECEC8E705E2C19@CY4PR11MB0037.namprd11.prod.outlook.com>
 <bd46f335-a977-3679-8cc5-d39a5b391db6@oracle.com>
 <CY4PR11MB0037C15CE06EDF928B1BA33DE2C19@CY4PR11MB0037.namprd11.prod.outlook.com>
 <2b389666-a268-41f4-6d72-46c7278ff566@oracle.com>
Message-ID: <CY4PR11MB0037E84A548649588EED8810E2C59@CY4PR11MB0037.namprd11.prod.outlook.com>

I don't think it's easy to ensure this level of alignment.  How can we do allocation alignment such that the low-order 6 bits of the allocated address are identical?

For example, let's say our original buffer was allocated at 0xXXX20 (i.e., 32-byte aligned, but *not* 64-byte aligned).  We then allocate a new buffer, whose address is 0xXXX80, which *is* 64-byte aligned (and also 32-byte aligned).  This will throw off all 64-byte aligned buffers within the segment, displacing them all by 32 bytes when the copy is made from one to the other.  In order to ensure proper alignment (without fixing up all offsets within the segment) we would need to allocate 32 additional bytes and do some complex bookkeeping to re-adjust the starting address of the segment.

Allocating all segment buffers with 64-byte alignment would be easier and less wasteful of memory.

Thanks,
--Scott Gibbons
Software Development Engineer, Runtime Engineering
  DEVELOPER SOFTWARE ENGINEERING
Ph: 1-503-456-7756
Cell: 1-469-450-8390
2501 NE Century Blvd
Hillsboro, OR 97124
Intel Corporation | www.intel.com

-----Original Message-----
From: dean.long at oracle.com <dean.long at oracle.com> 
Sent: Friday, August 20, 2021 5:52 PM
To: Gibbons, Scott <scott.gibbons at intel.com>; hotspot-dev at openjdk.java.net
Subject: Re: [External] : RE: RFC: x86_64: Fixing the align() macro

On 8/20/21 9:49 AM, Gibbons, Scott wrote:

> So if we copy one code buffer to another with different moduli of 
> starting addresses

Sorry if I wasn't clear.? The idea is to make sure the destination code buffer has the same alignment as the source.? Any padding would be adding when the code buffer is allocated (which is why I said "allocation alignment"), not for individual instructions.

dl


From kvn at openjdk.java.net  Tue Aug 24 16:24:33 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 24 Aug 2021 16:24:33 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v12]
In-Reply-To: <zFyCyUjEg9tNFEzslX1ZLt97hCKkdoxNk9ciNloCabU=.fdbd5340-908a-49bf-b6b7-7ee17f2407ab@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <zFyCyUjEg9tNFEzslX1ZLt97hCKkdoxNk9ciNloCabU=.fdbd5340-908a-49bf-b6b7-7ee17f2407ab@github.com>
Message-ID: <ECM1sWIBQBzzIzCclZDjWW5uKXHTl4-vuwTNYiB2O08=.95dc7d34-afff-4d10-b480-b8c2ebb80e5c@github.com>

On Fri, 20 Aug 2021 22:43:55 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes to make sure that ghash_long_swap_mask and counter_mask_addr calls are not duplicated

Yes, my testing during weekend passed too.
Changes are good for integration.

-------------

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

From shade at openjdk.java.net  Tue Aug 24 16:29:26 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 24 Aug 2021 16:29:26 GMT
Subject: RFR: 8272846: Move some runtime/Metaspace/elastic/ tests out of
 tier1
In-Reply-To: <7qeOERBH0ax0KSYm3U7vKJYjUezoIM8EgDtmsObrCAs=.b3f7f944-6424-4cd0-a148-9107c4581559@github.com>
References: <u0J-YJ8NjWb9Q3-mc_PZsYF5jRrtCmOLJiVAJPPOsLU=.ac7fb5fe-40e2-4f46-994d-786d033985f7@github.com>
 <7qeOERBH0ax0KSYm3U7vKJYjUezoIM8EgDtmsObrCAs=.b3f7f944-6424-4cd0-a148-9107c4581559@github.com>
Message-ID: <5KsyTbUa8N0of1PO_SF1ot6-1IlL_HSm4uNRx9Lli1E=.8c7d5738-151e-4314-b25e-63fdd3957525@github.com>

On Tue, 24 Aug 2021 05:41:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> They still would be run as part of tier2, right? 

Unfortunately there is no `hotspot:tier2` yet, I am adding them in [JDK-8272914](https://bugs.openjdk.java.net/browse/JDK-8272914). I checked these tests run with `hotspot_tier2_runtime`, though, which should be the part of future `hotspot:tier2`.

-------------

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

From xliu at openjdk.java.net  Tue Aug 24 16:55:40 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 24 Aug 2021 16:55:40 GMT
Subject: Withdrawn: 8272554: Add help message about the named pipe support of
 UL.
In-Reply-To: <PumJUqzmFfNGHg7GALm4JQje4rlRUldqqp2hjTgKDNM=.972d6873-2f1a-46b5-b8e7-b2972e371ed7@github.com>
References: <PumJUqzmFfNGHg7GALm4JQje4rlRUldqqp2hjTgKDNM=.972d6873-2f1a-46b5-b8e7-b2972e371ed7@github.com>
Message-ID: <7pjxZcKH60Ne12-utfL_Ea9ReSysARsVZhlDg5GnvTY=.2d1bddf1-2daa-476a-9f44-e42bc1622b07@github.com>

On Fri, 20 Aug 2021 22:52:05 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This patch adds a help message about the named pipe support of the Unified Logging to -Xlog:help and manpage.
> 
> For -Xlog:help, here is the new help message:
> 
> Available log outputs:
>  stdout/stderr
>  file=<filename>
>   If the filename contains %p and/or %t, they will expand to the JVM's PID and startup timestamp, respectively. The filename can be a named pipe when log rotation is disabled.  
> 
> 
> Here is the new manpage content.
> 
>  When using file=filename, specifying %p and/or %t in the file name expands to the JVM's PID and startup timestamp, respectively.  You can also configure text files to handle file rotation based on file size and a number of files to rotate.  For example, to rotate the log file every 10 MB and  keep  5
>  files  in rotation, specify the options filesize=10M, filecount=5.  The target size of the files isn't guaranteed to be exact, it's just an approximate value.  Files are rotated by default with up to 5 rotated files of target size 20 MB, unless configured otherwise.  Specifying filecount=0 means that
>  the log file shouldn't be rotated.  The filename can be a named pipe when log rotation is disabled.  There's a possibility of the pre-existing log file getting overwritten.

This pull request has been closed without being integrated.

-------------

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

From xliu at openjdk.java.net  Tue Aug 24 16:55:39 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 24 Aug 2021 16:55:39 GMT
Subject: RFR: 8272554: Add help message about the named pipe support of UL.
In-Reply-To: <PumJUqzmFfNGHg7GALm4JQje4rlRUldqqp2hjTgKDNM=.972d6873-2f1a-46b5-b8e7-b2972e371ed7@github.com>
References: <PumJUqzmFfNGHg7GALm4JQje4rlRUldqqp2hjTgKDNM=.972d6873-2f1a-46b5-b8e7-b2972e371ed7@github.com>
Message-ID: <Yq2AdIqVBVwqxOSd3vPFliRfylZxp3m8k44A6c3YbAo=.a30722b5-19a7-45cc-a325-091f83f026fc@github.com>

On Fri, 20 Aug 2021 22:52:05 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This patch adds a help message about the named pipe support of the Unified Logging to -Xlog:help and manpage.
> 
> For -Xlog:help, here is the new help message:
> 
> Available log outputs:
>  stdout/stderr
>  file=<filename>
>   If the filename contains %p and/or %t, they will expand to the JVM's PID and startup timestamp, respectively. The filename can be a named pipe when log rotation is disabled.  
> 
> 
> Here is the new manpage content.
> 
>  When using file=filename, specifying %p and/or %t in the file name expands to the JVM's PID and startup timestamp, respectively.  You can also configure text files to handle file rotation based on file size and a number of files to rotate.  For example, to rotate the log file every 10 MB and  keep  5
>  files  in rotation, specify the options filesize=10M, filecount=5.  The target size of the files isn't guaranteed to be exact, it's just an approximate value.  Files are rotated by default with up to 5 rotated files of target size 20 MB, unless configured otherwise.  Specifying filecount=0 means that
>  the log file shouldn't be rotated.  The filename can be a named pipe when log rotation is disabled.  There's a possibility of the pre-existing log file getting overwritten.

yes, I agree with David's comment.  here is my understanding: 
https://bugs.openjdk.java.net/browse/JDK-8272554?focusedCommentId=14443690&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14443690

-------------

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

From svkamath at openjdk.java.net  Tue Aug 24 17:00:29 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Tue, 24 Aug 2021 17:00:29 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v12]
In-Reply-To: <eP7iOibLrxlja0xvbiOapwCwGit7AAtbXHOi_aHwQeA=.f58da58e-fd5c-4b34-847b-861bf7afea1c@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <zFyCyUjEg9tNFEzslX1ZLt97hCKkdoxNk9ciNloCabU=.fdbd5340-908a-49bf-b6b7-7ee17f2407ab@github.com>
 <eP7iOibLrxlja0xvbiOapwCwGit7AAtbXHOi_aHwQeA=.f58da58e-fd5c-4b34-847b-861bf7afea1c@github.com>
Message-ID: <4jIW3v_bs7FY8txtmzr4W1uSxRvPuSruIXagjMm9yJA=.0d35a08d-2cc8-400d-a28e-768f987b9f3b@github.com>

On Mon, 23 Aug 2021 20:04:00 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changes to make sure that ghash_long_swap_mask and counter_mask_addr calls are not duplicated
>
> Tier 1-3 passed on linux-x64, windows-x64, macosx-x64, linux-aarch64

@ascarpino Looks like AES-GCM is ready to be integrated. Can you sponsor this patch? Thank you.

-------------

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

From shade at openjdk.java.net  Tue Aug 24 17:43:44 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 24 Aug 2021 17:43:44 GMT
Subject: RFR: 8272914: Create hotspot:tier2 and hotspot:tier3 test groups
Message-ID: <9aYAUWwQ9ay7S65EIVoEU0eDvIEEh5NFxx6yBtp9tbk=.0f57298c-5e68-4c3a-9237-9e5568225eee@github.com>

Currently, no tests run in `hotspot:tier2` and `hotspot:tier3` groups, yet some groups have the "tier2" and "tier3" in their names. As we move tests from `hotspot:tier1`, they need to land in higher tiers. Therefore, we need `hotspot:tier2` and `hotspot:tier3`.

I had to exclude `InvocationTests` from `tier3`, because they run for a very long time.

Sample runs:


TEST                                              TOTAL  PASS  FAIL ERROR   
jtreg:test/hotspot/jtreg:tier2                      383   383     0     0   

real	10m9.008s
user	418m16.348s
sys	37m16.874s



TEST                                              TOTAL  PASS  FAIL ERROR   
jtreg:test/hotspot/jtreg:tier3                       72    72     0     0   

real	6m51.729s
user	368m37.880s
sys	4m26.574s


These also hook up properly to global `tier2` and `tier3`.

Additional testing:
 - [x] Linux x86_64 fastdebug `hotspot:tier2`
 - [x] Linux x86_64 fastdebug `hotspot:tier3`

-------------

Commit messages:
 - 8272914: Create hotspot:tier2 and hotspot:tier3 test groups

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

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

From shade at openjdk.java.net  Tue Aug 24 17:52:51 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 24 Aug 2021 17:52:51 GMT
Subject: RFR: 8272914: Create hotspot:tier2 and hotspot:tier3 test groups
 [v2]
In-Reply-To: <9aYAUWwQ9ay7S65EIVoEU0eDvIEEh5NFxx6yBtp9tbk=.0f57298c-5e68-4c3a-9237-9e5568225eee@github.com>
References: <9aYAUWwQ9ay7S65EIVoEU0eDvIEEh5NFxx6yBtp9tbk=.0f57298c-5e68-4c3a-9237-9e5568225eee@github.com>
Message-ID: <vicLUUvqnCXrXyAdgyYZD_pwbgc5LNewVYTSCouMCZg=.50e78f32-5578-453d-8754-3879988773d1@github.com>

> Currently, no tests run in `hotspot:tier2` and `hotspot:tier3` groups, yet some groups have the "tier2" and "tier3" in their names. As we move tests from `hotspot:tier1`, they need to land in higher tiers. Therefore, we need `hotspot:tier2` and `hotspot:tier3`.
> 
> I had to exclude `InvocationTests` from `tier3`, because they run for a very long time.
> 
> Sample runs:
> 
> 
> TEST                                              TOTAL  PASS  FAIL ERROR   
> jtreg:test/hotspot/jtreg:tier2                      383   383     0     0   
> 
> real	10m9.008s
> user	418m16.348s
> sys	37m16.874s
> 
> 
> 
> TEST                                              TOTAL  PASS  FAIL ERROR   
> jtreg:test/hotspot/jtreg:tier3                       72    72     0     0   
> 
> real	6m51.729s
> user	368m37.880s
> sys	4m26.574s
> 
> 
> These also hook up properly to global `tier2` and `tier3`.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `hotspot:tier2`
>  - [x] Linux x86_64 fastdebug `hotspot:tier3`

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

  Filter InvocationTests in tier3, leaving the existing group alone

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5241/files
  - new: https://git.openjdk.java.net/jdk/pull/5241/files/2c3fed0c..51ee12e7

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

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

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

From kcr at openjdk.java.net  Tue Aug 24 18:52:38 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 24 Aug 2021 18:52:38 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions [v12]
In-Reply-To: <zFyCyUjEg9tNFEzslX1ZLt97hCKkdoxNk9ciNloCabU=.fdbd5340-908a-49bf-b6b7-7ee17f2407ab@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
 <zFyCyUjEg9tNFEzslX1ZLt97hCKkdoxNk9ciNloCabU=.fdbd5340-908a-49bf-b6b7-7ee17f2407ab@github.com>
Message-ID: <4sbZhUU0jADCb8nd5BiARSAz3_m1iZAJlK4YJHRd1k0=.88b0785f-ea74-4f27-a37a-8c889224f7d2@github.com>

On Fri, 20 Aug 2021 22:43:55 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes to make sure that ghash_long_swap_mask and counter_mask_addr calls are not duplicated

Checking to see if the bot is awake (it should reject my attempt).

-------------

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

From svkamath at openjdk.java.net  Tue Aug 24 18:52:39 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Tue, 24 Aug 2021 18:52:39 GMT
Subject: Integrated: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions
In-Reply-To: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
Message-ID: <VpYWXd_Zj1-RFsUDCy-thyAwK_UUWmEWeMymGsNzm6Q=.8f6d7370-7b7a-48af-b4cb-fe2f45650b0c@github.com>

On Fri, 14 May 2021 00:42:35 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
> Performance gain of ~1.5x - 2x for message sizes 8k and above.

This pull request has now been integrated.

Changeset: 0e7288ff
Author:    Smita Kamath <svkamath at openjdk.org>
Committer: Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0e7288ffbf635b9fdb17e8017e9a4f673ca0501d
Stats:     1436 lines in 21 files changed: 1190 ins; 118 del; 128 mod

8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions

Co-authored-by: Smita Kamath <svkamath at openjdk.org>
Co-authored-by: Tomasz Kantecki <tomasz.kantecki at intel.com>
Co-authored-by: Anthony Scarpino <ascarpino at openjdk.org>
Reviewed-by: kvn, valeriep

-------------

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

From coleenp at openjdk.java.net  Tue Aug 24 22:40:45 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 24 Aug 2021 22:40:45 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v2]
In-Reply-To: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
Message-ID: <AmQO1jU-Gw6g2tv6_XmDibISRqUc_-itKlWW6bFUMqo=.899b4871-6252-414d-9748-dd42168f0537@github.com>

> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
> Tested with tier1-6.

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

  Add simple gtest.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5218/files
  - new: https://git.openjdk.java.net/jdk/pull/5218/files/e7e70f1a..fb83fe81

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

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

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

From dean.long at oracle.com  Wed Aug 25 00:23:25 2021
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Tue, 24 Aug 2021 17:23:25 -0700
Subject: [External] : RE: RFC: x86_64: Fixing the align() macro
In-Reply-To: <CY4PR11MB0037E84A548649588EED8810E2C59@CY4PR11MB0037.namprd11.prod.outlook.com>
References: <CY4PR11MB00372DFF085FDF1ECEC8E705E2C19@CY4PR11MB0037.namprd11.prod.outlook.com>
 <bd46f335-a977-3679-8cc5-d39a5b391db6@oracle.com>
 <CY4PR11MB0037C15CE06EDF928B1BA33DE2C19@CY4PR11MB0037.namprd11.prod.outlook.com>
 <2b389666-a268-41f4-6d72-46c7278ff566@oracle.com>
 <CY4PR11MB0037E84A548649588EED8810E2C59@CY4PR11MB0037.namprd11.prod.outlook.com>
Message-ID: <88d85126-b691-02f3-ac0d-b053b2474ec4@oracle.com>

Hi Scott,


On 8/24/21 8:07 AM, Gibbons, Scott wrote:

> Allocating all segment buffers with 64-byte alignment would be easier


yes.? Are there any disadvantages (see below)?


> and less wasteful of memory.


I disagree, unless you expect most methods to require the higher 
alignment.? Also, I'm worried about icache performance.? We have tricks 
in the JVM to adjust field offsets to decrease dcache conflicts.? 
Doesn't increasing the code alignment have the same negative affect on 
the icache?? Have you tried a prototype and collected performance numbers?

dl


From david.holmes at oracle.com  Wed Aug 25 01:52:36 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Aug 2021 11:52:36 +1000
Subject: RFR: 8272846: Move some runtime/Metaspace/elastic/ tests out of
 tier1
In-Reply-To: <5KsyTbUa8N0of1PO_SF1ot6-1IlL_HSm4uNRx9Lli1E=.8c7d5738-151e-4314-b25e-63fdd3957525@github.com>
References: <u0J-YJ8NjWb9Q3-mc_PZsYF5jRrtCmOLJiVAJPPOsLU=.ac7fb5fe-40e2-4f46-994d-786d033985f7@github.com>
 <7qeOERBH0ax0KSYm3U7vKJYjUezoIM8EgDtmsObrCAs=.b3f7f944-6424-4cd0-a148-9107c4581559@github.com>
 <5KsyTbUa8N0of1PO_SF1ot6-1IlL_HSm4uNRx9Lli1E=.8c7d5738-151e-4314-b25e-63fdd3957525@github.com>
Message-ID: <42a8401d-9049-36ab-81c2-f90a110891a5@oracle.com>

On 25/08/2021 2:29 am, Aleksey Shipilev wrote:
> On Tue, 24 Aug 2021 05:41:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> 
>> They still would be run as part of tier2, right?
> 
> Unfortunately there is no `hotspot:tier2` yet, I am adding them in [JDK-8272914](https://bugs.openjdk.java.net/browse/JDK-8272914). I checked these tests run with `hotspot_tier2_runtime`, though, which should be the part of future `hotspot:tier2`.

Yeah probably an oversight. Our internal tier2 definition is the 
combination of various hotspot_tier2_* groups plus some other stuff 
(e.g. vector API testing). But there isn't a hotspot_tier2 group that 
represents that.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/5222
> 

From dholmes at openjdk.java.net  Wed Aug 25 02:12:23 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 25 Aug 2021 02:12:23 GMT
Subject: RFR: 8272914: Create hotspot:tier2 and hotspot:tier3 test groups
 [v2]
In-Reply-To: <vicLUUvqnCXrXyAdgyYZD_pwbgc5LNewVYTSCouMCZg=.50e78f32-5578-453d-8754-3879988773d1@github.com>
References: <9aYAUWwQ9ay7S65EIVoEU0eDvIEEh5NFxx6yBtp9tbk=.0f57298c-5e68-4c3a-9237-9e5568225eee@github.com>
 <vicLUUvqnCXrXyAdgyYZD_pwbgc5LNewVYTSCouMCZg=.50e78f32-5578-453d-8754-3879988773d1@github.com>
Message-ID: <icQHVKXjt0IpcVn9b_Iy7FJ4CILLjuo0tbqgEQNwm7o=.d3069a2f-841e-44fe-9806-4657fc0c6477@github.com>

On Tue, 24 Aug 2021 17:52:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Currently, no tests run in `hotspot:tier2` and `hotspot:tier3` groups, yet some groups have the "tier2" and "tier3" in their names. As we move tests from `hotspot:tier1`, they need to land in higher tiers. Therefore, we need `hotspot:tier2` and `hotspot:tier3`.
>> 
>> I had to exclude `InvocationTests` from `tier3`, because they run for a very long time.
>> 
>> Sample runs:
>> 
>> 
>> TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/hotspot/jtreg:tier2                      383   383     0     0   
>> 
>> real	10m9.008s
>> user	418m16.348s
>> sys	37m16.874s
>> 
>> 
>> 
>> TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/hotspot/jtreg:tier3                       72    72     0     0   
>> 
>> real	6m51.729s
>> user	368m37.880s
>> sys	4m26.574s
>> 
>> 
>> These also hook up properly to global `tier2` and `tier3`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `hotspot:tier2`
>>  - [x] Linux x86_64 fastdebug `hotspot:tier3`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Filter InvocationTests in tier3, leaving the existing group alone

Hi Aleksey,

A couple of queries below.

Also just to be very clear when Oracle refer to tier1, tier2 etc there is only an approximate mapping to the jtreg groups with those names. Our tier levels also have varied platform support, can include tests not already grouped in a tierN_x, and can run previous tier tests with different flags. So it is important to note that after this change if you refer to "tier3" testing and I refer to "tier3" testing then we are not referring to the exact same thing.

Cheers,
David

test/hotspot/jtreg/TEST.groups line 448:

> 446: 
> 447: tier2 = \
> 448:   -:tier1 \

Not certain but I think the excludes have to come last. Also in theory shouldn't be needed because the tier2_x group should already exclude the tier1_x group.

test/hotspot/jtreg/TEST.groups line 457:

> 455:   -:tier2 \
> 456:   :hotspot_tier3_runtime \
> 457:   -runtime/InvocationTests \

Why are these excluded?

-------------

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

From dholmes at openjdk.java.net  Wed Aug 25 02:27:26 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 25 Aug 2021 02:27:26 GMT
Subject: RFR: 8272914: Create hotspot:tier2 and hotspot:tier3 test groups
 [v2]
In-Reply-To: <icQHVKXjt0IpcVn9b_Iy7FJ4CILLjuo0tbqgEQNwm7o=.d3069a2f-841e-44fe-9806-4657fc0c6477@github.com>
References: <9aYAUWwQ9ay7S65EIVoEU0eDvIEEh5NFxx6yBtp9tbk=.0f57298c-5e68-4c3a-9237-9e5568225eee@github.com>
 <vicLUUvqnCXrXyAdgyYZD_pwbgc5LNewVYTSCouMCZg=.50e78f32-5578-453d-8754-3879988773d1@github.com>
 <icQHVKXjt0IpcVn9b_Iy7FJ4CILLjuo0tbqgEQNwm7o=.d3069a2f-841e-44fe-9806-4657fc0c6477@github.com>
Message-ID: <lBBX1MzM7TSuHu_iTjk5f3jGIgiDabLPy8HHu2thJLA=.0432353d-6a5c-48f6-aeb8-c6dcffc5c59e@github.com>

On Wed, 25 Aug 2021 02:04:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Filter InvocationTests in tier3, leaving the existing group alone
>
> test/hotspot/jtreg/TEST.groups line 457:
> 
>> 455:   -:tier2 \
>> 456:   :hotspot_tier3_runtime \
>> 457:   -runtime/InvocationTests \
> 
> Why are these excluded?

Sorry I missed the comment in the PR.

What is your time criteria?

-------------

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

From sakatakui at oss.nttdata.com  Wed Aug 25 08:27:28 2021
From: sakatakui at oss.nttdata.com (sakatakui)
Date: Wed, 25 Aug 2021 17:27:28 +0900
Subject: Regarding options of error and dump file paths
In-Reply-To: <CAA-vtUxVP1xMwzZvCue4=feMvzqB2nWPxcdWhGrVBYSGgw0w9w@mail.gmail.com>
References: <92708e25-331f-f832-144b-eb00e2b0a4ac@oss.nttdata.com>
 <CAA-vtUxVP1xMwzZvCue4=feMvzqB2nWPxcdWhGrVBYSGgw0w9w@mail.gmail.com>
Message-ID: <42b8604f91851d6fe6d89a6a34b0cce1@oss.nttdata.com>

Hi Thomas,

Thank you for your comment.

> Would it not be way less complex to just set the current working
> directory to wherever you want to direct the output?

I see your point, but setting an output directory with the option is 
handier than changing the current working directory. Changing it 
sometimes makes a mistake.
Also, the working directory is unchangeable in container environment 
when build instructions like Dockerfile already set another directory to 
the working directory and the directory has some sort of meaning.

> We even could give the VM a new option to let it cwd into a specific
> directory after launching.

I appreciate your input. Do you mean that we will be able to change the 
working directory through an existing command with the new option if we 
add it?

Regards,
Koichi

On 23-08-2021 01:54 PM, Thomas St?fe wrote:
> Hi Koichi,
> 
> Would it not be way less complex to just set the current working
> directory to wherever you want to direct the output?
> 
> We even could give the VM a new option to let it cwd into a specific
> directory after launching.
> 
> Cheers, Thomas
> 
> On Mon, Aug 23, 2021 at 5:29 AM Koichi Sakata
> <sakatakui at oss.nttdata.com> wrote:
> 
>> Hi all,
>> 
>> I'm writing to get feedback on my idea about options for error and
>> dump
>> file paths.
>> 
>> First of all, we can specify several options related to error and
>> dump
>> files. For example, the HeapDumpPath option sets the heap dump file
>> and
>> the ErrorFile option sets the hs_error file.
>> 
>> I've felt inconvenience about that because we need to write all path
>> 
>> options to put those files in a specific directory. I also recognize
>> 
>> that they are outputted in the working directory when I run an
>> application with no options. But I'd like to keep them in any
>> directory.
>> So the new option that sets the directory where those files are
>> outputted would be useful, I think.
>> 
>> The new option helps us especially to run applications on containers
>> 
>> like Docker, Kubernetes etc. If we run them without those existing
>> options on containers, files will be put in the local directory of
>> each
>> container. We lose files after we operate the container such as
>> deleting
>> it. The option enables us to keep certainly all error and dump files
>> if
>> we just specify the path of the persistent volume for the new
>> option.
>> 
>> As a concrete example, when we specify
>> -XX:ErrorAndDumpPath=/foo/bar/
>> (This option name is tentative), -XX:+HeapDumpOnOutOfMemoryError and
>> 
>> -XX:StartFlightRecording etc., files are generated in the /foo/bar
>> directory. From my point of view, the option will deal with the
>> following files:
>> - heap dump file (java_pid%p.hprof)
>> - error log file (hs_err_pid%p.log)
>> - JFR emergency dumps (hs_err_pid%p.jfr, hs_oom_pid%p.jfr,
>> hs_soe_pid%p.jfr)
>> - replay file (replay_pid%p.log)
>> 
>> The existing path options should override the new option. If I set
>> -XX:ErrorAndDumpPath=/foo/bar/ and -XX:HeapDumpPath=/foo/baz/, a
>> heap
>> dump file will be in the /foo/baz directory and other files will be
>> created in the /foo/bar.
>> 
>> I would like to hear your point of view. If some people agree to
>> this
>> idea, I will write a patch.
>> 
>> Regards,
>> Koichi

From shade at openjdk.java.net  Wed Aug 25 10:17:06 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 25 Aug 2021 10:17:06 GMT
Subject: RFR: 8272914: Create hotspot:tier2 and hotspot:tier3 test groups
 [v2]
In-Reply-To: <icQHVKXjt0IpcVn9b_Iy7FJ4CILLjuo0tbqgEQNwm7o=.d3069a2f-841e-44fe-9806-4657fc0c6477@github.com>
References: <9aYAUWwQ9ay7S65EIVoEU0eDvIEEh5NFxx6yBtp9tbk=.0f57298c-5e68-4c3a-9237-9e5568225eee@github.com>
 <vicLUUvqnCXrXyAdgyYZD_pwbgc5LNewVYTSCouMCZg=.50e78f32-5578-453d-8754-3879988773d1@github.com>
 <icQHVKXjt0IpcVn9b_Iy7FJ4CILLjuo0tbqgEQNwm7o=.d3069a2f-841e-44fe-9806-4657fc0c6477@github.com>
Message-ID: <es6ya9Dvhe9zbUzibONhEa9f2fBA42kygNrt86E4rVc=.8b370d00-03c0-451d-9705-e243dbbef699@github.com>

On Wed, 25 Aug 2021 02:00:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Filter InvocationTests in tier3, leaving the existing group alone
>
> test/hotspot/jtreg/TEST.groups line 448:
> 
>> 446: 
>> 447: tier2 = \
>> 448:   -:tier1 \
> 
> Not certain but I think the excludes have to come last. Also in theory shouldn't be needed because the tier2_x group should already exclude the tier1_x group.

Right. Actually now I am looking at it, these exclusions are not required. The included tierX* groups should exclude the tests from other tiers. See new commit.

-------------

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

From shade at openjdk.java.net  Wed Aug 25 10:17:03 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 25 Aug 2021 10:17:03 GMT
Subject: RFR: 8272914: Create hotspot:tier2 and hotspot:tier3 test groups
 [v3]
In-Reply-To: <9aYAUWwQ9ay7S65EIVoEU0eDvIEEh5NFxx6yBtp9tbk=.0f57298c-5e68-4c3a-9237-9e5568225eee@github.com>
References: <9aYAUWwQ9ay7S65EIVoEU0eDvIEEh5NFxx6yBtp9tbk=.0f57298c-5e68-4c3a-9237-9e5568225eee@github.com>
Message-ID: <WYwTuH65p5WEItNoE_xEZ_14RcvAznDcVAWRiuzTq3Y=.33fe0dcf-f8df-4c30-abbd-a0d7a63722a2@github.com>

> Currently, no tests run in `hotspot:tier2` and `hotspot:tier3` groups, yet some groups have the "tier2" and "tier3" in their names. As we move tests from `hotspot:tier1`, they need to land in higher tiers. Therefore, we need `hotspot:tier2` and `hotspot:tier3`.
> 
> I had to exclude `InvocationTests` from `tier3`, because they run for a very long time.
> 
> Sample runs:
> 
> 
> TEST                                              TOTAL  PASS  FAIL ERROR   
> jtreg:test/hotspot/jtreg:tier2                      383   383     0     0   
> 
> real	10m9.008s
> user	418m16.348s
> sys	37m16.874s
> 
> 
> 
> TEST                                              TOTAL  PASS  FAIL ERROR   
> jtreg:test/hotspot/jtreg:tier3                       72    72     0     0   
> 
> real	6m51.729s
> user	368m37.880s
> sys	4m26.574s
> 
> 
> These also hook up properly to global `tier2` and `tier3`.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `hotspot:tier2`
>  - [x] Linux x86_64 fastdebug `hotspot:tier3`

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

  Cleaner test group definitions

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5241/files
  - new: https://git.openjdk.java.net/jdk/pull/5241/files/51ee12e7..832dcc3a

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

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

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

From shade at openjdk.java.net  Wed Aug 25 10:17:09 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 25 Aug 2021 10:17:09 GMT
Subject: RFR: 8272914: Create hotspot:tier2 and hotspot:tier3 test groups
 [v2]
In-Reply-To: <lBBX1MzM7TSuHu_iTjk5f3jGIgiDabLPy8HHu2thJLA=.0432353d-6a5c-48f6-aeb8-c6dcffc5c59e@github.com>
References: <9aYAUWwQ9ay7S65EIVoEU0eDvIEEh5NFxx6yBtp9tbk=.0f57298c-5e68-4c3a-9237-9e5568225eee@github.com>
 <vicLUUvqnCXrXyAdgyYZD_pwbgc5LNewVYTSCouMCZg=.50e78f32-5578-453d-8754-3879988773d1@github.com>
 <icQHVKXjt0IpcVn9b_Iy7FJ4CILLjuo0tbqgEQNwm7o=.d3069a2f-841e-44fe-9806-4657fc0c6477@github.com>
 <lBBX1MzM7TSuHu_iTjk5f3jGIgiDabLPy8HHu2thJLA=.0432353d-6a5c-48f6-aeb8-c6dcffc5c59e@github.com>
Message-ID: <mdF6n7jJlSBRo57B7uAdTmnH9__nrRR20lu1n--sonY=.4b22a79e-d6a1-4740-9053-4b7c417fc1df@github.com>

On Wed, 25 Aug 2021 02:24:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/hotspot/jtreg/TEST.groups line 457:
>> 
>>> 455:   -:tier2 \
>>> 456:   :hotspot_tier3_runtime \
>>> 457:   -runtime/InvocationTests \
>> 
>> Why are these excluded?
>
> Sorry I missed the comment in the PR.
> 
> What is your time criteria?

So the current `runtime/InvocationTests` run for about 35 minutes real and 58 minutes user time. This blows up tier3 real time for about 5x. So I chickened out adding them to tier3. But after sleeping on it, I think those still make sense to run in tier3, and then we should optimize the tests themselves, for example with [JDK-8272970](https://bugs.openjdk.java.net/browse/JDK-8272970). See new commit.

-------------

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

From shade at openjdk.java.net  Wed Aug 25 10:21:27 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 25 Aug 2021 10:21:27 GMT
Subject: RFR: 8272914: Create hotspot:tier2 and hotspot:tier3 test groups
 [v2]
In-Reply-To: <icQHVKXjt0IpcVn9b_Iy7FJ4CILLjuo0tbqgEQNwm7o=.d3069a2f-841e-44fe-9806-4657fc0c6477@github.com>
References: <9aYAUWwQ9ay7S65EIVoEU0eDvIEEh5NFxx6yBtp9tbk=.0f57298c-5e68-4c3a-9237-9e5568225eee@github.com>
 <vicLUUvqnCXrXyAdgyYZD_pwbgc5LNewVYTSCouMCZg=.50e78f32-5578-453d-8754-3879988773d1@github.com>
 <icQHVKXjt0IpcVn9b_Iy7FJ4CILLjuo0tbqgEQNwm7o=.d3069a2f-841e-44fe-9806-4657fc0c6477@github.com>
Message-ID: <46joG7EWJP9U5qS2Uw2NSmVGbY47sqUS9iPzZxJV7gg=.55dc975f-abc3-4600-9cd1-732600cbf6c4@github.com>

On Wed, 25 Aug 2021 02:09:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Also just to be very clear when Oracle refer to tier1, tier2 etc there is only an approximate mapping to the jtreg groups with those names. Our tier levels also have varied platform support, can include tests not already grouped in a tierN_x, and can run previous tier tests with different flags. So it is important to note that after this change if you refer to "tier3" testing and I refer to "tier3" testing then we are not referring to the exact same thing.

Noted. This asymmetry is unfortunate, but it does not directly affect this work, I think. If we care enough to sync those up, then since nobody outside Oracle can guess what Oracle's definition of "tier2" and "tier3" is, it seems reasonable to say that the onus is on Oracle to match their definitions for "tier2" and "tier3" with the public test definitions, as much as practically possible.

-------------

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

From eosterlund at openjdk.java.net  Wed Aug 25 15:40:26 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 25 Aug 2021 15:40:26 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be
 safepoint_check_never [v2]
In-Reply-To: <c9XP_Cq6DAIS35iekHb0Sm6VRJDUKcjamXNeoiHvQsw=.68afb9c7-c4a8-44cc-af2c-1ca118b3b56a@github.com>
References: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
 <c9XP_Cq6DAIS35iekHb0Sm6VRJDUKcjamXNeoiHvQsw=.68afb9c7-c4a8-44cc-af2c-1ca118b3b56a@github.com>
Message-ID: <f-L5vU12HtvMGr9v9wrw5iEsU95pFW0sj0DBcwc3HNs=.252802d8-34b4-4ad2-9c68-ed12cd98a0e9@github.com>

On Mon, 23 Aug 2021 13:03:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
>> Tested with tier1-3.  Tier 4-6 testing in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove JfrSream_lock and rerun JFR tests.

So you are enforcing the relationship between safepoint checking and rank. In a way we already had that for special locks. I like it.

-------------

Marked as reviewed by eosterlund (Reviewer).

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Aug 25 17:25:37 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 25 Aug 2021 17:25:37 GMT
Subject: RFR: 8272992: Replace usages of Collections.sort with List.sort call
 in jdk.* modules
Message-ID: <9xbhI0rwD3XbAHZFfQAkJHYivbC5F4N085RuSVWx8HU=.8a470c93-5fee-4981-97e4-afb6cb1147b9@github.com>

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 jdk.* modules

Changes: https://git.openjdk.java.net/jdk/pull/5230/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5230&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272992
  Stats: 57 lines in 22 files changed: 0 ins; 17 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5230.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5230/head:pull/5230

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

From coleenp at openjdk.java.net  Wed Aug 25 18:55:27 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 25 Aug 2021 18:55:27 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be
 safepoint_check_never [v2]
In-Reply-To: <c9XP_Cq6DAIS35iekHb0Sm6VRJDUKcjamXNeoiHvQsw=.68afb9c7-c4a8-44cc-af2c-1ca118b3b56a@github.com>
References: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
 <c9XP_Cq6DAIS35iekHb0Sm6VRJDUKcjamXNeoiHvQsw=.68afb9c7-c4a8-44cc-af2c-1ca118b3b56a@github.com>
Message-ID: <sZxwnAQaWtDOjyuI2VyRII324IdXcH4yJ4JRuXLKGME=.6f769ba6-7546-4ddb-ada2-0f59bf3f6344@github.com>

On Mon, 23 Aug 2021 13:03:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
>> Tested with tier1-3.  Tier 4-6 testing in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove JfrSream_lock and rerun JFR tests.

Yes, eventually I'd like there to be a more strict relationship between rank and safepoint checking, so that's why I moved these locks down in the ranking system.  Thank you Erik!

-------------

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

From coleenp at openjdk.java.net  Wed Aug 25 19:38:39 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 25 Aug 2021 19:38:39 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v3]
In-Reply-To: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
Message-ID: <TNz5Cuv8GP6muRciDQLDfkAJs_153G8y_M2DHoOJ8KI=.151ebf41-1a1b-4a4b-8523-9e2639f0bccc@github.com>

> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
> Tested with tier1-6.

Coleen Phillimore 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 never-block
 - Add simple gtest.
 - 8272797: Mutex with rank safepoint_check_never imply allow_vm_block

-------------

Changes: https://git.openjdk.java.net/jdk/pull/5218/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5218&range=02
  Stats: 38 lines in 9 files changed: 15 ins; 0 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5218.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5218/head:pull/5218

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

From eastig at amazon.co.uk  Wed Aug 25 21:16:29 2021
From: eastig at amazon.co.uk (Astigeevich, Evgeny)
Date: Wed, 25 Aug 2021 21:16:29 +0000
Subject: RFC: AArch64: Implementing spin pauses with ISB
Message-ID: <EDB2660E-4F9A-4FA9-8A08-6E976CAC262B@amazon.com>

Hi Andrew,

>   How application dependent is this? Does it depend on how many threads are
>   contending for a lock? Are there other places (intrinsic monitors, say)
>  where we should do this?

IMHO, we've only scratched the surface of it. The problem is not well modelled by existing public benchmarks.
Yes, it is application dependent at some level.  In case of Thread.onSpinWait it depends on how an application implements spin loops.
Applications having spin loops with several iterations would benefit from short onSpinWait (this is what we've got in customers' benchmarks). Applications calling onSpinWait only couple times would benefit from longer onSpinWait.
"How heavy thread contention should be, what other places", these are still open questions. To answer them we need to detect the issues which is the problem itself.
What we currently use is the trial-and-error approach.

Thanks,
Evgeny

?On 21/08/2021, 11:08, "hotspot-dev on behalf of Andrew Haley" <hotspot-dev-retn at openjdk.java.net on behalf of aph-open at littlepinkcloud.com> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



    On 8/17/21 9:42 PM, Astigeevich, Evgeny wrote:
    >
    >> The ISB instruction wasn't intended to be used for that purpose...
    >
    > It might be a time for YIELD to be a real instruction, especially on Neoverse. High thread contention is a typical situation in server workloads.
    > If it would be great if Neoverse architects consider this.

    Maybe, but recent experience from Intel (where the delay was changed from 20-30
    clocks to 200) causing regressions in some areas, suggests it's very problematic.

    >> Your experiments were with one ISB - did you experiment at all with multiple ISBs? I'm curious as to what the overall effect would be.
    >
    > Yes, there were experiments with 2 ISBs. With 2 ISBs the performance improvements were less. Graviton 2 performance engineers' explanation of this is that spins should target 15-30ns. One ISB allows to be within these limits. Two and more ISBs get longer spins. It increases chances of an expensive code path and the OS to reschedule threads.

    How application dependent is this? Does it depend on how many threads are
    contending for a lock? Are there other places (intrinsic monitors, say)
    where we should do this?

    --
    Andrew Haley  (he/him)
    Java Platform Lead Engineer
    Red Hat UK Ltd. <https://www.redhat.com>
    https://keybase.io/andrewhaley
    EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671




Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.



From pchilanomate at openjdk.java.net  Wed Aug 25 21:39:23 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 25 Aug 2021 21:39:23 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v3]
In-Reply-To: <TNz5Cuv8GP6muRciDQLDfkAJs_153G8y_M2DHoOJ8KI=.151ebf41-1a1b-4a4b-8523-9e2639f0bccc@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
 <TNz5Cuv8GP6muRciDQLDfkAJs_153G8y_M2DHoOJ8KI=.151ebf41-1a1b-4a4b-8523-9e2639f0bccc@github.com>
Message-ID: <DHYywb5cXLtwLhnFliG80cPeZo9OTzMBO_pxu1PjBM4=.5eaf0416-9856-4b7c-a5b6-b3c638b62018@github.com>

On Wed, 25 Aug 2021 19:38:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
>> Tested with tier1-6.
>
> Coleen Phillimore 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 never-block
>  - Add simple gtest.
>  - 8272797: Mutex with rank safepoint_check_never imply allow_vm_block

I agree it makes sense for _safepoint_check_never to imply also NSV. Otherwise a deadlock could happen if the JT blocks for a safepoint in the critical region while there is another JT waiting to acquire the _safepoint_check_never lock, since the safepoint will never start. I guess we don't have such cases today.
If the _allow_vm_block flag is now always true with _safepoint_check_never then I wonder if we should have a separate constructor for the _safepoint_check_never locks that doesn't have the extra boolean parameter and that just calls the current constructor with _allow_vm_block=true.

-------------

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

From coleen.phillimore at oracle.com  Wed Aug 25 21:47:44 2021
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 25 Aug 2021 17:47:44 -0400
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v3]
In-Reply-To: <DHYywb5cXLtwLhnFliG80cPeZo9OTzMBO_pxu1PjBM4=.5eaf0416-9856-4b7c-a5b6-b3c638b62018@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
 <TNz5Cuv8GP6muRciDQLDfkAJs_153G8y_M2DHoOJ8KI=.151ebf41-1a1b-4a4b-8523-9e2639f0bccc@github.com>
 <DHYywb5cXLtwLhnFliG80cPeZo9OTzMBO_pxu1PjBM4=.5eaf0416-9856-4b7c-a5b6-b3c638b62018@github.com>
Message-ID: <fd7b2820-2b56-8e88-7986-b335f33bd79c@oracle.com>


On 8/25/21 5:39 PM, Patricio Chilano Mateo wrote:
> On Wed, 25 Aug 2021 19:38:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>
>>> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
>>> Tested with tier1-6.
>> Coleen Phillimore 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 never-block
>>   - Add simple gtest.
>>   - 8272797: Mutex with rank safepoint_check_never imply allow_vm_block
> I agree it makes sense for _safepoint_check_never to imply also NSV. Otherwise a deadlock could happen if the JT blocks for a safepoint in the critical region while there is another JT waiting to acquire the _safepoint_check_never lock, since the safepoint will never start. I guess we don't have such cases today.

You're right, that is a possible deadlock.

> If the _allow_vm_block flag is now always true with _safepoint_check_never then I wonder if we should have a separate constructor for the _safepoint_check_never locks that doesn't have the extra boolean parameter and that just calls the current constructor with _allow_vm_block=true.

This is a good idea.? The mutexLocker.cpp definitions are done with a 
macro, so I wouldn't change them but it would remove an obvious 
parameter from the other constructor callers.

thanks,

Coleen

>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/5218

From coleenp at openjdk.java.net  Wed Aug 25 23:07:50 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 25 Aug 2021 23:07:50 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v4]
In-Reply-To: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
Message-ID: <pezkXUedVgEjPJKzwwKMXF1CmwDZuL59mICHmUNX4Po=.0160ce37-d285-4ead-8829-23c9ede74e92@github.com>

> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
> Tested with tier1-6.

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

  Remove allow_vm_block parameter if safepoint_check_never.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5218/files
  - new: https://git.openjdk.java.net/jdk/pull/5218/files/285e8eb5..27179b77

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

  Stats: 63 lines in 29 files changed: 11 ins; 9 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5218.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5218/head:pull/5218

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

From coleenp at openjdk.java.net  Wed Aug 25 23:23:29 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 25 Aug 2021 23:23:29 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v4]
In-Reply-To: <pezkXUedVgEjPJKzwwKMXF1CmwDZuL59mICHmUNX4Po=.0160ce37-d285-4ead-8829-23c9ede74e92@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
 <pezkXUedVgEjPJKzwwKMXF1CmwDZuL59mICHmUNX4Po=.0160ce37-d285-4ead-8829-23c9ede74e92@github.com>
Message-ID: <c6Bl6gMFqrXFyesNlrGUyKJ6YxenWMxbxHZBDhR_1uo=.91e54a24-a97e-4197-a90e-cc7584d90179@github.com>

On Wed, 25 Aug 2021 23:07:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
>> Tested with tier1-6.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove allow_vm_block parameter if safepoint_check_never.

I added a 3 argument constructor to Mutex and Monitor so that if _safepoint_check_never will pass true and that parameter is no longer needed in the callers.  With a bigger change to mutexLocker.cpp, I can reorder the parameters so that there's a three argument constructor and allow_vm_block is the last parameter, so can be dependent on the safepoint_check_required one, rather than having default parameters. I don't want to do it here because changing all the lines in mutexLocker.cpp is a bigger change.

   Mutex(int rank, const char *name,
       SafepointCheckRequired safepoint_check_required, bool allow_vm_block);
   Mutex(int rank, const char *name, SafepointCheckRequired safepoint_check_required) :
       Mutex(rank, name, safepoint_check_required, safepoint_check_required == _safepoint_check_never ? true : false) {}

-------------

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

From dholmes at openjdk.java.net  Thu Aug 26 01:54:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 26 Aug 2021 01:54:28 GMT
Subject: RFR: 8272914: Create hotspot:tier2 and hotspot:tier3 test groups
 [v3]
In-Reply-To: <WYwTuH65p5WEItNoE_xEZ_14RcvAznDcVAWRiuzTq3Y=.33fe0dcf-f8df-4c30-abbd-a0d7a63722a2@github.com>
References: <9aYAUWwQ9ay7S65EIVoEU0eDvIEEh5NFxx6yBtp9tbk=.0f57298c-5e68-4c3a-9237-9e5568225eee@github.com>
 <WYwTuH65p5WEItNoE_xEZ_14RcvAznDcVAWRiuzTq3Y=.33fe0dcf-f8df-4c30-abbd-a0d7a63722a2@github.com>
Message-ID: <fMg_vg5ga5Axez0vkH4JCoMZ55UAakgAXMbdAIDEipo=.86f03071-374e-4a8f-b180-9f062ca791e1@github.com>

On Wed, 25 Aug 2021 10:17:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Currently, no tests run in `hotspot:tier2` and `hotspot:tier3` groups, yet some groups have the "tier2" and "tier3" in their names. As we move tests from `hotspot:tier1`, they need to land in higher tiers. Therefore, we need `hotspot:tier2` and `hotspot:tier3`.
>> 
>> Sample runs:
>> 
>> 
>> TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/hotspot/jtreg:tier2                      425   425     0     0   
>> 
>> real	11m45.244s
>> user	433m48.960s
>> sys	38m13.606s
>> 
>> 
>> 
>> TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/hotspot/jtreg:tier3                       80    80     0     0   
>> 
>> real	35m19.031s
>> user	418m45.607s
>> sys	5m41.748s
>> 
>> 
>> These also hook up properly to global `tier2` and `tier3`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `hotspot:tier2`
>>  - [x] Linux x86_64 fastdebug `hotspot:tier3`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaner test group definitions

This seems perfectly fine as a starting point and can easily be refined if needed.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

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

From dholmes at openjdk.java.net  Thu Aug 26 06:04:26 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 26 Aug 2021 06:04:26 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v4]
In-Reply-To: <pezkXUedVgEjPJKzwwKMXF1CmwDZuL59mICHmUNX4Po=.0160ce37-d285-4ead-8829-23c9ede74e92@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
 <pezkXUedVgEjPJKzwwKMXF1CmwDZuL59mICHmUNX4Po=.0160ce37-d285-4ead-8829-23c9ede74e92@github.com>
Message-ID: <68oxwS4QS8-CSRnUoy3Gy7YAlp9_9TpwfXi8GUbXPi4=.9f09e21d-80be-4d9f-b56a-f64d5e398ca6@github.com>

On Wed, 25 Aug 2021 23:07:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
>> Tested with tier1-6.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove allow_vm_block parameter if safepoint_check_never.

Hi Coleen,

I've put a lengthy comment in the JBS issue explaining how I see this change, but the bottom like is that I think it is a perfectly fine simplification.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

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

From david.holmes at oracle.com  Thu Aug 26 06:23:36 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Aug 2021 16:23:36 +1000
Subject: Regarding options of error and dump file paths
In-Reply-To: <92708e25-331f-f832-144b-eb00e2b0a4ac@oss.nttdata.com>
References: <92708e25-331f-f832-144b-eb00e2b0a4ac@oss.nttdata.com>
Message-ID: <8f51414c-86c1-49de-7b5f-4af0fae556aa@oracle.com>

Hi Koichi,

On 23/08/2021 1:29 pm, Koichi Sakata wrote:
> Hi all,
> 
> I'm writing to get feedback on my idea about options for error and dump 
> file paths.
> 
> First of all, we can specify several options related to error and dump 
> files. For example, the HeapDumpPath option sets the heap dump file and 
> the ErrorFile option sets the hs_error file.
> 
> I've felt inconvenience about that because we need to write all path 
> options to put those files in a specific directory. I also recognize 
> that they are outputted in the working directory when I run an 
> application with no options. But I'd like to keep them in any directory. 
> So the new option that sets the directory where those files are 
> outputted would be useful, I think.
> 
> The new option helps us especially to run applications on containers 
> like Docker, Kubernetes etc. If we run them without those existing 
> options on containers, files will be put in the local directory of each 
> container. We lose files after we operate the container such as deleting 
> it. The option enables us to keep certainly all error and dump files if 
> we just specify the path of the persistent volume for the new option.
> 
> As a concrete example, when we specify -XX:ErrorAndDumpPath=/foo/bar/ 
> (This option name is tentative), -XX:+HeapDumpOnOutOfMemoryError and 
> -XX:StartFlightRecording etc., files are generated in the /foo/bar 
> directory. From my point of view, the option will deal with the 
> following files:
> - heap dump file (java_pid%p.hprof)
> - error log file (hs_err_pid%p.log)
> - JFR emergency dumps (hs_err_pid%p.jfr, hs_oom_pid%p.jfr, 
> hs_soe_pid%p.jfr)
> - replay file (replay_pid%p.log)
> 
> The existing path options should override the new option. If I set 
> -XX:ErrorAndDumpPath=/foo/bar/ and -XX:HeapDumpPath=/foo/baz/, a heap 
> dump file will be in the /foo/baz directory and other files will be 
> created in the /foo/bar.
> 
> I would like to hear your point of view. If some people agree to this 
> idea, I will write a patch.

My initial reaction was that this seemed something better handled in a 
launch script because I figured if you had complex needs in relation to 
where these files were being placed, then you'd use a launch script to 
help manage that anyway.

But I can see there would be some convenience to controlling the output 
directory without also having to restate the default file names.

Having an explicit option override the default directory option is a 
good idea, but I'm not sure it is that clear cut. If you can specify a 
relative directory and file name for a given dump file, might you not 
want that to be relative to the specified default path, rather than 
relative to the pwd?

And we actually have quite a lot of potential output files from:
  - GC (heap dumps)
  - JIT (replay files)
  - hs_err files
  - JFR (a number of files)
  - jcmd/dcmd dumps?
  - Unified logging?

I think figuring out the exact details of how this should work, and 
interact with all the different files involved may be more involved than 
just prepending a path component.

I also think I would need to hear much greater demand, with detailed 
usage expectations, before supporting this.

Just my 2c.

Cheers,
David
-----

> Regards,
> Koichi

From shade at openjdk.java.net  Thu Aug 26 06:54:25 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 26 Aug 2021 06:54:25 GMT
Subject: RFR: 8272914: Create hotspot:tier2 and hotspot:tier3 test groups
 [v3]
In-Reply-To: <fMg_vg5ga5Axez0vkH4JCoMZ55UAakgAXMbdAIDEipo=.86f03071-374e-4a8f-b180-9f062ca791e1@github.com>
References: <9aYAUWwQ9ay7S65EIVoEU0eDvIEEh5NFxx6yBtp9tbk=.0f57298c-5e68-4c3a-9237-9e5568225eee@github.com>
 <WYwTuH65p5WEItNoE_xEZ_14RcvAznDcVAWRiuzTq3Y=.33fe0dcf-f8df-4c30-abbd-a0d7a63722a2@github.com>
 <fMg_vg5ga5Axez0vkH4JCoMZ55UAakgAXMbdAIDEipo=.86f03071-374e-4a8f-b180-9f062ca791e1@github.com>
Message-ID: <_3HsvYsJzIqcQNT8QB1mzkk_xTYO6lA5SbKX5fAQqqo=.4b5353ae-c8e3-4e9d-b90b-37452a97e4c9@github.com>

On Thu, 26 Aug 2021 01:51:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleaner test group definitions
>
> This seems perfectly fine as a starting point and can easily be refined if needed.
> 
> Thanks,
> David

Thanks for review, @dholmes-ora! @iignatev, want to take a look as well?

-------------

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

From chagedorn at openjdk.java.net  Thu Aug 26 09:59:23 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 26 Aug 2021 09:59:23 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 IGV transformations [v2]
In-Reply-To: <Y00AhlwMF0CkTa_RgOkEgcsx2P1xNpRN9m1qj0QTIm8=.2f8221ca-87a6-4d88-b0c1-6d5100dcd62b@github.com>
References: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
 <q4yXuw6KCd6stuAmLaNdI891rKOeN08TjMrXeXkiBkw=.aec2b77b-e487-4cd4-88e0-7b01ecc18eaf@github.com>
 <XgfE5LZPC81gHqf2GuBZ59PylILUaDNS68H2Jl52TvQ=.efdbc2a5-9bc0-4044-9f3e-408cbf8cc64e@github.com>
 <BKEtTh_TfaN9GtjQJeDpjEy-icmG6F1XTwuRtaMndqo=.46ed7685-23bf-4774-b337-c77c101d4585@github.com>
 <USUsq40B5NKY9bMPl2YNHhhOUItCkXx_vvU0v_bU1R0=.549e9028-60a4-4345-8964-95f65df317d0@github.com>
 <2uRU0b0fCTLTdN6jsB9mNpM_3BEgFZz7q4xHWnNG79I=.16186f49-c220-4bf7-aee1-c18f820e92a5@github.com>
 <cpQ56g49aFl4tHUaFXgyObZewh1djLYR8r5QRgBWyLU=.e09e10fc-533c-4f2a-9bf3-6570b09508fd@github.com>
 <Y00AhlwMF0CkTa_RgOkEgcsx2P1xNpRN9m1qj0QTIm8=.2f8221ca-87a6-4d88-b0c1-6d5100dcd62b@github.com>
Message-ID: <BqZteqGu-bIyzcQXd6z2xmzOxO3UeYCxRCVjJK94I6U=.c051a968-4174-4588-a146-b85db78c52de@github.com>

On Mon, 23 Aug 2021 22:39:37 GMT, John Tortugo <github.com+2249648+JohnTortugo at openjdk.org> wrote:

>>> This directory was created to split original set of tests to run in parallel and not related to C2 compiler
>> 
>> aren't you mixing this up w/ `tier1_compiler_[1-3]` test group? if you aren't, this was the wrong way to split tests and we need to fix that.
>> 
>>>  I want to have directories in `/compiler` per `optimization/transformation` type as we have now. For example, `/loopopts` is for C2 only but it is not under `/c2`.
>>> Actually I want to clear `c2` and `c1` directories eventually to move tests to corresponding category directories instead.
>> 
>> I would prefer to clear `/compiler` directory and move c1-specific tests into `/compiler/c1` directory and c2-specific tests into `/compiler/c2` with optimization/transformation type being subdirectories inside `/compiler/c[12]` (and shared/common tests moved to `/compiler/shared`), so `loopopts` tests are to moved to `/compiler/c2/loopopts`. one of the reasons, most of optimizations tests will be compiler-specific and having them together in `/compiler` doesn't make much sense and just makes it harder to navigate/use test base. e.g. if we have all c2 tests in `/compiler/c2`, one can easily run them together to test c2 changes, if c2-specific tests are in several directories in `/compiler`, so one will have to have intrinsic knowledge about all tests in `/compiler` to select the right one.
>
> Should I move all  tests created in this PR to folders under `/compiler/c2/`? Separated by type of optimization - loopOpts, scalarReplacement, etc?

I'm opting for having these tests in subfolders of `irTests` separated by type of optimization. But should we go with `compiler/irTests/*` or `/compiler/c2/irTests/*`?

-------------

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

From fmatte at openjdk.java.net  Thu Aug 26 14:29:26 2021
From: fmatte at openjdk.java.net (Fairoz Matte)
Date: Thu, 26 Aug 2021 14:29:26 GMT
Subject: RFR: 8272563: Possible assertion failure in CardTableBarrierSetC1
In-Reply-To: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
Message-ID: <I_G1_cd3JrO66mzyQk2DjlEz15JLcVoQ-AY9zGqc31U=.4b03c9b4-b30b-4374-831c-e71182458916@github.com>

On Wed, 18 Aug 2021 12:37:00 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
> 
> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>> __ move(addr, tmp);
> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
> The fix is to check if it is is_oop() and call the mov appropriately.
> 
> No issues found in local testing and Mach5 tier1-3

Hi Tobias, 
Thanks for looking into this thread. There is reproducer but it has lot of dependencies with dacapo-9.12-MR1-bach.jar and I am unable to isolate to smaller case.
I tried with your suggestion but could not resolve the issue.
Below is the original issue reproduced on fastdebug build (Updated the jbs bug)
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/tank/fmatte/bugs/8272563/openjdk-reproduce-5164/src/hotspot/share/c1/c1_LIR.hpp:413), pid=28744, tid=28763
#  assert(is_double_stack() && !is_virtual()) failed: type check
#
# JRE version: OpenJDK Runtime Environment (16.0.2) (fastdebug build 16.0.2-internal+0-adhoc.fmatte.openjdk-reproduce-5164)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 16.0.2-internal+0-adhoc.fmatte.openjdk-reproduce-5164, compiled mode, tiered, compressed oops, compressed class ptrs, serial gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x7202f3]  LIR_OprDesc::double_stack_ix() const+0x43
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /tank/fmatte/bugs/8272563/openjdk-reproduce-5164/core.28744)
#
# An error report file with more information is saved as:
# error.log
#
# Compiler replay data is saved as:
# /tank/fmatte/bugs/8272563/openjdk-reproduce-5164/replay_pid28744.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp

-------------

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

From coleenp at openjdk.java.net  Thu Aug 26 15:42:50 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 26 Aug 2021 15:42:50 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v5]
In-Reply-To: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
Message-ID: <hJHEQbqu7A_-YHVRym2FCNa_--6TC0Px8qCo8VDmvSs=.11abd4b7-96fe-42c1-a4e5-22d4ffdef00d@github.com>

> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
> Tested with tier1-6.

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

  Reverse the order of safepoint_check_required and allow_vm_block arguments so that the first can imply the value of the second.  This is good because if we decide to rename the second to something like _allow_safepoint_use instead there's less to change. Also remove default arguments as they are evil.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5218/files
  - new: https://git.openjdk.java.net/jdk/pull/5218/files/27179b77..a3b7d89e

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

  Stats: 56 lines in 15 files changed: 2 ins; 3 del; 51 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5218.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5218/head:pull/5218

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

From pchilanomate at openjdk.java.net  Thu Aug 26 16:21:23 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Thu, 26 Aug 2021 16:21:23 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v5]
In-Reply-To: <hJHEQbqu7A_-YHVRym2FCNa_--6TC0Px8qCo8VDmvSs=.11abd4b7-96fe-42c1-a4e5-22d4ffdef00d@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
 <hJHEQbqu7A_-YHVRym2FCNa_--6TC0Px8qCo8VDmvSs=.11abd4b7-96fe-42c1-a4e5-22d4ffdef00d@github.com>
Message-ID: <K3gs3u45uRCABjJKs_a6JAUheO3zU5cPrw5THSfw8pE=.fc050f1f-602e-4210-ab33-b29f38f280dd@github.com>

On Thu, 26 Aug 2021 15:42:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
>> Tested with tier1-6.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverse the order of safepoint_check_required and allow_vm_block arguments so that the first can imply the value of the second.  This is good because if we decide to rename the second to something like _allow_safepoint_use instead there's less to change. Also remove default arguments as they are evil.

Looks good to me! Thanks for fixing it.

Patricio

-------------

Marked as reviewed by pchilanomate (Committer).

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

From coleenp at openjdk.java.net  Thu Aug 26 17:38:28 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 26 Aug 2021 17:38:28 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v4]
In-Reply-To: <68oxwS4QS8-CSRnUoy3Gy7YAlp9_9TpwfXi8GUbXPi4=.9f09e21d-80be-4d9f-b56a-f64d5e398ca6@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
 <pezkXUedVgEjPJKzwwKMXF1CmwDZuL59mICHmUNX4Po=.0160ce37-d285-4ead-8829-23c9ede74e92@github.com>
 <68oxwS4QS8-CSRnUoy3Gy7YAlp9_9TpwfXi8GUbXPi4=.9f09e21d-80be-4d9f-b56a-f64d5e398ca6@github.com>
Message-ID: <RioAaU1ZgX7TITOXXm_WEhxE5RL33v-4l3m32kYMjpw=.fbd8d1c2-2b66-4246-946b-e7bdcdb7e003@github.com>

On Thu, 26 Aug 2021 06:01:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove allow_vm_block parameter if safepoint_check_never.
>
> Hi Coleen,
> 
> I've put a lengthy comment in the JBS issue explaining how I see this change, but the bottom like is that I think it is a perfectly fine simplification.
> 
> Thanks,
> David

Thanks for the comment in the bug and review, David, and for the review Patricio.  @dholmes-ora I added another change that I'd like you to look at.  I didn't change the order of arguments in mutexLocker.cpp because I'm going to save that bit of review tedium for the bigger task of renaming the ranks.

-------------

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

From serb at openjdk.java.net  Thu Aug 26 17:42:33 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Aug 2021 17:42:33 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> 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.
>
> Sergey Bylokhov 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 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - 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
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/be695a9b...e7127644

Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer?

-------------

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

From github.com+5709644+fdesu at openjdk.java.net  Thu Aug 26 18:33:27 2021
From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko)
Date: Thu, 26 Aug 2021 18:33:27 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
 <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
Message-ID: <vjfSSXTwCTncHGyKQOw5M3cV_bCdmb89ZEFgZ8ggTkQ=.b617da20-0a0c-4b55-8011-184d1932e2aa@github.com>

On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Sergey Bylokhov 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 14 additional commits since the last revision:
>> 
>>  - Update the usage of Files.readAllLines()
>>  - Update datatransfer
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - 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
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/810191b6...e7127644
>
> Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer?

@mrserb Not sure if it applies but there are couple of classes in `java.xml` that use charset names instead of standard charsets. Here they are:
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/AnyURIDV.java
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java
- src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java

would it make sense to go through them as well?

-------------

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

From serb at openjdk.java.net  Thu Aug 26 18:38:26 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Aug 2021 18:38:26 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
 <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
Message-ID: <a97uQJLcPbeqHP6UVqNXMtqDq4bf4GytTvBLl4C5HPk=.3a50dcbe-d199-4df4-9af7-a94f7755bfe3@github.com>

On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Sergey Bylokhov 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 14 additional commits since the last revision:
>> 
>>  - Update the usage of Files.readAllLines()
>>  - Update datatransfer
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - 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
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/e5c71cd0...e7127644
>
> Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer?

> @mrserb Not sure if it applies but there are couple of classes in `java.xml` that use charset names instead of standard charsets. 
> would it make sense to go through them as well?

Most of the cases in the XML module are related to the Xerces library, I have skipped it to make the future merges from upstream of that library simpler.

-------------

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

From dholmes at openjdk.java.net  Thu Aug 26 23:21:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 26 Aug 2021 23:21:28 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v5]
In-Reply-To: <hJHEQbqu7A_-YHVRym2FCNa_--6TC0Px8qCo8VDmvSs=.11abd4b7-96fe-42c1-a4e5-22d4ffdef00d@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
 <hJHEQbqu7A_-YHVRym2FCNa_--6TC0Px8qCo8VDmvSs=.11abd4b7-96fe-42c1-a4e5-22d4ffdef00d@github.com>
Message-ID: <i9PnOjSTHac09I67J_d-bezfSTeZ3S2qVYgFfPV5CMw=.cbef9e98-3ad9-447d-8739-150daaed3f17@github.com>

On Thu, 26 Aug 2021 15:42:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
>> Tested with tier1-6.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverse the order of safepoint_check_required and allow_vm_block arguments so that the first can imply the value of the second.  This is good because if we decide to rename the second to something like _allow_safepoint_use instead there's less to change. Also remove default arguments as they are evil.

Sorry Coleen but now I'm confused again. You have a bunch of locks that are safepoint_check_always AND _allow_vm_block==true. That doesn't make sense if _allow_vm_block is supposed to be about acquiring the lock in the VMThread (or GC thread) _at_ a safepoint. You seem to be trying to express that non-JavaThreads can acquire a lock at any time if _allow_vm_block is true. But _allow_vm_block should only be checked when at a safepoint, or else when it is the VMThread, otherwise it doesn't have the meaning that enabled you to make this change.

David

-------------

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

From dholmes at openjdk.java.net  Fri Aug 27 00:33:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 27 Aug 2021 00:33:25 GMT
Subject: RFR: 8272838: Move CriticalJNI tests out of tier1
In-Reply-To: <G0YRVmfZwtC0ZABcgkEE-nBwHRu7XLc1WoFkHn4wArc=.9cc5f88e-ead0-4a1a-bc67-729934217905@github.com>
References: <G0YRVmfZwtC0ZABcgkEE-nBwHRu7XLc1WoFkHn4wArc=.9cc5f88e-ead0-4a1a-bc67-729934217905@github.com>
Message-ID: <uHrHkO8r-S9339KIVEYl9sCr8FEg2K7faMe4aNfuPgs=.3131125b-455a-43b5-8659-f238690c9bf3@github.com>

On Mon, 23 Aug 2021 13:58:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug report for more discussion. These tests are tied in Epsilon and Shenandoah test groups, so I rehashed those a bit. Note there are no `tier2` or `tier3` test groups in Hotspot yet, which means these tests would only run as part of Epsilon and Shenandoah test suites. I would rehash tier2/3 in [JDK-8272914](https://bugs.openjdk.java.net/browse/JDK-8272914), while hooking up more runtime and GC tests there.
> 
> Motivational run time improvements:
> 
> 
> $  make run-test TEST=hotspot:tier1
> 
> # Before
> real	8m9.678s
> user	289m59.304s
> sys	27m46.347s
> 
> # After
> real	7m53.359s    # 15 seconds saved
> user	278m49.104s  # 11 minutes saved
> sys	28m2.516s
> 
> 
> Additional testing:
>  - [x] Checked `hotspot:tier1` run test lists before/after the patch, the difference is only these two lists
>  - [x] Some test performance measurements.

Hi Aleksey,

It was a bit hard to track the shuffling around but in the end this seems okay. :)

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

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

From iveresov at openjdk.java.net  Fri Aug 27 03:42:24 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 27 Aug 2021 03:42:24 GMT
Subject: RFR: 8272563: Possible assertion failure in CardTableBarrierSetC1
In-Reply-To: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
Message-ID: <fg0Ipd5Tq7TTMbuE3cFzDqQg3OS0Fx3pzuDACbaTmtY=.45fd237f-bb94-4edd-941a-c3e4b8dd087b@github.com>

On Wed, 18 Aug 2021 12:37:00 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
> 
> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>> __ move(addr, tmp);
> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
> The fix is to check if it is is_oop() and call the mov appropriately.
> 
> No issues found in local testing and Mach5 tier1-3

I think we have to somehow tell the register allocator not to spill arguments of type converting moves.  We already have some logic there to prevent spills in logic and arithmetic involving T_OBJECT: https://github.com/openjdk/jdk/blob/d732c3091fea0a7c6d6767227de89002564504e5/src/hotspot/share/c1/c1_LinearScan.cpp#L1135
Perhaps we should also detect the conversion case when ( `src` and `dst` ) are of different types and force both to be in registers?  Basically insert some logic here (reg-reg move):
https://github.com/openjdk/jdk/blob/d732c3091fea0a7c6d6767227de89002564504e5/src/hotspot/share/c1/c1_LinearScan.cpp#L1068
Check the types, and if it's the T_OBJECT->T_LONG situation  return `mustHaveRegister` ?

May be there is better solution, but that's the first thing that came to mind.

-------------

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

From aph-open at littlepinkcloud.com  Fri Aug 27 08:22:13 2021
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Fri, 27 Aug 2021 09:22:13 +0100
Subject: RFC: AArch64: Implementing spin pauses with ISB
In-Reply-To: <EDB2660E-4F9A-4FA9-8A08-6E976CAC262B@amazon.com>
References: <EDB2660E-4F9A-4FA9-8A08-6E976CAC262B@amazon.com>
Message-ID: <ec3ee875-91c3-1e16-3197-181b38e763b1@littlepinkcloud.com>

On 8/25/21 10:16 PM, Astigeevich, Evgeny wrote:

> IMHO, we've only scratched the surface of it. The problem is not
> well modelled by existing public benchmarks.  Yes, it is application
> dependent at some level.  In case of Thread.onSpinWait it depends on
> how an application implements spin loops.  Applications having spin
> loops with several iterations would benefit from short onSpinWait
> (this is what we've got in customers' benchmarks). Applications
> calling onSpinWait only couple times would benefit from longer
> onSpinWait.  "How heavy thread contention should be, what other
> places", these are still open questions. To answer them we need to
> detect the issues which is the problem itself.  What we currently
> use is the trial-and-error approach.

OK, thanks. I'm happy to approve a patch that switches NOP, PAUSE, and
ISB.

However, this all sounds a bit like cargo cult science to me. :-)

Some thoughts. In a high-contention case this is related to backoff in
transactional memory, where Dave Dice et al's TL2 (See "What really
makes transactions faster?" uses exponential*random backoff, like
Ethernet. The wisdom there is that you keep increasing the backoff
until it is about half the time that parking would take, then actually
park. That sounds intuitively reasonable.

But we don't need to do anything more if just adding an ISB is good
enough, at least for now. Let's do that, and see how it goes.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From thomas.stuefe at gmail.com  Fri Aug 27 09:05:20 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 27 Aug 2021 11:05:20 +0200
Subject: Proposal: On Linux, add option to periodically trim the glibc heap
Message-ID: <CAA-vtUzuy0YHqQNxoOJUb1MPsXNAVPuUCjXZz8iHY4n81Y-y1Q@mail.gmail.com>

Hi all,

I would like to gauge opinions on the following idea.

The glibc can be very reluctant to return released C-heap memory to the OS.
Memory returned to it via free(3) is typically cached within the glibc and
still counts toward the process RSS. It may be reused for
future allocations, but for now it is idling around. This manifests in the
process RSS not recovering from C-heap usage spikes, e.g. after intense
compilations. This effect is most pronounced with many small allocations
which have actually be touched - large allocations are mapped and unmapped
correctly on free(3).

I do not know of any other libc which has this problem to this extend. AIX
libc is somewhat bad too - in our proprietary VM we use manual mmap as a
backing for Arenas for that reason - but glibc is worse.

However, the glibc offers a very simple API to shake the memory loose and
return it to the OS: `malloc_trim(3)` [1].

With JDK-8269345 [2], SAP contributed a new jcmd command to *manually* trim
the C-heap on Linux: `jcmd System.trim_native_heap` will force the glibc to
release excess memory and print out the resulting RSS shrinkage. For
example, executing it on my running CDT reduces RSS by 400M:

```
thomas at starfish$ jcmd eclipse System.trim_native_heap
...
RSS before: 2229376k, after: 1784572k, (-444804k)
```

I see other memory reductions in different apps. E.g., with the springboot
petclinic, right after startup:

```
thomas at starfish$ jcmd petclinic System.trim_native_heap
...
RSS before: 649424k, after: 471052k, (-178372k)
```

JDK-8269345 explicitly avoided adding logic to any form of automatic
trimming. The intent of this command was to analyze high-memory situations
- especially to find out what part of RSS was glibc-cached memory.

-----

As a second step, I'd like to introduce some sort of automatic glibc
trimming. Implementing this - automatically calling `malloc_trim(3)`
periodically, or tied to some VM event - is technically easy. The big
problem is to decide if that makes sense.

When we trim, we release cached memory to the OS. Trimming itself costs a
bit, but the highest cost is re-acquiring that memory should we need it
again. Which is expensive especially if we are under memory pressure. But
that is also the scenario where releasing excess memory makes the most
sense: keeping memory cached within the glibc restricts this memory to
being used only by this VM process, only for subsequent malloc() calls,
which also need to have the right size for the freed blocks being reused.
Releasing it means it can be repurposed for some other consumer, which may
include the VM itself.

As with every caching, we would have to compare the cost of re-acquiring
memory with the benefit of having this memory available to other parts of
the system which need it more urgently. This is difficult since we'd need
to know how many mallocs will happen in the immediate future of the VM
process.

There are some shaky heuristics. For example, the JIT is one of the
heaviest C-heap consumers. Most of the compilations happen at startup, so
for some applications, we have a C-heap usage spike at the start, and not
much after that. So after the bulk of compilations have been done, it would
be a good time to call malloc_trim.

But relying on VM-internal information is fragile considering that non-VM
code may also call malloc within our process. Non-VM code may include our
JDK native code, third-party JNI code as well as System libraries. All
these may cause rare spikes in C-heap usage, or spike frequently, or have a
constant churn of malloc/free calls. We have no idea.

Therefore, I propose a simple and straightforward solution: let's add an
optional parameter (by default off), `-XX:+TrimNativeHeap`, coupled with a
second parameter `-XX:TrimNativeHeapPeriod=<seconds>`. When enabled, we
would periodically trim the glibc heap. We would choose the default period
to be reasonably long, e.g. 10 seconds.

This approach hands the instrument to the user but leaves the
responsibility with him too. If the user observes RSS bounce back after
each trim, forming a steep sawtooth pattern, it means the process really
needs that memory and is re-acquiring it each time. In that case, releasing
it probably hurts more than it helps. OTOH, if RSS stays flat after the
spike, at least for a number of periods, releasing the memory did make
sense.

----

We could add to this logic VM-internal knowledge, but I am not sure if that
complexity is warranted since we never can reliably guess the future
allocation behavior of both VM and non-VM code:
- trimming when (big) arenas are released or when the arena pool is cleaned
out
- trimming periodically, but not if a certain number of os::malloc calls
happened in the recent past
- trimming if the delta between current and peak allocation is X
   (would require NMT to be always on)

What do you think?

Thanks, Thomas

-----------

[1] https://man7.org/linux/man-pages/man3/malloc_trim.3.html
[2] https://bugs.openjdk.java.net/browse/JDK-8269345

From shade at openjdk.java.net  Fri Aug 27 09:38:31 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 27 Aug 2021 09:38:31 GMT
Subject: Integrated: 8272846: Move some runtime/Metaspace/elastic/ tests out
 of tier1
In-Reply-To: <u0J-YJ8NjWb9Q3-mc_PZsYF5jRrtCmOLJiVAJPPOsLU=.ac7fb5fe-40e2-4f46-994d-786d033985f7@github.com>
References: <u0J-YJ8NjWb9Q3-mc_PZsYF5jRrtCmOLJiVAJPPOsLU=.ac7fb5fe-40e2-4f46-994d-786d033985f7@github.com>
Message-ID: <JuItUN9iI2DLAFkzbvEfsDlAkKbT5lxodEEsOk7cpwY=.a20717d7-6515-4cc0-a5ce-89139c48636b@github.com>

On Mon, 23 Aug 2021 15:12:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug report for more discussion. Attention @tstuefe -- is it time yet to do this?
> 
> Motivational run time improvements:
> 
> 
> $  make run-test TEST=hotspot:tier1
> 
> # Before
> real	8m9.678s
> user	289m59.304s
> sys	27m46.347s
> 
> # After
> real	7m27.566s
> user	284m4.947s
> sys	27m33.724s
> 
> 
> Additional testing:
>  - [x] `tier1` no longer runs these tests
>  - [x] `hotspot_tier2_runtime` runs these tests

This pull request has now been integrated.

Changeset: ebd62bc0
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ebd62bc0433c56f3520b9e41621f18a1b736022b
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8272846: Move some runtime/Metaspace/elastic/ tests out of tier1

Reviewed-by: mseledtsov, stuefe

-------------

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

From shade at openjdk.java.net  Fri Aug 27 10:39:53 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 27 Aug 2021 10:39:53 GMT
Subject: RFR: 8272838: Move CriticalJNI tests out of tier1 [v2]
In-Reply-To: <G0YRVmfZwtC0ZABcgkEE-nBwHRu7XLc1WoFkHn4wArc=.9cc5f88e-ead0-4a1a-bc67-729934217905@github.com>
References: <G0YRVmfZwtC0ZABcgkEE-nBwHRu7XLc1WoFkHn4wArc=.9cc5f88e-ead0-4a1a-bc67-729934217905@github.com>
Message-ID: <gJqolLXr_pqT8WfM0P5D8Ritn3Vks_jJtb_909xw614=.95bce614-36b7-4c4a-8451-302d8f5583bc@github.com>

> See the bug report for more discussion. These tests are tied in Epsilon and Shenandoah test groups, so I rehashed those a bit. Note there are no `tier2` or `tier3` test groups in Hotspot yet, which means these tests would only run as part of Epsilon and Shenandoah test suites. I would rehash tier2/3 in [JDK-8272914](https://bugs.openjdk.java.net/browse/JDK-8272914), while hooking up more runtime and GC tests there.
> 
> Motivational run time improvements:
> 
> 
> $  make run-test TEST=hotspot:tier1
> 
> # Before
> real	8m9.678s
> user	289m59.304s
> sys	27m46.347s
> 
> # After
> real	7m53.359s    # 15 seconds saved
> user	278m49.104s  # 11 minutes saved
> sys	28m2.516s
> 
> 
> Additional testing:
>  - [x] Checked `hotspot:tier1` run test lists before/after the patch, the difference is only these two lists
>  - [x] Some test performance measurements.

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 sure CriticalJNI tests are in tier2 in both Epsilon and Shenandoah blocks
 - Merge branch 'master' into JDK-8272838-perf-test-criticaljni
 - 8272838: Remove CriticalJNI tests from tier1

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5219/files
  - new: https://git.openjdk.java.net/jdk/pull/5219/files/a9556d7a..8c628bf4

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

  Stats: 7100 lines in 339 files changed: 4941 ins; 1108 del; 1051 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5219.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5219/head:pull/5219

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

From shade at openjdk.java.net  Fri Aug 27 10:39:53 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 27 Aug 2021 10:39:53 GMT
Subject: RFR: 8272838: Move CriticalJNI tests out of tier1 [v2]
In-Reply-To: <uHrHkO8r-S9339KIVEYl9sCr8FEg2K7faMe4aNfuPgs=.3131125b-455a-43b5-8659-f238690c9bf3@github.com>
References: <G0YRVmfZwtC0ZABcgkEE-nBwHRu7XLc1WoFkHn4wArc=.9cc5f88e-ead0-4a1a-bc67-729934217905@github.com>
 <uHrHkO8r-S9339KIVEYl9sCr8FEg2K7faMe4aNfuPgs=.3131125b-455a-43b5-8659-f238690c9bf3@github.com>
Message-ID: <ua5hQwiRMTp8v9Bz7YbcosJjedtFQK_irz5zmfK3t04=.35996fe3-70c0-4037-9938-c7dee191cf9d@github.com>

On Fri, 27 Aug 2021 00:30:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> It was a bit hard to track the shuffling around but in the end this seems okay. :)

Yes, test groups are kind of a maze (ing). I now realized that the affected tests are in tier2_epsilon and tier3_shenandoah, which means they would run in both prospective `hotspot:tier2` and `hotspot:tier3`. I now moved the tests to tier2_shenandoah to match their tiers.

-------------

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

From kim.barrett at oracle.com  Fri Aug 27 11:06:40 2021
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 27 Aug 2021 11:06:40 +0000
Subject: Proposal: On Linux, add option to periodically trim the glibc heap
In-Reply-To: <CAA-vtUzuy0YHqQNxoOJUb1MPsXNAVPuUCjXZz8iHY4n81Y-y1Q@mail.gmail.com>
References: <CAA-vtUzuy0YHqQNxoOJUb1MPsXNAVPuUCjXZz8iHY4n81Y-y1Q@mail.gmail.com>
Message-ID: <B366EFFC-AE73-4F93-9B16-4C3A2EBD51A8@oracle.com>

> On Aug 27, 2021, at 5:05 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> 
> Hi all,
> 
> I would like to gauge opinions on the following idea.
> 
> The glibc can be very reluctant to return released C-heap memory to the OS.
> Memory returned to it via free(3) is typically cached within the glibc and
> still counts toward the process RSS. It may be reused for
> future allocations, but for now it is idling around. This manifests in the
> process RSS not recovering from C-heap usage spikes, e.g. after intense
> compilations. This effect is most pronounced with many small allocations
> which have actually be touched - large allocations are mapped and unmapped
> correctly on free(3).
> 
> I do not know of any other libc which has this problem to this extend. AIX
> libc is somewhat bad too - in our proprietary VM we use manual mmap as a
> backing for Arenas for that reason - but glibc is worse.
> 
> However, the glibc offers a very simple API to shake the memory loose and
> return it to the OS: `malloc_trim(3)` [1].

Not general purpose, but this seems like something that could/should be added
to G1 periodic GCs (https://openjdk.java.net/jeps/346). If the application is
considered inactive, so that returning Java heap space to the OS is desirable,
then similarly for C heap space.

Obviously that doesn't cover all the cases you are describing, but does cover
what seems like an important one.  And this seems like it should be fairly easy.


From claes.redestad at oracle.com  Fri Aug 27 11:17:11 2021
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 27 Aug 2021 13:17:11 +0200
Subject: Proposal: On Linux, add option to periodically trim the glibc heap
In-Reply-To: <CAA-vtUzuy0YHqQNxoOJUb1MPsXNAVPuUCjXZz8iHY4n81Y-y1Q@mail.gmail.com>
References: <CAA-vtUzuy0YHqQNxoOJUb1MPsXNAVPuUCjXZz8iHY4n81Y-y1Q@mail.gmail.com>
Message-ID: <0bd2e6eb-e050-f0ac-bd4a-bdb31921da3e@oracle.com>

First: great find!

On 2021-08-27 11:05, Thomas St?fe wrote:
> We could add to this logic VM-internal knowledge, but I am not sure if that
> complexity is warranted since we never can reliably guess the future
> allocation behavior of both VM and non-VM code:
> - trimming when (big) arenas are released or when the arena pool is cleaned
> out
> - trimming periodically, but not if a certain number ofos::malloc  calls
> happened in the recent past
> - trimming if the delta between current and peak allocation is X
>     (would require NMT to be always on)
> 
> What do you think?

Doing it periodically is simple and straightforward, but I guess it
could affect GC latency negatively, and by doing it repeatedly when
there's no need to is likely harmful to tail end latencies.

Assuming a significant part of this excess memory was allocated by JIT
threads that got spun up during startup/warmup and then terminated when
there was less work, trimming after a drop in such threads (with some
grace time) might be a simple yet effective heuristic. No need to track
os::malloc calls or allocation rate with NMT that way. I think doing the
same for GC threads might be less attractive, since those threads are
more likely to be revived periodically and more stable over time.

Thanks
Claes

From forax at univ-mlv.fr  Fri Aug 27 11:20:45 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 27 Aug 2021 13:20:45 +0200 (CEST)
Subject: Proposal: On Linux, add option to periodically trim the glibc heap
In-Reply-To: <B366EFFC-AE73-4F93-9B16-4C3A2EBD51A8@oracle.com>
References: <CAA-vtUzuy0YHqQNxoOJUb1MPsXNAVPuUCjXZz8iHY4n81Y-y1Q@mail.gmail.com>
 <B366EFFC-AE73-4F93-9B16-4C3A2EBD51A8@oracle.com>
Message-ID: <322686623.594454.1630063245509.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Kim Barrett" <kim.barrett at oracle.com>
> To: "Thomas St?fe" <thomas.stuefe at gmail.com>
> Cc: "hotspot-dev" <hotspot-dev at openjdk.java.net>
> Sent: Vendredi 27 Ao?t 2021 13:06:40
> Subject: Re: Proposal: On Linux, add option to periodically trim the glibc heap

>> On Aug 27, 2021, at 5:05 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>> 
>> Hi all,
>> 
>> I would like to gauge opinions on the following idea.
>> 
>> The glibc can be very reluctant to return released C-heap memory to the OS.
>> Memory returned to it via free(3) is typically cached within the glibc and
>> still counts toward the process RSS. It may be reused for
>> future allocations, but for now it is idling around. This manifests in the
>> process RSS not recovering from C-heap usage spikes, e.g. after intense
>> compilations. This effect is most pronounced with many small allocations
>> which have actually be touched - large allocations are mapped and unmapped
>> correctly on free(3).
>> 
>> I do not know of any other libc which has this problem to this extend. AIX
>> libc is somewhat bad too - in our proprietary VM we use manual mmap as a
>> backing for Arenas for that reason - but glibc is worse.
>> 
>> However, the glibc offers a very simple API to shake the memory loose and
>> return it to the OS: `malloc_trim(3)` [1].
> 
> Not general purpose, but this seems like something that could/should be added
> to G1 periodic GCs (https://openjdk.java.net/jeps/346). If the application is
> considered inactive, so that returning Java heap space to the OS is desirable,
> then similarly for C heap space.
> 
> Obviously that doesn't cover all the cases you are describing, but does cover
> what seems like an important one.  And this seems like it should be fairly easy.

Yes, and Shenandoah and ZGC are also able to uncommit unused Memory.

R?mi

From shade at redhat.com  Fri Aug 27 11:31:51 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 27 Aug 2021 13:31:51 +0200
Subject: Proposal: On Linux, add option to periodically trim the glibc heap
In-Reply-To: <322686623.594454.1630063245509.JavaMail.zimbra@u-pem.fr>
References: <CAA-vtUzuy0YHqQNxoOJUb1MPsXNAVPuUCjXZz8iHY4n81Y-y1Q@mail.gmail.com>
 <B366EFFC-AE73-4F93-9B16-4C3A2EBD51A8@oracle.com>
 <322686623.594454.1630063245509.JavaMail.zimbra@u-pem.fr>
Message-ID: <0af19e8a-acf4-56c3-35b9-d8aea6f5ed41@redhat.com>

On 8/27/21 1:20 PM, Remi Forax wrote:
>> Obviously that doesn't cover all the cases you are describing, but does cover
>> what seems like an important one.  And this seems like it should be fairly easy.
> 
> Yes, and Shenandoah and ZGC are also able to uncommit unused Memory.

+1, I think it would be sensible to shrink the C heap during periodic/explicit GCs. This also reuses 
the existing GC timing/logging/tuning facilities.

-- 
Thanks,
-Aleksey


From dholmes at openjdk.java.net  Fri Aug 27 13:20:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 27 Aug 2021 13:20:30 GMT
Subject: RFR: 8272838: Move CriticalJNI tests out of tier1 [v2]
In-Reply-To: <gJqolLXr_pqT8WfM0P5D8Ritn3Vks_jJtb_909xw614=.95bce614-36b7-4c4a-8451-302d8f5583bc@github.com>
References: <G0YRVmfZwtC0ZABcgkEE-nBwHRu7XLc1WoFkHn4wArc=.9cc5f88e-ead0-4a1a-bc67-729934217905@github.com>
 <gJqolLXr_pqT8WfM0P5D8Ritn3Vks_jJtb_909xw614=.95bce614-36b7-4c4a-8451-302d8f5583bc@github.com>
Message-ID: <zlWTi7yIBaNwGGb2G1p42J-VO5_BrpAjjQtanIjxyFE=.940f3ed4-4dfb-468b-80fc-8a0f2dffa45f@github.com>

On Fri, 27 Aug 2021 10:39:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug report for more discussion. These tests are tied in Epsilon and Shenandoah test groups, so I rehashed those a bit. Note there are no `tier2` or `tier3` test groups in Hotspot yet, which means these tests would only run as part of Epsilon and Shenandoah test suites. I would rehash tier2/3 in [JDK-8272914](https://bugs.openjdk.java.net/browse/JDK-8272914), while hooking up more runtime and GC tests there.
>> 
>> Motivational run time improvements:
>> 
>> 
>> $  make run-test TEST=hotspot:tier1
>> 
>> # Before
>> real	8m9.678s
>> user	289m59.304s
>> sys	27m46.347s
>> 
>> # After
>> real	7m53.359s    # 15 seconds saved
>> user	278m49.104s  # 11 minutes saved
>> sys	28m2.516s
>> 
>> 
>> Additional testing:
>>  - [x] Checked `hotspot:tier1` run test lists before/after the patch, the difference is only these two lists
>>  - [x] Some test performance measurements.
>
> 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 sure CriticalJNI tests are in tier2 in both Epsilon and Shenandoah blocks
>  - Merge branch 'master' into JDK-8272838-perf-test-criticaljni
>  - 8272838: Remove CriticalJNI tests from tier1

Marked as reviewed by dholmes (Reviewer).

-------------

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

From coleenp at openjdk.java.net  Fri Aug 27 13:32:23 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 27 Aug 2021 13:32:23 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v5]
In-Reply-To: <i9PnOjSTHac09I67J_d-bezfSTeZ3S2qVYgFfPV5CMw=.cbef9e98-3ad9-447d-8739-150daaed3f17@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
 <hJHEQbqu7A_-YHVRym2FCNa_--6TC0Px8qCo8VDmvSs=.11abd4b7-96fe-42c1-a4e5-22d4ffdef00d@github.com>
 <i9PnOjSTHac09I67J_d-bezfSTeZ3S2qVYgFfPV5CMw=.cbef9e98-3ad9-447d-8739-150daaed3f17@github.com>
Message-ID: <ihxRx-6AnrDbDq3M5UtBYHwlb-BnjOUpGpe2thQHHAc=.fd9f932a-f2b6-4459-a7ff-08f802fda63a@github.com>

On Thu, 26 Aug 2021 23:18:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverse the order of safepoint_check_required and allow_vm_block arguments so that the first can imply the value of the second.  This is good because if we decide to rename the second to something like _allow_safepoint_use instead there's less to change. Also remove default arguments as they are evil.
>
> Sorry Coleen but now I'm confused again. You have a bunch of locks that are safepoint_check_always AND _allow_vm_block==true. That doesn't make sense if _allow_vm_block is supposed to be about acquiring the lock in the VMThread (or GC thread) _at_ a safepoint. You seem to be trying to express that non-JavaThreads can acquire a lock at any time if _allow_vm_block is true. But _allow_vm_block should only be checked when at a safepoint, or else when it is the VMThread, otherwise it doesn't have the meaning that enabled you to make this change.
> 
> David

I believe @dholmes-ora  we've straightened this out in the CR comments.  Thanks for all the attention and discussion!
@pchilano Thank you for the discussion and suggested improvements!

-------------

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

From coleenp at openjdk.java.net  Fri Aug 27 14:18:44 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 27 Aug 2021 14:18:44 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v6]
In-Reply-To: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
Message-ID: <9yL2sYF8emkc_jO0-ci2REA-kTN_MH88oGnHOWZ3cSY=.91c68ff5-53df-4b38-940e-2eea2562d96c@github.com>

> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
> Tested with tier1-6.

Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into never-block
 - Reverse the order of safepoint_check_required and allow_vm_block arguments so that the first can imply the value of the second.  This is good because if we decide to rename the second to something like _allow_safepoint_use instead there's less to change. Also remove default arguments as they are evil.
 - Remove allow_vm_block parameter if safepoint_check_never.
 - Merge branch 'master' into never-block
 - Add simple gtest.
 - 8272797: Mutex with rank safepoint_check_never imply allow_vm_block

-------------

Changes: https://git.openjdk.java.net/jdk/pull/5218/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5218&range=05
  Stats: 133 lines in 40 files changed: 25 ins; 9 del; 99 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5218.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5218/head:pull/5218

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

From pchilanomate at openjdk.java.net  Fri Aug 27 14:29:29 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Fri, 27 Aug 2021 14:29:29 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v6]
In-Reply-To: <9yL2sYF8emkc_jO0-ci2REA-kTN_MH88oGnHOWZ3cSY=.91c68ff5-53df-4b38-940e-2eea2562d96c@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
 <9yL2sYF8emkc_jO0-ci2REA-kTN_MH88oGnHOWZ3cSY=.91c68ff5-53df-4b38-940e-2eea2562d96c@github.com>
Message-ID: <HSez2o2JQJgKT6gGXW1Ifr4l3F7YfiZFzXD99JseZrU=.558e60ba-0cd7-44d3-9a7c-eb811a8c1e21@github.com>

On Fri, 27 Aug 2021 14:18:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
>> Tested with tier1-6.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into never-block
>  - Reverse the order of safepoint_check_required and allow_vm_block arguments so that the first can imply the value of the second.  This is good because if we decide to rename the second to something like _allow_safepoint_use instead there's less to change. Also remove default arguments as they are evil.
>  - Remove allow_vm_block parameter if safepoint_check_never.
>  - Merge branch 'master' into never-block
>  - Add simple gtest.
>  - 8272797: Mutex with rank safepoint_check_never imply allow_vm_block

Marked as reviewed by pchilanomate (Committer).

-------------

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

From phedlin at openjdk.java.net  Fri Aug 27 15:25:57 2021
From: phedlin at openjdk.java.net (Patric Hedlin)
Date: Fri, 27 Aug 2021 15:25:57 GMT
Subject: RFR: 8264207: CodeStrings does not honour fixed address assumption.
Message-ID: <qkFzmEzzUnOzJ-kmwVvTI3DJ8Ja3g6oz2hHADnq7JG4=.af1dcee3-f9d3-450a-b39e-27a1644c4521@github.com>

Please review this change that addresses an issue originally found in JDK-8259590,
where the error message should read
`fatal error: DEBUG MESSAGE: verify_oop: r10: broken oop in decode_heap_oop`
but is lost since the code generated refers to a fixed (string) address, a string
(address) no longer available when **CodeStrings** have been propagated (copied)
between code buffers/blobs.

Background

**CodeStrings** used to be **CodeComments**. The solution to JDK-8008555 introduced
this change and added a new use-case for **CodeStrings**, not only as comments, but
as strings with a fixed address used in the code generated with support for debug
string printouts.

The changes introduced with JDK-8255208 breaks the fixed address assumption made
in the code generated with support for debug string printouts. Some of the (necessary)
move semantics have been replaced by copy semantics when **CodeStrings** are
propagated between code buffers/blobs (i.e. **CodeBuffer** and **CodeBlob** objects).

Additional issue addressed

+ Broken printout (i.e. missing  remarks) when multiple stubs are generated within
  the same primary buffer.

The following steps have been taken to provide fixed address (debug) strings.

+ Introduce a simple _gtest_ for **CodeString/s** support with **CodeBuffer/CodeBlob**.
+ Split **CodeStrings**  into two different abstractions;  strings associated with an offset,
  and strings with a fixed address.
  - Let the  first be  _Assembly Code  Remarks_, **AsmRemarks**, providing a simple
    1:N mapping, _offset_ -> _remark_.
  - Let the second be _Debug  Printout Strings_, **DbgStrings**, supporting a fixed
    address assumption such that:
      for each string A and B, if A = B -> &A = &B.
  - Use a  reference counting scheme to  ensure that both types  of strings are
    deallocated properly, when no longer in use.
+ Remove **CodeStrings** from **Stub** interface.
  - Replace with internal use in the interpreter code, propagating the code
    (assembly) remarks directly to the final codelet.
+ Remove  **CodeBuffer** self destruction, overwriting memory before  all
  deconstructors have been executed.
  - Replace with sentinel deconstructor to do the bidding.
+ Stub code generated into a single common **CodeBuffer**  (holding a number
  of stubs) will  not print the assembly remarks correctly  (except for the very first
  stub code section).
  - Introduce a displacement to correct the offset.
+ Remove old **CodeString/s** implementation.

Testing

Tier1-3 in debug mode, using debug strings, _without_ collecting remarks.
Tier1-3 in debug mode, using debug strings, _with_ collecting remarks (regardless of options).
Manual inspection of results (linux-x64 and linux-aarch64 only) for the following command line options:
`-XX:+PrintSignatureHandlers -XX:+PrintInterpreter -XX:+PrintStubCode -XX:+PrintAssembly`

-------------

Commit messages:
 - 8264207: CodeStrings does not honour fixed address assumption.

Changes: https://git.openjdk.java.net/jdk/pull/5281/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5281&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264207
  Stats: 891 lines in 16 files changed: 536 ins; 128 del; 227 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5281.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5281/head:pull/5281

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

From coleenp at openjdk.java.net  Fri Aug 27 15:54:45 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 27 Aug 2021 15:54:45 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v7]
In-Reply-To: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
Message-ID: <LcA_1_9zlZbXy_mrZY7BFtQvvWxfjMM2mtslH0HPXSY=.4b005b74-50bb-41f4-91ab-7547e9549b28@github.com>

> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
> Tested with tier1-6.

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

  Reverse the order of safepoint_check_required and allow_vm_block arguments so that the first can imply the value of the second.  This is good because if we decide to rename the second to something like _allow_safepoint_use instead there's less to change. Also remove default arguments as they are evil.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5218/files
  - new: https://git.openjdk.java.net/jdk/pull/5218/files/952e849f..220aca8c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5218&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5218&range=05-06

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

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

From coleenp at openjdk.java.net  Fri Aug 27 15:54:47 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 27 Aug 2021 15:54:47 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v6]
In-Reply-To: <9yL2sYF8emkc_jO0-ci2REA-kTN_MH88oGnHOWZ3cSY=.91c68ff5-53df-4b38-940e-2eea2562d96c@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
 <9yL2sYF8emkc_jO0-ci2REA-kTN_MH88oGnHOWZ3cSY=.91c68ff5-53df-4b38-940e-2eea2562d96c@github.com>
Message-ID: <3_rfoYdR9qI4Q5DLMo9b906ExHOMi3ZKlzeq84ijuGc=.dbe99f6f-85eb-4bc0-a3d4-f2a8cf04da91@github.com>

On Fri, 27 Aug 2021 14:18:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
>> Tested with tier1-6.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into never-block
>  - Reverse the order of safepoint_check_required and allow_vm_block arguments so that the first can imply the value of the second.  This is good because if we decide to rename the second to something like _allow_safepoint_use instead there's less to change. Also remove default arguments as they are evil.
>  - Remove allow_vm_block parameter if safepoint_check_never.
>  - Merge branch 'master' into never-block
>  - Add simple gtest.
>  - 8272797: Mutex with rank safepoint_check_never imply allow_vm_block

The last commit should have said "Fix merge errors."

-------------

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

From erikj at openjdk.java.net  Fri Aug 27 17:51:31 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 27 Aug 2021 17:51:31 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <LEmAelLl1suWas8ISeUc4p87XtgSBWwBTRPz5YSPguo=.6a717c6e-1d62-405e-9f65-2b2949f33c30@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> 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.
>
> Sergey Bylokhov 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 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - 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
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/6af90a19...e7127644

Build tool change looks good.

-------------

Marked as reviewed by erikj (Reviewer).

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

From kvn at openjdk.java.net  Fri Aug 27 18:02:28 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 27 Aug 2021 18:02:28 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 IGV transformations [v2]
In-Reply-To: <BqZteqGu-bIyzcQXd6z2xmzOxO3UeYCxRCVjJK94I6U=.c051a968-4174-4588-a146-b85db78c52de@github.com>
References: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
 <q4yXuw6KCd6stuAmLaNdI891rKOeN08TjMrXeXkiBkw=.aec2b77b-e487-4cd4-88e0-7b01ecc18eaf@github.com>
 <XgfE5LZPC81gHqf2GuBZ59PylILUaDNS68H2Jl52TvQ=.efdbc2a5-9bc0-4044-9f3e-408cbf8cc64e@github.com>
 <BKEtTh_TfaN9GtjQJeDpjEy-icmG6F1XTwuRtaMndqo=.46ed7685-23bf-4774-b337-c77c101d4585@github.com>
 <USUsq40B5NKY9bMPl2YNHhhOUItCkXx_vvU0v_bU1R0=.549e9028-60a4-4345-8964-95f65df317d0@github.com>
 <2uRU0b0fCTLTdN6jsB9mNpM_3BEgFZz7q4xHWnNG79I=.16186f49-c220-4bf7-aee1-c18f820e92a5@github.com>
 <cpQ56g49aFl4tHUaFXgyObZewh1djLYR8r5QRgBWyLU=.e09e10fc-533c-4f2a-9bf3-6570b09508fd@github.com>
 <Y00AhlwMF0CkTa_RgOkEgcsx2P1xNpRN9m1qj0QTIm8=.2f8221ca-87a6-4d88-b0c1-6d5100dcd62b@github.com>
 <BqZteqGu-bIyzcQXd6z2xmzOxO3UeYCxRCVjJK94I6U=.c051a968-4174-4588-a146-b85db78c52de@github.com>
Message-ID: <1ZjEPMgcx8a8qIfAMhBlFfQ1S0PUjbbv9r-uyF8cORc=.ad8ee7f3-603e-4ffd-b4e0-a12df3cf8ff3@github.com>

On Thu, 26 Aug 2021 09:56:31 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Should I move all  tests created in this PR to folders under `/compiler/c2/`? Separated by type of optimization - loopOpts, scalarReplacement, etc?
>
> I'm opting for having these tests in subfolders of `irTests` separated by type of optimization. But should we go with `compiler/irTests/*` or `/compiler/c2/irTests/*`?

I agree to do cleanup and **correctly** separate c1/c2/shared tests (as compiler tests cleanup RFE).

If we all agree with that then the answer for last question is `/compiler/c2/irTests/*`

-------------

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

From thomas.stuefe at gmail.com  Sat Aug 28 06:20:19 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sat, 28 Aug 2021 08:20:19 +0200
Subject: Proposal: On Linux, add option to periodically trim the glibc heap
In-Reply-To: <0bd2e6eb-e050-f0ac-bd4a-bdb31921da3e@oracle.com>
References: <CAA-vtUzuy0YHqQNxoOJUb1MPsXNAVPuUCjXZz8iHY4n81Y-y1Q@mail.gmail.com>
 <0bd2e6eb-e050-f0ac-bd4a-bdb31921da3e@oracle.com>
Message-ID: <CAA-vtUy-qRkAySq6abUTBNB-uk-Kskpq15HJt0cLwusFQ9Fu_w@mail.gmail.com>

On Fri, Aug 27, 2021 at 1:17 PM Claes Redestad <claes.redestad at oracle.com>
wrote:

> First: great find!
>
>
Thanks :)


> On 2021-08-27 11:05, Thomas St?fe wrote:
> > We could add to this logic VM-internal knowledge, but I am not sure if
> that
> > complexity is warranted since we never can reliably guess the future
> > allocation behavior of both VM and non-VM code:
> > - trimming when (big) arenas are released or when the arena pool is
> cleaned
> > out
> > - trimming periodically, but not if a certain number ofos::malloc  calls
> > happened in the recent past
> > - trimming if the delta between current and peak allocation is X
> >     (would require NMT to be always on)
> >
> > What do you think?
>
> Doing it periodically is simple and straightforward, but I guess it
> could affect GC latency negatively, and by doing it repeatedly when
> there's no need to is likely harmful to tail end latencies.
>

I will have to do some measurements. From reading the glibc sources, I
believe malloc_trim() should be cheap if there is nothing to trim. So
periodic trims should only cost something for the first malloc_trim() call.


>
> Assuming a significant part of this excess memory was allocated by JIT
> threads that got spun up during startup/warmup and then terminated when
> there was less work, trimming after a drop in such threads (with some
> grace time) might be a simple yet effective heuristic. No need to track
> os::malloc calls or allocation rate with NMT that way.


Interesting idea, but I'm not sure I want to couple trimming to the
lifetime of JIT threads. If we change their lifetime, increase the number
of compiler threads etc, we would then affect the trimming too. Where JIT
memory consumption is concerned, the easiest would be to hook into either
compile arena destruction or into the arena chunk pool cleaner which
periodically (atm every 5 secs) cleans the chunk pool.


> I think doing the
> same for GC threads might be less attractive, since those threads are
> more likely to be revived periodically and more stable over time.
>
>
I like the idea voiced in the other emails about coupling trimming with
periodic GCs. I'll have to think this through some more.

Thank you!

..Thomas


> Thanks
> Claes
>

From thomas.stuefe at gmail.com  Sat Aug 28 06:38:18 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sat, 28 Aug 2021 08:38:18 +0200
Subject: Proposal: On Linux, add option to periodically trim the glibc heap
In-Reply-To: <0af19e8a-acf4-56c3-35b9-d8aea6f5ed41@redhat.com>
References: <CAA-vtUzuy0YHqQNxoOJUb1MPsXNAVPuUCjXZz8iHY4n81Y-y1Q@mail.gmail.com>
 <B366EFFC-AE73-4F93-9B16-4C3A2EBD51A8@oracle.com>
 <322686623.594454.1630063245509.JavaMail.zimbra@u-pem.fr>
 <0af19e8a-acf4-56c3-35b9-d8aea6f5ed41@redhat.com>
Message-ID: <CAA-vtUzgoVSOwzncH022LCekMZfsF=UWK2DTaqWQjho7Gv=e_g@mail.gmail.com>

Hi Kim, Remi, Alexey,

thank you for your input. I combine my answers to you in one mail.

I first balked at the idea of tying malloc_trim to the G1 (or to any
singular VM facility which may or may not be active) because I often see
the highest C-heap usage from third-party code, not the VM. To me, a
dedicated independent little facility like the proposed periodic cleaner
seemed to be a better fit.

But thinking about this, the GC is a good fit because its job is to release
unused resources, and it does so periodically. But I would like to add this
to every GC, not just G1. I don't want to have to remember which GC does
the trimming.

Note that Ruby does it too: https://bugs.ruby-lang.org/issues/15667


> +1, I think it would be sensible to shrink the C heap during
> periodic/explicit GCs. This also reuses
> the existing GC timing/logging/tuning facilities.
>

That is a good point.


> --
> Thanks,
> -Aleksey
>
>

I'll analyze this some more, I want to have a better idea about the cost of
trimming, and will prepare a patch.

Thanks, Thomas

From dholmes at openjdk.java.net  Mon Aug 30 02:46:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 30 Aug 2021 02:46:29 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v7]
In-Reply-To: <LcA_1_9zlZbXy_mrZY7BFtQvvWxfjMM2mtslH0HPXSY=.4b005b74-50bb-41f4-91ab-7547e9549b28@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
 <LcA_1_9zlZbXy_mrZY7BFtQvvWxfjMM2mtslH0HPXSY=.4b005b74-50bb-41f4-91ab-7547e9549b28@github.com>
Message-ID: <0KxWmQwhAAzYjmjmRJ6AeuZUkKGYSAOZSXRGiNRtg3U=.cc146836-c11f-402f-b0c8-7cabb080422e@github.com>

On Fri, 27 Aug 2021 15:54:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
>> Tested with tier1-6.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverse the order of safepoint_check_required and allow_vm_block arguments so that the first can imply the value of the second.  This is good because if we decide to rename the second to something like _allow_safepoint_use instead there's less to change. Also remove default arguments as they are evil.

Hi Coleen,

A few non-blocking queries on some of the locks but the changes are fine as-is.

Thanks,
David

src/hotspot/share/gc/shared/taskTerminator.cpp line 75:

> 73:   _queue_set(queue_set),
> 74:   _offered_termination(0),
> 75:   _blocker(Mutex::leaf, "TaskTerminator", Monitor::_safepoint_check_never),

Is this lock even used by any JavaThreads? I'm guessing not - in which cases the always/never and allow/not-allow are immaterial, and the change is harmless.

src/hotspot/share/gc/z/zMetronome.cpp line 31:

> 29: 
> 30: ZMetronome::ZMetronome(uint64_t hz) :
> 31:     _monitor(Monitor::leaf, "ZMetronome", Monitor::_safepoint_check_never),

Again the "false" to "true" stands out here, but again I have to assume this is not a lock that is used by JavaThreads. Makes me wonder whether these locks can never encounter contention by the VMThread (otherwise they would assert).

src/hotspot/share/memory/heapInspection.hpp line 248:

> 246:       _missed_count(0),
> 247:       _success(true),
> 248:       _mutex(Mutex::leaf, "Parallel heap iteration data merge lock", Mutex::_safepoint_check_always) {}

Is this lock even used by JavaThreads. ??

test/hotspot/gtest/metaspace/test_is_metaspace_obj.cpp line 52:

> 50: 
> 51:   void do_test(Metaspace::MetadataType mdType) {
> 52:     _lock = new Mutex(Monitor::leaf, "gtest-IsMetaspaceObjTest-lock", Monitor::_safepoint_check_never);

Again unclear what impact false to true might have here - assuming VM threads even lock this? Ditto for other metaspace tests.

-------------

Marked as reviewed by dholmes (Reviewer).

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

From shade at openjdk.java.net  Mon Aug 30 06:45:33 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 30 Aug 2021 06:45:33 GMT
Subject: Integrated: 8272838: Move CriticalJNI tests out of tier1
In-Reply-To: <G0YRVmfZwtC0ZABcgkEE-nBwHRu7XLc1WoFkHn4wArc=.9cc5f88e-ead0-4a1a-bc67-729934217905@github.com>
References: <G0YRVmfZwtC0ZABcgkEE-nBwHRu7XLc1WoFkHn4wArc=.9cc5f88e-ead0-4a1a-bc67-729934217905@github.com>
Message-ID: <ZyAlNVMpka4Em20v1bjgpmMQxYd4xOURO-ud4GnV1cA=.aceae29d-fe4a-49ac-9916-a6877fad6d21@github.com>

On Mon, 23 Aug 2021 13:58:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug report for more discussion. These tests are tied in Epsilon and Shenandoah test groups, so I rehashed those a bit. Note there are no `tier2` or `tier3` test groups in Hotspot yet, which means these tests would only run as part of Epsilon and Shenandoah test suites. I would rehash tier2/3 in [JDK-8272914](https://bugs.openjdk.java.net/browse/JDK-8272914), while hooking up more runtime and GC tests there.
> 
> Motivational run time improvements:
> 
> 
> $  make run-test TEST=hotspot:tier1
> 
> # Before
> real	8m9.678s
> user	289m59.304s
> sys	27m46.347s
> 
> # After
> real	7m53.359s    # 15 seconds saved
> user	278m49.104s  # 11 minutes saved
> sys	28m2.516s
> 
> 
> Additional testing:
>  - [x] Checked `hotspot:tier1` run test lists before/after the patch, the difference is only these two lists
>  - [x] Some test performance measurements.

This pull request has now been integrated.

Changeset: f55d5ab5
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f55d5ab5177b6e08e8499abc181a320a98b28a5f
Stats:     18 lines in 1 file changed: 10 ins; 4 del; 4 mod

8272838: Move CriticalJNI tests out of tier1

Reviewed-by: dholmes

-------------

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

From fmatte at openjdk.java.net  Mon Aug 30 08:33:29 2021
From: fmatte at openjdk.java.net (Fairoz Matte)
Date: Mon, 30 Aug 2021 08:33:29 GMT
Subject: RFR: 8272563: Possible assertion failure in CardTableBarrierSetC1
In-Reply-To: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
Message-ID: <W7naND2DjQpVAwK_UgptdbesXRkhLrL7K6IR3VwH420=.28087e98-409d-46e6-9876-76693cbf5f37@github.com>

On Wed, 18 Aug 2021 12:37:00 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
> 
> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>> __ move(addr, tmp);
> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
> The fix is to check if it is is_oop() and call the mov appropriately.
> 
> No issues found in local testing and Mach5 tier1-3

Hi Igor, 

Thanks for looking into this and thanks for the pointers to handle the spills in logic involved in T_OBJECT to T_LONG mov's and Also to check the src and dst must have the registers.
These conditions can be handled using asserts/guarantee's (as the function doesn't return). 
But as original patch suggests we can have solution by copying over extra temp register. 

In https://github.com/openjdk/jdk/blob/d732c3091fea0a7c6d6767227de89002564504e5/src/hotspot/share/c1/c1_LinearScan.cpp#L1135 It was not handled and enfornced we must have both registers. So I am not sure if we also can handle this scenario or it can be prevented as done in c1_LinearScan.cpp file.

Thanks,

-------------

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

From redestad at openjdk.java.net  Mon Aug 30 08:41:26 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 30 Aug 2021 08:41:26 GMT
Subject: RFR: 8264207: CodeStrings does not honour fixed address
 assumption.
In-Reply-To: <qkFzmEzzUnOzJ-kmwVvTI3DJ8Ja3g6oz2hHADnq7JG4=.af1dcee3-f9d3-450a-b39e-27a1644c4521@github.com>
References: <qkFzmEzzUnOzJ-kmwVvTI3DJ8Ja3g6oz2hHADnq7JG4=.af1dcee3-f9d3-450a-b39e-27a1644c4521@github.com>
Message-ID: <I1xpI_N1ZW9AaSJKvvRgPTcPdFhz0i1h8AelrbJ0YgE=.5e59a251-1d3d-4856-8368-3831617aee8b@github.com>

On Fri, 27 Aug 2021 15:19:42 GMT, Patric Hedlin <phedlin at openjdk.org> wrote:

> Please review this change that addresses an issue originally found in JDK-8259590,
> where the error message should read
> `fatal error: DEBUG MESSAGE: verify_oop: r10: broken oop in decode_heap_oop`
> but is lost since the code generated refers to a fixed (string) address, a string
> (address) no longer available when **CodeStrings** have been propagated (copied)
> between code buffers/blobs.
> 
> Background
> 
> **CodeStrings** used to be **CodeComments**. The solution to JDK-8008555 introduced
> this change and added a new use-case for **CodeStrings**, not only as comments, but
> as strings with a fixed address used in the code generated with support for debug
> string printouts.
> 
> The changes introduced with JDK-8255208 breaks the fixed address assumption made
> in the code generated with support for debug string printouts. Some of the (necessary)
> move semantics have been replaced by copy semantics when **CodeStrings** are
> propagated between code buffers/blobs (i.e. **CodeBuffer** and **CodeBlob** objects).
> 
> Additional issue addressed
> 
> + Broken printout (i.e. missing  remarks) when multiple stubs are generated within
>   the same primary buffer.
> 
> The following steps have been taken to provide fixed address (debug) strings.
> 
> + Introduce a simple _gtest_ for **CodeString/s** support with **CodeBuffer/CodeBlob**.
> + Split **CodeStrings**  into two different abstractions;  strings associated with an offset,
>   and strings with a fixed address.
>   - Let the  first be  _Assembly Code  Remarks_, **AsmRemarks**, providing a simple
>     1:N mapping, _offset_ -> _remark_.
>   - Let the second be _Debug  Printout Strings_, **DbgStrings**, supporting a fixed
>     address assumption such that:
>       for each string A and B, if A = B -> &A = &B.
>   - Use a  reference counting scheme to  ensure that both types  of strings are
>     deallocated properly, when no longer in use.
> + Remove **CodeStrings** from **Stub** interface.
>   - Replace with internal use in the interpreter code, propagating the code
>     (assembly) remarks directly to the final codelet.
> + Remove  **CodeBuffer** self destruction, overwriting memory before  all
>   deconstructors have been executed.
>   - Replace with sentinel deconstructor to do the bidding.
> + Stub code generated into a single common **CodeBuffer**  (holding a number
>   of stubs) will  not print the assembly remarks correctly  (except for the very first
>   stub code section).
>   - Introduce a displacement to correct the offset.
> + Remove old **CodeString/s** implementation.
> 
> Testing
> 
> Tier1-3 in debug mode, using debug strings, _without_ collecting remarks.
> Tier1-3 in debug mode, using debug strings, _with_ collecting remarks (regardless of options).
> Manual inspection of results (linux-x64 and linux-aarch64 only) for the following command line options:
> `-XX:+PrintSignatureHandlers -XX:+PrintInterpreter -XX:+PrintStubCode -XX:+PrintAssembly`

FWIW (from someone who helped messing this up) I think this looks great. Clearly separates conflicting concerns and removes all trace of debug-only facilities in release code.

-------------

Marked as reviewed by redestad (Reviewer).

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

From mbaesken at openjdk.java.net  Mon Aug 30 12:04:36 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 30 Aug 2021 12:04:36 GMT
Subject: RFR: 8271490: [ppc] [s390]: Crash in
 JavaThread::pd_get_top_frame_for_profiling
In-Reply-To: <bD_GSVWnQEH5L4k08xN_CH7jtbpmHl7b5mwhLb_03lo=.81186ce8-3345-498c-934e-c4bf03bf80ab@github.com>
References: <bD_GSVWnQEH5L4k08xN_CH7jtbpmHl7b5mwhLb_03lo=.81186ce8-3345-498c-934e-c4bf03bf80ab@github.com>
Message-ID: <1aqJQPm4F9ThfgiuMmvztJLFbPk1L2Cb9L2pESqMVRw=.10412a57-c70d-4b4e-9e88-b614d4396539@github.com>

On Tue, 10 Aug 2021 14:50:34 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> Please review this pull request. It hardens the code on ppc and s390 against crashes while collecting stack traces for JFR. Stack frame collection in prims/forte.cpp will benefit from this fix as well as it uses the same platform-specific code.
> 
> Testing:
> SAP-internal functional and stress testing. Verifying a positive effect is hard because the targeted crashes occur only very rarely. No negative side effects of the fix have been observed.

Marked as reviewed by mbaesken (Reviewer).

-------------

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

From lucy at openjdk.java.net  Mon Aug 30 12:34:34 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Mon, 30 Aug 2021 12:34:34 GMT
Subject: RFR: 8271490: [ppc] [s390]: Crash in
 JavaThread::pd_get_top_frame_for_profiling
In-Reply-To: <bD_GSVWnQEH5L4k08xN_CH7jtbpmHl7b5mwhLb_03lo=.81186ce8-3345-498c-934e-c4bf03bf80ab@github.com>
References: <bD_GSVWnQEH5L4k08xN_CH7jtbpmHl7b5mwhLb_03lo=.81186ce8-3345-498c-934e-c4bf03bf80ab@github.com>
Message-ID: <qBwiVHel5s0xeK5j_O_MVAIHO55SglqArS2D20QHOEo=.f3cb4974-892c-42cc-9aba-ca2bdcacadf5@github.com>

On Tue, 10 Aug 2021 14:50:34 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> Please review this pull request. It hardens the code on ppc and s390 against crashes while collecting stack traces for JFR. Stack frame collection in prims/forte.cpp will benefit from this fix as well as it uses the same platform-specific code.
> 
> Testing:
> SAP-internal functional and stress testing. Verifying a positive effect is hard because the targeted crashes occur only very rarely. No negative side effects of the fix have been observed.

Thank you, Matthias, for reviewing and approving this fix. Will integrate now.

-------------

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

From lucy at openjdk.java.net  Mon Aug 30 12:34:34 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Mon, 30 Aug 2021 12:34:34 GMT
Subject: Integrated: 8271490: [ppc] [s390]: Crash in
 JavaThread::pd_get_top_frame_for_profiling
In-Reply-To: <bD_GSVWnQEH5L4k08xN_CH7jtbpmHl7b5mwhLb_03lo=.81186ce8-3345-498c-934e-c4bf03bf80ab@github.com>
References: <bD_GSVWnQEH5L4k08xN_CH7jtbpmHl7b5mwhLb_03lo=.81186ce8-3345-498c-934e-c4bf03bf80ab@github.com>
Message-ID: <imm1_vSXenwFathkAXOOE4BMucQ1qYARbp_Q6OIq3Ss=.ee93bea0-b98f-410d-92fb-7de73808baaf@github.com>

On Tue, 10 Aug 2021 14:50:34 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> Please review this pull request. It hardens the code on ppc and s390 against crashes while collecting stack traces for JFR. Stack frame collection in prims/forte.cpp will benefit from this fix as well as it uses the same platform-specific code.
> 
> Testing:
> SAP-internal functional and stress testing. Verifying a positive effect is hard because the targeted crashes occur only very rarely. No negative side effects of the fix have been observed.

This pull request has now been integrated.

Changeset: 276b07b3
Author:    Lutz Schmidt <lucy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/276b07b36af01d339e48baada7a512451fe34afe
Stats:     105 lines in 4 files changed: 76 ins; 12 del; 17 mod

8271490: [ppc] [s390]: Crash in JavaThread::pd_get_top_frame_for_profiling

Reviewed-by: stuefe, mbaesken

-------------

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

From coleenp at openjdk.java.net  Mon Aug 30 14:41:35 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 30 Aug 2021 14:41:35 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v7]
In-Reply-To: <0KxWmQwhAAzYjmjmRJ6AeuZUkKGYSAOZSXRGiNRtg3U=.cc146836-c11f-402f-b0c8-7cabb080422e@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
 <LcA_1_9zlZbXy_mrZY7BFtQvvWxfjMM2mtslH0HPXSY=.4b005b74-50bb-41f4-91ab-7547e9549b28@github.com>
 <0KxWmQwhAAzYjmjmRJ6AeuZUkKGYSAOZSXRGiNRtg3U=.cc146836-c11f-402f-b0c8-7cabb080422e@github.com>
Message-ID: <inBADyO83ej6eHvhpVpgM4TDvxCQkghXyY8gYU8hNXU=.d49d4147-10d5-48af-9d32-3613e91a091d@github.com>

On Mon, 30 Aug 2021 02:17:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverse the order of safepoint_check_required and allow_vm_block arguments so that the first can imply the value of the second.  This is good because if we decide to rename the second to something like _allow_safepoint_use instead there's less to change. Also remove default arguments as they are evil.
>
> src/hotspot/share/gc/shared/taskTerminator.cpp line 75:
> 
>> 73:   _queue_set(queue_set),
>> 74:   _offered_termination(0),
>> 75:   _blocker(Mutex::leaf, "TaskTerminator", Monitor::_safepoint_check_never),
> 
> Is this lock even used by any JavaThreads? I'm guessing not - in which cases the always/never and allow/not-allow are immaterial, and the change is harmless.

I see no evidence of this lock being taken by JavaThreads

> src/hotspot/share/gc/z/zMetronome.cpp line 31:
> 
>> 29: 
>> 30: ZMetronome::ZMetronome(uint64_t hz) :
>> 31:     _monitor(Monitor::leaf, "ZMetronome", Monitor::_safepoint_check_never),
> 
> Again the "false" to "true" stands out here, but again I have to assume this is not a lock that is used by JavaThreads. Makes me wonder whether these locks can never encounter contention by the VMThread (otherwise they would assert).

Also appears that this is only taken by GC threads.

-------------

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

From coleenp at openjdk.java.net  Mon Aug 30 14:50:38 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 30 Aug 2021 14:50:38 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v7]
In-Reply-To: <LcA_1_9zlZbXy_mrZY7BFtQvvWxfjMM2mtslH0HPXSY=.4b005b74-50bb-41f4-91ab-7547e9549b28@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
 <LcA_1_9zlZbXy_mrZY7BFtQvvWxfjMM2mtslH0HPXSY=.4b005b74-50bb-41f4-91ab-7547e9549b28@github.com>
Message-ID: <E4VZl0hUuYbBrqz6Pw8F7b2o8eVAlu130IaNPYEjby8=.7b533a8c-f570-478b-a187-47c914bd6e0d@github.com>

On Fri, 27 Aug 2021 15:54:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
>> Tested with tier1-6.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverse the order of safepoint_check_required and allow_vm_block arguments so that the first can imply the value of the second.  This is good because if we decide to rename the second to something like _allow_safepoint_use instead there's less to change. Also remove default arguments as they are evil.

Thanks for the review, David.

Thanks for the work of going through all the details of this with me, David and Patricio!

-------------

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

From coleenp at openjdk.java.net  Mon Aug 30 14:50:40 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 30 Aug 2021 14:50:40 GMT
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v7]
In-Reply-To: <0KxWmQwhAAzYjmjmRJ6AeuZUkKGYSAOZSXRGiNRtg3U=.cc146836-c11f-402f-b0c8-7cabb080422e@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
 <LcA_1_9zlZbXy_mrZY7BFtQvvWxfjMM2mtslH0HPXSY=.4b005b74-50bb-41f4-91ab-7547e9549b28@github.com>
 <0KxWmQwhAAzYjmjmRJ6AeuZUkKGYSAOZSXRGiNRtg3U=.cc146836-c11f-402f-b0c8-7cabb080422e@github.com>
Message-ID: <3BwNuWsFuNdrmYwZofgDB8PHBv-lJURpiiKVWUUoTYs=.c7c72dfc-c691-4b37-953e-f0250ac0d32f@github.com>

On Mon, 30 Aug 2021 02:34:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverse the order of safepoint_check_required and allow_vm_block arguments so that the first can imply the value of the second.  This is good because if we decide to rename the second to something like _allow_safepoint_use instead there's less to change. Also remove default arguments as they are evil.
>
> src/hotspot/share/memory/heapInspection.hpp line 248:
> 
>> 246:       _missed_count(0),
>> 247:       _success(true),
>> 248:       _mutex(Mutex::leaf, "Parallel heap iteration data merge lock", Mutex::_safepoint_check_always) {}
> 
> Is this lock even used by JavaThreads. ??

It doesn't look like this is.  If we change the _allow_vm_block check in Mutex::check_block_state to be:

     if (!_enforces_nsv && (!thread->isJavaThread() && is_at_safepoint())) {
         // some good explanatory comment
         fatal("A NonJava thread could block on lock that may be held by a JavaThread during safepoint: %s", name());
    }

I think this lock will get caught by this assert.

> test/hotspot/gtest/metaspace/test_is_metaspace_obj.cpp line 52:
> 
>> 50: 
>> 51:   void do_test(Metaspace::MetadataType mdType) {
>> 52:     _lock = new Mutex(Monitor::leaf, "gtest-IsMetaspaceObjTest-lock", Monitor::_safepoint_check_never);
> 
> Again unclear what impact false to true might have here - assuming VM threads even lock this? Ditto for other metaspace tests.

It has zero impact.  These locks just want no safepoint checking.

-------------

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

From coleenp at openjdk.java.net  Mon Aug 30 14:50:40 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 30 Aug 2021 14:50:40 GMT
Subject: Integrated: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block
In-Reply-To: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
Message-ID: <4xwQms7_hnUumfY60jGTVVdVIFbRZ464fxi28029Ydw=.f306dd7a-aab3-4afa-8f11-a2082264d04a@github.com>

On Mon, 23 Aug 2021 13:19:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> See CR for details.  This essentially makes Mutex that safepoint_check_never imply a NoSafepointVerifier, which is a stronger and simpler invariant.
> Tested with tier1-6.

This pull request has now been integrated.

Changeset: 98b9d980
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/98b9d98032a700490cda72f645dad505164ec699
Stats:     134 lines in 40 files changed: 25 ins; 9 del; 100 mod

8272797: Mutex with rank safepoint_check_never imply allow_vm_block

Reviewed-by: dholmes, pchilanomate

-------------

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

From iveresov at openjdk.java.net  Mon Aug 30 15:50:32 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Mon, 30 Aug 2021 15:50:32 GMT
Subject: RFR: 8272563: Possible assertion failure in CardTableBarrierSetC1
In-Reply-To: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
Message-ID: <DfLB9NqjIoMI8CAaYt23K9nNCnSLwVfGrhsrMvzSS2Y=.7c782c70-e0de-42b3-8972-4f7836e596bc@github.com>

On Wed, 18 Aug 2021 12:37:00 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
> 
> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>> __ move(addr, tmp);
> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
> The fix is to check if it is is_oop() and call the mov appropriately.
> 
> No issues found in local testing and Mach5 tier1-3

Well, an extra temp register won't solve it, right? You're just getting lucky that tmp2 is not getting spilled. If that happens you get exactly the same situation as before, don't you?

-------------

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

From duke at openjdk.java.net  Mon Aug 30 21:04:37 2021
From: duke at openjdk.java.net (duke)
Date: Mon, 30 Aug 2021 21:04:37 GMT
Subject: Withdrawn: 8268229: Aarch64: Use Neon in intrinsics for String.equals
In-Reply-To: <xs7kAUDQn75K9AinTDBa6ZY1iql5_1OCiikiiRieSyc=.384d6122-e6db-4f2d-afb7-53730d624276@github.com>
References: <xs7kAUDQn75K9AinTDBa6ZY1iql5_1OCiikiiRieSyc=.384d6122-e6db-4f2d-afb7-53730d624276@github.com>
Message-ID: <CFiOWEH4S1VDNaae3Oqr_gzANBbh-3bv_yk02p__Wcw=.c4b1ac7e-dd57-4bb4-9327-a6929067a403@github.com>

On Wed, 9 Jun 2021 03:10:45 GMT, Wang Huang <whuang at openjdk.org> wrote:

> Dear all, 
>      Could you give me a favor to review this patch? It improves the performance of the intrinsic of `String.equals` on Neon backend of Aarch64.
>      We profile the performance by using this JMH case:
>  
> 
>    ```java
>     package com.huawei.string;
>     import java.util.*;
>     import java.util.concurrent.TimeUnit;
>     
>     import org.openjdk.jmh.annotations.CompilerControl;
>     import org.openjdk.jmh.annotations.Benchmark;
>     import org.openjdk.jmh.annotations.Level;
>     import org.openjdk.jmh.annotations.OutputTimeUnit;
>     import org.openjdk.jmh.annotations.Param;
>     import org.openjdk.jmh.annotations.Scope;
>     import org.openjdk.jmh.annotations.Setup;
>     import org.openjdk.jmh.annotations.State;
>     import org.openjdk.jmh.annotations.Fork;
>     import org.openjdk.jmh.infra.Blackhole;
>     
>     @State(Scope.Thread)
>     @OutputTimeUnit(TimeUnit.MILLISECONDS)
>     public class StringEqual {
>         @Param({"8", "64", "4096"})
>         int size;
>     
>         String str1;
>         String str2;
>     
>         @Setup(Level.Trial)
>         public void init() {
>             str1 = newString(size, 'c', '1');
>             str2 = newString(size, 'c', '2');
>         }
>     
>         public String newString(int length, char charToFill, char lastChar) {
>             if (length > 0) {
>                 char[] array = new char[length];
>                 Arrays.fill(array, charToFill);
>                 array[length - 1] = lastChar;
>                 return new String(array);
>             }
>             return "";
>         }
>     
>         @Benchmark
>         @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>         public boolean EqualString() {
>             return str1.equals(str2);
>         }
>     }
> 
>    ```
> The result is list as following:?Linux aarch64 with 128cores?
> 
> Benchmark                       | (size) |  Mode | Cnt  |     Score |     Error |  Units
> ----------------------------------|-------|---------|-------|------------|------------|----------
> StringEqual.EqualString      |         8 | thrpt  | 10 | 123971.994 | ? 1462.131 | ops/ms
> StringEqual.EqualString       |       64 | thrpt |  10  | 56009.960  | ?  999.734 | ops/ms
> StringEqual.EqualString        |    4096 | thrpt |  10 |   1943.852 | ?  8.159 | ops/ms
> StringEqual.EqualStringWithNEON    |   8 | thrpt |  10 | 120319.271  | ? 1392.185 | ops/ms
> StringEqual.EqualStringWithNEON    |  64 | thrpt |  10 |  72914.767 | ? 1814.173 | ops/ms
> StringEqual.EqualStringWithNEON  |  4096 | thrpt  | 10  |  2579.155 | ? 15.589 | ops/ms
> 
> Yours, 
> WANG Huang

This pull request has been closed without being integrated.

-------------

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

From serb at openjdk.java.net  Mon Aug 30 23:46:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Aug 2021 23:46:15 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v3]
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <TqRtp_210_WAMsWmEo00_0RH7ZdcoPgWKC0f5bt0YMQ=.a0f183a7-969d-4601-940e-d8a9558bddee@github.com>

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

Sergey Bylokhov 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:

 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Update the usage of Files.readAllLines()
 - Update datatransfer
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - 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
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/22865adf...79829ec8

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5210/files
  - new: https://git.openjdk.java.net/jdk/pull/5210/files/e7127644..79829ec8

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

  Stats: 9423 lines in 339 files changed: 5247 ins; 1917 del; 2259 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 david.holmes at oracle.com  Mon Aug 30 23:52:30 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Aug 2021 09:52:30 +1000
Subject: RFR: 8272797: Mutex with rank safepoint_check_never imply
 allow_vm_block [v7]
In-Reply-To: <3BwNuWsFuNdrmYwZofgDB8PHBv-lJURpiiKVWUUoTYs=.c7c72dfc-c691-4b37-953e-f0250ac0d32f@github.com>
References: <fa9jv0ecPTiU6pndlWts8_1BxZ1Yva8sOxAw-8fMagA=.e85e84f6-1a61-4ff3-87dd-701f2f9c3899@github.com>
 <LcA_1_9zlZbXy_mrZY7BFtQvvWxfjMM2mtslH0HPXSY=.4b005b74-50bb-41f4-91ab-7547e9549b28@github.com>
 <0KxWmQwhAAzYjmjmRJ6AeuZUkKGYSAOZSXRGiNRtg3U=.cc146836-c11f-402f-b0c8-7cabb080422e@github.com>
 <3BwNuWsFuNdrmYwZofgDB8PHBv-lJURpiiKVWUUoTYs=.c7c72dfc-c691-4b37-953e-f0250ac0d32f@github.com>
Message-ID: <c0d8fada-ba4f-2180-242a-5a7efa7f9544@oracle.com>

On 31/08/2021 12:50 am, Coleen Phillimore wrote:
> On Mon, 30 Aug 2021 02:34:17 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Reverse the order of safepoint_check_required and allow_vm_block arguments so that the first can imply the value of the second.  This is good because if we decide to rename the second to something like _allow_safepoint_use instead there's less to change. Also remove default arguments as they are evil.
>>
>> src/hotspot/share/memory/heapInspection.hpp line 248:
>>
>>> 246:       _missed_count(0),
>>> 247:       _success(true),
>>> 248:       _mutex(Mutex::leaf, "Parallel heap iteration data merge lock", Mutex::_safepoint_check_always) {}
>>
>> Is this lock even used by JavaThreads. ??
> 
> It doesn't look like this is.  If we change the _allow_vm_block check in Mutex::check_block_state to be:
> 
>       if (!_enforces_nsv && (!thread->isJavaThread() && is_at_safepoint())) {
>           // some good explanatory comment
>           fatal("A NonJava thread could block on lock that may be held by a JavaThread during safepoint: %s", name());
>      }
> 
> I think this lock will get caught by this assert.

The point of my comment was more that it seems very odd to mark a lock 
as safepoint-check-always when it is never used by any JavaThreads. 
Given it isn't used by JavaThreads then the actual value of the 
safepoint-check field is immaterial in practice, but saying "always" 
seems "wrong".

Cheers,
David
-----

>> test/hotspot/gtest/metaspace/test_is_metaspace_obj.cpp line 52:
>>
>>> 50:
>>> 51:   void do_test(Metaspace::MetadataType mdType) {
>>> 52:     _lock = new Mutex(Monitor::leaf, "gtest-IsMetaspaceObjTest-lock", Monitor::_safepoint_check_never);
>>
>> Again unclear what impact false to true might have here - assuming VM threads even lock this? Ditto for other metaspace tests.
> 
> It has zero impact.  These locks just want no safepoint checking.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/5218
> 

From fmatte at openjdk.java.net  Tue Aug 31 03:30:32 2021
From: fmatte at openjdk.java.net (Fairoz Matte)
Date: Tue, 31 Aug 2021 03:30:32 GMT
Subject: RFR: 8272563: Possible assertion failure in CardTableBarrierSetC1
In-Reply-To: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
Message-ID: <ASo1VmsjdAWj9mcLDow_oxdinxF5aq5VCv1YfKntwCw=.bd5f06e1-addb-4352-beb5-299d0b352213@github.com>

On Wed, 18 Aug 2021 12:37:00 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
> 
> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>> __ move(addr, tmp);
> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
> The fix is to check if it is is_oop() and call the mov appropriately.
> 
> No issues found in local testing and Mach5 tier1-3

yes that's being the case. 
I got your point, will try to add guarantees to handle this scenario and propose the solution after testing

-------------

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

From iveresov at openjdk.java.net  Tue Aug 31 04:39:28 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 31 Aug 2021 04:39:28 GMT
Subject: RFR: 8272563: Possible assertion failure in CardTableBarrierSetC1
In-Reply-To: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
Message-ID: <F5vQSXZIYPvj6lkkAkbApsP85oa15ArGKDmGeAPAi68=.fa394d65-1718-46c8-ae5d-61ceec050bc8@github.com>

On Wed, 18 Aug 2021 12:37:00 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
> 
> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>> __ move(addr, tmp);
> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
> The fix is to check if it is is_oop() and call the mov appropriately.
> 
> No issues found in local testing and Mach5 tier1-3

Oh, hey! Another much easier idea. Do it with a `lea`.


LIR_Address* addr_addr = new LIR_Address(addr, addr->type());
__ leal(addr_addr, tmp);

It will force `addr` into a register. And no need to mess  with the register allocator.

-------------

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

From ccheung at openjdk.java.net  Tue Aug 31 05:50:27 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 31 Aug 2021 05:50:27 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC [v5]
In-Reply-To: <wqNzq04QzDkkpRm1794wOaSMMqCvxTxsER17ypC48xk=.f26776a6-6026-4eac-b999-cf0964b6196e@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
 <wqNzq04QzDkkpRm1794wOaSMMqCvxTxsER17ypC48xk=.f26776a6-6026-4eac-b999-cf0964b6196e@github.com>
Message-ID: <MnsOs-2ayWNQ8nWVQoLy5OKLgfvr7_LsMImTfcijg0c=.fc18588f-a3b2-4c46-9f13-14f22e4f007b@github.com>

On Wed, 18 Aug 2021 00:12:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> **Overview:**
>> 
>> This is the first step for supporting archived heap objects for non-G1 collectors. We are doing it for EpsilonGC first to iron out the API between GC and CDS. Also we can implement most of the common code (such as copying archived objects into heap), without impacting the overall system stability.
>> 
>> - Only G1 can write archive heap objects into the CDS archive.
>> - Archived objects are "mapped" by G1, but the mapping operation is quite complex.
>> - All other collectors will "load" the archive objects, which is much simpler to implement. The trade off is a small start-up penalty and no heap sharing.
>> 
>> Most of the loading code is implemented in heapShared.cpp. The collectors just need to implement the following two `CollectedHeap` APIs in 
>> 
>> 
>>   virtual bool can_load_archived_objects();
>>   virtual HeapWord* allocate_loaded_archive_space(size_t size); // typically return a block in old gen
>> 
>> 
>> **Implementation:**
>> 
>> - Allocate (from the old gen) a buffer that's large enough to contain all the archived heap objects.
>> - Inside the CDS archive file, the heap objects are usually divided into 2~4 disjoint regions (there are gaps between them).
>> - Copy every region in to the buffer consecutively, without any gaps.
>> - Relocate all the oop fields in all the copied objects, taking into account of the gap removal.
>> - The archived strings may be relocated by a full GC, but the CDS "shared string table" cannot handle relocation, so we copy the archived strings into the dynamic string table.
>> 
>> **Benchmarking:** 
>> 
>> We can see significant start-up improvement because the module graph can be loaded from CDS.
>> 
>> 
>> $ perf stat -r 40 java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx256m -version
>> 
>> Before:  43.1ms
>> After:   30.2ms
>> 
>> 
>> Testing:
>> 
>> - Some general clean up of the test cases.
>> - Added support for `-vmoptions:-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`: we dump the CDS archive with G1 so we have an archived heap, but run with EpsilonGC to test the new loading code.
>> - Added a mach5 task to run all CDS tests with the above config. Incompatible test cases are tagged with `@require vm.gc == null`. See changes in CDSOption.java and VMProps.java
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @shipilev review - fixed whitespaces

src/hotspot/share/cds/filemap.hpp line 601:

> 599:   }
> 600: 
> 601: private:

Maybe move the public function to the public block before line 567 so that the labels at lines 595 and 601 could be removed.

src/hotspot/share/cds/heapShared.hpp line 221:

> 219:   static bool is_in_loaded_heap(uintptr_t o) {
> 220:     return (_loaded_heap_bottom <= o && o < _loaded_heap_top);
> 221:   }

This could be a private function since it is only referenced at line 223.

test/hotspot/jtreg/runtime/cds/appcds/TestEpsilonGCWithCDS.java line 62:

> 60:     static String G1 = "-XX:+UseG1GC";
> 61:     static String Epsilon = "-XX:+UseEpsilonGC";
> 62:     static String experiment = "-XX:+UnlockExperimentalVMOptions";

The above could be declared `final`.

test/lib/jdk/test/lib/cds/CDSOptions.java line 136:

> 134:     public static void disableRuntimePrefix(String s) {
> 135:         disabledRuntimePrefixes.add(s);
> 136:     }

This could be `private`.

-------------

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

From fmatte at openjdk.java.net  Tue Aug 31 14:54:56 2021
From: fmatte at openjdk.java.net (Fairoz Matte)
Date: Tue, 31 Aug 2021 14:54:56 GMT
Subject: RFR: 8272563: Possible assertion failure in CardTableBarrierSetC1
 [v2]
In-Reply-To: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
Message-ID: <GsSAnYhVkwpl-361QO1GIyhm5xVdgX-sybAC_SkI3xg=.1c0e93e5-1b7c-4af4-af8e-ef32340b0e56@github.com>

> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
> 
> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>> __ move(addr, tmp);
> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
> The fix is to check if it is is_oop() and call the mov appropriately.
> 
> No issues found in local testing and Mach5 tier1-3

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

  8272563: Possible assertion failure in CardTableBarrierSetC1

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5164/files
  - new: https://git.openjdk.java.net/jdk/pull/5164/files/374cd7b8..c023f4bc

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

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

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

From fmatte at openjdk.java.net  Tue Aug 31 14:59:27 2021
From: fmatte at openjdk.java.net (Fairoz Matte)
Date: Tue, 31 Aug 2021 14:59:27 GMT
Subject: RFR: 8272563: Possible assertion failure in CardTableBarrierSetC1
 [v2]
In-Reply-To: <GsSAnYhVkwpl-361QO1GIyhm5xVdgX-sybAC_SkI3xg=.1c0e93e5-1b7c-4af4-af8e-ef32340b0e56@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
 <GsSAnYhVkwpl-361QO1GIyhm5xVdgX-sybAC_SkI3xg=.1c0e93e5-1b7c-4af4-af8e-ef32340b0e56@github.com>
Message-ID: <t2-X-wYlvp-2cfI1-qf8BB8Gzd8M6jFnh8FDCFpp7kI=.57d1ea0e-743e-4940-9cd6-4a0ecf5e358e@github.com>

On Tue, 31 Aug 2021 14:54:56 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

>> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
>> 
>> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>>> __ move(addr, tmp);
>> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
>> The fix is to check if it is is_oop() and call the mov appropriately.
>> 
>> No issues found in local testing and Mach5 tier1-3
>
> Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8272563: Possible assertion failure in CardTableBarrierSetC1

Hi Igor, 

Possibly you mean this,
`      LIR_Opr addr_opr = LIR_OprFact::address(new LIR_Address(addr, addr->type()));
      __ leal(addr_opr, tmp);`
I have updated the patch with this fix and there is no issue in hs-tier1 to hs-tier3

-------------

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

From iveresov at openjdk.java.net  Tue Aug 31 17:00:35 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 31 Aug 2021 17:00:35 GMT
Subject: RFR: 8272563: Possible assertion failure in CardTableBarrierSetC1
 [v2]
In-Reply-To: <GsSAnYhVkwpl-361QO1GIyhm5xVdgX-sybAC_SkI3xg=.1c0e93e5-1b7c-4af4-af8e-ef32340b0e56@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
 <GsSAnYhVkwpl-361QO1GIyhm5xVdgX-sybAC_SkI3xg=.1c0e93e5-1b7c-4af4-af8e-ef32340b0e56@github.com>
Message-ID: <waJYHjkIaaW58ecaBECGv_7Tlf5W3iEVBUEnCMFZzME=.4663ff7e-d001-4179-8e11-f1f471cdd25d@github.com>

On Tue, 31 Aug 2021 14:54:56 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

>> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
>> 
>> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>>> __ move(addr, tmp);
>> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
>> The fix is to check if it is is_oop() and call the mov appropriately.
>> 
>> No issues found in local testing and Mach5 tier1-3
>
> Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8272563: Possible assertion failure in CardTableBarrierSetC1

Good. You don't actually need to check if it's an oop or not. You can just do `leal` for all the types.

-------------

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

From shade at openjdk.java.net  Tue Aug 31 19:37:00 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 31 Aug 2021 19:37:00 GMT
Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering [v9]
In-Reply-To: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
Message-ID: <iscV74G2qQwcZv_WDsO6BRG3F34wJkgiD9Am4dGMED8=.e70ca24b-af87-4f76-aeb6-e2e79818fe6f@github.com>

> Shenandoah carries forwardee information in object's mark word. Installing the new mark word is effectively "releasing" the object copy, and reading from the new mark word is "acquiring" that object copy.
> 
> For the forwardee update side, Hotspot's default for atomic operations is memory_order_conservative, which emits two-way memory fences around the CASes at least on AArch64 and PPC64. This seems to be excessive for Shenandoah forwardee updates, and "release" is enough.
> 
> The reader side is much more interesting, because we generally want "consume", but it is not available. We can do "acquire", but it regresses performance all too much. The close inspection of the code reveals we need "acquire" on many paths, but not on the most critical one: heap updates. This must explain why current weaker reader side was never seen to fail, and this also opens a way to get `acquire`-in-lieu-of-`consume` without the observable performance penalty.
> 
> The relaxation in forwardee installation improves concurrent evacuation quite visibly. See for example GC cycle times with SPECjvm2008, Compiler.sunflow on AArch64:
> 
> Before:
> 
> 
> [info][gc,stats] Concurrent Evacuation          =    3.421 s (a =    21247 us) (n =   161)
> [info][gc,stats] Concurrent Evacuation          =    3.584 s (a =    21080 us) (n =   170)
> [info][gc,stats] Concurrent Evacuation          =    3.226 s (a =    21088 us) (n =   153)
> [info][gc,stats] Concurrent Evacuation          =    3.270 s (a =    20827 us) (n =   157)
> [info][gc,stats] Concurrent Evacuation          =    3.339 s (a =    20742 us) (n =   161)
> 
> 
> After:
> 
> [info][gc,stats] Concurrent Evacuation          =    3.109 s (a =    18617 us) (n =   167)
> [info][gc,stats] Concurrent Evacuation          =    3.027 s (a =    18918 us) (n =   160) 
> [info][gc,stats] Concurrent Evacuation          =    2.862 s (a =    17669 us) (n =   162) 
> [info][gc,stats] Concurrent Evacuation          =    2.858 s (a =    17425 us) (n =   164) 
> [info][gc,stats] Concurrent Evacuation          =    2.883 s (a =    17685 us) (n =   163) 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 `hotspot_gc_shenandoah`
>  - [x] Linux AArch64 `hotspot_gc_shenandoah`
>  - [ ] Linux x86_64 `tier1` with Shenandoah
>  - [ ] Linux AArch64 `tier1` with Shenandoah

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Doing acquires on most paths, and relaxed on the path that matters: heap update
 - Even more discussion
 - Additional discussion and corner cases
 - Merge branch 'master' into JDK-8261492-shenandoah-forwardee-memord
 - Add TODO
 - "acquire" is too slow on aarch64, and does not seem neccessary anyway
 - Merge branch 'master' into JDK-8261492-shenandoah-forwardee-memord
 - 8261492: Shenandoah: reconsider forwardee accesses memory ordering

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2496/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2496&range=08
  Stats: 174 lines in 13 files changed: 104 ins; 30 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2496.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2496/head:pull/2496

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

From shade at openjdk.java.net  Tue Aug 31 19:37:23 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 31 Aug 2021 19:37:23 GMT
Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering [v8]
In-Reply-To: <_IqJ7u4Vk7jF8E--2RzWfdnxYXDQr86TIsxA7sh_3WI=.4d2c4cd9-63c8-4921-b5a1-e77d66c10325@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
 <_IqJ7u4Vk7jF8E--2RzWfdnxYXDQr86TIsxA7sh_3WI=.4d2c4cd9-63c8-4921-b5a1-e77d66c10325@github.com>
Message-ID: <nSw6WOsSd_5D4f0CMKBF-zkuLQhJfHcN3OyQIJHakv8=.035e9c8e-1773-482b-8738-d80f2605a1c5@github.com>

On Mon, 5 Jul 2021 16:23:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Shenandoah carries forwardee information in object's mark word. Installing the new mark word is effectively "releasing" the object copy, and reading from the new mark word is "acquiring" that object copy.
>> 
>> For the forwardee update side, Hotspot's default for atomic operations is memory_order_conservative, which emits two-way memory fences around the CASes at least on AArch64 and PPC64. This seems to be excessive for Shenandoah forwardee updates, and "release" is enough.
>> 
>> The reader side is much more interesting, because we generally want "consume", but it is not available. We can do "acquire", but it regresses performance all too much. The close inspection of the code reveals we need "acquire" on many paths, but not on the most critical one: heap updates. This must explain why current weaker reader side was never seen to fail, and this also opens a way to get `acquire`-in-lieu-of-`consume` without the observable performance penalty.
>> 
>> The relaxation in forwardee installation improves concurrent evacuation quite visibly. See for example GC cycle times with SPECjvm2008, Compiler.sunflow on AArch64:
>> 
>> Before:
>> 
>> 
>> [info][gc,stats] Concurrent Evacuation          =    3.421 s (a =    21247 us) (n =   161)
>> [info][gc,stats] Concurrent Evacuation          =    3.584 s (a =    21080 us) (n =   170)
>> [info][gc,stats] Concurrent Evacuation          =    3.226 s (a =    21088 us) (n =   153)
>> [info][gc,stats] Concurrent Evacuation          =    3.270 s (a =    20827 us) (n =   157)
>> [info][gc,stats] Concurrent Evacuation          =    3.339 s (a =    20742 us) (n =   161)
>> 
>> 
>> After:
>> 
>> [info][gc,stats] Concurrent Evacuation          =    3.109 s (a =    18617 us) (n =   167)
>> [info][gc,stats] Concurrent Evacuation          =    3.027 s (a =    18918 us) (n =   160) 
>> [info][gc,stats] Concurrent Evacuation          =    2.862 s (a =    17669 us) (n =   162) 
>> [info][gc,stats] Concurrent Evacuation          =    2.858 s (a =    17425 us) (n =   164) 
>> [info][gc,stats] Concurrent Evacuation          =    2.883 s (a =    17685 us) (n =   163) 
>> 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 `hotspot_gc_shenandoah`
>>  - [x] Linux AArch64 `hotspot_gc_shenandoah`
>>  - [ ] Linux x86_64 `tier1` with Shenandoah
>>  - [ ] Linux AArch64 `tier1` with Shenandoah
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add TODO

More work: leave `acquire`-in-lieu-of-`consume` in, and special case the heap update paths to dodge the performance penalty of doing so. Seems to work on x86_64 and AArch64.

-------------

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

From iklam at openjdk.java.net  Tue Aug 31 19:58:33 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 31 Aug 2021 19:58:33 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC [v5]
In-Reply-To: <MnsOs-2ayWNQ8nWVQoLy5OKLgfvr7_LsMImTfcijg0c=.fc18588f-a3b2-4c46-9f13-14f22e4f007b@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
 <wqNzq04QzDkkpRm1794wOaSMMqCvxTxsER17ypC48xk=.f26776a6-6026-4eac-b999-cf0964b6196e@github.com>
 <MnsOs-2ayWNQ8nWVQoLy5OKLgfvr7_LsMImTfcijg0c=.fc18588f-a3b2-4c46-9f13-14f22e4f007b@github.com>
Message-ID: <OySjPPGrDcyfKVocHtBJ0EzvBxsXBlTrkNsrtIA-LZw=.c0a5992f-d38f-4379-bc4e-3b5011b19b86@github.com>

On Tue, 31 Aug 2021 05:46:53 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @shipilev review - fixed whitespaces
>
> src/hotspot/share/cds/filemap.hpp line 601:
> 
>> 599:   }
>> 600: 
>> 601: private:
> 
> Maybe move the public function to the public block before line 567 so that the labels at lines 595 and 601 could be removed.

I think it's better to keep the functions together so you can see the difference between `start_address_as_decoded_with_current_oop_encoding_mode` and `start_address_as_decoded_from_archive`. I've shuffled the code a little to group the two related private methods together.

> src/hotspot/share/cds/heapShared.hpp line 221:
> 
>> 219:   static bool is_in_loaded_heap(uintptr_t o) {
>> 220:     return (_loaded_heap_bottom <= o && o < _loaded_heap_top);
>> 221:   }
> 
> This could be a private function since it is only referenced at line 223.

Fixed.

> test/hotspot/jtreg/runtime/cds/appcds/TestEpsilonGCWithCDS.java line 62:
> 
>> 60:     static String G1 = "-XX:+UseG1GC";
>> 61:     static String Epsilon = "-XX:+UseEpsilonGC";
>> 62:     static String experiment = "-XX:+UnlockExperimentalVMOptions";
> 
> The above could be declared `final`.

Fixed.

> test/lib/jdk/test/lib/cds/CDSOptions.java line 136:
> 
>> 134:     public static void disableRuntimePrefix(String s) {
>> 135:         disabledRuntimePrefixes.add(s);
>> 136:     }
> 
> This could be `private`.

Fixed.

-------------

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

From serb at openjdk.java.net  Tue Aug 31 20:17:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 31 Aug 2021 20:17:25 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v4]
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <0BjXWeJE25KSeovjDycar9nGsqSQ4vehXgMBrqwWGHQ=.e83aec87-77a8-414d-9acb-bdbdd6bb27ca@github.com>

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

Sergey Bylokhov 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 16 additional commits since the last revision:

 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Update the usage of Files.readAllLines()
 - Update datatransfer
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/7289121a...7fe0327e

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5210/files
  - new: https://git.openjdk.java.net/jdk/pull/5210/files/79829ec8..7fe0327e

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

  Stats: 949 lines in 30 files changed: 678 ins; 166 del; 105 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 github.com+2249648+johntortugo at openjdk.java.net  Tue Aug 31 21:14:24 2021
From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo)
Date: Tue, 31 Aug 2021 21:14:24 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 IGV transformations [v3]
In-Reply-To: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
References: <XRsWZP-Y9oaSCSAbuS7y8lPJNGpjOENVF3-FzPSyuGA=.c6831bc6-afd3-4a6a-9cf5-0bd6fa4332da@github.com>
Message-ID: <B6Em9O9GXxcO_FDTyqVzunW2fr99noa8YeMd68Jx24M=.bfc3e431-9dc2-4bd7-bb56-615897d45c3e@github.com>

> Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:
> 
> - Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
> - Add more default IR regex's to IR-based test framework.
> - Changes to Sub, Div and Add Ideal nodes to that transformations on Int and Long types are the whenever possible same.
> - Changes to Sub*Node, Div*Node and Add*Node Ideal methods to fix some bugs and include new transformations.
> - New JTREG "ir_transformations" test group under test/hotspot/jtreg.

John Tortugo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'openjdk:master' into jdk-8267265
 - Reverting changes to Ideal transformations. Removing failing tests. Reverting order of nodes in IRNode.
 - Fix carriage returns one more time.
 - Fix more carriage returns.
 - Fixing carriage return chars.
 - Adding some tests for Ideal transformations.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5135/files
  - new: https://git.openjdk.java.net/jdk/pull/5135/files/22565304..ac430bf7

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

  Stats: 13949 lines in 544 files changed: 7990 ins; 3191 del; 2768 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5135.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5135/head:pull/5135

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

From coleenp at openjdk.java.net  Tue Aug 31 21:52:12 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 31 Aug 2021 21:52:12 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be
 safepoint_check_never [v3]
In-Reply-To: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
References: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
Message-ID: <KHFjN45Butkaa01MKtDqdLmN2VvyXshyixKGiQQQS84=.f12a6a36-04f2-404d-8afd-06554aa746c3@github.com>

> I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
> Tested with tier1-3.  Tier 4-6 testing in progress.

Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Fix merge error.
 - Merge branch 'master' into nonleaf
 - Remove JfrSream_lock and rerun JFR tests.
 - 8272788: Nonleaf ranked locks should not be safepoint_check_neve

-------------

Changes: https://git.openjdk.java.net/jdk/pull/5203/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5203&range=02
  Stats: 20 lines in 4 files changed: 3 ins; 13 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5203.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5203/head:pull/5203

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

From jiefu at openjdk.java.net  Tue Aug 31 23:16:05 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 31 Aug 2021 23:16:05 GMT
Subject: RFR: 8273206: jdk/jfr/event/gc/collection/TestG1ParallelPhases.java
 fails after JDK-8159979
Message-ID: <-Odd9NyApeMHE3VC6K9bHC7cSoKFJfwQtKj9IA7mDyc=.e8274c9e-c191-4041-989b-108b19d78167@github.com>

8273206: jdk/jfr/event/gc/collection/TestG1ParallelPhases.java fails after JDK-8159979

-------------

Commit messages:
 - 8273206: jdk/jfr/event/gc/collection/TestG1ParallelPhases.java fails after JDK-8159979

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

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

From iklam at openjdk.java.net  Tue Aug 31 23:55:22 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 31 Aug 2021 23:55:22 GMT
Subject: RFR: 8270489: Support archived heap objects in EpsilonGC [v6]
In-Reply-To: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
References: <8uAZQGqz-B1JzhrfMGkEz2r-jeZKLbZluxKy3BeLW6c=.5165b6ba-f6ac-48c6-ad78-12210b2e51bd@github.com>
Message-ID: <QiKMQUfO_ZFUS4ufFOeE6nmniUhgLOlqMeB8Ibz7NKM=.0e4bef36-f45d-43c9-814b-d87fcbba198f@github.com>

> **Overview:**
> 
> This is the first step for supporting archived heap objects for non-G1 collectors. We are doing it for EpsilonGC first to iron out the API between GC and CDS. Also we can implement most of the common code (such as copying archived objects into heap), without impacting the overall system stability.
> 
> - Only G1 can write archive heap objects into the CDS archive.
> - Archived objects are "mapped" by G1, but the mapping operation is quite complex.
> - All other collectors will "load" the archive objects, which is much simpler to implement. The trade off is a small start-up penalty and no heap sharing.
> 
> Most of the loading code is implemented in heapShared.cpp. The collectors just need to implement the following two `CollectedHeap` APIs in 
> 
> 
>   virtual bool can_load_archived_objects();
>   virtual HeapWord* allocate_loaded_archive_space(size_t size); // typically return a block in old gen
> 
> 
> **Implementation:**
> 
> - Allocate (from the old gen) a buffer that's large enough to contain all the archived heap objects.
> - Inside the CDS archive file, the heap objects are usually divided into 2~4 disjoint regions (there are gaps between them).
> - Copy every region in to the buffer consecutively, without any gaps.
> - Relocate all the oop fields in all the copied objects, taking into account of the gap removal.
> - The archived strings may be relocated by a full GC, but the CDS "shared string table" cannot handle relocation, so we copy the archived strings into the dynamic string table.
> 
> **Benchmarking:** 
> 
> We can see significant start-up improvement because the module graph can be loaded from CDS.
> 
> 
> $ perf stat -r 40 java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx256m -version
> 
> Before:  43.1ms
> After:   30.2ms
> 
> 
> Testing:
> 
> - Some general clean up of the test cases.
> - Added support for `-vmoptions:-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`: we dump the CDS archive with G1 so we have an archived heap, but run with EpsilonGC to test the new loading code.
> - Added a mach5 task to run all CDS tests with the above config. Incompatible test cases are tagged with `@require vm.gc == null`. See changes in CDSOption.java and VMProps.java

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

  @calvinccheung comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5074/files
  - new: https://git.openjdk.java.net/jdk/pull/5074/files/1d309451..652f94fb

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

  Stats: 17 lines in 4 files changed: 8 ins; 5 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5074.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5074/head:pull/5074

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