From dholmes at openjdk.java.net Sun May 1 11:39:36 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 1 May 2022 11:39:36 GMT Subject: RFR: 8285832: runtime/Thread/TooSmallStackSize.java failed "assert(k->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation" In-Reply-To: References: Message-ID: <9VNw8bCls_o7bTlez92QLkfT3RhTTpMs-u0fmTmlGo8=.cdfbc3a0-4b50-49a4-81e4-7beae444b240@github.com> On Fri, 29 Apr 2022 17:35:57 GMT, Coleen Phillimore wrote: > The minimum stack size check for ThreadStackSize, CompilerStackSize and VMStackSize should also be done for windows. I moved this to shared code with platform specific constants. > Windows platform was checking the option against the current thread's stack size, and not checking ThreadStackSize, and was setting the stack size against that. It worked until you increase StackShadowPages, and then the calculation is wrong. > For Windows, the minimum thread stack size with current StackShadowPages of 9 in debug is now 92K rather than 188K. > The ShadowPageSize is too low for the loom repository and is on the bounds of current mainline, so will be increased when Loom is integrated. When increased to 11 StackShadowPages, the smallest stack size is 100K. > Tested with tier1-4 on windows-x64-debug. src/hotspot/share/runtime/os.cpp line 2007: > 2005: // page size which again depends on the concrete system the VM is running > 2006: // on. Space for libc guard pages is not included in this size. > 2007: jint os::set_minimum_stack_sizes(size_t os_min_stack_allowed) { Rather than pass in the minimum and spread that knowledge across each OS specific file, can we not just define a field in the os class and have it set appropriately (during os::init()?) - once from os_posix.cpp and once from os_windows.cpp? ------------- PR: https://git.openjdk.java.net/jdk/pull/8471 From rehn at openjdk.java.net Mon May 2 06:04:43 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 2 May 2022 06:04:43 GMT Subject: RFR: 8284632: runtime/Thread/StopAtExit.java possibly leaking memory again [v2] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 16:59:26 GMT, Daniel D. Daugherty wrote: >> Throwing async exceptions at exiting JavaThreads can leak the exception: >> >> 1) HandshakeOperation::do_handshake() recognizes that the target thread >> might be terminated, but needs to do some cleanup when the operation >> is one that installs an async exception. >> >> 2) JavaThread::exit() uses a NoAsyncExceptionDeliveryMark to protect the >> VM's call out to Thread::exit() from async exceptions, but it needs to do >> some cleanup when those async exceptions cannot be delivered because >> the target thread has logically exited. >> >> Also tweaked runtime/Thread/StopAtExit.java to alternate between throwing >> RuntimeException and ThreadDeath. The async exception queuing code accepts >> any exception, but it recognizes ThreadDeath as special. When a target thread >> already has a queued async ThreadDeath exception, then another exception will >> not be queued. So the test now throws RuntimeException on odd iterations and >> ThreadDeath on even iterations and the target thread will have at most two async >> exceptions queued up. >> >> This fix has been tested with Mach5 Tier[1-7] (about to start a Tier8) and I also ran >> my StressWrapper_StopAtExit.java test using {release, fastdebug, and slowdebug} >> bits for 12 hours per config. No leaks detected. Previously, release bits would >> fail with OutOfMemoryException in ~2 minutes with StressWrapper_StopAtExit.java. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > pchilano, robehn, dholmes-ora - CR changes Thanks for finding and fixing! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8388 From duke at openjdk.java.net Mon May 2 10:22:42 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 2 May 2022 10:22:42 GMT Subject: Integrated: JDK-8285712: LogMessageBuffer doesn't check vsnprintf return value In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 10:34:53 GMT, Johan Sj?l?n wrote: > os::vsnprintf can return a negative value on encoding error. A negative return value will cause wraparound when cast to size_t. This in turn causes LogMessageBuffer::grow() to attempt a large memory allocation. Instead of accepting this we bail on the logging. This pull request has now been integrated. Changeset: cf81f6cf Author: Johan Sj?l?n Committer: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/cf81f6cf5bb098575ebce55f19b7c8149203cd71 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod 8285712: LogMessageBuffer doesn't check vsnprintf return value Reviewed-by: dholmes, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/8423 From coleenp at openjdk.java.net Mon May 2 11:43:37 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 2 May 2022 11:43:37 GMT Subject: RFR: 8285832: runtime/Thread/TooSmallStackSize.java failed "assert(k->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation" [v2] In-Reply-To: References: Message-ID: > The minimum stack size check for ThreadStackSize, CompilerStackSize and VMStackSize should also be done for windows. I moved this to shared code with platform specific constants. > Windows platform was checking the option against the current thread's stack size, and not checking ThreadStackSize, and was setting the stack size against that. It worked until you increase StackShadowPages, and then the calculation is wrong. > For Windows, the minimum thread stack size with current StackShadowPages of 9 in debug is now 92K rather than 188K. > The ShadowPageSize is too low for the loom repository and is on the bounds of current mainline, so will be increased when Loom is integrated. When increased to 11 StackShadowPages, the smallest stack size is 100K. > Tested with tier1-4 on windows-x64-debug. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Removed 40 for StackShadowPages as it exceeds windows range. Just check with 30. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8471/files - new: https://git.openjdk.java.net/jdk/pull/8471/files/05cb9aee..db3db351 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8471&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8471&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8471.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8471/head:pull/8471 PR: https://git.openjdk.java.net/jdk/pull/8471 From coleenp at openjdk.java.net Mon May 2 11:43:37 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 2 May 2022 11:43:37 GMT Subject: RFR: 8285832: runtime/Thread/TooSmallStackSize.java failed "assert(k->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation" [v2] In-Reply-To: <9VNw8bCls_o7bTlez92QLkfT3RhTTpMs-u0fmTmlGo8=.cdfbc3a0-4b50-49a4-81e4-7beae444b240@github.com> References: <9VNw8bCls_o7bTlez92QLkfT3RhTTpMs-u0fmTmlGo8=.cdfbc3a0-4b50-49a4-81e4-7beae444b240@github.com> Message-ID: On Sun, 1 May 2022 11:36:51 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed 40 for StackShadowPages as it exceeds windows range. Just check with 30. > > src/hotspot/share/runtime/os.cpp line 2007: > >> 2005: // page size which again depends on the concrete system the VM is running >> 2006: // on. Space for libc guard pages is not included in this size. >> 2007: jint os::set_minimum_stack_sizes(size_t os_min_stack_allowed) { > > Rather than pass in the minimum and spread that knowledge across each OS specific file, can we not just define a field in the os class and have it set appropriately (during os::init()?) - once from os_posix.cpp and once from os_windows.cpp? Could do that, sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/8471 From coleenp at openjdk.java.net Mon May 2 12:17:31 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 2 May 2022 12:17:31 GMT Subject: RFR: 8285832: runtime/Thread/TooSmallStackSize.java failed "assert(k->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation" [v3] In-Reply-To: References: Message-ID: <5fYPkCJj2Pl4DaWSMdTgUDfAaFYzWv4r4CdvEllK3qk=.e5b8ec96-c86d-4d88-83db-a0aff68ed7ca@github.com> > The minimum stack size check for ThreadStackSize, CompilerStackSize and VMStackSize should also be done for windows. I moved this to shared code with platform specific constants. > Windows platform was checking the option against the current thread's stack size, and not checking ThreadStackSize, and was setting the stack size against that. It worked until you increase StackShadowPages, and then the calculation is wrong. > For Windows, the minimum thread stack size with current StackShadowPages of 9 in debug is now 92K rather than 188K. > The ShadowPageSize is too low for the loom repository and is on the bounds of current mainline, so will be increased when Loom is integrated. When increased to 11 StackShadowPages, the smallest stack size is 100K. > Tested with tier1-4 on windows-x64-debug. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add global os_min_stack_allowed. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8471/files - new: https://git.openjdk.java.net/jdk/pull/8471/files/db3db351..23571376 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8471&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8471&range=01-02 Stats: 26 lines in 7 files changed: 11 ins; 6 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8471.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8471/head:pull/8471 PR: https://git.openjdk.java.net/jdk/pull/8471 From sgehwolf at redhat.com Mon May 2 12:41:15 2022 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 May 2022 14:41:15 +0200 Subject: SIGBUS on linux in perfMemory_init (containers) In-Reply-To: References: <48326cc7-b3b9-edfd-c487-e1ee1e5fc1c1@oracle.com> Message-ID: Hi, On Fri, 2022-04-29 at 14:19 -0700, Ioi Lam wrote: > > > On 4/29/2022 1:55 PM, Ioi Lam wrote: > > > > > > On 4/29/2022 6:44 AM, Vitaly Davidovich wrote: > > > Hi all, > > > > > > We've been seeing intermittent SIGBUS failures on linux with jdk11.? > > > They > > > all have this distinctive backtrace: > > > > > > C? [libc.so.6+0x12944d] > > > > > > V? [libjvm.so+0xcca542]? perfMemory_init()+0x72 > > > > > > V? [libjvm.so+0x8a3242]? vm_init_globals()+0x22 > > > > > > V? [libjvm.so+0xedc31d]? Threads::create_vm(JavaVMInitArgs*, > > > bool*)+0x1ed > > > > > > V? [libjvm.so+0x9615b2]? JNI_CreateJavaVM+0x52 > > > > > > C? [libjli.so+0x49af]? JavaMain+0x8f > > > > > > C? [libjli.so+0x9149]? ThreadJavaMain+0x9 > > > > > > > > > Initially, we suspected that /tmp was full but that turned out to not be > > > the case.? After a few more instances of the crash and investigation, we > > > believe we know the root cause. > > > > > > > > > The crashing applications are all running in a K8 pod, with each JVM > > > in a > > > separate container: > > > > > > > > > container_type: cgroupv1 (from the hs_err file) > > > > > > > > > /tmp is mounted such that it's shared by multiple containers. Since > > > these > > > JVMs are running in containers, we believe what happens is the > > > namespaced > > > (i.e. per container) PIDs overlap between different containers - 2 > > > JVMs, in > > > separate containers, can end up with the same namespaced PID. Since /tmp > > > is shared, they can now "contend" on the same perfMemory file since > > > those > > > file names are PID based. > > > > Hi Vitaly, > > > > Is there any reason for sharing the same /tmp directory across > > different containers? > > > > Are you using the /tmp/hsperfdata_$USER/ files at all. If not, > > for the time being, you can disable them with the -XX:-UsePerfData flag, > > > > https://bugs.openjdk.java.net/browse/JDK-8255008?has a related proposal: > > This bug is private. Could this one be made accessible somehow? Another related bug seems to be, though not quite the same: https://bugs.openjdk.java.net/browse/JDK-8284330 > > Java: -Djdk.attach.tmpdir=/container-attachdir > > -XX:+UnlockCommercialFeature -XX:+FlightRecorder -XX:+StartAttachListener > > Docker: --volume /tmp/container-attachdir:/container-attachdir > > > > In this case, we probably will run into the same UID clash problem as > > well. > > > > Maybe we should have an additional property like > > -Djdk.attach.use.global.pid=true > > > > I read the proposal in JDK-8255008 again and realized that the JVM > inside the container doesn't know what it's host PID is. The proposal is > to create these files: > > $jdk_attach_dir/hsperfdata_{user}/e4f3e2e4fd97:10 > $jdk_attach_dir/.java_pid:e4f3e2e4fd97:10 > > where the e4f3e2e4fd97 is the container ID which is visible as > /tmp/hostname from inside the container. > > I'll try to implement a prototype for the proposal. Please be aware that the container's hostname is also user-settable. E.g. $ docker run --hostname foo ... Would set the hostname to 'foo'. Ioi, did you end up creating a bug for this? Thanks, Severin > Thanks > - Ioi > > > > > > > > > Once multiple JVMs can contend on the same file, a SIGBUS can > > > arise > > > if one > > > JVM has mmap'd the file and another ftruncate()'s it from under > > > it (e.g. > > > https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/hotspot/os/linux/perfMemory_linux.cpp#L909 > > > ? > > > > > > ). > > > > > > > > > Is this a known issue? I couldn't find any existing JBS entries > > > or > > > mailing > > > list discussions around this specific circumstance. > > > > > > > > > As for possible solutions, would it be possible to use the global > > > PID > > > instead of the namespaced PID to "regain" the uniqueness > > > invariant of > > > the > > > PID? > > > > I think this needs to be optional. E.g., if you run a tool such as > > "jcmd" inside the same container as the jvm process, the jcmd tool > > would expect the PID to be the local version specific to this > > container. > > > > > ? Also, might it make sense to flock() the file to prevent > > > another > > > process from mucking with it? > > > > > That will not solve the fundamental problem where two processes are > > using the same hsperfdata file. One of them would fail to write to > > it, > > and tools won't be able to monitor both processes. > > > > Thanks > > - Ioi > > > > > Happy to provide more info if needed. > > > > > > > > > Thanks > > > From erikj at openjdk.java.net Mon May 2 12:59:34 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 2 May 2022 12:59:34 GMT Subject: RFR: 8282828: CDS uncompressed oops archive is not deterministic In-Reply-To: References: Message-ID: <4f0ydw14l2tRG_WpIjm0c4DXkgRKx0vCXBY7Bmzd6QU=.d6c49889-3754-41ed-ad0f-dc3ef201a6af@github.com> On Fri, 29 Apr 2022 22:50:45 GMT, Ioi Lam wrote: > During `java -Xshare:dump -XX:-UseCompressedOops`, the location of the Java heap is chosen by the OS. Due to Address Space Layout Randomization, the heap will always start at a different location. This causes the archive for uncompressed oops ($JAVA_HOME/lib/server/classes_nocoops.jsa) to be non-deterministic. > > The fix is to patch the archived object pointers to make it look like the heap starts at a fixed address -- I chose 0x10000000, but the exact value doesn't really matter. > > At runtime, the object pointers will be patched again according to the real location of the heap. > > Tested with tiers 1-5. I am running builds-tier5 several times to test the xxx-cmp-baseline builds. Change to compare.sh looks good. Thanks for fixing this! ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8478 From ihse at openjdk.java.net Mon May 2 14:03:51 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 2 May 2022 14:03:51 GMT Subject: RFR: 8282828: CDS uncompressed oops archive is not deterministic In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 22:50:45 GMT, Ioi Lam wrote: > During `java -Xshare:dump -XX:-UseCompressedOops`, the location of the Java heap is chosen by the OS. Due to Address Space Layout Randomization, the heap will always start at a different location. This causes the archive for uncompressed oops ($JAVA_HOME/lib/server/classes_nocoops.jsa) to be non-deterministic. > > The fix is to patch the archived object pointers to make it look like the heap starts at a fixed address -- I chose 0x10000000, but the exact value doesn't really matter. > > At runtime, the object pointers will be patched again according to the real location of the heap. > > Tested with tiers 1-5. I am running builds-tier5 several times to test the xxx-cmp-baseline builds. Marked as reviewed by ihse (Reviewer). Looks good to me. But you need hotspot reviewers as well. And thanks for fixing this! I think this is the last major known non-reproducibility bug in the JDK! ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/8478 From pchilanomate at openjdk.java.net Mon May 2 14:59:43 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 2 May 2022 14:59:43 GMT Subject: RFR: 8284632: runtime/Thread/StopAtExit.java possibly leaking memory again [v2] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 16:59:26 GMT, Daniel D. Daugherty wrote: >> Throwing async exceptions at exiting JavaThreads can leak the exception: >> >> 1) HandshakeOperation::do_handshake() recognizes that the target thread >> might be terminated, but needs to do some cleanup when the operation >> is one that installs an async exception. >> >> 2) JavaThread::exit() uses a NoAsyncExceptionDeliveryMark to protect the >> VM's call out to Thread::exit() from async exceptions, but it needs to do >> some cleanup when those async exceptions cannot be delivered because >> the target thread has logically exited. >> >> Also tweaked runtime/Thread/StopAtExit.java to alternate between throwing >> RuntimeException and ThreadDeath. The async exception queuing code accepts >> any exception, but it recognizes ThreadDeath as special. When a target thread >> already has a queued async ThreadDeath exception, then another exception will >> not be queued. So the test now throws RuntimeException on odd iterations and >> ThreadDeath on even iterations and the target thread will have at most two async >> exceptions queued up. >> >> This fix has been tested with Mach5 Tier[1-7] (about to start a Tier8) and I also ran >> my StressWrapper_StopAtExit.java test using {release, fastdebug, and slowdebug} >> bits for 12 hours per config. No leaks detected. Previously, release bits would >> fail with OutOfMemoryException in ~2 minutes with StressWrapper_StopAtExit.java. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > pchilano, robehn, dholmes-ora - CR changes Looks good to me! Thanks, Patricio ------------- Marked as reviewed by pchilanomate (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8388 From dcubed at openjdk.java.net Mon May 2 15:17:45 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 2 May 2022 15:17:45 GMT Subject: RFR: 8284632: runtime/Thread/StopAtExit.java possibly leaking memory again In-Reply-To: References: Message-ID: <-plYgOajAFTs8mSAiygrKS4osRxXt-emKRd4m1hLL_w=.040de0ff-0013-4c97-add2-6f6978e8ca21@github.com> On Thu, 28 Apr 2022 07:51:15 GMT, Robbin Ehn wrote: >> Throwing async exceptions at exiting JavaThreads can leak the exception: >> >> 1) HandshakeOperation::do_handshake() recognizes that the target thread >> might be terminated, but needs to do some cleanup when the operation >> is one that installs an async exception. >> >> 2) JavaThread::exit() uses a NoAsyncExceptionDeliveryMark to protect the >> VM's call out to Thread::exit() from async exceptions, but it needs to do >> some cleanup when those async exceptions cannot be delivered because >> the target thread has logically exited. >> >> Also tweaked runtime/Thread/StopAtExit.java to alternate between throwing >> RuntimeException and ThreadDeath. The async exception queuing code accepts >> any exception, but it recognizes ThreadDeath as special. When a target thread >> already has a queued async ThreadDeath exception, then another exception will >> not be queued. So the test now throws RuntimeException on odd iterations and >> ThreadDeath on even iterations and the target thread will have at most two async >> exceptions queued up. >> >> This fix has been tested with Mach5 Tier[1-7] (about to start a Tier8) and I also ran >> my StressWrapper_StopAtExit.java test using {release, fastdebug, and slowdebug} >> bits for 12 hours per config. No leaks detected. Previously, release bits would >> fail with OutOfMemoryException in ~2 minutes with StressWrapper_StopAtExit.java. > > Yes, good find! > > When combining the code @dcubed-ojdk, @pchilano comments and my comments in my head I was unsure if the result was doable :) So I had to write the code to make sure I was not complete wrong. > > Here is a change, diff against master: > https://github.com/openjdk/jdk/compare/master...robehn:8284161?expand=1 > Diff against this PR: > https://github.com/dcubed-ojdk/jdk/compare/JDK-8284632...robehn:8284161?expand=1 > Commit: > https://github.com/robehn/jdk/commit/0224ede15980006ce547de72ee0a778b10054b45 > > Thanks @robehn and @pchilano - Thanks for the re-reviews! @dholmes-ora - Did you want me to wait for your re-review? ------------- PR: https://git.openjdk.java.net/jdk/pull/8388 From pchilanomate at openjdk.java.net Mon May 2 15:21:43 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 2 May 2022 15:21:43 GMT Subject: RFR: 8285507: revert fix for JDK-8282704 now that JDK-8282952 is fixed [v2] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 20:27:11 GMT, Daniel D. Daugherty wrote: >> Revert (most of) the fix for JDK-8282704 now that JDK-8282952 is fixed. >> >> This fix has been tested with Mach5 Tier[1-7] (about to start a Tier8) and I also ran >> my StressWrapper_StopAtExit.java test using {release, fastdebug, and slowdebug} >> bits for 12 hours per config. No failures for StressWrapper_StopAtExit.java. > > Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'JDK-8284632' into JDK-8285507 > - 8285507.cr0 Looks good! Thanks, Patricio ------------- Marked as reviewed by pchilanomate (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8389 From dcubed at openjdk.java.net Mon May 2 15:21:43 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 2 May 2022 15:21:43 GMT Subject: RFR: 8285507: revert fix for JDK-8282704 now that JDK-8282952 is fixed [v2] In-Reply-To: References: Message-ID: <2JEneppJbsGlGYkmoLbI7Idt_vP4FHZFqC9RIqrKgZc=.52694555-ceb0-4a55-a6e8-7bb8f05dc2b2@github.com> On Fri, 29 Apr 2022 20:27:11 GMT, Daniel D. Daugherty wrote: >> Revert (most of) the fix for JDK-8282704 now that JDK-8282952 is fixed. >> >> This fix has been tested with Mach5 Tier[1-7] (about to start a Tier8) and I also ran >> my StressWrapper_StopAtExit.java test using {release, fastdebug, and slowdebug} >> bits for 12 hours per config. No failures for StressWrapper_StopAtExit.java. > > Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'JDK-8284632' into JDK-8285507 > - 8285507.cr0 @pchilano - Please review this fix when you get the chance... Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8389 From dcubed at openjdk.java.net Mon May 2 15:26:47 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 2 May 2022 15:26:47 GMT Subject: Integrated: 8284632: runtime/Thread/StopAtExit.java possibly leaking memory again In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 22:12:38 GMT, Daniel D. Daugherty wrote: > Throwing async exceptions at exiting JavaThreads can leak the exception: > > 1) HandshakeOperation::do_handshake() recognizes that the target thread > might be terminated, but needs to do some cleanup when the operation > is one that installs an async exception. > > 2) JavaThread::exit() uses a NoAsyncExceptionDeliveryMark to protect the > VM's call out to Thread::exit() from async exceptions, but it needs to do > some cleanup when those async exceptions cannot be delivered because > the target thread has logically exited. > > Also tweaked runtime/Thread/StopAtExit.java to alternate between throwing > RuntimeException and ThreadDeath. The async exception queuing code accepts > any exception, but it recognizes ThreadDeath as special. When a target thread > already has a queued async ThreadDeath exception, then another exception will > not be queued. So the test now throws RuntimeException on odd iterations and > ThreadDeath on even iterations and the target thread will have at most two async > exceptions queued up. > > This fix has been tested with Mach5 Tier[1-7] (about to start a Tier8) and I also ran > my StressWrapper_StopAtExit.java test using {release, fastdebug, and slowdebug} > bits for 12 hours per config. No leaks detected. Previously, release bits would > fail with OutOfMemoryException in ~2 minutes with StressWrapper_StopAtExit.java. This pull request has now been integrated. Changeset: 4a79270c Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/4a79270c0195e79cfc59f774c1ac58c56321ea8a Stats: 67 lines in 4 files changed: 45 ins; 18 del; 4 mod 8284632: runtime/Thread/StopAtExit.java possibly leaking memory again Reviewed-by: pchilanomate, rehn ------------- PR: https://git.openjdk.java.net/jdk/pull/8388 From dcubed at openjdk.java.net Mon May 2 15:28:41 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 2 May 2022 15:28:41 GMT Subject: RFR: 8285507: revert fix for JDK-8282704 now that JDK-8282952 is fixed [v2] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 15:18:37 GMT, Patricio Chilano Mateo wrote: >> Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: >> >> - Merge branch 'JDK-8284632' into JDK-8285507 >> - 8285507.cr0 > > Looks good! > > Thanks, > Patricio @pchilano - Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8389 From duke at openjdk.java.net Mon May 2 15:28:42 2022 From: duke at openjdk.java.net (openjdk-notifier[bot]) Date: Mon, 2 May 2022 15:28:42 GMT Subject: RFR: 8285507: revert fix for JDK-8282704 now that JDK-8282952 is fixed [v2] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 20:27:11 GMT, Daniel D. Daugherty wrote: >> Revert (most of) the fix for JDK-8282704 now that JDK-8282952 is fixed. >> >> This fix has been tested with Mach5 Tier[1-7] (about to start a Tier8) and I also ran >> my StressWrapper_StopAtExit.java test using {release, fastdebug, and slowdebug} >> bits for 12 hours per config. No failures for StressWrapper_StopAtExit.java. > > Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'JDK-8284632' into JDK-8285507 > - 8285507.cr0 The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout JDK-8284632 git fetch https://git.openjdk.java.net/jdk master git merge FETCH_HEAD # if there are conflicts, follow the instructions given by git merge git commit -m "Merge master" git push ------------- PR: https://git.openjdk.java.net/jdk/pull/8389 From dcubed at openjdk.java.net Mon May 2 15:43:19 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 2 May 2022 15:43:19 GMT Subject: RFR: 8285507: revert fix for JDK-8282704 now that JDK-8282952 is fixed [v3] In-Reply-To: References: Message-ID: > Revert (most of) the fix for JDK-8282704 now that JDK-8282952 is fixed. > > This fix has been tested with Mach5 Tier[1-7] (about to start a Tier8) and I also ran > my StressWrapper_StopAtExit.java test using {release, fastdebug, and slowdebug} > bits for 12 hours per config. No failures for StressWrapper_StopAtExit.java. Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge master - Merge branch 'JDK-8284632' into JDK-8285507 - pchilano, robehn, dholmes-ora - CR changes - 8285507.cr0 - 8284632.cr0 ------------- Changes: https://git.openjdk.java.net/jdk/pull/8389/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8389&range=02 Stats: 62 lines in 1 file changed: 0 ins; 60 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8389.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8389/head:pull/8389 PR: https://git.openjdk.java.net/jdk/pull/8389 From dcubed at openjdk.java.net Mon May 2 15:43:20 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 2 May 2022 15:43:20 GMT Subject: Integrated: 8285507: revert fix for JDK-8282704 now that JDK-8282952 is fixed In-Reply-To: References: Message-ID: <6Fora-dlvcYSj-ZE0aNz3wYtR65SVgAddWm4Ck0LVg4=.0355b03e-bdcb-4dd3-a786-c331fb90bb85@github.com> On Mon, 25 Apr 2022 22:17:00 GMT, Daniel D. Daugherty wrote: > Revert (most of) the fix for JDK-8282704 now that JDK-8282952 is fixed. > > This fix has been tested with Mach5 Tier[1-7] (about to start a Tier8) and I also ran > my StressWrapper_StopAtExit.java test using {release, fastdebug, and slowdebug} > bits for 12 hours per config. No failures for StressWrapper_StopAtExit.java. This pull request has now been integrated. Changeset: 41de506e Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/41de506ed6c9dc0331c2b6ae99c11623df05f34a Stats: 62 lines in 1 file changed: 0 ins; 60 del; 2 mod 8285507: revert fix for JDK-8282704 now that JDK-8282952 is fixed Reviewed-by: dholmes, pchilanomate ------------- PR: https://git.openjdk.java.net/jdk/pull/8389 From ccheung at openjdk.java.net Mon May 2 21:05:29 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 2 May 2022 21:05:29 GMT Subject: RFR: 8282828: CDS uncompressed oops archive is not deterministic In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 22:50:45 GMT, Ioi Lam wrote: > During `java -Xshare:dump -XX:-UseCompressedOops`, the location of the Java heap is chosen by the OS. Due to Address Space Layout Randomization, the heap will always start at a different location. This causes the archive for uncompressed oops ($JAVA_HOME/lib/server/classes_nocoops.jsa) to be non-deterministic. > > The fix is to patch the archived object pointers to make it look like the heap starts at a fixed address -- I chose 0x10000000, but the exact value doesn't really matter. > > At runtime, the object pointers will be patched again according to the real location of the heap. > > Tested with tiers 1-5. I am running builds-tier5 several times to test the xxx-cmp-baseline builds. LGTM ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8478 From dholmes at openjdk.java.net Mon May 2 21:31:28 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 2 May 2022 21:31:28 GMT Subject: RFR: 8284632: runtime/Thread/StopAtExit.java possibly leaking memory again In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 07:51:15 GMT, Robbin Ehn wrote: >> Throwing async exceptions at exiting JavaThreads can leak the exception: >> >> 1) HandshakeOperation::do_handshake() recognizes that the target thread >> might be terminated, but needs to do some cleanup when the operation >> is one that installs an async exception. >> >> 2) JavaThread::exit() uses a NoAsyncExceptionDeliveryMark to protect the >> VM's call out to Thread::exit() from async exceptions, but it needs to do >> some cleanup when those async exceptions cannot be delivered because >> the target thread has logically exited. >> >> Also tweaked runtime/Thread/StopAtExit.java to alternate between throwing >> RuntimeException and ThreadDeath. The async exception queuing code accepts >> any exception, but it recognizes ThreadDeath as special. When a target thread >> already has a queued async ThreadDeath exception, then another exception will >> not be queued. So the test now throws RuntimeException on odd iterations and >> ThreadDeath on even iterations and the target thread will have at most two async >> exceptions queued up. >> >> This fix has been tested with Mach5 Tier[1-7] (about to start a Tier8) and I also ran >> my StressWrapper_StopAtExit.java test using {release, fastdebug, and slowdebug} >> bits for 12 hours per config. No leaks detected. Previously, release bits would >> fail with OutOfMemoryException in ~2 minutes with StressWrapper_StopAtExit.java. > > Yes, good find! > > When combining the code @dcubed-ojdk, @pchilano comments and my comments in my head I was unsure if the result was doable :) So I had to write the code to make sure I was not complete wrong. > > Here is a change, diff against master: > https://github.com/openjdk/jdk/compare/master...robehn:8284161?expand=1 > Diff against this PR: > https://github.com/dcubed-ojdk/jdk/compare/JDK-8284632...robehn:8284161?expand=1 > Commit: > https://github.com/robehn/jdk/commit/0224ede15980006ce547de72ee0a778b10054b45 > > Thanks Looks really good to me! Thanks for the fix @robehn ! And kudos to @dcubed-ojdk and his stress testing for finding this. ------------- PR: https://git.openjdk.java.net/jdk/pull/8388 From dholmes at openjdk.java.net Mon May 2 21:31:31 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 2 May 2022 21:31:31 GMT Subject: RFR: 8284632: runtime/Thread/StopAtExit.java possibly leaking memory again [v2] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 16:59:26 GMT, Daniel D. Daugherty wrote: >> Throwing async exceptions at exiting JavaThreads can leak the exception: >> >> 1) HandshakeOperation::do_handshake() recognizes that the target thread >> might be terminated, but needs to do some cleanup when the operation >> is one that installs an async exception. >> >> 2) JavaThread::exit() uses a NoAsyncExceptionDeliveryMark to protect the >> VM's call out to Thread::exit() from async exceptions, but it needs to do >> some cleanup when those async exceptions cannot be delivered because >> the target thread has logically exited. >> >> Also tweaked runtime/Thread/StopAtExit.java to alternate between throwing >> RuntimeException and ThreadDeath. The async exception queuing code accepts >> any exception, but it recognizes ThreadDeath as special. When a target thread >> already has a queued async ThreadDeath exception, then another exception will >> not be queued. So the test now throws RuntimeException on odd iterations and >> ThreadDeath on even iterations and the target thread will have at most two async >> exceptions queued up. >> >> This fix has been tested with Mach5 Tier[1-7] (about to start a Tier8) and I also ran >> my StressWrapper_StopAtExit.java test using {release, fastdebug, and slowdebug} >> bits for 12 hours per config. No leaks detected. Previously, release bits would >> fail with OutOfMemoryException in ~2 minutes with StressWrapper_StopAtExit.java. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > pchilano, robehn, dholmes-ora - CR changes src/hotspot/share/runtime/thread.cpp line 1674: > 1672: HandshakeClosure("InstallAsyncException"), _aeh(aeh) {} > 1673: ~InstallAsyncExceptionHandshake() { > 1674: delete _aeh; A comment would have been good. I'm assuming: // Can only be non-null if this handshake was never actually executed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8388 From dcubed at openjdk.java.net Mon May 2 21:47:22 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 2 May 2022 21:47:22 GMT Subject: RFR: 8284632: runtime/Thread/StopAtExit.java possibly leaking memory again [v2] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 21:24:49 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> pchilano, robehn, dholmes-ora - CR changes > > src/hotspot/share/runtime/thread.cpp line 1674: > >> 1672: HandshakeClosure("InstallAsyncException"), _aeh(aeh) {} >> 1673: ~InstallAsyncExceptionHandshake() { >> 1674: delete _aeh; > > A comment would have been good. I'm assuming: > > // Can only be non-null if this handshake was never actually executed. Since we clear `_aeh` on L1679 below when `do_thread()` is executed, `_aeh` can only be non-NULL when `~InstallAsyncExceptionHandshake()` runs if `do_thread()` was never executed. I can add that comment above L1674 in a separate bug fix if you wish. @robehn - do you concur that a comment here would be good? ------------- PR: https://git.openjdk.java.net/jdk/pull/8388 From dholmes at openjdk.java.net Tue May 3 00:36:23 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 3 May 2022 00:36:23 GMT Subject: RFR: 8284632: runtime/Thread/StopAtExit.java possibly leaking memory again [v2] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 21:43:50 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/thread.cpp line 1674: >> >>> 1672: HandshakeClosure("InstallAsyncException"), _aeh(aeh) {} >>> 1673: ~InstallAsyncExceptionHandshake() { >>> 1674: delete _aeh; >> >> A comment would have been good. I'm assuming: >> >> // Can only be non-null if this handshake was never actually executed. > > Since we clear `_aeh` on L1679 below when `do_thread()` is executed, `_aeh` can > only be non-NULL when `~InstallAsyncExceptionHandshake()` runs if `do_thread()` > was never executed. > > I can add that comment above L1674 in a separate bug fix if you wish. > @robehn - do you concur that a comment here would be good? It was the fact we null it and delete it that initially caused a "What the???" reaction. :) So I think I comment would be good but can wait. ------------- PR: https://git.openjdk.java.net/jdk/pull/8388 From iklam at openjdk.java.net Tue May 3 00:46:04 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 3 May 2022 00:46:04 GMT Subject: RFR: 8282828: CDS uncompressed oops archive is not deterministic [v2] In-Reply-To: References: Message-ID: > During `java -Xshare:dump -XX:-UseCompressedOops`, the location of the Java heap is chosen by the OS. Due to Address Space Layout Randomization, the heap will always start at a different location. This causes the archive for uncompressed oops ($JAVA_HOME/lib/server/classes_nocoops.jsa) to be non-deterministic. > > The fix is to patch the archived object pointers to make it look like the heap starts at a fixed address -- I chose 0x10000000, but the exact value doesn't really matter. > > At runtime, the object pointers will be patched again according to the real location of the heap. > > Tested with tiers 1-5. I am running builds-tier5 several times to test the xxx-cmp-baseline builds. Ioi Lam 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' of https://github.com/openjdk/jdk into 8282828-uncompressed-oop-cds-archive-not-determinisic - 8282828: CDS uncompressed oops archive is not deterministic ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8478/files - new: https://git.openjdk.java.net/jdk/pull/8478/files/f0261c51..8ddea12f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8478&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8478&range=00-01 Stats: 15990 lines in 519 files changed: 10708 ins; 2732 del; 2550 mod Patch: https://git.openjdk.java.net/jdk/pull/8478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8478/head:pull/8478 PR: https://git.openjdk.java.net/jdk/pull/8478 From dholmes at openjdk.java.net Tue May 3 01:13:13 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 3 May 2022 01:13:13 GMT Subject: RFR: 8285832: runtime/Thread/TooSmallStackSize.java failed "assert(k->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation" [v3] In-Reply-To: <5fYPkCJj2Pl4DaWSMdTgUDfAaFYzWv4r4CdvEllK3qk=.e5b8ec96-c86d-4d88-83db-a0aff68ed7ca@github.com> References: <5fYPkCJj2Pl4DaWSMdTgUDfAaFYzWv4r4CdvEllK3qk=.e5b8ec96-c86d-4d88-83db-a0aff68ed7ca@github.com> Message-ID: On Mon, 2 May 2022 12:17:31 GMT, Coleen Phillimore wrote: >> The minimum stack size check for ThreadStackSize, CompilerStackSize and VMStackSize should also be done for windows. I moved this to shared code with platform specific constants. >> Windows platform was checking the option against the current thread's stack size, and not checking ThreadStackSize, and was setting the stack size against that. It worked until you increase StackShadowPages, and then the calculation is wrong. >> For Windows, the minimum thread stack size with current StackShadowPages of 9 in debug is now 92K rather than 188K. >> The ShadowPageSize is too low for the loom repository and is on the bounds of current mainline, so will be increased when Loom is integrated. When increased to 11 StackShadowPages, the smallest stack size is 100K. >> Tested with tier1-4 on windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add global os_min_stack_allowed. Hi Coleen, Overall this looks good. One typo on Windows that must be fixed, and a suggestion for the test. The comments (previously from os_posix.cpp) refer to libc in a couple of places, but that is probably okay even if not relevant for Windows. Thanks, David src/hotspot/os/windows/os_windows.cpp line 4288: > 4286: > 4287: // Check and sets minimum stack sizes against command line options > 4288: if (set_minimum_stack_sizes(_plaform_minimum_stack_allowed) == JNI_ERR) { typo: should be `_os_min_stack_allowed` test/hotspot/jtreg/runtime/Thread/TooSmallStackSize.java line 96: > 94: > 95: static ProcessBuilder createProcessWithOptions(String stackOption, String stackSize) throws Exception { > 96: if (testShadowSize == null) { There would be far less duplication if you just used: `testShadowSize == null ? "" : ("-XX:StackShadowPages=" + testShadowSize)` ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8471 From iklam at openjdk.java.net Tue May 3 04:09:22 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 3 May 2022 04:09:22 GMT Subject: RFR: 8282828: CDS uncompressed oops archive is not deterministic [v2] In-Reply-To: <4f0ydw14l2tRG_WpIjm0c4DXkgRKx0vCXBY7Bmzd6QU=.d6c49889-3754-41ed-ad0f-dc3ef201a6af@github.com> References: <4f0ydw14l2tRG_WpIjm0c4DXkgRKx0vCXBY7Bmzd6QU=.d6c49889-3754-41ed-ad0f-dc3ef201a6af@github.com> Message-ID: <542amXyYwrXbb1TtpJL7sF_VfCmOYGdnyb_LFVrvqxM=.1eca9740-0401-4155-82ee-76fd9f8e53b9@github.com> On Mon, 2 May 2022 12:56:36 GMT, Erik Joelsson wrote: >> Ioi Lam 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' of https://github.com/openjdk/jdk into 8282828-uncompressed-oop-cds-archive-not-determinisic >> - 8282828: CDS uncompressed oops archive is not deterministic > > Change to compare.sh looks good. Thanks for fixing this! Thanks @erikj79 @magicus @calvinccheung for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8478 From iklam at openjdk.java.net Tue May 3 04:09:23 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 3 May 2022 04:09:23 GMT Subject: Integrated: 8282828: CDS uncompressed oops archive is not deterministic In-Reply-To: References: Message-ID: <0Spq30mjW42FwZPLfIst0doH_37DxrjuiRAMqIBncgM=.ab9496dd-6e84-4990-9cc6-61b911f46352@github.com> On Fri, 29 Apr 2022 22:50:45 GMT, Ioi Lam wrote: > During `java -Xshare:dump -XX:-UseCompressedOops`, the location of the Java heap is chosen by the OS. Due to Address Space Layout Randomization, the heap will always start at a different location. This causes the archive for uncompressed oops ($JAVA_HOME/lib/server/classes_nocoops.jsa) to be non-deterministic. > > The fix is to patch the archived object pointers to make it look like the heap starts at a fixed address -- I chose 0x10000000, but the exact value doesn't really matter. > > At runtime, the object pointers will be patched again according to the real location of the heap. > > Tested with tiers 1-5. I am running builds-tier5 several times to test the xxx-cmp-baseline builds. This pull request has now been integrated. Changeset: 64b5b2b0 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/64b5b2b0b3e5156d9b0c5f378ce3a1ae52aa0819 Stats: 86 lines in 6 files changed: 62 ins; 2 del; 22 mod 8282828: CDS uncompressed oops archive is not deterministic Reviewed-by: erikj, ihse, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/8478 From ioi.lam at oracle.com Tue May 3 05:13:54 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 2 May 2022 22:13:54 -0700 Subject: SIGBUS on linux in perfMemory_init (containers) In-Reply-To: References: <48326cc7-b3b9-edfd-c487-e1ee1e5fc1c1@oracle.com> Message-ID: <0fc672f9-c122-240d-2552-279abfbea974@oracle.com> On 5/2/2022 5:41 AM, Severin Gehwolf wrote: > Hi, > > On Fri, 2022-04-29 at 14:19 -0700, Ioi Lam wrote: >> >> On 4/29/2022 1:55 PM, Ioi Lam wrote: >>> >>> On 4/29/2022 6:44 AM, Vitaly Davidovich wrote: >>>> Hi all, >>>> >>>> We've been seeing intermittent SIGBUS failures on linux with jdk11. >>>> They >>>> all have this distinctive backtrace: >>>> >>>> C? [libc.so.6+0x12944d] >>>> >>>> V? [libjvm.so+0xcca542]? perfMemory_init()+0x72 >>>> >>>> V? [libjvm.so+0x8a3242]? vm_init_globals()+0x22 >>>> >>>> V? [libjvm.so+0xedc31d]? Threads::create_vm(JavaVMInitArgs*, >>>> bool*)+0x1ed >>>> >>>> V? [libjvm.so+0x9615b2]? JNI_CreateJavaVM+0x52 >>>> >>>> C? [libjli.so+0x49af]? JavaMain+0x8f >>>> >>>> C? [libjli.so+0x9149]? ThreadJavaMain+0x9 >>>> >>>> >>>> Initially, we suspected that /tmp was full but that turned out to not be >>>> the case.? After a few more instances of the crash and investigation, we >>>> believe we know the root cause. >>>> >>>> >>>> The crashing applications are all running in a K8 pod, with each JVM >>>> in a >>>> separate container: >>>> >>>> >>>> container_type: cgroupv1 (from the hs_err file) >>>> >>>> >>>> /tmp is mounted such that it's shared by multiple containers. Since >>>> these >>>> JVMs are running in containers, we believe what happens is the >>>> namespaced >>>> (i.e. per container) PIDs overlap between different containers - 2 >>>> JVMs, in >>>> separate containers, can end up with the same namespaced PID. Since /tmp >>>> is shared, they can now "contend" on the same perfMemory file since >>>> those >>>> file names are PID based. >>> Hi Vitaly, >>> >>> Is there any reason for sharing the same /tmp directory across >>> different containers? >>> >>> Are you using the /tmp/hsperfdata_$USER/ files at all. If not, >>> for the time being, you can disable them with the -XX:-UsePerfData flag, >>> >>> https://bugs.openjdk.java.net/browse/JDK-8255008?has a related proposal: >>> > This bug is private. Could this one be made accessible somehow? I've made the bug public. > Another related bug seems to be, though not quite the same: > https://bugs.openjdk.java.net/browse/JDK-8284330 Vitaly's scenario will still crash with the above fix. >>> Java: -Djdk.attach.tmpdir=/container-attachdir >>> -XX:+UnlockCommercialFeature -XX:+FlightRecorder -XX:+StartAttachListener >>> Docker: --volume /tmp/container-attachdir:/container-attachdir >>> >>> In this case, we probably will run into the same UID clash problem as >>> well. >>> >>> Maybe we should have an additional property like >>> -Djdk.attach.use.global.pid=true >>> >> I read the proposal in JDK-8255008 again and realized that the JVM >> inside the container doesn't know what it's host PID is. The proposal is >> to create these files: >> >> $jdk_attach_dir/hsperfdata_{user}/e4f3e2e4fd97:10 >> $jdk_attach_dir/.java_pid:e4f3e2e4fd97:10 >> >> where the e4f3e2e4fd97 is the container ID which is visible as >> /tmp/hostname from inside the container. >> >> I'll try to implement a prototype for the proposal. > Please be aware that the container's hostname is also user-settable. > E.g. > > $ docker run --hostname foo ... > > Would set the hostname to 'foo'. Maybe that's OK, as the user will probably set them to unique names. Or we can use some sort of UUID. Is there anything that cgroup provides for a containerized process to uniquely identify itself? And, do we need to handle nested containers? Is this a practical use case? > Ioi, did you end up creating a bug for this? I created a JBS issue from Vitaly's original report: https://bugs.openjdk.java.net/browse/JDK-8286030 Thanks - Ioi > > Thanks, > Severin > >> Thanks >> - Ioi >> >>>> Once multiple JVMs can contend on the same file, a SIGBUS can >>>> arise >>>> if one >>>> JVM has mmap'd the file and another ftruncate()'s it from under >>>> it (e.g. >>>> https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/hotspot/os/linux/perfMemory_linux.cpp#L909 >>>> >>>> >>>> ). >>>> >>>> >>>> Is this a known issue? I couldn't find any existing JBS entries >>>> or >>>> mailing >>>> list discussions around this specific circumstance. >>>> >>>> >>>> As for possible solutions, would it be possible to use the global >>>> PID >>>> instead of the namespaced PID to "regain" the uniqueness >>>> invariant of >>>> the >>>> PID? >>> I think this needs to be optional. E.g., if you run a tool such as >>> "jcmd" inside the same container as the jvm process, the jcmd tool >>> would expect the PID to be the local version specific to this >>> container. >>> >>>> ? Also, might it make sense to flock() the file to prevent >>>> another >>>> process from mucking with it? >>>> >>> That will not solve the fundamental problem where two processes are >>> using the same hsperfdata file. One of them would fail to write to >>> it, >>> and tools won't be able to monitor both processes. >>> >>> Thanks >>> - Ioi >>> >>>> Happy to provide more info if needed. >>>> >>>> >>>> Thanks From mbaesken at openjdk.java.net Tue May 3 07:04:56 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 3 May 2022 07:04:56 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v2] In-Reply-To: References: Message-ID: > Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : > https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt > Macros for Conditional Declarations > "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." > > However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: set _WIN32_WINNT=0x0601 centrally in flags-cflags.m4 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8428/files - new: https://git.openjdk.java.net/jdk/pull/8428/files/aef2486f..dff223c5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=00-01 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8428.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8428/head:pull/8428 PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Tue May 3 07:10:58 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 3 May 2022 07:10:58 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: > Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : > https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt > Macros for Conditional Declarations > "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." > > However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust Copyright year in wepoll.c ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8428/files - new: https://git.openjdk.java.net/jdk/pull/8428/files/dff223c5..23b63c5b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8428.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8428/head:pull/8428 PR: https://git.openjdk.java.net/jdk/pull/8428 From rehn at openjdk.java.net Tue May 3 07:48:22 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 3 May 2022 07:48:22 GMT Subject: RFR: 8284632: runtime/Thread/StopAtExit.java possibly leaking memory again [v2] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 00:32:42 GMT, David Holmes wrote: >> Since we clear `_aeh` on L1679 below when `do_thread()` is executed, `_aeh` can >> only be non-NULL when `~InstallAsyncExceptionHandshake()` runs if `do_thread()` >> was never executed. >> >> I can add that comment above L1674 in a separate bug fix if you wish. >> @robehn - do you concur that a comment here would be good? > > It was the fact we null it and delete it that initially caused a "What the???" reaction. :) So I think I comment would be good but can wait. Yes add a comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/8388 From alanb at openjdk.java.net Tue May 3 08:27:22 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 3 May 2022 08:27:22 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: <61bijpgV4Ieny4ue1laoZWoKzJH7nFLWlaF0ZE1fUJM=.a8a96cc5-ad9e-4e87-b45f-9d92a77731b0@github.com> On Thu, 28 Apr 2022 07:13:24 GMT, Matthias Baesken wrote: >> src/java.base/windows/native/libnio/ch/wepoll.c line 159: >> >>> 157: >>> 158: #undef _WIN32_WINNT >>> 159: #define _WIN32_WINNT 0x0601 >> >> This is 3rd party code and would prefer not change it if possible. > > Hi Alan, I agree (thats why I did not change the define in harfbuzz, but I missed that wepoll.c is 3rd party code as well). I assume you can revert the update to the copyright header in the latest version as there aren't any changes to this source file now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From coleenp at openjdk.java.net Tue May 3 11:53:16 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 3 May 2022 11:53:16 GMT Subject: RFR: 8285832: runtime/Thread/TooSmallStackSize.java failed "assert(k->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation" [v3] In-Reply-To: References: <5fYPkCJj2Pl4DaWSMdTgUDfAaFYzWv4r4CdvEllK3qk=.e5b8ec96-c86d-4d88-83db-a0aff68ed7ca@github.com> Message-ID: On Tue, 3 May 2022 00:59:31 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add global os_min_stack_allowed. > > src/hotspot/os/windows/os_windows.cpp line 4288: > >> 4286: >> 4287: // Check and sets minimum stack sizes against command line options >> 4288: if (set_minimum_stack_sizes(_plaform_minimum_stack_allowed) == JNI_ERR) { > > typo: should be `_os_min_stack_allowed` This was temporarily broken, fixed now. > test/hotspot/jtreg/runtime/Thread/TooSmallStackSize.java line 96: > >> 94: >> 95: static ProcessBuilder createProcessWithOptions(String stackOption, String stackSize) throws Exception { >> 96: if (testShadowSize == null) { > > There would be far less duplication if you just used: > > `testShadowSize == null ? "" : ("-XX:StackShadowPages=" + testShadowSize)` Ok, sure. I'll see if it compiles. ------------- PR: https://git.openjdk.java.net/jdk/pull/8471 From vitalyd at gmail.com Tue May 3 11:05:08 2022 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 3 May 2022 07:05:08 -0400 Subject: SIGBUS on linux in perfMemory_init In-Reply-To: References: Message-ID: Hi all, Wanted to bump this thread in case someone with thoughts/opinions missed it the first time around. Solutions aside, should a JBS entry be filed to record/track this? Thanks On Fri, Apr 29, 2022 at 9:44 AM Vitaly Davidovich wrote: > Hi all, > > We've been seeing intermittent SIGBUS failures on linux with jdk11. They > all have this distinctive backtrace: > > C [libc.so.6+0x12944d] > > V [libjvm.so+0xcca542] perfMemory_init()+0x72 > > V [libjvm.so+0x8a3242] vm_init_globals()+0x22 > > V [libjvm.so+0xedc31d] Threads::create_vm(JavaVMInitArgs*, bool*)+0x1ed > > V [libjvm.so+0x9615b2] JNI_CreateJavaVM+0x52 > > C [libjli.so+0x49af] JavaMain+0x8f > > C [libjli.so+0x9149] ThreadJavaMain+0x9 > > > Initially, we suspected that /tmp was full but that turned out to not be > the case. After a few more instances of the crash and investigation, we > believe we know the root cause. > > > The crashing applications are all running in a K8 pod, with each JVM in a > separate container: > > > container_type: cgroupv1 (from the hs_err file) > > > /tmp is mounted such that it's shared by multiple containers. Since these > JVMs are running in containers, we believe what happens is the namespaced > (i.e. per container) PIDs overlap between different containers - 2 JVMs, in > separate containers, can end up with the same namespaced PID. Since /tmp > is shared, they can now "contend" on the same perfMemory file since those > file names are PID based. > > > Once multiple JVMs can contend on the same file, a SIGBUS can arise if one > JVM has mmap'd the file and another ftruncate()'s it from under it (e.g. > https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/hotspot/os/linux/perfMemory_linux.cpp#L909 > ). > > > Is this a known issue? I couldn't find any existing JBS entries or mailing > list discussions around this specific circumstance. > > > As for possible solutions, would it be possible to use the global PID > instead of the namespaced PID to "regain" the uniqueness invariant of the > PID? Also, might it make sense to flock() the file to prevent another > process from mucking with it? > > > Happy to provide more info if needed. > > > Thanks > > > -- Sent from my phone From coleenp at openjdk.java.net Tue May 3 12:05:00 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 3 May 2022 12:05:00 GMT Subject: RFR: 8285832: runtime/Thread/TooSmallStackSize.java failed "assert(k->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation" [v4] In-Reply-To: References: Message-ID: > The minimum stack size check for ThreadStackSize, CompilerStackSize and VMStackSize should also be done for windows. I moved this to shared code with platform specific constants. > Windows platform was checking the option against the current thread's stack size, and not checking ThreadStackSize, and was setting the stack size against that. It worked until you increase StackShadowPages, and then the calculation is wrong. > For Windows, the minimum thread stack size with current StackShadowPages of 9 in debug is now 92K rather than 188K. > The ShadowPageSize is too low for the loom repository and is on the bounds of current mainline, so will be increased when Loom is integrated. When increased to 11 StackShadowPages, the smallest stack size is 100K. > Tested with tier1-4 on windows-x64-debug. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: fix windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8471/files - new: https://git.openjdk.java.net/jdk/pull/8471/files/23571376..738c75ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8471&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8471&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8471.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8471/head:pull/8471 PR: https://git.openjdk.java.net/jdk/pull/8471 From coleenp at openjdk.java.net Tue May 3 12:05:01 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 3 May 2022 12:05:01 GMT Subject: RFR: 8285832: runtime/Thread/TooSmallStackSize.java failed "assert(k->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation" [v3] In-Reply-To: References: <5fYPkCJj2Pl4DaWSMdTgUDfAaFYzWv4r4CdvEllK3qk=.e5b8ec96-c86d-4d88-83db-a0aff68ed7ca@github.com> Message-ID: On Tue, 3 May 2022 11:50:09 GMT, Coleen Phillimore wrote: >> src/hotspot/os/windows/os_windows.cpp line 4288: >> >>> 4286: >>> 4287: // Check and sets minimum stack sizes against command line options >>> 4288: if (set_minimum_stack_sizes(_plaform_minimum_stack_allowed) == JNI_ERR) { >> >> typo: should be `_os_min_stack_allowed` > > This was temporarily broken, fixed now. Good catch. I forgot to push the fix. Now pushed. >> test/hotspot/jtreg/runtime/Thread/TooSmallStackSize.java line 96: >> >>> 94: >>> 95: static ProcessBuilder createProcessWithOptions(String stackOption, String stackSize) throws Exception { >>> 96: if (testShadowSize == null) { >> >> There would be far less duplication if you just used: >> >> `testShadowSize == null ? "" : ("-XX:StackShadowPages=" + testShadowSize)` > > Ok, sure. I'll see if it compiles. The process builder doesn't like the "" argument and thinks it's the class name. There's 3 lines of duplication plus a 3 line comment. That's why I put it together in a function. ------------- PR: https://git.openjdk.java.net/jdk/pull/8471 From dholmes at openjdk.java.net Tue May 3 12:39:23 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 3 May 2022 12:39:23 GMT Subject: RFR: 8285832: runtime/Thread/TooSmallStackSize.java failed "assert(k->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation" [v4] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 12:05:00 GMT, Coleen Phillimore wrote: >> The minimum stack size check for ThreadStackSize, CompilerStackSize and VMStackSize should also be done for windows. I moved this to shared code with platform specific constants. >> Windows platform was checking the option against the current thread's stack size, and not checking ThreadStackSize, and was setting the stack size against that. It worked until you increase StackShadowPages, and then the calculation is wrong. >> For Windows, the minimum thread stack size with current StackShadowPages of 9 in debug is now 92K rather than 188K. >> The ShadowPageSize is too low for the loom repository and is on the bounds of current mainline, so will be increased when Loom is integrated. When increased to 11 StackShadowPages, the smallest stack size is 100K. >> Tested with tier1-4 on windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > fix windows Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8471 From dholmes at openjdk.java.net Tue May 3 12:39:23 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 3 May 2022 12:39:23 GMT Subject: RFR: 8285832: runtime/Thread/TooSmallStackSize.java failed "assert(k->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation" [v3] In-Reply-To: References: <5fYPkCJj2Pl4DaWSMdTgUDfAaFYzWv4r4CdvEllK3qk=.e5b8ec96-c86d-4d88-83db-a0aff68ed7ca@github.com> Message-ID: On Tue, 3 May 2022 11:56:40 GMT, Coleen Phillimore wrote: >> Ok, sure. I'll see if it compiles. > > The process builder doesn't like the "" argument and thinks it's the class name. There's 3 lines of duplication plus a 3 line comment. That's why I put it together in a function. That is a shame. ------------- PR: https://git.openjdk.java.net/jdk/pull/8471 From erikj at openjdk.java.net Tue May 3 13:17:21 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 3 May 2022 13:17:21 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Copyright year in wepoll.c If we define this centrally using compiler flags, then we should not also update each location in the source. Those need to either be removed or left alone. In the cases where the source definition is guarded with an ifndef and there is a comment explaining why a particular version of windows is required, keeping it around could make sense. But on the other hand, since those defines are overridden using flags, they are likely to bit rot over time so we might as well just remove all of them. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From dholmes at openjdk.java.net Tue May 3 13:31:12 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 3 May 2022 13:31:12 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Copyright year in wepoll.c I agree with Erik - the source locations need to be modified to not define it. If we want to keep a record perhaps add an assertion that the value is what was expected? I still feel we have a disconnect between this and an actual check for what the build and runtime platform version is ... and it isn't at all clear how someone using an API only in a later Windows version, and so setting _WIN32_WINNT to a higher value, will know that this is defined down in the build files ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From fparain at openjdk.java.net Tue May 3 13:35:16 2022 From: fparain at openjdk.java.net (Frederic Parain) Date: Tue, 3 May 2022 13:35:16 GMT Subject: RFR: 8285832: runtime/Thread/TooSmallStackSize.java failed "assert(k->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation" [v4] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 12:05:00 GMT, Coleen Phillimore wrote: >> The minimum stack size check for ThreadStackSize, CompilerStackSize and VMStackSize should also be done for windows. I moved this to shared code with platform specific constants. >> Windows platform was checking the option against the current thread's stack size, and not checking ThreadStackSize, and was setting the stack size against that. It worked until you increase StackShadowPages, and then the calculation is wrong. >> For Windows, the minimum thread stack size with current StackShadowPages of 9 in debug is now 92K rather than 188K. >> The ShadowPageSize is too low for the loom repository and is on the bounds of current mainline, so will be increased when Loom is integrated. When increased to 11 StackShadowPages, the smallest stack size is 100K. >> Tested with tier1-4 on windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > fix windows Looks good to me. Fred ------------- Marked as reviewed by fparain (Committer). PR: https://git.openjdk.java.net/jdk/pull/8471 From mbaesken at openjdk.java.net Tue May 3 14:00:21 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 3 May 2022 14:00:21 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: <61bijpgV4Ieny4ue1laoZWoKzJH7nFLWlaF0ZE1fUJM=.a8a96cc5-ad9e-4e87-b45f-9d92a77731b0@github.com> References: <61bijpgV4Ieny4ue1laoZWoKzJH7nFLWlaF0ZE1fUJM=.a8a96cc5-ad9e-4e87-b45f-9d92a77731b0@github.com> Message-ID: <09w3bQ6aE-0lywGwhamYkRZeizTLHpYID7C5dzyuzTc=.44290269-9308-4969-ac52-2f0423883b2b@github.com> On Tue, 3 May 2022 08:23:52 GMT, Alan Bateman wrote: >> Hi Alan, I agree (thats why I did not change the define in harfbuzz, but I missed that wepoll.c is 3rd party code as well). > > I assume you can revert the update to the copyright header in the latest version as there aren't any changes to this source file now. Yes sure I did it . ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From sgehwolf at redhat.com Tue May 3 12:52:28 2022 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 03 May 2022 14:52:28 +0200 Subject: SIGBUS on linux in perfMemory_init (containers) In-Reply-To: <0fc672f9-c122-240d-2552-279abfbea974@oracle.com> References: <48326cc7-b3b9-edfd-c487-e1ee1e5fc1c1@oracle.com> <0fc672f9-c122-240d-2552-279abfbea974@oracle.com> Message-ID: On Mon, 2022-05-02 at 22:13 -0700, Ioi Lam wrote: > > > On 5/2/2022 5:41 AM, Severin Gehwolf wrote: > > Hi, > > > > On Fri, 2022-04-29 at 14:19 -0700, Ioi Lam wrote: > > > > > > On 4/29/2022 1:55 PM, Ioi Lam wrote: > > > > > > > > On 4/29/2022 6:44 AM, Vitaly Davidovich wrote: > > > > > Hi all, > > > > > > > > > > We've been seeing intermittent SIGBUS failures on linux with jdk11. > > > > > They > > > > > all have this distinctive backtrace: > > > > > > > > > > C? [libc.so.6+0x12944d] > > > > > > > > > > V? [libjvm.so+0xcca542]? perfMemory_init()+0x72 > > > > > > > > > > V? [libjvm.so+0x8a3242]? vm_init_globals()+0x22 > > > > > > > > > > V? [libjvm.so+0xedc31d]? Threads::create_vm(JavaVMInitArgs*, > > > > > bool*)+0x1ed > > > > > > > > > > V? [libjvm.so+0x9615b2]? JNI_CreateJavaVM+0x52 > > > > > > > > > > C? [libjli.so+0x49af]? JavaMain+0x8f > > > > > > > > > > C? [libjli.so+0x9149]? ThreadJavaMain+0x9 > > > > > > > > > > > > > > > Initially, we suspected that /tmp was full but that turned out to not be > > > > > the case.? After a few more instances of the crash and investigation, we > > > > > believe we know the root cause. > > > > > > > > > > > > > > > The crashing applications are all running in a K8 pod, with each JVM > > > > > in a > > > > > separate container: > > > > > > > > > > > > > > > container_type: cgroupv1 (from the hs_err file) > > > > > > > > > > > > > > > /tmp is mounted such that it's shared by multiple containers. Since > > > > > these > > > > > JVMs are running in containers, we believe what happens is the > > > > > namespaced > > > > > (i.e. per container) PIDs overlap between different containers - 2 > > > > > JVMs, in > > > > > separate containers, can end up with the same namespaced PID. Since /tmp > > > > > is shared, they can now "contend" on the same perfMemory file since > > > > > those > > > > > file names are PID based. > > > > Hi Vitaly, > > > > > > > > Is there any reason for sharing the same /tmp directory across > > > > different containers? > > > > > > > > Are you using the /tmp/hsperfdata_$USER/ files at all. If not, > > > > for the time being, you can disable them with the -XX:-UsePerfData flag, > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8255008?has a related proposal: > > > > > > This bug is private. Could this one be made accessible somehow? > > I've made the bug public. Thank you! > > Another related bug seems to be, though not quite the same: > > https://bugs.openjdk.java.net/browse/JDK-8284330 > > Vitaly's scenario will still crash with the above fix. Right. My understanding is that Vitaly's scenario is /tmp shared across multiple containers, which likely run as pid 1 (if the only process). Add to it that they run as the same users inside the container and you get your clash: Container 1: user A, single process (=> pid 1) Container 2: user A, single process (=> pid 1) Container 1 and 2 share /tmp (e.g. via volume mounts). Container 1 *and* Container 2's processes suddenly share /tmp/hsperfdata_usera/1. $ ps ax | grep java 17662 pts/0 Ssl+ 0:01 java -jar /deployments/undertow-servlet.jar 18057 pts/0 Ssl+ 0:01 java -jar /deployments/undertow-servlet.jar $ sudo lsof -p 17662 | grep hsperf java 17662 sgehwolf DEL REG 253,6 2464492 /tmp/hsperfdata_sgehwolf/1 $ sudo lsof -p 18057 | grep hsperf java 18057 sgehwolf mem REG 253,6 2464503 /tmp/hsperfdata_sgehwolf/1 (stat: No such file or directory) Containers started with: $ podman run --rm -ti --userns keep-id --user $(id -u) -v $(pwd)/tmp_share_test:/tmp:z quay.io/sgehwolf/fedora-35-undertow:jdk17 Question is why share tmp to begin with? > > > > Java: -Djdk.attach.tmpdir=/container-attachdir > > > > -XX:+UnlockCommercialFeature -XX:+FlightRecorder -XX:+StartAttachListener > > > > Docker: --volume /tmp/container-attachdir:/container-attachdir > > > > > > > > In this case, we probably will run into the same UID clash problem as > > > > well. > > > > > > > > Maybe we should have an additional property like > > > > -Djdk.attach.use.global.pid=true > > > > > > > I read the proposal in JDK-8255008 again and realized that the JVM > > > inside the container doesn't know what it's host PID is. The proposal is > > > to create these files: > > > > > > $jdk_attach_dir/hsperfdata_{user}/e4f3e2e4fd97:10 > > > $jdk_attach_dir/.java_pid:e4f3e2e4fd97:10 > > > > > > where the e4f3e2e4fd97 is the container ID which is visible as > > > /tmp/hostname from inside the container. > > > > > > I'll try to implement a prototype for the proposal. > > Please be aware that the container's hostname is also user-settable. > > E.g. > > > > $ docker run --hostname foo ... > > > > Would set the hostname to 'foo'. > > Maybe that's OK, as the user will probably set them to unique names. My concern is that all of a sudden user-input ends up writing paths in the filesystem. That's a no-no to me. > Or we can use some sort of UUID. Is there anything that cgroup provides > for a containerized process to uniquely identify itself? Not that I'm aware of. But then again I'm doubtful the use-case has a lot to stand on. > And, do we need to handle nested containers? Is this a practical use case? TBH, I'm not sure this is a fix worth having. Other than increased complexity of the code I don't see much benefit. What's the use-case exactly? To be able to extract JFR recordings from a process *in* a container, but not run as root on the host? > > Ioi, did you end up creating a bug for this? > > I created a JBS issue from Vitaly's original report: > > https://bugs.openjdk.java.net/browse/JDK-8286030 Thanks. -- Severin From ioi.lam at oracle.com Tue May 3 15:06:58 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 3 May 2022 08:06:58 -0700 Subject: SIGBUS on linux in perfMemory_init In-Reply-To: References: Message-ID: <402bd371-34ef-3cfb-cce9-a40d19356e33@oracle.com> On 5/3/2022 4:05 AM, Vitaly Davidovich wrote: > Hi all, > > Wanted to bump this thread in case someone with thoughts/opinions missed it > the first time around. > > Solutions aside, should a JBS entry be filed to record/track this? I already filed a JBS issue on your behalf https://bugs.openjdk.java.net/browse/JDK-8286030 Thanks - Ioi > Thanks > > On Fri, Apr 29, 2022 at 9:44 AM Vitaly Davidovich wrote: > >> Hi all, >> >> We've been seeing intermittent SIGBUS failures on linux with jdk11. They >> all have this distinctive backtrace: >> >> C [libc.so.6+0x12944d] >> >> V [libjvm.so+0xcca542] perfMemory_init()+0x72 >> >> V [libjvm.so+0x8a3242] vm_init_globals()+0x22 >> >> V [libjvm.so+0xedc31d] Threads::create_vm(JavaVMInitArgs*, bool*)+0x1ed >> >> V [libjvm.so+0x9615b2] JNI_CreateJavaVM+0x52 >> >> C [libjli.so+0x49af] JavaMain+0x8f >> >> C [libjli.so+0x9149] ThreadJavaMain+0x9 >> >> >> Initially, we suspected that /tmp was full but that turned out to not be >> the case. After a few more instances of the crash and investigation, we >> believe we know the root cause. >> >> >> The crashing applications are all running in a K8 pod, with each JVM in a >> separate container: >> >> >> container_type: cgroupv1 (from the hs_err file) >> >> >> /tmp is mounted such that it's shared by multiple containers. Since these >> JVMs are running in containers, we believe what happens is the namespaced >> (i.e. per container) PIDs overlap between different containers - 2 JVMs, in >> separate containers, can end up with the same namespaced PID. Since /tmp >> is shared, they can now "contend" on the same perfMemory file since those >> file names are PID based. >> >> >> Once multiple JVMs can contend on the same file, a SIGBUS can arise if one >> JVM has mmap'd the file and another ftruncate()'s it from under it (e.g. >> https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/hotspot/os/linux/perfMemory_linux.cpp#L909 >> ). >> >> >> Is this a known issue? I couldn't find any existing JBS entries or mailing >> list discussions around this specific circumstance. >> >> >> As for possible solutions, would it be possible to use the global PID >> instead of the namespaced PID to "regain" the uniqueness invariant of the >> PID? Also, might it make sense to flock() the file to prevent another >> process from mucking with it? >> >> >> Happy to provide more info if needed. >> >> >> Thanks >> >> >> -- > Sent from my phone From vitalyd at gmail.com Tue May 3 15:54:15 2022 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 3 May 2022 11:54:15 -0400 Subject: SIGBUS on linux in perfMemory_init In-Reply-To: <402bd371-34ef-3cfb-cce9-a40d19356e33@oracle.com> References: <402bd371-34ef-3cfb-cce9-a40d19356e33@oracle.com> Message-ID: On Tue, May 3, 2022 at 11:07 AM Ioi Lam wrote: > > > On 5/3/2022 4:05 AM, Vitaly Davidovich wrote: > > Hi all, > > > > Wanted to bump this thread in case someone with thoughts/opinions missed > it > > the first time around. > > > > Solutions aside, should a JBS entry be filed to record/track this? > > I already filed a JBS issue on your behalf > https://bugs.openjdk.java.net/browse/JDK-8286030 > > Thanks > - Ioi Ah, thanks Ioi! > > > > Thanks > > > > On Fri, Apr 29, 2022 at 9:44 AM Vitaly Davidovich > wrote: > > > >> Hi all, > >> > >> We've been seeing intermittent SIGBUS failures on linux with jdk11. > They > >> all have this distinctive backtrace: > >> > >> C [libc.so.6+0x12944d] > >> > >> V [libjvm.so+0xcca542] perfMemory_init()+0x72 > >> > >> V [libjvm.so+0x8a3242] vm_init_globals()+0x22 > >> > >> V [libjvm.so+0xedc31d] Threads::create_vm(JavaVMInitArgs*, > bool*)+0x1ed > >> > >> V [libjvm.so+0x9615b2] JNI_CreateJavaVM+0x52 > >> > >> C [libjli.so+0x49af] JavaMain+0x8f > >> > >> C [libjli.so+0x9149] ThreadJavaMain+0x9 > >> > >> > >> Initially, we suspected that /tmp was full but that turned out to not be > >> the case. After a few more instances of the crash and investigation, we > >> believe we know the root cause. > >> > >> > >> The crashing applications are all running in a K8 pod, with each JVM in > a > >> separate container: > >> > >> > >> container_type: cgroupv1 (from the hs_err file) > >> > >> > >> /tmp is mounted such that it's shared by multiple containers. Since > these > >> JVMs are running in containers, we believe what happens is the > namespaced > >> (i.e. per container) PIDs overlap between different containers - 2 > JVMs, in > >> separate containers, can end up with the same namespaced PID. Since > /tmp > >> is shared, they can now "contend" on the same perfMemory file since > those > >> file names are PID based. > >> > >> > >> Once multiple JVMs can contend on the same file, a SIGBUS can arise if > one > >> JVM has mmap'd the file and another ftruncate()'s it from under it (e.g. > >> > https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/hotspot/os/linux/perfMemory_linux.cpp#L909 > >> ). > >> > >> > >> Is this a known issue? I couldn't find any existing JBS entries or > mailing > >> list discussions around this specific circumstance. > >> > >> > >> As for possible solutions, would it be possible to use the global PID > >> instead of the namespaced PID to "regain" the uniqueness invariant of > the > >> PID? Also, might it make sense to flock() the file to prevent another > >> process from mucking with it? > >> > >> > >> Happy to provide more info if needed. > >> > >> > >> Thanks > >> > >> > >> -- > > Sent from my phone > > -- Sent from my phone From vitalyd at gmail.com Tue May 3 16:05:48 2022 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 3 May 2022 12:05:48 -0400 Subject: SIGBUS on linux in perfMemory_init In-Reply-To: References: <402bd371-34ef-3cfb-cce9-a40d19356e33@oracle.com> Message-ID: On Tue, May 3, 2022 at 11:54 AM Vitaly Davidovich wrote: > > > On Tue, May 3, 2022 at 11:07 AM Ioi Lam wrote: > >> >> >> On 5/3/2022 4:05 AM, Vitaly Davidovich wrote: >> > Hi all, >> > >> > Wanted to bump this thread in case someone with thoughts/opinions >> missed it >> > the first time around. >> > >> > Solutions aside, should a JBS entry be filed to record/track this? >> >> I already filed a JBS issue on your behalf >> https://bugs.openjdk.java.net/browse/JDK-8286030 > > I can't comment on the JBS, but another workaround (which we're employing) is -XX:+PerfDisableSharedMem. Per my understanding, this will prevent certain tools from locating the JVM instance but still allows something like `jcmd` to connect (via an explicitly supplied pid) and read the perf counters. > >> >> Thanks >> - Ioi > > Ah, thanks Ioi! > >> >> >> > Thanks >> > >> > On Fri, Apr 29, 2022 at 9:44 AM Vitaly Davidovich >> wrote: >> > >> >> Hi all, >> >> >> >> We've been seeing intermittent SIGBUS failures on linux with jdk11. >> They >> >> all have this distinctive backtrace: >> >> >> >> C [libc.so.6+0x12944d] >> >> >> >> V [libjvm.so+0xcca542] perfMemory_init()+0x72 >> >> >> >> V [libjvm.so+0x8a3242] vm_init_globals()+0x22 >> >> >> >> V [libjvm.so+0xedc31d] Threads::create_vm(JavaVMInitArgs*, >> bool*)+0x1ed >> >> >> >> V [libjvm.so+0x9615b2] JNI_CreateJavaVM+0x52 >> >> >> >> C [libjli.so+0x49af] JavaMain+0x8f >> >> >> >> C [libjli.so+0x9149] ThreadJavaMain+0x9 >> >> >> >> >> >> Initially, we suspected that /tmp was full but that turned out to not >> be >> >> the case. After a few more instances of the crash and investigation, >> we >> >> believe we know the root cause. >> >> >> >> >> >> The crashing applications are all running in a K8 pod, with each JVM >> in a >> >> separate container: >> >> >> >> >> >> container_type: cgroupv1 (from the hs_err file) >> >> >> >> >> >> /tmp is mounted such that it's shared by multiple containers. Since >> these >> >> JVMs are running in containers, we believe what happens is the >> namespaced >> >> (i.e. per container) PIDs overlap between different containers - 2 >> JVMs, in >> >> separate containers, can end up with the same namespaced PID. Since >> /tmp >> >> is shared, they can now "contend" on the same perfMemory file since >> those >> >> file names are PID based. >> >> >> >> >> >> Once multiple JVMs can contend on the same file, a SIGBUS can arise if >> one >> >> JVM has mmap'd the file and another ftruncate()'s it from under it >> (e.g. >> >> >> https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/hotspot/os/linux/perfMemory_linux.cpp#L909 >> >> ). >> >> >> >> >> >> Is this a known issue? I couldn't find any existing JBS entries or >> mailing >> >> list discussions around this specific circumstance. >> >> >> >> >> >> As for possible solutions, would it be possible to use the global PID >> >> instead of the namespaced PID to "regain" the uniqueness invariant of >> the >> >> PID? Also, might it make sense to flock() the file to prevent another >> >> process from mucking with it? >> >> >> >> >> >> Happy to provide more info if needed. >> >> >> >> >> >> Thanks >> >> >> >> >> >> -- >> > Sent from my phone >> >> -- > Sent from my phone > From jiefu at openjdk.java.net Tue May 3 16:11:09 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 3 May 2022 16:11:09 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible Message-ID: Hi all, `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. >From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). So `FillerObject_klass` should be loaded as soon as possible. (gdb) bt #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 .... #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 The fix just loads `FillerObject` after `Object_klass`. Thanks. Best regards, Jie ------------- Commit messages: - 8286066: FillerObject_klass should be loaded as early as possible Changes: https://git.openjdk.java.net/jdk/pull/8519/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286066 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8519/head:pull/8519 PR: https://git.openjdk.java.net/jdk/pull/8519 From iklam at openjdk.java.net Tue May 3 16:42:12 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 3 May 2022 16:42:12 GMT Subject: RFR: 8285832: runtime/Thread/TooSmallStackSize.java failed "assert(k->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation" [v4] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 12:05:00 GMT, Coleen Phillimore wrote: >> The minimum stack size check for ThreadStackSize, CompilerStackSize and VMStackSize should also be done for windows. I moved this to shared code with platform specific constants. >> Windows platform was checking the option against the current thread's stack size, and not checking ThreadStackSize, and was setting the stack size against that. It worked until you increase StackShadowPages, and then the calculation is wrong. >> For Windows, the minimum thread stack size with current StackShadowPages of 9 in debug is now 92K rather than 188K. >> The ShadowPageSize is too low for the loom repository and is on the bounds of current mainline, so will be increased when Loom is integrated. When increased to 11 StackShadowPages, the smallest stack size is 100K. >> Tested with tier1-4 on windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > fix windows LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8471 From nico at cryptonector.com Tue May 3 15:41:32 2022 From: nico at cryptonector.com (Nico Williams) Date: Tue, 3 May 2022 10:41:32 -0500 Subject: SIGBUS on linux in perfMemory_init In-Reply-To: References: Message-ID: On Fri, Apr 29, 2022 at 09:44:00AM -0400, Vitaly Davidovich wrote: > As for possible solutions, would it be possible to use the global PID > instead of the namespaced PID to "regain" the uniqueness invariant of the > PID? Also, might it make sense to flock() the file to prevent another > process from mucking with it? My unsolicited, outsider opinions: - Sharing /tmp across containers is a Bad Idea (tm). - Sharing /tmp across related containers (in a pod) is not _as_ bad an idea. (It might be a way to implement some cross-container communications, though it would be better to have an explicit mechanism for that rather than the rather-generic /tmp.) - Containerizing apps that *do* communicate over /tmp might be one reason one might configure a shared /tmp in a pod. Some support for such a configuration might be needed. (Alternatively, pods that share /tmp should also share a PID namespace.) - Since there is an option to not have an mmap'ed hsperf file, it might be nice to have an option to use the global PID for naming hsperf files. Or, better, implement an automatic mechanism for detecting conflict and switching to global PID for naming hsperf files (or switching to anonymous hsperf mmaps). - In any case, on systems that have a real flock(2), using flock(2) for liveness testing is better than kill(2) with signal 0 -- the latter has false positives, while the former does not [provided O_CLOEXEC is used]. For this reason, and though I am not too sympathetic to the situation that caused this crash, I believe that it would be better to have some sort of fix for this problem than to declare it a non-problem and not-fix it. I would like to expand on Vitaly's mention of flock(2). Using the global PID would leave the JVM unable to use kill(2) with signal 0 for liveness detection during hsperf garbage file collection. Using kill(2) with signal 0 for liveness is not that reliable anyways because of PID reuse -- it can have false positives. A better mechanism for liveness detection would be to have the owning JVM take an exclusive (LOCK_EX) flock(2) on the hsperf file at startup, and for hsperf garbage file collection to try (LOCK_NB) to get an exclusive lock (LOCK_EX) on a candidate hsperf garbage file as a liveness detection mechanism. When using the namespaced PID the kill(2) with signal 0 method of liveness detection should still be used for backwards-compatibility in, e.g., jvisualvm. Using flock(2) would be less portable than kill(2) with signal 0, but already there is a bunch of Linux-specific code here looking through /proc, and Linux does have a real flock(2). An adaptive, zero-conf hsperf file naming scheme might use the namespaced PID if available (i.e., if an exclusive flock(2) could be obtained on the file), or the global PID if not, with some indication in the name of the file's name of which kind of PID was used. Cheers, Nico -- From dcubed at openjdk.java.net Tue May 3 17:46:26 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 3 May 2022 17:46:26 GMT Subject: RFR: 8284632: runtime/Thread/StopAtExit.java possibly leaking memory again [v2] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:45:10 GMT, Robbin Ehn wrote: >> It was the fact we null it and delete it that initially caused a "What the???" reaction. :) So I think I comment would be good but can wait. > > Yes add a comment. Filed: JDK-8286088 add comment to InstallAsyncExceptionHandshake destructor https://bugs.openjdk.java.net/browse/JDK-8286088 ------------- PR: https://git.openjdk.java.net/jdk/pull/8388 From coleenp at openjdk.java.net Tue May 3 17:47:31 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 3 May 2022 17:47:31 GMT Subject: RFR: 8285832: runtime/Thread/TooSmallStackSize.java failed "assert(k->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation" [v4] In-Reply-To: References: Message-ID: <6y2EesJGPaa9a3YI8rueYw-lbOHs3vlhH2FTbDi38iw=.bcd1d195-f318-4acc-8914-b67b2f6f000d@github.com> On Tue, 3 May 2022 12:05:00 GMT, Coleen Phillimore wrote: >> The minimum stack size check for ThreadStackSize, CompilerStackSize and VMStackSize should also be done for windows. I moved this to shared code with platform specific constants. >> Windows platform was checking the option against the current thread's stack size, and not checking ThreadStackSize, and was setting the stack size against that. It worked until you increase StackShadowPages, and then the calculation is wrong. >> For Windows, the minimum thread stack size with current StackShadowPages of 9 in debug is now 92K rather than 188K. >> The ShadowPageSize is too low for the loom repository and is on the bounds of current mainline, so will be increased when Loom is integrated. When increased to 11 StackShadowPages, the smallest stack size is 100K. >> Tested with tier1-4 on windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > fix windows Thanks David. I looked at the comments and only the last line refers to libc, so thought I should leave the comment as is because it's a useful comment. Thanks Fred and Ioi for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/8471 From coleenp at openjdk.java.net Tue May 3 17:47:33 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 3 May 2022 17:47:33 GMT Subject: Integrated: 8285832: runtime/Thread/TooSmallStackSize.java failed "assert(k->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation" In-Reply-To: References: Message-ID: <57rBJfpLYTZ3s1j6dbPEcHuVl0GUEkp5Z8q2gtNygag=.631f3ea7-193a-4cf1-b4df-3ec0bfda29fb@github.com> On Fri, 29 Apr 2022 17:35:57 GMT, Coleen Phillimore wrote: > The minimum stack size check for ThreadStackSize, CompilerStackSize and VMStackSize should also be done for windows. I moved this to shared code with platform specific constants. > Windows platform was checking the option against the current thread's stack size, and not checking ThreadStackSize, and was setting the stack size against that. It worked until you increase StackShadowPages, and then the calculation is wrong. > For Windows, the minimum thread stack size with current StackShadowPages of 9 in debug is now 92K rather than 188K. > The ShadowPageSize is too low for the loom repository and is on the bounds of current mainline, so will be increased when Loom is integrated. When increased to 11 StackShadowPages, the smallest stack size is 100K. > Tested with tier1-4 on windows-x64-debug. This pull request has now been integrated. Changeset: be67acdf Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/be67acdf5cb962deb657045c4c07592984a789c9 Stats: 304 lines in 21 files changed: 134 ins; 125 del; 45 mod 8285832: runtime/Thread/TooSmallStackSize.java failed "assert(k->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation" Reviewed-by: dholmes, fparain, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/8471 From rriggs at openjdk.java.net Tue May 3 17:53:18 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 3 May 2022 17:53:18 GMT Subject: RFR: 8283606: Tests may fail with zh locale on MacOS [v2] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 17:30:22 GMT, Vikey Chen wrote: >> From the test doc of openjdk https://openjdk.java.net/groups/build/doc/testing.html >>> If your locale is non-US, some tests are likely to fail. To work around this you can set the locale to US. On Unix platforms simply setting LANG="en_US" in the environment before running tests should work. On Windows or MacOS, setting JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US" helps for most, but not all test cases. >> >> However, on MacOS 12.1, running `make test-tier1 JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"` command for tier-1 test, some tests still fail, including the following in tier-1.The tests expects output messages in English, but Chinese message are still produced. >> >> test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java >> test/langtools/jdk/javadoc/tool/6964914/TestStdDoclet.java >> test/langtools/jdk/javadoc/tool/6964914/TestUserDoclet.java >> test/langtools/jdk/javadoc/tool/EnsureNewOldDoclet.java >> test/langtools/jdk/javadoc/tool/testLocaleOption/TestLocaleOption.java >> test/langtools/tools/javac/T8132562/ClassPathWithDoubleQuotesTest.java >> test/langtools/tools/javac/options/smokeTests/OptionSmokeTest.java >> test/langtools/tools/javac/platform/PlatformProviderTest.java >> test/langtools/tools/jdeps/MultiReleaseJar.java > > Vikey Chen has updated the pull request incrementally with one additional commit since the last revision: > > polish Looks fine. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7924 From dcubed at openjdk.java.net Tue May 3 19:52:35 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 3 May 2022 19:52:35 GMT Subject: RFR: 8286088: add comment to InstallAsyncExceptionHandshake destructor Message-ID: A trivial fix to add comment to InstallAsyncExceptionHandshake destructor. ------------- Commit messages: - 8286088: add comment to InstallAsyncExceptionHandshake destructor Changes: https://git.openjdk.java.net/jdk/pull/8522/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8522&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286088 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8522/head:pull/8522 PR: https://git.openjdk.java.net/jdk/pull/8522 From dcubed at openjdk.java.net Tue May 3 19:52:36 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 3 May 2022 19:52:36 GMT Subject: RFR: 8286088: add comment to InstallAsyncExceptionHandshake destructor In-Reply-To: References: Message-ID: On Tue, 3 May 2022 19:46:34 GMT, Daniel D. Daugherty wrote: > A trivial fix to add comment to InstallAsyncExceptionHandshake destructor. @dholmes-ora, @robehn and @pchilano - Please take a look at the comment when you get the chance. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8522 From dcubed at openjdk.java.net Tue May 3 21:12:58 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 3 May 2022 21:12:58 GMT Subject: RFR: 8286088: add comment to InstallAsyncExceptionHandshake destructor [v2] In-Reply-To: References: Message-ID: > A trivial fix to add comment to InstallAsyncExceptionHandshake destructor. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: dholmes CR - simplify the comment. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8522/files - new: https://git.openjdk.java.net/jdk/pull/8522/files/12e2e98a..ae239ce2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8522&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8522&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8522/head:pull/8522 PR: https://git.openjdk.java.net/jdk/pull/8522 From dholmes at openjdk.java.net Tue May 3 21:22:20 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 3 May 2022 21:22:20 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible In-Reply-To: References: Message-ID: On Tue, 3 May 2022 16:01:56 GMT, Jie Fu wrote: > Hi all, > > `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. > We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. > > From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). > So `FillerObject_klass` should be loaded as soon as possible. > > > (gdb) bt > #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 > #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 > #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 > #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 > #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 > #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 > #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 > #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 > #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 > #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 > #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 > #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 > #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 > #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 > #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 > #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 > #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 > > > .... > > > #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 > > > #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 > #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 > #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 > #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 > #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 > #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 > #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 > #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 > > > The fix just loads `FillerObject` after `Object_klass`. > > Thanks. > Best regards, > Jie Changes requested by dholmes (Reviewer). src/hotspot/share/classfile/vmClassMacros.hpp line 54: > 52: do_klass(Object_klass, java_lang_Object ) \ > 53: /* GC support, should be loaded as early as possible */ \ > 54: do_klass(FillerObject_klass, jdk_internal_vm_FillerObject ) \ That seems just a touch too early for my liking, Even though it is an empty class it is in a different package and that might perturb a few things in an unexpected way. IIUC the class is going to be needed when the initial TLAB is expanded. Did you determine exactly which class was causing that? I'd like to see this loading delayed until after the core system classes, as much as possible. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From dholmes at openjdk.java.net Tue May 3 21:23:16 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 3 May 2022 21:23:16 GMT Subject: RFR: 8286088: add comment to InstallAsyncExceptionHandshake destructor [v2] In-Reply-To: References: Message-ID: <2o79Z-YtuEhnEwRLXmm6viaBjcY7oiuZ4BeRsIMAVLc=.b9c69a72-ad4e-44ae-ad30-d094046ed8ea@github.com> On Tue, 3 May 2022 21:12:58 GMT, Daniel D. Daugherty wrote: >> A trivial fix to add comment to InstallAsyncExceptionHandshake destructor. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > dholmes CR - simplify the comment. Looks good and trivial. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8522 From dcubed at openjdk.java.net Tue May 3 21:23:16 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 3 May 2022 21:23:16 GMT Subject: RFR: 8286088: add comment to InstallAsyncExceptionHandshake destructor [v2] In-Reply-To: <2o79Z-YtuEhnEwRLXmm6viaBjcY7oiuZ4BeRsIMAVLc=.b9c69a72-ad4e-44ae-ad30-d094046ed8ea@github.com> References: <2o79Z-YtuEhnEwRLXmm6viaBjcY7oiuZ4BeRsIMAVLc=.b9c69a72-ad4e-44ae-ad30-d094046ed8ea@github.com> Message-ID: <_eJ9zpoteipXKsEkOL4XTjxIgd6JscwB8a1C-lSff3I=.fd9b777e-4180-47ea-8374-e7b702be4105@github.com> On Tue, 3 May 2022 21:20:14 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> dholmes CR - simplify the comment. > > Looks good and trivial. > > Thanks, > David @dholmes-ora - Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8522 From dcubed at openjdk.java.net Tue May 3 21:30:22 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 3 May 2022 21:30:22 GMT Subject: Integrated: 8286088: add comment to InstallAsyncExceptionHandshake destructor In-Reply-To: References: Message-ID: On Tue, 3 May 2022 19:46:34 GMT, Daniel D. Daugherty wrote: > A trivial fix to add comment to InstallAsyncExceptionHandshake destructor. This pull request has now been integrated. Changeset: efcd3d3a Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/efcd3d3a8fd19909ef21a07cc61613aad4dbe145 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8286088: add comment to InstallAsyncExceptionHandshake destructor Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/8522 From coleenp at openjdk.java.net Tue May 3 22:59:26 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 3 May 2022 22:59:26 GMT Subject: RFR: 8286092: Remove dead windows stack code Message-ID: In reviewing JDK-[8285832](https://bugs.openjdk.java.net/browse/JDK-8285832) @iklam noticed the code following the minimum stack size calculation is dead. This change removes the dead code, plus an unused os_thread_counter nearby. This code predates mercurial. Tested with tier1 on windows-x64 and windows-x64-debug. ------------- Commit messages: - 8286092: Remove dead windows stack code Changes: https://git.openjdk.java.net/jdk/pull/8524/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8524&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286092 Stats: 37 lines in 2 files changed: 0 ins; 37 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8524.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8524/head:pull/8524 PR: https://git.openjdk.java.net/jdk/pull/8524 From iklam at openjdk.java.net Tue May 3 23:09:53 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 3 May 2022 23:09:53 GMT Subject: RFR: 8286092: Remove dead windows stack code In-Reply-To: References: Message-ID: On Tue, 3 May 2022 22:34:10 GMT, Coleen Phillimore wrote: > In reviewing JDK-[8285832](https://bugs.openjdk.java.net/browse/JDK-8285832) @iklam noticed the code following the minimum stack size calculation is dead. This change removes the dead code, plus an unused os_thread_counter nearby. > This code predates mercurial. > Tested with tier1 on windows-x64 and windows-x64-debug. LGTM. I searched all .java and .c/.cpp source code for `os_thread_count` and `os_thread_limit` and didn't find any references other than in os_windows.cpp/hpp. So these two fields aren't used by SA, either. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8524 From jiefu at openjdk.java.net Wed May 4 01:04:27 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 4 May 2022 01:04:27 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v2] In-Reply-To: References: Message-ID: > Hi all, > > `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. > We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. > > From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). > So `FillerObject_klass` should be loaded as soon as possible. > > > (gdb) bt > #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 > #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 > #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 > #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 > #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 > #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 > #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 > #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 > #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 > #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 > #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 > #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 > #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 > #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 > #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 > #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 > #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 > > > .... > > > #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 > > > #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 > #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 > #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 > #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 > #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 > #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 > #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 > #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 > > > The fix just loads `FillerObject` after `Object_klass`. > > Thanks. > Best regards, > Jie Jie Fu 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: - Add a jtreg test - Merge branch 'master' into JDK-8286066 - 8286066: FillerObject_klass should be loaded as early as possible ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8519/files - new: https://git.openjdk.java.net/jdk/pull/8519/files/992564dc..5e5b6a43 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=00-01 Stats: 574 lines in 38 files changed: 344 ins; 133 del; 97 mod Patch: https://git.openjdk.java.net/jdk/pull/8519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8519/head:pull/8519 PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Wed May 4 01:09:24 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 4 May 2022 01:09:24 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v2] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 21:19:11 GMT, David Holmes wrote: > That seems just a touch too early for my liking, Even though it is an empty class it is in a different package and that might perturb a few things in an unexpected way. > > IIUC the class is going to be needed when the initial TLAB is expanded. Did you determine exactly which class was causing that? I'd like to see this loading delayed until after the core system classes, as much as possible. > > Thanks. Thanks @dholmes-ora for the review. I added a jtreg to this bug. It can also be reproduced with `java -XX:-UseCompressedClassPointers -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xshare:dump` on Linux/x64. I saw the crash after `java.lang.ThreadDeath` was loaded on x86_32. Maybe, we can load `FillerObject` after `java.lang.Error`. STDERR: stdout: [[0.004s][info][class,path] bootstrap loader class path=/home/jdk/build/linux-x86-server-fastdebug/images/jdk/lib/modules [0.006s][warning][gc,init ] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups [0.006s][info ][cds ] Core region alignment: 4096 [0.006s][info ][class,path] app loader class path=/home/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_runtime_cds_appcds_TestEpsilonGCWithCDS_java/scratch/0/hello.jar [0.006s][info ][class,path] opened: /home/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_runtime_cds_appcds_TestEpsilonGCWithCDS_java/scratch/0/hello.jar [0.006s][info ][class,load] opened: /home/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_runtime_cds_appcds_TestEpsilonGCWithCDS_java/scratch/0/hello.jar [0.010s][info ][class,load] java.lang.Object source: jrt:/java.base [0.010s][info ][class,load] java.io.Serializable source: jrt:/java.base [0.010s][info ][class,load] java.lang.Comparable source: jrt:/java.base [0.010s][info ][class,load] java.lang.CharSequence source: jrt:/java.base [0.010s][info ][class,load] java.lang.constant.Constable source: jrt:/java.base [0.010s][info ][class,load] java.lang.constant.ConstantDesc source: jrt:/java.base [0.011s][info ][class,load] java.lang.String source: jrt:/java.base [0.011s][info ][class,load] java.lang.reflect.AnnotatedElement source: jrt:/java.base [0.012s][info ][class,load] java.lang.reflect.GenericDeclaration source: jrt:/java.base [0.012s][info ][class,load] java.lang.reflect.Type source: jrt:/java.base [0.012s][info ][class,load] java.lang.invoke.TypeDescriptor source: jrt:/java.base [0.012s][info ][class,load] java.lang.invoke.TypeDescriptor$OfField source: jrt:/java.base [0.012s][info ][class,load] java.lang.Class source: jrt:/java.base [0.012s][info ][class,load] java.lang.Cloneable source: jrt:/java.base [0.013s][info ][class,load] java.lang.ClassLoader source: jrt:/java.base [0.013s][info ][class,load] java.lang.System source: jrt:/java.base [0.013s][info ][class,load] java.lang.Throwable source: jrt:/java.base [0.013s][info ][class,load] java.lang.Error source: jrt:/java.base [0.013s][info ][class,load] java.lang.ThreadDeath source: jrt:/java.base # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/vmClasses.hpp:55 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55), pid=78368, tid=78371 # assert(k != __null) failed: klass not loaded # # JRE version: (19.0) (fastdebug build ) # Java VM: OpenJDK Server VM (fastdebug 19-internal-adhoc..jdk, interpreted mode, tiered, epsilon gc, linux-x86) # Problematic frame: # V [libjvm.so+0x85f54d] CollectedHeap::fill_with_dummy_object(HeapWordImpl**, HeapWordImpl**, bool)+0x42d # What do you think? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From dholmes at openjdk.java.net Wed May 4 01:10:24 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 4 May 2022 01:10:24 GMT Subject: RFR: 8286092: Remove dead windows stack code In-Reply-To: References: Message-ID: On Tue, 3 May 2022 22:34:10 GMT, Coleen Phillimore wrote: > In reviewing JDK-[8285832](https://bugs.openjdk.java.net/browse/JDK-8285832) @iklam noticed the code following the minimum stack size calculation is dead. This change removes the dead code, plus an unused os_thread_counter nearby. > This code predates mercurial. > Tested with tier1 on windows-x64 and windows-x64-debug. Nice cleanup! The thread count and limit appear to have been copied from the Solaris code, but the Windows code doesn't actually check the count against the limit anywhere, nor use the count. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8524 From jiefu at openjdk.java.net Wed May 4 01:28:27 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 4 May 2022 01:28:27 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v2] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 01:05:35 GMT, Jie Fu wrote: > Maybe, we can load `FillerObject` after `java.lang.Error`. But I'm not sure if it's always safe to do so on any platforms. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From dholmes at openjdk.java.net Wed May 4 01:50:25 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 4 May 2022 01:50:25 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v2] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 01:25:12 GMT, Jie Fu wrote: >>> That seems just a touch too early for my liking, Even though it is an empty class it is in a different package and that might perturb a few things in an unexpected way. >>> >>> IIUC the class is going to be needed when the initial TLAB is expanded. Did you determine exactly which class was causing that? I'd like to see this loading delayed until after the core system classes, as much as possible. >>> >>> Thanks. >> >> >> >> Thanks @dholmes-ora for the review. >> >> I added a jtreg to this bug. >> It can also be reproduced with `java -XX:-UseCompressedClassPointers -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xshare:dump` on Linux/x64. >> >> I saw the crash after `java.lang.ThreadDeath` was loaded on x86_32. >> Maybe, we can load `FillerObject` after `java.lang.Error`. >> >> STDERR: >> stdout: [[0.004s][info][class,path] bootstrap loader class path=/home/jdk/build/linux-x86-server-fastdebug/images/jdk/lib/modules >> [0.006s][warning][gc,init ] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups >> [0.006s][info ][cds ] Core region alignment: 4096 >> [0.006s][info ][class,path] app loader class path=/home/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_runtime_cds_appcds_TestEpsilonGCWithCDS_java/scratch/0/hello.jar >> [0.006s][info ][class,path] opened: /home/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_runtime_cds_appcds_TestEpsilonGCWithCDS_java/scratch/0/hello.jar >> [0.006s][info ][class,load] opened: /home/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_runtime_cds_appcds_TestEpsilonGCWithCDS_java/scratch/0/hello.jar >> [0.010s][info ][class,load] java.lang.Object source: jrt:/java.base >> [0.010s][info ][class,load] java.io.Serializable source: jrt:/java.base >> [0.010s][info ][class,load] java.lang.Comparable source: jrt:/java.base >> [0.010s][info ][class,load] java.lang.CharSequence source: jrt:/java.base >> [0.010s][info ][class,load] java.lang.constant.Constable source: jrt:/java.base >> [0.010s][info ][class,load] java.lang.constant.ConstantDesc source: jrt:/java.base >> [0.011s][info ][class,load] java.lang.String source: jrt:/java.base >> [0.011s][info ][class,load] java.lang.reflect.AnnotatedElement source: jrt:/java.base >> [0.012s][info ][class,load] java.lang.reflect.GenericDeclaration source: jrt:/java.base >> [0.012s][info ][class,load] java.lang.reflect.Type source: jrt:/java.base >> [0.012s][info ][class,load] java.lang.invoke.TypeDescriptor source: jrt:/java.base >> [0.012s][info ][class,load] java.lang.invoke.TypeDescriptor$OfField source: jrt:/java.base >> [0.012s][info ][class,load] java.lang.Class source: jrt:/java.base >> [0.012s][info ][class,load] java.lang.Cloneable source: jrt:/java.base >> [0.013s][info ][class,load] java.lang.ClassLoader source: jrt:/java.base >> [0.013s][info ][class,load] java.lang.System source: jrt:/java.base >> [0.013s][info ][class,load] java.lang.Throwable source: jrt:/java.base >> [0.013s][info ][class,load] java.lang.Error source: jrt:/java.base >> [0.013s][info ][class,load] java.lang.ThreadDeath source: jrt:/java.base >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: SuppressErrorAt=/vmClasses.hpp:55 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55), pid=78368, tid=78371 >> # assert(k != __null) failed: klass not loaded >> # >> # JRE version: (19.0) (fastdebug build ) >> # Java VM: OpenJDK Server VM (fastdebug 19-internal-adhoc..jdk, interpreted mode, tiered, epsilon gc, linux-x86) >> # Problematic frame: >> # V [libjvm.so+0x85f54d] CollectedHeap::fill_with_dummy_object(HeapWordImpl**, HeapWordImpl**, bool)+0x42d >> # >> >> >> What do you think? >> Thanks. > >> Maybe, we can load `FillerObject` after `java.lang.Error`. > > But I'm not sure if it's always safe to do so on any platforms. For the x64 case (thanks for that reproducer!) it crashes after loading ` java.lang.Thread$UncaughtExceptionHandler` - so somewhat later than the x86 case. I thought the underlying problem was the TLAB size but at least with EpsilonGC it is acting very counterintuitively - any size > 6K crashes, while less does not. But logging also seems to show that the requested size is not being honoured in those cases but the Ergo size of 2K is being selected! This is all very odd, but perhaps specific to Epsilon. With G1 I can crash with a TLABSize of 4K (or less), but it occurs much later after loading `jdk.internal.reflect.UnsafeStaticFieldAccessorImpl` (for 4K). With 2K minimum TLABSize it is after `java.lang.Boolean`. So I guess after Error is a reasonable compromise. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Wed May 4 02:15:18 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 4 May 2022 02:15:18 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v3] In-Reply-To: References: Message-ID: > Hi all, > > `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. > We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. > > From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). > So `FillerObject_klass` should be loaded as soon as possible. > > > (gdb) bt > #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 > #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 > #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 > #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 > #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 > #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 > #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 > #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 > #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 > #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 > #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 > #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 > #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 > #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 > #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 > #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 > #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 > > > .... > > > #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 > > > #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 > #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 > #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 > #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 > #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 > #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 > #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 > #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 > > > The fix just loads `FillerObject` after `Object_klass`. > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Load FillerObject_klass after Error_klass ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8519/files - new: https://git.openjdk.java.net/jdk/pull/8519/files/5e5b6a43..9fa0c6e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8519/head:pull/8519 PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Wed May 4 02:15:18 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 4 May 2022 02:15:18 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v3] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 01:46:50 GMT, David Holmes wrote: > So I guess after Error is a reasonable compromise. Updated. `runtime/cds/appcds/TestEpsilonGCWithCDS.java runtime/cds/FillerObjectLoadTest.java` passed on Linux/x86_32. More testing is in progress. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Wed May 4 03:10:02 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 4 May 2022 03:10:02 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v4] In-Reply-To: References: Message-ID: <-35C0aO72k5hHFWORRSnhdj4zXIalGlGuiA5QYS3c-E=.3c988d0b-9e21-4637-be8b-335433e5ddf9@github.com> > Hi all, > > `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. > We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. > > From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). > So `FillerObject_klass` should be loaded as soon as possible. > > > (gdb) bt > #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 > #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 > #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 > #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 > #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 > #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 > #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 > #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 > #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 > #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 > #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 > #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 > #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 > #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 > #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 > #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 > #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 > > > .... > > > #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 > > > #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 > #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 > #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 > #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 > #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 > #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 > #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 > #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 > > > The fix just loads `FillerObject` after `Object_klass`. > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Also test the defaul gc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8519/files - new: https://git.openjdk.java.net/jdk/pull/8519/files/9fa0c6e0..8668b8f2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=02-03 Stats: 7 lines in 1 file changed: 5 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8519/head:pull/8519 PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Wed May 4 03:10:02 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 4 May 2022 03:10:02 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v4] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 02:10:35 GMT, Jie Fu wrote: >> For the x64 case (thanks for that reproducer!) it crashes after loading ` java.lang.Thread$UncaughtExceptionHandler` - so somewhat later than the x86 case. >> I thought the underlying problem was the TLAB size but at least with EpsilonGC it is acting very counterintuitively - any size > 6K crashes, while less does not. But logging also seems to show that the requested size is not being honoured in those cases but the Ergo size of 2K is being selected! This is all very odd, but perhaps specific to Epsilon. >> With G1 I can crash with a TLABSize of 4K (or less), but it occurs much later after loading `jdk.internal.reflect.UnsafeStaticFieldAccessorImpl` (for 4K). With 2K minimum TLABSize it is after `java.lang.Boolean`. >> So I guess after Error is a reasonable compromise. >> Thanks. > >> So I guess after Error is a reasonable compromise. > > > Updated. > `runtime/cds/appcds/TestEpsilonGCWithCDS.java runtime/cds/FillerObjectLoadTest.java` passed on Linux/x86_32. > More testing is in progress. > Thanks. > With G1 I can crash with a TLABSize of 4K (or less), but it occurs much later after loading The jtreg test had been updated to also test the default GC. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Wed May 4 07:18:09 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 4 May 2022 07:18:09 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v5] In-Reply-To: References: Message-ID: > Hi all, > > `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. > We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. > > From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). > So `FillerObject_klass` should be loaded as soon as possible. > > > (gdb) bt > #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 > #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 > #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 > #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 > #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 > #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 > #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 > #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 > #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 > #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 > #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 > #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 > #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 > #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 > #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 > #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 > #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 > > > .... > > > #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 > > > #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 > #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 > #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 > #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 > #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 > #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 > #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 > #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 > > > The fix just loads `FillerObject` after `Object_klass`. > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Don't modify the original jdk image ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8519/files - new: https://git.openjdk.java.net/jdk/pull/8519/files/8668b8f2..9157207d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=03-04 Stats: 106 lines in 2 files changed: 56 ins; 50 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8519/head:pull/8519 PR: https://git.openjdk.java.net/jdk/pull/8519 From tschatzl at openjdk.java.net Wed May 4 07:31:25 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 4 May 2022 07:31:25 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v5] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 07:18:09 GMT, Jie Fu wrote: >> Hi all, >> >> `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. >> We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. >> >> From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). >> So `FillerObject_klass` should be loaded as soon as possible. >> >> >> (gdb) bt >> #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 >> #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 >> #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 >> #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 >> #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 >> #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 >> #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 >> #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 >> #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 >> #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 >> #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 >> #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 >> #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 >> #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 >> #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 >> #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 >> #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 >> >> >> .... >> >> >> #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 >> >> >> #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 >> #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 >> #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 >> #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 >> #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 >> #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 >> #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 >> #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 >> >> >> The fix just loads `FillerObject` after `Object_klass`. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Don't modify the original jdk image Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Wed May 4 07:31:25 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 4 May 2022 07:31:25 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v5] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 07:18:09 GMT, Jie Fu wrote: >> Hi all, >> >> `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. >> We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. >> >> From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). >> So `FillerObject_klass` should be loaded as soon as possible. >> >> >> (gdb) bt >> #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 >> #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 >> #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 >> #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 >> #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 >> #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 >> #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 >> #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 >> #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 >> #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 >> #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 >> #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 >> #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 >> #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 >> #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 >> #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 >> #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 >> >> >> .... >> >> >> #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 >> >> >> #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 >> #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 >> #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 >> #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 >> #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 >> #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 >> #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 >> #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 >> >> >> The fix just loads `FillerObject` after `Object_klass`. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Don't modify the original jdk image I tested tier1~tier3 on Linux/x64, no regression. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From mbaesken at openjdk.java.net Wed May 4 07:37:14 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 07:37:14 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Copyright year in wepoll.c Interesting fact : we run now into this compile error : d:\a\jdk\jdk\jdk\src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp(1262): error C2065: 'NCRYPT_CIPHER_KEY_BLOB': undeclared identifier d:\a\jdk\jdk\jdk\src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp(1280): error C2065: 'NCRYPT_PROTECTED_KEY_BLOB': undeclared identifier Reason seems that already for some time ( at least OpenJDK 11 (!) ) we have an implicit minimum requirement of Windows 8 / Windows 2012 APIs for this code, so enforcing Win 7 is too old : https://docs.microsoft.com/en-us/windows/win32/api/ncrypt/nf-ncrypt-ncryptexportkey NCRYPT_PROTECTED_KEY_BLOB Export a protected key in a NCRYPT_KEY_BLOB_HEADER structure. Windows 8 and Windows Server 2012: Support for this value begins. NCRYPT_CIPHER_KEY_BLOB Export a cipher key in a NCRYPT_KEY_BLOB_HEADER structure. Windows 8 and Windows Server 2012: Support for this value begins. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Wed May 4 07:42:14 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 07:42:14 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: <9KE3CEXRqW4z5bQgy9E5ydrFvcxY4LgV9zA-KGRH09M=.e21bbecb-5e37-4887-9a74-7e4227c70c07@github.com> On Tue, 3 May 2022 13:27:41 GMT, David Holmes wrote: > I agree with Erik - the source locations need to be modified to not define it. If we want to keep a record perhaps add an assertion that the value is what was expected? > > I still feel we have a disconnect between this and an actual check for what the build and runtime platform version is ... > > and it isn't at all clear how someone using an API only in a later Windows version, and so setting _WIN32_WINNT to a higher value, will know that this is defined down in the build files ? Hi David, I agree the other locations as long as they are not 3rd party code should be cleaned up. Someone using an API that is only available in later Windows versions would get a redefinition warning as long as no undefine is done. But we have to set _WIN32_WINNT anyway to a higher value (windows8, I think that's 0x0602) to compile src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp . ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From ayang at openjdk.java.net Wed May 4 07:54:12 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 4 May 2022 07:54:12 GMT Subject: RFR: 8285934: Remove unimplemented MemTracker::init_tracking_level In-Reply-To: References: Message-ID: <_EeiL6OFwoHqhThZa-O_AFHDP8Wr5PYjRM8eGs6H8wA=.4786a1b3-874d-4ac9-979e-0be530886215@github.com> On Fri, 29 Apr 2022 15:20:14 GMT, Albert Mingkun Yang wrote: > Trivial change of removing dead code. Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8469 From tschatzl at openjdk.java.net Wed May 4 07:55:21 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 4 May 2022 07:55:21 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v5] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 07:18:09 GMT, Jie Fu wrote: >> Hi all, >> >> `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. >> We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. >> >> From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). >> So `FillerObject_klass` should be loaded as soon as possible. >> >> >> (gdb) bt >> #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 >> #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 >> #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 >> #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 >> #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 >> #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 >> #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 >> #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 >> #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 >> #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 >> #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 >> #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 >> #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 >> #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 >> #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 >> #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 >> #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 >> >> >> .... >> >> >> #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 >> >> >> #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 >> #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 >> #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 >> #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 >> #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 >> #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 >> #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 >> #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 >> >> >> The fix just loads `FillerObject` after `Object_klass`. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Don't modify the original jdk image Changing my approval after thinking it through a bit more to discuss the options we have. An alternative fix which seems more comprehensive could be to use `java_lang_Object()` for filling these gaps while the other isn't initialized. E.g. in CollectedHeap::fill_with_object_impl(HeapWord* start, size_t words, bool zap) { assert(words <= filler_array_max_size(), "too big for a single object"); if (words >= filler_array_min_size()) { fill_with_array(start, words, zap); } else if (words > 0) { assert(words == min_fill_size(), "unaligned size"); ObjAllocator allocator(vmClasses::FillerObject_klass(), words); allocator.initialize(start); } } instead of direct use of `vmClasses::FillerObject_klass()`, add a helper function that selects it based on some predicate; not sure if `Universe::is_initialized()` (or so) isn't too lenient. I see that `vmClasses` already has some `XXXX_class_loaded()` methods - maybe add one of these for the filler objects and select on that? Use of the small filler objects is really rare, additionally it only happens at most once per TLAB/PLAB fill, and is mostly done by the application anyway, so I do not see an issue with such an additional flag. Another option is to have some global variable containing that klass (either in `Universe` or maybe better in `CollectedHeap`) that initially aliases `java_lang_Object` and after this class loading is complete, set it to the filler object klass (that is then used by `CollectedHeap::fill_with_object_impl`. This would completely avoid the somewhat brittle guessing about the initialization order of the klasses, and avoids any runtime overhead by checking whether the klass has already been loaded during runtime at the cost of a single global variable. At this time I kind of prefer this second option. ------------- Changes requested by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8519 From ayang at openjdk.java.net Wed May 4 07:57:41 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 4 May 2022 07:57:41 GMT Subject: Integrated: 8285934: Remove unimplemented MemTracker::init_tracking_level In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 15:20:14 GMT, Albert Mingkun Yang wrote: > Trivial change of removing dead code. This pull request has now been integrated. Changeset: ca9d039f Author: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/ca9d039fd3d2dca194c1515f04edf1d8deb38763 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8285934: Remove unimplemented MemTracker::init_tracking_level Reviewed-by: coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/8469 From mbaesken at openjdk.java.net Wed May 4 08:00:08 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 08:00:08 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: Message-ID: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> > Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : > https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt > Macros for Conditional Declarations > "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." > > However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust API level to Windows 8 for security.cpp and do some cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8428/files - new: https://git.openjdk.java.net/jdk/pull/8428/files/23b63c5b..721528c4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=02-03 Stats: 31 lines in 7 files changed: 1 ins; 26 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8428.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8428/head:pull/8428 PR: https://git.openjdk.java.net/jdk/pull/8428 From jiefu at openjdk.java.net Wed May 4 08:23:17 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 4 May 2022 08:23:17 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v5] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 07:49:24 GMT, Thomas Schatzl wrote: > An alternative fix which seems more comprehensive could be to use `java_lang_Object()` for filling these gaps while the other isn't initialized. > > E.g. in > > ``` > CollectedHeap::fill_with_object_impl(HeapWord* start, size_t words, bool zap) > { > assert(words <= filler_array_max_size(), "too big for a single object"); > > if (words >= filler_array_min_size()) { > fill_with_array(start, words, zap); > } else if (words > 0) { > assert(words == min_fill_size(), "unaligned size"); > ObjAllocator allocator(vmClasses::FillerObject_klass(), words); > allocator.initialize(start); > } > } > ``` > > instead of direct use of `vmClasses::FillerObject_klass()`, add a helper function that selects it based on some predicate; not sure if `Universe::is_initialized()` (or so) isn't too lenient. > > I see that `vmClasses` already has some `XXXX_class_loaded()` methods - maybe add one of these for the filler objects and select on that? > > Use of the small filler objects is really rare, additionally it only happens at most once per TLAB/PLAB fill, and is mostly done by the application anyway, so I do not see an issue with such an additional flag. > > Another option is to have some global variable containing that klass (either in `Universe` or maybe better in `CollectedHeap`) that initially aliases `java_lang_Object` and after this class loading is complete, set it to the filler object klass (that is then used by `CollectedHeap::fill_with_object_impl`. > > This would completely avoid the somewhat brittle guessing about the initialization order of the klasses, and avoids any runtime overhead by checking whether the klass has already been loaded during runtime at the cost of a single global variable. At this time I kind of prefer this second option. Thanks @tschatzl for your review and suggestion. Then part of the unused memory would be filled with `Object` and the others would be filled with `FillerObject`. I'm not sure if this kind of change is safe and if it would complicate the design/implementation/optimization of HotSpot GC algorithms. What do you think of my worries? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From dholmes at openjdk.java.net Wed May 4 08:38:24 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 4 May 2022 08:38:24 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup I'm confused. `src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp` doesn't set _WIN32_WINNT so how is that later API being enabled? Does this mean that not setting _WIN32_WINNT means :any API is allowed" ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From tschatzl at openjdk.java.net Wed May 4 08:41:18 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 4 May 2022 08:41:18 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v5] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 08:20:05 GMT, Jie Fu wrote: > Then part of the unused memory would be filled with `Object` and the others would be filled with `FillerObject`. I'm not sure if this kind of change is safe and if it would complicate the design/implementation/optimization of HotSpot GC algorithms. What do you think of my worries? Thanks. The gc filler objects only provide additional verification and easier debugging (i.e. any reference to such a filler object is simply an error somewhere). We don't (and can't) verify that every non-FillerObject is being referenced at all times. Also, the "wrong" filler objects would also only persist until the first garbage collection, as * all Universe initialization needs to happen before that (the VM will fail otherwise) * (g1 only) all objects allocated during initialization are (for g1) non-humongous * evacuation will reclaim these wrong fillers (and a potential evacuation failure will re-fill the holes with the correct fillers) This can certainly be combined with early as possible initialization of that global variable with the correct `j.i.v.FillerObject` to reduce the number of these objects. So I believe this is safe (and actually necessary to avoid specific TLAB sizes to fail anyway) to do. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From mbaesken at openjdk.java.net Wed May 4 09:11:17 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 09:11:17 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:34:43 GMT, David Holmes wrote: > I'm confused. `src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp` doesn't set _WIN32_WINNT so how is that later API being enabled? Does this mean that not setting _WIN32_WINNT means :any API is allowed" ? I found this info here https://stackoverflow.com/questions/37668692/visual-studio-setting-winver-win32-winnt-to-windows-8-on-windows-7 "VS 2012 uses the Windows 8.0 SDK which defaults to _WIN32_WINNT=0x0602 (Windows 8). VS 2013 / 2015 uses the Windows 8.1 SDK which defaults to _WIN32_WINNT=0x0603 (Windows 8.1). If you use VS 2015 and the Windows 10 SDK, it defaults to _WIN32_WINNT=0x0A00 (Windows 10)." So it seems you get some more or less recent default when working with a not too old compiler/SDK. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From asotona at openjdk.java.net Wed May 4 09:47:44 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Wed, 4 May 2022 09:47:44 GMT Subject: RFR: 8262004: Classpath separator: Man page says semicolon; should be colon on Linux Message-ID: Man file for the java command in JDK, the arguments such as -classpath, --module-path and --upgrade-module-path say "A semicolon (;) separated list of directories" Please review this fix correcting the text to "A colon (:) separated list of directories". Thanks, Adam ------------- Commit messages: - 8262004: Classpath separator: Man page says semicolon; should be colon on Linux Changes: https://git.openjdk.java.net/jdk/pull/8530/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8530&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262004 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8530/head:pull/8530 PR: https://git.openjdk.java.net/jdk/pull/8530 From dholmes at openjdk.java.net Wed May 4 10:12:11 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 4 May 2022 10:12:11 GMT Subject: RFR: 8262004: Classpath separator: Man page says semicolon; should be colon on Linux In-Reply-To: References: Message-ID: On Wed, 4 May 2022 09:28:22 GMT, Adam Sotona wrote: > Man file for the java command in JDK, the arguments such as -classpath, --module-path and --upgrade-module-path say "A semicolon (;) separated list of directories" > > Please review this fix correcting the text to "A colon (:) separated list of directories". > > Thanks, > Adam Hi @asotona, The actual source for this is in our closed repository and while this is a manpage and arguably non-Windows, the actual source produces other output variations that are platform agnostic. So we actually need to fix this at a higher-level and clarify that the path separator is actually platform specific. ------------- PR: https://git.openjdk.java.net/jdk/pull/8530 From mbaesken at openjdk.java.net Wed May 4 12:10:39 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 12:10:39 GMT Subject: RFR: JDK-8285987: executing shell scripts without #! fails on Alpine linux Message-ID: A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 . Looks like this is a known issue on musl / Alpine, see also https://www.openwall.com/lists/musl/2018/03/09/2 and https://github.com/scala-steward-org/scala-steward/issues/1374 (we see it on Alpine 3.15). ------------- Commit messages: - JDK-8285987 Changes: https://git.openjdk.java.net/jdk/pull/8535/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8535&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285987 Stats: 35 lines in 3 files changed: 17 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/8535.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8535/head:pull/8535 PR: https://git.openjdk.java.net/jdk/pull/8535 From coleenp at openjdk.java.net Wed May 4 12:46:16 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 4 May 2022 12:46:16 GMT Subject: RFR: 8286092: Remove dead windows stack code In-Reply-To: References: Message-ID: On Tue, 3 May 2022 22:34:10 GMT, Coleen Phillimore wrote: > In reviewing JDK-[8285832](https://bugs.openjdk.java.net/browse/JDK-8285832) @iklam noticed the code following the minimum stack size calculation is dead. This change removes the dead code, plus an unused os_thread_counter nearby. > This code predates mercurial. > Tested with tier1 on windows-x64 and windows-x64-debug. Thanks Ioi for double checking the SA code. I think this code was an attempt to fix 32 bit windows since it would run out of address space when creating threads. ------------- PR: https://git.openjdk.java.net/jdk/pull/8524 From coleenp at openjdk.java.net Wed May 4 12:55:17 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 4 May 2022 12:55:17 GMT Subject: RFR: 8286092: Remove dead windows stack code In-Reply-To: References: Message-ID: <6TywJCygK6V1yQGjLQZpLBYUg5AfdYHe0192dms-6C8=.a03b27b6-efbc-4be9-947d-7cca4875e9ae@github.com> On Tue, 3 May 2022 22:34:10 GMT, Coleen Phillimore wrote: > In reviewing JDK-[8285832](https://bugs.openjdk.java.net/browse/JDK-8285832) @iklam noticed the code following the minimum stack size calculation is dead. This change removes the dead code, plus an unused os_thread_counter nearby. > This code predates mercurial. > Tested with tier1 on windows-x64 and windows-x64-debug. Yes, thanks David. You forced me to look at old code. It was for Solaris code and not for the windows address space size problems we had with creating threads once. Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8524 From coleenp at openjdk.java.net Wed May 4 12:55:17 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 4 May 2022 12:55:17 GMT Subject: Integrated: 8286092: Remove dead windows stack code In-Reply-To: References: Message-ID: On Tue, 3 May 2022 22:34:10 GMT, Coleen Phillimore wrote: > In reviewing JDK-[8285832](https://bugs.openjdk.java.net/browse/JDK-8285832) @iklam noticed the code following the minimum stack size calculation is dead. This change removes the dead code, plus an unused os_thread_counter nearby. > This code predates mercurial. > Tested with tier1 on windows-x64 and windows-x64-debug. This pull request has now been integrated. Changeset: 29c2e54c Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/29c2e54cf6fe472bd75a75fedf4ecf66e204647a Stats: 37 lines in 2 files changed: 0 ins; 37 del; 0 mod 8286092: Remove dead windows stack code Reviewed-by: iklam, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/8524 From jiefu at openjdk.java.net Wed May 4 13:34:55 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 4 May 2022 13:34:55 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v6] In-Reply-To: References: Message-ID: > Hi all, > > `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. > We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. > > From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). > So `FillerObject_klass` should be loaded as soon as possible. > > > (gdb) bt > #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 > #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 > #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 > #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 > #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 > #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 > #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 > #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 > #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 > #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 > #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 > #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 > #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 > #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 > #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 > #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 > #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 > > > .... > > > #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 > > > #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 > #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 > #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 > #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 > #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 > #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 > #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 > #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 > > > The fix just loads `FillerObject` after `Object_klass`. > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8519/files - new: https://git.openjdk.java.net/jdk/pull/8519/files/9157207d..c05b1338 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=04-05 Stats: 26 lines in 4 files changed: 20 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8519/head:pull/8519 PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Wed May 4 13:44:27 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 4 May 2022 13:44:27 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v5] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 08:35:22 GMT, Thomas Schatzl wrote: > > Then part of the unused memory would be filled with `Object` and the others would be filled with `FillerObject`. I'm not sure if this kind of change is safe and if it would complicate the design/implementation/optimization of HotSpot GC algorithms. What do you think of my worries? Thanks. > > The gc filler objects only provide additional verification and easier debugging (i.e. any reference to such a filler object is simply an error somewhere). We don't (and can't) verify that every non-FillerObject is being referenced at all times. > > Also, the "wrong" filler objects would also only persist until the first garbage collection, as > > * all Universe initialization needs to happen before that (the VM will fail otherwise) > * (g1 only) all objects allocated during initialization are (for g1) non-humongous > * evacuation will reclaim these wrong fillers (and a potential evacuation failure will re-fill the holes with the correct fillers) > > This can certainly be combined with early as possible initialization of that global variable with the correct `j.i.v.FillerObject` to reduce the number of these objects. > > So I believe this is safe (and actually necessary to avoid specific TLAB sizes to fail anyway) to do. > > Thanks, Thomas Sounds good! Updated. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From dcubed at openjdk.java.net Wed May 4 16:42:08 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 4 May 2022 16:42:08 GMT Subject: Integrated: 8286138: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 Message-ID: A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64. ------------- Commit messages: - 8286138: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/8538/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8538&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286138 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8538.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8538/head:pull/8538 PR: https://git.openjdk.java.net/jdk/pull/8538 From bpb at openjdk.java.net Wed May 4 16:42:08 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 4 May 2022 16:42:08 GMT Subject: Integrated: 8286138: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Wed, 4 May 2022 16:32:09 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8538 From dcubed at openjdk.java.net Wed May 4 16:42:08 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 4 May 2022 16:42:08 GMT Subject: Integrated: 8286138: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Wed, 4 May 2022 16:33:43 GMT, Brian Burkhalter wrote: >> A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64. > > Marked as reviewed by bpb (Reviewer). @bplb - Thanks for the lightning fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8538 From dcubed at openjdk.java.net Wed May 4 16:42:08 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 4 May 2022 16:42:08 GMT Subject: Integrated: 8286138: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Wed, 4 May 2022 16:32:09 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64. This pull request has now been integrated. Changeset: 497a94fe Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/497a94fead145788af6f196d2c7166efc46a9e9e Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8286138: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/8538 From prr at openjdk.java.net Wed May 4 16:54:41 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 4 May 2022 16:54:41 GMT Subject: Integrated: 8286138: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 In-Reply-To: References: Message-ID: <3WoULE1UGIQ61UyWkiYyBONDsVjO6qHvAdAlkjiSO7Q=.73befc00-a227-423e-981a-1b65e9529d0f@github.com> On Wed, 4 May 2022 16:32:09 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64. I didn't see the need to PL this. There's a fix under review ! ------------- PR: https://git.openjdk.java.net/jdk/pull/8538 From iklam at openjdk.java.net Wed May 4 18:02:22 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 4 May 2022 18:02:22 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v6] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 13:34:55 GMT, Jie Fu wrote: >> Hi all, >> >> `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. >> We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. >> >> From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). >> So `FillerObject_klass` should be loaded as soon as possible. >> >> >> (gdb) bt >> #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 >> #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 >> #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 >> #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 >> #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 >> #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 >> #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 >> #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 >> #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 >> #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 >> #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 >> #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 >> #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 >> #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 >> #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 >> #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 >> #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 >> >> >> .... >> >> >> #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 >> >> >> #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 >> #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 >> #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 >> #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 >> #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 >> #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 >> #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 >> #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 >> >> >> The fix just loads `FillerObject` after `Object_klass`. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments If we decide to go with the latest implementation, the bug title should be updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From dcubed at openjdk.java.net Wed May 4 18:17:17 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 4 May 2022 18:17:17 GMT Subject: Integrated: 8286138: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Wed, 4 May 2022 16:32:09 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64. This would be why I pinged in https://github.com/openjdk/jdk/pull/8380 this morning. That PR has been under review for more than a week and it wasn't clear to me from the comments that it was going to reach resolution soon. So.... I pinged @prrace and @prsadhuk in that PR and then waited a couple of hours before I created a ProblemListing PR. It should very easy to to merge in the ProblemListing changeset and then UnProblemList the test in https://github.com/openjdk/jdk/pull/8380. ------------- PR: https://git.openjdk.java.net/jdk/pull/8538 From ccheung at openjdk.java.net Wed May 4 18:30:02 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 4 May 2022 18:30:02 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file from JUnit Message-ID: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> Please review this change for an additional check before archiving a lambda proxy class. If the nest host of an lambda proxy class cannot be verified during dump time due to its major version is < JDK_6 (50), the lambda proxy class should not be archived. This avoids accessing a null nest host during runtime while loading the lambda proxy class from the CDS archive. Passed the test in the bug report. Passed CI tiers 1 - 4 testing (including the new tests). ------------- Commit messages: - 8285914: AppCDS crash when using shared archive with old class file from JUnit Changes: https://git.openjdk.java.net/jdk/pull/8540/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8540&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285914 Stats: 220 lines in 5 files changed: 218 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8540.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8540/head:pull/8540 PR: https://git.openjdk.java.net/jdk/pull/8540 From duke at openjdk.java.net Wed May 4 18:35:52 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 4 May 2022 18:35:52 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL Message-ID: This PR cleans up some minor annoyances in the UL code. Note that the change from `LogImpl` to `LogTagSet` is equivalent, we're essentially inlining the calls that `LogImpl` would have made. This simplifies understanding ("why do we need `LogImpl` here?" was my question, answer: We don't!)' ------------- Commit messages: - Use uniform initialization syntax in top level - Use LogTagSet directly in LogMessage - Use LogTagSetMapping in LogTargetImpl instead of LogImpl - Declare pointers to LogTagSet const - Fix comments in LogStream Changes: https://git.openjdk.java.net/jdk/pull/8541/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8541&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286117 Stats: 18 lines in 5 files changed: 0 ins; 3 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8541.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8541/head:pull/8541 PR: https://git.openjdk.java.net/jdk/pull/8541 From ioi.lam at oracle.com Wed May 4 19:13:02 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 4 May 2022 12:13:02 -0700 Subject: SIGBUS on linux in perfMemory_init In-Reply-To: References: Message-ID: On 5/3/2022 8:41 AM, Nico Williams wrote: > On Fri, Apr 29, 2022 at 09:44:00AM -0400, Vitaly Davidovich wrote: >> As for possible solutions, would it be possible to use the global PID >> instead of the namespaced PID to "regain" the uniqueness invariant of the >> PID? Also, might it make sense to flock() the file to prevent another >> process from mucking with it? > My unsolicited, outsider opinions: > > - Sharing /tmp across containers is a Bad Idea (tm). > > - Sharing /tmp across related containers (in a pod) is not _as_ bad an > idea. > > (It might be a way to implement some cross-container communications, > though it would be better to have an explicit mechanism for that > rather than the rather-generic /tmp.) > > - Containerizing apps that *do* communicate over /tmp might be one > reason one might configure a shared /tmp in a pod. > > Some support for such a configuration might be needed. > > (Alternatively, pods that share /tmp should also share a PID > namespace.) > > - Since there is an option to not have an mmap'ed hsperf file, it might > be nice to have an option to use the global PID for naming hsperf > files. Or, better, implement an automatic mechanism for detecting > conflict and switching to global PID for naming hsperf files (or > switching to anonymous hsperf mmaps). I think using the PID in the serviceability files is problematic with containers. Currently, the files use the PID returned by getpid(2), it's the PID within the container's namespace. Example: if a process has the host PID of 3456 and namespaced PID of 1, the files are accessible by the host as: ???? /proc/3456/root/tmp/hsperfdata_user/1 ???? /proc/3456/root/tmp/.java_pid1 and accessible inside the container as ???? /tmp/hsperfdata_user/1 ???? /tmp/.java_pid1 If you run "jps" on the host, you'd get ??? 3456 MyApp If you run "jps" inside the container, you'd get ??? 1 MyApp if we use some sort of "global PID", we could name the file as /proc/3456/root/tmp/hsperfdata_user/3456 /proc/3456/root/tmp/.java_pid3456 But there are several problems: - The file is created by the MyApp process. AFAIK there's no way for a containerized process to obtain its host PID (i.e., 3456) - "jps" no longer works inside the container, because 3456 is not a valid process in the container. Also, what happens if we use nested containers? A process's ID could be 1, 3456, or 7890, depending on what namespace you are looking at, Which one should we use? ==================================== I think we should understand the requirements. I am guessing they are: - "jps" should report the process IDs of all the JVM processes that are visible to the current user. The PIDs should be in the current namespace. - The user can use a PID returned by "jps" to attach to the process. ==================================== How about this: When a JVM starts up, it creates the hsperfdata with a UUID instead of PID. E.g., ??? /tmp/hsperfdata_user/0da29ace76f76f61 Today, jps reads /proc/*/status to determine the NSpid, so we are doing a lot of processing already. Instead, we should read /proc/*/maps and scan for something with this pattern: ??? 7ffb2536d000-7ffb25375000 rw-s .... /tmp/hsperfdata_user/0da29ace76f76f61 If we can find this pattern, we know we have a JVM process that the current user can attach to. When attaching to this process, we will use this file instead /proc/$PID/root/tmp/.java_pid0da29ace76f76f61 This should work with - shared /tmp across containers - nested containers > - In any case, on systems that have a real flock(2), using flock(2) for > liveness testing is better than kill(2) with signal 0 -- the latter > has false positives, while the former does not [provided O_CLOEXEC is > used]. > > For this reason, and though I am not too sympathetic to the situation > that caused this crash, I believe that it would be better to have > some sort of fix for this problem than to declare it a non-problem > and not-fix it. > > > I would like to expand on Vitaly's mention of flock(2). Using the > global PID would leave the JVM unable to use kill(2) with signal 0 for > liveness detection during hsperf garbage file collection. Using kill(2) > with signal 0 for liveness is not that reliable anyways because of PID > reuse -- it can have false positives. > > A better mechanism for liveness detection would be to have the owning > JVM take an exclusive (LOCK_EX) flock(2) on the hsperf file at startup, > and for hsperf garbage file collection to try (LOCK_NB) to get an > exclusive lock (LOCK_EX) on a candidate hsperf garbage file as a > liveness detection mechanism. > > When using the namespaced PID the kill(2) with signal 0 method of > liveness detection should still be used for backwards-compatibility in, > e.g., jvisualvm. > > Using flock(2) would be less portable than kill(2) with signal 0, but > already there is a bunch of Linux-specific code here looking through > /proc, and Linux does have a real flock(2). > > An adaptive, zero-conf hsperf file naming scheme might use the > namespaced PID if available (i.e., if an exclusive flock(2) could be > obtained on the file), or the global PID if not, with some indication in > the name of the file's name of which kind of PID was used. Nico, Using flock for liveness detection is somewhat off topic. Do you want to create an RFE for it and perhaps start a separate discussion? Thanks - Ioi > Cheers, > > Nico From dholmes at openjdk.java.net Wed May 4 22:49:18 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 4 May 2022 22:49:18 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file from JUnit In-Reply-To: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> Message-ID: On Wed, 4 May 2022 18:20:14 GMT, Calvin Cheung wrote: > Please review this change for an additional check before archiving a lambda proxy class. If the nest host of an lambda proxy class cannot be verified during dump time due to its major version is < JDK_6 (50), the lambda proxy class should not be archived. This avoids accessing a null nest host during runtime while loading the lambda proxy class from the CDS archive. > > Passed the test in the bug report. > > Passed CI tiers 1 - 4 testing (including the new tests). Pardon my ignorance but how can a JDK 6 version classfile have any association with a lambda proxy? Has the lambda proxy been "hand crafted" to refer to an old version "host" class? Is that even legal? There can't be a valid nest-mate relationship here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8540 From dholmes at openjdk.java.net Wed May 4 23:05:16 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 4 May 2022 23:05:16 GMT Subject: RFR: 8286066: FillerObject_klass should be loaded as early as possible [v6] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 13:34:55 GMT, Jie Fu wrote: >> Hi all, >> >> `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. >> We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. >> >> From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). >> So `FillerObject_klass` should be loaded as soon as possible. >> >> >> (gdb) bt >> #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 >> #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 >> #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 >> #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 >> #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 >> #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 >> #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 >> #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 >> #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 >> #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 >> #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 >> #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 >> #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 >> #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 >> #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 >> #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 >> #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 >> >> >> .... >> >> >> #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 >> >> >> #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 >> #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 >> #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 >> #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 >> #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 >> #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 >> #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 >> #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 >> >> >> The fix just loads `FillerObject` after `Object_klass`. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments test/hotspot/jtreg/runtime/cds/appcds/FillerObjectLoadTest.java line 42: > 40: String java_home_dst = CDSTestUtils.getOutputDir() + File.separator + "moved_jdk"; > 41: CDSTestUtils.clone(new File(java_home_src), new File(java_home_dst)); > 42: String dstJava = java_home_dst + File.separator + "bin" + File.separator + "java"; Can't you avoid all this by specifying the name of the shared archive file for the dump? ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From dholmes at openjdk.java.net Wed May 4 23:18:30 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 4 May 2022 23:18:30 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL In-Reply-To: References: Message-ID: On Wed, 4 May 2022 18:29:22 GMT, Johan Sj?l?n wrote: > This PR cleans up some minor annoyances in the UL code. > > Note that the change from `LogImpl` to `LogTagSet` is equivalent, we're essentially inlining the calls that `LogImpl` would have made. This simplifies understanding ("why do we need `LogImpl` here?" was my question, answer: We don't!)' src/hotspot/share/logging/logMessage.hpp line 65: > 63: class LogMessageImpl : public LogMessageBuffer { > 64: private: > 65: LogImpl _log; I'm not very familiar with the detailed internals here, but don't we need this to capture the Log "state" and ensure it is always the same when used for this LogMessageImpl - otherwise can't `LogTagSetMapping::tagset()` change what it returns over time? src/hotspot/share/logging/logTagSet.hpp line 168: > 166: // tagset. This _tagset contains the configuration for those tags. > 167: template > 168: LogTagSet LogTagSetMapping::_tagset{&LogPrefix::prefix, T0, T1, T2, T3, T4}; Is this a specialized initialization syntax? I'm not familiar with its significance. ------------- PR: https://git.openjdk.java.net/jdk/pull/8541 From jiefu at openjdk.java.net Wed May 4 23:55:00 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 4 May 2022 23:55:00 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v7] In-Reply-To: References: Message-ID: > Hi all, > > `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. > We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. > > From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). > So `FillerObject_klass` should be loaded as soon as possible. > > > (gdb) bt > #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 > #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 > #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 > #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 > #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 > #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 > #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 > #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 > #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 > #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 > #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 > #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 > #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 > #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 > #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 > #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 > #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 > > > .... > > > #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 > > > #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 > #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 > #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 > #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 > #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 > #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 > #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 > #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 > > > The fix just loads `FillerObject` after `Object_klass`. > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Specifying the name of the shared archive file for the dump ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8519/files - new: https://git.openjdk.java.net/jdk/pull/8519/files/c05b1338..45e16735 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=05-06 Stats: 18 lines in 1 file changed: 2 ins; 7 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8519/head:pull/8519 PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Wed May 4 23:55:00 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 4 May 2022 23:55:00 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v6] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 17:58:36 GMT, Ioi Lam wrote: > If we decide to go with the latest implementation, the bug title should be updated. Updated. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Wed May 4 23:55:01 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 4 May 2022 23:55:01 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v6] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 23:01:45 GMT, David Holmes wrote: > Can't you avoid all this by specifying the name of the shared archive file for the dump? It works! Updated. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Wed May 4 23:57:11 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 4 May 2022 23:57:11 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v8] In-Reply-To: References: Message-ID: > Hi all, > > `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. > We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. > > From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). > So `FillerObject_klass` should be loaded as soon as possible. > > > (gdb) bt > #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 > #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 > #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 > #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 > #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 > #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 > #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 > #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 > #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 > #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 > #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 > #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 > #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 > #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 > #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 > #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 > #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 > > > .... > > > #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 > > > #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 > #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 > #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 > #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 > #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 > #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 > #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 > #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 > > > The fix just loads `FillerObject` after `Object_klass`. > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Update the test summary ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8519/files - new: https://git.openjdk.java.net/jdk/pull/8519/files/45e16735..390b1784 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8519/head:pull/8519 PR: https://git.openjdk.java.net/jdk/pull/8519 From iklam at openjdk.java.net Thu May 5 00:09:28 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 5 May 2022 00:09:28 GMT Subject: RFR: 8283606: Tests may fail with zh locale on MacOS [v4] In-Reply-To: <21e-mJzcWAauSAEVbW0Icg2ELKkADKi1IgpcshgObfQ=.c65f5570-de08-444f-b6a4-e37509862267@github.com> References: <21e-mJzcWAauSAEVbW0Icg2ELKkADKi1IgpcshgObfQ=.c65f5570-de08-444f-b6a4-e37509862267@github.com> Message-ID: <1WS-PIPcRSnYI2AjzykxCMZhFLpyInWL1JGmMTZjhuY=.88e75659-952a-4313-837b-6770dbe994ca@github.com> On Mon, 28 Mar 2022 17:00:39 GMT, Vikey Chen wrote: >> From the test doc of openjdk https://openjdk.java.net/groups/build/doc/testing.html >>> If your locale is non-US, some tests are likely to fail. To work around this you can set the locale to US. On Unix platforms simply setting LANG="en_US" in the environment before running tests should work. On Windows or MacOS, setting JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US" helps for most, but not all test cases. >> >> However, on MacOS 12.1, running `make test-tier1 JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"` command for tier-1 test, some tests still fail, including the following in tier-1.The tests expects output messages in English, but Chinese message are still produced. >> >> test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java >> test/langtools/jdk/javadoc/tool/6964914/TestStdDoclet.java >> test/langtools/jdk/javadoc/tool/6964914/TestUserDoclet.java >> test/langtools/jdk/javadoc/tool/EnsureNewOldDoclet.java >> test/langtools/jdk/javadoc/tool/testLocaleOption/TestLocaleOption.java >> test/langtools/tools/javac/T8132562/ClassPathWithDoubleQuotesTest.java >> test/langtools/tools/javac/options/smokeTests/OptionSmokeTest.java >> test/langtools/tools/javac/platform/PlatformProviderTest.java >> test/langtools/tools/jdeps/MultiReleaseJar.java > > Vikey Chen has updated the pull request incrementally with one additional commit since the last revision: > > Locale.ENGLISH to Locale.US I tested the patch on latest JDK repo and passed tiers 1 and 2. ------------- PR: https://git.openjdk.java.net/jdk/pull/7924 From duke at openjdk.java.net Thu May 5 00:09:30 2022 From: duke at openjdk.java.net (Vikey Chen) Date: Thu, 5 May 2022 00:09:30 GMT Subject: Integrated: 8283606: Tests may fail with zh locale on MacOS In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 15:34:43 GMT, Vikey Chen wrote: > From the test doc of openjdk https://openjdk.java.net/groups/build/doc/testing.html >> If your locale is non-US, some tests are likely to fail. To work around this you can set the locale to US. On Unix platforms simply setting LANG="en_US" in the environment before running tests should work. On Windows or MacOS, setting JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US" helps for most, but not all test cases. > > However, on MacOS 12.1, running `make test-tier1 JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"` command for tier-1 test, some tests still fail, including the following in tier-1.The tests expects output messages in English, but Chinese message are still produced. > > test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java > test/langtools/jdk/javadoc/tool/6964914/TestStdDoclet.java > test/langtools/jdk/javadoc/tool/6964914/TestUserDoclet.java > test/langtools/jdk/javadoc/tool/EnsureNewOldDoclet.java > test/langtools/jdk/javadoc/tool/testLocaleOption/TestLocaleOption.java > test/langtools/tools/javac/T8132562/ClassPathWithDoubleQuotesTest.java > test/langtools/tools/javac/options/smokeTests/OptionSmokeTest.java > test/langtools/tools/javac/platform/PlatformProviderTest.java > test/langtools/tools/jdeps/MultiReleaseJar.java This pull request has now been integrated. Changeset: 7d545084 Author: Vikey Chen Committer: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/7d545084f45af44386cb38172fd783f889a8c4e7 Stats: 37 lines in 9 files changed: 14 ins; 0 del; 23 mod 8283606: Tests may fail with zh locale on MacOS Reviewed-by: iklam, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/7924 From duke at openjdk.java.net Thu May 5 01:19:22 2022 From: duke at openjdk.java.net (Vikey Chen) Date: Thu, 5 May 2022 01:19:22 GMT Subject: RFR: 8283606: Tests may fail with zh locale on MacOS [v4] In-Reply-To: <21e-mJzcWAauSAEVbW0Icg2ELKkADKi1IgpcshgObfQ=.c65f5570-de08-444f-b6a4-e37509862267@github.com> References: <21e-mJzcWAauSAEVbW0Icg2ELKkADKi1IgpcshgObfQ=.c65f5570-de08-444f-b6a4-e37509862267@github.com> Message-ID: On Mon, 28 Mar 2022 17:00:39 GMT, Vikey Chen wrote: >> From the test doc of openjdk https://openjdk.java.net/groups/build/doc/testing.html >>> If your locale is non-US, some tests are likely to fail. To work around this you can set the locale to US. On Unix platforms simply setting LANG="en_US" in the environment before running tests should work. On Windows or MacOS, setting JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US" helps for most, but not all test cases. >> >> However, on MacOS 12.1, running `make test-tier1 JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"` command for tier-1 test, some tests still fail, including the following in tier-1.The tests expects output messages in English, but Chinese message are still produced. >> >> test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java >> test/langtools/jdk/javadoc/tool/6964914/TestStdDoclet.java >> test/langtools/jdk/javadoc/tool/6964914/TestUserDoclet.java >> test/langtools/jdk/javadoc/tool/EnsureNewOldDoclet.java >> test/langtools/jdk/javadoc/tool/testLocaleOption/TestLocaleOption.java >> test/langtools/tools/javac/T8132562/ClassPathWithDoubleQuotesTest.java >> test/langtools/tools/javac/options/smokeTests/OptionSmokeTest.java >> test/langtools/tools/javac/platform/PlatformProviderTest.java >> test/langtools/tools/jdeps/MultiReleaseJar.java > > Vikey Chen has updated the pull request incrementally with one additional commit since the last revision: > > Locale.ENGLISH to Locale.US Thanks Ioi and Roger. ------------- PR: https://git.openjdk.java.net/jdk/pull/7924 From dholmes at openjdk.java.net Thu May 5 01:36:34 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 5 May 2022 01:36:34 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v8] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 23:57:11 GMT, Jie Fu wrote: >> Hi all, >> >> `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. >> We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. >> >> From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). >> So `FillerObject_klass` should be loaded as soon as possible. >> >> >> (gdb) bt >> #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 >> #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 >> #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 >> #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 >> #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 >> #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 >> #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 >> #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 >> #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 >> #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 >> #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 >> #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 >> #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 >> #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 >> #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 >> #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 >> #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 >> >> >> .... >> >> >> #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 >> >> >> #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 >> #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 >> #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 >> #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 >> #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 >> #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 >> #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 >> #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 >> >> >> The fix just loads `FillerObject` after `Object_klass`. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Update the test summary test/hotspot/jtreg/runtime/cds/appcds/FillerObjectLoadTest.java line 41: > 39: "-XX:+IgnoreUnrecognizedVMOptions", "-XX:-UseCompressedClassPointers", > 40: "-XX:+UnlockExperimentalVMOptions", "-XX:+UseEpsilonGC", "-Xshare:dump", > 41: "-XX:SharedArchiveFile=./hello.jsa"); Use ` TestCommon.getCurrentArchiveName()` to get a unique name to use. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From dholmes at openjdk.java.net Thu May 5 01:36:36 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 5 May 2022 01:36:36 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v8] In-Reply-To: References: Message-ID: <-nRuScWtg5pJmi34iJQo-GWcTS2FgIoXcwiv8GYeqKo=.450a81ff-100f-4c06-8c81-636d2f758156@github.com> On Thu, 5 May 2022 01:32:53 GMT, David Holmes wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Update the test summary > > test/hotspot/jtreg/runtime/cds/appcds/FillerObjectLoadTest.java line 41: > >> 39: "-XX:+IgnoreUnrecognizedVMOptions", "-XX:-UseCompressedClassPointers", >> 40: "-XX:+UnlockExperimentalVMOptions", "-XX:+UseEpsilonGC", "-Xshare:dump", >> 41: "-XX:SharedArchiveFile=./hello.jsa"); > > Use ` TestCommon.getCurrentArchiveName()` to get a unique name to use. Actually that might be overkill for this simple case ... I wonder if @iklam could comment? hello.jsa is a bit of a weird name to use though :) ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Thu May 5 02:04:18 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 5 May 2022 02:04:18 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v8] In-Reply-To: <-nRuScWtg5pJmi34iJQo-GWcTS2FgIoXcwiv8GYeqKo=.450a81ff-100f-4c06-8c81-636d2f758156@github.com> References: <-nRuScWtg5pJmi34iJQo-GWcTS2FgIoXcwiv8GYeqKo=.450a81ff-100f-4c06-8c81-636d2f758156@github.com> Message-ID: On Thu, 5 May 2022 01:34:22 GMT, David Holmes wrote: >> test/hotspot/jtreg/runtime/cds/appcds/FillerObjectLoadTest.java line 41: >> >>> 39: "-XX:+IgnoreUnrecognizedVMOptions", "-XX:-UseCompressedClassPointers", >>> 40: "-XX:+UnlockExperimentalVMOptions", "-XX:+UseEpsilonGC", "-Xshare:dump", >>> 41: "-XX:SharedArchiveFile=./hello.jsa"); >> >> Use ` TestCommon.getCurrentArchiveName()` to get a unique name to use. > > Actually that might be overkill for this simple case ... I wonder if @iklam could comment? > > hello.jsa is a bit of a weird name to use though :) > Use ` TestCommon.getCurrentArchiveName()` to get a unique name to use. Hi @dholmes-ora , I didn't get the point why we need to get a unique name. What's the problem if we always use the same name? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From dholmes at openjdk.java.net Thu May 5 02:38:26 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 5 May 2022 02:38:26 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v8] In-Reply-To: References: <-nRuScWtg5pJmi34iJQo-GWcTS2FgIoXcwiv8GYeqKo=.450a81ff-100f-4c06-8c81-636d2f758156@github.com> Message-ID: On Thu, 5 May 2022 02:00:29 GMT, Jie Fu wrote: >> Actually that might be overkill for this simple case ... I wonder if @iklam could comment? >> >> hello.jsa is a bit of a weird name to use though :) > >> Use ` TestCommon.getCurrentArchiveName()` to get a unique name to use. > > Hi @dholmes-ora , I didn't get the point why we need to get a unique name. > What's the problem if we always use the same name? > Thanks. We had issues in the past with tests running concurrently IIRC . I'm not sure if this is still an issue if the test working directory is already unique. @iklam should remember the details. We put in a lot of support code to make sure things always worked smoothly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From iklam at openjdk.java.net Thu May 5 02:38:27 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 5 May 2022 02:38:27 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v8] In-Reply-To: References: <-nRuScWtg5pJmi34iJQo-GWcTS2FgIoXcwiv8GYeqKo=.450a81ff-100f-4c06-8c81-636d2f758156@github.com> Message-ID: <-9zdv8p18osU6X_9wWikUv11ViAfknUctaeTuoBEyIc=.f591c9d9-c958-452d-b365-1a0fc53d5054@github.com> On Thu, 5 May 2022 02:34:39 GMT, David Holmes wrote: >>> Use ` TestCommon.getCurrentArchiveName()` to get a unique name to use. >> >> Hi @dholmes-ora , I didn't get the point why we need to get a unique name. >> What's the problem if we always use the same name? >> Thanks. > > We had issues in the past with tests running concurrently IIRC . I'm not sure if this is still an issue if the test working directory is already unique. @iklam should remember the details. We put in a lot of support code to make sure things always worked smoothly. We had problems on Windows in the past. If two tests generate an archive with the same name, after the first test finishes, jtreg deletes the first version of this file. However, Windows virus scanners will keep the file alive for a little longer. When the second tests tries to create the file again, it gets a file permission error. This would lead to infrequent random failures in the CDS tests. That's the reason we use `TestCommon.getCurrentArchiveName()` in the CDS tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From iklam at openjdk.java.net Thu May 5 02:46:21 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 5 May 2022 02:46:21 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v8] In-Reply-To: <-9zdv8p18osU6X_9wWikUv11ViAfknUctaeTuoBEyIc=.f591c9d9-c958-452d-b365-1a0fc53d5054@github.com> References: <-nRuScWtg5pJmi34iJQo-GWcTS2FgIoXcwiv8GYeqKo=.450a81ff-100f-4c06-8c81-636d2f758156@github.com> <-9zdv8p18osU6X_9wWikUv11ViAfknUctaeTuoBEyIc=.f591c9d9-c958-452d-b365-1a0fc53d5054@github.com> Message-ID: On Thu, 5 May 2022 02:34:41 GMT, Ioi Lam wrote: >> We had issues in the past with tests running concurrently IIRC . I'm not sure if this is still an issue if the test working directory is already unique. @iklam should remember the details. We put in a lot of support code to make sure things always worked smoothly. > > We had problems on Windows in the past. If two tests generate an archive with the same name, after the first test finishes, jtreg deletes the first version of this file. However, Windows virus scanners will keep the file alive for a little longer. When the second tests tries to create the file again, it gets a file permission error. This would lead to infrequent random failures in the CDS tests. > > That's the reason we use `TestCommon.getCurrentArchiveName()` in the CDS tests. > We had issues in the past with tests running concurrently IIRC . I'm not sure if this is still an issue if the test working directory is already unique. The archive file is generated in the test's "working scratch" directory, which is reused. For example, if you have 3 test cases and a jtreg concurrency setting of 2: `0/scratch/` could be used twice whereas `1/scratch/` is used once. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Thu May 5 03:33:16 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 5 May 2022 03:33:16 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v9] In-Reply-To: References: Message-ID: > Hi all, > > `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. > We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. > > From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). > So `FillerObject_klass` should be loaded as soon as possible. > > > (gdb) bt > #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 > #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 > #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 > #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 > #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 > #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 > #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 > #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 > #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 > #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 > #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 > #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 > #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 > #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 > #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 > #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 > #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 > > > .... > > > #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 > > > #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 > #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 > #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 > #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 > #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 > #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 > #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 > #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 > > > The fix just loads `FillerObject` after `Object_klass`. > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Test with unique jsa name ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8519/files - new: https://git.openjdk.java.net/jdk/pull/8519/files/390b1784..81819cd0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=07-08 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8519/head:pull/8519 PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Thu May 5 03:33:16 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 5 May 2022 03:33:16 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v8] In-Reply-To: References: <-nRuScWtg5pJmi34iJQo-GWcTS2FgIoXcwiv8GYeqKo=.450a81ff-100f-4c06-8c81-636d2f758156@github.com> <-9zdv8p18osU6X_9wWikUv11ViAfknUctaeTuoBEyIc=.f591c9d9-c958-452d-b365-1a0fc53d5054@github.com> Message-ID: <9If4tLlpqoDJEo2LiWQm8RNS6mIA5rSr_7V-cgA61ck=.157a4775-88f2-4907-aba7-5491e5c5ea52@github.com> On Thu, 5 May 2022 02:42:46 GMT, Ioi Lam wrote: >> We had problems on Windows in the past. If two tests generate an archive with the same name, after the first test finishes, jtreg deletes the first version of this file. However, Windows virus scanners will keep the file alive for a little longer. When the second tests tries to create the file again, it gets a file permission error. This would lead to infrequent random failures in the CDS tests. >> >> That's the reason we use `TestCommon.getCurrentArchiveName()` in the CDS tests. > >> We had issues in the past with tests running concurrently IIRC . I'm not sure if this is still an issue if the test working directory is already unique. > > The archive file is generated in the test's "working scratch" directory, which is reused. For example, if you have 3 test cases and a jtreg concurrency setting of 2: `0/scratch/` could be used twice whereas `1/scratch/` is used once. > We had problems on Windows in the past. If two tests generate an archive with the same name, after the first test finishes, jtreg deletes the first version of this file. However, Windows virus scanners will keep the file alive for a little longer. When the second tests tries to create the file again, it gets a file permission error. This would lead to infrequent random failures in the CDS tests. > > That's the reason we use `TestCommon.getCurrentArchiveName()` in the CDS tests. Thanks @iklam and @dholmes-ora for your kind explanation. Updated. `TestCommon.getCurrentArchiveName()` returns `null` so I use `TestCommon.getNewArchiveName()` instead. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From ccheung at openjdk.java.net Thu May 5 04:44:17 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 5 May 2022 04:44:17 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file from JUnit In-Reply-To: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> Message-ID: <7rArGa5hOfhE6wsWg57himYDwX2Cfr5pasEKziR6lcY=.3e4be933-990b-4d3b-8aef-dadea1fc8b4b@github.com> On Wed, 4 May 2022 18:20:14 GMT, Calvin Cheung wrote: > Please review this change for an additional check before archiving a lambda proxy class. If the nest host of an lambda proxy class cannot be verified during dump time due to its major version is < JDK_6 (50), the lambda proxy class should not be archived. This avoids accessing a null nest host during runtime while loading the lambda proxy class from the CDS archive. > > Passed the test in the bug report. > > Passed CI tiers 1 - 4 testing (including the new tests). Hi David, The `ChildOldInf` class of the test case has an inner class `InnerChild`. A lambda proxy class will be generated if the `doTest` method is called. The nest host of the lambda proxy class is `ChildOldInf` which extends an old interface `OldInf`. So the nest host is considered old. The test case is just a simplified version of the test in the bug report. The `ChildOldInf` corresponds to the `JsaCrash` in the bug report test case; the `ChildOldInf$InnerChild` corresponds to the `JsaCrash$Builder`. `public class JsaCrash implements TestRule` `TestRule` is an old class. Thanks, Calvin ------------- PR: https://git.openjdk.java.net/jdk/pull/8540 From dholmes at openjdk.java.net Thu May 5 04:59:23 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 5 May 2022 04:59:23 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file from JUnit In-Reply-To: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> Message-ID: On Wed, 4 May 2022 18:20:14 GMT, Calvin Cheung wrote: > Please review this change for an additional check before archiving a lambda proxy class. If the nest host of an lambda proxy class cannot be verified during dump time due to its major version is < JDK_6 (50), the lambda proxy class should not be archived. This avoids accessing a null nest host during runtime while loading the lambda proxy class from the CDS archive. > > Passed the test in the bug report. > > Passed CI tiers 1 - 4 testing (including the new tests). Thanks for the explanation Calvin, so it is not the nest-host that is old, but an interface implemented by the nest-host. The old interface prevents the nest-host from being archived and so the lambda-proxy also should not (can not) be archived. So this is really just a general constraint on class archiving: if a class A has a nest-host B, and B can not be archived, then A can not be archived. Is that correct? Or is there some reason this only affects lambda-proxy classes? ------------- PR: https://git.openjdk.java.net/jdk/pull/8540 From iklam at openjdk.java.net Thu May 5 05:28:16 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 5 May 2022 05:28:16 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file from JUnit In-Reply-To: <7rArGa5hOfhE6wsWg57himYDwX2Cfr5pasEKziR6lcY=.3e4be933-990b-4d3b-8aef-dadea1fc8b4b@github.com> References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> <7rArGa5hOfhE6wsWg57himYDwX2Cfr5pasEKziR6lcY=.3e4be933-990b-4d3b-8aef-dadea1fc8b4b@github.com> Message-ID: On Thu, 5 May 2022 04:41:04 GMT, Calvin Cheung wrote: > Hi David, > > The `ChildOldInf` class of the test case has an inner class `InnerChild`. A lambda proxy class will be generated if the `doTest` method is called. The nest host of the lambda proxy class is `ChildOldInf` which extends an old interface `OldInf`. So the nest host is considered old. The test case is just a simplified version of the test in the bug report. > > The `ChildOldInf` corresponds to the `JsaCrash` in the bug report test case; the `ChildOldInf$InnerChild` corresponds to the `JsaCrash$Builder`. > > `public class JsaCrash implements TestRule` > > `TestRule` is an old class. > > Thanks, Calvin I think the PR description should be updated. The nest host `JsaCrash` itself is not an old class. Rather, it implements an interface `TestRule` which is an old class. Due to limitations in CDS (*1), `JsaCrash` cannot be archived, so it will be filtered by `SystemDictionaryShared::check_for_exclusion_impl()`. As a result, Lambda proxy classes of `JsaCrash` cannot be archived, because such classes contain a direct pointer reference to `JsaCrash`, and such pointers will be set to NULL during CDS dump. There are actually multiple reasons that a class could be excluded from the archive. `!nest_host->can_be_verified_at_dumptime()` is just one of them. To check for all cases, instead of adding the check in `SystemDictionaryShared::add_lambda_proxy_class()`, I think it's better to add a check like this in `SystemDictionaryShared::check_for_exclusion_impl()`: if (is_registered_lambda_proxy_class(k)) { DumpTimeClassInfo* info = _dumptime_table->get(k); assert(info != NULL, "sanity"); if (!check_for_exclusion(info->nest_host(), NULL) { return true; } (*1) `TestRule` is verified by the old verifier, whose results cannot be saved in CDS. As a result, `TestRule` (and `JsaCrash`) must be re-verified at runtime. However, verification runs during class linking. If we want to re-verify `JsaCrash` at runtime, we must revert it back to the `loaded` state, which is non trivial because we need to undo the results of bytecode rewriting. ------------- PR: https://git.openjdk.java.net/jdk/pull/8540 From iklam at openjdk.java.net Thu May 5 05:31:34 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 5 May 2022 05:31:34 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v9] In-Reply-To: References: Message-ID: <7T_bLnpVizP_dvOfu2DVxbm_akq7e3I3iah1xtqDOvI=.9a953fe5-2797-46ab-980c-9a601c1355da@github.com> On Thu, 5 May 2022 03:33:16 GMT, Jie Fu wrote: >> Hi all, >> >> `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. >> We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. >> >> From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). >> So `FillerObject_klass` should be loaded as soon as possible. >> >> >> (gdb) bt >> #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 >> #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 >> #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 >> #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 >> #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 >> #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 >> #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 >> #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 >> #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 >> #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 >> #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 >> #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 >> #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 >> #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 >> #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 >> #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 >> #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 >> >> >> .... >> >> >> #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 >> >> >> #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 >> #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 >> #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 >> #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 >> #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 >> #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 >> #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 >> #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 >> >> >> The fix just loads `FillerObject` after `Object_klass`. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Test with unique jsa name LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8519 From iklam at openjdk.java.net Thu May 5 05:59:19 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 5 May 2022 05:59:19 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL In-Reply-To: References: Message-ID: On Wed, 4 May 2022 18:29:22 GMT, Johan Sj?l?n wrote: > This PR cleans up some minor annoyances in the UL code. > > Note that the change from `LogImpl` to `LogTagSet` is equivalent, we're essentially inlining the calls that `LogImpl` would have made. This simplifies understanding ("why do we need `LogImpl` here?" was my question, answer: We don't!)' src/hotspot/share/logging/log.hpp line 184: > 182: > 183: static bool is_enabled() { > 184: return LogTagSetMapping::tagset().is_level(level); This removes an abstraction and makes the code more verbose. I don't see the value of doing this, especially when LogImpl is used by macros like `log_info()`, `log_debug()`, etc, which are the primary interface to UL. With this change, people who wonder how `log_info()` works would need to understand more implementation details than before. ------------- PR: https://git.openjdk.java.net/jdk/pull/8541 From rehn at openjdk.java.net Thu May 5 06:24:18 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 5 May 2022 06:24:18 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL In-Reply-To: References: Message-ID: On Thu, 5 May 2022 05:56:15 GMT, Ioi Lam wrote: >> This PR cleans up some minor annoyances in the UL code. >> >> Note that the change from `LogImpl` to `LogTagSet` is equivalent, we're essentially inlining the calls that `LogImpl` would have made. This simplifies understanding ("why do we need `LogImpl` here?" was my question, answer: We don't!)' > > src/hotspot/share/logging/log.hpp line 184: > >> 182: >> 183: static bool is_enabled() { >> 184: return LogTagSetMapping::tagset().is_level(level); > > This removes an abstraction and makes the code more verbose. I don't see the value of doing this, especially when LogImpl is used by macros like `log_info()`, `log_debug()`, etc, which are the primary interface to UL. With this change, people who wonder how `log_info()` works would need to understand more implementation details than before. I think the point was to make the code more explicit/verbose since this is the implementation (thus removing abstraction inside the implementation), thus making it easier to understand what it does. I'm fine with as is or with this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/8541 From duke at openjdk.java.net Thu May 5 06:46:20 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Thu, 5 May 2022 06:46:20 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL In-Reply-To: References: Message-ID: On Thu, 5 May 2022 05:56:15 GMT, Ioi Lam wrote: >> This PR cleans up some minor annoyances in the UL code. >> >> Note that the change from `LogImpl` to `LogTagSet` is equivalent, we're essentially inlining the calls that `LogImpl` would have made. This simplifies understanding ("why do we need `LogImpl` here?" was my question, answer: We don't!)' > > src/hotspot/share/logging/log.hpp line 184: > >> 182: >> 183: static bool is_enabled() { >> 184: return LogTagSetMapping::tagset().is_level(level); > > This removes an abstraction and makes the code more verbose. I don't see the value of doing this, especially when LogImpl is used by macros like `log_info()`, `log_debug()`, etc, which are the primary interface to UL. With this change, people who wonder how `log_info()` works would need to understand more implementation details than before. Hi @iklam, `LogImpl` is still used in `log_X()` macros! `LogTarget` macro uses `LogTargetImpl`, which this changes. We're not lowering the level of abstraction, we're getting rid of an unneeded one that, to me, made the code even more difficult to understand. Let's read the code together, because this was confusing to me when I saw it. LogImpl::is_level(level) ~> // log.hpp:186:LogImplTarget LogTagSetMapping::tagset().is_level(level) ~> // log.hpp:124:LogImpl _output_list.is_level(level); // logTagSet.hpp:126:LogTagSet When you read `log.hpp:186` you're probably thinking "OK, `LogTargetImpl` *needs* `LogImpl`, which makes sense!" but then you follow the code and LogImpl doesn't provide any extra state for `LogTagSet`. So maybe then you think that `LogImpl` provides some extra state when constructed (nope, empty constructor, LogTagSetMapping constructs LogTagSet for us statically). At about that point I made the conclusion that this indirection is unneeded and should be removed :-). PS. Accidentally posted this from my *other* Github account, so sorry for the double notification e-mail :-). ------------- PR: https://git.openjdk.java.net/jdk/pull/8541 From duke at openjdk.java.net Thu May 5 07:01:19 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Thu, 5 May 2022 07:01:19 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL In-Reply-To: References: Message-ID: On Wed, 4 May 2022 23:11:52 GMT, David Holmes wrote: >> This PR cleans up some minor annoyances in the UL code. >> >> Note that the change from `LogImpl` to `LogTagSet` is equivalent, we're essentially inlining the calls that `LogImpl` would have made. This simplifies understanding ("why do we need `LogImpl` here?" was my question, answer: We don't!)' > > src/hotspot/share/logging/logMessage.hpp line 65: > >> 63: class LogMessageImpl : public LogMessageBuffer { >> 64: private: >> 65: LogImpl _log; > > I'm not very familiar with the detailed internals here, but don't we need this to capture the Log "state" and ensure it is always the same when used for this LogMessageImpl - otherwise can't `LogTagSetMapping::tagset()` change what it returns over time? See my comment to Ioi for a more detailed explanation, but in short: No. The template parameters uniquely identify a specific tagset. The tagsets themselves are mutated in place, to accomodate for new outputs and altered decorations, for example. ------------- PR: https://git.openjdk.java.net/jdk/pull/8541 From duke at openjdk.java.net Thu May 5 07:13:31 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Thu, 5 May 2022 07:13:31 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL In-Reply-To: References: Message-ID: On Wed, 4 May 2022 23:13:48 GMT, David Holmes wrote: >> This PR cleans up some minor annoyances in the UL code. >> >> Note that the change from `LogImpl` to `LogTagSet` is equivalent, we're essentially inlining the calls that `LogImpl` would have made. This simplifies understanding ("why do we need `LogImpl` here?" was my question, answer: We don't!)' > > src/hotspot/share/logging/logTagSet.hpp line 168: > >> 166: // tagset. This _tagset contains the configuration for those tags. >> 167: template >> 168: LogTagSet LogTagSetMapping::_tagset{&LogPrefix::prefix, T0, T1, T2, T3, T4}; > > Is this a specialized initialization syntax? I'm not familiar with its significance. This particular change I'm not very attached to, if it doesn't immediately improve the code to you then I suggest we skip it. This syntax is called "uniform initialization" syntax, I believe. Semantically it is *almost* equivalent to using `()` for initialization. Here I am only using it to make it very clear that we're initializing a static field for a specific class. I think it reads easier at the top-level since with parens it's syntactically similar to a strange function declaration. Here's a good link: https://stackoverflow.com/questions/24953658/what-are-the-differences-between-c-like-constructor-and-uniform-initialization Regarding your other comment: This line is what instantiates every single `LogTagSet` which is needed for the logging, and none are created at run time. ------------- PR: https://git.openjdk.java.net/jdk/pull/8541 From tschatzl at openjdk.java.net Thu May 5 07:38:27 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 5 May 2022 07:38:27 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v9] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 03:33:16 GMT, Jie Fu wrote: >> Hi all, >> >> `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. >> We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. >> >> From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). >> So `FillerObject_klass` should be loaded as soon as possible. >> >> >> (gdb) bt >> #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 >> #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 >> #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 >> #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 >> #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 >> #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 >> #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 >> #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 >> #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 >> #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 >> #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 >> #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 >> #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 >> #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 >> #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 >> #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 >> #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 >> >> >> .... >> >> >> #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 >> >> >> #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 >> #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 >> #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 >> #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 >> #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 >> #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 >> #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 >> #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 >> >> >> The fix just loads `FillerObject` after `Object_klass`. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Test with unique jsa name Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/shared/collectedHeap.cpp line 63: > 61: class ClassLoaderData; > 62: > 63: Klass* CollectedHeap::_filler_klass = NULL; Please name this member `_filler_object_klass` to better distinguish it from `_filler_array*`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Thu May 5 08:09:03 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 5 May 2022 08:09:03 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v10] In-Reply-To: References: Message-ID: > Hi all, > > `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. > We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. > > From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). > So `FillerObject_klass` should be loaded as soon as possible. > > > (gdb) bt > #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 > #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 > #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 > #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 > #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 > #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 > #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 > #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 > #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 > #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 > #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 > #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 > #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 > #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 > #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 > #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 > #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 > > > .... > > > #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 > > > #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 > #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 > #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 > #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 > #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 > #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 > #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 > #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 > > > The fix just loads `FillerObject` after `Object_klass`. > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with one additional commit since the last revision: _filler_klass --> _filler_object_klass ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8519/files - new: https://git.openjdk.java.net/jdk/pull/8519/files/81819cd0..618d7e42 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=08-09 Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8519/head:pull/8519 PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Thu May 5 08:09:03 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 5 May 2022 08:09:03 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v9] In-Reply-To: References: Message-ID: <57StlAcRZZYyPoZwsGcWnW6Kv8gYU_B-WN8s-4HhCWo=.fc84e924-d38d-4c44-9d78-c66476327072@github.com> On Thu, 5 May 2022 07:33:54 GMT, Thomas Schatzl wrote: > Please name this member `_filler_object_klass` to better distinguish it from `_filler_array*`. Updated. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From asotona at openjdk.java.net Thu May 5 08:50:21 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Thu, 5 May 2022 08:50:21 GMT Subject: RFR: 8262004: Classpath separator: Man page says semicolon; should be colon on Linux [v2] In-Reply-To: References: Message-ID: > Man file for the java command in JDK, the arguments such as -classpath, --module-path and --upgrade-module-path say "A semicolon (;) separated list of directories" > > Please review this fix correcting the text to "A colon (:) separated list of directories". > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: path separators documented platform-specific way ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8530/files - new: https://git.openjdk.java.net/jdk/pull/8530/files/7a05e4f7..b6dcde54 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8530&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8530&range=00-01 Stats: 19 lines in 1 file changed: 12 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8530/head:pull/8530 PR: https://git.openjdk.java.net/jdk/pull/8530 From tschatzl at openjdk.java.net Thu May 5 09:49:17 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 5 May 2022 09:49:17 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v10] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 08:09:03 GMT, Jie Fu wrote: >> Hi all, >> >> `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. >> We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. >> >> From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). >> So `FillerObject_klass` should be loaded as soon as possible. >> >> >> (gdb) bt >> #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 >> #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 >> #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 >> #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 >> #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 >> #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 >> #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 >> #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 >> #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 >> #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 >> #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 >> #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 >> #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 >> #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 >> #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 >> #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 >> #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 >> >> >> .... >> >> >> #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 >> >> >> #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 >> #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 >> #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 >> #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 >> #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 >> #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 >> #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 >> #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 >> >> >> The fix just loads `FillerObject` after `Object_klass`. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > _filler_klass --> _filler_object_klass Lgtm. Thanks. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8519 From sgehwolf at redhat.com Thu May 5 10:05:38 2022 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 05 May 2022 12:05:38 +0200 Subject: SIGBUS on linux in perfMemory_init In-Reply-To: References: Message-ID: <93c0759e5b829796a4f8d2c00364a00ccd9a62b0.camel@redhat.com> On Wed, 2022-05-04 at 12:13 -0700, Ioi Lam wrote: > ==================================== > > How about this: > > When a JVM starts up, it creates the hsperfdata with a UUID instead of > PID. E.g., > > ???? /tmp/hsperfdata_user/0da29ace76f76f61 > > Today, jps reads /proc/*/status to determine the NSpid, so we are doing > a lot of processing already. Instead, we should read /proc/*/maps and > scan for something with this pattern: > > ???? 7ffb2536d000-7ffb25375000 rw-s .... > /tmp/hsperfdata_user/0da29ace76f76f61 > > If we can find this pattern, we know we have a JVM process that the > current user can attach to. > > When attaching to this process, we will use this file instead > > /proc/$PID/root/tmp/.java_pid0da29ace76f76f61 > > This should work with > > - shared /tmp across containers > - nested containers Wouldn't this break with the work-around Vitaly employed? I.e. using -XX:+PerfDisableSharedMem $ ps ax | grep java 10449 pts/4 Sl+ 0:00 ./build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java -XX:+PerfDisableSharedMem Hello 10744 pts/5 S+ 0:00 grep --color=auto java $ grep hsperf /proc/10449/maps $ jcmd 10449 VM.version 10449: OpenJDK 64-Bit Server VM version 11.0.16-internal+0-adhoc.sgehwolf.jdk11u-dev JDK 11.0.16 $ jcmd -l 10857 jdk.jcmd/sun.tools.jcmd.JCmd -l Basically, by departing from using system identifiers, we need some other way to discover the well known identifier. Thanks, Severin From dholmes at openjdk.java.net Thu May 5 10:56:23 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 5 May 2022 10:56:23 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v10] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 08:09:03 GMT, Jie Fu wrote: >> Hi all, >> >> `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. >> We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. >> >> From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). >> So `FillerObject_klass` should be loaded as soon as possible. >> >> >> (gdb) bt >> #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 >> #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 >> #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 >> #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 >> #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 >> #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 >> #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 >> #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 >> #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 >> #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 >> #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 >> #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 >> #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 >> #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 >> #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 >> #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 >> #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 >> >> >> .... >> >> >> #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 >> >> >> #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 >> #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 >> #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 >> #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 >> #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 >> #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 >> #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 >> #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 >> >> >> The fix just loads `FillerObject` after `Object_klass`. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > _filler_klass --> _filler_object_klass Looks good! But I'd like to test it in our CI before integration please. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8519 From tschatzl at openjdk.java.net Thu May 5 11:15:20 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 5 May 2022 11:15:20 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v10] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 08:09:03 GMT, Jie Fu wrote: >> Hi all, >> >> `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. >> We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. >> >> From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). >> So `FillerObject_klass` should be loaded as soon as possible. >> >> >> (gdb) bt >> #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 >> #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 >> #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 >> #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 >> #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 >> #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 >> #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 >> #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 >> #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 >> #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 >> #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 >> #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 >> #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 >> #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 >> #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 >> #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 >> #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 >> >> >> .... >> >> >> #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 >> >> >> #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 >> #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 >> #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 >> #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 >> #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 >> #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 >> #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 >> #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 >> >> >> The fix just loads `FillerObject` after `Object_klass`. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > _filler_klass --> _filler_object_klass I'll push it through our tier1-3 and report back ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From mdoerr at openjdk.java.net Thu May 5 12:19:19 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 5 May 2022 12:19:19 GMT Subject: RFR: JDK-8285987: executing shell scripts without #! fails on Alpine linux In-Reply-To: References: Message-ID: On Wed, 4 May 2022 12:04:47 GMT, Matthias Baesken wrote: > A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 . > Looks like this is a known issue on musl / Alpine, see also > https://www.openwall.com/lists/musl/2018/03/09/2 > and > https://github.com/scala-steward-org/scala-steward/issues/1374 > (we see it on Alpine 3.15). LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8535 From goetz at openjdk.java.net Thu May 5 12:28:20 2022 From: goetz at openjdk.java.net (Goetz Lindenmaier) Date: Thu, 5 May 2022 12:28:20 GMT Subject: RFR: JDK-8285987: executing shell scripts without #! fails on Alpine linux In-Reply-To: References: Message-ID: On Wed, 4 May 2022 12:04:47 GMT, Matthias Baesken wrote: > A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 . > Looks like this is a known issue on musl / Alpine, see also > https://www.openwall.com/lists/musl/2018/03/09/2 > and > https://github.com/scala-steward-org/scala-steward/issues/1374 > (we see it on Alpine 3.15). Looks good ------------- Marked as reviewed by goetz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8535 From asotona at openjdk.java.net Thu May 5 12:47:01 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Thu, 5 May 2022 12:47:01 GMT Subject: RFR: 8262004: Classpath separator: Man page says semicolon; should be colon on Linux [v3] In-Reply-To: References: Message-ID: > Man file for the java command in JDK, the arguments such as -classpath, --module-path and --upgrade-module-path say "A semicolon (;) separated list of directories" > > Please review this fix correcting the text to "A colon (:) separated list of directories". > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: more generalized text ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8530/files - new: https://git.openjdk.java.net/jdk/pull/8530/files/b6dcde54..737840fd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8530&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8530&range=01-02 Stats: 14 lines in 1 file changed: 0 ins; 6 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8530/head:pull/8530 PR: https://git.openjdk.java.net/jdk/pull/8530 From mbaesken at openjdk.java.net Thu May 5 12:49:19 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 5 May 2022 12:49:19 GMT Subject: RFR: JDK-8285987: executing shell scripts without #! fails on Alpine linux In-Reply-To: References: Message-ID: On Wed, 4 May 2022 12:04:47 GMT, Matthias Baesken wrote: > A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 . > Looks like this is a known issue on musl / Alpine, see also > https://www.openwall.com/lists/musl/2018/03/09/2 > and > https://github.com/scala-steward-org/scala-steward/issues/1374 > (we see it on Alpine 3.15). Hi Martin and Goetz, thanks for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/8535 From mbaesken at openjdk.java.net Thu May 5 12:49:19 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 5 May 2022 12:49:19 GMT Subject: Integrated: JDK-8285987: executing shell scripts without #! fails on Alpine linux In-Reply-To: References: Message-ID: On Wed, 4 May 2022 12:04:47 GMT, Matthias Baesken wrote: > A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 . > Looks like this is a known issue on musl / Alpine, see also > https://www.openwall.com/lists/musl/2018/03/09/2 > and > https://github.com/scala-steward-org/scala-steward/issues/1374 > (we see it on Alpine 3.15). This pull request has now been integrated. Changeset: 9d2f591e Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/9d2f591e6a15dc155a8cc3b18a54456d5f9a3aa7 Stats: 35 lines in 3 files changed: 17 ins; 0 del; 18 mod 8285987: executing shell scripts without #! fails on Alpine linux Reviewed-by: mdoerr, goetz ------------- PR: https://git.openjdk.java.net/jdk/pull/8535 From alanb at openjdk.java.net Thu May 5 13:47:19 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 5 May 2022 13:47:19 GMT Subject: RFR: JDK-8285987: executing shell scripts without #! fails on Alpine linux In-Reply-To: References: Message-ID: On Wed, 4 May 2022 12:04:47 GMT, Matthias Baesken wrote: > A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 . > Looks like this is a known issue on musl / Alpine, see also > https://www.openwall.com/lists/musl/2018/03/09/2 > and > https://github.com/scala-steward-org/scala-steward/issues/1374 > (we see it on Alpine 3.15). test/lib/jdk/test/lib/Platform.java line 192: > 190: } > 191: > 192: public static boolean isMusl() { I think this will need test/lib/TestMutuallyExclusivePlatformPredicates.java to be updated too. ------------- PR: https://git.openjdk.java.net/jdk/pull/8535 From mbaesken at openjdk.java.net Thu May 5 14:19:15 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 5 May 2022 14:19:15 GMT Subject: RFR: JDK-8285987: executing shell scripts without #! fails on Alpine linux In-Reply-To: References: Message-ID: On Thu, 5 May 2022 13:43:30 GMT, Alan Bateman wrote: >> A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 . >> Looks like this is a known issue on musl / Alpine, see also >> https://www.openwall.com/lists/musl/2018/03/09/2 >> and >> https://github.com/scala-steward-org/scala-steward/issues/1374 >> (we see it on Alpine 3.15). > > test/lib/jdk/test/lib/Platform.java line 192: > >> 190: } >> 191: >> 192: public static boolean isMusl() { > > I think this will need test/lib/TestMutuallyExclusivePlatformPredicates.java to be updated too. Hi Alan, thanks for the advice; do you think we can put it into the IGNORED group ? https://github.com/openjdk/jdk/blob/master/test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java#L53 ------------- PR: https://git.openjdk.java.net/jdk/pull/8535 From rriggs at openjdk.java.net Thu May 5 14:49:28 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 5 May 2022 14:49:28 GMT Subject: RFR: JDK-8285987: executing shell scripts without #! fails on Alpine linux In-Reply-To: References: Message-ID: On Thu, 5 May 2022 14:15:30 GMT, Matthias Baesken wrote: >> test/lib/jdk/test/lib/Platform.java line 192: >> >>> 190: } >>> 191: >>> 192: public static boolean isMusl() { >> >> I think this will need test/lib/TestMutuallyExclusivePlatformPredicates.java to be updated too. > > Hi Alan, thanks for the advice; do you think we can put it into the IGNORED group ? > https://github.com/openjdk/jdk/blob/master/test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java#L53 Its now on the ProblemList and Created Issue: [JDK-8286191](https://bugs.openjdk.java.net/browse/JDK-8286191) Test library test failure in TestMutuallyExclusivePlatformPredicates.java ------------- PR: https://git.openjdk.java.net/jdk/pull/8535 From stuefe at openjdk.java.net Thu May 5 15:03:56 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 5 May 2022 15:03:56 GMT Subject: RFR: JDK-8286198: [linux] Fix process-memory information Message-ID: We use mallinfo/mallinfo2 to obtain information about the glibc used memory, but there is an error which causes it to be correct only for fine granular malloc allocations. glibc puts larger allocations in mmap-allocated areas, which were missing from the old calculation. This patch fixes that; it also adds information about memory retained in the glibc after free. Note that the latter unfortunately does not follow glibc trims because trimming is done AFAIK with madvice(MADV_DONTNEED) which does not seem to affect glibc internal bookkeeping. Still its a very valuable thing to know in order to estimate glibc overhead especially in fine granular mass allocation scenarios. Tests: Lots of manual tests with various malloc loads and granularities, in addition to automated tests. ------------- Commit messages: - fix process memory information on linux Changes: https://git.openjdk.java.net/jdk/pull/8553/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8553&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286198 Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8553.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8553/head:pull/8553 PR: https://git.openjdk.java.net/jdk/pull/8553 From rriggs at openjdk.java.net Thu May 5 15:12:19 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 5 May 2022 15:12:19 GMT Subject: RFR: JDK-8285987: executing shell scripts without #! fails on Alpine linux In-Reply-To: References: Message-ID: On Thu, 5 May 2022 14:47:22 GMT, Roger Riggs wrote: >> Hi Alan, thanks for the advice; do you think we can put it into the IGNORED group ? >> https://github.com/openjdk/jdk/blob/master/test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java#L53 > > Its now on the ProblemList and Created Issue: > [JDK-8286191](https://bugs.openjdk.java.net/browse/JDK-8286191) Test library test failure in TestMutuallyExclusivePlatformPredicates.java This PR also caused a test failure in ExternalEditorTest because there is no defined value for "vm.musl" used in @\requires. What test were run before integration? ------------- PR: https://git.openjdk.java.net/jdk/pull/8535 From mdoerr at openjdk.java.net Thu May 5 15:28:28 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 5 May 2022 15:28:28 GMT Subject: RFR: JDK-8285987: executing shell scripts without #! fails on Alpine linux In-Reply-To: References: Message-ID: <1sjCy0VTLNkGW44pGTZDld1cq-5tFNH0i-_cLjPbX3Y=.5b3b41a6-5534-4a1a-814e-0d9eb5557282@github.com> On Wed, 4 May 2022 12:04:47 GMT, Matthias Baesken wrote: > A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 . > Looks like this is a known issue on musl / Alpine, see also > https://www.openwall.com/lists/musl/2018/03/09/2 > and > https://github.com/scala-steward-org/scala-steward/issues/1374 > (we see it on Alpine 3.15). Strange. The pre-submit tests are all green. ------------- PR: https://git.openjdk.java.net/jdk/pull/8535 From mbaesken at openjdk.java.net Thu May 5 15:34:19 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 5 May 2022 15:34:19 GMT Subject: RFR: JDK-8285987: executing shell scripts without #! fails on Alpine linux In-Reply-To: <1sjCy0VTLNkGW44pGTZDld1cq-5tFNH0i-_cLjPbX3Y=.5b3b41a6-5534-4a1a-814e-0d9eb5557282@github.com> References: <1sjCy0VTLNkGW44pGTZDld1cq-5tFNH0i-_cLjPbX3Y=.5b3b41a6-5534-4a1a-814e-0d9eb5557282@github.com> Message-ID: On Thu, 5 May 2022 15:24:25 GMT, Martin Doerr wrote: > Strange. The pre-submit tests are all green. Yes sorry those seem not to cover these 2 findings. And I think I locally run by mistake only the jdk test instead of the jdk + langtools tests with my script , this will of course not show the langtools issue. The green langtools/tier1 from presubmit might not include the ExternalEditorTest . ------------- PR: https://git.openjdk.java.net/jdk/pull/8535 From ioi.lam at oracle.com Thu May 5 18:06:28 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 5 May 2022 11:06:28 -0700 Subject: SIGBUS on linux in perfMemory_init In-Reply-To: <93c0759e5b829796a4f8d2c00364a00ccd9a62b0.camel@redhat.com> References: <93c0759e5b829796a4f8d2c00364a00ccd9a62b0.camel@redhat.com> Message-ID: On 5/5/2022 3:05 AM, Severin Gehwolf wrote: > On Wed, 2022-05-04 at 12:13 -0700, Ioi Lam wrote: >> ==================================== >> >> How about this: >> >> When a JVM starts up, it creates the hsperfdata with a UUID instead of >> PID. E.g., >> >> ???? /tmp/hsperfdata_user/0da29ace76f76f61 >> >> Today, jps reads /proc/*/status to determine the NSpid, so we are doing >> a lot of processing already. Instead, we should read /proc/*/maps and >> scan for something with this pattern: >> >> ???? 7ffb2536d000-7ffb25375000 rw-s .... >> /tmp/hsperfdata_user/0da29ace76f76f61 >> >> If we can find this pattern, we know we have a JVM process that the >> current user can attach to. >> >> When attaching to this process, we will use this file instead >> >> /proc/$PID/root/tmp/.java_pid0da29ace76f76f61 >> >> This should work with >> >> - shared /tmp across containers >> - nested containers > Wouldn't this break with the work-around Vitaly employed? I.e. using > > -XX:+PerfDisableSharedMem > > $ ps ax | grep java > 10449 pts/4 Sl+ 0:00 ./build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java -XX:+PerfDisableSharedMem Hello > 10744 pts/5 S+ 0:00 grep --color=auto java > $ grep hsperf /proc/10449/maps > $ jcmd 10449 VM.version > 10449: > OpenJDK 64-Bit Server VM version 11.0.16-internal+0-adhoc.sgehwolf.jdk11u-dev > JDK 11.0.16 > $ jcmd -l > 10857 jdk.jcmd/sun.tools.jcmd.JCmd -l I think we can create a fake mmap region when -XX:+PerfDisableSharedMem is used. E.g., 7ffb2536d000-7ffb25375000 rw-s .... /tmp/hsperfdata_user/0da29ace76f76f61-disabled So we can reliably discover the .java_pidxxxxx file used for attachment: jcmd $PID -> /proc/$PID/maps -> /tmp/hsperfdata_user/0da29ace76f76f61-disabled -> /proc/$PID/root/tmp/.java_pid0da29ace76f76f61 Thanks - Ioi > > Basically, by departing from using system identifiers, we need some > other way to discover the well known identifier. > > Thanks, > Severin > > From ioi.lam at oracle.com Thu May 5 19:43:57 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 5 May 2022 12:43:57 -0700 Subject: SIGBUS on linux in perfMemory_init In-Reply-To: References: <93c0759e5b829796a4f8d2c00364a00ccd9a62b0.camel@redhat.com> Message-ID: On 5/5/2022 11:06 AM, Ioi Lam wrote: > > > On 5/5/2022 3:05 AM, Severin Gehwolf wrote: >> On Wed, 2022-05-04 at 12:13 -0700, Ioi Lam wrote: >>> ==================================== >>> >>> How about this: >>> >>> When a JVM starts up, it creates the hsperfdata with a UUID instead of >>> PID. E.g., >>> >>> ????? /tmp/hsperfdata_user/0da29ace76f76f61 >>> >>> Today, jps reads /proc/*/status to determine the NSpid, so we are doing >>> a lot of processing already. Instead, we should read /proc/*/maps and >>> scan for something with this pattern: >>> >>> ????? 7ffb2536d000-7ffb25375000 rw-s .... >>> /tmp/hsperfdata_user/0da29ace76f76f61 >>> >>> If we can find this pattern, we know we have a JVM process that the >>> current user can attach to. >>> >>> When attaching to this process, we will use this file instead >>> >>> /proc/$PID/root/tmp/.java_pid0da29ace76f76f61 >>> >>> This should work with >>> >>> - shared /tmp across containers >>> - nested containers >> Wouldn't this break with the work-around Vitaly employed? I.e. using >> >> -XX:+PerfDisableSharedMem >> >> $ ps ax | grep java >> ?? 10449 pts/4??? Sl+??? 0:00 >> ./build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java >> -XX:+PerfDisableSharedMem Hello >> ?? 10744 pts/5??? S+???? 0:00 grep --color=auto java >> $ grep hsperf /proc/10449/maps >> $ jcmd 10449 VM.version >> 10449: >> OpenJDK 64-Bit Server VM version >> 11.0.16-internal+0-adhoc.sgehwolf.jdk11u-dev >> JDK 11.0.16 >> $ jcmd -l >> 10857 jdk.jcmd/sun.tools.jcmd.JCmd -l > > I think we can create a fake mmap region when > -XX:+PerfDisableSharedMem is used. E.g., > > 7ffb2536d000-7ffb25375000 rw-s .... > /tmp/hsperfdata_user/0da29ace76f76f61-disabled > > So we can reliably discover the .java_pidxxxxx file used for attachment: > > jcmd $PID > -> /proc/$PID/maps > -> /tmp/hsperfdata_user/0da29ace76f76f61-disabled > -> /proc/$PID/root/tmp/.java_pid0da29ace76f76f61 > An alternative is to set an environment variable like JVM_ATTACH_UUID=0da29ace76f76f61 and we can get that from /proc/*/environ , which might be more light-weight. > Thanks > - Ioi > > >> >> Basically, by departing from using system identifiers, we need some >> other way to discover the well known identifier. >> >> Thanks, >> Severin >> >> > From ioi.lam at oracle.com Thu May 5 20:48:37 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 5 May 2022 13:48:37 -0700 Subject: SIGBUS on linux in perfMemory_init In-Reply-To: References: Message-ID: <094eb6f1-c0a1-e654-3a31-0a141e5560af@oracle.com> On 5/3/2022 8:41 AM, Nico Williams wrote: > On Fri, Apr 29, 2022 at 09:44:00AM -0400, Vitaly Davidovich wrote: >> As for possible solutions, would it be possible to use the global PID >> instead of the namespaced PID to "regain" the uniqueness invariant of the >> PID? Also, might it make sense to flock() the file to prevent another >> process from mucking with it? > My unsolicited, outsider opinions: > > - Sharing /tmp across containers is a Bad Idea (tm). > > - Sharing /tmp across related containers (in a pod) is not _as_ bad an > idea. > > (It might be a way to implement some cross-container communications, > though it would be better to have an explicit mechanism for that > rather than the rather-generic /tmp.) > > - Containerizing apps that *do* communicate over /tmp might be one > reason one might configure a shared /tmp in a pod. > > Some support for such a configuration might be needed. > > (Alternatively, pods that share /tmp should also share a PID > namespace.) > > - Since there is an option to not have an mmap'ed hsperf file, it might > be nice to have an option to use the global PID for naming hsperf > files. Or, better, implement an automatic mechanism for detecting > conflict and switching to global PID for naming hsperf files (or > switching to anonymous hsperf mmaps). > > - In any case, on systems that have a real flock(2), using flock(2) for > liveness testing is better than kill(2) with signal 0 -- the latter > has false positives, while the former does not [provided O_CLOEXEC is > used]. > > For this reason, and though I am not too sympathetic to the situation > that caused this crash, I believe that it would be better to have > some sort of fix for this problem than to declare it a non-problem > and not-fix it. > > > I would like to expand on Vitaly's mention of flock(2). Using the > global PID would leave the JVM unable to use kill(2) with signal 0 for > liveness detection during hsperf garbage file collection. Using kill(2) > with signal 0 for liveness is not that reliable anyways because of PID > reuse -- it can have false positives. > > A better mechanism for liveness detection would be to have the owning > JVM take an exclusive (LOCK_EX) flock(2) on the hsperf file at startup, > and for hsperf garbage file collection to try (LOCK_NB) to get an > exclusive lock (LOCK_EX) on a candidate hsperf garbage file as a > liveness detection mechanism. > > When using the namespaced PID the kill(2) with signal 0 method of > liveness detection should still be used for backwards-compatibility in, > e.g., jvisualvm. > > Using flock(2) would be less portable than kill(2) with signal 0, but > already there is a bunch of Linux-specific code here looking through > /proc, and Linux does have a real flock(2). > > An adaptive, zero-conf hsperf file naming scheme might use the > namespaced PID if available (i.e., if an exclusive flock(2) could be > obtained on the file), or the global PID if not, with some indication in > the name of the file's name of which kind of PID was used. Hi Nico, I read your message again and now I totally agree with using flock(2) :-) As you said, we should start with getpid(). That way the behavior is compatible with older versions of jcmd tools, especially when Java is used outside of containers. One thing I realized is that if we have a collision, we don't need to use a globally unique ID. We just need an ID that's unique in the directory being written into. I think we can do this on the VM side: ??? String id = getpid(); ??? while (true) { ??????? String file = "/tmp/hsperfdata_" + username() + "/" + id; ??????? if (get_exclusive_access(file)) { ??????????? // I won the contest and ??????????? // (a) the file didn't exist, or ??????????? // (b) the file existed but the JVM that used it has died ??????????? return file; ??????? } ??????? // Add an "x" here so we don't collide with the getpid() of another process ??????? id = "x" + random(); ??? } On the tools side, we can do the pid -> rendezvous file mapping as I described in the other e-mail. Thanks - Ioi > Cheers, > > Nico From dholmes at openjdk.java.net Thu May 5 21:32:05 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 5 May 2022 21:32:05 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v10] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 08:09:03 GMT, Jie Fu wrote: >> Hi all, >> >> `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. >> We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. >> >> From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). >> So `FillerObject_klass` should be loaded as soon as possible. >> >> >> (gdb) bt >> #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 >> #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 >> #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 >> #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 >> #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 >> #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 >> #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 >> #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 >> #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 >> #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 >> #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 >> #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 >> #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 >> #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 >> #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 >> #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 >> #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 >> >> >> .... >> >> >> #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 >> >> >> #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 >> #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 >> #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 >> #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 >> #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 >> #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 >> #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 >> #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 >> >> >> The fix just loads `FillerObject` after `Object_klass`. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > _filler_klass --> _filler_object_klass I had a clear run on tier1-3 so all good to integrate ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From dholmes at openjdk.java.net Thu May 5 21:37:49 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 5 May 2022 21:37:49 GMT Subject: RFR: 8262004: Classpath separator: Man page says semicolon; should be colon on Linux [v3] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 12:47:01 GMT, Adam Sotona wrote: >> Man file for the java command in JDK, the arguments such as -classpath, --module-path and --upgrade-module-path say "A semicolon (;) separated list of directories" >> >> Please review this fix correcting the text to "A colon (:) separated list of directories". >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > more generalized text Looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8530 From ccheung at openjdk.java.net Thu May 5 22:55:05 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 5 May 2022 22:55:05 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file [v2] In-Reply-To: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> Message-ID: > Please review this change for an additional check before archiving a lambda proxy class. If the nest host of an lambda proxy class implements an old (major version < JDK_6 (50)) interface, the lambda proxy class should not be archived. This avoids accessing a null nest host during runtime while loading the lambda proxy class from the CDS archive. > > Passed the test in the bug report. > > Passed CI tiers 1 - 4 testing (including the new tests). Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: @iklam comments and also rename the test classes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8540/files - new: https://git.openjdk.java.net/jdk/pull/8540/files/2646c2a3..38b2a05c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8540&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8540&range=00-01 Stats: 203 lines in 5 files changed: 99 ins; 91 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8540.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8540/head:pull/8540 PR: https://git.openjdk.java.net/jdk/pull/8540 From ccheung at openjdk.java.net Thu May 5 22:58:47 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 5 May 2022 22:58:47 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file In-Reply-To: References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> <7rArGa5hOfhE6wsWg57himYDwX2Cfr5pasEKziR6lcY=.3e4be933-990b-4d3b-8aef-dadea1fc8b4b@github.com> Message-ID: On Thu, 5 May 2022 05:24:43 GMT, Ioi Lam wrote: > > ``` > if (is_registered_lambda_proxy_class(k)) { > DumpTimeClassInfo* info = _dumptime_table->get(k); > assert(info != NULL, "sanity"); > if (!check_for_exclusion(info->nest_host(), NULL) { > return true; > } > ``` > I've made the above change. Note the `if (!check_for_exclusion(info->nest_host(), NULL) {` should be `if (check_for_exclusion(info->nest_host(), NULL) {` I've also changed the class names of the test case: `OldNestHost` to `NestHostOldInf` `OldNestHostApp` to `NestHostOldInfApp` ------------- PR: https://git.openjdk.java.net/jdk/pull/8540 From jiefu at openjdk.java.net Thu May 5 23:20:03 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 5 May 2022 23:20:03 GMT Subject: RFR: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass [v10] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 08:09:03 GMT, Jie Fu wrote: >> Hi all, >> >> `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. >> We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. >> >> From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). >> So `FillerObject_klass` should be loaded as soon as possible. >> >> >> (gdb) bt >> #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 >> #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 >> #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 >> #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 >> #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 >> #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 >> #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 >> #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 >> #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 >> #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 >> #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 >> #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 >> #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 >> #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 >> #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 >> #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 >> #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 >> >> >> .... >> >> >> #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 >> >> >> #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 >> #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) >> at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 >> #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 >> #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 >> #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 >> #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 >> #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 >> #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 >> >> >> The fix just loads `FillerObject` after `Object_klass`. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > _filler_klass --> _filler_object_klass Thank you all for the review and testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From jiefu at openjdk.java.net Thu May 5 23:20:05 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 5 May 2022 23:20:05 GMT Subject: Integrated: 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass In-Reply-To: References: Message-ID: On Tue, 3 May 2022 16:01:56 GMT, Jie Fu wrote: > Hi all, > > `FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded. > We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32. > > From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`). > So `FillerObject_klass` should be loaded as soon as possible. > > > (gdb) bt > #0 0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55 > #1 0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87 > #2 0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470 > #3 0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479 > #4 0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289 > #5 0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503 > #6 0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122 > #7 0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145 > #8 0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152 > #9 0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309 > #10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278 > #11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350 > #12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363 > #13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46 > #14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55 > #15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004 > #16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428 > > > .... > > > #27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99 > > > #28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108 > #29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10) > at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64 > #30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168 > #31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655 > #32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346 > #33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966 > #34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132 > #35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756 > > > The fix just loads `FillerObject` after `Object_klass`. > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: 7ebc4bce Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/7ebc4bce930e7d406f1e68c8bd09ac1dc3a21e5a Stats: 74 lines in 4 files changed: 70 ins; 2 del; 2 mod 8286066: assert(k != __null) failed: klass not loaded caused by FillerObject_klass Reviewed-by: dholmes, tschatzl, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/8519 From ccheung at openjdk.java.net Fri May 6 03:41:54 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 6 May 2022 03:41:54 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file In-Reply-To: References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> Message-ID: <1TIxgE8dShAgmQdlCSiVNUffK4u7iR4ZnYv8uE6apy0=.b3eae268-527e-4020-a60b-ec841cc114c4@github.com> On Thu, 5 May 2022 04:55:49 GMT, David Holmes wrote: > Thanks for the explanation Calvin, so it is not the nest-host that is old, but an interface implemented by the nest-host. The old interface prevents the nest-host from being archived and so the lambda-proxy also should not (can not) be archived. So this is really just a general constraint on class archiving: if a class A has a nest-host B, and B can not be archived, then A can not be archived. Is that correct? Or is there some reason this only affects lambda-proxy classes? We record the nest host for a lambda proxy class during dump time so that we can ensure the nest host obtained during runtime is the same as the one recorded at dump time. Refer to the `SystemDictionaryShared::prepare_shared_lambda_proxy_class` function for more details. ------------- PR: https://git.openjdk.java.net/jdk/pull/8540 From dholmes at openjdk.java.net Fri May 6 03:55:50 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 6 May 2022 03:55:50 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file [v2] In-Reply-To: References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> Message-ID: On Thu, 5 May 2022 22:55:05 GMT, Calvin Cheung wrote: >> Please review this change for an additional check before archiving a lambda proxy class. If the nest host of an lambda proxy class implements an old (major version < JDK_6 (50)) interface, the lambda proxy class should not be archived. This avoids accessing a null nest host during runtime while loading the lambda proxy class from the CDS archive. >> >> Passed the test in the bug report. >> >> Passed CI tiers 1 - 4 testing (including the new tests). > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @iklam comments and also rename the test classes Hi Calvin, I few minor nits to address. Thanks, David src/hotspot/share/classfile/systemDictionaryShared.cpp line 332: > 330: assert(info != NULL, "sanity"); > 331: if (check_for_exclusion(info->nest_host(), NULL)) { > 332: log_debug(cds)("Skipping %s: lambda proxy class", k->name()->as_C_string()); Do we need to say why we are skipping it - that it is because of the nest-host? test/hotspot/jtreg/runtime/cds/appcds/NestHostOldInf.java line 2: > 1: /* > 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. New file so 2021 -> 2022 test/hotspot/jtreg/runtime/cds/appcds/NestHostOldInf.java line 28: > 26: * @bug 8285914 > 27: * @summary A lambda proxy class should not be archived if its nest host implements an > 28: * old (with major version < JDK_6 (50) interface which cannot be verified during dump time). This should read: `* old (with major version < JDK_6 (50)) interface which cannot be verified during dump time.` The closing parenthesis was in the wrong place. test/hotspot/jtreg/runtime/cds/appcds/NestHostOldInf.java line 33: > 31: * @compile test-classes/OldInf.jasm > 32: * @compile test-classes/ChildOldInf.java > 33: * @compile test-classes/NestHostOldInfApp.java Can these not be combined into a single @compile - or is there some ordering dependency? test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/NestHostOldInf.java line 29: > 27: * @bug 8285914 > 28: * @summary A lambda proxy class should not be archived if its nest host implements an > 29: * old (with major version < JDK_6 (50) interface which cannot be verified during dump time). Same comment - closing parenthesis is in wrong place. test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/NestHostOldInf.java line 34: > 32: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds > 33: * @compile ../test-classes/OldInf.jasm ../test-classes/ChildOldInf.java > 34: * @compile ../test-classes/NestHostOldInfApp.java Again combine in one? test/hotspot/jtreg/runtime/cds/appcds/test-classes/NestHostOldInfApp.java line 26: > 24: public class NestHostOldInfApp { > 25: public static void main(String args[]) { > 26: Unnecessary blank line. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8540 From iklam at openjdk.java.net Fri May 6 04:53:49 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 6 May 2022 04:53:49 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file [v2] In-Reply-To: References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> Message-ID: <-dm1aetK8VBAxgGNQNJBS10SOIx9rBP_ak3CP0rRnGo=.ecbb163f-f43e-4cbc-b1bd-36270e5f3792@github.com> On Thu, 5 May 2022 22:55:05 GMT, Calvin Cheung wrote: >> Please review this change for an additional check before archiving a lambda proxy class. If the nest host of an lambda proxy class implements an old (major version < JDK_6 (50)) interface, the lambda proxy class should not be archived. This avoids accessing a null nest host during runtime while loading the lambda proxy class from the CDS archive. >> >> Passed the test in the bug report. >> >> Passed CI tiers 1 - 4 testing (including the new tests). > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @iklam comments and also rename the test classes I was curious about how the lambda proxy classes are removed from the archive, so I applied you patch and traced inside gdb. The removal is done in `CleanupDumpTimeLambdaProxyClassTable`, which will remove a proxy class if its `caller_ik` is excluded. I think it makes sense to put the `nest_host` check in the same place. So instead of my previous suggestion, this seems to be a better way to handle it: class CleanupDumpTimeLambdaProxyClassTable: StackObj { public: bool do_entry(LambdaProxyClassKey& key, DumpTimeLambdaProxyClassInfo& info) { assert_lock_strong(DumpTimeTable_lock); InstanceKlass* caller_ik = key.caller_ik(); InstanceKlass* nest_host = caller_ik->nest_host_not_null(); // If the caller class and/or nest_host are excluded, the associated lambda proxy // must also be excluded. bool always_exclude = SystemDictionaryShared::check_for_exclusion(caller_ik, NULL) || SystemDictionaryShared::check_for_exclusion(nest_host, NULL); for (int i = info._proxy_klasses->length() - 1; i >= 0; i--) { InstanceKlass* ik = info._proxy_klasses->at(i); if (always_exclude || SystemDictionaryShared::check_for_exclusion(ik, NULL)) { SystemDictionaryShared::reset_registered_lambda_proxy_class(ik); info._proxy_klasses->remove_at(i); } } return info._proxy_klasses->length() == 0 ? true /* delete the node*/ : false; } }; ... add add this to instanceKlass.hpp // Call this only if you know that the nest host has been initialized. InstanceKlass* nest_host_not_null() { assert(_nest_host != NULL, "must be"); return _nest_host; } ------------- PR: https://git.openjdk.java.net/jdk/pull/8540 From ccheung at openjdk.java.net Fri May 6 05:04:56 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 6 May 2022 05:04:56 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file [v3] In-Reply-To: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> Message-ID: > Please review this change for an additional check before archiving a lambda proxy class. If the nest host of an lambda proxy class implements an old (major version < JDK_6 (50)) interface, the lambda proxy class should not be archived. This avoids accessing a null nest host during runtime while loading the lambda proxy class from the CDS archive. > > Passed the test in the bug report. > > Passed CI tiers 1 - 4 testing (including the new tests). Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: comments from David H. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8540/files - new: https://git.openjdk.java.net/jdk/pull/8540/files/38b2a05c..bfdd3722 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8540&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8540&range=01-02 Stats: 13 lines in 4 files changed: 2 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8540.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8540/head:pull/8540 PR: https://git.openjdk.java.net/jdk/pull/8540 From ccheung at openjdk.java.net Fri May 6 05:05:03 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 6 May 2022 05:05:03 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file [v2] In-Reply-To: References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> Message-ID: On Fri, 6 May 2022 03:45:54 GMT, David Holmes wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> @iklam comments and also rename the test classes > > src/hotspot/share/classfile/systemDictionaryShared.cpp line 332: > >> 330: assert(info != NULL, "sanity"); >> 331: if (check_for_exclusion(info->nest_host(), NULL)) { >> 332: log_debug(cds)("Skipping %s: lambda proxy class", k->name()->as_C_string()); > > Do we need to say why we are skipping it - that it is because of the nest-host? I changed the log statement so that it prints the following with the test case: `[1.999s][debug ][cds] Skipping ChildOldInf$InnerChild$$Lambda$1+0x0000000801001000: lambda proxy class because its nest host ChildOldInf was excluded` > test/hotspot/jtreg/runtime/cds/appcds/NestHostOldInf.java line 2: > >> 1: /* >> 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. > > New file so 2021 -> 2022 Fixed. > test/hotspot/jtreg/runtime/cds/appcds/NestHostOldInf.java line 28: > >> 26: * @bug 8285914 >> 27: * @summary A lambda proxy class should not be archived if its nest host implements an >> 28: * old (with major version < JDK_6 (50) interface which cannot be verified during dump time). > > This should read: > > `* old (with major version < JDK_6 (50)) interface which cannot be verified during dump time.` > > The closing parenthesis was in the wrong place. Fixed > test/hotspot/jtreg/runtime/cds/appcds/NestHostOldInf.java line 33: > >> 31: * @compile test-classes/OldInf.jasm >> 32: * @compile test-classes/ChildOldInf.java >> 33: * @compile test-classes/NestHostOldInfApp.java > > Can these not be combined into a single @compile - or is there some ordering dependency? Fixed. > test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/NestHostOldInf.java line 29: > >> 27: * @bug 8285914 >> 28: * @summary A lambda proxy class should not be archived if its nest host implements an >> 29: * old (with major version < JDK_6 (50) interface which cannot be verified during dump time). > > Same comment - closing parenthesis is in wrong place. Fixed. > test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/NestHostOldInf.java line 34: > >> 32: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds >> 33: * @compile ../test-classes/OldInf.jasm ../test-classes/ChildOldInf.java >> 34: * @compile ../test-classes/NestHostOldInfApp.java > > Again combine in one? Fixed. > test/hotspot/jtreg/runtime/cds/appcds/test-classes/NestHostOldInfApp.java line 26: > >> 24: public class NestHostOldInfApp { >> 25: public static void main(String args[]) { >> 26: > > Unnecessary blank line. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8540 From asotona at openjdk.java.net Fri May 6 06:03:55 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Fri, 6 May 2022 06:03:55 GMT Subject: Integrated: 8262004: Classpath separator: Man page says semicolon; should be colon on Linux In-Reply-To: References: Message-ID: On Wed, 4 May 2022 09:28:22 GMT, Adam Sotona wrote: > Man file for the java command in JDK, the arguments such as -classpath, --module-path and --upgrade-module-path say "A semicolon (;) separated list of directories" > > Please review this fix correcting the text to "A colon (:) separated list of directories". > > Thanks, > Adam This pull request has now been integrated. Changeset: 015cfda8 Author: Adam Sotona URL: https://git.openjdk.java.net/jdk/commit/015cfda8e141eaaa3bad60e669c24e53039ca364 Stats: 21 lines in 1 file changed: 9 ins; 4 del; 8 mod 8262004: Classpath separator: Man page says semicolon; should be colon on Linux Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/8530 From ccheung at openjdk.java.net Fri May 6 06:29:41 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 6 May 2022 06:29:41 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file [v4] In-Reply-To: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> Message-ID: > Please review this change for an additional check before archiving a lambda proxy class. If the nest host of an lambda proxy class implements an old (major version < JDK_6 (50)) interface, the lambda proxy class should not be archived. This avoids accessing a null nest host during runtime while loading the lambda proxy class from the CDS archive. > > Passed the test in the bug report. > > Passed CI tiers 1 - 4 testing (including the new tests). Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: exclude lambda proxy class in CleanupDumpTimeLambdaProxyClassTable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8540/files - new: https://git.openjdk.java.net/jdk/pull/8540/files/bfdd3722..93f434d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8540&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8540&range=02-03 Stats: 29 lines in 2 files changed: 5 ins; 12 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/8540.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8540/head:pull/8540 PR: https://git.openjdk.java.net/jdk/pull/8540 From ccheung at openjdk.java.net Fri May 6 06:29:42 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 6 May 2022 06:29:42 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file [v2] In-Reply-To: <-dm1aetK8VBAxgGNQNJBS10SOIx9rBP_ak3CP0rRnGo=.ecbb163f-f43e-4cbc-b1bd-36270e5f3792@github.com> References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> <-dm1aetK8VBAxgGNQNJBS10SOIx9rBP_ak3CP0rRnGo=.ecbb163f-f43e-4cbc-b1bd-36270e5f3792@github.com> Message-ID: <1b1YTPw5dA5CQcRR3Wi1MoHJjh7X0m3x3XEf43vR09Q=.9313fa56-5be7-4a15-80c4-637ba92fbdb7@github.com> On Fri, 6 May 2022 04:50:06 GMT, Ioi Lam wrote: > I was curious about how the lambda proxy classes are removed from the archive, so I applied you patch and traced inside gdb. The removal is done in `CleanupDumpTimeLambdaProxyClassTable`, which will remove a proxy class if its `caller_ik` is excluded. > > I think it makes sense to put the `nest_host` check in the same place. So instead of my previous suggestion, this seems to be a better way to handle it: > > ``` > class CleanupDumpTimeLambdaProxyClassTable: StackObj { > public: > bool do_entry(LambdaProxyClassKey& key, DumpTimeLambdaProxyClassInfo& info) { > assert_lock_strong(DumpTimeTable_lock); > InstanceKlass* caller_ik = key.caller_ik(); > InstanceKlass* nest_host = caller_ik->nest_host_not_null(); > > // If the caller class and/or nest_host are excluded, the associated lambda proxy > // must also be excluded. > bool always_exclude = SystemDictionaryShared::check_for_exclusion(caller_ik, NULL) || > SystemDictionaryShared::check_for_exclusion(nest_host, NULL); > > for (int i = info._proxy_klasses->length() - 1; i >= 0; i--) { > InstanceKlass* ik = info._proxy_klasses->at(i); > if (always_exclude || SystemDictionaryShared::check_for_exclusion(ik, NULL)) { > SystemDictionaryShared::reset_registered_lambda_proxy_class(ik); > info._proxy_klasses->remove_at(i); > } > } > return info._proxy_klasses->length() == 0 ? true /* delete the node*/ : false; > } > }; > > ... add add this to instanceKlass.hpp > > // Call this only if you know that the nest host has been initialized. > InstanceKlass* nest_host_not_null() { > assert(_nest_host != NULL, "must be"); > return _nest_host; > } > ``` Ok. I've made the above change. Re-running tiers 1 and 2 tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/8540 From mbaesken at openjdk.java.net Fri May 6 07:36:48 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 6 May 2022 07:36:48 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 09:08:28 GMT, Matthias Baesken wrote: > Does this mean that not setting _WIN32_WINNT means :any API is allowed" ? Hi David , I did one more try with my current setup (VS2017 on a Win10 notebook). I did not set _WIN32_WINNT. My little test program #include #include int main() { #ifdef _WIN32_WINNT printf("_WIN32_WINNT is defined .\n"); #if (_WIN32_WINNT == 0x0600) printf("Vista API setting\n"); #endif #if (_WIN32_WINNT == 0x0601) printf("Win 7 API setting\n"); #endif #if (_WIN32_WINNT == 0x0602) printf("Win 8 API setting\n"); #endif #if (_WIN32_WINNT == 0x0603) printf("Win 8.1 API setting\n"); #endif #if (_WIN32_WINNT == 0x0A00) printf("Win 10 API setting\n"); #endif #endif return 0; } shows me _WIN32_WINNT is defined . Win 10 API setting So I think with our current compilers in use like VS2017 / VS2019 we allow Win10 APIs in most of our code except a few places where we set _WIN32_WINNT and go back to some mixture of older APIs. Not sure if this is a good thing, we could break for example Win 8.1/Win2012 compatibility easily this way. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From sgehwolf at redhat.com Fri May 6 08:17:16 2022 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 06 May 2022 10:17:16 +0200 Subject: SIGBUS on linux in perfMemory_init In-Reply-To: References: <93c0759e5b829796a4f8d2c00364a00ccd9a62b0.camel@redhat.com> Message-ID: <07ffe303e0eaaca5e6357400ddedb39878c58437.camel@redhat.com> On Thu, 2022-05-05 at 12:43 -0700, Ioi Lam wrote: > > > On 5/5/2022 11:06 AM, Ioi Lam wrote: > > > > > > On 5/5/2022 3:05 AM, Severin Gehwolf wrote: > > > On Wed, 2022-05-04 at 12:13 -0700, Ioi Lam wrote: > > > > ==================================== > > > > > > > > How about this: > > > > > > > > When a JVM starts up, it creates the hsperfdata with a UUID instead of > > > > PID. E.g., > > > > > > > > ????? /tmp/hsperfdata_user/0da29ace76f76f61 > > > > > > > > Today, jps reads /proc/*/status to determine the NSpid, so we are doing > > > > a lot of processing already. Instead, we should read /proc/*/maps and > > > > scan for something with this pattern: > > > > > > > > ????? 7ffb2536d000-7ffb25375000 rw-s .... > > > > /tmp/hsperfdata_user/0da29ace76f76f61 > > > > > > > > If we can find this pattern, we know we have a JVM process that the > > > > current user can attach to. > > > > > > > > When attaching to this process, we will use this file instead > > > > > > > > /proc/$PID/root/tmp/.java_pid0da29ace76f76f61 > > > > > > > > This should work with > > > > > > > > - shared /tmp across containers > > > > - nested containers > > > Wouldn't this break with the work-around Vitaly employed? I.e. using > > > > > > -XX:+PerfDisableSharedMem > > > > > > $ ps ax | grep java > > > ?? 10449 pts/4??? Sl+??? 0:00 > > > ./build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java > > > -XX:+PerfDisableSharedMem Hello > > > ?? 10744 pts/5??? S+???? 0:00 grep --color=auto java > > > $ grep hsperf /proc/10449/maps > > > $ jcmd 10449 VM.version > > > 10449: > > > OpenJDK 64-Bit Server VM version > > > 11.0.16-internal+0-adhoc.sgehwolf.jdk11u-dev > > > JDK 11.0.16 > > > $ jcmd -l > > > 10857 jdk.jcmd/sun.tools.jcmd.JCmd -l > > > > I think we can create a fake mmap region when > > -XX:+PerfDisableSharedMem is used. E.g., > > > > 7ffb2536d000-7ffb25375000 rw-s .... > > /tmp/hsperfdata_user/0da29ace76f76f61-disabled > > > > So we can reliably discover the .java_pidxxxxx file used for attachment: > > > > jcmd $PID > > -> /proc/$PID/maps > > -> /tmp/hsperfdata_user/0da29ace76f76f61-disabled > > -> /proc/$PID/root/tmp/.java_pid0da29ace76f76f61 > > > > An alternative is to set an environment variable like > JVM_ATTACH_UUID=0da29ace76f76f61 and we can get that from > /proc/*/environ , which might be more light-weight. That idea sounds good to me. +1 Thanks, Severin From sgehwolf at redhat.com Fri May 6 08:40:31 2022 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 06 May 2022 10:40:31 +0200 Subject: SIGBUS on linux in perfMemory_init In-Reply-To: <094eb6f1-c0a1-e654-3a31-0a141e5560af@oracle.com> References: <094eb6f1-c0a1-e654-3a31-0a141e5560af@oracle.com> Message-ID: <1146e8f96849c70de32e8780fbe92afbcef4b42f.camel@redhat.com> On Thu, 2022-05-05 at 13:48 -0700, Ioi Lam wrote: > > > On 5/3/2022 8:41 AM, Nico Williams wrote: > > On Fri, Apr 29, 2022 at 09:44:00AM -0400, Vitaly Davidovich wrote: > > > As for possible solutions, would it be possible to use the global PID > > > instead of the namespaced PID to "regain" the uniqueness invariant of the > > > PID? Also, might it make sense to flock() the file to prevent another > > > process from mucking with it? > > My unsolicited, outsider opinions: > > > > ? - Sharing /tmp across containers is a Bad Idea (tm). > > > > ? - Sharing /tmp across related containers (in a pod) is not _as_ bad an > > ??? idea. > > > > ??? (It might be a way to implement some cross-container communications, > > ??? though it would be better to have an explicit mechanism for that > > ??? rather than the rather-generic /tmp.) > > > > ? - Containerizing apps that *do* communicate over /tmp might be one > > ??? reason one might configure a shared /tmp in a pod. > > > > ??? Some support for such a configuration might be needed. > > > > ??? (Alternatively, pods that share /tmp should also share a PID > > ??? namespace.) > > > > ? - Since there is an option to not have an mmap'ed hsperf file, it might > > ??? be nice to have an option to use the global PID for naming hsperf > > ??? files.? Or, better, implement an automatic mechanism for detecting > > ??? conflict and switching to global PID for naming hsperf files (or > > ??? switching to anonymous hsperf mmaps). > > > > ? - In any case, on systems that have a real flock(2), using flock(2) for > > ??? liveness testing is better than kill(2) with signal 0 -- the latter > > ??? has false positives, while the former does not [provided O_CLOEXEC is > > ??? used]. > > > > ??? For this reason, and though I am not too sympathetic to the situation > > ??? that caused this crash, I believe that it would be better to have > > ??? some sort of fix for this problem than to declare it a non-problem > > ??? and not-fix it. > > > > > > I would like to expand on Vitaly's mention of flock(2).? Using the > > global PID would leave the JVM unable to use kill(2) with signal 0 for > > liveness detection during hsperf garbage file collection.? Using kill(2) > > with signal 0 for liveness is not that reliable anyways because of PID > > reuse -- it can have false positives. > > > > A better mechanism for liveness detection would be to have the owning > > JVM take an exclusive (LOCK_EX) flock(2) on the hsperf file at startup, > > and for hsperf garbage file collection to try (LOCK_NB) to get an > > exclusive lock (LOCK_EX) on a candidate hsperf garbage file as a > > liveness detection mechanism. > > > > When using the namespaced PID the kill(2) with signal 0 method of > > liveness detection should still be used for backwards-compatibility in, > > e.g., jvisualvm. > > > > Using flock(2) would be less portable than kill(2) with signal 0, but > > already there is a bunch of Linux-specific code here looking through > > /proc, and Linux does have a real flock(2). > > > > An adaptive, zero-conf hsperf file naming scheme might use the > > namespaced PID if available (i.e., if an exclusive flock(2) could be > > obtained on the file), or the global PID if not, with some indication in > > the name of the file's name of which kind of PID was used. > > Hi Nico, > > I read your message again and now I totally agree with using flock(2) :-) > > As you said, we should start with getpid(). That way the behavior is > compatible with older versions of jcmd tools, especially when Java is > used outside of containers. > > One thing I realized is that if we have a collision, we don't need to > use a globally unique ID. We just need an ID that's unique in the > directory being written into. > > I think we can do this on the VM side: > > ???? String id = getpid(); > ???? while (true) { > ???????? String file = "/tmp/hsperfdata_" + username() + "/" + id; > ???????? if (get_exclusive_access(file)) { > ???????????? // I won the contest and > ???????????? // (a) the file didn't exist, or > ???????????? // (b) the file existed but the JVM that used it has died > ???????????? return file; > ???????? } > ???????? // Add an "x" here so we don't collide with the getpid() of > another process > ???????? id = "x" + random(); > ???? } > > On the tools side, we can do the pid -> rendezvous file mapping as I > described in the other e-mail. If we could limit using this this special trick when it's actually neede then this would be my preference. For one, it mostly keeps compatibility with older JVMs and for two this isn't a very common use- case which would penalize the 90% of use cases which aren't affected by this. On the other hand, 'man proc' tells me this about /proc/*/environ: """ This file contains the initial environment that was set when the currently executing program was started via execve(2). [...] If, after an execve(2), the process modifies its environment (e.g., by calling functions such as putenv(3) or modifying the environ(7) variable directly), this file will not reflect those changes. [...] Permission to access this file is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see ptrace(2). """ So doing the publication of the file that was used in a reliable way will be a challenge. Both approaches, shared memory mapping and setting the environment will need PTRACE_MODE_READ_FSCREDS which I think isn't generally granted for containers. Thanks, Severin From dholmes at openjdk.java.net Fri May 6 09:52:47 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 6 May 2022 09:52:47 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup This seems okay to me in this form. I agree that explicitly setting this is better than unknowingly using API's that might not be available on supported platforms. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Fri May 6 09:57:47 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 6 May 2022 09:57:47 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Hi David, thanks for the review ! ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From erikj at openjdk.java.net Fri May 6 12:47:41 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 6 May 2022 12:47:41 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: <5t5qsNQ4XMMB_1ACFCDIKGj1BxBnsmAAq5d4C5z3yQU=.c1c2bb90-57dc-4754-a2cd-56b0e5d58843@github.com> On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From ihse at openjdk.java.net Fri May 6 14:38:50 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 6 May 2022 14:38:50 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Looks good, thanks for doing this cleanup. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8428 From iklam at openjdk.java.net Fri May 6 16:16:04 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 6 May 2022 16:16:04 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file [v4] In-Reply-To: References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> Message-ID: On Fri, 6 May 2022 06:29:41 GMT, Calvin Cheung wrote: >> Please review this change for an additional check before archiving a lambda proxy class. If the nest host of an lambda proxy class implements an old (major version < JDK_6 (50)) interface, the lambda proxy class should not be archived. This avoids accessing a null nest host during runtime while loading the lambda proxy class from the CDS archive. >> >> Passed the test in the bug report. >> >> Passed CI tiers 1 - 4 testing (including the new tests). > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > exclude lambda proxy class in CleanupDumpTimeLambdaProxyClassTable LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8540 From lkorinth at openjdk.java.net Fri May 6 18:58:06 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Fri, 6 May 2022 18:58:06 GMT Subject: RFR: 8286312: Stop mixing signed and unsigned types in bit operations Message-ID: uint32_t is a much more natural type for bitsIdx. ------------- Commit messages: - 8286312: Do not mix signed and unsigned in bit operations Changes: https://git.openjdk.java.net/jdk/pull/8581/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8581&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286312 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8581.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8581/head:pull/8581 PR: https://git.openjdk.java.net/jdk/pull/8581 From coleenp at openjdk.java.net Fri May 6 19:17:39 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 6 May 2022 19:17:39 GMT Subject: RFR: 8286312: Stop mixing signed and unsigned types in bit operations In-Reply-To: References: Message-ID: On Fri, 6 May 2022 18:52:36 GMT, Leo Korinth wrote: > uint32_t is a much more natural type for bitsIdx. Seems ok to me. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8581 From dcubed at openjdk.java.net Fri May 6 19:58:15 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 6 May 2022 19:58:15 GMT Subject: Integrated: 8286342: ProblemList compiler/c2/irTests/TestEnumFinalFold.java Message-ID: A trivial fix to ProblemList compiler/c2/irTests/TestEnumFinalFold.java. ------------- Commit messages: - 8286342: ProblemList compiler/c2/irTests/TestEnumFinalFold.java Changes: https://git.openjdk.java.net/jdk/pull/8582/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8582&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286342 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8582.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8582/head:pull/8582 PR: https://git.openjdk.java.net/jdk/pull/8582 From mikael at openjdk.java.net Fri May 6 19:58:15 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 6 May 2022 19:58:15 GMT Subject: Integrated: 8286342: ProblemList compiler/c2/irTests/TestEnumFinalFold.java In-Reply-To: References: Message-ID: On Fri, 6 May 2022 19:47:50 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList compiler/c2/irTests/TestEnumFinalFold.java. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8582 From dcubed at openjdk.java.net Fri May 6 19:58:16 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 6 May 2022 19:58:16 GMT Subject: Integrated: 8286342: ProblemList compiler/c2/irTests/TestEnumFinalFold.java In-Reply-To: References: Message-ID: On Fri, 6 May 2022 19:49:59 GMT, Mikael Vidstedt wrote: >> A trivial fix to ProblemList compiler/c2/irTests/TestEnumFinalFold.java. > > Marked as reviewed by mikael (Reviewer). @vidmik - Thanks for the lightning fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8582 From dcubed at openjdk.java.net Fri May 6 19:58:17 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 6 May 2022 19:58:17 GMT Subject: Integrated: 8286342: ProblemList compiler/c2/irTests/TestEnumFinalFold.java In-Reply-To: References: Message-ID: On Fri, 6 May 2022 19:47:50 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList compiler/c2/irTests/TestEnumFinalFold.java. This pull request has now been integrated. Changeset: d8f9686b Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/d8f9686b123bc9f0521da0cd286726c3b4327abd Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8286342: ProblemList compiler/c2/irTests/TestEnumFinalFold.java Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/8582 From dlong at openjdk.java.net Fri May 6 20:49:55 2022 From: dlong at openjdk.java.net (Dean Long) Date: Fri, 6 May 2022 20:49:55 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator In-Reply-To: References: Message-ID: On Fri, 6 May 2022 17:54:45 GMT, Zhengyu Gu wrote: > jni_GetStringUTFChars() calls `AllocateHeap(length + 1, mtInternal, 0, AllocFailStrategy::RETURN_NULL);` to allocate memory, where it passes `0` as `NativeCallStack` reference, that results construction of `NativeCallStack`. > > In `NativeCallStack`'s constructor, it performs stack walk to capture native call stack. This is unnecessary, if NMT detail tracking is not enabled. > > It should use `char* AllocateHeap(size_t size, > MEMFLAGS flags, > AllocFailType alloc_failmode /* = AllocFailStrategy::EXIT_OOM*/)` heap allocator instead. The changes looks correct, but I don't think it will give the desired behavior. It looks like there is a bug in the 3-parameter version of AllocateHeap where it ignores the alloc_failmode argument. You will need to fix that too for your change to work correctly. Try forcing an allocation failure and verify that it returns NULL instead of exiting with OOM. ------------- Changes requested by dlong (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8579 From zgu at openjdk.java.net Fri May 6 22:28:50 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 6 May 2022 22:28:50 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator In-Reply-To: References: Message-ID: On Fri, 6 May 2022 17:54:45 GMT, Zhengyu Gu wrote: > jni_GetStringUTFChars() calls `AllocateHeap(length + 1, mtInternal, 0, AllocFailStrategy::RETURN_NULL);` to allocate memory, where it passes `0` as `NativeCallStack` reference, that results construction of `NativeCallStack`. > > In `NativeCallStack`'s constructor, it performs stack walk to capture native call stack. This is unnecessary, if NMT detail tracking is not enabled. > > It should use `char* AllocateHeap(size_t size, > MEMFLAGS flags, > AllocFailType alloc_failmode /* = AllocFailStrategy::EXIT_OOM*/)` heap allocator instead. > You are right, filed [JDK-8286346](https://bugs.openjdk.java.net/browse/JDK-8286346). ------------- PR: https://git.openjdk.java.net/jdk/pull/8579 From zgu at openjdk.java.net Fri May 6 23:56:10 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 6 May 2022 23:56:10 GMT Subject: RFR: 8286346: 3-parameter version of AllocateHeap should not ignore AllocFailType Message-ID: Synopsis says all. ------------- Commit messages: - 8286346: 3-parameter version of AllocateHeap ignores AllocFailType Changes: https://git.openjdk.java.net/jdk/pull/8585/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8585&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286346 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8585.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8585/head:pull/8585 PR: https://git.openjdk.java.net/jdk/pull/8585 From dholmes at openjdk.java.net Sat May 7 05:39:37 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 7 May 2022 05:39:37 GMT Subject: RFR: 8286312: Stop mixing signed and unsigned types in bit operations In-Reply-To: References: Message-ID: On Fri, 6 May 2022 18:52:36 GMT, Leo Korinth wrote: > uint32_t is a much more natural type for bitsIdx. Seems fine and trivial. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8581 From kbarrett at openjdk.java.net Sat May 7 05:46:37 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 7 May 2022 05:46:37 GMT Subject: RFR: 8286346: 3-parameter version of AllocateHeap should not ignore AllocFailType In-Reply-To: References: Message-ID: On Fri, 6 May 2022 23:48:03 GMT, Zhengyu Gu wrote: > Synopsis says all. > > Test: > > - [x] tier1 on Linux x86_64 Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8585 From dholmes at openjdk.java.net Sat May 7 05:46:38 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 7 May 2022 05:46:38 GMT Subject: RFR: 8286346: 3-parameter version of AllocateHeap should not ignore AllocFailType In-Reply-To: References: Message-ID: On Fri, 6 May 2022 23:48:03 GMT, Zhengyu Gu wrote: > Synopsis says all. > > Test: > > - [x] tier1 on Linux x86_64 Looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8585 From stuefe at openjdk.java.net Sat May 7 09:08:42 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 7 May 2022 09:08:42 GMT Subject: RFR: 8286346: 3-parameter version of AllocateHeap should not ignore AllocFailType In-Reply-To: References: Message-ID: On Fri, 6 May 2022 23:48:03 GMT, Zhengyu Gu wrote: > Synopsis says all. > > Test: > > - [x] tier1 on Linux x86_64 +1 ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8585 From jvernee at openjdk.java.net Sat May 7 12:51:12 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Sat, 7 May 2022 12:51:12 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v4] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits: - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 - Merge branch 'master' into JEP-19-VM-IMPL2 - 8284161: Implementation of Virtual Threads (Preview) Co-authored-by: Ron Pressler Co-authored-by: Alan Bateman Co-authored-by: Erik ?sterlund Co-authored-by: Andrew Haley Co-authored-by: Rickard B?ckman Co-authored-by: Markus Gr?nlund Co-authored-by: Leonid Mesnik Co-authored-by: Serguei Spitsyn Co-authored-by: Chris Plummer Co-authored-by: Coleen Phillimore Co-authored-by: Robbin Ehn Co-authored-by: Stefan Karlsson Co-authored-by: Thomas Schatzl Co-authored-by: Sergey Kuksenko Reviewed-by: lancea, eosterlund, rehn, sspitsyn, stefank, tschatzl, dfuchs, lmesnik, dcubed, kevinw, amenkov, dlong, mchung, psandoz, bpb, coleenp, smarks, egahlin, mseledtsov, coffeys, darcy - 8282218: C1: Missing side effects of dynamic class loading during constant linkage Reviewed-by: thartmann, kvn - 8286342: ProblemList compiler/c2/irTests/TestEnumFinalFold.java Reviewed-by: mikael - 8286263: compiler/c1/TestPinnedIntrinsics.java failed with "RuntimeException: testCurrentTimeMillis failed with -3" Reviewed-by: thartmann, kvn - 8285295: Need better testing for IdentityHashMap Reviewed-by: jpai, lancea - 8286190: Add test to verify constant folding for Enum fields Reviewed-by: kvn, thartmann - 8286154: Fix 3rd party notices in test files Reviewed-by: darcy, joehw, iris - 8286291: G1: Remove unused segment allocator printouts Reviewed-by: ayang, iwalulya - ... and 80 more: https://git.openjdk.java.net/jdk/compare/f823bf84...5cef96f7 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7959/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=03 Stats: 117182 lines in 1482 files changed: 100895 ins; 8432 del; 7855 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Sat May 7 12:59:05 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Sat, 7 May 2022 12:59:05 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v5] In-Reply-To: References: Message-ID: <0jKvCItLYrueCki_LnvoP5uRXjLF-a2M5qW6l1Mjpo4=.be3b10da-1c4d-4c41-95db-252ab28ee897@github.com> > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Revert "Merge branch 'master' into JEP-19-VM-IMPL2" This reverts commit 98864b62749f3a482dbb0516a987f38904142042, reversing changes made to a7b9f131c4cc5fbec81811941e5c3e164838a88d. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/5cef96f7..f195789f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=03-04 Stats: 332953 lines in 4896 files changed: 22818 ins; 256179 del; 53956 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Sat May 7 13:05:38 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Sat, 7 May 2022 13:05:38 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v6] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee 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 20 new commits since the last revision: - Remove unneeded ComputeMoveOrder - Remove comment about native calls in lcm.cpp - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 Reviewed-by: jvernee, mcimadamore - Update riscv and arm stubs - Remove spurious ProblemList change - Pass pointer to LogStream - Polish - Replace TraceNativeInvokers flag with unified logging - Fix other platforms, take 2 - Fix other platforms - ... and 10 more: https://git.openjdk.java.net/jdk/compare/f195789f...e84e3379 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/f195789f..e84e3379 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=04-05 Stats: 222764 lines in 3783 files changed: 157991 ins; 17628 del; 47145 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Sat May 7 13:05:45 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Sat, 7 May 2022 13:05:45 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v4] In-Reply-To: References: Message-ID: On Sat, 7 May 2022 12:51:12 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits: > > - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 > - Merge branch 'master' into JEP-19-VM-IMPL2 > - 8284161: Implementation of Virtual Threads (Preview) > > Co-authored-by: Ron Pressler > Co-authored-by: Alan Bateman > Co-authored-by: Erik ?sterlund > Co-authored-by: Andrew Haley > Co-authored-by: Rickard B?ckman > Co-authored-by: Markus Gr?nlund > Co-authored-by: Leonid Mesnik > Co-authored-by: Serguei Spitsyn > Co-authored-by: Chris Plummer > Co-authored-by: Coleen Phillimore > Co-authored-by: Robbin Ehn > Co-authored-by: Stefan Karlsson > Co-authored-by: Thomas Schatzl > Co-authored-by: Sergey Kuksenko > Reviewed-by: lancea, eosterlund, rehn, sspitsyn, stefank, tschatzl, dfuchs, lmesnik, dcubed, kevinw, amenkov, dlong, mchung, psandoz, bpb, coleenp, smarks, egahlin, mseledtsov, coffeys, darcy > - 8282218: C1: Missing side effects of dynamic class loading during constant linkage > > Reviewed-by: thartmann, kvn > - 8286342: ProblemList compiler/c2/irTests/TestEnumFinalFold.java > > Reviewed-by: mikael > - 8286263: compiler/c1/TestPinnedIntrinsics.java failed with "RuntimeException: testCurrentTimeMillis failed with -3" > > Reviewed-by: thartmann, kvn > - 8285295: Need better testing for IdentityHashMap > > Reviewed-by: jpai, lancea > - 8286190: Add test to verify constant folding for Enum fields > > Reviewed-by: kvn, thartmann > - 8286154: Fix 3rd party notices in test files > > Reviewed-by: darcy, joehw, iris > - 8286291: G1: Remove unused segment allocator printouts > > Reviewed-by: ayang, iwalulya > - ... and 80 more: https://git.openjdk.java.net/jdk/compare/f823bf84...5cef96f7 I brought in the changes from master after the Virtual Threads integration, but because the PR branch I'm basing on doesn't have those changes, they showed up in the diff. I've undone this mistake by rebasing onto the target branch, which gives a clean diff that should be unchanged from before (but shuffles the commit history to the end of the convo tab). ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From ioi.lam at oracle.com Sun May 8 04:55:33 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Sat, 7 May 2022 21:55:33 -0700 Subject: SIGBUS on linux in perfMemory_init In-Reply-To: <1146e8f96849c70de32e8780fbe92afbcef4b42f.camel@redhat.com> References: <094eb6f1-c0a1-e654-3a31-0a141e5560af@oracle.com> <1146e8f96849c70de32e8780fbe92afbcef4b42f.camel@redhat.com> Message-ID: On 5/6/2022 1:40 AM, Severin Gehwolf wrote: > On Thu, 2022-05-05 at 13:48 -0700, Ioi Lam wrote: >> >> On 5/3/2022 8:41 AM, Nico Williams wrote: >>> On Fri, Apr 29, 2022 at 09:44:00AM -0400, Vitaly Davidovich wrote: >>>> As for possible solutions, would it be possible to use the global PID >>>> instead of the namespaced PID to "regain" the uniqueness invariant of the >>>> PID? Also, might it make sense to flock() the file to prevent another >>>> process from mucking with it? >>> My unsolicited, outsider opinions: >>> >>> ? - Sharing /tmp across containers is a Bad Idea (tm). >>> >>> ? - Sharing /tmp across related containers (in a pod) is not _as_ bad an >>> ??? idea. >>> >>> ??? (It might be a way to implement some cross-container communications, >>> ??? though it would be better to have an explicit mechanism for that >>> ??? rather than the rather-generic /tmp.) >>> >>> ? - Containerizing apps that *do* communicate over /tmp might be one >>> ??? reason one might configure a shared /tmp in a pod. >>> >>> ??? Some support for such a configuration might be needed. >>> >>> ??? (Alternatively, pods that share /tmp should also share a PID >>> ??? namespace.) >>> >>> ? - Since there is an option to not have an mmap'ed hsperf file, it might >>> ??? be nice to have an option to use the global PID for naming hsperf >>> ??? files.? Or, better, implement an automatic mechanism for detecting >>> ??? conflict and switching to global PID for naming hsperf files (or >>> ??? switching to anonymous hsperf mmaps). >>> >>> ? - In any case, on systems that have a real flock(2), using flock(2) for >>> ??? liveness testing is better than kill(2) with signal 0 -- the latter >>> ??? has false positives, while the former does not [provided O_CLOEXEC is >>> ??? used]. >>> >>> ??? For this reason, and though I am not too sympathetic to the situation >>> ??? that caused this crash, I believe that it would be better to have >>> ??? some sort of fix for this problem than to declare it a non-problem >>> ??? and not-fix it. >>> >>> >>> I would like to expand on Vitaly's mention of flock(2).? Using the >>> global PID would leave the JVM unable to use kill(2) with signal 0 for >>> liveness detection during hsperf garbage file collection.? Using kill(2) >>> with signal 0 for liveness is not that reliable anyways because of PID >>> reuse -- it can have false positives. >>> >>> A better mechanism for liveness detection would be to have the owning >>> JVM take an exclusive (LOCK_EX) flock(2) on the hsperf file at startup, >>> and for hsperf garbage file collection to try (LOCK_NB) to get an >>> exclusive lock (LOCK_EX) on a candidate hsperf garbage file as a >>> liveness detection mechanism. >>> >>> When using the namespaced PID the kill(2) with signal 0 method of >>> liveness detection should still be used for backwards-compatibility in, >>> e.g., jvisualvm. >>> >>> Using flock(2) would be less portable than kill(2) with signal 0, but >>> already there is a bunch of Linux-specific code here looking through >>> /proc, and Linux does have a real flock(2). >>> >>> An adaptive, zero-conf hsperf file naming scheme might use the >>> namespaced PID if available (i.e., if an exclusive flock(2) could be >>> obtained on the file), or the global PID if not, with some indication in >>> the name of the file's name of which kind of PID was used. >> Hi Nico, >> >> I read your message again and now I totally agree with using flock(2) :-) >> >> As you said, we should start with getpid(). That way the behavior is >> compatible with older versions of jcmd tools, especially when Java is >> used outside of containers. >> >> One thing I realized is that if we have a collision, we don't need to >> use a globally unique ID. We just need an ID that's unique in the >> directory being written into. >> >> I think we can do this on the VM side: >> >> ???? String id = getpid(); >> ???? while (true) { >> ???????? String file = "/tmp/hsperfdata_" + username() + "/" + id; >> ???????? if (get_exclusive_access(file)) { >> ???????????? // I won the contest and >> ???????????? // (a) the file didn't exist, or >> ???????????? // (b) the file existed but the JVM that used it has died >> ???????????? return file; >> ???????? } >> ???????? // Add an "x" here so we don't collide with the getpid() of >> another process >> ???????? id = "x" + random(); >> ???? } >> >> On the tools side, we can do the pid -> rendezvous file mapping as I >> described in the other e-mail. > If we could limit using this this special trick when it's actually > neede then this would be my preference. For one, it mostly keeps > compatibility with older JVMs and for two this isn't a very common use- > case which would penalize the 90% of use cases which aren't affected by > this. > > On the other hand, 'man proc' tells me this about /proc/*/environ: > > """ > This file contains the initial environment that was set when the > currently executing program was started via execve(2). [...] > > If, after an execve(2), the process modifies its environment (e.g., > by calling functions such as putenv(3) or modifying the environ(7) > variable directly), this file will not reflect those changes. > > [...] > > Permission to access this file is governed by a ptrace access mode > PTRACE_MODE_READ_FSCREDS check; see ptrace(2). > """ > > So doing the publication of the file that was used in a reliable way > will be a challenge. Both approaches, shared memory mapping and setting > the environment will need PTRACE_MODE_READ_FSCREDS which I think isn't > generally granted for containers. I think publishing via /proc/*/environ is going to be problematic, but using the maps file seems fine. Here are my experiments. My conclusion is: If a Java process is visible to "jps" today, "jps" can also read its /proc/id/maps file. ============== test 1 ================ Docker running with cgroup v1 on Ubuntu 20.04.3 LTS ubuntu at minikube-cgv1:~$ jps -J-version openjdk version "11.0.15" 2022-04-19 OpenJDK Runtime Environment (build 11.0.15+10-Ubuntu-0ubuntu0.20.04.1) OpenJDK 64-Bit Server VM (build 11.0.15+10-Ubuntu-0ubuntu0.20.04.1, mixed mode, sharing) ubuntu at minikube-cgv1:~$ ps -ef | grep Wait ubuntu????? 3490??? 3280? 2 21:34 pts/1??? 00:00:00 docker run -it --tty=true --rm my-java-app java -cp / Wait root??????? 3541??? 3515? 2 21:34 pts/0??? 00:00:00 java -cp / Wait ubuntu????? 3598??? 1247? 0 21:34 pts/0??? 00:00:00 grep --color=auto Wait ubuntu at minikube-cgv1:~$ jps 3611 Jps ubuntu at minikube-cgv1:~$ sudo jps 3541 Wait 3630 Jps ubuntu at minikube-cgv1:~$ wc /proc/3541/maps wc: /proc/3541/maps: Permission denied ubuntu at minikube-cgv1:~$ ls /proc/3541/root ls: cannot access '/proc/3541/root': Permission denied ubuntu at minikube-cgv1:~$ sudo wc /proc/3541/maps 181 968 12074 /proc/3541/maps ubuntu at minikube-cgv1:~$ sudo grep hsperf /proc/3541/maps 7f4ebca2b000-7f4ebca33000 rw-s 00000000 00:33 1818692??????????????????? /tmp/hsperfdata_root/1 ============== test 2 ================ podman rootless + cgroupv2 on Ubuntu 21.10 ubuntu at podman-tester:~$ jps -J-version openjdk version "17.0.1" 2021-10-19 OpenJDK Runtime Environment (build 17.0.1+12-Ubuntu-121.10) OpenJDK 64-Bit Server VM (build 17.0.1+12-Ubuntu-121.10, mixed mode, sharing) ubuntu at podman-tester:~$ ps -ef | grep Wait ubuntu????? 1531??? 1468? 0 21:19 pts/0??? 00:00:01 podman run -it --tty=true --rm my-java-app java -cp / Wait ubuntu????? 1571??? 1556? 0 21:19 pts/0??? 00:00:01 java -cp / Wait ubuntu????? 1946??? 1686? 0 21:23 pts/1??? 00:00:00 grep --color=auto Wait ubuntu at podman-tester:~$ jps 1778 Jps 1571 Wait ubuntu at podman-tester:~$ cat /^C ubuntu at podman-tester:~$ sudo jps 1571 Wait 1805 Jps ubuntu at podman-tester:~$ grep hsperf/proc/1571/maps 7f88dc40c000-7f88dc414000 rw-s 00000000 08:01 792115???????????????????? /tmp/hsperfdata_root/1 ubuntu at podman-tester:~$ sudo grep hsperf/proc/1571/maps 7f88dc40c000-7f88dc414000 rw-s 00000000 08:01 792115???????????????????? /tmp/hsperfdata_root/1 ubuntu at podman-tester:~$ ls -l /proc/1571/root/tmp/hsperfdata_root/1 -rw------- 1 ubuntu ubuntu 32768 May? 7 21:24 /proc/1571/root/tmp/hsperfdata_root/1 From stuefe at openjdk.java.net Sun May 8 09:08:48 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 8 May 2022 09:08:48 GMT Subject: RFR: JDK-8286198: [linux] Fix process-memory information In-Reply-To: References: Message-ID: On Thu, 5 May 2022 14:55:01 GMT, Thomas Stuefe wrote: > We use mallinfo/mallinfo2 to obtain information about the glibc used memory, but there is an error which causes it to be correct only for fine granular malloc allocations. glibc puts larger allocations in mmap-allocated areas, which were missing from the old calculation. > > This patch fixes that; it also adds information about memory retained in the glibc after free. Note that the latter unfortunately does not follow glibc trims because trimming is done AFAIK with madvice(MADV_DONTNEED) which does not seem to affect glibc internal bookkeeping. Still its a very valuable thing to know in order to estimate glibc overhead especially in fine granular mass allocation scenarios. > > Tests: Lots of manual tests with various malloc loads and granularities, in addition to automated tests. GHA test error on Windows irrelevant for this patch ------------- PR: https://git.openjdk.java.net/jdk/pull/8553 From stuefe at openjdk.java.net Sun May 8 09:15:45 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 8 May 2022 09:15:45 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator In-Reply-To: References: Message-ID: On Fri, 6 May 2022 17:54:45 GMT, Zhengyu Gu wrote: > jni_GetStringUTFChars() calls `AllocateHeap(length + 1, mtInternal, 0, AllocFailStrategy::RETURN_NULL);` to allocate memory, where it passes `0` as `NativeCallStack` reference, that results construction of `NativeCallStack`. > > In `NativeCallStack`'s constructor, it performs stack walk to capture native call stack. This is unnecessary, if NMT detail tracking is not enabled. > > It should use `char* AllocateHeap(size_t size, > MEMFLAGS flags, > AllocFailType alloc_failmode /* = AllocFailStrategy::EXIT_OOM*/)` heap allocator instead. Change looks good. So, we accidentally call `NativeCallStack(int toSkip);` ? If yes, and we don't like that, should we declare that constructor as explicit? ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8579 From dholmes at openjdk.java.net Mon May 9 01:21:40 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 9 May 2022 01:21:40 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL In-Reply-To: References: Message-ID: On Thu, 5 May 2022 06:58:16 GMT, Johan Sj?l?n wrote: >> src/hotspot/share/logging/logMessage.hpp line 65: >> >>> 63: class LogMessageImpl : public LogMessageBuffer { >>> 64: private: >>> 65: LogImpl _log; >> >> I'm not very familiar with the detailed internals here, but don't we need this to capture the Log "state" and ensure it is always the same when used for this LogMessageImpl - otherwise can't `LogTagSetMapping::tagset()` change what it returns over time? > > See my comment to Ioi for a more detailed explanation, but in short: No. The template parameters uniquely identify a specific tagset. The tagsets themselves are mutated in place, to accomodate for new outputs and altered decorations, for example. So really `_log` is just a simple alias that makes the other code easier to read IMO. So can't we keep `_log` and change the type? ------------- PR: https://git.openjdk.java.net/jdk/pull/8541 From dholmes at openjdk.java.net Mon May 9 01:42:48 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 9 May 2022 01:42:48 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file [v4] In-Reply-To: References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> Message-ID: On Fri, 6 May 2022 06:29:41 GMT, Calvin Cheung wrote: >> Please review this change for an additional check before archiving a lambda proxy class. If the nest host of an lambda proxy class implements an old (major version < JDK_6 (50)) interface, the lambda proxy class should not be archived. This avoids accessing a null nest host during runtime while loading the lambda proxy class from the CDS archive. >> >> Passed the test in the bug report. >> >> Passed CI tiers 1 - 4 testing (including the new tests). > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > exclude lambda proxy class in CleanupDumpTimeLambdaProxyClassTable Looks good! Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8540 From dholmes at openjdk.java.net Mon May 9 02:55:58 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 9 May 2022 02:55:58 GMT Subject: RFR: JDK-8286198: [linux] Fix process-memory information In-Reply-To: References: Message-ID: <99vNBvfeRDY4zO3lID4Oeh-hDV8RhgQHdT93Qyg6L10=.eed3e11d-5aca-4b65-ac7e-f4fd9b0a029c@github.com> On Thu, 5 May 2022 14:55:01 GMT, Thomas Stuefe wrote: > We use mallinfo/mallinfo2 to obtain information about the glibc used memory, but there is an error which causes it to be correct only for fine granular malloc allocations. glibc puts larger allocations in mmap-allocated areas, which were missing from the old calculation. > > This patch fixes that; it also adds information about memory retained in the glibc after free. Note that the latter unfortunately does not follow glibc trims because trimming is done AFAIK with madvice(MADV_DONTNEED) which does not seem to affect glibc internal bookkeeping. Still its a very valuable thing to know in order to estimate glibc overhead especially in fine granular mass allocation scenarios. > > Tests: Lots of manual tests with various malloc loads and granularities, in addition to automated tests. I don't understand your "free retained" terminology, but otherwise the changes seem fine and do what you describe. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8553 From iklam at openjdk.java.net Mon May 9 04:23:49 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 9 May 2022 04:23:49 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL In-Reply-To: References: Message-ID: On Thu, 5 May 2022 06:42:59 GMT, Johan Sj?l?n wrote: >> src/hotspot/share/logging/log.hpp line 184: >> >>> 182: >>> 183: static bool is_enabled() { >>> 184: return LogTagSetMapping::tagset().is_level(level); >> >> This removes an abstraction and makes the code more verbose. I don't see the value of doing this, especially when LogImpl is used by macros like `log_info()`, `log_debug()`, etc, which are the primary interface to UL. With this change, people who wonder how `log_info()` works would need to understand more implementation details than before. > > Hi @iklam, `LogImpl` is still used in `log_X()` macros! `LogTarget` macro uses `LogTargetImpl`, which this changes. We're not lowering the level of abstraction, we're getting rid of an unneeded one that, to me, made the code even more difficult to understand. > > Let's read the code together, because this was confusing to me when I saw it. > > > LogImpl::is_level(level) ~> // log.hpp:186:LogImplTarget > LogTagSetMapping::tagset().is_level(level) ~> // log.hpp:124:LogImpl > _output_list.is_level(level); // logTagSet.hpp:126:LogTagSet > > > When you read `log.hpp:186` you're probably thinking "OK, `LogTargetImpl` *needs* `LogImpl`, which makes sense!" but then you follow the code and LogImpl doesn't provide any extra state for `LogTagSet`. So maybe then you think that `LogImpl` provides some extra state when constructed (nope, empty constructor, LogTagSetMapping constructs LogTagSet for us statically). > > At about that point I made the conclusion that this indirection is unneeded and should be removed :-). > > PS. Accidentally posted this from my *other* Github account, so sorry for the double notification e-mail :-). OK, that sounds fair. I got mixed up with `LogImpl` and `LogTargetImpl`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8541 From stuefe at openjdk.java.net Mon May 9 04:28:47 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 9 May 2022 04:28:47 GMT Subject: RFR: JDK-8286198: [linux] Fix process-memory information In-Reply-To: <99vNBvfeRDY4zO3lID4Oeh-hDV8RhgQHdT93Qyg6L10=.eed3e11d-5aca-4b65-ac7e-f4fd9b0a029c@github.com> References: <99vNBvfeRDY4zO3lID4Oeh-hDV8RhgQHdT93Qyg6L10=.eed3e11d-5aca-4b65-ac7e-f4fd9b0a029c@github.com> Message-ID: <7qnxi5s64eKj9qpQvt216--gWW91ismClMIVAbt4iSE=.bb8073c2-fa78-44b8-8acd-36fc14e94228@github.com> On Mon, 9 May 2022 02:52:22 GMT, David Holmes wrote: > I don't understand your "free retained" terminology, but otherwise the changes seem fine and do what you describe. > > Thanks, David Thank you, David. Free Retained memory is memory you free()'d but which is retained by the glibc, not handed back to the Operating System. ------------- PR: https://git.openjdk.java.net/jdk/pull/8553 From kbarrett at openjdk.java.net Mon May 9 05:27:11 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 9 May 2022 05:27:11 GMT Subject: RFR: 8286371: Avoid use of deprecated str[n]icmp Message-ID: <1ZGbVo5Jr5RW3W3RGmEfLD_G0QFOPY54ObNozSJKedw=.b55e2ec3-cdb6-4992-b7d1-1a8070ac0a8c@github.com> Please review this trivial change to use _str[n]icmp instead of (deprecated) str[n]icmp in the only places the latter are used in HotSpot, in Windows-specific code. This change is in preparation for removing the global disable of deprecation warnings for HotSpot Windows builds. An alternative would be to use str[n]casecmp, which are defined in globalDefinitions_visCPP.hpp for compatibilty in shared code. But since the uses of the functions being changed are in Windows-specific code I think the non-deprecated Windows-specific functions are more appropriate. There are some other uses of the deprecated functions in the JDK. I didn't change them. Those other places have different approaches to dealing with the source compatibility and deprecation than does HotSpot, suppressing the warning for this and various other functions using _CRT_NONSTDC_NO_DEPRECATE. Note that the deprecation message for these functions is the same one used for deprecating various POSIX functions, and the deprecation is under the control of the same macro, even though these aren't actually from POSIX. ------------- Commit messages: - use _str[n]icmp Changes: https://git.openjdk.java.net/jdk/pull/8590/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8590&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286371 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8590.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8590/head:pull/8590 PR: https://git.openjdk.java.net/jdk/pull/8590 From dholmes at openjdk.java.net Mon May 9 06:33:48 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 9 May 2022 06:33:48 GMT Subject: RFR: 8286371: Avoid use of deprecated str[n]icmp In-Reply-To: <1ZGbVo5Jr5RW3W3RGmEfLD_G0QFOPY54ObNozSJKedw=.b55e2ec3-cdb6-4992-b7d1-1a8070ac0a8c@github.com> References: <1ZGbVo5Jr5RW3W3RGmEfLD_G0QFOPY54ObNozSJKedw=.b55e2ec3-cdb6-4992-b7d1-1a8070ac0a8c@github.com> Message-ID: On Mon, 9 May 2022 05:20:01 GMT, Kim Barrett wrote: > Please review this trivial change to use _str[n]icmp instead of (deprecated) > str[n]icmp in the only places the latter are used in HotSpot, in > Windows-specific code. This change is in preparation for removing the global > disable of deprecation warnings for HotSpot Windows builds. > > An alternative would be to use str[n]casecmp, which are defined in > globalDefinitions_visCPP.hpp for compatibilty in shared code. But since the > uses of the functions being changed are in Windows-specific code I think the > non-deprecated Windows-specific functions are more appropriate. > > There are some other uses of the deprecated functions in the JDK. I didn't > change them. Those other places have different approaches to dealing with the > source compatibility and deprecation than does HotSpot, suppressing the > warning for this and various other functions using _CRT_NONSTDC_NO_DEPRECATE. > > Note that the deprecation message for these functions is the same one used for > deprecating various POSIX functions, and the deprecation is under the control > of the same macro, even though these aren't actually from POSIX. Looks good and trivial. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8590 From lkorinth at openjdk.java.net Mon May 9 07:56:54 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Mon, 9 May 2022 07:56:54 GMT Subject: RFR: 8286312: Stop mixing signed and unsigned types in bit operations In-Reply-To: References: Message-ID: On Fri, 6 May 2022 18:52:36 GMT, Leo Korinth wrote: > uint32_t is a much more natural type for bitsIdx. Thanks for the review Coleen and David! ------------- PR: https://git.openjdk.java.net/jdk/pull/8581 From lkorinth at openjdk.java.net Mon May 9 07:56:55 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Mon, 9 May 2022 07:56:55 GMT Subject: Integrated: 8286312: Stop mixing signed and unsigned types in bit operations In-Reply-To: References: Message-ID: On Fri, 6 May 2022 18:52:36 GMT, Leo Korinth wrote: > uint32_t is a much more natural type for bitsIdx. This pull request has now been integrated. Changeset: 39f4434f Author: Leo Korinth URL: https://git.openjdk.java.net/jdk/commit/39f4434f44d46548917926c7a802b046197bbe33 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8286312: Stop mixing signed and unsigned types in bit operations Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/8581 From jvernee at openjdk.java.net Mon May 9 10:28:27 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 9 May 2022 10:28:27 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 - Remove unneeded ComputeMoveOrder - Remove comment about native calls in lcm.cpp - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 Reviewed-by: jvernee, mcimadamore - Update riscv and arm stubs - Remove spurious ProblemList change - Pass pointer to LogStream - Polish - Replace TraceNativeInvokers flag with unified logging - Fix other platforms, take 2 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7959/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=06 Stats: 6934 lines in 157 files changed: 2678 ins; 3218 del; 1038 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From duke at openjdk.java.net Mon May 9 11:15:40 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 9 May 2022 11:15:40 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL [v2] In-Reply-To: References: Message-ID: > This PR cleans up some minor annoyances in the UL code. > > Note that the change from `LogImpl` to `LogTagSet` is equivalent, we're essentially inlining the calls that `LogImpl` would have made. This simplifies understanding ("why do we need `LogImpl` here?" was my question, answer: We don't!)' > > *Edit:* Passes tier1. Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Use _tagset ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8541/files - new: https://git.openjdk.java.net/jdk/pull/8541/files/ecd9b543..810c4436 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8541&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8541&range=00-01 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8541.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8541/head:pull/8541 PR: https://git.openjdk.java.net/jdk/pull/8541 From duke at openjdk.java.net Mon May 9 11:37:50 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 9 May 2022 11:37:50 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL [v2] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 01:18:50 GMT, David Holmes wrote: >> See my comment to Ioi for a more detailed explanation, but in short: No. The template parameters uniquely identify a specific tagset. The tagsets themselves are mutated in place, to accomodate for new outputs and altered decorations, for example. > > So really `_log` is just a simple alias that makes the other code easier to read IMO. So can't we keep `_log` and change the type? How about `LogTagSet& _tagset`? There are more examples of `_tagset` members in UL, so it's consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/8541 From zgu at openjdk.java.net Mon May 9 12:32:59 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 9 May 2022 12:32:59 GMT Subject: RFR: 8286346: 3-parameter version of AllocateHeap should not ignore AllocFailType In-Reply-To: References: Message-ID: <-DzBeBMvKDHcBh6nGw3vzyZsL1gwJO3SF8o0knQFiHE=.c0df3914-7d35-4fbb-99b7-35490ac9ab48@github.com> On Sat, 7 May 2022 05:40:27 GMT, Kim Barrett wrote: >> Synopsis says all. >> >> Test: >> >> - [x] tier1 on Linux x86_64 > > Looks good. Thanks, @kimbarrett @dholmes-ora and @tstuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8585 From zgu at openjdk.java.net Mon May 9 12:35:15 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 9 May 2022 12:35:15 GMT Subject: Integrated: 8286346: 3-parameter version of AllocateHeap should not ignore AllocFailType In-Reply-To: References: Message-ID: On Fri, 6 May 2022 23:48:03 GMT, Zhengyu Gu wrote: > Synopsis says all. > > Test: > > - [x] tier1 on Linux x86_64 This pull request has now been integrated. Changeset: 64b05ccb Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/64b05ccbed7879dd38a49453a6098bfe9729ee76 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8286346: 3-parameter version of AllocateHeap should not ignore AllocFailType Reviewed-by: kbarrett, dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8585 From zgu at openjdk.java.net Mon May 9 12:51:33 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 9 May 2022 12:51:33 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator [v2] In-Reply-To: References: Message-ID: <92fzc9FoxO86AUcAIk4GqQ7xHeihtURQAIJzafs0yC4=.25ce9fb9-55fa-4885-b292-36f28fb5192c@github.com> > jni_GetStringUTFChars() calls `AllocateHeap(length + 1, mtInternal, 0, AllocFailStrategy::RETURN_NULL);` to allocate memory, where it passes `0` as `NativeCallStack` reference, that results construction of `NativeCallStack`. > > In `NativeCallStack`'s constructor, it performs stack walk to capture native call stack. This is unnecessary, if NMT detail tracking is not enabled. > > It should use `char* AllocateHeap(size_t size, > MEMFLAGS flags, > AllocFailType alloc_failmode /* = AllocFailStrategy::EXIT_OOM*/)` heap allocator instead. Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Thomas' suggestion ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8579/files - new: https://git.openjdk.java.net/jdk/pull/8579/files/df1b8c33..8c13d81d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8579&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8579&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8579.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8579/head:pull/8579 PR: https://git.openjdk.java.net/jdk/pull/8579 From dholmes at openjdk.java.net Mon May 9 12:54:53 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 9 May 2022 12:54:53 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL [v2] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 11:34:43 GMT, Johan Sj?l?n wrote: >> So really `_log` is just a simple alias that makes the other code easier to read IMO. So can't we keep `_log` and change the type? > > How about `LogTagSet& _tagset`? There are more examples of `_tagset` members in UL, so it's consistent. That seems a bit odd to me. Why can't we use the actual thing we will log to? The description of LogMessage is that it is a multi-part log entry that is accumulated until we flush it by writing to the actual log device. ------------- PR: https://git.openjdk.java.net/jdk/pull/8541 From zgu at openjdk.java.net Mon May 9 12:56:54 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 9 May 2022 12:56:54 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator In-Reply-To: References: Message-ID: On Sun, 8 May 2022 09:12:10 GMT, Thomas Stuefe wrote: > So, we accidentally call `NativeCallStack(int toSkip);` ? If yes, and we don't like that, should we declare that constructor as explicit? Good point, fixed. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/8579 From zgu at openjdk.java.net Mon May 9 13:41:50 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 9 May 2022 13:41:50 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator In-Reply-To: References: Message-ID: On Fri, 6 May 2022 22:25:26 GMT, Zhengyu Gu wrote: > > > > You are right, filed [JDK-8286346](https://bugs.openjdk.java.net/browse/JDK-8286346). @dean-long JDK-8286346 has been integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8579 From kbarrett at openjdk.java.net Mon May 9 15:25:55 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 9 May 2022 15:25:55 GMT Subject: RFR: 8286371: Avoid use of deprecated str[n]icmp In-Reply-To: References: <1ZGbVo5Jr5RW3W3RGmEfLD_G0QFOPY54ObNozSJKedw=.b55e2ec3-cdb6-4992-b7d1-1a8070ac0a8c@github.com> Message-ID: On Mon, 9 May 2022 06:30:52 GMT, David Holmes wrote: >> Please review this trivial change to use _str[n]icmp instead of (deprecated) >> str[n]icmp in the only places the latter are used in HotSpot, in >> Windows-specific code. This change is in preparation for removing the global >> disable of deprecation warnings for HotSpot Windows builds. >> >> An alternative would be to use str[n]casecmp, which are defined in >> globalDefinitions_visCPP.hpp for compatibilty in shared code. But since the >> uses of the functions being changed are in Windows-specific code I think the >> non-deprecated Windows-specific functions are more appropriate. >> >> There are some other uses of the deprecated functions in the JDK. I didn't >> change them. Those other places have different approaches to dealing with the >> source compatibility and deprecation than does HotSpot, suppressing the >> warning for this and various other functions using _CRT_NONSTDC_NO_DEPRECATE. >> >> Note that the deprecation message for these functions is the same one used for >> deprecating various POSIX functions, and the deprecation is under the control >> of the same macro, even though these aren't actually from POSIX. > > Looks good and trivial. > > Thanks. Thanks for review @dholmes-ora ------------- PR: https://git.openjdk.java.net/jdk/pull/8590 From kbarrett at openjdk.java.net Mon May 9 15:25:59 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 9 May 2022 15:25:59 GMT Subject: Integrated: 8286371: Avoid use of deprecated str[n]icmp In-Reply-To: <1ZGbVo5Jr5RW3W3RGmEfLD_G0QFOPY54ObNozSJKedw=.b55e2ec3-cdb6-4992-b7d1-1a8070ac0a8c@github.com> References: <1ZGbVo5Jr5RW3W3RGmEfLD_G0QFOPY54ObNozSJKedw=.b55e2ec3-cdb6-4992-b7d1-1a8070ac0a8c@github.com> Message-ID: On Mon, 9 May 2022 05:20:01 GMT, Kim Barrett wrote: > Please review this trivial change to use _str[n]icmp instead of (deprecated) > str[n]icmp in the only places the latter are used in HotSpot, in > Windows-specific code. This change is in preparation for removing the global > disable of deprecation warnings for HotSpot Windows builds. > > An alternative would be to use str[n]casecmp, which are defined in > globalDefinitions_visCPP.hpp for compatibilty in shared code. But since the > uses of the functions being changed are in Windows-specific code I think the > non-deprecated Windows-specific functions are more appropriate. > > There are some other uses of the deprecated functions in the JDK. I didn't > change them. Those other places have different approaches to dealing with the > source compatibility and deprecation than does HotSpot, suppressing the > warning for this and various other functions using _CRT_NONSTDC_NO_DEPRECATE. > > Note that the deprecation message for these functions is the same one used for > deprecating various POSIX functions, and the deprecation is under the control > of the same macro, even though these aren't actually from POSIX. This pull request has now been integrated. Changeset: fe6e0c0b Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/fe6e0c0beba5065cca4e2e5d1a89125d5bd0dba6 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8286371: Avoid use of deprecated str[n]icmp Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/8590 From ccheung at openjdk.java.net Mon May 9 16:04:50 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 9 May 2022 16:04:50 GMT Subject: RFR: 8285914: AppCDS crash when using shared archive with old class file [v4] In-Reply-To: References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> Message-ID: On Fri, 6 May 2022 06:29:41 GMT, Calvin Cheung wrote: >> Please review this change for an additional check before archiving a lambda proxy class. If the nest host of an lambda proxy class implements an old (major version < JDK_6 (50)) interface, the lambda proxy class should not be archived. This avoids accessing a null nest host during runtime while loading the lambda proxy class from the CDS archive. >> >> Passed the test in the bug report. >> >> Passed CI tiers 1 - 4 testing (including the new tests). > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > exclude lambda proxy class in CleanupDumpTimeLambdaProxyClassTable Thanks Ioi and David for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8540 From ccheung at openjdk.java.net Mon May 9 16:04:52 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 9 May 2022 16:04:52 GMT Subject: Integrated: 8285914: AppCDS crash when using shared archive with old class file In-Reply-To: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> References: <0iO_3lBJOdEIEv_fP9HpyKkkNNyCOaYyJr-9ry4hAIg=.a8c793d1-29de-4c5b-b16b-62f7dd10b6c0@github.com> Message-ID: <9JtPRJwyaTbla6hKO8tdhmBHgue7jzyeSEWfkBvcZMQ=.977cb954-2fba-4b6a-8bf6-f5a3d6a5a255@github.com> On Wed, 4 May 2022 18:20:14 GMT, Calvin Cheung wrote: > Please review this change for an additional check before archiving a lambda proxy class. If the nest host of an lambda proxy class implements an old (major version < JDK_6 (50)) interface, the lambda proxy class should not be archived. This avoids accessing a null nest host during runtime while loading the lambda proxy class from the CDS archive. > > Passed the test in the bug report. > > Passed CI tiers 1 - 4 testing (including the new tests). This pull request has now been integrated. Changeset: 29ccb8fb Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/29ccb8fbb83037882d59bda35865d3aed1780f9d Stats: 227 lines in 6 files changed: 218 ins; 1 del; 8 mod 8285914: AppCDS crash when using shared archive with old class file Reviewed-by: dholmes, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/8540 From duke at openjdk.java.net Mon May 9 17:38:58 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 9 May 2022 17:38:58 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL [v2] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 12:51:10 GMT, David Holmes wrote: >> How about `LogTagSet& _tagset`? There are more examples of `_tagset` members in UL, so it's consistent. > > That seems a bit odd to me. Why can't we use the actual thing we will log to? The description of LogMessage is that it is a multi-part log entry that is accumulated until we flush it by writing to the actual log device. This is the dependency-structure of UL before this PR (this PR moves the arrows into `LogImpl` directly into `LogTagSet`). `LogTagSet` knows what it logs to, because it has access to the `LogOutputList`, nothing else has such info (which is why every arrow goes into LogTagSet). This is why `LogMessage` doesn't know what it will flush to, `LogTagSet` redirects to the correct outputs. ![loggers](https://user-images.githubusercontent.com/103041674/167464762-80c6cd61-797a-4bd8-b7f3-609a8d95a0e7.png) Circles = external API, rectangle = internal to UL. ------------- PR: https://git.openjdk.java.net/jdk/pull/8541 From prr at openjdk.java.net Mon May 9 18:06:54 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 18:06:54 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: <4TPEAEob1ukdLvqdnzddoOBEGrsVfkaQEG5-307Mxjw=.130e42ef-8170-4dcf-bce5-3b69615a6c2a@github.com> On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From lmesnik at openjdk.java.net Mon May 9 18:10:14 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 9 May 2022 18:10:14 GMT Subject: RFR: 8284980: Test vmTestbase/nsk/stress/except/except010.java times out with -Xcomp -XX:+DeoptimizeALot Message-ID: Test executes method recursively and works too long. It the same issue as [JDK-8139875](https://bugs.openjdk.java.net/browse/JDK-8139875) The test shouldn't be run with DeoptimizeALot ------------- Commit messages: - copyrights fixed - 8284980: Test vmTestbase/nsk/stress/except/except010.java times out with -Xcomp -XX:+DeoptimizeALot Changes: https://git.openjdk.java.net/jdk/pull/8602/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8602&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284980 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8602.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8602/head:pull/8602 PR: https://git.openjdk.java.net/jdk/pull/8602 From dcubed at openjdk.java.net Mon May 9 19:28:13 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 9 May 2022 19:28:13 GMT Subject: Integrated: 8286435: JDK-8284316 caused validate-source to fail in Tier1 Message-ID: A trivial to solve JDK-8284316 caused validate-source to fail in Tier1. ------------- Commit messages: - 8286435: JDK-8284316 caused validate-source to fail in Tier1 Changes: https://git.openjdk.java.net/jdk/pull/8607/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8607&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286435 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8607.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8607/head:pull/8607 PR: https://git.openjdk.java.net/jdk/pull/8607 From mikael at openjdk.java.net Mon May 9 19:28:13 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Mon, 9 May 2022 19:28:13 GMT Subject: Integrated: 8286435: JDK-8284316 caused validate-source to fail in Tier1 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 19:16:46 GMT, Daniel D. Daugherty wrote: > A trivial to solve JDK-8284316 caused validate-source to fail in Tier1. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8607 From dcubed at openjdk.java.net Mon May 9 19:28:14 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 9 May 2022 19:28:14 GMT Subject: Integrated: 8286435: JDK-8284316 caused validate-source to fail in Tier1 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 19:18:23 GMT, Mikael Vidstedt wrote: >> A trivial to solve JDK-8284316 caused validate-source to fail in Tier1. > > Marked as reviewed by mikael (Reviewer). @vidmik - Thanks for the lightning fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8607 From dcubed at openjdk.java.net Mon May 9 19:28:15 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 9 May 2022 19:28:15 GMT Subject: Integrated: 8286435: JDK-8284316 caused validate-source to fail in Tier1 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 19:16:46 GMT, Daniel D. Daugherty wrote: > A trivial to solve JDK-8284316 caused validate-source to fail in Tier1. This pull request has now been integrated. Changeset: 02e5fc04 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/02e5fc04ccd046e9904302548f131b89d5f2954a Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8286435: JDK-8284316 caused validate-source to fail in Tier1 Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/8607 From dlong at openjdk.java.net Mon May 9 19:40:50 2022 From: dlong at openjdk.java.net (Dean Long) Date: Mon, 9 May 2022 19:40:50 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator [v2] In-Reply-To: <92fzc9FoxO86AUcAIk4GqQ7xHeihtURQAIJzafs0yC4=.25ce9fb9-55fa-4885-b292-36f28fb5192c@github.com> References: <92fzc9FoxO86AUcAIk4GqQ7xHeihtURQAIJzafs0yC4=.25ce9fb9-55fa-4885-b292-36f28fb5192c@github.com> Message-ID: On Mon, 9 May 2022 12:51:33 GMT, Zhengyu Gu wrote: >> jni_GetStringUTFChars() calls `AllocateHeap(length + 1, mtInternal, 0, AllocFailStrategy::RETURN_NULL);` to allocate memory, where it passes `0` as `NativeCallStack` reference, that results construction of `NativeCallStack`. >> >> In `NativeCallStack`'s constructor, it performs stack walk to capture native call stack. This is unnecessary, if NMT detail tracking is not enabled. >> >> It should use `char* AllocateHeap(size_t size, >> MEMFLAGS flags, >> AllocFailType alloc_failmode /* = AllocFailStrategy::EXIT_OOM*/)` heap allocator instead. > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Thomas' suggestion Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8579 From zgu at openjdk.java.net Mon May 9 19:48:56 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 9 May 2022 19:48:56 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator [v2] In-Reply-To: References: <92fzc9FoxO86AUcAIk4GqQ7xHeihtURQAIJzafs0yC4=.25ce9fb9-55fa-4885-b292-36f28fb5192c@github.com> Message-ID: On Mon, 9 May 2022 19:37:01 GMT, Dean Long wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> Thomas' suggestion > > Marked as reviewed by dlong (Reviewer). Thanks, @dean-long @tstuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8579 From zgu at openjdk.java.net Mon May 9 19:48:57 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 9 May 2022 19:48:57 GMT Subject: Integrated: 8286331: jni_GetStringUTFChars() uses wrong heap allocator In-Reply-To: References: Message-ID: On Fri, 6 May 2022 17:54:45 GMT, Zhengyu Gu wrote: > jni_GetStringUTFChars() calls `AllocateHeap(length + 1, mtInternal, 0, AllocFailStrategy::RETURN_NULL);` to allocate memory, where it passes `0` as `NativeCallStack` reference, that results construction of `NativeCallStack`. > > In `NativeCallStack`'s constructor, it performs stack walk to capture native call stack. This is unnecessary, if NMT detail tracking is not enabled. > > It should use `char* AllocateHeap(size_t size, > MEMFLAGS flags, > AllocFailType alloc_failmode /* = AllocFailStrategy::EXIT_OOM*/)` heap allocator instead. This pull request has now been integrated. Changeset: b0d2b0a3 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/b0d2b0a3553cbb2db23d543b98ab1401b3dbfa91 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8286331: jni_GetStringUTFChars() uses wrong heap allocator Reviewed-by: dlong, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8579 From dcubed at openjdk.java.net Mon May 9 20:20:34 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 9 May 2022 20:20:34 GMT Subject: RFR: 8283651: nsk/jvmti/SuspendThread/suspendthrd003 may leak native memory Message-ID: A trivial fix to nsk_jvmti_threadByName() to solve a native memory leak. This fix has been stress tested with my StressWrapper60M_NMT_detail_suspendthrd003.java test and I did NMT detailed monitoring for the whole 60M run. Total committed memory has gone down from 1.17GB to 300MB. Prior to my last rebase, it was down to 239MB. I ran the fix thru Mach5 Tier[1-7] with no failures. I just rebased the fix to the latest jdk/jdk and Mach5 Tier[1-3] have passed with no failures. Tier[45] are still running. ------------- Commit messages: - 8283651.cr0 Changes: https://git.openjdk.java.net/jdk/pull/8609/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8609&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283651 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8609.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8609/head:pull/8609 PR: https://git.openjdk.java.net/jdk/pull/8609 From kbarrett at openjdk.java.net Mon May 9 21:03:41 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 9 May 2022 21:03:41 GMT Subject: RFR: 8286424: GetVersionEx is deprecated Message-ID: Please review this change to explicitly disable deprecation warnings for the two uses of GetVersionEx in HotSpot code. This is a step toward being able to remove the global (to HotSpot) disable of deprecation warnings for Windows. (It is because of that global disable that these uses don't currently generate warnings.) There are uses of this function in non-HotSpot parts of the JDK. These are not being changed. They all disable the warning in some fashion, as appropriate to that area's usage. This change is only about HotSpot usage, and wanting to remove global deprecation disabling from HotSpot builds. ------------- Commit messages: - suppress deprecation warning for GetVersionEx Changes: https://git.openjdk.java.net/jdk/pull/8611/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8611&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286424 Stats: 17 lines in 1 file changed: 9 ins; 3 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8611/head:pull/8611 PR: https://git.openjdk.java.net/jdk/pull/8611 From dcubed at openjdk.java.net Mon May 9 21:30:10 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 9 May 2022 21:30:10 GMT Subject: RFR: 8286442: ProblemList compiler/c2/irTests/TestSkeletonPredicates.java in -Xcomp mode Message-ID: A trivial fix to ProblemList compiler/c2/irTests/TestSkeletonPredicates.java in -Xcomp mode. ------------- Commit messages: - 8286442: ProblemList compiler/c2/irTests/TestSkeletonPredicates.java in -Xcomp mode Changes: https://git.openjdk.java.net/jdk/pull/8612/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8612&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286442 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8612.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8612/head:pull/8612 PR: https://git.openjdk.java.net/jdk/pull/8612 From ctornqvi at openjdk.java.net Mon May 9 21:32:16 2022 From: ctornqvi at openjdk.java.net (Christian Tornqvist) Date: Mon, 9 May 2022 21:32:16 GMT Subject: RFR: 8286442: ProblemList compiler/c2/irTests/TestSkeletonPredicates.java in -Xcomp mode In-Reply-To: References: Message-ID: <9tq4e18r_G__6IPrgDpvtzEAosFI77JuqeIUddo5tqQ=.ee72c7cd-67e1-4944-beb8-06df1f5d8964@github.com> On Mon, 9 May 2022 21:23:12 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList compiler/c2/irTests/TestSkeletonPredicates.java in -Xcomp mode. Marked as reviewed by ctornqvi (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8612 From dcubed at openjdk.java.net Mon May 9 21:37:54 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 9 May 2022 21:37:54 GMT Subject: RFR: 8286442: ProblemList compiler/c2/irTests/TestSkeletonPredicates.java in -Xcomp mode In-Reply-To: <9tq4e18r_G__6IPrgDpvtzEAosFI77JuqeIUddo5tqQ=.ee72c7cd-67e1-4944-beb8-06df1f5d8964@github.com> References: <9tq4e18r_G__6IPrgDpvtzEAosFI77JuqeIUddo5tqQ=.ee72c7cd-67e1-4944-beb8-06df1f5d8964@github.com> Message-ID: On Mon, 9 May 2022 21:29:59 GMT, Christian Tornqvist wrote: >> A trivial fix to ProblemList compiler/c2/irTests/TestSkeletonPredicates.java in -Xcomp mode. > > Marked as reviewed by ctornqvi (Reviewer). @ctornqvi - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8612 From dcubed at openjdk.java.net Mon May 9 21:37:56 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 9 May 2022 21:37:56 GMT Subject: Integrated: 8286442: ProblemList compiler/c2/irTests/TestSkeletonPredicates.java in -Xcomp mode In-Reply-To: References: Message-ID: On Mon, 9 May 2022 21:23:12 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList compiler/c2/irTests/TestSkeletonPredicates.java in -Xcomp mode. This pull request has now been integrated. Changeset: c28a6361 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/c28a63617dd64e009df8b548d58d2dd72579a3ad Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8286442: ProblemList compiler/c2/irTests/TestSkeletonPredicates.java in -Xcomp mode Reviewed-by: ctornqvi ------------- PR: https://git.openjdk.java.net/jdk/pull/8612 From dcubed at openjdk.java.net Mon May 9 22:05:06 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 9 May 2022 22:05:06 GMT Subject: RFR: 8283651: nsk/jvmti/SuspendThread/suspendthrd003 may leak native memory In-Reply-To: <5l5s-2txgF3FLxnQQkQ0_GfdYPTdtKs7D4p0phm9ym4=.86818859-37dc-4dbe-9c1d-c073b4d1bf77@github.com> References: <5l5s-2txgF3FLxnQQkQ0_GfdYPTdtKs7D4p0phm9ym4=.86818859-37dc-4dbe-9c1d-c073b4d1bf77@github.com> Message-ID: On Mon, 9 May 2022 21:57:41 GMT, Leonid Mesnik wrote: >> A trivial fix to nsk_jvmti_threadByName() to solve a native memory leak. >> >> This fix has been stress tested with my StressWrapper60M_NMT_detail_suspendthrd003.java >> test and I did NMT detailed monitoring for the whole 60M run. Total committed memory has >> gone down from 1.17GB to 300MB. Prior to my last rebase, it was down to 239MB. >> >> I ran the fix thru Mach5 Tier[1-7] with no failures. I just rebased the fix to the latest jdk/jdk >> and Mach5 Tier[1-3] have passed with no failures. Tier[45] are still running. > > Marked as reviewed by lmesnik (Reviewer). @lmesnik - Thanks for the review! Do you agree that this is a trivial fix? ------------- PR: https://git.openjdk.java.net/jdk/pull/8609 From dcubed at openjdk.java.net Mon May 9 22:05:06 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 9 May 2022 22:05:06 GMT Subject: RFR: 8283651: nsk/jvmti/SuspendThread/suspendthrd003 may leak native memory In-Reply-To: References: Message-ID: On Mon, 9 May 2022 20:15:21 GMT, Daniel D. Daugherty wrote: > A trivial fix to nsk_jvmti_threadByName() to solve a native memory leak. > > This fix has been stress tested with my StressWrapper60M_NMT_detail_suspendthrd003.java > test and I did NMT detailed monitoring for the whole 60M run. Total committed memory has > gone down from 1.17GB to 300MB. Prior to my last rebase, it was down to 239MB. > > I ran the fix thru Mach5 Tier[1-7] with no failures. I just rebased the fix to the latest jdk/jdk > and Mach5 Tier[1-3] have passed with no failures. Tier[45] are still running. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8609 From lmesnik at openjdk.java.net Mon May 9 22:05:05 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 9 May 2022 22:05:05 GMT Subject: RFR: 8283651: nsk/jvmti/SuspendThread/suspendthrd003 may leak native memory In-Reply-To: References: Message-ID: <5l5s-2txgF3FLxnQQkQ0_GfdYPTdtKs7D4p0phm9ym4=.86818859-37dc-4dbe-9c1d-c073b4d1bf77@github.com> On Mon, 9 May 2022 20:15:21 GMT, Daniel D. Daugherty wrote: > A trivial fix to nsk_jvmti_threadByName() to solve a native memory leak. > > This fix has been stress tested with my StressWrapper60M_NMT_detail_suspendthrd003.java > test and I did NMT detailed monitoring for the whole 60M run. Total committed memory has > gone down from 1.17GB to 300MB. Prior to my last rebase, it was down to 239MB. > > I ran the fix thru Mach5 Tier[1-7] with no failures. I just rebased the fix to the latest jdk/jdk > and Mach5 Tier[1-3] have passed with no failures. Tier[45] are still running. Marked as reviewed by lmesnik (Reviewer). Yes, I agree, the fix is trivial. ------------- PR: https://git.openjdk.java.net/jdk/pull/8609 From dcubed at openjdk.java.net Mon May 9 22:06:21 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 9 May 2022 22:06:21 GMT Subject: Integrated: 8283651: nsk/jvmti/SuspendThread/suspendthrd003 may leak native memory In-Reply-To: References: Message-ID: On Mon, 9 May 2022 20:15:21 GMT, Daniel D. Daugherty wrote: > A trivial fix to nsk_jvmti_threadByName() to solve a native memory leak. > > This fix has been stress tested with my StressWrapper60M_NMT_detail_suspendthrd003.java > test and I did NMT detailed monitoring for the whole 60M run. Total committed memory has > gone down from 1.17GB to 300MB. Prior to my last rebase, it was down to 239MB. > > I ran the fix thru Mach5 Tier[1-7] with no failures. I just rebased the fix to the latest jdk/jdk > and Mach5 Tier[1-3] have passed with no failures. Tier[45] are still running. This pull request has now been integrated. Changeset: 61450bb0 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/61450bb061ecda9700ddbd387a1f0659ebd1cced Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod 8283651: nsk/jvmti/SuspendThread/suspendthrd003 may leak native memory Reviewed-by: lmesnik ------------- PR: https://git.openjdk.java.net/jdk/pull/8609 From lmesnik at openjdk.java.net Tue May 10 00:16:27 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 10 May 2022 00:16:27 GMT Subject: RFR: 8284980: Test vmTestbase/nsk/stress/except/except010.java times out with -Xcomp -XX:+DeoptimizeALot [v2] In-Reply-To: References: Message-ID: > Test executes method recursively and works too long. > > It the same issue as [JDK-8139875](https://bugs.openjdk.java.net/browse/JDK-8139875) > > The test shouldn't be run with DeoptimizeALot Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: Rename Read2.jav` to Read2.java reverted renaming ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8602/files - new: https://git.openjdk.java.net/jdk/pull/8602/files/84a75c5c..900deb58 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8602&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8602&range=00-01 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8602.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8602/head:pull/8602 PR: https://git.openjdk.java.net/jdk/pull/8602 From dholmes at openjdk.java.net Tue May 10 02:36:42 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 10 May 2022 02:36:42 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL [v2] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 11:15:40 GMT, Johan Sj?l?n wrote: >> This PR cleans up some minor annoyances in the UL code. >> >> Note that the change from `LogImpl` to `LogTagSet` is equivalent, we're essentially inlining the calls that `LogImpl` would have made. This simplifies understanding ("why do we need `LogImpl` here?" was my question, answer: We don't!)' >> >> *Edit:* Passes tier1. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Use _tagset This all seems fine to me now. Thanks for explaining everything. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8541 From dholmes at openjdk.java.net Tue May 10 02:36:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 10 May 2022 02:36:43 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL [v2] In-Reply-To: References: Message-ID: <5Tgb4ygDdy7uBmNJX2IVVLgG-R6NIKKS8idAUh0caG0=.67d7bab2-b92e-4e89-970b-0800605ffaa9@github.com> On Mon, 9 May 2022 17:32:48 GMT, Johan Sj?l?n wrote: >> That seems a bit odd to me. Why can't we use the actual thing we will log to? The description of LogMessage is that it is a multi-part log entry that is accumulated until we flush it by writing to the actual log device. > > This is the dependency-structure of UL before this PR (this PR moves the arrows into `LogImpl` directly into `LogTagSet`). `LogTagSet` knows what it logs to, because it has access to the `LogOutputList`, nothing else has such info (which is why every arrow goes into LogTagSet). This is why `LogMessage` doesn't know what it will flush to, `LogTagSet` redirects to the correct outputs. > > ![loggers](https://user-images.githubusercontent.com/103041674/167464762-80c6cd61-797a-4bd8-b7f3-609a8d95a0e7.png) > > Circles = external API, rectangle = internal to UL. Thanks for that picture! I think my main problem is that `LogTagSet` is actually a much more fundamental abstraction than I was thinking it was from the name. It really embodies a complete entity of logging that I can't readily describe without using words (target, configuration) already used for something else in UL. In that sense `LogImpl` actually did add a level of abstraction that made things a little clearer (and I think `LogImpl` is perhaps what they chose to describe that because they couldn't just use `Log`). Okay things are a bit clearer now. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8541 From dholmes at openjdk.java.net Tue May 10 03:14:40 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 10 May 2022 03:14:40 GMT Subject: RFR: 8286424: GetVersionEx is deprecated In-Reply-To: References: Message-ID: On Mon, 9 May 2022 20:56:25 GMT, Kim Barrett wrote: > Please review this change to explicitly disable deprecation warnings for the > two uses of GetVersionEx in HotSpot code. This is a step toward being able to > remove the global (to HotSpot) disable of deprecation warnings for Windows. > (It is because of that global disable that these uses don't currently generate > warnings.) > > There are uses of this function in non-HotSpot parts of the JDK. These are not > being changed. They all disable the warning in some fashion, as appropriate to > that area's usage. This change is only about HotSpot usage, and wanting to > remove global deprecation disabling from HotSpot builds. Hi Kim, AFAICS both uses of this only try to determine whether we are running a server or client/workstation version - and for that the `IsWindowsServer()` API exists: https://docs.microsoft.com/en-us/windows/win32/api/versionhelpers/nf-versionhelpers-iswindowsserver But the fix itself is fine for silencing the deprecation warning (a deprecation that I didn't find documented ??). Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8611 From iklam at openjdk.java.net Tue May 10 04:30:20 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 10 May 2022 04:30:20 GMT Subject: RFR: 8285518: CDS assert: visibility cannot change between dump time and runtime Message-ID: This PR fixes a timing hole in the CDS class loading code. The bug happens with the `jdk/internal/ref/Cleaner` class, which is loaded by the boot classloader. - The loading of `Cleaner` is initiated - We look up the `pkg_entry` for this class - At this point, the module system is not yet fully initialized, so package information is not yet available, and we get `pkg_entry == NULL` - Later, in `SystemDictionary::is_shared_class_visible_impl`, we try to check the visbility of this class, but now the module system is fully initialized, so the NULL `pkg_entry` is no longer valid. The fix is to always reload the `pkg_entry` if it's NULL. This should happen very rarely because `pkg_entry` for archived classes are usually non-null. This timing hole existed before but has been triggered (once) only after Loom changed the bootstrap sequence of the reference thread. Nonetheless we should backport to older JDKs since there's still a theoretical chance this it may happen, and the fix is simple. ------------- Commit messages: - removed debug code - 8285518: CDS assert: visibility cannot change between dump time and runtime Changes: https://git.openjdk.java.net/jdk/pull/8392/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8392&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285518 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8392.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8392/head:pull/8392 PR: https://git.openjdk.java.net/jdk/pull/8392 From dholmes at openjdk.java.net Tue May 10 04:38:56 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 10 May 2022 04:38:56 GMT Subject: RFR: 8285518: CDS assert: visibility cannot change between dump time and runtime In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 23:48:14 GMT, Ioi Lam wrote: > This PR fixes a timing hole in the CDS class loading code. The bug happens with the `jdk/internal/ref/Cleaner` class, which is loaded by the boot classloader. > > - The loading of `Cleaner` is initiated > - We look up the `pkg_entry` for this class > - At this point, the module system is not yet fully initialized, so package information is not yet available, and we get `pkg_entry == NULL` > - Later, in `SystemDictionary::is_shared_class_visible_impl`, we try to check the visbility of this class, but now the module system is fully initialized, so the NULL `pkg_entry` is no longer valid. > > The fix is to always reload the `pkg_entry` if it's NULL. This should happen very rarely because `pkg_entry` for archived classes are usually non-null. > > This timing hole existed before but has been triggered (once) only after Loom changed the bootstrap sequence of the reference thread. Nonetheless we should backport to older JDKs since there's still a theoretical chance this it may happen, and the fix is simple. Seems quite reasonable. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8392 From alanb at openjdk.java.net Tue May 10 05:46:40 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 10 May 2022 05:46:40 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Tue May 10 06:48:40 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 10 May 2022 06:48:40 GMT Subject: Integrated: JDK-8285730: unify _WIN32_WINNT settings In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken wrote: > Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : > https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt > Macros for Conditional Declarations > "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." > > However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). This pull request has now been integrated. Changeset: 4fd79a6a Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/4fd79a6ad2683e4863bd4e311cb01cbc30ebf57f Stats: 33 lines in 7 files changed: 2 ins; 25 del; 6 mod 8285730: unify _WIN32_WINNT settings Reviewed-by: dholmes, erikj, ihse, prr, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From cstein at openjdk.java.net Tue May 10 07:34:33 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 10 May 2022 07:34:33 GMT Subject: RFR: 8286460: Remove dependence on JAR filename in CDS tests Message-ID: Use location information stored in JUnit `Test` class' runtime representation in order to remove a hard-coded dependence on JUnit's JAR filename. ------------- Commit messages: - 8286460: Remove dependence on JAR filename in CDS tests Changes: https://git.openjdk.java.net/jdk/pull/8624/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8624&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286460 Stats: 112 lines in 14 files changed: 0 ins; 98 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/8624.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8624/head:pull/8624 PR: https://git.openjdk.java.net/jdk/pull/8624 From duke at openjdk.java.net Tue May 10 11:16:00 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Tue, 10 May 2022 11:16:00 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL [v2] In-Reply-To: <5Tgb4ygDdy7uBmNJX2IVVLgG-R6NIKKS8idAUh0caG0=.67d7bab2-b92e-4e89-970b-0800605ffaa9@github.com> References: <5Tgb4ygDdy7uBmNJX2IVVLgG-R6NIKKS8idAUh0caG0=.67d7bab2-b92e-4e89-970b-0800605ffaa9@github.com> Message-ID: On Tue, 10 May 2022 02:30:12 GMT, David Holmes wrote: >> This is the dependency-structure of UL before this PR (this PR moves the arrows into `LogImpl` directly into `LogTagSet`). `LogTagSet` knows what it logs to, because it has access to the `LogOutputList`, nothing else has such info (which is why every arrow goes into LogTagSet). This is why `LogMessage` doesn't know what it will flush to, `LogTagSet` redirects to the correct outputs. >> >> ![loggers](https://user-images.githubusercontent.com/103041674/167464762-80c6cd61-797a-4bd8-b7f3-609a8d95a0e7.png) >> >> Circles = external API, rectangle = internal to UL. > > Thanks for that picture! I think my main problem is that `LogTagSet` is actually a much more fundamental abstraction than I was thinking it was from the name. It really embodies a complete entity of logging that I can't readily describe without using words (target, configuration) already used for something else in UL. In that sense `LogImpl` actually did add a level of abstraction that made things a little clearer (and I think `LogImpl` is perhaps what they chose to describe that because they couldn't just use `Log`). > Okay things are a bit clearer now. Thanks. You're welcome! This confusion is exactly why I'm trying to clean things up (I drew the picture for me originally :-)). Thank you for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8541 From mdegtyarev at gmail.com Tue May 10 03:08:36 2022 From: mdegtyarev at gmail.com (Maxim Degtyarev) Date: Tue, 10 May 2022 06:08:36 +0300 Subject: MethodType runtime API vs constant pool entry of the same type Message-ID: Inspired by https://mail.openjdk.java.net/pipermail/compiler-dev/2022-May/019558.html According to the JDK 17 `j.l.i.MethodType` javadoc [1]: Like classes and strings, method types can also be represented directly in a class file's constant pool as constants. A method type may be loaded by an ldc instruction which refers to a suitable CONSTANT_MethodType constant pool entry. The entry refers to a CONSTANT_Utf8 spelling for the descriptor string. (For full details on method type constants, see sections 4.4.8 and 5.4.3.5 of the Java Virtual Machine Specification.) If I understand it correctly, this implies that any `MethodType` instance that can be successfully created with the call to `MethodType.fromMethodDescriptorString()` method can be also represented as a constant pool entry of type MethodType. Now consider the following example: // main/TestRuntime.java package main; import java.lang.invoke.MethodType; public class TestRuntime { public static void main(String... args) { System.out.println( MethodType.fromMethodDescriptorString( "()Lfoo/Foo$Bar;", TestRuntime.class.getClassLoader() ) ); } } // main/TestConstantPool.jasm /** * * You need asmtools to assemble this example. * * To assemble run: * * java -jar asmtools.jar jasm -g TestConstantPool.jasm * * */ package main; super public class TestConstantPool version 52:0 { public Method "":"()V" stack 1 locals 1 { aload_0; invokespecial Method java/lang/Object."":"()V"; return; } public static varargs Method main:"([Ljava/lang/String;)V" stack 2 locals 1 { getstatic Field java/lang/System.out:"Ljava/io/PrintStream;"; ldc MethodType "()Lfoo/Foo$Bar;"; invokevirtual Method java/io/PrintStream.println:"(Ljava/lang/Object;)V"; return; } } // end Class TestConstantPool // foo/Foo.java package foo; public class Foo { public static Bar bar() { return new Bar(); } static class Bar {} } Both `main.TestRuntime` and `main.TestConstantPool` are functionally equal and should print string representation of the `MethodType` instance. While `main.TestRuntime` behaves as expected: $ java main.TestRuntime ()Bar The `main.TestConstantPool` failed with `j.l.IllegalAccessError`: $ java main.TestConstantPool Exception in thread "main" java.lang.IllegalAccessError: tried to access class foo.Foo$Bar from class main.TestConstantPool at main.TestConstantPool.main(TestConstantPool.jasm:18) However, if we declare class `foo.Foo.Bar` public then both `TestRuntime` and `TestConstantPool` run without exceptions. Checked both with `Java(TM) SE Runtime Environment (build 1.8.0_152-b16)` and `OpenJDK Runtime Environment (build 19-ea+21-1482)`. Questions: 1) Shouldn't both examples expose equal behaviour? 2) Which of 2 observed behaviours is correct? Examples from this message can be found at [2] [1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/MethodType.html [2] https://github.com/Maccimo/MethodType-API-vs-ConstantPool From sgehwolf at openjdk.java.net Tue May 10 12:40:42 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 10 May 2022 12:40:42 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems Message-ID: Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter). In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running. Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round). Testing: - [x] Added unit tests - [x] GHA - [x] Container tests on cgroups v1 Linux. Continue to pass ------------- Commit messages: - 8286212: Cgroup v1 initialization causes NPE on some systems Changes: https://git.openjdk.java.net/jdk/pull/8629/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8629&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286212 Stats: 267 lines in 7 files changed: 256 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8629.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8629/head:pull/8629 PR: https://git.openjdk.java.net/jdk/pull/8629 From mbaesken at openjdk.java.net Tue May 10 12:49:44 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 10 May 2022 12:49:44 GMT Subject: RFR: JDK-8286198: [linux] Fix process-memory information In-Reply-To: References: Message-ID: On Thu, 5 May 2022 14:55:01 GMT, Thomas Stuefe wrote: > We use mallinfo/mallinfo2 to obtain information about the glibc used memory, but there is an error which causes it to be correct only for fine granular malloc allocations. glibc puts larger allocations in mmap-allocated areas, which were missing from the old calculation. > > This patch fixes that; it also adds information about memory retained in the glibc after free. Note that the latter unfortunately does not follow glibc trims because trimming is done AFAIK with madvice(MADV_DONTNEED) which does not seem to affect glibc internal bookkeeping. Still its a very valuable thing to know in order to estimate glibc overhead especially in fine granular mass allocation scenarios. > > Tests: Lots of manual tests with various malloc loads and granularities, in addition to automated tests. Hi Thomas, when looking at the manpage https://man7.org/linux/man-pages/man3/mallinfo.3.html then the manpage is describing "Total allocated space" as just uordblks , see the output in the example program of the manpage. So maybe it would be better to print mi.uordblks and mi.hblkhd separately so that someone looking at the mallinfo manpage finds exactly the same terminology described there in the JVM output? Maybe in some situations it is useful too to get both values ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8553 From david.holmes at oracle.com Tue May 10 13:12:16 2022 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 May 2022 23:12:16 +1000 Subject: MethodType runtime API vs constant pool entry of the same type In-Reply-To: References: Message-ID: <0f45052f-22e8-a720-1add-734bf1d78743@oracle.com> Hi Maxim, On 10/05/2022 1:08 pm, Maxim Degtyarev wrote: > Inspired by https://mail.openjdk.java.net/pipermail/compiler-dev/2022-May/019558.html > > According to the JDK 17 `j.l.i.MethodType` javadoc [1]: > > Like classes and strings, method types can also be represented > directly in a class file's constant pool as constants. > A method type may be loaded by an ldc instruction which refers to a > suitable CONSTANT_MethodType constant pool entry. > The entry refers to a CONSTANT_Utf8 spelling for the descriptor > string. (For full details on method type constants, > see sections 4.4.8 and 5.4.3.5 of the Java Virtual Machine Specification.) > > > If I understand it correctly, this implies that any `MethodType` > instance that can be successfully created with the > call to `MethodType.fromMethodDescriptorString()` method can be also > represented as a constant pool entry of type MethodType. > > > Now consider the following example: > > > // main/TestRuntime.java > package main; > > import java.lang.invoke.MethodType; > > public class TestRuntime { > > public static void main(String... args) { > System.out.println( > MethodType.fromMethodDescriptorString( > "()Lfoo/Foo$Bar;", > TestRuntime.class.getClassLoader() > ) > ); > } > > } > > > // main/TestConstantPool.jasm > /** > * > * You need asmtools > to assemble this example. > * > * To assemble run: > * > * java -jar asmtools.jar jasm -g TestConstantPool.jasm > * > * > */ > package main; > > super public class TestConstantPool > version 52:0 > { > public Method "":"()V" > stack 1 locals 1 > { > aload_0; > invokespecial Method java/lang/Object."":"()V"; > return; > } > > public static varargs Method main:"([Ljava/lang/String;)V" > stack 2 locals 1 > { > getstatic Field java/lang/System.out:"Ljava/io/PrintStream;"; > ldc MethodType "()Lfoo/Foo$Bar;"; > invokevirtual Method > java/io/PrintStream.println:"(Ljava/lang/Object;)V"; > return; > > } > } // end Class TestConstantPool > > > // foo/Foo.java > package foo; > > public class Foo { > public static Bar bar() { > return new Bar(); > } > > static class Bar {} > } > > > Both `main.TestRuntime` and `main.TestConstantPool` are functionally > equal and should print > string representation of the `MethodType` instance. > > > While `main.TestRuntime` behaves as expected: > > $ java main.TestRuntime > ()Bar > > > The `main.TestConstantPool` failed with `j.l.IllegalAccessError`: > > $ java main.TestConstantPool > Exception in thread "main" java.lang.IllegalAccessError: tried to > access class foo.Foo$Bar from class main.TestConstantPool > at main.TestConstantPool.main(TestConstantPool.jasm:18) > > > However, if we declare class `foo.Foo.Bar` public then both > `TestRuntime` and `TestConstantPool` run without exceptions. > > > Checked both with `Java(TM) SE Runtime Environment (build > 1.8.0_152-b16)` and `OpenJDK Runtime Environment (build > 19-ea+21-1482)`. > > > Questions: > > 1) Shouldn't both examples expose equal behaviour? I believe so, yes. > 2) Which of 2 observed behaviours is correct? main.TestConstantPool. In both cases the type designated by the descriptor string has to be resolved. Resolution includes an access check. The ldc version is correctly resolving and performing the access check and so throwing the IllegalAccessError. It appears there is a bug in MethodType.fromMethodDescriptorString. Cheers, David ----- > > Examples from this message can be found at [2] > > > [1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/MethodType.html > [2] https://github.com/Maccimo/MethodType-API-vs-ConstantPool From stuefe at openjdk.java.net Tue May 10 13:17:49 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 10 May 2022 13:17:49 GMT Subject: RFR: JDK-8286198: [linux] Fix process-memory information In-Reply-To: References: Message-ID: On Tue, 10 May 2022 12:46:41 GMT, Matthias Baesken wrote: > Hi Thomas, when looking at the manpage https://man7.org/linux/man-pages/man3/mallinfo.3.html then the manpage is describing "Total allocated space" as just uordblks , see the output in the example program of the manpage. So maybe it would be better to print mi.uordblks and mi.hblkhd separately so that someone looking at the mallinfo manpage finds exactly the same terminology described there in the JVM output? Maybe in some situations it is useful too to get both values ? No, it's wrong. Hence this patch (see patch description - the number does not account for large areas allocated by the glibc with mmap). Not sure what the state of that manpage is. But I tested this very thoroughly. Observe: ### 1a) Old VM allocates 100mio 16 byte blocks: thomas at starfish:~$ jjjcmd de.stuefe.repros.AllocCHeap VM.info | grep C-Heap C-Heap outstanding allocations: 3128240K OK. ### 1b) Old VM allocates 16 100mio byte blocks: thomas at starfish:~$ jjjcmd de.stuefe.repros.AllocCHeap VM.info | grep C-Heap C-Heap outstanding allocations: 5782K Not OK. It says 5,7M, but we just allocated (payloadsize) ~1.6G. ### 2a) Patched VM allocates 100mio 16 byte blocks: thomas at starfish:~$ jjjcmd de.stuefe.repros.AllocCHeap VM.info | grep C-Heap C-Heap outstanding allocations: 3171375K, retained: 6440K Still OK. ### 2b) Patched VM allocates 16 100mio byte blocks: thomas at starfish:~$ jjjcmd de.stuefe.repros.AllocCHeap VM.info | grep C-Heap C-Heap outstanding allocations: 1611294K, retained: 2553K Now it looks legit too, compared to (1b). The lower size (1.6G vs 3.1G) stems from the massively lower glibc overhead when allocating large areas instead of tiny blocks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8553 From mbaesken at openjdk.java.net Tue May 10 13:31:53 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 10 May 2022 13:31:53 GMT Subject: RFR: JDK-8286198: [linux] Fix process-memory information In-Reply-To: References: Message-ID: <3fOOCGnNgpf6NMiwYIlNwPWaVSUDuo2kf1U_TUeYE0g=.78e33720-3b39-45e8-9cdc-1e3504b48218@github.com> On Thu, 5 May 2022 14:55:01 GMT, Thomas Stuefe wrote: > We use mallinfo/mallinfo2 to obtain information about the glibc used memory, but there is an error which causes it to be correct only for fine granular malloc allocations. glibc puts larger allocations in mmap-allocated areas, which were missing from the old calculation. > > This patch fixes that; it also adds information about memory retained in the glibc after free. Note that the latter unfortunately does not follow glibc trims because trimming is done AFAIK with madvice(MADV_DONTNEED) which does not seem to affect glibc internal bookkeeping. Still its a very valuable thing to know in order to estimate glibc overhead especially in fine granular mass allocation scenarios. > > Tests: Lots of manual tests with various malloc loads and granularities, in addition to automated tests. Marked as reviewed by mbaesken (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8553 From stuefe at openjdk.java.net Tue May 10 13:31:56 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 10 May 2022 13:31:56 GMT Subject: RFR: JDK-8286198: [linux] Fix process-memory information In-Reply-To: <99vNBvfeRDY4zO3lID4Oeh-hDV8RhgQHdT93Qyg6L10=.eed3e11d-5aca-4b65-ac7e-f4fd9b0a029c@github.com> References: <99vNBvfeRDY4zO3lID4Oeh-hDV8RhgQHdT93Qyg6L10=.eed3e11d-5aca-4b65-ac7e-f4fd9b0a029c@github.com> Message-ID: <3ZfxNwjmjqRKiOt9RLEqvLQ7lArqJSRSGv4pjj0DRTc=.929e4d58-c87a-4af3-8b64-528b433942e8@github.com> On Mon, 9 May 2022 02:52:22 GMT, David Holmes wrote: >> We use mallinfo/mallinfo2 to obtain information about the glibc used memory, but there is an error which causes it to be correct only for fine granular malloc allocations. glibc puts larger allocations in mmap-allocated areas, which were missing from the old calculation. >> >> This patch fixes that; it also adds information about memory retained in the glibc after free. Note that the latter unfortunately does not follow glibc trims because trimming is done AFAIK with madvice(MADV_DONTNEED) which does not seem to affect glibc internal bookkeeping. Still its a very valuable thing to know in order to estimate glibc overhead especially in fine granular mass allocation scenarios. >> >> Tests: Lots of manual tests with various malloc loads and granularities, in addition to automated tests. > > I don't understand your "free retained" terminology, but otherwise the changes seem fine and do what you describe. > > Thanks, > David Thanks @dholmes-ora and @MBaesken ! ------------- PR: https://git.openjdk.java.net/jdk/pull/8553 From stuefe at openjdk.java.net Tue May 10 13:31:58 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 10 May 2022 13:31:58 GMT Subject: Integrated: JDK-8286198: [linux] Fix process-memory information In-Reply-To: References: Message-ID: On Thu, 5 May 2022 14:55:01 GMT, Thomas Stuefe wrote: > We use mallinfo/mallinfo2 to obtain information about the glibc used memory, but there is an error which causes it to be correct only for fine granular malloc allocations. glibc puts larger allocations in mmap-allocated areas, which were missing from the old calculation. > > This patch fixes that; it also adds information about memory retained in the glibc after free. Note that the latter unfortunately does not follow glibc trims because trimming is done AFAIK with madvice(MADV_DONTNEED) which does not seem to affect glibc internal bookkeeping. Still its a very valuable thing to know in order to estimate glibc overhead especially in fine granular mass allocation scenarios. > > Tests: Lots of manual tests with various malloc loads and granularities, in addition to automated tests. This pull request has now been integrated. Changeset: 9e320d9a Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/9e320d9ab1813eda705d7318ef964092c50d1ade Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod 8286198: [linux] Fix process-memory information Reviewed-by: dholmes, mbaesken ------------- PR: https://git.openjdk.java.net/jdk/pull/8553 From kbarrett at openjdk.java.net Tue May 10 14:57:50 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 10 May 2022 14:57:50 GMT Subject: RFR: 8286424: GetVersionEx is deprecated In-Reply-To: References: Message-ID: On Tue, 10 May 2022 03:11:49 GMT, David Holmes wrote: > AFAICS both uses of this only try to determine whether we are running a server or client/workstation version - and for that the `IsWindowsServer()` API exists: > > https://docs.microsoft.com/en-us/windows/win32/api/versionhelpers/nf-versionhelpers-iswindowsserver You are right! I just assumed that in print_windows_version it was making further use of the info from GetVersionEx further down. But it's not! Because of that, I missed that IsWindowsServer could serve as a replacement. Thanks for spotting that; I'll make that change instead. > But the fix itself is fine for silencing the deprecation warning (a deprecation that I didn't find documented ??). https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversionexa "GetVersionExA may be altered or unavailable for releases after Windows 8.1. Instead, use the Version Helper functions." That sounds like "deprecated" without actually using that word, and a reasonable excuse for the compiler warning. ------------- PR: https://git.openjdk.java.net/jdk/pull/8611 From mbaesken at openjdk.java.net Tue May 10 15:05:13 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 10 May 2022 15:05:13 GMT Subject: RFR: JDK-8286459: compile error with VS2017 in continuationFreezeThaw.cpp Message-ID: After recent changes (loom?) we run into this compile error when using VS2017 : d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2463): error C2440: 'type cast': cannot convert from 'int (__cdecl *)(JavaThread *,intptr_t *)' to 'address' d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2463): note: Context does not allow for disambiguation of overloaded function d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2451): note: see reference to function template instantiation 'void ConfigResolve::resolve::type>(void)' being compiled d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2436): note: see reference to function template instantiation 'void ConfigResolve::resolve_gc(void)' being compiled d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2466): error C2440: 'type cast': cannot convert from 'intptr_t *(__cdecl *)(JavaThread *,int)' to 'address' d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2466): note: Context does not allow for disambiguation of overloaded function An additional cast can be added to make the issue go away. ------------- Commit messages: - JDK-8286459 Changes: https://git.openjdk.java.net/jdk/pull/8632/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8632&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286459 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8632.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8632/head:pull/8632 PR: https://git.openjdk.java.net/jdk/pull/8632 From clanger at openjdk.java.net Tue May 10 15:05:13 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 10 May 2022 15:05:13 GMT Subject: RFR: JDK-8286459: compile error with VS2017 in continuationFreezeThaw.cpp In-Reply-To: References: Message-ID: <-uK5YJRuitsgba0yJsm1F9caFl9sdp_66xwbQycYzpw=.e6b3b209-465f-4c54-b910-bd6767457268@github.com> On Tue, 10 May 2022 14:45:43 GMT, Matthias Baesken wrote: > After recent changes (loom?) we run into this compile error when using VS2017 : > > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2463): error C2440: 'type cast': cannot convert from 'int (__cdecl *)(JavaThread *,intptr_t *)' to 'address' > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2463): note: Context does not allow for disambiguation of overloaded function > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2451): note: see reference to function template instantiation 'void ConfigResolve::resolve::type>(void)' being compiled > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2436): note: see reference to function template instantiation 'void ConfigResolve::resolve_gc(void)' being compiled > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2466): error C2440: 'type cast': cannot convert from 'intptr_t *(__cdecl *)(JavaThread *,int)' to 'address' > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2466): note: Context does not allow for disambiguation of overloaded function > > An additional cast can be added to make the issue go away. OK, not nice this type of change but I guess it's acceptable. Maybe you want to add a comment that the (void*) is required to please VS2017? ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8632 From mdoerr at openjdk.java.net Tue May 10 15:05:14 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 10 May 2022 15:05:14 GMT Subject: RFR: JDK-8286459: compile error with VS2017 in continuationFreezeThaw.cpp In-Reply-To: References: Message-ID: On Tue, 10 May 2022 14:45:43 GMT, Matthias Baesken wrote: > After recent changes (loom?) we run into this compile error when using VS2017 : > > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2463): error C2440: 'type cast': cannot convert from 'int (__cdecl *)(JavaThread *,intptr_t *)' to 'address' > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2463): note: Context does not allow for disambiguation of overloaded function > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2451): note: see reference to function template instantiation 'void ConfigResolve::resolve::type>(void)' being compiled > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2436): note: see reference to function template instantiation 'void ConfigResolve::resolve_gc(void)' being compiled > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2466): error C2440: 'type cast': cannot convert from 'intptr_t *(__cdecl *)(JavaThread *,int)' to 'address' > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2466): note: Context does not allow for disambiguation of overloaded function > > An additional cast can be added to make the issue go away. Valid workaround for VS 2017. As long as this small change is sufficient, I think it should be done. I'd have done the same. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8632 From dcubed at openjdk.java.net Tue May 10 15:36:49 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 10 May 2022 15:36:49 GMT Subject: RFR: 8284980: Test vmTestbase/nsk/stress/except/except010.java times out with -Xcomp -XX:+DeoptimizeALot [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 00:16:27 GMT, Leonid Mesnik wrote: >> Test executes method recursively and works too long. >> >> It the same issue as [JDK-8139875](https://bugs.openjdk.java.net/browse/JDK-8139875) >> >> The test shouldn't be run with DeoptimizeALot > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > Rename Read2.jav` to Read2.java > > reverted renaming Thumbs up. This is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8602 From ccheung at openjdk.java.net Tue May 10 17:17:37 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 10 May 2022 17:17:37 GMT Subject: RFR: 8286460: Remove dependence on JAR filename in CDS tests In-Reply-To: References: Message-ID: On Tue, 10 May 2022 07:27:35 GMT, Christian Stein wrote: > Use location information stored in JUnit `Test` class' runtime representation in order to remove a hard-coded dependence on JUnit's JAR filename. Thanks for fixing this. Changes look good. Just one nit: copyright year needs to be updated. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8624 From iklam at openjdk.java.net Tue May 10 17:17:37 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 10 May 2022 17:17:37 GMT Subject: RFR: 8286460: Remove dependence on JAR filename in CDS tests In-Reply-To: References: Message-ID: On Tue, 10 May 2022 07:27:35 GMT, Christian Stein wrote: > Use location information stored in JUnit `Test` class' runtime representation in order to remove a hard-coded dependence on JUnit's JAR filename. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8624 From ccheung at openjdk.java.net Tue May 10 17:37:48 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 10 May 2022 17:37:48 GMT Subject: RFR: 8285518: CDS assert: visibility cannot change between dump time and runtime In-Reply-To: References: Message-ID: <0T5nTFQnM1ByQyVG0YGNzCuRz73R8evBx_YZAFVoiK4=.6ccd3594-ecc8-4c68-a14f-a2bd63c857b2@github.com> On Mon, 25 Apr 2022 23:48:14 GMT, Ioi Lam wrote: > This PR fixes a timing hole in the CDS class loading code. The bug happens with the `jdk/internal/ref/Cleaner` class, which is loaded by the boot classloader. > > - The loading of `Cleaner` is initiated > - We look up the `pkg_entry` for this class > - At this point, the module system is not yet fully initialized, so package information is not yet available, and we get `pkg_entry == NULL` > - Later, in `SystemDictionary::is_shared_class_visible_impl`, we try to check the visbility of this class, but now the module system is fully initialized, so the NULL `pkg_entry` is no longer valid. > > The fix is to always reload the `pkg_entry` if it's NULL. This should happen very rarely because `pkg_entry` for archived classes are usually non-null. > > This timing hole existed before but has been triggered (once) only after Loom changed the bootstrap sequence of the reference thread. Nonetheless we should backport to older JDKs since there's still a theoretical chance this it may happen, and the fix is simple. Looks good. Just curious usually how many classes would require reload of `pkg_entry`? ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8392 From cstein at openjdk.java.net Tue May 10 17:39:32 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 10 May 2022 17:39:32 GMT Subject: RFR: 8286460: Remove dependence on JAR filename in CDS tests [v2] In-Reply-To: References: Message-ID: > Use location information stored in JUnit `Test` class' runtime representation in order to remove a hard-coded dependence on JUnit's JAR filename. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Update copyright year to 2022 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8624/files - new: https://git.openjdk.java.net/jdk/pull/8624/files/d7c6d756..5ebd8c03 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8624&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8624&range=00-01 Stats: 14 lines in 14 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/8624.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8624/head:pull/8624 PR: https://git.openjdk.java.net/jdk/pull/8624 From ccheung at openjdk.java.net Tue May 10 17:53:47 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 10 May 2022 17:53:47 GMT Subject: RFR: 8286460: Remove dependence on JAR filename in CDS tests [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 17:39:32 GMT, Christian Stein wrote: >> Use location information stored in JUnit `Test` class' runtime representation in order to remove a hard-coded dependence on JUnit's JAR filename. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year to 2022 Marked as reviewed by ccheung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8624 From iklam at openjdk.java.net Tue May 10 18:03:57 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 10 May 2022 18:03:57 GMT Subject: RFR: 8285518: CDS assert: visibility cannot change between dump time and runtime In-Reply-To: <0T5nTFQnM1ByQyVG0YGNzCuRz73R8evBx_YZAFVoiK4=.6ccd3594-ecc8-4c68-a14f-a2bd63c857b2@github.com> References: <0T5nTFQnM1ByQyVG0YGNzCuRz73R8evBx_YZAFVoiK4=.6ccd3594-ecc8-4c68-a14f-a2bd63c857b2@github.com> Message-ID: On Tue, 10 May 2022 17:34:21 GMT, Calvin Cheung wrote: > Looks good. Just curious usually how many classes would require reload of `pkg_entry`? Usually the reload never happens. I ran two test cases: - HelloWorld: is_shared_class_visible_impl called 227 times - javac: is_shared_class_visible_impl called 688 times In both cases, the reload never happened. ------------- PR: https://git.openjdk.java.net/jdk/pull/8392 From cstein at openjdk.java.net Tue May 10 18:18:54 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 10 May 2022 18:18:54 GMT Subject: Integrated: 8286460: Remove dependence on JAR filename in CDS tests In-Reply-To: References: Message-ID: On Tue, 10 May 2022 07:27:35 GMT, Christian Stein wrote: > Use location information stored in JUnit `Test` class' runtime representation in order to remove a hard-coded dependence on JUnit's JAR filename. This pull request has now been integrated. Changeset: 52dbfa99 Author: Christian Stein Committer: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/52dbfa99fe34d7b9469fba626e3577a22fd1d1fe Stats: 126 lines in 14 files changed: 0 ins; 98 del; 28 mod 8286460: Remove dependence on JAR filename in CDS tests Reviewed-by: ccheung, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/8624 From iklam at openjdk.java.net Tue May 10 18:19:55 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 10 May 2022 18:19:55 GMT Subject: RFR: 8285518: CDS assert: visibility cannot change between dump time and runtime In-Reply-To: References: Message-ID: On Tue, 10 May 2022 04:35:43 GMT, David Holmes wrote: >> This PR fixes a timing hole in the CDS class loading code. The bug happens with the `jdk/internal/ref/Cleaner` class, which is loaded by the boot classloader. >> >> - The loading of `Cleaner` is initiated >> - We look up the `pkg_entry` for this class >> - At this point, the module system is not yet fully initialized, so package information is not yet available, and we get `pkg_entry == NULL` >> - Later, in `SystemDictionary::is_shared_class_visible_impl`, we try to check the visbility of this class, but now the module system is fully initialized, so the NULL `pkg_entry` is no longer valid. >> >> The fix is to always reload the `pkg_entry` if it's NULL. This should happen very rarely because `pkg_entry` for archived classes are usually non-null. >> >> This timing hole existed before but has been triggered (once) only after Loom changed the bootstrap sequence of the reference thread. Nonetheless we should backport to older JDKs since there's still a theoretical chance this it may happen, and the fix is simple. > > Seems quite reasonable. > > Thanks. Thanks to @dholmes-ora and @calvinccheung for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8392 From iklam at openjdk.java.net Tue May 10 18:22:42 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 10 May 2022 18:22:42 GMT Subject: Integrated: 8285518: CDS assert: visibility cannot change between dump time and runtime In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 23:48:14 GMT, Ioi Lam wrote: > This PR fixes a timing hole in the CDS class loading code. The bug happens with the `jdk/internal/ref/Cleaner` class, which is loaded by the boot classloader. > > - The loading of `Cleaner` is initiated > - We look up the `pkg_entry` for this class > - At this point, the module system is not yet fully initialized, so package information is not yet available, and we get `pkg_entry == NULL` > - Later, in `SystemDictionary::is_shared_class_visible_impl`, we try to check the visbility of this class, but now the module system is fully initialized, so the NULL `pkg_entry` is no longer valid. > > The fix is to always reload the `pkg_entry` if it's NULL. This should happen very rarely because `pkg_entry` for archived classes are usually non-null. > > This timing hole existed before but has been triggered (once) only after Loom changed the bootstrap sequence of the reference thread. Nonetheless we should backport to older JDKs since there's still a theoretical chance this it may happen, and the fix is simple. This pull request has now been integrated. Changeset: 61c68abc Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/61c68abc68a77e5d009d4665dc21e840db02f4ae Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod 8285518: CDS assert: visibility cannot change between dump time and runtime Reviewed-by: dholmes, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/8392 From lmesnik at openjdk.java.net Tue May 10 19:06:55 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 10 May 2022 19:06:55 GMT Subject: Integrated: 8284980: Test vmTestbase/nsk/stress/except/except010.java times out with -Xcomp -XX:+DeoptimizeALot In-Reply-To: References: Message-ID: On Mon, 9 May 2022 18:02:13 GMT, Leonid Mesnik wrote: > Test executes method recursively and works too long. > > It the same issue as [JDK-8139875](https://bugs.openjdk.java.net/browse/JDK-8139875) > > The test shouldn't be run with DeoptimizeALot This pull request has now been integrated. Changeset: 7704eb18 Author: Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/7704eb18664606361bc87d54d102533530f1d2dd Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8284980: Test vmTestbase/nsk/stress/except/except010.java times out with -Xcomp -XX:+DeoptimizeALot Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/8602 From ccheung at openjdk.java.net Tue May 10 20:18:14 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 10 May 2022 20:18:14 GMT Subject: RFR: 8286551: JDK-8286460 causes tests to fail to compile in Tier2 Message-ID: The tests fail compilation due to a missing import statement. Simple fix to add the following import statement to the tests: `import java.nio.file.Path` Ran the tests successfully locally on linux-x64. ------------- Commit messages: - 8286551: JDK-8286460 causes tests to fail to compile in Tier2 Changes: https://git.openjdk.java.net/jdk/pull/8639/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8639&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286551 Stats: 16 lines in 14 files changed: 14 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8639.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8639/head:pull/8639 PR: https://git.openjdk.java.net/jdk/pull/8639 From dcubed at openjdk.java.net Tue May 10 20:18:15 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 10 May 2022 20:18:15 GMT Subject: RFR: 8286551: JDK-8286460 causes tests to fail to compile in Tier2 In-Reply-To: References: Message-ID: On Tue, 10 May 2022 20:05:52 GMT, Calvin Cheung wrote: > The tests fail compilation due to a missing import statement. > > Simple fix to add the following import statement to the tests: > > `import java.nio.file.Path` > > Ran the tests successfully locally on linux-x64. Thumbs up on the fix. These changes are trivial and they fix compilation errors in Tier2 so I'm okay if we don't wait for the usual 24H. I am wondering if there are more surprises in store in the upper tiers. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8639 From ccheung at openjdk.java.net Tue May 10 20:18:15 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 10 May 2022 20:18:15 GMT Subject: RFR: 8286551: JDK-8286460 causes tests to fail to compile in Tier2 In-Reply-To: References: Message-ID: On Tue, 10 May 2022 20:12:53 GMT, Daniel D. Daugherty wrote: > Thumbs up on the fix. These changes are trivial and they fix compilation errors in Tier2 so I'm okay if we don't wait for the usual 24H. > > I am wondering if there are more surprises in store in the upper tiers. Thanks for the quick review. There shouldn't be surprises in the upper tiers as the fix only changes how to find junit jar. ------------- PR: https://git.openjdk.java.net/jdk/pull/8639 From ccheung at openjdk.java.net Tue May 10 20:23:28 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 10 May 2022 20:23:28 GMT Subject: Integrated: 8286551: JDK-8286460 causes tests to fail to compile in Tier2 In-Reply-To: References: Message-ID: <8572Yru-0ca7c_dHzhGjKHTnR66ewJuCoKxp3uUF5vo=.e9977693-bd36-40c3-8f8a-067b11d7eaca@github.com> On Tue, 10 May 2022 20:05:52 GMT, Calvin Cheung wrote: > The tests fail compilation due to a missing import statement. > > Simple fix to add the following import statement to the tests: > > `import java.nio.file.Path` > > Ran the tests successfully locally on linux-x64. This pull request has now been integrated. Changeset: 070a0cda Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/070a0cda31f83a3cf18a612b91c30d66cf407c3c Stats: 16 lines in 14 files changed: 14 ins; 0 del; 2 mod 8286551: JDK-8286460 causes tests to fail to compile in Tier2 Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/8639 From vlivanov at openjdk.java.net Tue May 10 21:06:18 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 10 May 2022 21:06:18 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: Message-ID: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> On Mon, 9 May 2022 10:28:27 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 > - Remove unneeded ComputeMoveOrder > - Remove comment about native calls in lcm.cpp > - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 > > Reviewed-by: jvernee, mcimadamore > - Update riscv and arm stubs > - Remove spurious ProblemList change > - Pass pointer to LogStream > - Polish > - Replace TraceNativeInvokers flag with unified logging > - Fix other platforms, take 2 > - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 Nice work! Looks good. Some minor comments/questions follow. src/hotspot/cpu/aarch64/frame_aarch64.cpp line 379: > 377: // need unextended_sp here, since normal sp is wrong for interpreter callees > 378: return reinterpret_cast( > 379: reinterpret_cast(frame.unextended_sp()) + in_bytes(_frame_data_offset)); Maybe use `address` instead of `char*`? src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5531: > 5529: } > 5530: > 5531: // On 64 bit we will store integer like items to the stack as Time for a cleanup? `64 bit` vs `64bit`, `abi`, `Aarch64`. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5547: > 5545: } else if (dst.first()->is_stack()) { > 5546: // reg to stack > 5547: // Do we really have to sign extend??? Obsolete? Remove? src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 306: > 304: intptr_t exception_handler_offset = __ pc() - start; > 305: > 306: // Native caller has no idea how to handle exceptions, Can you elaborate, please, how it is expected to work in presence of asynchronous exceptions? I'd expect to see a code which unconditionally clears pending exception with an assertion that verifies that the exception is of expected type. src/hotspot/cpu/x86/foreign_globals_x86.hpp line 30: > 28: #include "utilities/growableArray.hpp" > 29: > 30: class outputStream; Redundant declaration? src/hotspot/cpu/x86/foreign_globals_x86_64.cpp line 52: > 50: > 51: objArrayOop inputStorage = jdk_internal_foreign_abi_ABIDescriptor::inputStorage(abi_oop); > 52: loadArray(inputStorage, INTEGER_TYPE, abi._integer_argument_registers, as_Register); `loadArray` helper looks a bit misleading. In presence of `javaClass`-style accessors, it misleadingly hints that it refers to some Java-level operation/entity, though what it does it parses register list representation backed by a Java array. I suggest to rename it to something like `parse_argument_registers_array()`). src/hotspot/cpu/x86/macroAssembler_x86.cpp line 933: > 931: } else { > 932: assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)", > 933: src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name()); Wrong indentation. src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 36: > 34: #include "code/nativeInst.hpp" > 35: #include "code/vtableStubs.hpp" > 36: #include "compiler/disassembler.hpp" Redundant includes? No new code added in the file. src/hotspot/share/c1/c1_GraphBuilder.cpp line 4230: > 4228: > 4229: case vmIntrinsics::_linkToNative: > 4230: print_inlining(callee, "Native call", /*success*/ false); Since the message is appended, lower case is preferred:`"native call"`. src/hotspot/share/code/codeBlob.hpp line 754: > 752: class ProgrammableUpcallHandler; > 753: > 754: class OptimizedEntryBlob: public RuntimeBlob { What's the motivation to move `OptimizedEntryBlob` up in the hierarchy (from `BufferBlob` to `RuntimeBlob`)? src/hotspot/share/opto/callGenerator.cpp line 1131: > 1129: > 1130: case vmIntrinsics::_linkToNative: > 1131: print_inlining_failure(C, callee, jvms->depth() - 1, jvms->bci(), Why is it unconditionally reported as inlining failure? src/hotspot/share/prims/foreign_globals.cpp line 147: > 145: // based on ComputeMoveOrder from x86_64 shared runtime code. > 146: // with some changes. > 147: class ForeignCMO: public StackObj { Considering how seldom it is used, I don't see much value in abbreviating it. Also, the comment is misleading: there's no such entity as `ComputeMoveOrder` in the code. And `compute_move_order` is completely removed by this change. src/hotspot/share/prims/foreign_globals.cpp line 217: > 215: > 216: public: > 217: ForeignCMO(int total_in_args, const VMRegPair* in_regs, int total_out_args, VMRegPair* out_regs, I propose to turn it into a trivial ctor and move all the logic into a helper static function which returns the computed moves. src/hotspot/share/prims/foreign_globals.hpp line 35: > 33: #include CPU_HEADER(foreign_globals) > 34: > 35: class CallConvClosure { Just a question on terminology: why is it called a `Closure`? src/hotspot/share/prims/foreign_globals.hpp line 62: > 60: > 61: > 62: class JavaCallConv : public CallConvClosure { Does it really worth to abbreviate `CallingConvention` to `CallConv`? src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 313: > 311: MethodType newType = oldType.dropParameterTypes(destIndex, destIndex + 1); > 312: int[] reorder = new int[oldType.parameterCount()]; > 313: if (destIndex < sourceIndex) Misses braces. src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Architecture.java line 169: > 167: stackAlignment, > 168: shadowSpace, > 169: targetAddrStorage, retBufAddrStorage); Wrong indentation. src/java.base/share/classes/jdk/internal/foreign/abi/x64/X86_64Architecture.java line 156: > 154: stackAlignment, > 155: shadowSpace, > 156: targetAddrStorage, retBufAddrStorage); Wrong indentation. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From vlivanov at openjdk.java.net Tue May 10 21:06:20 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 10 May 2022 21:06:20 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 12:15:10 GMT, Jorn Vernee wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/share/utilities/growableArray.hpp line 151: > >> 149: return _data; >> 150: } >> 151: > > This accessor is added to be able to temporarily view a stable GrowableArray instance as a C-style array. It is used to by `NativeCallConv` and `RegSpiller` in `foreign_globals.hpp`. > > GrowableArray already has an `adr_at` accessor that does something similar, but using `adr_at(0)` fails on empty growable arrays since it also performs a bounds check. So it can not be used. Any problems with migrating `CallConv` and `RegSpiller`away from ` VMReg* + int` to `GrowableArray`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From kbarrett at openjdk.java.net Tue May 10 21:29:31 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 10 May 2022 21:29:31 GMT Subject: RFR: 8286424: GetVersionEx is deprecated [v2] In-Reply-To: References: Message-ID: <7W82D45KUc00_-RloszKs6xLsOlghWRebqYcOdpwNp8=.5fe56297-493c-4173-9a21-91317c273d58@github.com> > Please review this change to explicitly disable deprecation warnings for the > two uses of GetVersionEx in HotSpot code. This is a step toward being able to > remove the global (to HotSpot) disable of deprecation warnings for Windows. > (It is because of that global disable that these uses don't currently generate > warnings.) > > There are uses of this function in non-HotSpot parts of the JDK. These are not > being changed. They all disable the warning in some fashion, as appropriate to > that area's usage. This change is only about HotSpot usage, and wanting to > remove global deprecation disabling from HotSpot builds. Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: use IsWindowsServer ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8611/files - new: https://git.openjdk.java.net/jdk/pull/8611/files/9c06f99a..6743b766 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8611&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8611&range=00-01 Stats: 33 lines in 1 file changed: 1 ins; 30 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8611/head:pull/8611 PR: https://git.openjdk.java.net/jdk/pull/8611 From paul.sandoz at oracle.com Tue May 10 22:51:49 2022 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 10 May 2022 22:51:49 +0000 Subject: MethodType runtime API vs constant pool entry of the same type In-Reply-To: References: Message-ID: MethodType.fromMethodDescriptorString does not have the bytecode behavior of loading a method type from the constant pool, where access control checks are applied. The use of the string descriptor is a convenience and not meant to imply bytecode behavior. The method, as stated, defers resolution of classes to the given class loader. In your Java code example it's equivalent to doing: MethodType m = MethodType.methodType(Class.forName("foo.Foo$Bar", false, Test.class.getClassLoader())); The following paragraph after that which you quote states: * When the JVM materializes a {@code MethodType} from a descriptor string, * all classes named in the descriptor must be accessible, and will be loaded. * (But the classes need not be initialized, as is the case with a {@code CONSTANT_Class}.) * This loading may occur at any time before the {@code MethodType} object is first derived. In jasm try doing a ldc of class Bar and you should also get an illegal access error [1]. The equivalent bytecode behavior (except for the exception, error vs runtime exception) can be achieved using the nominal descriptor: MethodTypeDesc d = MethodTypeDesc.ofDescriptor("()Lfoo/Foo$Bar;"); MethodType m = (MethodType) d.resolveConstantDesc(MethodHandles.lookup()); // throws IllegalAccessException Which in turn is equivalent to: MethodHandles.Lookup l = MethodHandles.lookup(); MethodType m = MethodType.fromMethodDescriptorString( "()Lfoo/Foo$Bar;", l.lookupClass().getClassLoader() ); l.accessClass(m.returnType()); // On May 9, 2022, at 8:08 PM, Maxim Degtyarev wrote: > > Inspired by https://mail.openjdk.java.net/pipermail/compiler-dev/2022-May/019558.html > > According to the JDK 17 `j.l.i.MethodType` javadoc [1]: > > Like classes and strings, method types can also be represented > directly in a class file's constant pool as constants. > A method type may be loaded by an ldc instruction which refers to a > suitable CONSTANT_MethodType constant pool entry. > The entry refers to a CONSTANT_Utf8 spelling for the descriptor > string. (For full details on method type constants, > see sections 4.4.8 and 5.4.3.5 of the Java Virtual Machine Specification.) > > > If I understand it correctly, this implies that any `MethodType` > instance that can be successfully created with the > call to `MethodType.fromMethodDescriptorString()` method can be also > represented as a constant pool entry of type MethodType. > > > Now consider the following example: > > > // main/TestRuntime.java > package main; > > import java.lang.invoke.MethodType; > > public class TestRuntime { > > public static void main(String... args) { > System.out.println( > MethodType.fromMethodDescriptorString( > "()Lfoo/Foo$Bar;", > TestRuntime.class.getClassLoader() > ) > ); > } > > } > > > // main/TestConstantPool.jasm > /** > * > * You need asmtools > to assemble this example. > * > * To assemble run: > * > * java -jar asmtools.jar jasm -g TestConstantPool.jasm > * > * > */ > package main; > > super public class TestConstantPool > version 52:0 > { > public Method "":"()V" > stack 1 locals 1 > { > aload_0; > invokespecial Method java/lang/Object."":"()V"; > return; > } > > public static varargs Method main:"([Ljava/lang/String;)V" > stack 2 locals 1 > { > getstatic Field java/lang/System.out:"Ljava/io/PrintStream;"; > ldc MethodType "()Lfoo/Foo$Bar;"; > invokevirtual Method > java/io/PrintStream.println:"(Ljava/lang/Object;)V"; > return; > > } > } // end Class TestConstantPool > > > // foo/Foo.java > package foo; > > public class Foo { > public static Bar bar() { > return new Bar(); > } > > static class Bar {} > } > > > Both `main.TestRuntime` and `main.TestConstantPool` are functionally > equal and should print > string representation of the `MethodType` instance. > > > While `main.TestRuntime` behaves as expected: > > $ java main.TestRuntime > ()Bar > > > The `main.TestConstantPool` failed with `j.l.IllegalAccessError`: > > $ java main.TestConstantPool > Exception in thread "main" java.lang.IllegalAccessError: tried to > access class foo.Foo$Bar from class main.TestConstantPool > at main.TestConstantPool.main(TestConstantPool.jasm:18) > > > However, if we declare class `foo.Foo.Bar` public then both > `TestRuntime` and `TestConstantPool` run without exceptions. > > > Checked both with `Java(TM) SE Runtime Environment (build > 1.8.0_152-b16)` and `OpenJDK Runtime Environment (build > 19-ea+21-1482)`. > > > Questions: > > 1) Shouldn't both examples expose equal behaviour? > > 2) Which of 2 observed behaviours is correct? > > > Examples from this message can be found at [2] > > > [1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/MethodType.html > [2] https://github.com/Maccimo/MethodType-API-vs-ConstantPool From david.holmes at oracle.com Wed May 11 01:07:52 2022 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 May 2022 11:07:52 +1000 Subject: MethodType runtime API vs constant pool entry of the same type In-Reply-To: References: Message-ID: Hi Paul, On 11/05/2022 8:51 am, Paul Sandoz wrote: > MethodType.fromMethodDescriptorString does not have the bytecode behavior of loading a method type from the constant pool, where access control checks are applied. The API spec states: "Any class or interface name embedded in the descriptor string will be resolved by the given loader ..." And resolution includes an access control check. David ----- > The use of the string descriptor is a convenience and not meant to imply bytecode behavior. The method, as stated, defers resolution of classes to the given class loader. In your Java code example it's equivalent to doing: > > MethodType m = MethodType.methodType(Class.forName("foo.Foo$Bar", false, Test.class.getClassLoader())); > > The following paragraph after that which you quote states: > > * When the JVM materializes a {@code MethodType} from a descriptor string, > * all classes named in the descriptor must be accessible, and will be loaded. > * (But the classes need not be initialized, as is the case with a {@code CONSTANT_Class}.) > * This loading may occur at any time before the {@code MethodType} object is first derived. > > In jasm try doing a ldc of class Bar and you should also get an illegal access error [1]. > > The equivalent bytecode behavior (except for the exception, error vs runtime exception) can be achieved using the nominal descriptor: > > MethodTypeDesc d = MethodTypeDesc.ofDescriptor("()Lfoo/Foo$Bar;"); > MethodType m = (MethodType) d.resolveConstantDesc(MethodHandles.lookup()); // throws IllegalAccessException > > Which in turn is equivalent to: > > MethodHandles.Lookup l = MethodHandles.lookup(); > MethodType m = MethodType.fromMethodDescriptorString( > "()Lfoo/Foo$Bar;", > l.lookupClass().getClassLoader() > ); > l.accessClass(m.returnType()); // > Hth, > Paul. > > [1] https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-5.html#jvms-5.4.3.1 > >> On May 9, 2022, at 8:08 PM, Maxim Degtyarev wrote: >> >> Inspired by https://mail.openjdk.java.net/pipermail/compiler-dev/2022-May/019558.html >> >> According to the JDK 17 `j.l.i.MethodType` javadoc [1]: >> >> Like classes and strings, method types can also be represented >> directly in a class file's constant pool as constants. >> A method type may be loaded by an ldc instruction which refers to a >> suitable CONSTANT_MethodType constant pool entry. >> The entry refers to a CONSTANT_Utf8 spelling for the descriptor >> string. (For full details on method type constants, >> see sections 4.4.8 and 5.4.3.5 of the Java Virtual Machine Specification.) >> >> >> If I understand it correctly, this implies that any `MethodType` >> instance that can be successfully created with the >> call to `MethodType.fromMethodDescriptorString()` method can be also >> represented as a constant pool entry of type MethodType. >> >> >> Now consider the following example: >> >> >> // main/TestRuntime.java >> package main; >> >> import java.lang.invoke.MethodType; >> >> public class TestRuntime { >> >> public static void main(String... args) { >> System.out.println( >> MethodType.fromMethodDescriptorString( >> "()Lfoo/Foo$Bar;", >> TestRuntime.class.getClassLoader() >> ) >> ); >> } >> >> } >> >> >> // main/TestConstantPool.jasm >> /** >> * >> * You need asmtools >> to assemble this example. >> * >> * To assemble run: >> * >> * java -jar asmtools.jar jasm -g TestConstantPool.jasm >> * >> * >> */ >> package main; >> >> super public class TestConstantPool >> version 52:0 >> { >> public Method "":"()V" >> stack 1 locals 1 >> { >> aload_0; >> invokespecial Method java/lang/Object."":"()V"; >> return; >> } >> >> public static varargs Method main:"([Ljava/lang/String;)V" >> stack 2 locals 1 >> { >> getstatic Field java/lang/System.out:"Ljava/io/PrintStream;"; >> ldc MethodType "()Lfoo/Foo$Bar;"; >> invokevirtual Method >> java/io/PrintStream.println:"(Ljava/lang/Object;)V"; >> return; >> >> } >> } // end Class TestConstantPool >> >> >> // foo/Foo.java >> package foo; >> >> public class Foo { >> public static Bar bar() { >> return new Bar(); >> } >> >> static class Bar {} >> } >> >> >> Both `main.TestRuntime` and `main.TestConstantPool` are functionally >> equal and should print >> string representation of the `MethodType` instance. >> >> >> While `main.TestRuntime` behaves as expected: >> >> $ java main.TestRuntime >> ()Bar >> >> >> The `main.TestConstantPool` failed with `j.l.IllegalAccessError`: >> >> $ java main.TestConstantPool >> Exception in thread "main" java.lang.IllegalAccessError: tried to >> access class foo.Foo$Bar from class main.TestConstantPool >> at main.TestConstantPool.main(TestConstantPool.jasm:18) >> >> >> However, if we declare class `foo.Foo.Bar` public then both >> `TestRuntime` and `TestConstantPool` run without exceptions. >> >> >> Checked both with `Java(TM) SE Runtime Environment (build >> 1.8.0_152-b16)` and `OpenJDK Runtime Environment (build >> 19-ea+21-1482)`. >> >> >> Questions: >> >> 1) Shouldn't both examples expose equal behaviour? >> >> 2) Which of 2 observed behaviours is correct? >> >> >> Examples from this message can be found at [2] >> >> >> [1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/MethodType.html >> [2] https://github.com/Maccimo/MethodType-API-vs-ConstantPool > From dholmes at openjdk.java.net Wed May 11 01:32:37 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 11 May 2022 01:32:37 GMT Subject: RFR: 8286424: GetVersionEx is deprecated [v2] In-Reply-To: <7W82D45KUc00_-RloszKs6xLsOlghWRebqYcOdpwNp8=.5fe56297-493c-4173-9a21-91317c273d58@github.com> References: <7W82D45KUc00_-RloszKs6xLsOlghWRebqYcOdpwNp8=.5fe56297-493c-4173-9a21-91317c273d58@github.com> Message-ID: On Tue, 10 May 2022 21:29:31 GMT, Kim Barrett wrote: >> Please review this change to explicitly disable deprecation warnings for the >> two uses of GetVersionEx in HotSpot code. This is a step toward being able to >> remove the global (to HotSpot) disable of deprecation warnings for Windows. >> (It is because of that global disable that these uses don't currently generate >> warnings.) >> >> There are uses of this function in non-HotSpot parts of the JDK. These are not >> being changed. They all disable the warning in some fashion, as appropriate to >> that area's usage. This change is only about HotSpot usage, and wanting to >> remove global deprecation disabling from HotSpot builds. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > use IsWindowsServer Looks good. That "deprecation" is why we don't actually use `GetVersionEx` to get the version - see JDK-8059803. I guess the existence of `IsWindowsServer` was overlooked at the time. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8611 From mbaesken at openjdk.java.net Wed May 11 06:59:45 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 11 May 2022 06:59:45 GMT Subject: Integrated: JDK-8286459: compile error with VS2017 in continuationFreezeThaw.cpp In-Reply-To: References: Message-ID: On Tue, 10 May 2022 14:45:43 GMT, Matthias Baesken wrote: > After recent changes (loom?) we run into this compile error when using VS2017 : > > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2463): error C2440: 'type cast': cannot convert from 'int (__cdecl *)(JavaThread *,intptr_t *)' to 'address' > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2463): note: Context does not allow for disambiguation of overloaded function > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2451): note: see reference to function template instantiation 'void ConfigResolve::resolve::type>(void)' being compiled > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2436): note: see reference to function template instantiation 'void ConfigResolve::resolve_gc(void)' being compiled > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2466): error C2440: 'type cast': cannot convert from 'intptr_t *(__cdecl *)(JavaThread *,int)' to 'address' > d:\build\jdk\src\hotspot\share\runtime\continuationFreezeThaw.cpp(2466): note: Context does not allow for disambiguation of overloaded function > > An additional cast can be added to make the issue go away. This pull request has now been integrated. Changeset: 6586e5ae Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/6586e5ae37e09a6d47f07758e710e1327e1c3be9 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8286459: compile error with VS2017 in continuationFreezeThaw.cpp Reviewed-by: clanger, mdoerr ------------- PR: https://git.openjdk.java.net/jdk/pull/8632 From dnsimon at openjdk.java.net Wed May 11 10:45:28 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 11 May 2022 10:45:28 GMT Subject: RFR: 8282607: runtime/ErrorHandling/MachCodeFramesInErrorFile.java failed with "RuntimeException: 0 < 2" Message-ID: I've looked through the failures reported in https://bugs.openjdk.java.net/browse/JDK-8282607 and in all cases, the problem is that hs_err is truncated while printing the register to memory mapping and always while printing x14. Here are a few examples: Register to memory mapping: x0=0x000000000000000a is an unknown value x1=0x000000000000000a is an unknown value x2=0x0 is NULL x3=0x000000000000000a is an unknown value x4=0x000000013e009080 points into unknown readable memory: 0xabababababababab | ab ab ab ab ab ab ab ab x5=0x0000000000000005 is an unknown value x6=0x0 is NULL x7=0x0 is NULL x8=0x0 is NULL x9=0x0000000000000001 is an unknown value x10=0x2010000030300000 is an unknown value x11=0x0000000000000002 is an unknown value x12={method} {0x0000000800467b20} 'getLong' '(Ljava/lang/Object;J)J' in 'jdk/internal/misc/Unsafe' x13=0x0000000080000000 is an unknown value x14= and: Register to memory mapping: x0=0x000000000000000a is an unknown value x1=0x000000000000000a is an unknown value x2=0x0 is NULL x3=0x000000000000000a is an unknown value x4=0x000000012002ebc0 is pointing into metadata x5=0x0000000000000012 is an unknown value x6=0x0 is NULL x7=0x0000000136808210 is a thread x8=0x0 is NULL x9=0x0000000000000001 is an unknown value x10=0x2010000030300000 is an unknown value x11=0x0000010000000102 is an unknown value x12={method} {0x00000008004b0ed0} 'getLong' '(Ljava/lang/Object;J)J' in 'jdk/internal/misc/Unsafe' x13=0x0000000080000000 is an unknown value x14= To avoid the MachCodeFramesInErrorFile test failing as a result the truncation, the test has been modified to pass if the section preceding the code blob dumping is not seen. ------------- Commit messages: - workaround truncated hs-err log on macosx-aarch64 in MachCodeFramesInErrorFile Changes: https://git.openjdk.java.net/jdk/pull/8650/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8650&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282607 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8650.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8650/head:pull/8650 PR: https://git.openjdk.java.net/jdk/pull/8650 From jvernee at openjdk.java.net Wed May 11 10:45:12 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 10:45:12 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 18:44:01 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/cpu/aarch64/frame_aarch64.cpp line 379: > >> 377: // need unextended_sp here, since normal sp is wrong for interpreter callees >> 378: return reinterpret_cast( >> 379: reinterpret_cast(frame.unextended_sp()) + in_bytes(_frame_data_offset)); > > Maybe use `address` instead of `char*`? Ok. I think I used `char*` to try and avoid a potential strict-aliasing violation, but I don't think we compile with that turned on any ways. Will change it to `address` (for x86 too) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 10:50:47 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 10:50:47 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 18:48:08 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5547: > >> 5545: } else if (dst.first()->is_stack()) { >> 5546: // reg to stack >> 5547: // Do we really have to sign extend??? > > Obsolete? Remove? Yes, this looks like it can be removed. (was copied over from SharedRuntime_aarch64) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 10:55:09 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 10:55:09 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 18:55:03 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/cpu/x86/foreign_globals_x86.hpp line 30: > >> 28: #include "utilities/growableArray.hpp" >> 29: >> 30: class outputStream; > > Redundant declaration? Yeah, this whole file is redundant :) (replaced by foreign_globals_x86_64.hpp) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 11:02:47 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 11:02:47 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 19:16:35 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/share/code/codeBlob.hpp line 754: > >> 752: class ProgrammableUpcallHandler; >> 753: >> 754: class OptimizedEntryBlob: public RuntimeBlob { > > What's the motivation to move `OptimizedEntryBlob` up in the hierarchy (from `BufferBlob` to `RuntimeBlob`)? Some of it is discussed here: https://github.com/openjdk/panama-foreign/pull/617 Essentially, it is to avoid accidentally inheriting behavior from BufferBlob which we don't want. Also, BufferBlob currently expects a fixed-sized header (`sizeof(BufferBlob)`), while OptimizedEntryBlobs has fields, so we'd have to pass the real header size to the `BufferBlob` constructor, which is a bit messy. It felt better to just cleanly break away from BufferBlob. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 11:09:52 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 11:09:52 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 19:21:58 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/share/opto/callGenerator.cpp line 1131: > >> 1129: >> 1130: case vmIntrinsics::_linkToNative: >> 1131: print_inlining_failure(C, callee, jvms->depth() - 1, jvms->bci(), > > Why is it unconditionally reported as inlining failure? The call that is being processed here is `linkToNative`, and that call is not inlined, so reporting an inlining failure seems correct. We still go through the method handle trampoline stub which loads the actual target from the NativeEntryPoint (`jump_to_native_invoker` in methodHandles_x86.cpp). It's potentially faster here to generate a runtime call to the underlying invoker/downcall stub if the NativeEntryPoint is constant (i.e. avoid the lookup through NEP in the MH trampoline), but I hadn't gotten to investigating that yet. >From comparing the benchmark times between this and the old implementation (which generated an inline call), they are not all that different. So it seemed that doing something special here would not save that much time any ways. (but, still would be good to investigate at some point) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 11:13:53 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 11:13:53 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 20:30:09 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/share/prims/foreign_globals.cpp line 147: > >> 145: // based on ComputeMoveOrder from x86_64 shared runtime code. >> 146: // with some changes. >> 147: class ForeignCMO: public StackObj { > > Considering how seldom it is used, I don't see much value in abbreviating it. Also, the comment is misleading: there's no such entity as `ComputeMoveOrder` in the code. And `compute_move_order` is completely removed by this change. Good points, I think we can just rename this class to `ComputeMoveOrder` at this point. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 11:28:05 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 11:28:05 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 20:48:47 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/share/prims/foreign_globals.hpp line 35: > >> 33: #include CPU_HEADER(foreign_globals) >> 34: >> 35: class CallConvClosure { > > Just a question on terminology: why is it called a `Closure`? It is the terminology used in other parts of hotspot for function objects it seems. See for instance the classes in `iterator.hpp` > src/hotspot/share/prims/foreign_globals.hpp line 62: > >> 60: >> 61: >> 62: class JavaCallConv : public CallConvClosure { > > Does it really worth to abbreviate `CallingConvention` to `CallConv`? Maybe not... I'll spell out the full thing. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 12:08:53 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 12:08:53 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 21:01:48 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 306: > >> 304: intptr_t exception_handler_offset = __ pc() - start; >> 305: >> 306: // Native caller has no idea how to handle exceptions, > > Can you elaborate, please, how it is expected to work in presence of asynchronous exceptions? I'd expect to see a code which unconditionally clears pending exception with an assertion that verifies that the exception is of expected type. We have an exception handler in Java as well, so this code is only a fail safe. But, I think in the case of asynchronous exceptions this might be problematic if the exception is discovered by the current thread outside of the Java exception handler, turned into a synchronous exception and then we get here and call `ProgrammableUpcallhandler::handle_uncaught_exception` and then crash. Or if the asynchronous exception is discovered in `ProgrammableUpcallHandler::on_exit` (where there is currently an assert for no exceptions). I think you're right that, in both of those cases, if the exception is asynchronous, we should just ignore it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 12:19:05 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 12:19:05 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Wed, 11 May 2022 10:51:10 GMT, Jorn Vernee wrote: >> src/hotspot/cpu/x86/foreign_globals_x86.hpp line 30: >> >>> 28: #include "utilities/growableArray.hpp" >>> 29: >>> 30: class outputStream; >> >> Redundant declaration? > > Yeah, this whole file is redundant :) (replaced by foreign_globals_x86_64.hpp) Hmm, it doesn't look like having x64 specific header files is support by the CPU_HEADER macros. Will stick to the shared header file for x86_32 and x86_64 for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 12:23:59 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 12:23:59 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 20:45:02 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/cpu/x86/foreign_globals_x86_64.cpp line 52: > >> 50: >> 51: objArrayOop inputStorage = jdk_internal_foreign_abi_ABIDescriptor::inputStorage(abi_oop); >> 52: loadArray(inputStorage, INTEGER_TYPE, abi._integer_argument_registers, as_Register); > > `loadArray` helper looks a bit misleading. In presence of `javaClass`-style accessors, it misleadingly hints that it refers to some Java-level operation/entity, though what it does it parses register list representation backed by a Java array. I suggest to rename it to something like `parse_argument_registers_array()`). I went with `parse_register_array` (since it's also used for return registers) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 12:24:02 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 12:24:02 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 20:53:37 GMT, Vladimir Ivanov wrote: >> src/hotspot/share/utilities/growableArray.hpp line 151: >> >>> 149: return _data; >>> 150: } >>> 151: >> >> This accessor is added to be able to temporarily view a stable GrowableArray instance as a C-style array. It is used to by `NativeCallConv` and `RegSpiller` in `foreign_globals.hpp`. >> >> GrowableArray already has an `adr_at` accessor that does something similar, but using `adr_at(0)` fails on empty growable arrays since it also performs a bounds check. So it can not be used. > > Any problems with migrating `CallConv` and `RegSpiller`away from ` VMReg* + int` to `GrowableArray`? I'll try migrating to `GrowableArray` ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From dholmes at openjdk.java.net Wed May 11 12:32:55 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 11 May 2022 12:32:55 GMT Subject: RFR: 8282607: runtime/ErrorHandling/MachCodeFramesInErrorFile.java failed with "RuntimeException: 0 < 2" In-Reply-To: References: Message-ID: On Wed, 11 May 2022 10:36:19 GMT, Doug Simon wrote: > I've looked through the failures reported in https://bugs.openjdk.java.net/browse/JDK-8282607 and in all cases, the problem is that hs_err is truncated while printing the register to memory mapping and always while printing x14. Here are a few examples: > > > Register to memory mapping: > > x0=0x000000000000000a is an unknown value > x1=0x000000000000000a is an unknown value > x2=0x0 is NULL > x3=0x000000000000000a is an unknown value > x4=0x000000013e009080 points into unknown readable memory: 0xabababababababab | ab ab ab ab ab ab ab ab > x5=0x0000000000000005 is an unknown value > x6=0x0 is NULL > x7=0x0 is NULL > x8=0x0 is NULL > x9=0x0000000000000001 is an unknown value > x10=0x2010000030300000 is an unknown value > x11=0x0000000000000002 is an unknown value > x12={method} {0x0000000800467b20} 'getLong' '(Ljava/lang/Object;J)J' in 'jdk/internal/misc/Unsafe' > x13=0x0000000080000000 is an unknown value > x14= > > and: > > Register to memory mapping: > > x0=0x000000000000000a is an unknown value > x1=0x000000000000000a is an unknown value > x2=0x0 is NULL > x3=0x000000000000000a is an unknown value > x4=0x000000012002ebc0 is pointing into metadata > x5=0x0000000000000012 is an unknown value > x6=0x0 is NULL > x7=0x0000000136808210 is a thread > x8=0x0 is NULL > x9=0x0000000000000001 is an unknown value > x10=0x2010000030300000 is an unknown value > x11=0x0000010000000102 is an unknown value > x12={method} {0x00000008004b0ed0} 'getLong' '(Ljava/lang/Object;J)J' in 'jdk/internal/misc/Unsafe' > x13=0x0000000080000000 is an unknown value > x14= > > > To avoid the MachCodeFramesInErrorFile test failing as a result the truncation, the test has been modified to pass if the section preceding the code blob dumping is not seen. Workaround seems reasonable, but this begs the question as to why the hs_err file is truncated - especially in such a consistent manner? Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8650 From jvernee at openjdk.java.net Wed May 11 14:29:19 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 14:29:19 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v8] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: - Migrate to GrowableArray - Address some review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/43fd1b91..abd2b6ca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=06-07 Stats: 254 lines in 23 files changed: 22 ins; 125 del; 107 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 14:29:25 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 14:29:25 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: <9eViilPD2YEH0Lt8StEhiGJfDlMSSa1NpPC02MKItuM=.0ce2490e-9a53-46b3-a14b-ab88b4a0f3fc@github.com> On Tue, 10 May 2022 21:02:39 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > Nice work! Looks good. Some minor comments/questions follow. @iwanowww Thanks for the review! I've addressed most comments already, but will have to think a bit on how to handle the asynchronous exceptions issue. > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5531: > >> 5529: } >> 5530: >> 5531: // On 64 bit we will store integer like items to the stack as > > Time for a cleanup? `64 bit` vs `64bit`, `abi`, `Aarch64`. I've cleaned up the spaces and capitalization here a bit. > src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 36: > >> 34: #include "code/nativeInst.hpp" >> 35: #include "code/vtableStubs.hpp" >> 36: #include "compiler/disassembler.hpp" > > Redundant includes? No new code added in the file. Good catch. Seems like a merge artifact maybe. Removing them seems to be fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 14:33:56 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 14:33:56 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Wed, 11 May 2022 11:06:51 GMT, Jorn Vernee wrote: >> src/hotspot/share/opto/callGenerator.cpp line 1131: >> >>> 1129: >>> 1130: case vmIntrinsics::_linkToNative: >>> 1131: print_inlining_failure(C, callee, jvms->depth() - 1, jvms->bci(), >> >> Why is it unconditionally reported as inlining failure? > > The call that is being processed here is `linkToNative`, and that call is not inlined, so reporting an inlining failure seems correct. We still go through the method handle trampoline stub which loads the actual target from the NativeEntryPoint appendix argument (`jump_to_native_invoker` in methodHandles_x86.cpp). > > It's potentially faster here to generate a runtime call to the underlying invoker/downcall stub if the NativeEntryPoint is constant (i.e. avoid the lookup through NEP in the MH trampoline), but I hadn't gotten to investigating that yet. > > From comparing the benchmark times between this and the old implementation (which generated an inline call), they are not all that different. So it seemed that doing something special here would not save that much time any ways. (but, still would be good to investigate at some point) I've filed: https://bugs.openjdk.java.net/browse/JDK-8286588 ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 14:34:02 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 14:34:02 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: <1xENEcoejLZmUfLYTJsJ-nUWF9dlZ3BdXdpvSU_JoPk=.8efe4cde-cdc1-4174-a4a2-5437464f55d2@github.com> On Tue, 10 May 2022 20:38:05 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/share/prims/foreign_globals.cpp line 217: > >> 215: >> 216: public: >> 217: ForeignCMO(int total_in_args, const VMRegPair* in_regs, int total_out_args, VMRegPair* out_regs, > > I propose to turn it into a trivial ctor and move all the logic into a helper static function which returns the computed moves. Done. Moved constructor logic into a `compute` method, and added a static helper that constructs a ComputeMoveOrder, calls `compute`, and then returns the moves. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From coleenp at openjdk.java.net Wed May 11 15:06:57 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 11 May 2022 15:06:57 GMT Subject: RFR: 8282607: runtime/ErrorHandling/MachCodeFramesInErrorFile.java failed with "RuntimeException: 0 < 2" In-Reply-To: References: Message-ID: On Wed, 11 May 2022 10:36:19 GMT, Doug Simon wrote: > I've looked through the failures reported in https://bugs.openjdk.java.net/browse/JDK-8282607 and in all cases, the problem is that hs_err is truncated while printing the register to memory mapping and always while printing x14. Here are a few examples: > > > Register to memory mapping: > > x0=0x000000000000000a is an unknown value > x1=0x000000000000000a is an unknown value > x2=0x0 is NULL > x3=0x000000000000000a is an unknown value > x4=0x000000013e009080 points into unknown readable memory: 0xabababababababab | ab ab ab ab ab ab ab ab > x5=0x0000000000000005 is an unknown value > x6=0x0 is NULL > x7=0x0 is NULL > x8=0x0 is NULL > x9=0x0000000000000001 is an unknown value > x10=0x2010000030300000 is an unknown value > x11=0x0000000000000002 is an unknown value > x12={method} {0x0000000800467b20} 'getLong' '(Ljava/lang/Object;J)J' in 'jdk/internal/misc/Unsafe' > x13=0x0000000080000000 is an unknown value > x14= > > and: > > Register to memory mapping: > > x0=0x000000000000000a is an unknown value > x1=0x000000000000000a is an unknown value > x2=0x0 is NULL > x3=0x000000000000000a is an unknown value > x4=0x000000012002ebc0 is pointing into metadata > x5=0x0000000000000012 is an unknown value > x6=0x0 is NULL > x7=0x0000000136808210 is a thread > x8=0x0 is NULL > x9=0x0000000000000001 is an unknown value > x10=0x2010000030300000 is an unknown value > x11=0x0000010000000102 is an unknown value > x12={method} {0x00000008004b0ed0} 'getLong' '(Ljava/lang/Object;J)J' in 'jdk/internal/misc/Unsafe' > x13=0x0000000080000000 is an unknown value > x14= > > > To avoid the MachCodeFramesInErrorFile test failing as a result of the intermittent truncation, the test has been modified to pass if the section preceding the code blob dumping is not seen. I think this is fine. We have a bunch of open issues wrt to truncated hs_err files. We're not sure if it's the testing environment or not https://bugs.openjdk.java.net/browse/JDK-8275677 There's one also still open: https://bugs.openjdk.java.net/browse/JDK-8239567 I think it's fine to tolerate this in this test. It seems to always be macos or bsd. Should this also check for bsd ? ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8650 From dnsimon at openjdk.java.net Wed May 11 15:18:45 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 11 May 2022 15:18:45 GMT Subject: RFR: 8282607: runtime/ErrorHandling/MachCodeFramesInErrorFile.java failed with "RuntimeException: 0 < 2" In-Reply-To: References: Message-ID: On Wed, 11 May 2022 12:29:38 GMT, David Holmes wrote: > ... this begs the question as to why the hs_err file is truncated I don't know but I left a few guesses in [this comment](https://bugs.openjdk.java.net/browse/JDK-8282607?focusedCommentId=14495313&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14495313): * Is register x14 special on macosx-aarch64? * Could this be a missing WX transition in hs-err dumping? * Or some unsafe memory access in [os::print_location](https://github.com/openjdk/jdk/blob/73c5e993e17f7435553edae79a1e8d70ece5493d/src/hotspot/share/runtime/os.cpp#L1072)? > It seems to always be macos or bsd. Should this also check for bsd ? I haven't seen any instances of it failing on bsd so would prefer to keep the workaround specific to macOS. ------------- PR: https://git.openjdk.java.net/jdk/pull/8650 From jvernee at openjdk.java.net Wed May 11 15:24:39 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 15:24:39 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v9] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Fix use of rt_call ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/abd2b6ca..c6754a1c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 15:47:11 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 15:47:11 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> On Wed, 11 May 2022 12:05:29 GMT, Jorn Vernee wrote: >> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 306: >> >>> 304: intptr_t exception_handler_offset = __ pc() - start; >>> 305: >>> 306: // Native caller has no idea how to handle exceptions, >> >> Can you elaborate, please, how it is expected to work in presence of asynchronous exceptions? I'd expect to see a code which unconditionally clears pending exception with an assertion that verifies that the exception is of expected type. > > We have an exception handler in Java as well, so this code is only a fail safe. But, I think in the case of asynchronous exceptions this might be problematic if the exception is discovered by the current thread outside of the Java exception handler, turned into a synchronous exception and then we get here and call `ProgrammableUpcallhandler::handle_uncaught_exception` and then crash. Or if the asynchronous exception is discovered in `ProgrammableUpcallHandler::on_exit` (where there is currently an assert for no exceptions). > > I think you're right that, in both of those cases, if the exception is asynchronous, we should just ignore it. Discussed this with Maurizio as well. My understanding is as follows: 1. Async exceptions are installed into a thread's `pending_exception` field by handshake at a safepoint 2. From there they are "thrown" (I guess during the same safepoint?), in which case we either end up in a user-defined exception handler (higher up the stack), in our Java fallback exception handler (print stack trace and terminate), or in this fallback exception handler (print and terminate). 3. If we end up in this exception handler it means the async exception was installed somewhere outside of our Java exception handler and "thrown" from there. However, it also means that the Java code we were calling into completed abruptly. 4. We've previously established that we have no way of signalling to the native code that is calling us that something went wrong, and so the only safe option is to terminate, as to not leave the application in an inconsistent state. As a consequence, I don't think we have much choice in the case of async exceptions if we get here. Silently clearing them seems like it will leave the program in an inconsistent state (since we unwound some frames), so we have to terminate I think. (@dholmes-ora is my understanding of async exceptions in point 1. and 2. correct here?) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 15:47:12 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 15:47:12 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v9] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 12:20:43 GMT, Jorn Vernee wrote: >> Any problems with migrating `CallConv` and `RegSpiller`away from ` VMReg* + int` to `GrowableArray`? > > I'll try migrating to `GrowableArray` Done. I've removed these accessors as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From mkartashev at openjdk.java.net Wed May 11 16:03:54 2022 From: mkartashev at openjdk.java.net (Maxim Kartashev) Date: Wed, 11 May 2022 16:03:54 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup This change seem to have made this group of declarations obsolete: `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link]( https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From pchilanomate at openjdk.java.net Wed May 11 16:24:02 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 11 May 2022 16:24:02 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> Message-ID: <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> On Wed, 11 May 2022 15:44:19 GMT, Jorn Vernee wrote: >> We have an exception handler in Java as well, so this code is only a fail safe. But, I think in the case of asynchronous exceptions this might be problematic if the exception is discovered by the current thread outside of the Java exception handler, turned into a synchronous exception and then we get here and call `ProgrammableUpcallhandler::handle_uncaught_exception` and then crash. Or if the asynchronous exception is discovered in `ProgrammableUpcallHandler::on_exit` (where there is currently an assert for no exceptions). >> >> I think you're right that, in both of those cases, if the exception is asynchronous, we should just ignore it. > > Discussed this with Maurizio as well. > > My understanding is as follows: > 1. Async exceptions are installed into a thread's `pending_exception` field by handshake at a safepoint > 2. From there they are "thrown" (I guess during the same safepoint?), in which case we either end up in a user-defined exception handler (higher up the stack), in our Java fallback exception handler (print stack trace and terminate), or in this fallback exception handler (print and terminate). > 3. If we end up in this exception handler it means the async exception was installed somewhere outside of our Java exception handler and "thrown" from there. However, it also means that the Java code we were calling into completed abruptly. > 4. We've previously established that we have no way of signalling to the native code that is calling us that something went wrong, and so the only safe option is to terminate, as to not leave the application in an inconsistent state. > > As a consequence, I don't think we have much choice in the case of async exceptions if we get here. Silently clearing them seems like it will leave the program in an inconsistent state (since we unwound some frames), so we have to terminate I think. > > (@dholmes-ora is my understanding of async exceptions in point 1. and 2. correct here?) If you want to avoid processing asynchronous exceptions during this upcall you could block them (check NoAsyncExceptionDeliveryMark in JavaThread::exit()). Seems you could set the flag in ProgrammableUpcallhandler::on_entry() and unset it back on ProgrammableUpcallhandler::on_exit(). While that flag is set any asynchronous exception in the handshake queue of this thread will be skipped from processing. Maybe we should add a public method in the JavaThread class, block_async_exceptions()/unblock_async_exceptions() so we hide the handshake implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 16:42:59 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 16:42:59 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> Message-ID: On Wed, 11 May 2022 16:20:32 GMT, Patricio Chilano Mateo wrote: >> Discussed this with Maurizio as well. >> >> My understanding is as follows: >> 1. Async exceptions are installed into a thread's `pending_exception` field by handshake at a safepoint >> 2. From there they are "thrown" (I guess during the same safepoint?), in which case we either end up in a user-defined exception handler (higher up the stack), in our Java fallback exception handler (print stack trace and terminate), or in this fallback exception handler (print and terminate). >> 3. If we end up in this exception handler it means the async exception was installed somewhere outside of our Java exception handler and "thrown" from there. However, it also means that the Java code we were calling into completed abruptly. >> 4. We've previously established that we have no way of signalling to the native code that is calling us that something went wrong, and so the only safe option is to terminate, as to not leave the application in an inconsistent state. >> >> As a consequence, I don't think we have much choice in the case of async exceptions if we get here. Silently clearing them seems like it will leave the program in an inconsistent state (since we unwound some frames), so we have to terminate I think. >> >> (@dholmes-ora is my understanding of async exceptions in point 1. and 2. correct here?) > > If you want to avoid processing asynchronous exceptions during this upcall you could block them (check NoAsyncExceptionDeliveryMark in JavaThread::exit()). Seems you could set the flag in ProgrammableUpcallhandler::on_entry() and unset it back on ProgrammableUpcallhandler::on_exit(). While that flag is set any asynchronous exception in the handshake queue of this thread will be skipped from processing. Maybe we should add a public method in the JavaThread class, block_async_exceptions()/unblock_async_exceptions() so we hide the handshake implementation. Oh nice! I was just thinking that the only possible way out of this conundrum would be to somehow block the delivery of async exceptions (at least outside of the user's exception handler). So, that seems to be exactly what we need :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From paul.sandoz at oracle.com Wed May 11 16:45:22 2022 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 11 May 2022 16:45:22 +0000 Subject: MethodType runtime API vs constant pool entry of the same type In-Reply-To: References: Message-ID: <7D1A1AAA-CED0-4533-B024-C716E72412BB@oracle.com> Hi David, Yeah, it's confusing, and in this case I think underspecified. I suspect the resolution in this case refers to operating on the loader via ClassLoader::loadClass [1] (whereby object parameter descriptors are first converted to binary class names) We could update the API spec to be clearer and link to MethodTypeDesc. Paul. [1] ClassLoader::loadClass also confusingly states: "It is invoked by the Java virtual machine to resolve class references." > On May 10, 2022, at 6:07 PM, David Holmes wrote: > > Hi Paul, > > On 11/05/2022 8:51 am, Paul Sandoz wrote: >> MethodType.fromMethodDescriptorString does not have the bytecode behavior of loading a method type from the constant pool, where access control checks are applied. > > The API spec states: > > "Any class or interface name embedded in the descriptor string will be resolved by the given loader ..." > > And resolution includes an access control check. > > David > ----- > >> The use of the string descriptor is a convenience and not meant to imply bytecode behavior. The method, as stated, defers resolution of classes to the given class loader. In your Java code example it's equivalent to doing: >> MethodType m = MethodType.methodType(Class.forName("foo.Foo$Bar", false, Test.class.getClassLoader())); >> The following paragraph after that which you quote states: >> * When the JVM materializes a {@code MethodType} from a descriptor string, >> * all classes named in the descriptor must be accessible, and will be loaded. >> * (But the classes need not be initialized, as is the case with a {@code CONSTANT_Class}.) >> * This loading may occur at any time before the {@code MethodType} object is first derived. >> In jasm try doing a ldc of class Bar and you should also get an illegal access error [1]. >> The equivalent bytecode behavior (except for the exception, error vs runtime exception) can be achieved using the nominal descriptor: >> MethodTypeDesc d = MethodTypeDesc.ofDescriptor("()Lfoo/Foo$Bar;"); >> MethodType m = (MethodType) d.resolveConstantDesc(MethodHandles.lookup()); // throws IllegalAccessException >> Which in turn is equivalent to: >> MethodHandles.Lookup l = MethodHandles.lookup(); >> MethodType m = MethodType.fromMethodDescriptorString( >> "()Lfoo/Foo$Bar;", >> l.lookupClass().getClassLoader() >> ); >> l.accessClass(m.returnType()); // > Hth, >> Paul. >> [1] https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-5.html#jvms-5.4.3.1 >>> On May 9, 2022, at 8:08 PM, Maxim Degtyarev wrote: >>> >>> Inspired by https://mail.openjdk.java.net/pipermail/compiler-dev/2022-May/019558.html >>> >>> According to the JDK 17 `j.l.i.MethodType` javadoc [1]: >>> >>> Like classes and strings, method types can also be represented >>> directly in a class file's constant pool as constants. >>> A method type may be loaded by an ldc instruction which refers to a >>> suitable CONSTANT_MethodType constant pool entry. >>> The entry refers to a CONSTANT_Utf8 spelling for the descriptor >>> string. (For full details on method type constants, >>> see sections 4.4.8 and 5.4.3.5 of the Java Virtual Machine Specification.) >>> >>> >>> If I understand it correctly, this implies that any `MethodType` >>> instance that can be successfully created with the >>> call to `MethodType.fromMethodDescriptorString()` method can be also >>> represented as a constant pool entry of type MethodType. >>> >>> >>> Now consider the following example: >>> >>> >>> // main/TestRuntime.java >>> package main; >>> >>> import java.lang.invoke.MethodType; >>> >>> public class TestRuntime { >>> >>> public static void main(String... args) { >>> System.out.println( >>> MethodType.fromMethodDescriptorString( >>> "()Lfoo/Foo$Bar;", >>> TestRuntime.class.getClassLoader() >>> ) >>> ); >>> } >>> >>> } >>> >>> >>> // main/TestConstantPool.jasm >>> /** >>> * >>> * You need asmtools >>> to assemble this example. >>> * >>> * To assemble run: >>> * >>> * java -jar asmtools.jar jasm -g TestConstantPool.jasm >>> * >>> * >>> */ >>> package main; >>> >>> super public class TestConstantPool >>> version 52:0 >>> { >>> public Method "":"()V" >>> stack 1 locals 1 >>> { >>> aload_0; >>> invokespecial Method java/lang/Object."":"()V"; >>> return; >>> } >>> >>> public static varargs Method main:"([Ljava/lang/String;)V" >>> stack 2 locals 1 >>> { >>> getstatic Field java/lang/System.out:"Ljava/io/PrintStream;"; >>> ldc MethodType "()Lfoo/Foo$Bar;"; >>> invokevirtual Method >>> java/io/PrintStream.println:"(Ljava/lang/Object;)V"; >>> return; >>> >>> } >>> } // end Class TestConstantPool >>> >>> >>> // foo/Foo.java >>> package foo; >>> >>> public class Foo { >>> public static Bar bar() { >>> return new Bar(); >>> } >>> >>> static class Bar {} >>> } >>> >>> >>> Both `main.TestRuntime` and `main.TestConstantPool` are functionally >>> equal and should print >>> string representation of the `MethodType` instance. >>> >>> >>> While `main.TestRuntime` behaves as expected: >>> >>> $ java main.TestRuntime >>> ()Bar >>> >>> >>> The `main.TestConstantPool` failed with `j.l.IllegalAccessError`: >>> >>> $ java main.TestConstantPool >>> Exception in thread "main" java.lang.IllegalAccessError: tried to >>> access class foo.Foo$Bar from class main.TestConstantPool >>> at main.TestConstantPool.main(TestConstantPool.jasm:18) >>> >>> >>> However, if we declare class `foo.Foo.Bar` public then both >>> `TestRuntime` and `TestConstantPool` run without exceptions. >>> >>> >>> Checked both with `Java(TM) SE Runtime Environment (build >>> 1.8.0_152-b16)` and `OpenJDK Runtime Environment (build >>> 19-ea+21-1482)`. >>> >>> >>> Questions: >>> >>> 1) Shouldn't both examples expose equal behaviour? >>> >>> 2) Which of 2 observed behaviours is correct? >>> >>> >>> Examples from this message can be found at [2] >>> >>> >>> [1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/MethodType.html >>> [2] https://github.com/Maccimo/MethodType-API-vs-ConstantPool From jvernee at openjdk.java.net Wed May 11 17:51:31 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 17:51:31 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v10] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: - Block async exceptions during upcalls - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 - Fix use of rt_call - Migrate to GrowableArray - Address some review comments - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 - Remove unneeded ComputeMoveOrder - Remove comment about native calls in lcm.cpp - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 Reviewed-by: jvernee, mcimadamore - Update riscv and arm stubs - ... and 16 more: https://git.openjdk.java.net/jdk/compare/cdd006e7...b29ad8f4 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7959/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=09 Stats: 6870 lines in 157 files changed: 2596 ins; 3218 del; 1056 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 17:58:46 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 17:58:46 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> Message-ID: On Wed, 11 May 2022 16:38:54 GMT, Jorn Vernee wrote: >> If you want to avoid processing asynchronous exceptions during this upcall you could block them (check NoAsyncExceptionDeliveryMark in JavaThread::exit()). Seems you could set the flag in ProgrammableUpcallhandler::on_entry() and unset it back on ProgrammableUpcallhandler::on_exit(). While that flag is set any asynchronous exception in the handshake queue of this thread will be skipped from processing. Maybe we should add a public method in the JavaThread class, block_async_exceptions()/unblock_async_exceptions() so we hide the handshake implementation. > > Oh nice! I was just thinking that the only possible way out of this conundrum would be to somehow block the delivery of async exceptions (at least outside of the user's exception handler). So, that seems to be exactly what we need :) I went ahead and implemented this suggestion. Now we block async exceptions in on_entry, and unblock in on_exit. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From dnsimon at openjdk.java.net Wed May 11 20:11:46 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 11 May 2022 20:11:46 GMT Subject: Integrated: 8282607: runtime/ErrorHandling/MachCodeFramesInErrorFile.java failed with "RuntimeException: 0 < 2" In-Reply-To: References: Message-ID: On Wed, 11 May 2022 10:36:19 GMT, Doug Simon wrote: > I've looked through the failures reported in https://bugs.openjdk.java.net/browse/JDK-8282607 and in all cases, the problem is that hs_err is truncated while printing the register to memory mapping and always while printing x14. Here are a few examples: > > > Register to memory mapping: > > x0=0x000000000000000a is an unknown value > x1=0x000000000000000a is an unknown value > x2=0x0 is NULL > x3=0x000000000000000a is an unknown value > x4=0x000000013e009080 points into unknown readable memory: 0xabababababababab | ab ab ab ab ab ab ab ab > x5=0x0000000000000005 is an unknown value > x6=0x0 is NULL > x7=0x0 is NULL > x8=0x0 is NULL > x9=0x0000000000000001 is an unknown value > x10=0x2010000030300000 is an unknown value > x11=0x0000000000000002 is an unknown value > x12={method} {0x0000000800467b20} 'getLong' '(Ljava/lang/Object;J)J' in 'jdk/internal/misc/Unsafe' > x13=0x0000000080000000 is an unknown value > x14= > > and: > > Register to memory mapping: > > x0=0x000000000000000a is an unknown value > x1=0x000000000000000a is an unknown value > x2=0x0 is NULL > x3=0x000000000000000a is an unknown value > x4=0x000000012002ebc0 is pointing into metadata > x5=0x0000000000000012 is an unknown value > x6=0x0 is NULL > x7=0x0000000136808210 is a thread > x8=0x0 is NULL > x9=0x0000000000000001 is an unknown value > x10=0x2010000030300000 is an unknown value > x11=0x0000010000000102 is an unknown value > x12={method} {0x00000008004b0ed0} 'getLong' '(Ljava/lang/Object;J)J' in 'jdk/internal/misc/Unsafe' > x13=0x0000000080000000 is an unknown value > x14= > > > To avoid the MachCodeFramesInErrorFile test failing as a result of the intermittent truncation, the test has been modified to pass if the section preceding the code blob dumping is not seen. This pull request has now been integrated. Changeset: 1c50ea36 Author: Doug Simon URL: https://git.openjdk.java.net/jdk/commit/1c50ea36a5878869ecdba7c3135eea4216ade675 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod 8282607: runtime/ErrorHandling/MachCodeFramesInErrorFile.java failed with "RuntimeException: 0 < 2" Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/8650 From pchilanomate at openjdk.java.net Wed May 11 20:31:05 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 11 May 2022 20:31:05 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> Message-ID: On Wed, 11 May 2022 17:55:16 GMT, Jorn Vernee wrote: >> Oh nice! I was just thinking that the only possible way out of this conundrum would be to somehow block the delivery of async exceptions (at least outside of the user's exception handler). So, that seems to be exactly what we need :) > > I went ahead and implemented this suggestion. Now we block async exceptions in on_entry, and unblock in on_exit. Is it possible for these upcalls to be nested? If yes, we could add a boolean to context to avoid unsetting the flag in those nested cases. And now that I think we should probably add that check in NoAsyncExceptionDeliveryMark too if we allow broader use of this flag. David added the NoAsyncExceptionDeliveryMark code with that assert about nesting so maybe he might have more insights about that. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From dholmes at openjdk.java.net Thu May 12 03:30:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 May 2022 03:30:43 GMT Subject: RFR: 8282607: runtime/ErrorHandling/MachCodeFramesInErrorFile.java failed with "RuntimeException: 0 < 2" In-Reply-To: References: Message-ID: On Wed, 11 May 2022 10:36:19 GMT, Doug Simon wrote: > I've looked through the failures reported in https://bugs.openjdk.java.net/browse/JDK-8282607 and in all cases, the problem is that hs_err is truncated while printing the register to memory mapping and always while printing x14. Here are a few examples: > > > Register to memory mapping: > > x0=0x000000000000000a is an unknown value > x1=0x000000000000000a is an unknown value > x2=0x0 is NULL > x3=0x000000000000000a is an unknown value > x4=0x000000013e009080 points into unknown readable memory: 0xabababababababab | ab ab ab ab ab ab ab ab > x5=0x0000000000000005 is an unknown value > x6=0x0 is NULL > x7=0x0 is NULL > x8=0x0 is NULL > x9=0x0000000000000001 is an unknown value > x10=0x2010000030300000 is an unknown value > x11=0x0000000000000002 is an unknown value > x12={method} {0x0000000800467b20} 'getLong' '(Ljava/lang/Object;J)J' in 'jdk/internal/misc/Unsafe' > x13=0x0000000080000000 is an unknown value > x14= > > and: > > Register to memory mapping: > > x0=0x000000000000000a is an unknown value > x1=0x000000000000000a is an unknown value > x2=0x0 is NULL > x3=0x000000000000000a is an unknown value > x4=0x000000012002ebc0 is pointing into metadata > x5=0x0000000000000012 is an unknown value > x6=0x0 is NULL > x7=0x0000000136808210 is a thread > x8=0x0 is NULL > x9=0x0000000000000001 is an unknown value > x10=0x2010000030300000 is an unknown value > x11=0x0000010000000102 is an unknown value > x12={method} {0x00000008004b0ed0} 'getLong' '(Ljava/lang/Object;J)J' in 'jdk/internal/misc/Unsafe' > x13=0x0000000080000000 is an unknown value > x14= > > > To avoid the MachCodeFramesInErrorFile test failing as a result of the intermittent truncation, the test has been modified to pass if the section preceding the code blob dumping is not seen. I've reopened JDK-8275677 to track this specific failure mode. ------------- PR: https://git.openjdk.java.net/jdk/pull/8650 From dholmes at openjdk.java.net Thu May 12 03:37:53 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 May 2022 03:37:53 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v10] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 17:51:31 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: > > - Block async exceptions during upcalls > - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 > - Fix use of rt_call > - Migrate to GrowableArray > - Address some review comments > - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 > - Remove unneeded ComputeMoveOrder > - Remove comment about native calls in lcm.cpp > - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 > > Reviewed-by: jvernee, mcimadamore > - Update riscv and arm stubs > - ... and 16 more: https://git.openjdk.java.net/jdk/compare/cdd006e7...b29ad8f4 src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp line 3: > 1: /* > 2: * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (c) 2019, 2021, Arm Limited. All rights reserved. Only update third-party copyrights under direction from that copyright holder. This may not be the correct format for example. Also it is 2022. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From dholmes at openjdk.java.net Thu May 12 03:37:54 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 May 2022 03:37:54 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> Message-ID: <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com> On Wed, 11 May 2022 20:27:42 GMT, Patricio Chilano Mateo wrote: >> I went ahead and implemented this suggestion. Now we block async exceptions in on_entry, and unblock in on_exit. > > Is it possible for these upcalls to be nested? If yes, we could add a boolean to context to avoid unsetting the flag in those nested cases. And now that I think we should probably add that check in NoAsyncExceptionDeliveryMark too if we allow broader use of this flag. David added the NoAsyncExceptionDeliveryMark code with that assert about nesting so maybe he might have more insights about that. NoAsyncExceptionDeliveryMark is not for general use! There is no provision for blocking async exceptions when running user-defined Java code. NoAsyncExceptionDeliveryMark was purely for protecting "system Java code". ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From stuefe at openjdk.java.net Thu May 12 03:44:39 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 12 May 2022 03:44:39 GMT Subject: RFR: 8282607: runtime/ErrorHandling/MachCodeFramesInErrorFile.java failed with "RuntimeException: 0 < 2" In-Reply-To: References: Message-ID: On Wed, 11 May 2022 10:36:19 GMT, Doug Simon wrote: > I've looked through the failures reported in https://bugs.openjdk.java.net/browse/JDK-8282607 and in all cases, the problem is that hs_err is truncated while printing the register to memory mapping and always while printing x14. Here are a few examples: > > > Register to memory mapping: > > x0=0x000000000000000a is an unknown value > x1=0x000000000000000a is an unknown value > x2=0x0 is NULL > x3=0x000000000000000a is an unknown value > x4=0x000000013e009080 points into unknown readable memory: 0xabababababababab | ab ab ab ab ab ab ab ab > x5=0x0000000000000005 is an unknown value > x6=0x0 is NULL > x7=0x0 is NULL > x8=0x0 is NULL > x9=0x0000000000000001 is an unknown value > x10=0x2010000030300000 is an unknown value > x11=0x0000000000000002 is an unknown value > x12={method} {0x0000000800467b20} 'getLong' '(Ljava/lang/Object;J)J' in 'jdk/internal/misc/Unsafe' > x13=0x0000000080000000 is an unknown value > x14= > > and: > > Register to memory mapping: > > x0=0x000000000000000a is an unknown value > x1=0x000000000000000a is an unknown value > x2=0x0 is NULL > x3=0x000000000000000a is an unknown value > x4=0x000000012002ebc0 is pointing into metadata > x5=0x0000000000000012 is an unknown value > x6=0x0 is NULL > x7=0x0000000136808210 is a thread > x8=0x0 is NULL > x9=0x0000000000000001 is an unknown value > x10=0x2010000030300000 is an unknown value > x11=0x0000010000000102 is an unknown value > x12={method} {0x00000008004b0ed0} 'getLong' '(Ljava/lang/Object;J)J' in 'jdk/internal/misc/Unsafe' > x13=0x0000000080000000 is an unknown value > x14= > > > To avoid the MachCodeFramesInErrorFile test failing as a result of the intermittent truncation, the test has been modified to pass if the section preceding the code blob dumping is not seen. Yes, this should be fixed instead of hidden. ------------- PR: https://git.openjdk.java.net/jdk/pull/8650 From dholmes at openjdk.java.net Thu May 12 04:28:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 May 2022 04:28:43 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 11 May 2022 16:00:32 GMT, Maxim Kartashev wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> adjust API level to Windows 8 for security.cpp and do some cleanup > > This change seem to have made this group of declarations obsolete: > `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link]( > https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself. @mkartashev all references to WINVER in the AWT code seem obsolete. Possibly most of the IS_WINxxx usages could also be replaced. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From iklam at openjdk.java.net Thu May 12 06:16:45 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 12 May 2022 06:16:45 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems In-Reply-To: References: Message-ID: On Tue, 10 May 2022 12:29:10 GMT, Severin Gehwolf wrote: > Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter). > > In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running. > > Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round). > > Testing: > - [x] Added unit tests > - [x] GHA > - [x] Container tests on cgroups v1 Linux. Continue to pass I just started to look at the code so just one comment for now. src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 65: > 63: path = mountPoint + cgroupSubstr; > 64: } > 65: } else { Looks like `path` is still not set if the condition at line 61 `if (cgroupPath.length() > root.length()) {` is false. ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From mbaesken at openjdk.java.net Thu May 12 07:31:50 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 12 May 2022 07:31:50 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 11 May 2022 16:00:32 GMT, Maxim Kartashev wrote: > This change seem to have made this group of declarations obsolete: `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link](https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself. Hi Maxim, no plans from me, so feel free to do further cleanups. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From ngasson at openjdk.java.net Thu May 12 08:27:00 2022 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 12 May 2022 08:27:00 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v10] In-Reply-To: References: Message-ID: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com> On Thu, 12 May 2022 03:34:19 GMT, David Holmes wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: >> >> - Block async exceptions during upcalls >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Fix use of rt_call >> - Migrate to GrowableArray >> - Address some review comments >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - ... and 16 more: https://git.openjdk.java.net/jdk/compare/cdd006e7...b29ad8f4 > > src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp line 3: > >> 1: /* >> 2: * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. >> 3: * Copyright (c) 2019, 2021, Arm Limited. All rights reserved. > > Only update third-party copyrights under direction from that copyright holder. This may not be the correct format for example. > Also it is 2022. :) I think the Arm Ltd one was probably changed by me in one of the PRs in the Panama repo. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 09:28:59 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 09:28:59 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v11] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Revert "Block async exceptions during upcalls" This reverts commit b29ad8f46732666f2d07e63ce8701b1eb7bed790. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/b29ad8f4..1c04a42e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=09-10 Stats: 25 lines in 3 files changed: 0 ins; 21 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 09:29:00 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 09:29:00 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com> Message-ID: On Thu, 12 May 2022 03:32:15 GMT, David Holmes wrote: >> Is it possible for these upcalls to be nested? If yes, we could add a boolean to context to avoid unsetting the flag in those nested cases. And now that I think we should probably add that check in NoAsyncExceptionDeliveryMark too if we allow broader use of this flag. David added the NoAsyncExceptionDeliveryMark code with that assert about nesting so maybe he might have more insights about that. > > NoAsyncExceptionDeliveryMark is not for general use! There is no provision for blocking async exceptions when running user-defined Java code. NoAsyncExceptionDeliveryMark was purely for protecting "system Java code". Okay, I see. I think I acted a little too hastily on this yesterday. I'll revert the change that uses this blocking mechanism. The stack more or less looks like this during an upcall: | --- | | | --- | <1: user define try block with exception handler (maybe)> | | --- | <2: user code start> | | --- | <3: method handle impl frames 1> | | --- | <4: upcall wrapper class with fallback handler 1> | | --- | <5: method handle impl frames 2> | | --- | <6: upcallk stub with fallback handler 2> | | <7: unknown native code> | --- | | I think there are several options to address async exceptions: 1. Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will up in one of the fallback handlers and the VM will be terminated. 2. Block async exceptions in all code up from 6. 3. Somehow only block async exceptions only between 6. and 1. I think that is possible by changing the API so that the user passes us a method handle to their fallback exception handler. We would need 2 methods for blocking and unblocking async exceptions from Java. Then we could disable async exceptions at the start of 6. enabled them at the start of the try block in 4. (around the call to user code), and disable them at the end of this try block. Then finally re-enable them at the end of 6. If an exception occurs in the try block in 4., delegate to the user-defined exception handler (but use the VM terminate strategy as a fallback for when another exception occurs). The other problem I see with that is that to make that fast enough (i.e. not incur a ~1.5-2x cost on call overhead), we would need compiler intrinsics for the blocking/unblocking, and in the past we've been unable to define 'critical' sections of code like that in C2 (it's an unsolved problem at this point). ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 09:31:36 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 09:31:36 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v10] In-Reply-To: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com> References: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com> Message-ID: On Thu, 12 May 2022 08:23:11 GMT, Nick Gasson wrote: >> src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp line 3: >> >>> 1: /* >>> 2: * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. >>> 3: * Copyright (c) 2019, 2021, Arm Limited. All rights reserved. >> >> Only update third-party copyrights under direction from that copyright holder. This may not be the correct format for example. >> Also it is 2022. :) > > I think the Arm Ltd one was probably changed by me in one of the PRs in the Panama repo. Right, I brought in these commits from the Panama repo, so this is from Nick's updates there (specifically from this PR: https://github.com/openjdk/panama-foreign/pull/610). I'm not sure what to do here. I own the PR, but Nick is a contributor on it, so some of the changes are his (including this copyright year change). ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From sgehwolf at openjdk.java.net Thu May 12 10:07:31 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 12 May 2022 10:07:31 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems In-Reply-To: References: Message-ID: On Thu, 12 May 2022 06:11:03 GMT, Ioi Lam wrote: >> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter). >> >> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running. >> >> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round). >> >> Testing: >> - [x] Added unit tests >> - [x] GHA >> - [x] Container tests on cgroups v1 Linux. Continue to pass > > src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 65: > >> 63: path = mountPoint + cgroupSubstr; >> 64: } >> 65: } else { > > Looks like `path` is still not set if the condition at line 61 `if (cgroupPath.length() > root.length()) {` is false. Yes. There are more cases where the cgroup path might be null. If you know of cases that should be handled and aren't, please do let me know. Incidentally, that's why I've added the catch for NPE in `CgroupV1Subsystem.initSubSystem()`, because it's not clear what should be used as `path` in those corner cases. It certainly shouldn't throw a NPE :-). It then also more closely matches what hotspot does. Having said that, if `cgroupPath.length < root.length()` it's implied that `cgroupPath.startsWith(root)` is false. Then the only case where it would still be null is when the paths match in lenght, but aren't the same. I'm not convinced the logic when then cgroup patch starts with the root path, then it should do what it does today. I.e. given `mountpath=/sys/fs/cgroup/memory`, `root=/foo/bar` and `cgroupPath=/foo/bar/baz` then `path=/sys/fs/cgroup/memory/baz`. I've personally not seen such a setup and the code predates me. Considering that the equivalent hotspot code had a bug in this logic since day 1, it doesn't seem very widely used... The most common cases I know to date are: 1. `root=/`, `cgroupPath=/some`, `mount=/sys/fs/cgroup/controller` => `path=/sys/fs/cgroup/controller/some` (host systems) 2. `root=/foo/bar/baz`, `cgroupPath=/foo/bar/baz`, `mount=/sys/fs/cgroup/controller` => `path=/sys/fs/cgroup/controller` (most container engines) ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From mkartashev at openjdk.java.net Thu May 12 11:00:49 2022 From: mkartashev at openjdk.java.net (Maxim Kartashev) Date: Thu, 12 May 2022 11:00:49 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Thu, 12 May 2022 04:25:24 GMT, David Holmes wrote: >> This change seem to have made this group of declarations obsolete: >> `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link]( >> https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself. > > @mkartashev all references to WINVER in the AWT code seem obsolete. Possibly most of the IS_WINxxx usages could also be replaced. @dholmes-ora @MBaesken Thank you! Filed [JDK-8286634](https://bugs.openjdk.java.net/browse/JDK-8286634). ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From sgehwolf at openjdk.java.net Thu May 12 11:36:46 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 12 May 2022 11:36:46 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems In-Reply-To: References: Message-ID: On Thu, 12 May 2022 06:13:47 GMT, Ioi Lam wrote: > I just started to look at the code so just one comment for now. Sure, thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From mcimadamore at openjdk.java.net Thu May 12 12:12:55 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 12 May 2022 12:12:55 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com> Message-ID: On Thu, 12 May 2022 09:24:23 GMT, Jorn Vernee wrote: > Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will end up in one of the fallback handlers and the VM will be terminated. My understanding is that if they materialize while we're executing the upcall Java code, if that code has a try/catch block, we will go there, rather than crash the VM. In other words, IMHO the only problem with async exception is if they occur _after_ the Java user code has completed, because that will crash the Java adapter, this preventing it from returning to native call cleanly. So, either we disable async exceptions during that phase (e.g. after user code has executed, but before we return back to native code), or we just punt and stop. Since this seems like a corner^3 case, and since there are also other issue with upcalls that can occur if other threads do not cooperate (e.g. an upcall can get stuck into an infinite safepoint if the VM exits while an async native thread runs the upcall), and given that obtaining a linker is a restricted operation anyway, I don't think we should bend over backwards to try to add 1% more safety to something that's unavoidably sharp anyways. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From dholmes at openjdk.java.net Thu May 12 13:12:04 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 May 2022 13:12:04 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v10] In-Reply-To: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com> References: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com> Message-ID: On Thu, 12 May 2022 08:23:11 GMT, Nick Gasson wrote: >> src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp line 3: >> >>> 1: /* >>> 2: * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. >>> 3: * Copyright (c) 2019, 2021, Arm Limited. All rights reserved. >> >> Only update third-party copyrights under direction from that copyright holder. This may not be the correct format for example. >> Also it is 2022. :) > > I think the Arm Ltd one was probably changed by me in one of the PRs in the Panama repo. That's fine, just needed to check. But as these are now being committed to mainline the year does need to change to 2022 - at least in Oracle copyright. @nick-arm will have to advise what he thinks should be done with the ARM copyright. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From ngasson at openjdk.java.net Thu May 12 13:59:11 2022 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 12 May 2022 13:59:11 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v10] In-Reply-To: References: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com> Message-ID: On Thu, 12 May 2022 13:07:24 GMT, David Holmes wrote: >> I think the Arm Ltd one was probably changed by me in one of the PRs in the Panama repo. > > That's fine, just needed to check. But as these are now being committed to mainline the year does need to change to 2022 - at least in Oracle copyright. @nick-arm will have to advise what he thinks should be done with the ARM copyright. I think the Arm line can be updated to 2022 at the same time. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From stuefe at openjdk.java.net Thu May 12 14:05:57 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 12 May 2022 14:05:57 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems In-Reply-To: References: Message-ID: On Tue, 10 May 2022 12:29:10 GMT, Severin Gehwolf wrote: > Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter). > > In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running. > > Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round). > > Testing: > - [x] Added unit tests > - [x] GHA > - [x] Container tests on cgroups v1 Linux. Continue to pass src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 113: > 111: } > 112: buf[MAXPATHLEN-1] = '\0'; > 113: _path = os::strdup(buf); I think this code can be simplified a lot with stringStream and without strtok, so no need for fixed buffers (which may fail with longer path names) and no need for writable string copies on the stack. Something like this: stringStream ss; ss.print_raw(_mount_point); const char* p1 = _root; const char* p2 = cgroup_path; int last_matching_dash_pos = -1; for (int i = 0; *p1 == *p2 && *p1 != 0; i ++) { if (*p1 == '/') { last_matching_dash_pos = i; } p1++; p2++; } ss.print_raw(_root, last_matching_dash_pos); // Now use ss.base() to access the assembled string ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From jvernee at openjdk.java.net Thu May 12 14:53:03 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 14:53:03 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v12] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Update Oracle copyright years ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/1c04a42e..9a7bb6bb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=10-11 Stats: 70 lines in 70 files changed: 0 ins; 0 del; 70 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 15:03:05 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 15:03:05 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v10] In-Reply-To: References: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com> Message-ID: On Thu, 12 May 2022 13:55:20 GMT, Nick Gasson wrote: >> That's fine, just needed to check. But as these are now being committed to mainline the year does need to change to 2022 - at least in Oracle copyright. @nick-arm will have to advise what he thinks should be done with the ARM copyright. > > I think the Arm line can be updated to 2022 at the same time. I've updated all the Oracle copyright years in the files touched by this PR. @nick-arm If you wouldn't mind, could you use the "Add a suggestion" feature (the +/- button when leaving a review comment) to suggest copyright year updates to the relevant files (I think it's just foreign_globals_aarch64.cpp and universalUpcallHandler_aarch64.cpp). That way, when I accept those suggestions, an automatic commit will be made with you as the commit co-author, and it's even clearer that I'm making that change on your behalf. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 15:07:57 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 15:07:57 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v13] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Missed 2 years ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/9a7bb6bb..8100e0a7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=11-12 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From ngasson at openjdk.java.net Thu May 12 15:08:01 2022 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 12 May 2022 15:08:01 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v12] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 14:53:03 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Update Oracle copyright years src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp line 3: > 1: /* > 2: * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (c) 2019, 2021, Arm Limited. All rights reserved. Suggestion: * Copyright (c) 2019, 2022, Arm Limited. All rights reserved. src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 3: > 1: /* > 2: * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (c) 2019, 2021, Arm Limited. All rights reserved. Suggestion: * Copyright (c) 2019, 2022, Arm Limited. All rights reserved. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 15:16:08 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 15:16:08 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v14] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Apply copyright year updates per request of @nick-arm Co-authored-by: Nick Gasson ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/8100e0a7..0f49ff0b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=12-13 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 15:16:10 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 15:16:10 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v10] In-Reply-To: References: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com> Message-ID: On Thu, 12 May 2022 13:55:20 GMT, Nick Gasson wrote: >> That's fine, just needed to check. But as these are now being committed to mainline the year does need to change to 2022 - at least in Oracle copyright. @nick-arm will have to advise what he thinks should be done with the ARM copyright. > > I think the Arm line can be updated to 2022 at the same time. @nick-arm Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 15:58:04 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 15:58:04 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v15] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2 - Fix overwritten copyright years. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/0f49ff0b..aab2d15c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=13-14 Stats: 36 lines in 33 files changed: 4 ins; 0 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 16:01:17 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 16:01:17 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v16] In-Reply-To: References: Message-ID: <1WJgr8j7aHe_iD2t5KwVDk3c-raW7Q0NEbaSNfeo3zA=.5b14ab8c-b2a3-4fba-8209-643228a8b85d@github.com> > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Undo spurious changes. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/aab2d15c..f961121a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=14-15 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From sgehwolf at openjdk.java.net Thu May 12 16:03:01 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 12 May 2022 16:03:01 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems In-Reply-To: References: Message-ID: On Thu, 12 May 2022 14:00:44 GMT, Thomas Stuefe wrote: >> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter). >> >> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running. >> >> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round). >> >> Testing: >> - [x] Added unit tests >> - [x] GHA >> - [x] Container tests on cgroups v1 Linux. Continue to pass > > src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 113: > >> 111: } >> 112: buf[MAXPATHLEN-1] = '\0'; >> 113: _path = os::strdup(buf); > > I think this code can be simplified a lot with stringStream and without strtok, so no need for fixed buffers (which may fail with longer path names) and no need for writable string copies on the stack. > > Something like this: > > stringStream ss; > ss.print_raw(_mount_point); > const char* p1 = _root; > const char* p2 = cgroup_path; > int last_matching_dash_pos = -1; > for (int i = 0; *p1 == *p2 && *p1 != 0; i ++) { > if (*p1 == '/') { > last_matching_dash_pos = i; > } > p1++; p2++; > } > ss.print_raw(_root, last_matching_dash_pos); > // Now use ss.base() to access the assembled string Nice, thanks! I'll update it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From duke at openjdk.java.net Thu May 12 16:26:41 2022 From: duke at openjdk.java.net (openjdk-notifier[bot]) Date: Thu, 12 May 2022 16:26:41 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v16] In-Reply-To: <1WJgr8j7aHe_iD2t5KwVDk3c-raW7Q0NEbaSNfeo3zA=.5b14ab8c-b2a3-4fba-8209-643228a8b85d@github.com> References: <1WJgr8j7aHe_iD2t5KwVDk3c-raW7Q0NEbaSNfeo3zA=.5b14ab8c-b2a3-4fba-8209-643228a8b85d@github.com> Message-ID: On Thu, 12 May 2022 16:01:17 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Undo spurious changes. The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout JEP-19-VM-IMPL2 git fetch https://git.openjdk.java.net/jdk master git merge FETCH_HEAD # if there are conflicts, follow the instructions given by git merge git commit -m "Merge master" git push ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 16:58:36 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 16:58:36 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v17] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 98 commits: - Merge branch 'master' into JEP-19-VM-IMPL2 - Undo spurious changes. - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2 - Apply copyright year updates per request of @nick-arm Co-authored-by: Nick Gasson - Fix overwritten copyright years. - Missed 2 years - Update Oracle copyright years - Revert "Block async exceptions during upcalls" This reverts commit b29ad8f46732666f2d07e63ce8701b1eb7bed790. - Block async exceptions during upcalls - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 - ... and 88 more: https://git.openjdk.java.net/jdk/compare/2c5d1362...f55b6c59 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7959/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=16 Stats: 6913 lines in 155 files changed: 2576 ins; 3219 del; 1118 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 17:30:00 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 17:30:00 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com> Message-ID: <9NhIJsBLpV42NNz7rjhBu_cEvljMy1KIAA7IdTz1aGM=.1ac390e6-4834-4616-b85d-fda842c8e4fa@github.com> On Thu, 12 May 2022 12:10:53 GMT, Maurizio Cimadamore wrote: >> Okay, I see. I think I acted a little too hastily on this yesterday. I'll revert the change that uses this blocking mechanism. >> >> The stack more or less looks like this during an upcall: >> >> >> | --- >> | | >> | --- >> | <1: user define try block with exception handler (maybe)> | >> | --- >> | <2: user code start> | >> | --- >> | <3: method handle impl frames 1> | >> | --- >> | <4: upcall wrapper class with fallback handler 1> | >> | --- >> | <5: method handle impl frames 2> | >> | --- >> | <6: upcallk stub with fallback handler 2> | >> | <7: unknown native code> >> | --- >> | | >> >> >> I think there are several options to address async exceptions: >> 1. Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will end up in one of the fallback handlers and the VM will be terminated. >> 2. Block async exceptions in all code up from 6. >> 3. Somehow only block async exceptions only between 6. and 1. >> I think that is possible by changing the API so that the user passes us a method handle to their fallback exception handler, and we invoke it in our code in 4. We would need 2 methods for blocking and unblocking async exceptions from Java. Then we could disable async exceptions at the start of 6. enabled them at the start of the try block in 4. (around the call to user code), and disable them at the end of this try block. Then finally re-enable them at the end of 6. If an exception occurs in the try block in 4., delegate to the user-defined exception handler (but use the VM terminate strategy as a fallback for when another exception occurs). The other problem I see with that is that to make that fast enough (i.e. not incur a ~1.5-2x cost on call overhead), we would need compiler intrinsics for the blocking/unblocking, and in the past we've been unable to define 'critical' sections of code like that in C2 (it's an unsolved problem at this point). > >> Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will end up in one of the fallback handlers and the VM will be terminated. > > My understanding is that if they materialize while we're executing the upcall Java code, if that code has a try/catch block, we will go there, rather than crash the VM. > > In other words, IMHO the only problem with async exception is if they occur _after_ the Java user code has completed, because that will crash the Java adapter, this preventing it from returning to native call cleanly. > > So, either we disable async exceptions during that phase (e.g. after user code has executed, but before we return back to native code), or we just punt and stop. Since this seems like a corner^3 case, and since there are also other issue with upcalls that can occur if other threads do not cooperate (e.g. an upcall can get stuck into an infinite safepoint if the VM exits while an async native thread runs the upcall), and given that obtaining a linker is a restricted operation anyway, I don't think we should bend over backwards to try to add 1% more safety to something that's unavoidably sharp anyways. Ok. Then, if no one objects, I will leave this area as-is for now. (and perhaps come back to this issue in the future, if it becomes more pressing). ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From sgehwolf at openjdk.java.net Thu May 12 18:09:40 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 12 May 2022 18:09:40 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2] In-Reply-To: References: Message-ID: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com> > Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter). > > In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running. > > Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round). > > Testing: > - [x] Added unit tests > - [x] GHA > - [x] Container tests on cgroups v1 Linux. Continue to pass Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Use stringStream to simplify controller path assembly ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8629/files - new: https://git.openjdk.java.net/jdk/pull/8629/files/bc873b3f..66241aa5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8629&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8629&range=00-01 Stats: 32 lines in 1 file changed: 0 ins; 21 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8629.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8629/head:pull/8629 PR: https://git.openjdk.java.net/jdk/pull/8629 From sgehwolf at openjdk.java.net Thu May 12 18:09:41 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 12 May 2022 18:09:41 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 15:58:57 GMT, Severin Gehwolf wrote: >> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 113: >> >>> 111: } >>> 112: buf[MAXPATHLEN-1] = '\0'; >>> 113: _path = os::strdup(buf); >> >> I think this code can be simplified a lot with stringStream and without strtok, so no need for fixed buffers (which may fail with longer path names) and no need for writable string copies on the stack. >> >> Something like this: >> >> stringStream ss; >> ss.print_raw(_mount_point); >> const char* p1 = _root; >> const char* p2 = cgroup_path; >> int last_matching_dash_pos = -1; >> for (int i = 0; *p1 == *p2 && *p1 != 0; i ++) { >> if (*p1 == '/') { >> last_matching_dash_pos = i; >> } >> p1++; p2++; >> } >> ss.print_raw(_root, last_matching_dash_pos); >> // Now use ss.base() to access the assembled string > > Nice, thanks! I'll update it. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From hseigel at openjdk.java.net Thu May 12 19:04:57 2022 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 12 May 2022 19:04:57 GMT Subject: RFR: 8286424: GetVersionEx is deprecated [v2] In-Reply-To: <7W82D45KUc00_-RloszKs6xLsOlghWRebqYcOdpwNp8=.5fe56297-493c-4173-9a21-91317c273d58@github.com> References: <7W82D45KUc00_-RloszKs6xLsOlghWRebqYcOdpwNp8=.5fe56297-493c-4173-9a21-91317c273d58@github.com> Message-ID: On Tue, 10 May 2022 21:29:31 GMT, Kim Barrett wrote: >> Please review this change to explicitly disable deprecation warnings for the >> two uses of GetVersionEx in HotSpot code. This is a step toward being able to >> remove the global (to HotSpot) disable of deprecation warnings for Windows. >> (It is because of that global disable that these uses don't currently generate >> warnings.) >> >> There are uses of this function in non-HotSpot parts of the JDK. These are not >> being changed. They all disable the warning in some fashion, as appropriate to >> that area's usage. This change is only about HotSpot usage, and wanting to >> remove global deprecation disabling from HotSpot builds. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > use IsWindowsServer LGTM! Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8611 From kbarrett at openjdk.java.net Thu May 12 22:33:45 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 12 May 2022 22:33:45 GMT Subject: RFR: 8286424: GetVersionEx is deprecated [v2] In-Reply-To: References: <7W82D45KUc00_-RloszKs6xLsOlghWRebqYcOdpwNp8=.5fe56297-493c-4173-9a21-91317c273d58@github.com> Message-ID: <2BlPdbSjxAFrr4bzBvhYMEBKgN0ZHZnw0Hxm4usWlrQ=.94f9a382-e7d3-408b-8a44-169825f71c1e@github.com> On Wed, 11 May 2022 01:29:02 GMT, David Holmes wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> use IsWindowsServer > > Looks good. > > That "deprecation" is why we don't actually use `GetVersionEx` to get the version - see JDK-8059803. I guess the existence of `IsWindowsServer` was overlooked at the time. > > Thanks. Thanks @dholmes-ora and @hseigel for reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/8611 From kbarrett at openjdk.java.net Thu May 12 22:33:46 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 12 May 2022 22:33:46 GMT Subject: Integrated: 8286424: GetVersionEx is deprecated In-Reply-To: References: Message-ID: On Mon, 9 May 2022 20:56:25 GMT, Kim Barrett wrote: > Please review this change to explicitly disable deprecation warnings for the > two uses of GetVersionEx in HotSpot code. This is a step toward being able to > remove the global (to HotSpot) disable of deprecation warnings for Windows. > (It is because of that global disable that these uses don't currently generate > warnings.) > > There are uses of this function in non-HotSpot parts of the JDK. These are not > being changed. They all disable the warning in some fashion, as appropriate to > that area's usage. This change is only about HotSpot usage, and wanting to > remove global deprecation disabling from HotSpot builds. This pull request has now been integrated. Changeset: 4b8a66a5 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/4b8a66a5ff511c0476096a52e999d5b168bb0cd3 Stats: 27 lines in 1 file changed: 1 ins; 24 del; 2 mod 8286424: GetVersionEx is deprecated Reviewed-by: dholmes, hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/8611 From david.holmes at oracle.com Fri May 13 03:19:38 2022 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 May 2022 13:19:38 +1000 Subject: MethodType runtime API vs constant pool entry of the same type In-Reply-To: <7D1A1AAA-CED0-4533-B024-C716E72412BB@oracle.com> References: <7D1A1AAA-CED0-4533-B024-C716E72412BB@oracle.com> Message-ID: <0878cd6b-1c1a-74c8-93cc-a94fe1a9b2da@oracle.com> On 12/05/2022 2:45 am, Paul Sandoz wrote: > Hi David, > > Yeah, it's confusing, and in this case I think underspecified. I suspect the resolution in this case refers to operating on the loader via ClassLoader::loadClass [1] (whereby object parameter descriptors are first converted to binary class names) > > We could update the API spec to be clearer and link to MethodTypeDesc. Yes please - at the moment I'd say this is a bug: resolution has a very specific meaning. > Paul. > > [1] ClassLoader::loadClass also confusingly states: > > "It is invoked by the Java virtual machine to resolve class references." Probably should say "when resolving class references". If the virtual machine is resolving a reference to a class B, in a class A, then it has to invoke loadClass to load B. Cheers, David >> On May 10, 2022, at 6:07 PM, David Holmes wrote: >> >> Hi Paul, >> >> On 11/05/2022 8:51 am, Paul Sandoz wrote: >>> MethodType.fromMethodDescriptorString does not have the bytecode behavior of loading a method type from the constant pool, where access control checks are applied. >> >> The API spec states: >> >> "Any class or interface name embedded in the descriptor string will be resolved by the given loader ..." >> >> And resolution includes an access control check. >> >> David >> ----- >> >>> The use of the string descriptor is a convenience and not meant to imply bytecode behavior. The method, as stated, defers resolution of classes to the given class loader. In your Java code example it's equivalent to doing: >>> MethodType m = MethodType.methodType(Class.forName("foo.Foo$Bar", false, Test.class.getClassLoader())); >>> The following paragraph after that which you quote states: >>> * When the JVM materializes a {@code MethodType} from a descriptor string, >>> * all classes named in the descriptor must be accessible, and will be loaded. >>> * (But the classes need not be initialized, as is the case with a {@code CONSTANT_Class}.) >>> * This loading may occur at any time before the {@code MethodType} object is first derived. >>> In jasm try doing a ldc of class Bar and you should also get an illegal access error [1]. >>> The equivalent bytecode behavior (except for the exception, error vs runtime exception) can be achieved using the nominal descriptor: >>> MethodTypeDesc d = MethodTypeDesc.ofDescriptor("()Lfoo/Foo$Bar;"); >>> MethodType m = (MethodType) d.resolveConstantDesc(MethodHandles.lookup()); // throws IllegalAccessException >>> Which in turn is equivalent to: >>> MethodHandles.Lookup l = MethodHandles.lookup(); >>> MethodType m = MethodType.fromMethodDescriptorString( >>> "()Lfoo/Foo$Bar;", >>> l.lookupClass().getClassLoader() >>> ); >>> l.accessClass(m.returnType()); // >> Hth, >>> Paul. >>> [1] https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-5.html#jvms-5.4.3.1 >>>> On May 9, 2022, at 8:08 PM, Maxim Degtyarev wrote: >>>> >>>> Inspired by https://mail.openjdk.java.net/pipermail/compiler-dev/2022-May/019558.html >>>> >>>> According to the JDK 17 `j.l.i.MethodType` javadoc [1]: >>>> >>>> Like classes and strings, method types can also be represented >>>> directly in a class file's constant pool as constants. >>>> A method type may be loaded by an ldc instruction which refers to a >>>> suitable CONSTANT_MethodType constant pool entry. >>>> The entry refers to a CONSTANT_Utf8 spelling for the descriptor >>>> string. (For full details on method type constants, >>>> see sections 4.4.8 and 5.4.3.5 of the Java Virtual Machine Specification.) >>>> >>>> >>>> If I understand it correctly, this implies that any `MethodType` >>>> instance that can be successfully created with the >>>> call to `MethodType.fromMethodDescriptorString()` method can be also >>>> represented as a constant pool entry of type MethodType. >>>> >>>> >>>> Now consider the following example: >>>> >>>> >>>> // main/TestRuntime.java >>>> package main; >>>> >>>> import java.lang.invoke.MethodType; >>>> >>>> public class TestRuntime { >>>> >>>> public static void main(String... args) { >>>> System.out.println( >>>> MethodType.fromMethodDescriptorString( >>>> "()Lfoo/Foo$Bar;", >>>> TestRuntime.class.getClassLoader() >>>> ) >>>> ); >>>> } >>>> >>>> } >>>> >>>> >>>> // main/TestConstantPool.jasm >>>> /** >>>> * >>>> * You need asmtools >>>> to assemble this example. >>>> * >>>> * To assemble run: >>>> * >>>> * java -jar asmtools.jar jasm -g TestConstantPool.jasm >>>> * >>>> * >>>> */ >>>> package main; >>>> >>>> super public class TestConstantPool >>>> version 52:0 >>>> { >>>> public Method "":"()V" >>>> stack 1 locals 1 >>>> { >>>> aload_0; >>>> invokespecial Method java/lang/Object."":"()V"; >>>> return; >>>> } >>>> >>>> public static varargs Method main:"([Ljava/lang/String;)V" >>>> stack 2 locals 1 >>>> { >>>> getstatic Field java/lang/System.out:"Ljava/io/PrintStream;"; >>>> ldc MethodType "()Lfoo/Foo$Bar;"; >>>> invokevirtual Method >>>> java/io/PrintStream.println:"(Ljava/lang/Object;)V"; >>>> return; >>>> >>>> } >>>> } // end Class TestConstantPool >>>> >>>> >>>> // foo/Foo.java >>>> package foo; >>>> >>>> public class Foo { >>>> public static Bar bar() { >>>> return new Bar(); >>>> } >>>> >>>> static class Bar {} >>>> } >>>> >>>> >>>> Both `main.TestRuntime` and `main.TestConstantPool` are functionally >>>> equal and should print >>>> string representation of the `MethodType` instance. >>>> >>>> >>>> While `main.TestRuntime` behaves as expected: >>>> >>>> $ java main.TestRuntime >>>> ()Bar >>>> >>>> >>>> The `main.TestConstantPool` failed with `j.l.IllegalAccessError`: >>>> >>>> $ java main.TestConstantPool >>>> Exception in thread "main" java.lang.IllegalAccessError: tried to >>>> access class foo.Foo$Bar from class main.TestConstantPool >>>> at main.TestConstantPool.main(TestConstantPool.jasm:18) >>>> >>>> >>>> However, if we declare class `foo.Foo.Bar` public then both >>>> `TestRuntime` and `TestConstantPool` run without exceptions. >>>> >>>> >>>> Checked both with `Java(TM) SE Runtime Environment (build >>>> 1.8.0_152-b16)` and `OpenJDK Runtime Environment (build >>>> 19-ea+21-1482)`. >>>> >>>> >>>> Questions: >>>> >>>> 1) Shouldn't both examples expose equal behaviour? >>>> >>>> 2) Which of 2 observed behaviours is correct? >>>> >>>> >>>> Examples from this message can be found at [2] >>>> >>>> >>>> [1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/MethodType.html >>>> [2] https://github.com/Maccimo/MethodType-API-vs-ConstantPool > From ioi.lam at oracle.com Fri May 13 04:35:54 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 12 May 2022 21:35:54 -0700 Subject: SIGBUS on linux in perfMemory_init In-Reply-To: References: <094eb6f1-c0a1-e654-3a31-0a141e5560af@oracle.com> <1146e8f96849c70de32e8780fbe92afbcef4b42f.camel@redhat.com> Message-ID: Hi All, I've created a preliminary patch based on the suggestions from Vitaly and Nico. I would love to hear feedback before I start a formal PR. https://github.com/openjdk/jdk/compare/master...iklam:8286030-containers-share-tmp-dir Goals ===== + Allow JVM processes in different containers to share the /tmp directory ? (See https://bugs.openjdk.java.net/browse/JDK-8286030 for use cases) + Serviceability tools such as jps and jcmd should be able to access all such processes. Non-goals ========= + The /tmp directory can be shared only by updated JVMs with this patch. We do not support such sharing with older JVMs. + When using a shared /tmp directory, you must use the updated jbs/jcmd/etc tools. Tools from older JDKs don't work. Compatibility ============= + When the /tmp directory is NOT shared across containers, the behavior of the updated JVM is exactly the same as before. The updated JVM can co-exist with older JVMs, and can be accessed by jbs/jcmd/etc tools from older JDKs. + The updated jbs/jcmd/etc tools in the updated JDK can work with JVMs from older JDKs. Design ====== AttachID -- this is the number used for /tmp/hsperfdata_$USER/ and /tmp/.java_pid When a JVM starts, it chooses its AttachID by: ?? for (id = os::current_process_id(); ; id = random_id()) { ???? if ((flock /tmp/hsperfdata_$USER/$id) == SUCCESS) { ?????? break; ???? } ?? } Note that random_id() always returns a negative integer, so we will not step on the pid of another valid process. See the LINUX version of mmap_create_shared(). Cleaning up unused perfdata files ================================= See unlink_sharedmem_file_if_stale() in the patch. We use both flock() and kill(pid, 0) to check to liveness. This is a little complicated because we need to co-exist with older JVMs. Note that if the pid is positive, it could be from an older JVM, which doesn't do flock(). Therefore, for such pids we also use kill(pid, 0). This is racy, but it's no worse than before. Discovering JVMs ================ See LocalVmManager.activeVms() -> PlatformSupport.activeVms(). See PlatformSupport.getAttachID(). The Linux version no longer scans /tmp directories. Instead, it scans for hsperfdata files in the /proc/*/maps files. This way, it can detect the AttachID of each JVM process. The AttachID may be randomized so it will be different than the JVM's host pid and nspid. Testing ======= I've done some quick manual testing and it seems to work when several containers are sharing the same /tmp directory. My command-line is this: (/tmp insider the container is mapped to /tmp/dockertmp on the host file system) docker run -it --tty=true --rm \ ? ? -v /tmp/dockertmp:/tmp my-java-container \ ??? java -cp / -Xlog:perf+memops=debug -Xlog:attach=trace Wait I'll try to write a jtreg test case. Since we can't run as root, I'll try to use podman and run the tests in rootless mode. About -XX:+PerfDisableSharedMem =============================== With my patch, if you share /tmp across containers and run Java with -XX:+PerfDisableSharedMem + jps will not list these processes + "jcmd $HOSTPID" works for the first process that you connect to, but might fail with another process. This is because two processes may use the same socket file, e.g., /tmp/.java_pid1 Both of the above are the same as before, so there's no regression. To avoid making this patch more complicated, I plan to fix this in a future bug by mapping an empty /tmp/hsperfdata_$USER/$id file. Please let me know what you think. Thanks - Ioi On 5/7/2022 9:55 PM, Ioi Lam wrote: > > > On 5/6/2022 1:40 AM, Severin Gehwolf wrote: >> On Thu, 2022-05-05 at 13:48 -0700, Ioi Lam wrote: >>> >>> On 5/3/2022 8:41 AM, Nico Williams wrote: >>>> On Fri, Apr 29, 2022 at 09:44:00AM -0400, Vitaly Davidovich wrote: >>>>> As for possible solutions, would it be possible to use the global PID >>>>> instead of the namespaced PID to "regain" the uniqueness invariant >>>>> of the >>>>> PID? Also, might it make sense to flock() the file to prevent another >>>>> process from mucking with it? >>>> My unsolicited, outsider opinions: >>>> >>>> ?? - Sharing /tmp across containers is a Bad Idea (tm). >>>> >>>> ?? - Sharing /tmp across related containers (in a pod) is not _as_ >>>> bad an >>>> ???? idea. >>>> >>>> ???? (It might be a way to implement some cross-container >>>> communications, >>>> ???? though it would be better to have an explicit mechanism for that >>>> ???? rather than the rather-generic /tmp.) >>>> >>>> ?? - Containerizing apps that *do* communicate over /tmp might be one >>>> ???? reason one might configure a shared /tmp in a pod. >>>> >>>> ???? Some support for such a configuration might be needed. >>>> >>>> ???? (Alternatively, pods that share /tmp should also share a PID >>>> ???? namespace.) >>>> >>>> ?? - Since there is an option to not have an mmap'ed hsperf file, >>>> it might >>>> ???? be nice to have an option to use the global PID for naming hsperf >>>> ???? files.? Or, better, implement an automatic mechanism for >>>> detecting >>>> ???? conflict and switching to global PID for naming hsperf files (or >>>> ???? switching to anonymous hsperf mmaps). >>>> >>>> ?? - In any case, on systems that have a real flock(2), using >>>> flock(2) for >>>> ???? liveness testing is better than kill(2) with signal 0 -- the >>>> latter >>>> ???? has false positives, while the former does not [provided >>>> O_CLOEXEC is >>>> ???? used]. >>>> >>>> ???? For this reason, and though I am not too sympathetic to the >>>> situation >>>> ???? that caused this crash, I believe that it would be better to have >>>> ???? some sort of fix for this problem than to declare it a >>>> non-problem >>>> ???? and not-fix it. >>>> >>>> >>>> I would like to expand on Vitaly's mention of flock(2). Using the >>>> global PID would leave the JVM unable to use kill(2) with signal 0 for >>>> liveness detection during hsperf garbage file collection. Using >>>> kill(2) >>>> with signal 0 for liveness is not that reliable anyways because of PID >>>> reuse -- it can have false positives. >>>> >>>> A better mechanism for liveness detection would be to have the owning >>>> JVM take an exclusive (LOCK_EX) flock(2) on the hsperf file at >>>> startup, >>>> and for hsperf garbage file collection to try (LOCK_NB) to get an >>>> exclusive lock (LOCK_EX) on a candidate hsperf garbage file as a >>>> liveness detection mechanism. >>>> >>>> When using the namespaced PID the kill(2) with signal 0 method of >>>> liveness detection should still be used for backwards-compatibility >>>> in, >>>> e.g., jvisualvm. >>>> >>>> Using flock(2) would be less portable than kill(2) with signal 0, but >>>> already there is a bunch of Linux-specific code here looking through >>>> /proc, and Linux does have a real flock(2). >>>> >>>> An adaptive, zero-conf hsperf file naming scheme might use the >>>> namespaced PID if available (i.e., if an exclusive flock(2) could be >>>> obtained on the file), or the global PID if not, with some >>>> indication in >>>> the name of the file's name of which kind of PID was used. >>> Hi Nico, >>> >>> I read your message again and now I totally agree with using >>> flock(2) :-) >>> >>> As you said, we should start with getpid(). That way the behavior is >>> compatible with older versions of jcmd tools, especially when Java is >>> used outside of containers. >>> >>> One thing I realized is that if we have a collision, we don't need to >>> use a globally unique ID. We just need an ID that's unique in the >>> directory being written into. >>> >>> I think we can do this on the VM side: >>> >>> ????? String id = getpid(); >>> ????? while (true) { >>> ????????? String file = "/tmp/hsperfdata_" + username() + "/" + id; >>> ????????? if (get_exclusive_access(file)) { >>> ????????????? // I won the contest and >>> ????????????? // (a) the file didn't exist, or >>> ????????????? // (b) the file existed but the JVM that used it has died >>> ????????????? return file; >>> ????????? } >>> ????????? // Add an "x" here so we don't collide with the getpid() of >>> another process >>> ????????? id = "x" + random(); >>> ????? } >>> >>> On the tools side, we can do the pid -> rendezvous file mapping as I >>> described in the other e-mail. >> If we could limit using this this special trick when it's actually >> neede then this would be my preference. For one, it mostly keeps >> compatibility with older JVMs and for two this isn't a very common use- >> case which would penalize the 90% of use cases which aren't affected by >> this. >> >> On the other hand, 'man proc' tells me this about /proc/*/environ: >> >> """ >> This file contains the initial environment that was set when the >> currently executing program was started via execve(2). [...] >> >> If,? after? an? execve(2),? the process modifies its environment (e.g., >> by calling functions such as putenv(3) or modifying the environ(7) >> variable directly), this file will not reflect those changes. >> >> [...] >> >> Permission to access this file is governed by a ptrace access mode >> PTRACE_MODE_READ_FSCREDS check; see ptrace(2). >> """ >> >> So doing the publication of the file that was used in a reliable way >> will be a challenge. Both approaches, shared memory mapping and setting >> the environment will need PTRACE_MODE_READ_FSCREDS which I think isn't >> generally granted for containers. > > I think publishing via /proc/*/environ is going to be problematic, but > using the maps file seems fine. Here are my experiments. > > My conclusion is: > > If a Java process is visible to "jps" today, "jps" can also read its > /proc/id/maps file. > > ============== test 1 ================ > Docker running with cgroup v1 on Ubuntu 20.04.3 LTS > > ubuntu at minikube-cgv1:~$ jps -J-version > openjdk version "11.0.15" 2022-04-19 > OpenJDK Runtime Environment (build 11.0.15+10-Ubuntu-0ubuntu0.20.04.1) > OpenJDK 64-Bit Server VM (build 11.0.15+10-Ubuntu-0ubuntu0.20.04.1, > mixed mode, sharing) > ubuntu at minikube-cgv1:~$ ps -ef | grep Wait > ubuntu????? 3490??? 3280? 2 21:34 pts/1??? 00:00:00 docker run -it > --tty=true --rm my-java-app java -cp / Wait > root??????? 3541??? 3515? 2 21:34 pts/0??? 00:00:00 java -cp / Wait > ubuntu????? 3598??? 1247? 0 21:34 pts/0??? 00:00:00 grep --color=auto > Wait > > ubuntu at minikube-cgv1:~$ jps > 3611 Jps > ubuntu at minikube-cgv1:~$ sudo jps > 3541 Wait > 3630 Jps > ubuntu at minikube-cgv1:~$ wc /proc/3541/maps > wc: /proc/3541/maps: Permission denied > ubuntu at minikube-cgv1:~$ ls /proc/3541/root > ls: cannot access '/proc/3541/root': Permission denied > ubuntu at minikube-cgv1:~$ sudo wc /proc/3541/maps > 181 968 12074 /proc/3541/maps > ubuntu at minikube-cgv1:~$ sudo grep hsperf /proc/3541/maps > 7f4ebca2b000-7f4ebca33000 rw-s 00000000 00:33 > 1818692??????????????????? /tmp/hsperfdata_root/1 > > ============== test 2 ================ > podman rootless + cgroupv2 on Ubuntu 21.10 > > ubuntu at podman-tester:~$ jps -J-version > openjdk version "17.0.1" 2021-10-19 > OpenJDK Runtime Environment (build 17.0.1+12-Ubuntu-121.10) > OpenJDK 64-Bit Server VM (build 17.0.1+12-Ubuntu-121.10, mixed mode, > sharing) > ubuntu at podman-tester:~$ ps -ef | grep Wait > ubuntu????? 1531??? 1468? 0 21:19 pts/0??? 00:00:01 podman run -it > --tty=true --rm my-java-app java -cp / Wait > ubuntu????? 1571??? 1556? 0 21:19 pts/0??? 00:00:01 java -cp / Wait > ubuntu????? 1946??? 1686? 0 21:23 pts/1??? 00:00:00 grep --color=auto > Wait > ubuntu at podman-tester:~$ jps > 1778 Jps > 1571 Wait > ubuntu at podman-tester:~$ cat /^C > ubuntu at podman-tester:~$ sudo jps > 1571 Wait > 1805 Jps > ubuntu at podman-tester:~$ grep hsperf/proc/1571/maps > 7f88dc40c000-7f88dc414000 rw-s 00000000 08:01 > 792115???????????????????? /tmp/hsperfdata_root/1 > ubuntu at podman-tester:~$ sudo grep hsperf/proc/1571/maps > 7f88dc40c000-7f88dc414000 rw-s 00000000 08:01 > 792115???????????????????? /tmp/hsperfdata_root/1 > ubuntu at podman-tester:~$ ls -l /proc/1571/root/tmp/hsperfdata_root/1 > -rw------- 1 ubuntu ubuntu 32768 May? 7 21:24 > /proc/1571/root/tmp/hsperfdata_root/1 > > > From rehn at openjdk.java.net Fri May 13 06:43:49 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 13 May 2022 06:43:49 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL [v2] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 11:15:40 GMT, Johan Sj?l?n wrote: >> This PR cleans up some minor annoyances in the UL code. >> >> Note that the change from `LogImpl` to `LogTagSet` is equivalent, we're essentially inlining the calls that `LogImpl` would have made. This simplifies understanding ("why do we need `LogImpl` here?" was my question, answer: We don't!)' >> >> *Edit:* Passes tier1. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Use _tagset Marked as reviewed by rehn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8541 From iklam at openjdk.java.net Fri May 13 06:48:04 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 13 May 2022 06:48:04 GMT Subject: RFR: 8286117: Remove unnecessary indirection and unused code in UL [v2] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 11:15:40 GMT, Johan Sj?l?n wrote: >> This PR cleans up some minor annoyances in the UL code. >> >> Note that the change from `LogImpl` to `LogTagSet` is equivalent, we're essentially inlining the calls that `LogImpl` would have made. This simplifies understanding ("why do we need `LogImpl` here?" was my question, answer: We don't!)' >> >> *Edit:* Passes tier1. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Use _tagset Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8541 From duke at openjdk.java.net Fri May 13 06:53:13 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 13 May 2022 06:53:13 GMT Subject: Integrated: 8286117: Remove unnecessary indirection and unused code in UL In-Reply-To: References: Message-ID: On Wed, 4 May 2022 18:29:22 GMT, Johan Sj?l?n wrote: > This PR cleans up some minor annoyances in the UL code. > > Note that the change from `LogImpl` to `LogTagSet` is equivalent, we're essentially inlining the calls that `LogImpl` would have made. This simplifies understanding ("why do we need `LogImpl` here?" was my question, answer: We don't!)' > > *Edit:* Passes tier1. This pull request has now been integrated. Changeset: d5ae3833 Author: Johan Sj?l?n Committer: Robbin Ehn URL: https://git.openjdk.java.net/jdk/commit/d5ae3833b1b71eb84fadb69c0c92851400f8921c Stats: 23 lines in 5 files changed: 2 ins; 3 del; 18 mod 8286117: Remove unnecessary indirection and unused code in UL Reviewed-by: dholmes, rehn, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/8541 From stuefe at openjdk.java.net Fri May 13 10:21:48 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 13 May 2022 10:21:48 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2] In-Reply-To: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com> References: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com> Message-ID: On Thu, 12 May 2022 18:09:40 GMT, Severin Gehwolf wrote: >> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter). >> >> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running. >> >> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round). >> >> Testing: >> - [x] Added unit tests >> - [x] GHA >> - [x] Container tests on cgroups v1 Linux. Continue to pass > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Use stringStream to simplify controller path assembly Thanks for taking my suggestion! Much simpler now :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From vlivanov at openjdk.java.net Fri May 13 19:17:46 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 13 May 2022 19:17:46 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <9NhIJsBLpV42NNz7rjhBu_cEvljMy1KIAA7IdTz1aGM=.1ac390e6-4834-4616-b85d-fda842c8e4fa@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com> <9NhIJsBLpV42NNz7rjhBu_cEvljMy1KIAA7IdTz1aGM=.1ac390e6-4834-4616-b85d-fda842c8e4fa@github.com> Message-ID: On Thu, 12 May 2022 17:26:44 GMT, Jorn Vernee wrote: >>> Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will end up in one of the fallback handlers and the VM will be terminated. >> >> My understanding is that if they materialize while we're executing the upcall Java code, if that code has a try/catch block, we will go there, rather than crash the VM. >> >> In other words, IMHO the only problem with async exception is if they occur _after_ the Java user code has completed, because that will crash the Java adapter, this preventing it from returning to native call cleanly. >> >> So, either we disable async exceptions during that phase (e.g. after user code has executed, but before we return back to native code), or we just punt and stop. Since this seems like a corner^3 case, and since there are also other issue with upcalls that can occur if other threads do not cooperate (e.g. an upcall can get stuck into an infinite safepoint if the VM exits while an async native thread runs the upcall), and given that obtaining a linker is a restricted operation anyway, I don't think we should bend over backwards to try to add 1% more safety to something that's unavoidably sharp anyways. > > Ok. Then, if no one objects, I will leave this area as-is for now. (and perhaps come back to this issue in the future, if it becomes more pressing). > > (I'll also note that this issue already exists in the current code that's in mainline. So, it seems fair to address this as a followup as well, if needed). I don't see a way to reliably handle async exceptions purely with `try/catch`. In the end, there's always a safepoint poll right before returning from a method where new exception can be installed. So, there's always a small chance present to observe a pending exception on VM side irrespective of how hard you try on Java side. >From reliability perspective, I find it important to gracefully handle such corner cases. But I'm fine with addressing the problem separately. As an alternative solution, exception handling for upcalls can be handled by another upcall (into catch handler when pending exception is encountered). As a bonus, it allows to handle repeated exceptions. In the worst case, it would manifest as a hang (when async exceptions are continuously delivered). Still, some special handling is needed for stack overflow errors. (Not sure how those are handled now. Are they?) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From vlivanov at openjdk.java.net Fri May 13 19:24:41 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 13 May 2022 19:24:41 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v17] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 16:58:36 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 98 commits: > > - Merge branch 'master' into JEP-19-VM-IMPL2 > - Undo spurious changes. > - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2 > - Apply copyright year updates per request of @nick-arm > > Co-authored-by: Nick Gasson > - Fix overwritten copyright years. > - Missed 2 years > - Update Oracle copyright years > - Revert "Block async exceptions during upcalls" > > This reverts commit b29ad8f46732666f2d07e63ce8701b1eb7bed790. > - Block async exceptions during upcalls > - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 > - ... and 88 more: https://git.openjdk.java.net/jdk/compare/2c5d1362...f55b6c59 Looks good. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5531: > 5529: } > 5530: > 5531: // On64 bit we will store integer like items to the stack as Missing space. src/hotspot/cpu/x86/macroAssembler_x86.cpp line 933: > 931: } else { > 932: assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)", > 933: src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name()); Still not indented properly. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Fri May 13 20:03:11 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 13 May 2022 20:03:11 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v17] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 19:16:36 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 98 commits: >> >> - Merge branch 'master' into JEP-19-VM-IMPL2 >> - Undo spurious changes. >> - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2 >> - Apply copyright year updates per request of @nick-arm >> >> Co-authored-by: Nick Gasson >> - Fix overwritten copyright years. >> - Missed 2 years >> - Update Oracle copyright years >> - Revert "Block async exceptions during upcalls" >> >> This reverts commit b29ad8f46732666f2d07e63ce8701b1eb7bed790. >> - Block async exceptions during upcalls >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - ... and 88 more: https://git.openjdk.java.net/jdk/compare/2c5d1362...f55b6c59 > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5531: > >> 5529: } >> 5530: >> 5531: // On64 bit we will store integer like items to the stack as > > Missing space. Oh, looks like i deleted the wrong space by accident. > src/hotspot/cpu/x86/macroAssembler_x86.cpp line 933: > >> 931: } else { >> 932: assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)", >> 933: src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name()); > > Still not indented properly. Shouldn't there be a 2-space indentation wrt the assert here? I could also indent all the arguments to be aligned with the format string, if that seems better. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Fri May 13 20:15:47 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 13 May 2022 20:15:47 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com> <9NhIJsBLpV42NNz7rjhBu_cEvljMy1KIAA7IdTz1aGM=.1ac390e6-4834-4616-b85d-fda842c8e4fa@github.com> Message-ID: On Fri, 13 May 2022 19:13:46 GMT, Vladimir Ivanov wrote: >> Ok. Then, if no one objects, I will leave this area as-is for now. (and perhaps come back to this issue in the future, if it becomes more pressing). >> >> (I'll also note that this issue already exists in the current code that's in mainline. So, it seems fair to address this as a followup as well, if needed). > > I don't see a way to reliably handle async exceptions purely with `try/catch`. In the end, there's always a safepoint poll right before returning from a method where new exception can be installed. So, there's always a small chance present to observe a pending exception on VM side irrespective of how hard you try on Java side. > > From reliability perspective, I find it important to gracefully handle such corner cases. But I'm fine with addressing the problem separately. > > As an alternative solution, exception handling for upcalls can be handled by another upcall (into catch handler when pending exception is encountered). As a bonus, it allows to handle repeated exceptions. In the worst case, it would manifest as a hang (when async exceptions are continuously delivered). Still, some special handling is needed for stack overflow errors. (Not sure how those are handled now. Are they?) SOE (of the Java exception kind) is not specially handled right now. I think the same rule applies there: we can't unwind or return to native frames (at least not without some guidance from the user). I've filed an issue here to capture some of the discussion: https://bugs.openjdk.java.net/browse/JDK-8286761 ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From vlivanov at openjdk.java.net Fri May 13 20:50:46 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 13 May 2022 20:50:46 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v17] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 19:59:40 GMT, Jorn Vernee wrote: >> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 933: >> >>> 931: } else { >>> 932: assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)", >>> 933: src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name()); >> >> Still not indented properly. > > Shouldn't there be a 2-space indentation wrt the assert here? I could also indent all the arguments to be aligned with the format string, if that seems better. It's preferred to indent multi-line argument lists on the column where argument list starts. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From vlivanov at openjdk.java.net Fri May 13 20:50:46 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 13 May 2022 20:50:46 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v17] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 20:46:19 GMT, Vladimir Ivanov wrote: >> Shouldn't there be a 2-space indentation wrt the assert here? I could also indent all the arguments to be aligned with the format string, if that seems better. > > It's preferred to indent multi-line argument lists on the column where argument list starts. assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)", src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name()); ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Fri May 13 21:01:10 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 13 May 2022 21:01:10 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v18] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: - indentation - fix space ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/f55b6c59..2ea5bc94 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=16-17 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Fri May 13 21:01:11 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 13 May 2022 21:01:11 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v18] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 20:47:22 GMT, Vladimir Ivanov wrote: >> It's preferred to indent multi-line argument lists on the column where argument list starts. > > assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)", > src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name()); Done ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From dnsimon at openjdk.java.net Sat May 14 11:02:09 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sat, 14 May 2022 11:02:09 GMT Subject: RFR: 8286771: workaround implemented for JDK-8282607 is incomplete Message-ID: Completes the workaround implemented in [JDK-8282607](https://bugs.openjdk.java.net/browse/JDK-8282607) so that the test actually passes when hs-err truncation is seen. ------------- Commit messages: - test must pass when hs-err truncation detected Changes: https://git.openjdk.java.net/jdk/pull/8713/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8713&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286771 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8713.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8713/head:pull/8713 PR: https://git.openjdk.java.net/jdk/pull/8713 From dholmes at openjdk.java.net Sat May 14 12:54:48 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 14 May 2022 12:54:48 GMT Subject: RFR: 8286771: workaround implemented for JDK-8282607 is incomplete In-Reply-To: References: Message-ID: <8PLI_xHdjW2fh5f2yyZnEGjk9ZBeAe8i_2gG1RuLia8=.71ac0c39-9fb1-4456-b8ce-35f9c38d0300@github.com> On Sat, 14 May 2022 10:54:07 GMT, Doug Simon wrote: > Completes the workaround implemented in [JDK-8282607](https://bugs.openjdk.java.net/browse/JDK-8282607) so that the test actually passes when hs-err truncation is seen. Looks good and trivial. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8713 From dnsimon at openjdk.java.net Sat May 14 15:33:49 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sat, 14 May 2022 15:33:49 GMT Subject: Integrated: 8286771: workaround implemented for JDK-8282607 is incomplete In-Reply-To: References: Message-ID: <22mAzjjwbWZwvNKgbQ2GEwESnrl7QBZBP6CNJq6gioo=.eb223623-be88-4758-a9ba-33d4b50d062a@github.com> On Sat, 14 May 2022 10:54:07 GMT, Doug Simon wrote: > Completes the workaround implemented in [JDK-8282607](https://bugs.openjdk.java.net/browse/JDK-8282607) so that the test actually passes when hs-err truncation is seen. This pull request has now been integrated. Changeset: af24d2d1 Author: Doug Simon URL: https://git.openjdk.java.net/jdk/commit/af24d2d1d6a6679b5e0f74ada0a5e3956b58e300 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8286771: workaround implemented for JDK-8282607 is incomplete Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/8713 From tanksherman27 at gmail.com Sun May 15 13:47:59 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Sun, 15 May 2022 21:47:59 +0800 Subject: HotSpot Interpreter Message-ID: Bit of an odd question, but out of curiosity, is HotSpot's Interpreter a Token Threaded one or an Indirect Threaded one? best regards, Julian From jvernee at openjdk.java.net Mon May 16 14:52:04 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 16 May 2022 14:52:04 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v19] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Fix failure with SPEC disabled (accidentally dropped change) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/2ea5bc94..ff8835ee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=17-18 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Mon May 16 16:06:24 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 16 May 2022 16:06:24 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v20] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Cleanup UL usage ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/ff8835ee..d611f365 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=18-19 Stats: 14 lines in 5 files changed: 2 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Mon May 16 16:06:25 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 16 May 2022 16:06:25 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v19] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 14:52:04 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Fix failure with SPEC disabled (accidentally dropped change) @robehn found a test failure in a non-default configuration that I've fixed [1] (it was addressed in the panama repo by a different patch). I've also cleaned up use of UL a bit [2]: the `panama` tag was renamed to `foreign` and I've added the `downcall` and `upcall` tags as well, for down/up call logging respectively. This is now all under NOT_PRODUCT. [1]: https://github.com/openjdk/jdk/pull/7959/commits/ff8835ee99203e94fb216c5bd7cf1ce610d5737f [2]: https://github.com/openjdk/jdk/pull/7959/commits/d611f365ade15cd7a7d005547814ce88fff0ca1a ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Mon May 16 16:15:49 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 16 May 2022 16:15:49 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v21] In-Reply-To: References: Message-ID: <-H-hj0CmArcV48YOFCPUC1yIZXJxZ41p9PGBP-E_Vc0=.dad63c91-0e01-4124-9b44-467134a26b75@github.com> > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Missing ASSERT -> NOT_PRODUCT ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/d611f365..406f3e83 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=20 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=19-20 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From iklam at openjdk.java.net Mon May 16 23:12:07 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 16 May 2022 23:12:07 GMT Subject: RFR: 8286277: CDS VerifyError when calling clone() on object array Message-ID: **Problem:** When verifying an invokevirtual bytecode that calls a protected method in a superclass of the current class, the verifier requires that the object being invoked must be a subtype of the current class. This prevents invocation of protected methods in an unrelated class. For example, the following is disallowed -- the type `InvokeCloneInvalid` cannot invoke `clone()` on a `String`: super public class InvokeCloneInvalid version 52:0 { public static Method test:"(Ljava/lang/String;)V" stack 1 locals 1 { aload_0; invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; return; } } However, there's a special case where invoking `Object.clone()` is allowed on all object arrays. Here's an example: super public class InvokeCloneValid version 52:0 { public static Method test:"([Ljava/lang/Object;)V" stack 1 locals 1 { aload_0; invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; return; } Before this PR. the Verifier would first do the assignability check. When a failure is encountered, the Verifier then checks for the special case and ignores the failure accordingly. In the above case, the assignability check will fail because the object being invoked (an Object array) is not assignable to the current class (InvokeCloneValid) The problem is that CDS remembers all the assignability checks and tries to replay them at runtime. Therefore, it will re-check the assignability of Object Array to InvokeCloneValid, and throw a VerifyError as a result. **Proposed Fix** In `ClassVerifier::verify_invoke_instructions()`, check the special case first, before doing the assignability check. This way, such invalid-but-ignored assignability checks are no longer performed and thus won't be remembered by CDS. **Testing** Tiers 1 - 4, plus 3 new test cases. ------------- Commit messages: - fixed trailing spaces - 8286277: CDS VerifyError when calling clone() on object array Changes: https://git.openjdk.java.net/jdk/pull/8737/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8737&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286277 Stats: 348 lines in 7 files changed: 339 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8737.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8737/head:pull/8737 PR: https://git.openjdk.java.net/jdk/pull/8737 From iklam at openjdk.java.net Tue May 17 05:58:45 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 17 May 2022 05:58:45 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2] In-Reply-To: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com> References: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com> Message-ID: On Thu, 12 May 2022 18:09:40 GMT, Severin Gehwolf wrote: >> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter). >> >> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running. >> >> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round). >> >> Testing: >> - [x] Added unit tests >> - [x] GHA >> - [x] Container tests on cgroups v1 Linux. Continue to pass > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Use stringStream to simplify controller path assembly test/hotspot/gtest/runtime/test_os_linux_cgroups.cpp line 63: > 61: ASSERT_STREQ(expected_cg_paths[i], ctrl->subsystem_path()); > 62: } > 63: } I found it hard to relate the different paths. Could you create a new struct like this? struct TestCase { char* mount_path; char* root_paths; char* cgroup_path; char* expected_cg_paths; } = { { "/sys/fs/cgroup/memory", // mount "/", // root, .... ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From iklam at openjdk.java.net Tue May 17 06:21:50 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 17 May 2022 06:21:50 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2] In-Reply-To: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com> References: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com> Message-ID: On Thu, 12 May 2022 18:09:40 GMT, Severin Gehwolf wrote: >> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter). >> >> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running. >> >> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round). >> >> Testing: >> - [x] Added unit tests >> - [x] GHA >> - [x] Container tests on cgroups v1 Linux. Continue to pass > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Use stringStream to simplify controller path assembly src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92: > 90: } > 91: ss.print_raw(_root, last_matching_slash_pos); > 92: _path = os::strdup(ss.base()); Do you mean `Find the longest common prefix`? Maybe give an example in the comments? Text parsing in C code is really difficult to understand. ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From dholmes at openjdk.java.net Tue May 17 06:42:49 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 17 May 2022 06:42:49 GMT Subject: RFR: 8286277: CDS VerifyError when calling clone() on object array In-Reply-To: References: Message-ID: On Mon, 16 May 2022 22:49:24 GMT, Ioi Lam wrote: > **Problem:** > > When verifying an invokevirtual bytecode that calls a protected method in a superclass of the current class, the verifier requires that the object being invoked must be a subtype of the current class. This prevents invocation of protected methods in an unrelated class. For example, the following is disallowed -- the type `InvokeCloneInvalid` cannot invoke `clone()` on a `String`: > > > super public class InvokeCloneInvalid > version 52:0 > { > public static Method test:"(Ljava/lang/String;)V" > stack 1 locals 1 > { > aload_0; > invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; > return; > } > } > > > However, there's a special case where invoking `Object.clone()` is allowed on all object arrays. Here's an example: > > > super public class InvokeCloneValid > version 52:0 > { > public static Method test:"([Ljava/lang/Object;)V" > stack 1 locals 1 > { > aload_0; > invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; > return; > } > > > Before this PR. the Verifier would first do the assignability check. When a failure is encountered, the Verifier then checks for the special case and ignores the failure accordingly. > > In the above case, the assignability check will fail because the object being invoked (an Object array) is not assignable to the current class (InvokeCloneValid) > > The problem is that CDS remembers all the assignability checks and tries to replay them at runtime. Therefore, it will re-check the assignability of Object Array to InvokeCloneValid, and throw a VerifyError as a result. > > **Proposed Fix** > > In `ClassVerifier::verify_invoke_instructions()`, check the special case first, before doing the assignability check. This way, such invalid-but-ignored assignability checks are no longer performed and thus won't be remembered by CDS. > > **Testing** > > Tiers 1 - 4, plus 3 new test cases. Is the component type of the array already loaded and verified at this point? My only concern would be that the `is_assignable` check might load and verify the class as a side-effect, and we have now skipped that. ?? test/hotspot/jtreg/runtime/verifier/InvokeCloneValid.jasm line 42: > 40: return; > 41: } > 42: } Missing newline at end of line. ------------- PR: https://git.openjdk.java.net/jdk/pull/8737 From stuefe at openjdk.java.net Tue May 17 07:17:49 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 17 May 2022 07:17:49 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2] In-Reply-To: References: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com> Message-ID: On Tue, 17 May 2022 06:18:25 GMT, Ioi Lam wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Use stringStream to simplify controller path assembly > > src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92: > >> 90: } >> 91: ss.print_raw(_root, last_matching_slash_pos); >> 92: _path = os::strdup(ss.base()); > > Do you mean `Find the longest common prefix`? Maybe give an example in the comments? Text parsing in C code is really difficult to understand. Maybe factor out the search like this // Return length of common starting substring. E.g. "cat" for ("cattle", "catnip"); static int find_common_starting_substring(const char* s1, const char* s2) { ... } That way its clearer and we can find and move this to utilities if we ever need this in other places. ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From sgehwolf at openjdk.java.net Tue May 17 08:15:40 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 17 May 2022 08:15:40 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2] In-Reply-To: References: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com> Message-ID: On Tue, 17 May 2022 07:14:34 GMT, Thomas Stuefe wrote: >> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92: >> >>> 90: } >>> 91: ss.print_raw(_root, last_matching_slash_pos); >>> 92: _path = os::strdup(ss.base()); >> >> Do you mean `Find the longest common prefix`? Maybe give an example in the comments? Text parsing in C code is really difficult to understand. > > Maybe factor out the search like this > > // Return length of common starting substring. E.g. "cat" for ("cattle", "catnip"); > static int find_common_starting_substring(const char* s1, const char* s2) { > ... > } > > That way its clearer and we can find and move this to utilities if we ever need this in other places. OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From sgehwolf at openjdk.java.net Tue May 17 08:15:41 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 17 May 2022 08:15:41 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2] In-Reply-To: References: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com> Message-ID: On Tue, 17 May 2022 05:55:47 GMT, Ioi Lam wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Use stringStream to simplify controller path assembly > > test/hotspot/gtest/runtime/test_os_linux_cgroups.cpp line 63: > >> 61: ASSERT_STREQ(expected_cg_paths[i], ctrl->subsystem_path()); >> 62: } >> 63: } > > I found it hard to relate the different paths. Could you create a new struct like this? > > > struct TestCase { > char* mount_path; > char* root_paths; > char* cgroup_path; > char* expected_cg_paths; > } = { > { "/sys/fs/cgroup/memory", // mount > "/", // root, > .... Yes, makes sense. Will do. ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From mcimadamore at openjdk.java.net Tue May 17 08:31:03 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 17 May 2022 08:31:03 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v21] In-Reply-To: <-H-hj0CmArcV48YOFCPUC1yIZXJxZ41p9PGBP-E_Vc0=.dad63c91-0e01-4124-9b44-467134a26b75@github.com> References: <-H-hj0CmArcV48YOFCPUC1yIZXJxZ41p9PGBP-E_Vc0=.dad63c91-0e01-4124-9b44-467134a26b75@github.com> Message-ID: On Mon, 16 May 2022 16:15:49 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Missing ASSERT -> NOT_PRODUCT src/java.base/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java line 66: > 64: private static final boolean USE_SPEC = Boolean.parseBoolean( > 65: GetPropertyAction.privilegedGetProperty("jdk.internal.foreign.ProgrammableInvoker.USE_SPEC", "true")); > 66: private static final boolean USE_INTRINSICS = Boolean.parseBoolean( Do we need to update TestMatrix given that we're removing one dimension in the invokers? ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Tue May 17 10:06:05 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 17 May 2022 10:06:05 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v21] In-Reply-To: References: <-H-hj0CmArcV48YOFCPUC1yIZXJxZ41p9PGBP-E_Vc0=.dad63c91-0e01-4124-9b44-467134a26b75@github.com> Message-ID: On Tue, 17 May 2022 08:27:41 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Missing ASSERT -> NOT_PRODUCT > > src/java.base/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java line 66: > >> 64: private static final boolean USE_SPEC = Boolean.parseBoolean( >> 65: GetPropertyAction.privilegedGetProperty("jdk.internal.foreign.ProgrammableInvoker.USE_SPEC", "true")); >> 66: private static final boolean USE_INTRINSICS = Boolean.parseBoolean( > > Do we need to update TestMatrix given that we're removing one dimension in the invokers? Looks like that already happened as part of the main JEP integration. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Tue May 17 10:38:39 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 17 May 2022 10:38:39 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v22] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: ifdef NOT_PRODUCT -> ifndef PRODUCT ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/406f3e83..c3abb732 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=21 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=20-21 Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From rehn at openjdk.java.net Tue May 17 12:27:11 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 17 May 2022 12:27:11 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v22] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 10:38:39 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > ifdef NOT_PRODUCT -> ifndef PRODUCT Looks good, thanks. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7959 From asotona at openjdk.java.net Tue May 17 12:55:21 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Tue, 17 May 2022 12:55:21 GMT Subject: RFR: 8286571: java source launcher from a minimal jdk image containing jdk.compiler fails with --enable-preview option Message-ID: ### Problem description Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies fails to run java source launcher correctly (for example when --source N is specified). Failing source launcher is the only one expression of internal jdk.compiler malfunction, another example is failure to run javac with --release option. ### Root cause Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality. However module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info. ### Alternative patch The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). ### Proposed fix This patch does fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs. Plus added specific test case. Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs. Thanks, Adam ------------- Commit messages: - 8286571: java source launcher from a minimal jdk image containing jdk.compiler fails with --enable-preview option Changes: https://git.openjdk.java.net/jdk/pull/8747/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8747&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286571 Stats: 30 lines in 2 files changed: 29 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8747.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8747/head:pull/8747 PR: https://git.openjdk.java.net/jdk/pull/8747 From duke at openjdk.java.net Tue May 17 13:03:18 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Tue, 17 May 2022 13:03:18 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl Message-ID: May I please have a review of this PR which adds non-interleaving log streams to UL? In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: 1. `ttyLocker` + `(x)tty` Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. 2. `stringStream` + `outputStream*` In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. Passes tier 1. ------------- Commit messages: - Add tests for interleaved-ness of the two logstreams - Make templated LogStreamImpl and add NoninterleavingStream on top - Make LogMessageImpl non-templated and use references for LogTagSet Changes: https://git.openjdk.java.net/jdk/pull/8748/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286180 Stats: 400 lines in 6 files changed: 224 ins; 142 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/8748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8748/head:pull/8748 PR: https://git.openjdk.java.net/jdk/pull/8748 From asotona at openjdk.java.net Tue May 17 13:08:32 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Tue, 17 May 2022 13:08:32 GMT Subject: RFR: 8286571: java source launcher from a minimal jdk image containing jdk.compiler fails with --enable-preview option [v2] In-Reply-To: References: Message-ID: > ### Problem description > Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies > fails to run java source launcher correctly (for example when --source N is specified). > Failing source launcher is the only one expression of internal jdk.compiler malfunction, another example is failure to run javac with --release option. > > ### Root cause > Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality. > However module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info. > > ### Alternative patch > The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). > > ### Proposed fix > This patch does fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs. > Plus added specific test case. > > Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fix of LimitedImage test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8747/files - new: https://git.openjdk.java.net/jdk/pull/8747/files/40884fd8..6bdf4a9a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8747&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8747&range=00-01 Stats: 45 lines in 1 file changed: 0 ins; 37 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8747.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8747/head:pull/8747 PR: https://git.openjdk.java.net/jdk/pull/8747 From duke at openjdk.java.net Tue May 17 13:19:39 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Tue, 17 May 2022 13:19:39 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v2] In-Reply-To: References: Message-ID: <5k8qO4jHizgHCsJsQ0O8DVzB23gUk4HFwfTGD7niw3Y=.0de9e0ed-86e6-4e07-9385-8e3b436a5101@github.com> > May I please have a review of this PR which adds non-interleaving log streams to UL? > > In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. > > Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: > > 1. `ttyLocker` + `(x)tty` > Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. > > 2. `stringStream` + `outputStream*` > In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. > > Passes tier 1. Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Fix minor style issues ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8748/files - new: https://git.openjdk.java.net/jdk/pull/8748/files/cccc3437..607998e4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=00-01 Stats: 23 lines in 1 file changed: 3 ins; 1 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/8748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8748/head:pull/8748 PR: https://git.openjdk.java.net/jdk/pull/8748 From duke at openjdk.java.net Tue May 17 13:31:24 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Tue, 17 May 2022 13:31:24 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v3] In-Reply-To: References: Message-ID: > May I please have a review of this PR which adds non-interleaving log streams to UL? > > In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. > > Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: > > 1. `ttyLocker` + `(x)tty` > Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. > > 2. `stringStream` + `outputStream*` > In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. > > Passes tier 1. Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Fix constructor style ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8748/files - new: https://git.openjdk.java.net/jdk/pull/8748/files/607998e4..bce09e80 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=01-02 Stats: 13 lines in 2 files changed: 1 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8748/head:pull/8748 PR: https://git.openjdk.java.net/jdk/pull/8748 From duke at openjdk.java.net Tue May 17 13:35:53 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Tue, 17 May 2022 13:35:53 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v4] In-Reply-To: References: Message-ID: > May I please have a review of this PR which adds non-interleaving log streams to UL? > > In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. > > Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: > > 1. `ttyLocker` + `(x)tty` > Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. > > 2. `stringStream` + `outputStream*` > In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. > > Passes tier 1. Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Don't use get_ prefix and fix indentation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8748/files - new: https://git.openjdk.java.net/jdk/pull/8748/files/bce09e80..13e1cca2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=02-03 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8748/head:pull/8748 PR: https://git.openjdk.java.net/jdk/pull/8748 From mbaesken at openjdk.java.net Tue May 17 13:40:09 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 17 May 2022 13:40:09 GMT Subject: RFR: JDK-8286869: unify os::dir_is_empty coding across posix platforms Message-ID: The os::dir_is_empty coding is very similar across Posix platforms and could be unified to os_posix.cpp . ------------- Commit messages: - JDK-8286869 Changes: https://git.openjdk.java.net/jdk/pull/8750/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8750&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286869 Stats: 76 lines in 4 files changed: 19 ins; 57 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8750.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8750/head:pull/8750 PR: https://git.openjdk.java.net/jdk/pull/8750 From hseigel at openjdk.java.net Tue May 17 13:47:39 2022 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 17 May 2022 13:47:39 GMT Subject: RFR: 8286277: CDS VerifyError when calling clone() on object array In-Reply-To: References: Message-ID: On Mon, 16 May 2022 22:49:24 GMT, Ioi Lam wrote: > **Problem:** > > When verifying an invokevirtual bytecode that calls a protected method in a superclass of the current class, the verifier requires that the object being invoked must be a subtype of the current class. This prevents invocation of protected methods in an unrelated class. For example, the following is disallowed -- the type `InvokeCloneInvalid` cannot invoke `clone()` on a `String`: > > > super public class InvokeCloneInvalid > version 52:0 > { > public static Method test:"(Ljava/lang/String;)V" > stack 1 locals 1 > { > aload_0; > invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; > return; > } > } > > > However, there's a special case where invoking `Object.clone()` is allowed on all object arrays. Here's an example: > > > super public class InvokeCloneValid > version 52:0 > { > public static Method test:"([Ljava/lang/Object;)V" > stack 1 locals 1 > { > aload_0; > invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; > return; > } > > > Before this PR. the Verifier would first do the assignability check. When a failure is encountered, the Verifier then checks for the special case and ignores the failure accordingly. > > In the above case, the assignability check will fail because the object being invoked (an Object array) is not assignable to the current class (InvokeCloneValid) > > The problem is that CDS remembers all the assignability checks and tries to replay them at runtime. Therefore, it will re-check the assignability of Object Array to InvokeCloneValid, and throw a VerifyError as a result. > > **Proposed Fix** > > In `ClassVerifier::verify_invoke_instructions()`, check the special case first, before doing the assignability check. This way, such invalid-but-ignored assignability checks are no longer performed and thus won't be remembered by CDS. > > **Testing** > > Tiers 1 - 4, plus 3 new test cases. The is_assignable_check() may or may not load the array class depending on what it needs to check assignability. But neither the verifier nor the JVM has any dependency on the array class being loaded. Note that if this were not a protected access or if name_in_supers() returned null then the is_assignable_check() would not get called. Also note that the verifier tries to avoid loading classes. Also, the assignability check may cause the array class to get loaded but would not cause it to get linked or verified. ------------- PR: https://git.openjdk.java.net/jdk/pull/8737 From jvernee at openjdk.java.net Tue May 17 15:53:05 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 17 May 2022 15:53:05 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v23] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits: - Merge branch 'master' into JEP-19-VM-IMPL2 - ifdef NOT_PRODUCT -> ifndef PRODUCT - Missing ASSERT -> NOT_PRODUCT - Cleanup UL usage - Fix failure with SPEC disabled (accidentally dropped change) - indentation - fix space - Merge branch 'master' into JEP-19-VM-IMPL2 - Undo spurious changes. - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2 - ... and 95 more: https://git.openjdk.java.net/jdk/compare/af07919e...c3c1421b ------------- Changes: https://git.openjdk.java.net/jdk/pull/7959/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=22 Stats: 6914 lines in 155 files changed: 2577 ins; 3219 del; 1118 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From iklam at openjdk.java.net Tue May 17 16:13:37 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 17 May 2022 16:13:37 GMT Subject: RFR: 8286277: CDS VerifyError when calling clone() on object array [v2] In-Reply-To: References: Message-ID: > **Problem:** > > When verifying an invokevirtual bytecode that calls a protected method in a superclass of the current class, the verifier requires that the object being invoked must be a subtype of the current class. This prevents invocation of protected methods in an unrelated class. For example, the following is disallowed -- the type `InvokeCloneInvalid` cannot invoke `clone()` on a `String`: > > > super public class InvokeCloneInvalid > version 52:0 > { > public static Method test:"(Ljava/lang/String;)V" > stack 1 locals 1 > { > aload_0; > invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; > return; > } > } > > > However, there's a special case where invoking `Object.clone()` is allowed on all object arrays. Here's an example: > > > super public class InvokeCloneValid > version 52:0 > { > public static Method test:"([Ljava/lang/Object;)V" > stack 1 locals 1 > { > aload_0; > invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; > return; > } > > > Before this PR. the Verifier would first do the assignability check. When a failure is encountered, the Verifier then checks for the special case and ignores the failure accordingly. > > In the above case, the assignability check will fail because the object being invoked (an Object array) is not assignable to the current class (InvokeCloneValid) > > The problem is that CDS remembers all the assignability checks and tries to replay them at runtime. Therefore, it will re-check the assignability of Object Array to InvokeCloneValid, and throw a VerifyError as a result. > > **Proposed Fix** > > In `ClassVerifier::verify_invoke_instructions()`, check the special case first, before doing the assignability check. This way, such invalid-but-ignored assignability checks are no longer performed and thus won't be remembered by CDS. > > **Testing** > > Tiers 1 - 4, plus 3 new test cases. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Adding newline at end of file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8737/files - new: https://git.openjdk.java.net/jdk/pull/8737/files/7121754a..a292dc39 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8737&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8737&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8737.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8737/head:pull/8737 PR: https://git.openjdk.java.net/jdk/pull/8737 From iklam at openjdk.java.net Tue May 17 16:13:38 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 17 May 2022 16:13:38 GMT Subject: RFR: 8286277: CDS VerifyError when calling clone() on object array [v2] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 06:36:40 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding newline at end of file > > test/hotspot/jtreg/runtime/verifier/InvokeCloneValid.jasm line 42: > >> 40: return; >> 41: } >> 42: } > > Missing newline at end of line. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8737 From iklam at openjdk.java.net Tue May 17 22:24:31 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 17 May 2022 22:24:31 GMT Subject: RFR: JDK-8286869: unify os::dir_is_empty coding across posix platforms In-Reply-To: References: Message-ID: On Tue, 17 May 2022 13:33:57 GMT, Matthias Baesken wrote: > The os::dir_is_empty coding is very similar across Posix platforms and could be unified to os_posix.cpp . Marked as reviewed by iklam (Reviewer). The code change looks good to me. The word "coding" in the bug title is superfluous and could be confused with "encoding" since this is in the OS area. I would suggest removing this word from the bug title. ------------- PR: https://git.openjdk.java.net/jdk/pull/8750 From dholmes at openjdk.java.net Wed May 18 02:16:47 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 May 2022 02:16:47 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v4] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 13:35:53 GMT, Johan Sj?l?n wrote: >> May I please have a review of this PR which adds non-interleaving log streams to UL? >> >> In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. >> >> Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: >> >> 1. `ttyLocker` + `(x)tty` >> Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. >> >> 2. `stringStream` + `outputStream*` >> In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. >> >> Passes tier 1. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Don't use get_ prefix and fix indentation src/hotspot/share/logging/logStream.hpp line 72: > 70: > 71: virtual ~LogStreamImpl() { > 72: if (_current_line.is_empty() == false) { Nit: boolean functions can be used directly in expressions - so `if (!_current_line.is_empty()) {` ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From dholmes at openjdk.java.net Wed May 18 02:23:58 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 May 2022 02:23:58 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v4] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 13:35:53 GMT, Johan Sj?l?n wrote: >> May I please have a review of this PR which adds non-interleaving log streams to UL? >> >> In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. >> >> Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: >> >> 1. `ttyLocker` + `(x)tty` >> Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. >> >> 2. `stringStream` + `outputStream*` >> In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. >> >> Passes tier 1. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Don't use get_ prefix and fix indentation src/hotspot/share/logging/logStream.hpp line 127: > 125: size_t newcap = align_up(atleast + additional_expansion, additional_expansion); > 126: if (newcap > reasonable_max) { > 127: log_info(logging)("Suspiciously long log line: \"%.100s%s", Can we safely log from inside logging code? test/hotspot/gtest/logging/test_logStream.cpp line 24: > 22: * > 23: */ > 24: #include "memory/resourceArea.hpp" includes should be ordered alphabetically in general, but nothing should come before precompiled.hpp ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From jpai at openjdk.java.net Wed May 18 02:53:49 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 18 May 2022 02:53:49 GMT Subject: RFR: 8286571: java source launcher from a minimal jdk image containing jdk.compiler fails with --enable-preview option [v2] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 13:08:32 GMT, Adam Sotona wrote: >> ### Problem description >> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies >> fails to run java source launcher correctly (for example when --source N is specified). >> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option. >> >> ### Root cause >> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality. >> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info. >> >> ### Alternative patch >> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. >> >> ### Proposed fix >> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs. >> Plus added specific test case. >> >> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > fix of LimitedImage test Hello Adam, I don't have necessary knowledge of this area, so I don't know what approach would be preferred. But a couple of questions: - If we do decide to add the `jdk.zipfs` dependency to `jdk.compiler` module, do you think the `LimitedImage` test is still relevant? Or should it be removed? The comment on that test states: > @summary Verify javac behaves properly in absence of zip/jar FileSystemProvider and it does so by using `--limit-modules`. But now with the `jdk.zipfs` being a dependency, the zip/jar FileSystemProvider will not be absent and the test then would seem unnecessary. - In the JBS issue corresponding to this PR, you noted that: >There are actually two different issues: > >First in JDKPlatformProvider, which silently swallows ProviderNotFoundException. Should something be done there? I see that the catch block happens to reside in the `static` block of that class (which also happens to be a implementation of a Java `service`), so I'm unsure what if anything can be done there. ------------- PR: https://git.openjdk.java.net/jdk/pull/8747 From dholmes at openjdk.java.net Wed May 18 06:53:45 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 May 2022 06:53:45 GMT Subject: RFR: JDK-8286869: unify os::dir_is_empty across posix platforms In-Reply-To: References: Message-ID: On Tue, 17 May 2022 13:33:57 GMT, Matthias Baesken wrote: > The os::dir_is_empty coding is very similar across Posix platforms and could be unified to os_posix.cpp . Looks fine - one suggested tweak below. Won't it be nice if one day we can use `std::filesystem::is_empty` :) src/hotspot/os/posix/os_posix.cpp line 260: > 258: // Scan the directory > 259: bool result = true; > 260: while (result && (ptr = readdir(dir)) != NULL) { This will call `os::readdir` when we can just call `::readdir` directly. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8750 From dholmes at openjdk.java.net Wed May 18 07:00:55 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 May 2022 07:00:55 GMT Subject: RFR: 8286277: CDS VerifyError when calling clone() on object array [v2] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 16:13:37 GMT, Ioi Lam wrote: >> **Problem:** >> >> When verifying an invokevirtual bytecode that calls a protected method in a superclass of the current class, the verifier requires that the object being invoked must be a subtype of the current class. This prevents invocation of protected methods in an unrelated class. For example, the following is disallowed -- the type `InvokeCloneInvalid` cannot invoke `clone()` on a `String`: >> >> >> super public class InvokeCloneInvalid >> version 52:0 >> { >> public static Method test:"(Ljava/lang/String;)V" >> stack 1 locals 1 >> { >> aload_0; >> invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; >> return; >> } >> } >> >> >> However, there's a special case where invoking `Object.clone()` is allowed on all object arrays. Here's an example: >> >> >> super public class InvokeCloneValid >> version 52:0 >> { >> public static Method test:"([Ljava/lang/Object;)V" >> stack 1 locals 1 >> { >> aload_0; >> invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; >> return; >> } >> >> >> Before this PR. the Verifier would first do the assignability check. When a failure is encountered, the Verifier then checks for the special case and ignores the failure accordingly. >> >> In the above case, the assignability check will fail because the object being invoked (an Object array) is not assignable to the current class (InvokeCloneValid) >> >> The problem is that CDS remembers all the assignability checks and tries to replay them at runtime. Therefore, it will re-check the assignability of Object Array to InvokeCloneValid, and throw a VerifyError as a result. >> >> **Proposed Fix** >> >> In `ClassVerifier::verify_invoke_instructions()`, check the special case first, before doing the assignability check. This way, such invalid-but-ignored assignability checks are no longer performed and thus won't be remembered by CDS. >> >> **Testing** >> >> Tiers 1 - 4, plus 3 new test cases. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Adding newline at end of file Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8737 From dholmes at openjdk.java.net Wed May 18 07:00:56 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 May 2022 07:00:56 GMT Subject: RFR: 8286277: CDS VerifyError when calling clone() on object array In-Reply-To: References: Message-ID: <8PU3jkjztWn7jC3sKdHbcSDpW_Kjqh9orzLaZcYmKB8=.f7381f6b-31b5-4ad5-b8e8-d2c54e685a4a@github.com> On Tue, 17 May 2022 13:44:46 GMT, Harold Seigel wrote: >> **Problem:** >> >> When verifying an invokevirtual bytecode that calls a protected method in a superclass of the current class, the verifier requires that the object being invoked must be a subtype of the current class. This prevents invocation of protected methods in an unrelated class. For example, the following is disallowed -- the type `InvokeCloneInvalid` cannot invoke `clone()` on a `String`: >> >> >> super public class InvokeCloneInvalid >> version 52:0 >> { >> public static Method test:"(Ljava/lang/String;)V" >> stack 1 locals 1 >> { >> aload_0; >> invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; >> return; >> } >> } >> >> >> However, there's a special case where invoking `Object.clone()` is allowed on all object arrays. Here's an example: >> >> >> super public class InvokeCloneValid >> version 52:0 >> { >> public static Method test:"([Ljava/lang/Object;)V" >> stack 1 locals 1 >> { >> aload_0; >> invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; >> return; >> } >> >> >> Before this PR. the Verifier would first do the assignability check. When a failure is encountered, the Verifier then checks for the special case and ignores the failure accordingly. >> >> In the above case, the assignability check will fail because the object being invoked (an Object array) is not assignable to the current class (InvokeCloneValid) >> >> The problem is that CDS remembers all the assignability checks and tries to replay them at runtime. Therefore, it will re-check the assignability of Object Array to InvokeCloneValid, and throw a VerifyError as a result. >> >> **Proposed Fix** >> >> In `ClassVerifier::verify_invoke_instructions()`, check the special case first, before doing the assignability check. This way, such invalid-but-ignored assignability checks are no longer performed and thus won't be remembered by CDS. >> >> **Testing** >> >> Tiers 1 - 4, plus 3 new test cases. > > The is_assignable_check() may or may not load the array class depending on what it needs to check assignability. But neither the verifier nor the JVM has any dependency on the array class being loaded. Note that if this were not a protected access or if name_in_supers() returned null then the is_assignable_check() would not get called. Also note that the verifier tries to avoid loading classes. > > Also, the assignability check may cause the array class to get loaded but would not cause it to get linked or verified. Thanks Harold! @hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/8737 From mbaesken at openjdk.java.net Wed May 18 07:05:57 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 18 May 2022 07:05:57 GMT Subject: RFR: JDK-8286869: unify os::dir_is_empty across posix platforms In-Reply-To: References: Message-ID: On Wed, 18 May 2022 06:44:13 GMT, David Holmes wrote: >> The os::dir_is_empty coding is very similar across Posix platforms and could be unified to os_posix.cpp . > > src/hotspot/os/posix/os_posix.cpp line 260: > >> 258: // Scan the directory >> 259: bool result = true; >> 260: while (result && (ptr = readdir(dir)) != NULL) { > > This will call `os::readdir` when we can just call `::readdir` directly. Hi David , so do you suggest to use ::readdir instead ? What about opendir and closedir, should we use as well ::opendir and ::closedir ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8750 From dholmes at openjdk.java.net Wed May 18 07:13:51 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 May 2022 07:13:51 GMT Subject: RFR: JDK-8286869: unify os::dir_is_empty across posix platforms In-Reply-To: References: Message-ID: <_MTDE6HALXWu2o_x9OyDs5L6QWftI-NP-PxrqfU5rgY=.6e409d5f-2adf-427c-bbf0-783256f721bf@github.com> On Wed, 18 May 2022 07:02:29 GMT, Matthias Baesken wrote: >> src/hotspot/os/posix/os_posix.cpp line 260: >> >>> 258: // Scan the directory >>> 259: bool result = true; >>> 260: while (result && (ptr = readdir(dir)) != NULL) { >> >> This will call `os::readdir` when we can just call `::readdir` directly. > > Hi David , so do you suggest to use ::readdir instead ? What about opendir and closedir, should we use as well ::opendir and ::closedir ? Yes, sorry, all of them. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8750 From mbaesken at openjdk.java.net Wed May 18 07:28:38 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 18 May 2022 07:28:38 GMT Subject: RFR: JDK-8286869: unify os::dir_is_empty across posix platforms [v2] In-Reply-To: References: Message-ID: > The os::dir_is_empty coding is very similar across Posix platforms and could be unified to os_posix.cpp . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: use readdir, opendir, closedir from global scope ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8750/files - new: https://git.openjdk.java.net/jdk/pull/8750/files/ba634945..2229b51d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8750&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8750&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8750.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8750/head:pull/8750 PR: https://git.openjdk.java.net/jdk/pull/8750 From mbaesken at openjdk.java.net Wed May 18 07:32:42 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 18 May 2022 07:32:42 GMT Subject: RFR: JDK-8286869: unify os::dir_is_empty across posix platforms [v2] In-Reply-To: <_MTDE6HALXWu2o_x9OyDs5L6QWftI-NP-PxrqfU5rgY=.6e409d5f-2adf-427c-bbf0-783256f721bf@github.com> References: <_MTDE6HALXWu2o_x9OyDs5L6QWftI-NP-PxrqfU5rgY=.6e409d5f-2adf-427c-bbf0-783256f721bf@github.com> Message-ID: On Wed, 18 May 2022 07:10:28 GMT, David Holmes wrote: > Yes, sorry, all of them. Thanks. I adjusted the 3 calls. ------------- PR: https://git.openjdk.java.net/jdk/pull/8750 From jvernee at openjdk.java.net Wed May 18 09:53:31 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 18 May 2022 09:53:31 GMT Subject: Integrated: 8283689: Update the foreign linker VM implementation In-Reply-To: References: Message-ID: <96UqTMEdAdl4yleY0IBU6LJjL8ww23IUcktML7Aa8UM=.9bfa69dc-720b-43aa-9b77-147b29d925cd@github.com> On Fri, 25 Mar 2022 13:48:20 GMT, Jorn Vernee wrote: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 This pull request has now been integrated. Changeset: 81e4bdbe Author: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/81e4bdbe1358b7feced08ba758ddb66415968036 Stats: 6914 lines in 155 files changed: 2577 ins; 3219 del; 1118 mod 8283689: Update the foreign linker VM implementation Co-authored-by: Jorn Vernee Co-authored-by: Nick Gasson Reviewed-by: mcimadamore, vlivanov, rehn ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From duke at openjdk.java.net Wed May 18 10:04:48 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 18 May 2022 10:04:48 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v4] In-Reply-To: References: Message-ID: On Wed, 18 May 2022 02:18:09 GMT, David Holmes wrote: >> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't use get_ prefix and fix indentation > > src/hotspot/share/logging/logStream.hpp line 127: > >> 125: size_t newcap = align_up(atleast + additional_expansion, additional_expansion); >> 126: if (newcap > reasonable_max) { >> 127: log_info(logging)("Suspiciously long log line: \"%.100s%s", > > Can we safely log from inside logging code? Yes. This call never occurs when the backing log is logged to, so there's no risk of double locking (this is technically not "logging code"). This code has also been in the source tree since 2016, so experimentally it seems OK :-). My change moves this inside of `logStream.hpp` and deletes `logStream.cpp` as `LogStreamImpl` is templated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From mbaesken at openjdk.java.net Wed May 18 10:48:02 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 18 May 2022 10:48:02 GMT Subject: RFR: JDK-8286869: unify os::dir_is_empty across posix platforms [v2] In-Reply-To: References: Message-ID: <0_uy46SypKkh2CQ3jozoRMqdVuOqHD0YTdyLNaqHUFk=.c4ac0c20-23ff-4567-ac70-d65f4ff4f291@github.com> On Wed, 18 May 2022 07:28:38 GMT, Matthias Baesken wrote: >> The os::dir_is_empty coding is very similar across Posix platforms and could be unified to os_posix.cpp . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > use readdir, opendir, closedir from global scope Thanks for the reviews. Are you fine with the latest version of the patch? ------------- PR: https://git.openjdk.java.net/jdk/pull/8750 From dholmes at openjdk.java.net Wed May 18 10:52:59 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 May 2022 10:52:59 GMT Subject: RFR: JDK-8286869: unify os::dir_is_empty across posix platforms [v2] In-Reply-To: References: Message-ID: On Wed, 18 May 2022 07:28:38 GMT, Matthias Baesken wrote: >> The os::dir_is_empty coding is very similar across Posix platforms and could be unified to os_posix.cpp . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > use readdir, opendir, closedir from global scope Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8750 From duke at openjdk.java.net Wed May 18 13:53:54 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 18 May 2022 13:53:54 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v4] In-Reply-To: References: Message-ID: On Wed, 18 May 2022 02:13:19 GMT, David Holmes wrote: >> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't use get_ prefix and fix indentation > > src/hotspot/share/logging/logStream.hpp line 72: > >> 70: >> 71: virtual ~LogStreamImpl() { >> 72: if (_current_line.is_empty() == false) { > > Nit: boolean functions can be used directly in expressions - so `if (!_current_line.is_empty()) {` Nice, fixed! ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From duke at openjdk.java.net Wed May 18 15:10:07 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 18 May 2022 15:10:07 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v5] In-Reply-To: References: Message-ID: > May I please have a review of this PR which adds non-interleaving log streams to UL? > > In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. > > Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: > > 1. `ttyLocker` + `(x)tty` > Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. > > 2. `stringStream` + `outputStream*` > In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. > > Passes tier 1. Johan Sj?l?n has updated the pull request incrementally with three additional commits since the last revision: - Use unary not instead of comparing to false - Sort includes - Style changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8748/files - new: https://git.openjdk.java.net/jdk/pull/8748/files/13e1cca2..c04e06be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=03-04 Stats: 39 lines in 2 files changed: 15 ins; 8 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/8748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8748/head:pull/8748 PR: https://git.openjdk.java.net/jdk/pull/8748 From duke at openjdk.java.net Wed May 18 15:10:09 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 18 May 2022 15:10:09 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v4] In-Reply-To: References: Message-ID: <0oGw8654KOROmZpE-r4-_IRjENIxM-W2mDJWhczCoZY=.83f89e47-a3b7-4ea1-bf86-7c36578db8ba@github.com> On Wed, 18 May 2022 02:20:25 GMT, David Holmes wrote: >> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't use get_ prefix and fix indentation > > test/hotspot/gtest/logging/test_logStream.cpp line 24: > >> 22: * >> 23: */ >> 24: #include "memory/resourceArea.hpp" > > includes should be ordered alphabetically in general, but nothing should come before precompiled.hpp Fixed! ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From iklam at openjdk.java.net Wed May 18 15:29:55 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 18 May 2022 15:29:55 GMT Subject: RFR: JDK-8286869: unify os::dir_is_empty across posix platforms [v2] In-Reply-To: References: Message-ID: On Wed, 18 May 2022 07:28:38 GMT, Matthias Baesken wrote: >> The os::dir_is_empty coding is very similar across Posix platforms and could be unified to os_posix.cpp . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > use readdir, opendir, closedir from global scope Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8750 From mbaesken at openjdk.java.net Wed May 18 16:49:45 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 18 May 2022 16:49:45 GMT Subject: Integrated: JDK-8286869: unify os::dir_is_empty across posix platforms In-Reply-To: References: Message-ID: On Tue, 17 May 2022 13:33:57 GMT, Matthias Baesken wrote: > The os::dir_is_empty coding is very similar across Posix platforms and could be unified to os_posix.cpp . This pull request has now been integrated. Changeset: 9ab29b6c Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/9ab29b6c07d0995127ba647b2eab1c694e236661 Stats: 76 lines in 4 files changed: 19 ins; 57 del; 0 mod 8286869: unify os::dir_is_empty across posix platforms Reviewed-by: iklam, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/8750 From sgehwolf at openjdk.java.net Wed May 18 18:14:52 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 18 May 2022 18:14:52 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3] In-Reply-To: References: Message-ID: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com> > Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter). > > In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running. > > Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round). > > Testing: > - [x] Added unit tests > - [x] GHA > - [x] Container tests on cgroups v1 Linux. Continue to pass Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision: - Refactor hotspot gtest - Separate into function. Fix comment. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8629/files - new: https://git.openjdk.java.net/jdk/pull/8629/files/66241aa5..4b8e92fa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8629&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8629&range=01-02 Stats: 93 lines in 3 files changed: 56 ins; 25 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/8629.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8629/head:pull/8629 PR: https://git.openjdk.java.net/jdk/pull/8629 From sgehwolf at openjdk.java.net Wed May 18 18:14:55 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 18 May 2022 18:14:55 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2] In-Reply-To: References: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com> Message-ID: On Tue, 17 May 2022 06:18:25 GMT, Ioi Lam wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Use stringStream to simplify controller path assembly > > src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92: > >> 90: } >> 91: ss.print_raw(_root, last_matching_slash_pos); >> 92: _path = os::strdup(ss.base()); > > Do you mean `Find the longest common prefix`? Maybe give an example in the comments? Text parsing in C code is really difficult to understand. @iklam yes I meant `Find the longest common prefix`. Fixed the comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From sgehwolf at openjdk.java.net Wed May 18 18:14:57 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 18 May 2022 18:14:57 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2] In-Reply-To: References: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com> Message-ID: On Wed, 18 May 2022 18:09:54 GMT, Severin Gehwolf wrote: >> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92: >> >>> 90: } >>> 91: ss.print_raw(_root, last_matching_slash_pos); >>> 92: _path = os::strdup(ss.base()); >> >> Do you mean `Find the longest common prefix`? Maybe give an example in the comments? Text parsing in C code is really difficult to understand. > > @iklam yes I meant `Find the longest common prefix`. Fixed the comment. I'm not convinced the extra function makes the code more readable, but here it is. I can revert back if this is too much. >> test/hotspot/gtest/runtime/test_os_linux_cgroups.cpp line 63: >> >>> 61: ASSERT_STREQ(expected_cg_paths[i], ctrl->subsystem_path()); >>> 62: } >>> 63: } >> >> I found it hard to relate the different paths. Could you create a new struct like this? >> >> >> struct TestCase { >> char* mount_path; >> char* root_paths; >> char* cgroup_path; >> char* expected_cg_paths; >> } = { >> { "/sys/fs/cgroup/memory", // mount >> "/", // root, >> .... > > Yes, makes sense. Will do. Done now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From iklam at openjdk.java.net Thu May 19 06:21:58 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 19 May 2022 06:21:58 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3] In-Reply-To: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com> References: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com> Message-ID: On Wed, 18 May 2022 18:14:52 GMT, Severin Gehwolf wrote: >> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter). >> >> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running. >> >> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round). >> >> Testing: >> - [x] Added unit tests >> - [x] GHA >> - [x] Container tests on cgroups v1 Linux. Continue to pass > > Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor hotspot gtest > - Separate into function. Fix comment. Changes requested by iklam (Reviewer). src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 60: > 58: strncpy(buf, _mount_point, MAXPATHLEN); > 59: buf[MAXPATHLEN-1] = '\0'; > 60: _path = os::strdup(buf); Comment on the old code: why this cannot be simply _path = os::strdup(_mount_point); Also, all the strncat calls in this function seem problematic, and should be converted to stringStream for consistency. src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 63: > 61: } else { > 62: char *p = strstr(cgroup_path, _root); > 63: if (p != NULL && p == cgroup_path) { What happens if cgroup_path is "/foo/bar" and _root is "/fo"? Maybe this block should be combined with the new `else` block you're adding? However, the behavior seems opposite between these two blocks of code: The upper block: _root is a prefix of cgroup_path, we take the **tail** of cgroup_path TestCase substring_match = { "/sys/fs/cgroup/memory", // mount_path "/user.slice/user-1000.slice", // root_path "/user.slice/user-1000.slice/user at 1001.service", // cgroup_path "/sys/fs/cgroup/memory/user at 1001.service" // expected_path }; The lower block: The beginning of _root is a prefix of cgroup_path, we take the **head** of cgroup_path TestCase prefix_matched_cg = { "/sys/fs/cgroup/memory", // mount_path "/user.slice/user-1000.slice/session-50.scope", // root_path "/user.slice/user-1000.slice/session-3.scope", // cgroup_path "/sys/fs/cgroup/memory/user.slice/user-1000.slice" // expected_path }; I find the behavior hard to understand. I think the rules (and reasons) should be added to the comment block above the function. src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 86: > 84: const char* cgroup_p = cgroup_path; > 85: int last_slash = find_last_slash_pos(root_p, cgroup_p); > 86: assert(last_slash >= 0, "not an absolute path?"); Are root_p and cgroup_p directly read from the /proc/xxx files. If so, do we validate the input to make sure they are absolute paths? It seems like our code cannot handle trailing '/' in the input. If so, we should clear all trailing '/' from the input string. Then, in functions that process them, we should assert that they don't end with slash. See my comment in find_last_slash_pos(). src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 102: > 100: for (int i = 0; *s1 == *s2 && *s1 != 0; i++) { > 101: if (*s1 == '/') { > 102: last_matching_slash_pos = i; I found the behavior a little hard to understand. Is it intentional? "/cat/cow", "/cat/dog" -> "/cat/" "/cat/", "/cat/dog" -> "/cat/" "/cat", "/cat/dog" -> "/" The name `find_last_slash_pos` doesn't properly describe the behavior. I thought about `find_common_path_prefix`, but that doesn't match the current behavior (for the 3rd case, the common path prefix is `"/cat"`). ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From stuefe at openjdk.java.net Thu May 19 07:05:50 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 19 May 2022 07:05:50 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2] In-Reply-To: References: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com> Message-ID: On Wed, 18 May 2022 18:10:45 GMT, Severin Gehwolf wrote: >> @iklam yes I meant `Find the longest common prefix`. Fixed the comment. > > I'm not convinced the extra function makes the code more readable, but here it is. I can revert back if this is too much. @jerboaa Feel free to go back to your original variant. This was only a proposal. ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From sgehwolf at openjdk.java.net Thu May 19 08:21:48 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 19 May 2022 08:21:48 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2] In-Reply-To: References: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com> Message-ID: On Thu, 19 May 2022 07:02:13 GMT, Thomas Stuefe wrote: >> I'm not convinced the extra function makes the code more readable, but here it is. I can revert back if this is too much. > > @jerboaa Feel free to go back to your original variant. This was only a proposal. understood. ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From sgehwolf at openjdk.java.net Thu May 19 09:10:49 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 19 May 2022 09:10:49 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3] In-Reply-To: References: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com> Message-ID: <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com> On Thu, 19 May 2022 05:53:19 GMT, Ioi Lam wrote: >> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision: >> >> - Refactor hotspot gtest >> - Separate into function. Fix comment. > > src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 60: > >> 58: strncpy(buf, _mount_point, MAXPATHLEN); >> 59: buf[MAXPATHLEN-1] = '\0'; >> 60: _path = os::strdup(buf); > > Comment on the old code: why this cannot be simply > > > _path = os::strdup(_mount_point); > > > Also, all the strncat calls in this function seem problematic, and should be converted to stringStream for consistency. Agreed. I've filed https://bugs.openjdk.java.net/browse/JDK-8287007 to track this. I'd like to limit the changes of this patch to a minimum. It seems orthogonal. > What happens if cgroup_path is "/foo/bar" and _root is "/fo"? With a mount path of `/bar` this ends up being `/bar/o/bar`. Pretty strange, but then again it's a bit of a contrived example as those paths come from `/proc` parsing. Anyway, this is code that got added with [JDK-8146115](https://bugs.openjdk.java.net/browse/JDK-8146115). It's not something I've written and to be honest, I'm not sure this branch is needed, but I didn't want to change the existing behaviour with this patch. I have no more insight than you in terms of why that approach has been taken. > Maybe this block should be combined with the new `else` block you're adding? Maybe, but I'm not sure if it would break something. > However, the behavior seems opposite between these two blocks of code: > > The upper block: _root is a prefix of cgroup_path, we take the **tail** of cgroup_path > > ``` > TestCase substring_match = { > "/sys/fs/cgroup/memory", // mount_path > "/user.slice/user-1000.slice", // root_path > "/user.slice/user-1000.slice/user at 1001.service", // cgroup_path > "/sys/fs/cgroup/memory/user at 1001.service" // expected_path > }; > ``` Yes. Though, I cannot comment on why that has been chosen. It's been there since day one :-/ > The lower block: The beginning of _root is a prefix of cgroup_path, we take the **head** of cgroup_path > > ``` > TestCase prefix_matched_cg = { > "/sys/fs/cgroup/memory", // mount_path > "/user.slice/user-1000.slice/session-50.scope", // root_path > "/user.slice/user-1000.slice/session-3.scope", // cgroup_path > "/sys/fs/cgroup/memory/user.slice/user-1000.slice" // expected_path > }; > ``` > > I find the behavior hard to understand. I think the rules (and reasons) should be added to the comment block above the function. The reason why I've gone down the path of adding the head of cgroup_path is because of this document (in conjunction to what the user was observing on an affected system): https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ The user was observing paths as listed in the test: "/user.slice/user-1000.slice/session-50.scope", // root_path "/user.slice/user-1000.slice/session-3.scope", // cgroup_path This very much looks like systemd managed. Given that and knowing that systemd adds processes into `scopes` or `services` and groups them via `slices` and also knowing that cgroups are hierarchical (i.e. limits of `/foo/bar` also apply to `/foo/bar/baz`), it seems likely that if there are any limits, then it'll be on `/user.slice/user-1000.slice` within the mounted controller. Unfortunately, I'm not able to reproduce this myself. ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From sgehwolf at openjdk.java.net Thu May 19 09:33:41 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 19 May 2022 09:33:41 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3] In-Reply-To: References: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com> Message-ID: On Thu, 19 May 2022 06:00:06 GMT, Ioi Lam wrote: >> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision: >> >> - Refactor hotspot gtest >> - Separate into function. Fix comment. > > src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 86: > >> 84: const char* cgroup_p = cgroup_path; >> 85: int last_slash = find_last_slash_pos(root_p, cgroup_p); >> 86: assert(last_slash >= 0, "not an absolute path?"); > > Are root_p and cgroup_p directly read from the /proc/xxx files. If so, do we validate the input to make sure they are absolute paths? > > It seems like our code cannot handle trailing '/' in the input. If so, we should clear all trailing '/' from the input string. Then, in functions that process them, we should assert that they don't end with slash. See my comment in find_last_slash_pos(). Yes, those values come from `/proc/self/mountinfo` and `/proc/self/cgroup`. There is no validation being done. Then again, we only end up in this branch if the root path is not a substring of the cgroup path. In that case trailing slashes don't matter, since there would not be a character by character match earlier. I'll add handling of trailing slashes and appropriate asserts where it makes sense. ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From sgehwolf at openjdk.java.net Thu May 19 09:49:07 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 19 May 2022 09:49:07 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3] In-Reply-To: References: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com> Message-ID: <7HeR1izA4CAi-Q989J7bEf5vyjguRveviD8rNOouYkY=.63efa7b6-d2c4-4a17-8659-02c62b63f250@github.com> On Thu, 19 May 2022 05:58:31 GMT, Ioi Lam wrote: >> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision: >> >> - Refactor hotspot gtest >> - Separate into function. Fix comment. > > src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 102: > >> 100: for (int i = 0; *s1 == *s2 && *s1 != 0; i++) { >> 101: if (*s1 == '/') { >> 102: last_matching_slash_pos = i; > > I found the behavior a little hard to understand. Is it intentional? > > > "/cat/cow", "/cat/dog" -> "/cat/" > "/cat/", "/cat/dog" -> "/cat/" > "/cat", "/cat/dog" -> "/" > > > The name `find_last_slash_pos` doesn't properly describe the behavior. I thought about `find_common_path_prefix`, but that doesn't match the current behavior (for the 3rd case, the common path prefix is `"/cat"`). It's supposed to find the common path prefix as you say. I'll fix it. Open to suggestions to make it easier to understand. ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From ccheung at openjdk.java.net Thu May 19 19:17:48 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 19 May 2022 19:17:48 GMT Subject: RFR: 8286277: CDS VerifyError when calling clone() on object array [v2] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 16:13:37 GMT, Ioi Lam wrote: >> **Problem:** >> >> When verifying an invokevirtual bytecode that calls a protected method in a superclass of the current class, the verifier requires that the object being invoked must be a subtype of the current class. This prevents invocation of protected methods in an unrelated class. For example, the following is disallowed -- the type `InvokeCloneInvalid` cannot invoke `clone()` on a `String`: >> >> >> super public class InvokeCloneInvalid >> version 52:0 >> { >> public static Method test:"(Ljava/lang/String;)V" >> stack 1 locals 1 >> { >> aload_0; >> invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; >> return; >> } >> } >> >> >> However, there's a special case where invoking `Object.clone()` is allowed on all object arrays. Here's an example: >> >> >> super public class InvokeCloneValid >> version 52:0 >> { >> public static Method test:"([Ljava/lang/Object;)V" >> stack 1 locals 1 >> { >> aload_0; >> invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; >> return; >> } >> >> >> Before this PR. the Verifier would first do the assignability check. When a failure is encountered, the Verifier then checks for the special case and ignores the failure accordingly. >> >> In the above case, the assignability check will fail because the object being invoked (an Object array) is not assignable to the current class (InvokeCloneValid) >> >> The problem is that CDS remembers all the assignability checks and tries to replay them at runtime. Therefore, it will re-check the assignability of Object Array to InvokeCloneValid, and throw a VerifyError as a result. >> >> **Proposed Fix** >> >> In `ClassVerifier::verify_invoke_instructions()`, check the special case first, before doing the assignability check. This way, such invalid-but-ignored assignability checks are no longer performed and thus won't be remembered by CDS. >> >> **Testing** >> >> Tiers 1 - 4, plus 3 new test cases. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Adding newline at end of file Looks good. Just one nit. test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/VerifyObjArrayCloneTest.java line 32: > 30: * /test/hotspot/jtreg/runtime/cds/appcds/test-classes > 31: * @build sun.hotspot.WhiteBox > 32: * @build InvokeCloneValid InvokeCloneInvalid VerifyObjArrayCloneTestApp Please align line 32 with line 31. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8737 From pchilanomate at openjdk.java.net Thu May 19 19:40:07 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 19 May 2022 19:40:07 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops Message-ID: On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things: - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state. - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases. I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.java.net/jdk/pull/8795/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8795&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286830 Stats: 84 lines in 5 files changed: 73 ins; 8 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8795/head:pull/8795 PR: https://git.openjdk.java.net/jdk/pull/8795 From iklam at openjdk.java.net Thu May 19 20:02:36 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 19 May 2022 20:02:36 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3] In-Reply-To: <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com> References: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com> <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com> Message-ID: On Thu, 19 May 2022 09:06:18 GMT, Severin Gehwolf wrote: >> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 63: >> >>> 61: } else { >>> 62: char *p = strstr(cgroup_path, _root); >>> 63: if (p != NULL && p == cgroup_path) { >> >> What happens if cgroup_path is "/foo/bar" and _root is "/fo"? >> >> Maybe this block should be combined with the new `else` block you're adding? However, the behavior seems opposite between these two blocks of code: >> >> The upper block: _root is a prefix of cgroup_path, we take the **tail** of cgroup_path >> >> >> TestCase substring_match = { >> "/sys/fs/cgroup/memory", // mount_path >> "/user.slice/user-1000.slice", // root_path >> "/user.slice/user-1000.slice/user at 1001.service", // cgroup_path >> "/sys/fs/cgroup/memory/user at 1001.service" // expected_path >> }; >> >> >> The lower block: The beginning of _root is a prefix of cgroup_path, we take the **head** of cgroup_path >> >> >> TestCase prefix_matched_cg = { >> "/sys/fs/cgroup/memory", // mount_path >> "/user.slice/user-1000.slice/session-50.scope", // root_path >> "/user.slice/user-1000.slice/session-3.scope", // cgroup_path >> "/sys/fs/cgroup/memory/user.slice/user-1000.slice" // expected_path >> }; >> >> >> I find the behavior hard to understand. I think the rules (and reasons) should be added to the comment block above the function. > >> What happens if cgroup_path is "/foo/bar" and _root is "/fo"? > > With a mount path of `/bar` this ends up being `/bar/o/bar`. Pretty strange, but then again it's a bit of a contrived example as those paths come from `/proc` parsing. Anyway, this is code that got added with [JDK-8146115](https://bugs.openjdk.java.net/browse/JDK-8146115). It's not something I've written and to be honest, I'm not sure this branch is needed, but I didn't want to change the existing behaviour with this patch. I have no more insight than you in terms of why that approach has been taken. > >> Maybe this block should be combined with the new `else` block you're adding? > > Maybe, but I'm not sure if it would break something. > >> However, the behavior seems opposite between these two blocks of code: >> >> The upper block: _root is a prefix of cgroup_path, we take the **tail** of cgroup_path >> >> ``` >> TestCase substring_match = { >> "/sys/fs/cgroup/memory", // mount_path >> "/user.slice/user-1000.slice", // root_path >> "/user.slice/user-1000.slice/user at 1001.service", // cgroup_path >> "/sys/fs/cgroup/memory/user at 1001.service" // expected_path >> }; >> ``` > > Yes. Though, I cannot comment on why that has been chosen. It's been there since day one :-/ > >> The lower block: The beginning of _root is a prefix of cgroup_path, we take the **head** of cgroup_path >> >> ``` >> TestCase prefix_matched_cg = { >> "/sys/fs/cgroup/memory", // mount_path >> "/user.slice/user-1000.slice/session-50.scope", // root_path >> "/user.slice/user-1000.slice/session-3.scope", // cgroup_path >> "/sys/fs/cgroup/memory/user.slice/user-1000.slice" // expected_path >> }; >> ``` >> >> I find the behavior hard to understand. I think the rules (and reasons) should be added to the comment block above the function. > > The reason why I've gone down the path of adding the head of cgroup_path is because of this document (in conjunction to what the user was observing on an affected system): > https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ > > The user was observing paths as listed in the test: > > "/user.slice/user-1000.slice/session-50.scope", // root_path > "/user.slice/user-1000.slice/session-3.scope", // cgroup_path > > This very much looks like systemd managed. Given that and knowing that systemd adds processes into `scopes` or `services` and groups them via `slices` and also knowing that cgroups are hierarchical (i.e. limits of `/foo/bar` also apply to `/foo/bar/baz`), it seems likely that if there are any limits, then it'll be on `/user.slice/user-1000.slice` within the mounted controller. Unfortunately, I'm not able to reproduce this myself. I am wondering if the problem is this: We have systemd running on the host, and a different copy of systemd that runs inside the container. - They both set up `/user.slice/user-1000.slice/session-??.scope` within their own file systems - For some reason, when you're looking inside the container, `/proc/self/cgroup` might use a path in the containerized file system whereas `/proc/self/mountinfo` uses a path in the host file system. These two paths may look alike but they have absolutely no relation to each other. I have asked the reporter for more information: https://gist.github.com/gaol/4d96eace8290e6549635fdc0ea41d0b4?permalink_comment_id=4172593#gistcomment-4172593 Meanwhile, I think the current method of finding "which directory under /sys/fs/cgroup/memory controls my memory usage" is broken. As mentioned about, the path you get from `/proc/self/cgroup` and `/proc/self/mountinfo` have no relation to each other, but we use them anyway to get our answer, with many ad-hoc methods that are not documented in the code. Maybe we should do this instead? - Read /proc/self/cgroup - Find the `10:memory:` line - If `/sys/fs/cgroup/memory//tasks` contains my PID, this is the path - Otherwise, scan all `tasks` files under `/sys/fs/cgroup/memory/`. Exactly one of them contains my PID. For example, here's a test with docker: INSIDE CONTAINER # cat /proc/self/cgroup | grep memory 10:memory:/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050 # cat /proc/self/mountinfo | grep memory 801 791 0:42 /docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050 /sys/fs/cgroup/memory ro,nosuid,nodev,noexec,relatime master:23 - cgroup cgroup rw,memory # cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks cat: /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks: No such file or directory # cat /sys/fs/cgroup/memory/tasks | grep $$ 1 ON HOST # cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks 37494 # cat /proc/37494/status | grep NSpid NSpid: 37494 1 ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From iklam at openjdk.java.net Thu May 19 20:21:47 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 19 May 2022 20:21:47 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3] In-Reply-To: References: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com> <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com> Message-ID: On Thu, 19 May 2022 19:59:18 GMT, Ioi Lam wrote: >>> What happens if cgroup_path is "/foo/bar" and _root is "/fo"? >> >> With a mount path of `/bar` this ends up being `/bar/o/bar`. Pretty strange, but then again it's a bit of a contrived example as those paths come from `/proc` parsing. Anyway, this is code that got added with [JDK-8146115](https://bugs.openjdk.java.net/browse/JDK-8146115). It's not something I've written and to be honest, I'm not sure this branch is needed, but I didn't want to change the existing behaviour with this patch. I have no more insight than you in terms of why that approach has been taken. >> >>> Maybe this block should be combined with the new `else` block you're adding? >> >> Maybe, but I'm not sure if it would break something. >> >>> However, the behavior seems opposite between these two blocks of code: >>> >>> The upper block: _root is a prefix of cgroup_path, we take the **tail** of cgroup_path >>> >>> ``` >>> TestCase substring_match = { >>> "/sys/fs/cgroup/memory", // mount_path >>> "/user.slice/user-1000.slice", // root_path >>> "/user.slice/user-1000.slice/user at 1001.service", // cgroup_path >>> "/sys/fs/cgroup/memory/user at 1001.service" // expected_path >>> }; >>> ``` >> >> Yes. Though, I cannot comment on why that has been chosen. It's been there since day one :-/ >> >>> The lower block: The beginning of _root is a prefix of cgroup_path, we take the **head** of cgroup_path >>> >>> ``` >>> TestCase prefix_matched_cg = { >>> "/sys/fs/cgroup/memory", // mount_path >>> "/user.slice/user-1000.slice/session-50.scope", // root_path >>> "/user.slice/user-1000.slice/session-3.scope", // cgroup_path >>> "/sys/fs/cgroup/memory/user.slice/user-1000.slice" // expected_path >>> }; >>> ``` >>> >>> I find the behavior hard to understand. I think the rules (and reasons) should be added to the comment block above the function. >> >> The reason why I've gone down the path of adding the head of cgroup_path is because of this document (in conjunction to what the user was observing on an affected system): >> https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ >> >> The user was observing paths as listed in the test: >> >> "/user.slice/user-1000.slice/session-50.scope", // root_path >> "/user.slice/user-1000.slice/session-3.scope", // cgroup_path >> >> This very much looks like systemd managed. Given that and knowing that systemd adds processes into `scopes` or `services` and groups them via `slices` and also knowing that cgroups are hierarchical (i.e. limits of `/foo/bar` also apply to `/foo/bar/baz`), it seems likely that if there are any limits, then it'll be on `/user.slice/user-1000.slice` within the mounted controller. Unfortunately, I'm not able to reproduce this myself. > > I am wondering if the problem is this: > > We have systemd running on the host, and a different copy of systemd that runs inside the container. > > - They both set up `/user.slice/user-1000.slice/session-??.scope` within their own file systems > - For some reason, when you're looking inside the container, `/proc/self/cgroup` might use a path in the containerized file system whereas `/proc/self/mountinfo` uses a path in the host file system. These two paths may look alike but they have absolutely no relation to each other. > > I have asked the reporter for more information: > > https://gist.github.com/gaol/4d96eace8290e6549635fdc0ea41d0b4?permalink_comment_id=4172593#gistcomment-4172593 > > Meanwhile, I think the current method of finding "which directory under /sys/fs/cgroup/memory controls my memory usage" is broken. As mentioned about, the path you get from `/proc/self/cgroup` and `/proc/self/mountinfo` have no relation to each other, but we use them anyway to get our answer, with many ad-hoc methods that are not documented in the code. > > Maybe we should do this instead? > > - Read /proc/self/cgroup > - Find the `10:memory:` line > - If `/sys/fs/cgroup/memory//tasks` contains my PID, this is the path > - Otherwise, scan all `tasks` files under `/sys/fs/cgroup/memory/`. Exactly one of them contains my PID. > > For example, here's a test with docker: > > > INSIDE CONTAINER > # cat /proc/self/cgroup | grep memory > 10:memory:/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050 > # cat /proc/self/mountinfo | grep memory > 801 791 0:42 /docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050 /sys/fs/cgroup/memory ro,nosuid,nodev,noexec,relatime master:23 - cgroup cgroup rw,memory > # cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks > cat: /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks: No such file or directory > # cat /sys/fs/cgroup/memory/tasks | grep $$ > 1 > > ON HOST > # cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks > 37494 > # cat /proc/37494/status | grep NSpid > NSpid: 37494 1 Also, I think the current PR could produce the wrong answer, if systemd is indeed running inside the container, and we have: "/user.slice/user-1000.slice/session-50.scope", // root_path "/user.slice/user-1000.slice/session-3.scope", // cgroup_path The PR gives /sys/fs/cgroup/memory/user.slice/user-1000.slice/, which specifies the overall memory limit for user-1000. However, the correct answer may be /sys/fs/cgroup/memory/user.slice/user-1000.slice/session-3.scope, which may have a smaller memory limit, and the JVM may end up allocating a larger heap than allowed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From ccheung at openjdk.java.net Fri May 20 01:55:14 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 20 May 2022 01:55:14 GMT Subject: RFR: 8286978: SIGBUS in libz during CDS initialization Message-ID: Please review this fix to ensure all requested bytes are transferred by calling `FileChannel.transferFrom` in a loop and checking its return value. Tested by running the SharedArchiveConsistency.java test on linux-aarch64 30 times on each of the following tier3 options: - `-XX:+CreateCoredumpOnCrash -XX:+UseSerialGC ` - `-XX:+CreateCoredumpOnCrash -XX:+UseParallelGC -XX:+UseNUMA` ------------- Commit messages: - 8286978: SIGBUS in libz during CDS initialization Changes: https://git.openjdk.java.net/jdk/pull/8799/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8799&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286978 Stats: 27 lines in 1 file changed: 23 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8799.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8799/head:pull/8799 PR: https://git.openjdk.java.net/jdk/pull/8799 From dholmes at openjdk.java.net Fri May 20 04:27:56 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 20 May 2022 04:27:56 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: On Thu, 19 May 2022 19:17:09 GMT, Patricio Chilano Mateo wrote: > On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. > To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things: > - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state. > - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. > > I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases. > > I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that. > > Thanks, > Patricio src/hotspot/share/runtime/thread.cpp line 1443: > 1441: // we can just put in the exiting state and it will be correctly handled. > 1442: // Also, no more async exceptions will be added to the queue after this point. > 1443: set_terminated(_thread_exiting); I would have expected that cleaning up any async exceptions has to happen after we set the _thread_exiting state; otherwise what happens if another thread is trying to install an async exception on the current thread before we set it? ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From dholmes at openjdk.java.net Fri May 20 04:47:58 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 20 May 2022 04:47:58 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: <1sBgMSLq90h-UruR-GUlJ-r7-znmJ_sp2Wv0RE75IO0=.d999ace9-e506-45bb-89c0-a17ef33ff49c@github.com> On Thu, 19 May 2022 19:17:09 GMT, Patricio Chilano Mateo wrote: > On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. > To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things: > - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state. > - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. > > I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases. > > I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that. > > Thanks, > Patricio Hi Patricio, I still need to find time to look at this in more detail. Things are definitely on the right track but I want to check the details. I still think we should be able to have a simple scheme whereby once the thread is marked as _thread_exiting then it can't engage in further handshakes and so at that point we could explicitly destroy the HandshakeState rather than special casing async exceptions. I'd also like for Dan to see this and he is still away for a while unfortunately. > Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. Why do you think this is necessary? I'm not saying it is incorrect but I'm not sure it is necessary either and the less the termination sequence is perturbed the better. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From ccheung at openjdk.java.net Fri May 20 05:37:27 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 20 May 2022 05:37:27 GMT Subject: RFR: 8286978: SIGBUS in libz during CDS initialization [v2] In-Reply-To: References: Message-ID: > Please review this fix to ensure all requested bytes are transferred by calling `FileChannel.transferFrom` in a loop and checking its return value. > > Tested by running the SharedArchiveConsistency.java test on linux-aarch64 30 times on each of the following tier3 options: > > - `-XX:+CreateCoredumpOnCrash -XX:+UseSerialGC ` > - `-XX:+CreateCoredumpOnCrash -XX:+UseParallelGC -XX:+UseNUMA` Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: corrected the condition of the while loop, removed an unneeded line of code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8799/files - new: https://git.openjdk.java.net/jdk/pull/8799/files/a78672cd..9147888d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8799&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8799&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8799.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8799/head:pull/8799 PR: https://git.openjdk.java.net/jdk/pull/8799 From iklam at openjdk.java.net Fri May 20 06:27:43 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 20 May 2022 06:27:43 GMT Subject: RFR: 8286978: SIGBUS in libz during CDS initialization [v2] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 05:37:27 GMT, Calvin Cheung wrote: >> Please review this fix to ensure all requested bytes are transferred by calling `FileChannel.transferFrom` in a loop and checking its return value. >> >> Tested by running the SharedArchiveConsistency.java test on linux-aarch64 30 times on each of the following tier3 options: >> >> - `-XX:+CreateCoredumpOnCrash -XX:+UseSerialGC ` >> - `-XX:+CreateCoredumpOnCrash -XX:+UseParallelGC -XX:+UseNUMA` > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > corrected the condition of the while loop, removed an unneeded line of code Changes requested by iklam (Reviewer). test/lib/jdk/test/lib/cds/CDSArchiveUtils.java line 440: > 438: transferFrom(inputChannel, outputChannel, 0, offset); > 439: outputChannel.position(offset); > 440: outputChannel.write(ByteBuffer.wrap(bytes)); The changes for transferFrom looks good, but we still have a problem with outputChannel.write(), which can also return fewer bytes than requested (or even zero). For simplicity, I think it's best to ditch FileChannel and use FileOutputStream.write() instead. test/lib/jdk/test/lib/cds/CDSArchiveUtils.java line 458: > 456: transferFrom(inputChannel, outputChannel, 0, offset); > 457: inputChannel.position(offset + nBytes); > 458: long length = orgSize - nBytes; Line 458 doesn't seem to be needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8799 From iklam at openjdk.java.net Fri May 20 14:51:59 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 20 May 2022 14:51:59 GMT Subject: RFR: 8286978: SIGBUS in libz during CDS initialization [v2] In-Reply-To: References: Message-ID: <14fO8vV26ObvLCCUhD8Ksjj5fOXDOb9yzrMTPOAq50A=.c364dba4-3e0d-4aec-b78c-f4b13ef5de56@github.com> On Fri, 20 May 2022 06:23:57 GMT, Ioi Lam wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> corrected the condition of the while loop, removed an unneeded line of code > > test/lib/jdk/test/lib/cds/CDSArchiveUtils.java line 440: > >> 438: transferFrom(inputChannel, outputChannel, 0, offset); >> 439: outputChannel.position(offset); >> 440: outputChannel.write(ByteBuffer.wrap(bytes)); > > The changes for transferFrom looks good, but we still have a problem with outputChannel.write(), which can also return fewer bytes than requested (or even zero). > > For simplicity, I think it's best to ditch FileChannel and use FileOutputStream.write() instead. Another option is to avoid using outputChannel.write(). Instead, duplicate some bytes from the end of the header. public static File insertBytesRandomlyAfterHeader(File orgFile, String newFileName) throws Exception { long headerSize = fileHeaderSize(orgFile); long dupSize = getRandomBetween(0L, headerSize); File dstFile = new File(newFileName); try (FileChannel inputChannel = new FileInputStream(orgFile).getChannel(); FileChannel outputChannel = new FileOutputStream(dstFile).getChannel()) { long orgSize = inputChannel.size(); // Copy the header transferFrom(inputChannel, outputChannel, 0, headerSize); // Copy dupSize bytes from the end of the header. Then, copy the rest // of the input such that the new file will have the same size as // the old file. inputChannel.position(headerSize - dupSize); transferFrom(inputChannel, outputChannel, headerSize, orgSize - headerSize); } return dstFile; } ------------- PR: https://git.openjdk.java.net/jdk/pull/8799 From pchilanomate at openjdk.java.net Fri May 20 16:53:44 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 20 May 2022 16:53:44 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: <95xBsud1dKr1fiOck-80-e64VqByH7ctPfdcAtaRfEU=.8360693e-e898-441d-8255-50712fe459ce@github.com> On Thu, 19 May 2022 19:17:09 GMT, Patricio Chilano Mateo wrote: > On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. > To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things: > - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state. > - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. > > I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases. > > I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that. > > Thanks, > Patricio Hi David, Thanks for taking a look at this. > > I still need to find time to look at this in more detail. Things are definitely on the right track but I want to check the details. I still think we should be able to have a simple scheme whereby once the thread is marked as _thread_exiting then it can't engage in further handshakes and so at that point we could explicitly destroy the HandshakeState rather than special casing async exceptions. > If by "can't engage in further handshakes" you mean to make sure no other handshake closure could be executed against it after moving to _thread_exiting, then yes we can do that. But the queue is lock free for inserts so there could still be some handshaker trying to add an operation to the queue after that, although the closure just won't be executed. That means we know no other ThreadSelfSuspensionHandshake or AsyncExceptionHandshake operation will be added to the queue after _thread_exiting, since those happen inside the closure of a synchronous handshake. But there could still be synchronous operations remaining or about to be added to the queue, again eventhough the closures won't be executed. In fact we could have some other async operation added to the queue after that since they don't necessarily need to be added inside another handshake, but we don't have any of those today. > I'd also like for Dan to see this and he is still away for a while unfortunately. > > > Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. > > Why do you think this is necessary? I'm not saying it is incorrect but I'm not sure it is necessary either and the less the termination sequence is perturbed the better. > We need to guarantee that after the async exception cleanup no other async exception can be installed. The key for that is the is_exiting() check I added in install_async_exception(). But for the destroy_vm=true path case we never set it, so if the exiting thread blocks while trying to acquire the Threads_lock in Threads::remove() for example, we could have a new handshake that installs an async exception. Later in Threads::destroy_vm() we would hit this same issue of touching an oop when doing "delete thread". ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From pchilanomate at openjdk.java.net Fri May 20 16:53:44 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 20 May 2022 16:53:44 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: On Fri, 20 May 2022 04:24:29 GMT, David Holmes wrote: >> On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. >> To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things: >> - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state. >> - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. >> >> I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases. >> >> I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that. >> >> Thanks, >> Patricio > > src/hotspot/share/runtime/thread.cpp line 1443: > >> 1441: // we can just put in the exiting state and it will be correctly handled. >> 1442: // Also, no more async exceptions will be added to the queue after this point. >> 1443: set_terminated(_thread_exiting); > > I would have expected that cleaning up any async exceptions has to happen after we set the _thread_exiting state; otherwise what happens if another thread is trying to install an async exception on the current thread before we set it? The ordering of cleaning up the async exceptions in the queue and the write of _thread_exiting doesn't really matter as long as the state remains _thread_in_vm. We install async exceptions inside a synchronous handshake, which can only happen while the target is handshake/safepoint safe. Since moving to a safe state by the target and reading of the state by the handshaker uses acquire/release semantics, the handshaker will already see the _thread_exiting value inside the handshake. ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From ccheung at openjdk.java.net Fri May 20 17:17:39 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 20 May 2022 17:17:39 GMT Subject: RFR: 8286978: SIGBUS in libz during CDS initialization [v3] In-Reply-To: References: Message-ID: > Please review this fix to ensure all requested bytes are transferred by calling `FileChannel.transferFrom` in a loop and checking its return value. > > Tested by running the SharedArchiveConsistency.java test on linux-aarch64 30 times on each of the following tier3 options: > > - `-XX:+CreateCoredumpOnCrash -XX:+UseSerialGC ` > - `-XX:+CreateCoredumpOnCrash -XX:+UseParallelGC -XX:+UseNUMA` Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: avoid the use of FileChannel.write ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8799/files - new: https://git.openjdk.java.net/jdk/pull/8799/files/9147888d..752e64a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8799&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8799&range=01-02 Stats: 13 lines in 2 files changed: 4 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8799.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8799/head:pull/8799 PR: https://git.openjdk.java.net/jdk/pull/8799 From ccheung at openjdk.java.net Fri May 20 17:23:42 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 20 May 2022 17:23:42 GMT Subject: RFR: 8286978: SIGBUS in libz during CDS initialization [v2] In-Reply-To: <14fO8vV26ObvLCCUhD8Ksjj5fOXDOb9yzrMTPOAq50A=.c364dba4-3e0d-4aec-b78c-f4b13ef5de56@github.com> References: <14fO8vV26ObvLCCUhD8Ksjj5fOXDOb9yzrMTPOAq50A=.c364dba4-3e0d-4aec-b78c-f4b13ef5de56@github.com> Message-ID: On Fri, 20 May 2022 14:48:36 GMT, Ioi Lam wrote: >> test/lib/jdk/test/lib/cds/CDSArchiveUtils.java line 440: >> >>> 438: transferFrom(inputChannel, outputChannel, 0, offset); >>> 439: outputChannel.position(offset); >>> 440: outputChannel.write(ByteBuffer.wrap(bytes)); >> >> The changes for transferFrom looks good, but we still have a problem with outputChannel.write(), which can also return fewer bytes than requested (or even zero). >> >> For simplicity, I think it's best to ditch FileChannel and use FileOutputStream.write() instead. > > Another option is to avoid using outputChannel.write(). Instead, duplicate some bytes from the end of the header. > > > public static File insertBytesRandomlyAfterHeader(File orgFile, String newFileName) throws Exception { > long headerSize = fileHeaderSize(orgFile); > long dupSize = getRandomBetween(0L, headerSize); > File dstFile = new File(newFileName); > try (FileChannel inputChannel = new FileInputStream(orgFile).getChannel(); > FileChannel outputChannel = new FileOutputStream(dstFile).getChannel()) { > long orgSize = inputChannel.size(); > // Copy the header > transferFrom(inputChannel, outputChannel, 0, headerSize); > // Copy dupSize bytes from the end of the header. Then, copy the rest > // of the input such that the new file will have the same size as > // the old file. > inputChannel.position(headerSize - dupSize); > transferFrom(inputChannel, outputChannel, headerSize, orgSize - headerSize); > } > return dstFile; > } Thanks for the suggestions. I've pushed another commit with the above changes. I also changed the callsite in SharedArchiveConsistency.java since there's no need to pass in a byte array. ------------- PR: https://git.openjdk.java.net/jdk/pull/8799 From ccheung at openjdk.java.net Fri May 20 17:23:43 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 20 May 2022 17:23:43 GMT Subject: RFR: 8286978: SIGBUS in libz during CDS initialization [v3] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 02:28:48 GMT, Ioi Lam wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> avoid the use of FileChannel.write > > test/lib/jdk/test/lib/cds/CDSArchiveUtils.java line 458: > >> 456: transferFrom(inputChannel, outputChannel, 0, offset); >> 457: inputChannel.position(offset + nBytes); >> 458: long length = orgSize - nBytes; > > Line 458 doesn't seem to be needed. The line was removed in version v1 https://openjdk.github.io/cr/?repo=jdk&pr=8799&range=01#sdiff-0-test/lib/jdk/test/lib/cds/CDSArchiveUtils.java ------------- PR: https://git.openjdk.java.net/jdk/pull/8799 From iklam at openjdk.java.net Fri May 20 17:31:44 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 20 May 2022 17:31:44 GMT Subject: RFR: 8286978: SIGBUS in libz during CDS initialization [v3] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 17:17:39 GMT, Calvin Cheung wrote: >> Please review this fix to ensure all requested bytes are transferred by calling `FileChannel.transferFrom` in a loop and checking its return value. >> >> Tested by running the SharedArchiveConsistency.java test on linux-aarch64 30 times on each of the following tier3 options: >> >> - `-XX:+CreateCoredumpOnCrash -XX:+UseSerialGC ` >> - `-XX:+CreateCoredumpOnCrash -XX:+UseParallelGC -XX:+UseNUMA` > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > avoid the use of FileChannel.write LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8799 From ccheung at openjdk.java.net Fri May 20 17:55:41 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 20 May 2022 17:55:41 GMT Subject: RFR: 8286978: SIGBUS in libz during CDS initialization [v3] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 17:29:00 GMT, Ioi Lam wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> avoid the use of FileChannel.write > > LGTM Thanks @iklam for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8799 From ccheung at openjdk.java.net Fri May 20 17:55:41 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 20 May 2022 17:55:41 GMT Subject: Integrated: 8286978: SIGBUS in libz during CDS initialization In-Reply-To: References: Message-ID: On Fri, 20 May 2022 01:05:18 GMT, Calvin Cheung wrote: > Please review this fix to ensure all requested bytes are transferred by calling `FileChannel.transferFrom` in a loop and checking its return value. > > Tested by running the SharedArchiveConsistency.java test on linux-aarch64 30 times on each of the following tier3 options: > > - `-XX:+CreateCoredumpOnCrash -XX:+UseSerialGC ` > - `-XX:+CreateCoredumpOnCrash -XX:+UseParallelGC -XX:+UseNUMA` This pull request has now been integrated. Changeset: 087bccfe Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/087bccfe28c03cb714d46b307e276efca11a4315 Stats: 34 lines in 2 files changed: 23 ins; 0 del; 11 mod 8286978: SIGBUS in libz during CDS initialization Reviewed-by: iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/8799 From dholmes at openjdk.java.net Mon May 23 02:41:42 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 23 May 2022 02:41:42 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: <95xBsud1dKr1fiOck-80-e64VqByH7ctPfdcAtaRfEU=.8360693e-e898-441d-8255-50712fe459ce@github.com> References: <95xBsud1dKr1fiOck-80-e64VqByH7ctPfdcAtaRfEU=.8360693e-e898-441d-8255-50712fe459ce@github.com> Message-ID: On Fri, 20 May 2022 16:50:19 GMT, Patricio Chilano Mateo wrote: > But there could still be synchronous operations remaining or about to be added to the queue, again even though the closures won't be executed. In fact we could have some other async operation added to the queue after that Sorry I'm not clear on the exact details. But a handshake requires the target thread to respond to the handshake request (that is afterall the "handshake" part of it). Once a thread starts to exit it will/should no longer respond to any handshake requests (sync or async) so the submitter of such a request must be polling for the target thread to either acknowledge the handshake or else indicate it is exiting; if the latter then the submitter abandons the handshake request because the target is considered dead. Are you saying that the submitter actually installs the op in the target's queue even if never acknowledged by the target (due to it exiting)? ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From dholmes at openjdk.java.net Mon May 23 07:03:56 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 23 May 2022 07:03:56 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v5] In-Reply-To: References: Message-ID: <8xlmmGlUSi0gQwHdjAjm89y8kyGl4zcvPefMfXv7sSY=.c8a657ac-cbba-4393-bd9c-933c2077fee7@github.com> On Wed, 18 May 2022 15:10:07 GMT, Johan Sj?l?n wrote: >> May I please have a review of this PR which adds non-interleaving log streams to UL? >> >> In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. >> >> Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: >> >> 1. `ttyLocker` + `(x)tty` >> Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. >> >> 2. `stringStream` + `outputStream*` >> In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. >> >> Passes tier 1. > > Johan Sj?l?n has updated the pull request incrementally with three additional commits since the last revision: > > - Use unary not instead of comparing to false > - Sort includes > - Style changes The code looks reasonable just reading through the changes, but I'm missing something fundamental here. We have: `class NonInterleavingLogStream : public LogStreamImpl` and `class LogStream : public LogStreamImpl` but I can't tell what makes the former "non-inter-leaving" while the latter is "inter-leaving" , nor do I understand the test cases for these. Thanks. test/hotspot/gtest/logging/test_logStream.cpp line 101: > 99: { > 100: LogStream foo(Log(gc)::info()); > 101: if(foo.is_enabled()) { Style nit: space after "if" please - here and below. ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From yyang at openjdk.java.net Mon May 23 07:37:16 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 23 May 2022 07:37:16 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong Message-ID: It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. Currently, NonHeapUsage = CodeCache + Metaspace + CompressedClassSpace ==> CodeHeap 'non-nmethods' 1532544 (Used) ==> CodeHeap 'profiled nmethods' 0 ==> CodeHeap 'non-profiled nmethods' 13952 ==> Metaspace 506696 ==> Compressed Class Space 43312 init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K) In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be NonHeapUsage = CodeCache + Metaspace. ------------- Commit messages: - 8287135 Calculation of jmm_GetMemoryUsage is wrong Changes: https://git.openjdk.java.net/jdk/pull/8831/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8831&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287135 Stats: 10 lines in 2 files changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8831/head:pull/8831 PR: https://git.openjdk.java.net/jdk/pull/8831 From sgehwolf at openjdk.java.net Mon May 23 09:27:45 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 23 May 2022 09:27:45 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3] In-Reply-To: References: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com> <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com> Message-ID: On Thu, 19 May 2022 20:18:50 GMT, Ioi Lam wrote: >> I am wondering if the problem is this: >> >> We have systemd running on the host, and a different copy of systemd that runs inside the container. >> >> - They both set up `/user.slice/user-1000.slice/session-??.scope` within their own file systems >> - For some reason, when you're looking inside the container, `/proc/self/cgroup` might use a path in the containerized file system whereas `/proc/self/mountinfo` uses a path in the host file system. These two paths may look alike but they have absolutely no relation to each other. >> >> I have asked the reporter for more information: >> >> https://gist.github.com/gaol/4d96eace8290e6549635fdc0ea41d0b4?permalink_comment_id=4172593#gistcomment-4172593 >> >> Meanwhile, I think the current method of finding "which directory under /sys/fs/cgroup/memory controls my memory usage" is broken. As mentioned about, the path you get from `/proc/self/cgroup` and `/proc/self/mountinfo` have no relation to each other, but we use them anyway to get our answer, with many ad-hoc methods that are not documented in the code. >> >> Maybe we should do this instead? >> >> - Read /proc/self/cgroup >> - Find the `10:memory:` line >> - If `/sys/fs/cgroup/memory//tasks` contains my PID, this is the path >> - Otherwise, scan all `tasks` files under `/sys/fs/cgroup/memory/`. Exactly one of them contains my PID. >> >> For example, here's a test with docker: >> >> >> INSIDE CONTAINER >> # cat /proc/self/cgroup | grep memory >> 10:memory:/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050 >> # cat /proc/self/mountinfo | grep memory >> 801 791 0:42 /docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050 /sys/fs/cgroup/memory ro,nosuid,nodev,noexec,relatime master:23 - cgroup cgroup rw,memory >> # cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks >> cat: /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks: No such file or directory >> # cat /sys/fs/cgroup/memory/tasks | grep $$ >> 1 >> >> ON HOST >> # cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks >> 37494 >> # cat /proc/37494/status | grep NSpid >> NSpid: 37494 1 > > Also, I think the current PR could produce the wrong answer, if systemd is indeed running inside the container, and we have: > > > "/user.slice/user-1000.slice/session-50.scope", // root_path > "/user.slice/user-1000.slice/session-3.scope", // cgroup_path > > > The PR gives /sys/fs/cgroup/memory/user.slice/user-1000.slice/, which specifies the overall memory limit for user-1000. However, the correct answer may be /sys/fs/cgroup/memory/user.slice/user-1000.slice/session-3.scope, which may have a smaller memory limit, and the JVM may end up allocating a larger heap than allowed. Yes, if we can decide which one the right file is. This is largely undocumented territory. The correct fix is a) find the correct path to the namespace hierarchy the process is a part of. b) starting at the leaf node, walk up the hierarchy and find the **lowest** limits. Doing this would be very expensive! Aside: Current container detection in the JVM/JDK is notoriously imprecise. It's largely based on common setups (containers like docker). The heuristics assume that memory limits are reported inside the container at the leaf node. If, however, that's not the case, the detected limits will be wrong (it will detect it as unlimited, even though it's - for example - memory constrained at the parent). This can for example be reproduced on a cgroups v2 system with a systemd slice using memory limits. We've worked-around this in OpenJDK for cgroups v1 by https://bugs.openjdk.java.net/browse/JDK-8217338 ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From dholmes at openjdk.java.net Mon May 23 10:01:42 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 23 May 2022 10:01:42 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Mon, 23 May 2022 07:28:41 GMT, Yi Yang wrote: > It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. > > Currently, NonHeapUsage = CodeCache + Metaspace + CompressedClassSpace > > ==> CodeHeap 'non-nmethods' 1532544 (Used) > ==> CodeHeap 'profiled nmethods' 0 > ==> CodeHeap 'non-profiled nmethods' 13952 > ==> Metaspace 506696 > ==> Compressed Class Space 43312 > init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K) > > In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be NonHeapUsage = CodeCache + Metaspace. Sorry but I can't agree with this change as presented. By definition the total non-heap memory is the sum of all pools which identify as non-heap as per the specification: "The non-heap memory consists of one or more memory pools. The used and committed size of the returned memory usage is the sum of those values of all non-heap memory pools ..." so the existing code that sums the non-heap pools is correct. If you think `CompressedClassSpace` should not be counted then you need to argue for it to not be "non-heap". Cheers, David ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8831 From duke at openjdk.java.net Mon May 23 10:24:01 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 23 May 2022 10:24:01 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v5] In-Reply-To: <8xlmmGlUSi0gQwHdjAjm89y8kyGl4zcvPefMfXv7sSY=.c8a657ac-cbba-4393-bd9c-933c2077fee7@github.com> References: <8xlmmGlUSi0gQwHdjAjm89y8kyGl4zcvPefMfXv7sSY=.c8a657ac-cbba-4393-bd9c-933c2077fee7@github.com> Message-ID: On Mon, 23 May 2022 06:47:37 GMT, David Holmes wrote: >> Johan Sj?l?n has updated the pull request incrementally with three additional commits since the last revision: >> >> - Use unary not instead of comparing to false >> - Sort includes >> - Style changes > > test/hotspot/gtest/logging/test_logStream.cpp line 101: > >> 99: { >> 100: LogStream foo(Log(gc)::info()); >> 101: if(foo.is_enabled()) { > > Style nit: space after "if" please - here and below. Thank you, fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From duke at openjdk.java.net Mon May 23 10:31:07 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 23 May 2022 10:31:07 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v5] In-Reply-To: <8xlmmGlUSi0gQwHdjAjm89y8kyGl4zcvPefMfXv7sSY=.c8a657ac-cbba-4393-bd9c-933c2077fee7@github.com> References: <8xlmmGlUSi0gQwHdjAjm89y8kyGl4zcvPefMfXv7sSY=.c8a657ac-cbba-4393-bd9c-933c2077fee7@github.com> Message-ID: <3OOl6SMZiqLXRrd7GbR4a89GP9pPPM-mmF48VS_jESs=.f44f40c4-8397-4690-897b-aa0d7c15433a@github.com> On Mon, 23 May 2022 07:00:48 GMT, David Holmes wrote: > The code looks reasonable just reading through the changes, but I'm missing something fundamental here. We have: > > `class NonInterleavingLogStream : public LogStreamImpl` > > and > > `class LogStream : public LogStreamImpl` > > but I can't tell what makes the former "non-inter-leaving" while the latter is "inter-leaving" , nor do I understand the test cases for these. > > Thanks. @dholmes-ora `LogMessageHandle` and `LogTargetHandle` provides different guarantees. The former guarantees that all lines are logged without interleaving and the latter does not guarantee this. The former takes a bit more memory, so it's sometimes preferable to use the latter. The tests `(Non)InterleavingStream` show that the output order differs between the two log streams. For the non-interleaving log stream the `log_info()` calls are all lumped together at the start, because the stream messages will be flushed together. This is not the case for the `InterleavingStream` test where the `log_info()` messages interleave with the stream messages. ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From yyang at openjdk.java.net Mon May 23 11:14:54 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 23 May 2022 11:14:54 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Mon, 23 May 2022 09:58:46 GMT, David Holmes wrote: > Sorry but I can't agree with this change as presented. By definition the total non-heap memory is the sum of all pools which identify as non-heap as per the specification: > > "The non-heap memory consists of one or more memory pools. The used and committed size of the returned memory usage is the sum of those values of all non-heap memory pools ..." > > so the existing code that sums the non-heap pools is correct. If you think `CompressedClassSpace` should not be counted then you need to argue for it to not be "non-heap". > > Cheers, David Hi David, As far as APIs go, nobody wants to count ClassTypeSpace twice(`NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`) when using getNonHeapMemoryUsage. The documentation should be there to explain the API more clearly, rather than guiding how to implement the API. Digging into commit history, I found only CodeHeap was presented as NonHeap pool [originally](https://github.com/kelthuzadx/jdk/blob/ca3a1be3fe174f6e406a0f5f61a77d3d8d4ec4d7/hotspot/src/share/vm/services/memoryPool.cpp) But yes, there is a slightly conflict between API doc and internal implementation. I think there are some possible changes: 1. Tweak API documentation and adopt patch. Clearly document on what NonHeap really is. e.g. it consists of CodeCache + Metaspace. 2. Remove CompressedClassSpacePool. As there is no explicit use for it. Or some other candidates? Looking forward to your suggesstions. ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From pchilanomate at openjdk.java.net Mon May 23 15:31:41 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 23 May 2022 15:31:41 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: <95xBsud1dKr1fiOck-80-e64VqByH7ctPfdcAtaRfEU=.8360693e-e898-441d-8255-50712fe459ce@github.com> Message-ID: On Mon, 23 May 2022 02:37:53 GMT, David Holmes wrote: > > But there could still be synchronous operations remaining or about to be added to the queue, again even though the closures won't be executed. In fact we could have some other async operation added to the queue after that > > Sorry I'm not clear on the exact details. But a handshake requires the target thread to respond to the handshake request (that is afterall the "handshake" part of it). Once a thread starts to exit it will/should no longer respond to any handshake requests (sync or async) so the submitter of such a request must be polling for the target thread to either acknowledge the handshake or else indicate it is exiting; if the latter then the submitter abandons the handshake request because the target is considered dead. Are you saying that the submitter actually installs the op in the target's queue even if never acknowledged by the target (due to it exiting)? > Yes, the handshaker just checks if the target is included in the thread list it created. If it is included, it adds the operation to the queue. Then it will loop calling HandshakeState::try_process() until the operation is processed(which doesn't mean the closure will actually be executed). So until the target removes itself form the active threads list new operations could be added to the queue. If we want to avoid that and check the terminated status too then we would need to add extra locking to the add operation, but I don't think that's what we want. ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From iklam at openjdk.java.net Mon May 23 16:28:06 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 23 May 2022 16:28:06 GMT Subject: RFR: 8286277: CDS VerifyError when calling clone() on object array [v3] In-Reply-To: References: Message-ID: > **Problem:** > > When verifying an invokevirtual bytecode that calls a protected method in a superclass of the current class, the verifier requires that the object being invoked must be a subtype of the current class. This prevents invocation of protected methods in an unrelated class. For example, the following is disallowed -- the type `InvokeCloneInvalid` cannot invoke `clone()` on a `String`: > > > super public class InvokeCloneInvalid > version 52:0 > { > public static Method test:"(Ljava/lang/String;)V" > stack 1 locals 1 > { > aload_0; > invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; > return; > } > } > > > However, there's a special case where invoking `Object.clone()` is allowed on all object arrays. Here's an example: > > > super public class InvokeCloneValid > version 52:0 > { > public static Method test:"([Ljava/lang/Object;)V" > stack 1 locals 1 > { > aload_0; > invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; > return; > } > > > Before this PR. the Verifier would first do the assignability check. When a failure is encountered, the Verifier then checks for the special case and ignores the failure accordingly. > > In the above case, the assignability check will fail because the object being invoked (an Object array) is not assignable to the current class (InvokeCloneValid) > > The problem is that CDS remembers all the assignability checks and tries to replay them at runtime. Therefore, it will re-check the assignability of Object Array to InvokeCloneValid, and throw a VerifyError as a result. > > **Proposed Fix** > > In `ClassVerifier::verify_invoke_instructions()`, check the special case first, before doing the assignability check. This way, such invalid-but-ignored assignability checks are no longer performed and thus won't be remembered by CDS. > > **Testing** > > Tiers 1 - 4, plus 3 new test cases. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @calvinccheung review -- fixed alignment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8737/files - new: https://git.openjdk.java.net/jdk/pull/8737/files/a292dc39..7f2e2329 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8737&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8737&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8737.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8737/head:pull/8737 PR: https://git.openjdk.java.net/jdk/pull/8737 From iklam at openjdk.java.net Mon May 23 16:28:10 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 23 May 2022 16:28:10 GMT Subject: RFR: 8286277: CDS VerifyError when calling clone() on object array [v2] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 19:14:12 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding newline at end of file > > Looks good. Just one nit. Thanks @calvinccheung and @dholmes-ora for the review, and @hseigel for confirming the fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/8737 From iklam at openjdk.java.net Mon May 23 16:28:13 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 23 May 2022 16:28:13 GMT Subject: Integrated: 8286277: CDS VerifyError when calling clone() on object array In-Reply-To: References: Message-ID: On Mon, 16 May 2022 22:49:24 GMT, Ioi Lam wrote: > **Problem:** > > When verifying an invokevirtual bytecode that calls a protected method in a superclass of the current class, the verifier requires that the object being invoked must be a subtype of the current class. This prevents invocation of protected methods in an unrelated class. For example, the following is disallowed -- the type `InvokeCloneInvalid` cannot invoke `clone()` on a `String`: > > > super public class InvokeCloneInvalid > version 52:0 > { > public static Method test:"(Ljava/lang/String;)V" > stack 1 locals 1 > { > aload_0; > invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; > return; > } > } > > > However, there's a special case where invoking `Object.clone()` is allowed on all object arrays. Here's an example: > > > super public class InvokeCloneValid > version 52:0 > { > public static Method test:"([Ljava/lang/Object;)V" > stack 1 locals 1 > { > aload_0; > invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; > return; > } > > > Before this PR. the Verifier would first do the assignability check. When a failure is encountered, the Verifier then checks for the special case and ignores the failure accordingly. > > In the above case, the assignability check will fail because the object being invoked (an Object array) is not assignable to the current class (InvokeCloneValid) > > The problem is that CDS remembers all the assignability checks and tries to replay them at runtime. Therefore, it will re-check the assignability of Object Array to InvokeCloneValid, and throw a VerifyError as a result. > > **Proposed Fix** > > In `ClassVerifier::verify_invoke_instructions()`, check the special case first, before doing the assignability check. This way, such invalid-but-ignored assignability checks are no longer performed and thus won't be remembered by CDS. > > **Testing** > > Tiers 1 - 4, plus 3 new test cases. This pull request has now been integrated. Changeset: 646c8aae Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/646c8aaeeccb494c72ff84c6e0f303f790be0ba9 Stats: 348 lines in 7 files changed: 339 ins; 0 del; 9 mod 8286277: CDS VerifyError when calling clone() on object array Reviewed-by: dholmes, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/8737 From gziemski at openjdk.java.net Mon May 23 19:10:08 2022 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 23 May 2022 19:10:08 GMT Subject: RFR: 8261768: SelfDestructTimer should accept seconds Message-ID: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> The Java VM supports a runtime flag called `SelfDestructTimer`, which if used, will automatically terminate the java process using the value, expressed in minutes. This flag is very useful when, for example, working on VM startup performance, as it allows a sampling tool to capture the exact same time interval for clear comparison of before and after optimizations. The only problem is that the minimum value of 1 minutes is a really long time for a computer and any data captured during that minute will have many samples to filter through. This fix allows SelfDestructTimer to accept a fractional value of minutes, which in practical terms allows for values to be expressed as seconds, which allows more flexible control. For example: - `XX:SelfDestructTimer=0.0` means that the feature is **off** (default, unchanged) - `XX:SelfDestructTimer=0.25` means **15 seconds** - `XX:SelfDestructTimer=0.5` means **30 seconds** - `XX:SelfDestructTimer=1.0` means **1 minute** The implementation keeps the old semantics, so that`XX: SelfDestructTimer=1` behavior, for example, is unchanged. ------------- Commit messages: - Extend SelfDestructTimer to accept fractional minutes Changes: https://git.openjdk.java.net/jdk/pull/8849/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8849&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261768 Stats: 7 lines in 2 files changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8849.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8849/head:pull/8849 PR: https://git.openjdk.java.net/jdk/pull/8849 From sgehwolf at openjdk.java.net Mon May 23 19:13:58 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 23 May 2022 19:13:58 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3] In-Reply-To: References: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com> <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com> Message-ID: <3kqALUtVpso2x-3Pv41cTPRvjpXI7_88yFPfj-xmRNg=.143ff56d-ad5a-4ffb-8649-03f9447a9248@github.com> On Mon, 23 May 2022 09:24:19 GMT, Severin Gehwolf wrote: >> Also, I think the current PR could produce the wrong answer, if systemd is indeed running inside the container, and we have: >> >> >> "/user.slice/user-1000.slice/session-50.scope", // root_path >> "/user.slice/user-1000.slice/session-3.scope", // cgroup_path >> >> >> The PR gives /sys/fs/cgroup/memory/user.slice/user-1000.slice/, which specifies the overall memory limit for user-1000. However, the correct answer may be /sys/fs/cgroup/memory/user.slice/user-1000.slice/session-3.scope, which may have a smaller memory limit, and the JVM may end up allocating a larger heap than allowed. > > Yes, if we can decide which one the right file is. This is largely undocumented territory. The correct fix is a) find the correct path to the namespace hierarchy the process is a part of. b) starting at the leaf node, walk up the hierarchy and find the **lowest** limits. Doing this would be very expensive! > > Aside: Current container detection in the JVM/JDK is notoriously imprecise. It's largely based on common setups (containers like docker). The heuristics assume that memory limits are reported inside the container at the leaf node. If, however, that's not the case, the detected limits will be wrong (it will detect it as unlimited, even though it's - for example - memory constrained at the parent). This can for example be reproduced on a cgroups v2 system with a systemd slice using memory limits. We've worked-around this in OpenJDK for cgroups v1 by https://bugs.openjdk.java.net/browse/JDK-8217338 > Maybe we should do this instead? > > * Read /proc/self/cgroup > > * Find the `10:memory:` line > > * If `/sys/fs/cgroup/memory//tasks` contains my PID, this is the path > > * Otherwise, scan all `tasks` files under `/sys/fs/cgroup/memory/`. Exactly one of them contains my PID. Something like that seems most promising, but it would have to be `cgroup.procs` not `tasks` as `tasks` is the task id (i.e. Linux's thread), not the process. We could keep the two common cases as short circuiting. I.e. host and docker cases in the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/8629 From iklam at openjdk.java.net Mon May 23 22:24:24 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 23 May 2022 22:24:24 GMT Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller Message-ID: This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode. The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1). However, the "hybrid checks" only considers the following controllers that Java cares about: - cpu - cpuacct - cpuset - blkio - memory - pids If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert. $ cat /proc/self/cgroup 1:freezer:/ 0::/user.slice/user-1001.slice/session-85.scope The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name). ------------- Commit messages: - 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller Changes: https://git.openjdk.java.net/jdk/pull/8858/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8858&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287107 Stats: 116 lines in 3 files changed: 113 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8858.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8858/head:pull/8858 PR: https://git.openjdk.java.net/jdk/pull/8858 From mseledtsov at openjdk.java.net Mon May 23 23:18:36 2022 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Mon, 23 May 2022 23:18:36 GMT Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller In-Reply-To: References: Message-ID: On Mon, 23 May 2022 22:11:47 GMT, Ioi Lam wrote: > This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode. > > The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1). > > However, the "hybrid checks" only considers the following controllers that Java cares about: > > - cpu > - cpuacct > - cpuset > - blkio > - memory > - pids > > If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert. > > > $ cat /proc/self/cgroup > 1:freezer:/ > 0::/user.slice/user-1001.slice/session-85.scope > > > The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name). Marked as reviewed by mseledtsov (Committer). Change looks good to me. Thanks for the fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/8858 From dholmes at openjdk.java.net Tue May 24 04:29:49 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 May 2022 04:29:49 GMT Subject: RFR: 8261768: SelfDestructTimer should accept seconds In-Reply-To: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> References: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> Message-ID: On Mon, 23 May 2022 16:39:29 GMT, Gerard Ziemski wrote: > it allows a sampling tool to capture the exact same time interval for clear comparison Not the "exact same time interval". This will be polled every GuaranteedSafepointInterval milliseconds in a quiescent VM, but otherwise it will depend on the VM operations being executed. When the self-destruct interval is in minutes this difference is in the noise, but if you try to make it too short then it could affect what you are trying to measure. ------------- PR: https://git.openjdk.java.net/jdk/pull/8849 From dholmes at openjdk.java.net Tue May 24 04:33:55 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 May 2022 04:33:55 GMT Subject: RFR: 8261768: SelfDestructTimer should accept seconds In-Reply-To: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> References: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> Message-ID: On Mon, 23 May 2022 16:39:29 GMT, Gerard Ziemski wrote: > The Java VM supports a runtime flag called `SelfDestructTimer`, which if used, will automatically terminate the java process using the value, expressed in minutes. > > This flag is very useful when, for example, working on VM startup performance, as it allows a sampling tool to capture the exact same time interval for clear comparison of before and after optimizations. > > The only problem is that the minimum value of 1 minutes is a really long time for a computer and any data captured during that minute will have many samples to filter through. > > This fix allows SelfDestructTimer to accept a fractional value of minutes, which in practical terms allows for values to be expressed as seconds, which allows more flexible control. > > For example: > > - `XX:SelfDestructTimer=0.0` means that the feature is **off** (default, unchanged) > - `XX:SelfDestructTimer=0.25` means **15 seconds** > - `XX:SelfDestructTimer=0.5` means **30 seconds** > - `XX:SelfDestructTimer=1.0` means **1 minute** > > The implementation keeps the old semantics, so that`XX: SelfDestructTimer=1` behavior, for example, is unchanged. I'm on the fence as to whether this needs a CSR request. It does change a product flag but not in a way that any current uses of the flag would notice - I'm assuming that setting to 0 rather than 0.0 still turns it off? ------------- PR: https://git.openjdk.java.net/jdk/pull/8849 From dholmes at openjdk.java.net Tue May 24 04:37:54 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 May 2022 04:37:54 GMT Subject: RFR: 8261768: SelfDestructTimer should accept seconds In-Reply-To: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> References: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> Message-ID: On Mon, 23 May 2022 16:39:29 GMT, Gerard Ziemski wrote: > The Java VM supports a runtime flag called `SelfDestructTimer`, which if used, will automatically terminate the java process using the value, expressed in minutes. > > This flag is very useful when, for example, working on VM startup performance, as it allows a sampling tool to capture the exact same time interval for clear comparison of before and after optimizations. > > The only problem is that the minimum value of 1 minutes is a really long time for a computer and any data captured during that minute will have many samples to filter through. > > This fix allows SelfDestructTimer to accept a fractional value of minutes, which in practical terms allows for values to be expressed as seconds, which allows more flexible control. > > For example: > > - `XX:SelfDestructTimer=0.0` means that the feature is **off** (default, unchanged) > - `XX:SelfDestructTimer=0.25` means **15 seconds** > - `XX:SelfDestructTimer=0.5` means **30 seconds** > - `XX:SelfDestructTimer=1.0` means **1 minute** > > The implementation keeps the old semantics, so that`XX: SelfDestructTimer=1` behavior, for example, is unchanged. Code changes seem fine. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8849 From stuefe at openjdk.java.net Tue May 24 04:49:55 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 24 May 2022 04:49:55 GMT Subject: RFR: 8261768: SelfDestructTimer should accept seconds In-Reply-To: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> References: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> Message-ID: <9II08PXnghOGZp6NP7FLAp1tiFMs99yipWZt5vaaBL4=.a5692f7b-971a-496d-b529-7027c8d88985@github.com> On Mon, 23 May 2022 16:39:29 GMT, Gerard Ziemski wrote: > The Java VM supports a runtime flag called `SelfDestructTimer`, which if used, will automatically terminate the java process using the value, expressed in minutes. > > This flag is very useful when, for example, working on VM startup performance, as it allows a sampling tool to capture the exact same time interval for clear comparison of before and after optimizations. > > The only problem is that the minimum value of 1 minutes is a really long time for a computer and any data captured during that minute will have many samples to filter through. > > This fix allows SelfDestructTimer to accept a fractional value of minutes, which in practical terms allows for values to be expressed as seconds, which allows more flexible control. > > For example: > > - `XX:SelfDestructTimer=0.0` means that the feature is **off** (default, unchanged) > - `XX:SelfDestructTimer=0.25` means **15 seconds** > - `XX:SelfDestructTimer=0.5` means **30 seconds** > - `XX:SelfDestructTimer=1.0` means **1 minute** > > The implementation keeps the old semantics, so that`XX: SelfDestructTimer=1` behavior, for example, is unchanged. Looks good. I'm surprised this is a product flag and not diagnostic. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8849 From dholmes at openjdk.java.net Tue May 24 05:05:47 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 May 2022 05:05:47 GMT Subject: RFR: 8261768: SelfDestructTimer should accept seconds In-Reply-To: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> References: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> Message-ID: On Mon, 23 May 2022 16:39:29 GMT, Gerard Ziemski wrote: > The Java VM supports a runtime flag called `SelfDestructTimer`, which if used, will automatically terminate the java process using the value, expressed in minutes. > > This flag is very useful when, for example, working on VM startup performance, as it allows a sampling tool to capture the exact same time interval for clear comparison of before and after optimizations. > > The only problem is that the minimum value of 1 minutes is a really long time for a computer and any data captured during that minute will have many samples to filter through. > > This fix allows SelfDestructTimer to accept a fractional value of minutes, which in practical terms allows for values to be expressed as seconds, which allows more flexible control. > > For example: > > - `XX:SelfDestructTimer=0.0` means that the feature is **off** (default, unchanged) > - `XX:SelfDestructTimer=0.25` means **15 seconds** > - `XX:SelfDestructTimer=0.5` means **30 seconds** > - `XX:SelfDestructTimer=1.0` means **1 minute** > > The implementation keeps the old semantics, so that`XX: SelfDestructTimer=1` behavior, for example, is unchanged. This is a very old flag that predates diagnostic flags. :) Changing it to diagnostic would not be unreasonable IMO but a separate RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/8849 From dholmes at openjdk.java.net Tue May 24 07:02:49 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 May 2022 07:02:49 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v5] In-Reply-To: References: <8xlmmGlUSi0gQwHdjAjm89y8kyGl4zcvPefMfXv7sSY=.c8a657ac-cbba-4393-bd9c-933c2077fee7@github.com> Message-ID: On Mon, 23 May 2022 10:20:09 GMT, Johan Sj?l?n wrote: >> test/hotspot/gtest/logging/test_logStream.cpp line 101: >> >>> 99: { >>> 100: LogStream foo(Log(gc)::info()); >>> 101: if(foo.is_enabled()) { >> >> Style nit: space after "if" please - here and below. > > Thank you, fixed. I don't see it fixed :) ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From dholmes at openjdk.java.net Tue May 24 07:06:39 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 May 2022 07:06:39 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v5] In-Reply-To: References: Message-ID: <_pPak6FMPZ_zGRtO4Fe7uVQ-hDFfiv9UNz6D6wBQl54=.0fea1522-e524-4832-855c-f8514ad8ca36@github.com> On Wed, 18 May 2022 15:10:07 GMT, Johan Sj?l?n wrote: >> May I please have a review of this PR which adds non-interleaving log streams to UL? >> >> In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. >> >> Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: >> >> 1. `ttyLocker` + `(x)tty` >> Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. >> >> 2. `stringStream` + `outputStream*` >> In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. >> >> Passes tier 1. > > Johan Sj?l?n has updated the pull request incrementally with three additional commits since the last revision: > > - Use unary not instead of comparing to false > - Sort includes > - Style changes Thanks - The relationship and difference between a LogMessage and a LogTarget are not clear. It sounds like a LogMessage is just a buffering LogTarget - is that accurate? Or perhaps that a LogMessage accumulates logging output for later dump to a LogTarget? I understand the tests now - thanks - I would hope no real code switches between those different logging techniques. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From dholmes at openjdk.java.net Tue May 24 07:11:46 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 May 2022 07:11:46 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v5] In-Reply-To: References: Message-ID: <2wJ3FaXHhpt1AgtmyZhFBB5H9ipvD0hdnpm8MKUgSu8=.62eae85f-0d03-4ba6-85f4-27140807f694@github.com> On Wed, 18 May 2022 15:10:07 GMT, Johan Sj?l?n wrote: >> May I please have a review of this PR which adds non-interleaving log streams to UL? >> >> In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. >> >> Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: >> >> 1. `ttyLocker` + `(x)tty` >> Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. >> >> 2. `stringStream` + `outputStream*` >> In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. >> >> Passes tier 1. > > Johan Sj?l?n has updated the pull request incrementally with three additional commits since the last revision: > > - Use unary not instead of comparing to false > - Sort includes > - Style changes src/hotspot/share/logging/logStream.hpp line 160: > 158: const size_t minimum_capacity_needed = _pos + len + 1; > 159: try_ensure_cap(minimum_capacity_needed); > 160: // try_ensure_cap may not have enlarged the capacity to the full requested Would it be worth having `try_ensure_cap` return a boolean to indicate whether it was able to expand to the size requested? ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From sgehwolf at openjdk.java.net Tue May 24 10:26:01 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 24 May 2022 10:26:01 GMT Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller In-Reply-To: References: Message-ID: On Mon, 23 May 2022 22:11:47 GMT, Ioi Lam wrote: > This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode. > > The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1). > > However, the "hybrid checks" only considers the following controllers that Java cares about: > > - cpu > - cpuacct > - cpuset > - blkio > - memory > - pids > > If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert. > > > $ cat /proc/self/cgroup > 1:freezer:/ > 0::/user.slice/user-1001.slice/session-85.scope > > > The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name). src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 155: > 153: // There are some controllers (such as freezer) that Java doesn't > 154: // care about. Just ignore them. These are not considered in the > 155: // anyCgroupsV1Controller/anyCgroupsV1Controller checks. It's not clear why this `default` is necessary. Could we just add the comment like so: // Intentional fall-through. There are controllers (such as freezer) that // Java doesn't care about. Just ignore them. Only listed controllers are // considered in the anyCgroupsV1Controller/anyCgroupsV2Controller checks. src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 229: > 227: String name = tokens[1]; > 228: if (!name.equals("")) { > 229: // This is probably a v1 controller that we have ignored (e.g., freezer) Could we add an assertion that the controller isn't in the `infos` map? if (!name.equals("")) { // This must be a v1 controller that we have ignored (e.g., freezer) assert infos.get(name) == null; return; } ------------- PR: https://git.openjdk.java.net/jdk/pull/8858 From duke at openjdk.java.net Tue May 24 11:17:33 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Tue, 24 May 2022 11:17:33 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v6] In-Reply-To: References: Message-ID: > May I please have a review of this PR which adds non-interleaving log streams to UL? > > In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. > > Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: > > 1. `ttyLocker` + `(x)tty` > Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. > > 2. `stringStream` + `outputStream*` > In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. > > Passes tier 1. Johan Sj?l?n has updated the pull request incrementally with three additional commits since the last revision: - Minor style fixes - Call renamed function - Fix indentation nit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8748/files - new: https://git.openjdk.java.net/jdk/pull/8748/files/c04e06be..a8832d74 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=04-05 Stats: 10 lines in 3 files changed: 2 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8748/head:pull/8748 PR: https://git.openjdk.java.net/jdk/pull/8748 From duke at openjdk.java.net Tue May 24 11:17:34 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Tue, 24 May 2022 11:17:34 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v5] In-Reply-To: References: <8xlmmGlUSi0gQwHdjAjm89y8kyGl4zcvPefMfXv7sSY=.c8a657ac-cbba-4393-bd9c-933c2077fee7@github.com> Message-ID: On Tue, 24 May 2022 06:59:23 GMT, David Holmes wrote: >> Thank you, fixed. > > I don't see it fixed :) My bad, the changes are pushed now :). ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From duke at openjdk.java.net Tue May 24 13:45:35 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Tue, 24 May 2022 13:45:35 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v7] In-Reply-To: References: Message-ID: <92sdixb1CgHJYSyazuObfxXtI_sU7NJXJYCZhJquABA=.0ca27862-63a0-4687-ab55-bb4189726019@github.com> > May I please have a review of this PR which adds non-interleaving log streams to UL? > > In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. > > Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: > > 1. `ttyLocker` + `(x)tty` > Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. > > 2. `stringStream` + `outputStream*` > In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. > > Passes tier 1. Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Refactor try_ensure_cap ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8748/files - new: https://git.openjdk.java.net/jdk/pull/8748/files/a8832d74..f3718ccb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=05-06 Stats: 46 lines in 1 file changed: 12 ins; 7 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/8748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8748/head:pull/8748 PR: https://git.openjdk.java.net/jdk/pull/8748 From duke at openjdk.java.net Tue May 24 13:45:36 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Tue, 24 May 2022 13:45:36 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v5] In-Reply-To: <2wJ3FaXHhpt1AgtmyZhFBB5H9ipvD0hdnpm8MKUgSu8=.62eae85f-0d03-4ba6-85f4-27140807f694@github.com> References: <2wJ3FaXHhpt1AgtmyZhFBB5H9ipvD0hdnpm8MKUgSu8=.62eae85f-0d03-4ba6-85f4-27140807f694@github.com> Message-ID: On Tue, 24 May 2022 07:08:15 GMT, David Holmes wrote: >> Johan Sj?l?n has updated the pull request incrementally with three additional commits since the last revision: >> >> - Use unary not instead of comparing to false >> - Sort includes >> - Style changes > > src/hotspot/share/logging/logStream.hpp line 160: > >> 158: const size_t minimum_capacity_needed = _pos + len + 1; >> 159: try_ensure_cap(minimum_capacity_needed); >> 160: // try_ensure_cap may not have enlarged the capacity to the full requested > > Would it be worth having `try_ensure_cap` return a boolean to indicate whether it was able to expand to the size requested? I did this and also took the time to refactor `try_ensure_cap`, I think it reads more easily now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From gziemski at openjdk.java.net Tue May 24 15:46:46 2022 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 24 May 2022 15:46:46 GMT Subject: RFR: 8261768: SelfDestructTimer should accept seconds In-Reply-To: References: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> Message-ID: On Tue, 24 May 2022 04:30:33 GMT, David Holmes wrote: > I'm on the fence as to whether this needs a CSR request. It does change a product flag but not in a way that any current uses of the flag would notice - I'm assuming that setting to 0 rather than 0.0 still turns it off? In JDK-8261768 I listed 3 different ways of implementing this. In the end I decided to go with this way, primarily because I was hoping that CSR would not be needed if I do it like this. The semantics did not change, i.e. XX:SelfDestructTimer=0.0 means the same as XX:SelfDestructTimer=0, whose behavior remains unchanged. This enhancement, however, would probably benefit from a release note blurb. ------------- PR: https://git.openjdk.java.net/jdk/pull/8849 From gziemski at openjdk.java.net Tue May 24 15:46:47 2022 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 24 May 2022 15:46:47 GMT Subject: RFR: 8261768: SelfDestructTimer should accept seconds In-Reply-To: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> References: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> Message-ID: On Mon, 23 May 2022 16:39:29 GMT, Gerard Ziemski wrote: > The Java VM supports a runtime flag called `SelfDestructTimer`, which if used, will automatically terminate the java process using the value, expressed in minutes. > > This flag is very useful when, for example, working on VM startup performance, as it allows a sampling tool to capture the exact same time interval for clear comparison of before and after optimizations. > > The only problem is that the minimum value of 1 minutes is a really long time for a computer and any data captured during that minute will have many samples to filter through. > > This fix allows SelfDestructTimer to accept a fractional value of minutes, which in practical terms allows for values to be expressed as seconds, which allows more flexible control. > > For example: > > - `XX:SelfDestructTimer=0.0` means that the feature is **off** (default, unchanged) > - `XX:SelfDestructTimer=0.25` means **15 seconds** > - `XX:SelfDestructTimer=0.5` means **30 seconds** > - `XX:SelfDestructTimer=1.0` means **1 minute** > > The implementation keeps the old semantics, so that`XX: SelfDestructTimer=1` behavior, for example, is unchanged. Thank you David, Thomas for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/8849 From iklam at openjdk.java.net Tue May 24 16:15:03 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 24 May 2022 16:15:03 GMT Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v2] In-Reply-To: References: Message-ID: > This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode. > > The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1). > > However, the "hybrid checks" only considers the following controllers that Java cares about: > > - cpu > - cpuacct > - cpuset > - blkio > - memory > - pids > > If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert. > > > $ cat /proc/self/cgroup > 1:freezer:/ > 0::/user.slice/user-1001.slice/session-85.scope > > > The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @jerboaa comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8858/files - new: https://git.openjdk.java.net/jdk/pull/8858/files/c4d8354d..1f17b6e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8858&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8858&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8858.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8858/head:pull/8858 PR: https://git.openjdk.java.net/jdk/pull/8858 From iklam at openjdk.java.net Tue May 24 16:15:06 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 24 May 2022 16:15:06 GMT Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v2] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 10:12:31 GMT, Severin Gehwolf wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @jerboaa comments > > src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 155: > >> 153: // There are some controllers (such as freezer) that Java doesn't >> 154: // care about. Just ignore them. These are not considered in the >> 155: // anyCgroupsV1Controller/anyCgroupsV1Controller checks. > > It's not clear why this `default` is necessary. Could we just add the comment like so: > > > // Intentional fall-through. There are controllers (such as freezer) that > // Java doesn't care about. Just ignore them. Only listed controllers are > // considered in the anyCgroupsV1Controller/anyCgroupsV2Controller checks. This is not a fall-through because the previous line ends with a `break`. > src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 229: > >> 227: String name = tokens[1]; >> 228: if (!name.equals("")) { >> 229: // This is probably a v1 controller that we have ignored (e.g., freezer) > > Could we add an assertion that the controller isn't in the `infos` map? > > if (!name.equals("")) { > // This must be a v1 controller that we have ignored (e.g., freezer) > assert infos.get(name) == null; > return; > } Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8858 From duke at openjdk.java.net Tue May 24 16:29:04 2022 From: duke at openjdk.java.net (duke) Date: Tue, 24 May 2022 16:29:04 GMT Subject: Withdrawn: 8280928: os::Linux::get_tick_information is inaccurate if the guest fields are non-zero In-Reply-To: References: Message-ID: <2JXdpCNwMMTeLEwG6AtV2mEP9MxTgjeusYnPDHSsB1E=.2a7f925e-0ea6-4343-8ec4-7552b303158b@github.com> On Tue, 1 Feb 2022 12:46:10 GMT, Mitsuru Kariya wrote: > Removed `guestNiceTicks` from `os::Linux::get_tick_information` because the guest field in `/proc/stat` is already added to the user field in `/proc/stat` inside the linux kernel. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7303 From sgehwolf at openjdk.java.net Tue May 24 19:39:01 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 24 May 2022 19:39:01 GMT Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v2] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 16:15:03 GMT, Ioi Lam wrote: >> This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode. >> >> The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1). >> >> However, the "hybrid checks" only considers the following controllers that Java cares about: >> >> - cpu >> - cpuacct >> - cpuset >> - blkio >> - memory >> - pids >> >> If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert. >> >> >> $ cat /proc/self/cgroup >> 1:freezer:/ >> 0::/user.slice/user-1001.slice/session-85.scope >> >> >> The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @jerboaa comments Looks good. Thanks for the thorough analysis. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8858 From sgehwolf at openjdk.java.net Tue May 24 19:39:04 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 24 May 2022 19:39:04 GMT Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v2] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 16:09:54 GMT, Ioi Lam wrote: >> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 155: >> >>> 153: // There are some controllers (such as freezer) that Java doesn't >>> 154: // care about. Just ignore them. These are not considered in the >>> 155: // anyCgroupsV1Controller/anyCgroupsV1Controller checks. >> >> It's not clear why this `default` is necessary. Could we just add the comment like so: >> >> >> // Intentional fall-through. There are controllers (such as freezer) that >> // Java doesn't care about. Just ignore them. Only listed controllers are >> // considered in the anyCgroupsV1Controller/anyCgroupsV2Controller checks. > > This is not a fall-through because the previous line ends with a `break`. My bad. How about `Intentional incomplete switch. There are ...`? Anyway, why is the empty `default` case needed other than for the comment? ------------- PR: https://git.openjdk.java.net/jdk/pull/8858 From iklam at openjdk.java.net Tue May 24 21:13:05 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 24 May 2022 21:13:05 GMT Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v2] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 19:34:16 GMT, Severin Gehwolf wrote: >> This is not a fall-through because the previous line ends with a `break`. > > My bad. How about `Intentional incomplete switch. There are ...`? Anyway, why is the empty `default` case needed other than for the comment? To me, the `default:` switch is a clear indication that "everything else comes here". So you won't be confused whether the comment is related to the last line just above the comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/8858 From dholmes at openjdk.java.net Wed May 25 06:15:40 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 25 May 2022 06:15:40 GMT Subject: RFR: 8261768: SelfDestructTimer should accept seconds In-Reply-To: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> References: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> Message-ID: On Mon, 23 May 2022 16:39:29 GMT, Gerard Ziemski wrote: > The Java VM supports a runtime flag called `SelfDestructTimer`, which if used, will automatically terminate the java process using the value, expressed in minutes. > > This flag is very useful when, for example, working on VM startup performance, as it allows a sampling tool to capture the exact same time interval for clear comparison of before and after optimizations. > > The only problem is that the minimum value of 1 minutes is a really long time for a computer and any data captured during that minute will have many samples to filter through. > > This fix allows SelfDestructTimer to accept a fractional value of minutes, which in practical terms allows for values to be expressed as seconds, which allows more flexible control. > > For example: > > - `XX:SelfDestructTimer=0.0` means that the feature is **off** (default, unchanged) > - `XX:SelfDestructTimer=0.25` means **15 seconds** > - `XX:SelfDestructTimer=0.5` means **30 seconds** > - `XX:SelfDestructTimer=1.0` means **1 minute** > > The implementation keeps the old semantics, so that`XX: SelfDestructTimer=1` behavior, for example, is unchanged. This is essentially an undocumented flag so not Release Note worthy. ------------- PR: https://git.openjdk.java.net/jdk/pull/8849 From dholmes at openjdk.java.net Wed May 25 06:31:03 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 25 May 2022 06:31:03 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v7] In-Reply-To: <92sdixb1CgHJYSyazuObfxXtI_sU7NJXJYCZhJquABA=.0ca27862-63a0-4687-ab55-bb4189726019@github.com> References: <92sdixb1CgHJYSyazuObfxXtI_sU7NJXJYCZhJquABA=.0ca27862-63a0-4687-ab55-bb4189726019@github.com> Message-ID: On Tue, 24 May 2022 13:45:35 GMT, Johan Sj?l?n wrote: >> May I please have a review of this PR which adds non-interleaving log streams to UL? >> >> In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. >> >> Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: >> >> 1. `ttyLocker` + `(x)tty` >> Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. >> >> 2. `stringStream` + `outputStream*` >> In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. >> >> Passes tier 1. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Refactor try_ensure_cap Nothing further from me. This all seems okay. Need a second reviewer of course. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8748 From sgehwolf at openjdk.java.net Wed May 25 08:43:50 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 25 May 2022 08:43:50 GMT Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v2] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 19:49:35 GMT, Ioi Lam wrote: >> My bad. How about `Intentional incomplete switch. There are ...`? Anyway, why is the empty `default` case needed other than for the comment? > > To me, the `default:` switch is a clear indication that "everything else comes here". So you won't be confused whether the comment is related to the last line just above the comment. It confused me, fwiw. Anyway up to you. It's not super important. ------------- PR: https://git.openjdk.java.net/jdk/pull/8858 From stefank at openjdk.java.net Wed May 25 13:17:00 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 25 May 2022 13:17:00 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v7] In-Reply-To: <92sdixb1CgHJYSyazuObfxXtI_sU7NJXJYCZhJquABA=.0ca27862-63a0-4687-ab55-bb4189726019@github.com> References: <92sdixb1CgHJYSyazuObfxXtI_sU7NJXJYCZhJquABA=.0ca27862-63a0-4687-ab55-bb4189726019@github.com> Message-ID: On Tue, 24 May 2022 13:45:35 GMT, Johan Sj?l?n wrote: >> May I please have a review of this PR which adds non-interleaving log streams to UL? >> >> In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. >> >> Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: >> >> 1. `ttyLocker` + `(x)tty` >> Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. >> >> 2. `stringStream` + `outputStream*` >> In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. >> >> Passes tier 1. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Refactor try_ensure_cap I propose a few changes to this: 1) Move the non-trivial implementation to logStream.cpp 2) Move non-template code to a *Base class 3) Smaller style changes https://github.com/stefank/jdk/tree/pr_8748 ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From duke at openjdk.java.net Wed May 25 13:24:50 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 25 May 2022 13:24:50 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v8] In-Reply-To: References: Message-ID: > May I please have a review of this PR which adds non-interleaving log streams to UL? > > In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. > > Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: > > 1. `ttyLocker` + `(x)tty` > Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. > > 2. `stringStream` + `outputStream*` > In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. > > Passes tier 1. Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision: - Update full name - Review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8748/files - new: https://git.openjdk.java.net/jdk/pull/8748/files/f3718ccb..0809969f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=06-07 Stats: 242 lines in 2 files changed: 133 ins; 104 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8748/head:pull/8748 PR: https://git.openjdk.java.net/jdk/pull/8748 From duke at openjdk.java.net Wed May 25 13:24:50 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 25 May 2022 13:24:50 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v7] In-Reply-To: References: <92sdixb1CgHJYSyazuObfxXtI_sU7NJXJYCZhJquABA=.0ca27862-63a0-4687-ab55-bb4189726019@github.com> Message-ID: On Wed, 25 May 2022 13:13:12 GMT, Stefan Karlsson wrote: > I propose a few changes to this: > > 1. Move the non-trivial implementation to logStream.cpp > > 2. Move non-template code to a *Base class > > 3. Smaller style changes > > > https://github.com/stefank/jdk/tree/pr_8748 LGTM, thank you for taking a look at this. ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From duke at openjdk.java.net Wed May 25 13:28:45 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 25 May 2022 13:28:45 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v9] In-Reply-To: References: Message-ID: > May I please have a review of this PR which adds non-interleaving log streams to UL? > > In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. > > Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: > > 1. `ttyLocker` + `(x)tty` > Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. > > 2. `stringStream` + `outputStream*` > In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. > > Passes tier 1. Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Update full name ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8748/files - new: https://git.openjdk.java.net/jdk/pull/8748/files/0809969f..f267bd45 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=07-08 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8748/head:pull/8748 PR: https://git.openjdk.java.net/jdk/pull/8748 From sgehwolf at openjdk.java.net Wed May 25 15:53:20 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 25 May 2022 15:53:20 GMT Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v3] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 08:40:48 GMT, Severin Gehwolf wrote: >> If you don't like the `default:` coding style, how about this: >> >> >> switch (info.getName()) { >> // Only the following controllers are important to Java. All >> // other controllers (such as freezer) are ignored and >> // are not considered in the checks below for >> // anyCgroupsV1Controller/anyCgroupsV1Controller. >> case CPU_CTRL: infos.put(CPU_CTRL, info); break; >> case CPUACCT_CTRL: infos.put(CPUACCT_CTRL, info); break; >> case CPUSET_CTRL: infos.put(CPUSET_CTRL, info); break; >> case MEMORY_CTRL: infos.put(MEMORY_CTRL, info); break; >> case BLKIO_CTRL: infos.put(BLKIO_CTRL, info); break; >> case PIDS_CTRL: infos.put(PIDS_CTRL, info); break; >> } > > It confused me, fwiw. Anyway up to you. It's not super important. works for me. +1. Note the typo `anyCgroupsV1Controller/anyCgroupsV2Controller` not **V1** twice. ------------- PR: https://git.openjdk.java.net/jdk/pull/8858 From iklam at openjdk.java.net Wed May 25 15:51:04 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 25 May 2022 15:51:04 GMT Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v3] In-Reply-To: References: Message-ID: > This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode. > > The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1). > > However, the "hybrid checks" only considers the following controllers that Java cares about: > > - cpu > - cpuacct > - cpuset > - blkio > - memory > - pids > > If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert. > > > $ cat /proc/self/cgroup > 1:freezer:/ > 0::/user.slice/user-1001.slice/session-85.scope > > > The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8858/files - new: https://git.openjdk.java.net/jdk/pull/8858/files/1f17b6e8..9134182e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8858&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8858&range=01-02 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8858.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8858/head:pull/8858 PR: https://git.openjdk.java.net/jdk/pull/8858 From iklam at openjdk.java.net Wed May 25 15:51:06 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 25 May 2022 15:51:06 GMT Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v3] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 19:49:35 GMT, Ioi Lam wrote: >> My bad. How about `Intentional incomplete switch. There are ...`? Anyway, why is the empty `default` case needed other than for the comment? > > To me, the `default:` switch is a clear indication that "everything else comes here". So you won't be confused whether the comment is related to the last line just above the comment. If you don't like the `default:` coding style, how about this: switch (info.getName()) { // Only the following controllers are important to Java. All // other controllers (such as freezer) are ignored and // are not considered in the checks below for // anyCgroupsV1Controller/anyCgroupsV1Controller. case CPU_CTRL: infos.put(CPU_CTRL, info); break; case CPUACCT_CTRL: infos.put(CPUACCT_CTRL, info); break; case CPUSET_CTRL: infos.put(CPUSET_CTRL, info); break; case MEMORY_CTRL: infos.put(MEMORY_CTRL, info); break; case BLKIO_CTRL: infos.put(BLKIO_CTRL, info); break; case PIDS_CTRL: infos.put(PIDS_CTRL, info); break; } ------------- PR: https://git.openjdk.java.net/jdk/pull/8858 From sgehwolf at openjdk.java.net Wed May 25 16:14:50 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 25 May 2022 16:14:50 GMT Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v3] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 15:51:04 GMT, Ioi Lam wrote: >> This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode. >> >> The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1). >> >> However, the "hybrid checks" only considers the following controllers that Java cares about: >> >> - cpu >> - cpuacct >> - cpuset >> - blkio >> - memory >> - pids >> >> If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert. >> >> >> $ cat /proc/self/cgroup >> 1:freezer:/ >> 0::/user.slice/user-1001.slice/session-85.scope >> >> >> The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed comments src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 149: > 147: // other controllers (such as freezer) are ignored and > 148: // are not considered in the checks below for > 149: // anyCgroupsV1Controller/anyCgroupsV1Controller. It still has the `anyCgroupsV1Controller/anyCgroupsV1Controller` typo. Not **V1** twice? ------------- PR: https://git.openjdk.java.net/jdk/pull/8858 From iklam at openjdk.java.net Wed May 25 17:14:28 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 25 May 2022 17:14:28 GMT Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v3] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 15:50:32 GMT, Severin Gehwolf wrote: >> It confused me, fwiw. Anyway up to you. It's not super important. > > works for me. +1. Note the typo `anyCgroupsV1Controller/anyCgroupsV2Controller` not **V1** twice. Oops, I'll fixed that. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8858 From gziemski at openjdk.java.net Wed May 25 17:29:48 2022 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 25 May 2022 17:29:48 GMT Subject: Integrated: 8261768: SelfDestructTimer should accept seconds In-Reply-To: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> References: <-3UPxgjSRI5P0cwwA94CPajNE76lSnvq1AqJntjQj6c=.a52445c3-ed65-4d88-a2d6-3f1957d11c59@github.com> Message-ID: On Mon, 23 May 2022 16:39:29 GMT, Gerard Ziemski wrote: > The Java VM supports a runtime flag called `SelfDestructTimer`, which if used, will automatically terminate the java process using the value, expressed in minutes. > > This flag is very useful when, for example, working on VM startup performance, as it allows a sampling tool to capture the exact same time interval for clear comparison of before and after optimizations. > > The only problem is that the minimum value of 1 minutes is a really long time for a computer and any data captured during that minute will have many samples to filter through. > > This fix allows SelfDestructTimer to accept a fractional value of minutes, which in practical terms allows for values to be expressed as seconds, which allows more flexible control. > > For example: > > - `XX:SelfDestructTimer=0.0` means that the feature is **off** (default, unchanged) > - `XX:SelfDestructTimer=0.25` means **15 seconds** > - `XX:SelfDestructTimer=0.5` means **30 seconds** > - `XX:SelfDestructTimer=1.0` means **1 minute** > > The implementation keeps the old semantics, so that`XX: SelfDestructTimer=1` behavior, for example, is unchanged. This pull request has now been integrated. Changeset: 0b3d4095 Author: Gerard Ziemski URL: https://git.openjdk.java.net/jdk/commit/0b3d409540206bd1bf444ac5183a37c73b957daa Stats: 7 lines in 2 files changed: 1 ins; 0 del; 6 mod 8261768: SelfDestructTimer should accept seconds Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8849 From iklam at openjdk.java.net Wed May 25 23:49:48 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 25 May 2022 23:49:48 GMT Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v4] In-Reply-To: References: Message-ID: > This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode. > > The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1). > > However, the "hybrid checks" only considers the following controllers that Java cares about: > > - cpu > - cpuacct > - cpuset > - blkio > - memory > - pids > > If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert. > > > $ cat /proc/self/cgroup > 1:freezer:/ > 0::/user.slice/user-1001.slice/session-85.scope > > > The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed typo in comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8858/files - new: https://git.openjdk.java.net/jdk/pull/8858/files/9134182e..a13afe47 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8858&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8858&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8858.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8858/head:pull/8858 PR: https://git.openjdk.java.net/jdk/pull/8858 From dholmes at openjdk.java.net Thu May 26 02:25:46 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 26 May 2022 02:25:46 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v9] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 13:28:45 GMT, Johan Sj?l?n wrote: >> May I please have a review of this PR which adds non-interleaving log streams to UL? >> >> In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. >> >> Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: >> >> 1. `ttyLocker` + `(x)tty` >> Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. >> >> 2. `stringStream` + `outputStream*` >> In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. >> >> Passes tier 1. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Update full name No further comments on updates either. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8748 From iklam at openjdk.java.net Thu May 26 04:19:47 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 26 May 2022 04:19:47 GMT Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v2] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 19:36:57 GMT, Severin Gehwolf wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @jerboaa comments > > Looks good. Thanks for the thorough analysis. Thanks @jerboaa and @mseledts for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8858 From iklam at openjdk.java.net Thu May 26 04:19:49 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 26 May 2022 04:19:49 GMT Subject: Integrated: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller In-Reply-To: References: Message-ID: On Mon, 23 May 2022 22:11:47 GMT, Ioi Lam wrote: > This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode. > > The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1). > > However, the "hybrid checks" only considers the following controllers that Java cares about: > > - cpu > - cpuacct > - cpuset > - blkio > - memory > - pids > > If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert. > > > $ cat /proc/self/cgroup > 1:freezer:/ > 0::/user.slice/user-1001.slice/session-85.scope > > > The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name). This pull request has now been integrated. Changeset: 704b9a66 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/704b9a66bba0dc8adb62be80fd62864b9c687c3f Stats: 117 lines in 3 files changed: 114 ins; 0 del; 3 mod 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller Reviewed-by: mseledtsov, sgehwolf ------------- PR: https://git.openjdk.java.net/jdk/pull/8858 From iklam at openjdk.java.net Thu May 26 05:11:35 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 26 May 2022 05:11:35 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Mon, 23 May 2022 07:28:41 GMT, Yi Yang wrote: > It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. > > Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)` > > ==> CodeHeap 'non-nmethods' 1532544 (Used) > ==> CodeHeap 'profiled nmethods' 0 > ==> CodeHeap 'non-profiled nmethods' 13952 > ==> Metaspace 506696 > ==> Compressed Class Space 43312 > init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K) > > In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`. src/hotspot/share/services/management.cpp line 753: > 751: for (int i = 0; i < MemoryService::num_memory_pools(); i++) { > 752: MemoryPool* pool = MemoryService::get_memory_pool(i); > 753: if (pool->is_codeheap() || pool->is_metaspace()) { Our only special case is that all the memory reported by `CompressedKlassSpacePool` are already reported by `MetaspacePool`, so shouldn't we do this: if (pool->is_non_heap() && !pool->is_compressed_klass_space()) { // skip CompressedKlassSpacePool since its memory is already reported by // MetaspacePool ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From iklam at openjdk.java.net Thu May 26 05:58:06 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 26 May 2022 05:58:06 GMT Subject: RFR: 8287352: DockerTestUtils::execute shows incorrect elapsed time Message-ID: Please review this small change to improve the test reporting: - Calculating elapsed time after child process has exited - Do not print `"Child process STDOUT is trimmed ..."` unless the lines are really trimmed. ------------- Commit messages: - 8287352: DockerTestUtils::execute shows incorrect elapsed time Changes: https://git.openjdk.java.net/jdk/pull/8897/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8897&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287352 Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8897.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8897/head:pull/8897 PR: https://git.openjdk.java.net/jdk/pull/8897 From yyang at openjdk.java.net Thu May 26 06:02:42 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 26 May 2022 06:02:42 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Thu, 26 May 2022 05:08:13 GMT, Ioi Lam wrote: >> It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. >> >> Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)` >> >> ==> CodeHeap 'non-nmethods' 1532544 (Used) >> ==> CodeHeap 'profiled nmethods' 0 >> ==> CodeHeap 'non-profiled nmethods' 13952 >> ==> Metaspace 506696 >> ==> Compressed Class Space 43312 >> init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K) >> >> In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`. > > src/hotspot/share/services/management.cpp line 753: > >> 751: for (int i = 0; i < MemoryService::num_memory_pools(); i++) { >> 752: MemoryPool* pool = MemoryService::get_memory_pool(i); >> 753: if (pool->is_codeheap() || pool->is_metaspace()) { > > Our only special case is that all the memory reported by `CompressedKlassSpacePool` are already reported by `MetaspacePool`, so shouldn't we do this: > > > if (pool->is_non_heap() && !pool->is_compressed_klass_space()) { > // skip CompressedKlassSpacePool since its memory is already reported by > // MetaspacePool This is also acceptable, but if we add more memory pools, we might add more special pools to exclude their space from nonheap. Instead, we can specify exactly which pools we need to accumulate, which is what this change did. ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From dholmes at openjdk.java.net Thu May 26 07:06:42 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 26 May 2022 07:06:42 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: On Thu, 19 May 2022 19:17:09 GMT, Patricio Chilano Mateo wrote: > On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. > To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things: > - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state. > - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. > > I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases. > > I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that. > > Thanks, > Patricio Marked as reviewed by dholmes (Reviewer). Hi Patricio, I've had a much closer look at the details and have been surprised at how "loose" the coordination between handshakes and thread termination actually is. It would be good, IMO, if there was a point (like setting is_exiting) where you knew that once that was reached a thread would have zero interaction with handshakes and could delete everything handshake related if you wanted to. The fact that the acquisition of the Threads_lock in Threads::remove might process any handshake certainly complicates things. I think, at a minimum, it would be preferable if we actually checked _is_exiting in that polling/checking logic so that we knew no further handshakes could be executed once _is_exiting is true - rather than placing the check in the operation (e.g. in install_async_exception()). That still relies on your changes for the destroy_vm case of course. So future RFE's aside everything you are doing seems fine and reasonable. Thanks for your patience walking me through this one. ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From dholmes at openjdk.java.net Thu May 26 07:38:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 26 May 2022 07:38:43 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Thu, 26 May 2022 05:59:30 GMT, Yi Yang wrote: >> src/hotspot/share/services/management.cpp line 753: >> >>> 751: for (int i = 0; i < MemoryService::num_memory_pools(); i++) { >>> 752: MemoryPool* pool = MemoryService::get_memory_pool(i); >>> 753: if (pool->is_codeheap() || pool->is_metaspace()) { >> >> Our only special case is that all the memory reported by `CompressedKlassSpacePool` are already reported by `MetaspacePool`, so shouldn't we do this: >> >> >> if (pool->is_non_heap() && !pool->is_compressed_klass_space()) { >> // skip CompressedKlassSpacePool since its memory is already reported by >> // MetaspacePool > > This is also acceptable, but if we add more memory pools, we might add more special pools to exclude their space from nonheap. Instead, we can specify exactly which pools we need to accumulate, which is what this change did. I think the problem is the definition of the pools. We seem to have nested pools but it is far from clear that this API/mechanism was designed/intended to support nested pools. ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From stuefe at openjdk.java.net Thu May 26 09:01:41 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 26 May 2022 09:01:41 GMT Subject: RFR: 8287352: DockerTestUtils::execute shows incorrect elapsed time In-Reply-To: References: Message-ID: On Thu, 26 May 2022 04:55:00 GMT, Ioi Lam wrote: > Please review this small change to improve the test reporting: > > - Calculating elapsed time after child process has exited > - Do not print `"Child process STDOUT is trimmed ..."` unless the lines are really trimmed. Looks good. I was confused btw by the name `trimLines` since that indicates that the lines where whitespace trimmed when in fact it just returns the first n lines from the input. Maybe rename that function? If you do, I don't need another review. Thanks, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8897 From yyang at openjdk.java.net Thu May 26 11:34:48 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 26 May 2022 11:34:48 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Thu, 26 May 2022 07:34:59 GMT, David Holmes wrote: >> This is also acceptable, but if we add more memory pools, we might add more special pools to exclude their space from nonheap. Instead, we can specify exactly which pools we need to accumulate, which is what this change did. > > I think the problem is the definition of the pools. We seem to have nested pools but it is far from clear that this API/mechanism was designed/intended to support nested pools. In any case, it's unreasonable for getNonHeapMemoryUsage to repeatedly count a piece of memory, right? In the extreme case, we might add all nested pools of metaspace, and we will get Metaspace x2 + CodeCache when using getNonHeapMemoryUsage. >From the developer's point of view, MemoryMXBean.getNonHeapMemoryUsage is expected to obtain the size of non-heap area. Given that MemoryMXBean.getHeapMemoryUsage is clearly stated which is heap area: * Returns the current memory usage of the heap that * is used for object allocation. The heap consists * of one or more memory pools. I propose to revise the Java doc to describe the definition of non-heap area more precisely: /** * Returns the current memory usage of non-heap memory that * contains code cache and metaspace. * The non-heap memory consists of one or more memory pools. ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From dholmes at openjdk.java.net Thu May 26 12:51:36 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 26 May 2022 12:51:36 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Thu, 26 May 2022 11:32:46 GMT, Yi Yang wrote: >> I think the problem is the definition of the pools. We seem to have nested pools but it is far from clear that this API/mechanism was designed/intended to support nested pools. > > In any case, it's unreasonable for getNonHeapMemoryUsage to count a piece of memory repeatedly, right? In the extreme case, we might add all nested pools of metaspace, and we will get Metaspace x2 + CodeCache when using getNonHeapMemoryUsage, which should be far beyond what developers expect. In a real scenario, some monitor platforms draw a line chart by collecting getHeapMemoryUsage and getNonHeapMemoryUsage. It's confusing for end-users of the monitor platform to understand why getHeapMemoryUsage is desired while getNonHeapMemoryUsage is bigger than expectation. > > From the developer's point of view, MemoryMXBean.getNonHeapMemoryUsage is expected to obtain the size of non-heap area. Given that MemoryMXBean.getHeapMemoryUsage is clearly stated which is heap area: > > * Returns the current memory usage of the heap that > * is used for object allocation. The heap consists > * of one or more memory pools. > > > I propose to revise the Java doc to describe the definition of non-heap area more precisely: > > /** > * Returns the current memory usage of non-heap memory that > * contains code cache and metaspace. > * The non-heap memory consists of one or more memory pools. No, things like code-cache and metaspace do not get baked into the specification. "non-heap" is deliberately vague and open-ended. I can agree the calculation may be wrong but we need to determine exactly why it is wrong. To me the pool definitions seem wrong - they shouldn't be nested, so then you couldn't double-count. But we really need the experts on this code to chime in. ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From stuefe at openjdk.java.net Thu May 26 13:15:42 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 26 May 2022 13:15:42 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Thu, 26 May 2022 12:47:42 GMT, David Holmes wrote: >> In any case, it's unreasonable for getNonHeapMemoryUsage to count a piece of memory repeatedly, right? In the extreme case, we might add all nested pools of metaspace, and we will get Metaspace x2 + CodeCache when using getNonHeapMemoryUsage, which should be far beyond what developers expect. In a real scenario, some monitor platforms draw a line chart by collecting getHeapMemoryUsage and getNonHeapMemoryUsage. It's confusing for end-users of the monitor platform to understand why getHeapMemoryUsage is desired while getNonHeapMemoryUsage is bigger than expectation. >> >> From the developer's point of view, MemoryMXBean.getNonHeapMemoryUsage is expected to obtain the size of non-heap area. Given that MemoryMXBean.getHeapMemoryUsage is clearly stated which is heap area: >> >> * Returns the current memory usage of the heap that >> * is used for object allocation. The heap consists >> * of one or more memory pools. >> >> >> I propose to revise the Java doc to describe the definition of non-heap area more precisely: >> >> /** >> * Returns the current memory usage of non-heap memory that >> * contains code cache and metaspace. >> * The non-heap memory consists of one or more memory pools. > > No, things like code-cache and metaspace do not get baked into the specification. "non-heap" is deliberately vague and open-ended. > > I can agree the calculation may be wrong but we need to determine exactly why it is wrong. To me the pool definitions seem wrong - they shouldn't be nested, so then you couldn't double-count. But we really need the experts on this code to chime in. Sorry for chiming in in a not very helpful way, but I am not sure what even the point is of this API. I'm seriously interested in who uses it, and for what. Calculating real memory usage is notoriously difficult. This one seems to be just an arbitrary selection of stuff. It leaves out C-heap usage (VM, outer JDK, and third party libs), native mappings, sometimes massive system library overhead, text segments, thread stacks... that it counts class space twice is probably its smallest problem... ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From stuefe at openjdk.java.net Thu May 26 13:51:41 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 26 May 2022 13:51:41 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Thu, 26 May 2022 11:32:46 GMT, Yi Yang wrote: >> I think the problem is the definition of the pools. We seem to have nested pools but it is far from clear that this API/mechanism was designed/intended to support nested pools. > > In any case, it's unreasonable for getNonHeapMemoryUsage to count a piece of memory repeatedly, right? In the extreme case, we might add all nested pools of metaspace, and we will get Metaspace x2 + CodeCache when using getNonHeapMemoryUsage, which should be far beyond what developers expect. In a real scenario, some monitor platforms draw a line chart by collecting getHeapMemoryUsage and getNonHeapMemoryUsage. It's confusing for end-users of the monitor platform to understand why getHeapMemoryUsage is desired while getNonHeapMemoryUsage is bigger than expectation. > > From the developer's point of view, MemoryMXBean.getNonHeapMemoryUsage is expected to obtain the size of non-heap area. Given that MemoryMXBean.getHeapMemoryUsage is clearly stated which is heap area: > > * Returns the current memory usage of the heap that > * is used for object allocation. The heap consists > * of one or more memory pools. > > > I propose to revise the Java doc to describe the definition of non-heap area more precisely: > > /** > * Returns the current memory usage of non-heap memory that > * contains code cache and metaspace. > * The non-heap memory consists of one or more memory pools. Beside my general points, I think this patch makes sense. I agree with @kelthuzadx that counting Classspace twice is wrong, whatever the intention of this API originally was. ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From iklam at openjdk.java.net Thu May 26 15:17:22 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 26 May 2022 15:17:22 GMT Subject: RFR: 8287352: DockerTestUtils::execute shows incorrect elapsed time [v2] In-Reply-To: References: Message-ID: > Please review this small change to improve the test reporting: > > - Calculating elapsed time after child process has exited > - Do not print `"Child process STDOUT is trimmed ..."` unless the lines are really trimmed. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Renamed trimLines() -> limitLines() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8897/files - new: https://git.openjdk.java.net/jdk/pull/8897/files/6a225656..d1cb5946 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8897&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8897&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8897.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8897/head:pull/8897 PR: https://git.openjdk.java.net/jdk/pull/8897 From iklam at openjdk.java.net Thu May 26 15:17:22 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 26 May 2022 15:17:22 GMT Subject: RFR: 8287352: DockerTestUtils::execute shows incorrect elapsed time [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 08:58:13 GMT, Thomas Stuefe wrote: > Looks good. > > I was confused btw by the name `trimLines` since that indicates that the lines where whitespace trimmed when in fact it just returns the first n lines from the input. Maybe rename that function? If you do, I don't need another review. > > Thanks, Thomas I renamed it to `limitLines()` ------------- PR: https://git.openjdk.java.net/jdk/pull/8897 From mchung at openjdk.java.net Thu May 26 18:12:52 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 26 May 2022 18:12:52 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Mon, 23 May 2022 07:28:41 GMT, Yi Yang wrote: > It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. > > Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)` > > ==> CodeHeap 'non-nmethods' 1532544 (Used) > ==> CodeHeap 'profiled nmethods' 0 > ==> CodeHeap 'non-profiled nmethods' 13952 > ==> Metaspace 506696 > ==> Compressed Class Space 43312 > init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K) > > In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`. Memory pool API does not support "nested" memory pools (or sub-memory pools). JDK 18 memory pools are the following: HEAP G1 Eden Space HEAP G1 Old Gen HEAP G1 Survivor Space NON_HEAP CodeHeap 'non-nmethods' NON_HEAP Metaspace NON_HEAP CodeHeap 'profiled nmethods' NON_HEAP Compressed Class Space NON_HEAP CodeHeap 'non-profiled nmethods' If `Metaspace` memory pool contains the compressed class space, then I agree with David that the current non-heap memory pools need to be examined. The meta space should be separated into multiple non-heap memory pools without overlap. ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From zgu at openjdk.java.net Thu May 26 18:19:21 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 26 May 2022 18:19:21 GMT Subject: RFR: 8271406: Kitchensink failed with "assert(early->flag() == current->flag()) failed: Should be the same" Message-ID: There is a narrow race window if nmt baseline is executed between reserving a virtual region and setting it nmt type, that can result the assertion failure. Thanks @coleenp for testing the patch, as it is an Oracle internal test. ------------- Commit messages: - 8271406 Changes: https://git.openjdk.java.net/jdk/pull/8906/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8906&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271406 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8906.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8906/head:pull/8906 PR: https://git.openjdk.java.net/jdk/pull/8906 From pchilanomate at openjdk.java.net Thu May 26 18:23:35 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 26 May 2022 18:23:35 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: <--CpRciHALgWkvDT6_kA7LZme6fn7Lx0IuLG8YrhMjE=.d6b91801-987b-4914-87a7-af07af18301b@github.com> On Thu, 26 May 2022 07:00:35 GMT, David Holmes wrote: > Hi Patricio, > > I've had a much closer look at the details and have been surprised at how "loose" the coordination between handshakes and thread termination actually is. It would be good, IMO, if there was a point (like setting is_exiting) where you knew that once that was reached a thread would have zero interaction with handshakes and could delete everything handshake related if you wanted to. > > The fact that the acquisition of the Threads_lock in Threads::remove might process any handshake certainly complicates things. I think, at a minimum, it would be preferable if we actually checked _is_exiting in that polling/checking logic so that we knew no further handshakes could be executed once _is_exiting is true - rather than placing the check in the operation (e.g. in install_async_exception()). That still relies on your changes for the destroy_vm case of course. > > So future RFE's aside everything you are doing seems fine and reasonable. Thanks for your patience walking me through this one. > Thanks for the review David! I'll make sure to wait until Dan comes back next week before integrating since he might also want to take a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From coleenp at openjdk.java.net Thu May 26 18:28:40 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 26 May 2022 18:28:40 GMT Subject: RFR: 8271406: Kitchensink failed with "assert(early->flag() == current->flag()) failed: Should be the same" In-Reply-To: References: Message-ID: On Thu, 26 May 2022 18:11:29 GMT, Zhengyu Gu wrote: > There is a narrow race window if nmt baseline is executed between reserving a virtual region and setting it nmt type, that can result the assertion failure. > > Thanks @coleenp for testing the patch, as it is an Oracle internal test. Looks good! Thank you for fixing it. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8906 From dholmes at openjdk.java.net Thu May 26 22:20:41 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 26 May 2022 22:20:41 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Thu, 26 May 2022 13:47:55 GMT, Thomas Stuefe wrote: >> In any case, it's unreasonable for getNonHeapMemoryUsage to count a piece of memory repeatedly, right? In the extreme case, we might add all nested pools of metaspace, and we will get Metaspace x2 + CodeCache when using getNonHeapMemoryUsage, which should be far beyond what developers expect. In a real scenario, some monitor platforms draw a line chart by collecting getHeapMemoryUsage and getNonHeapMemoryUsage. It's confusing for end-users of the monitor platform to understand why getHeapMemoryUsage is desired while getNonHeapMemoryUsage is bigger than expectation. >> >> From the developer's point of view, MemoryMXBean.getNonHeapMemoryUsage is expected to obtain the size of non-heap area. Given that MemoryMXBean.getHeapMemoryUsage is clearly stated which is heap area: >> >> * Returns the current memory usage of the heap that >> * is used for object allocation. The heap consists >> * of one or more memory pools. >> >> >> I propose to revise the Java doc to describe the definition of non-heap area more precisely: >> >> /** >> * Returns the current memory usage of non-heap memory that >> * contains code cache and metaspace. >> * The non-heap memory consists of one or more memory pools. > > Beside my general points, I think this patch makes sense. I agree with @kelthuzadx that counting Classspace twice is wrong, whatever the intention of this API originally was. Yes counting it twice is wrong but this is the wrong fix. The pools are not defined correctly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From darcy at openjdk.java.net Thu May 26 22:37:15 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 26 May 2022 22:37:15 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 Message-ID: Time to start getting ready for JDK 20... ------------- Commit messages: - Update symbol information for JDK 19 b24. - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Update symbol information for JDK 19 b23. - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - ... and 23 more: https://git.openjdk.java.net/jdk/compare/295be6f1...49c871d9 Changes: https://git.openjdk.java.net/jdk/pull/8236/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284858 Stats: 6210 lines in 67 files changed: 6166 ins; 0 del; 44 mod Patch: https://git.openjdk.java.net/jdk/pull/8236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236 PR: https://git.openjdk.java.net/jdk/pull/8236 From darcy at openjdk.java.net Thu May 26 22:37:15 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 26 May 2022 22:37:15 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy wrote: > Time to start getting ready for JDK 20... The expected kinds of updates to start up JDK 20. ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From dholmes at openjdk.java.net Thu May 26 22:46:42 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 26 May 2022 22:46:42 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy wrote: > Time to start getting ready for JDK 20... One comment below. I ignored the sym files. Everything else appears okay. Thanks. src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java line 312: > 310: int V18 = 0 << 16 | 62; > 311: int V19 = 0 << 16 | 63; > 312: int V20 = 0 << 17 | 64; 17 ?? Though why do we even bother with this when the minor version is zero? Simple assignment works. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8236 From kcr at openjdk.java.net Thu May 26 22:46:44 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 26 May 2022 22:46:44 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy wrote: > Time to start getting ready for JDK 20... You also need to change the JBS version from 19 to 20 in [`.jcheck/conf`](https://github.com/openjdk/jdk/blob/6a33974a6b8a629744c6d76c3b4fa1f772e52ac8/.jcheck/conf#L4): ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From darcy at openjdk.java.net Thu May 26 23:05:32 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 26 May 2022 23:05:32 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2] In-Reply-To: References: Message-ID: > Time to start getting ready for JDK 20... Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8236/files - new: https://git.openjdk.java.net/jdk/pull/8236/files/49c871d9..96be1787 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236 PR: https://git.openjdk.java.net/jdk/pull/8236 From darcy at openjdk.java.net Thu May 26 23:05:33 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 26 May 2022 23:05:33 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 In-Reply-To: References: Message-ID: On Thu, 26 May 2022 22:40:59 GMT, Kevin Rushforth wrote: > You also need to change the JBS version from 19 to 20 in [`.jcheck/conf`](https://github.com/openjdk/jdk/blob/6a33974a6b8a629744c6d76c3b4fa1f772e52ac8/.jcheck/conf#L4): Acknowledged; will fix in the next push. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From darcy at openjdk.java.net Thu May 26 23:05:33 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 26 May 2022 23:05:33 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 22:38:12 GMT, David Holmes wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback. > > src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java line 312: > >> 310: int V18 = 0 << 16 | 62; >> 311: int V19 = 0 << 16 | 63; >> 312: int V20 = 0 << 17 | 64; > > 17 ?? > > Though why do we even bother with this when the minor version is zero? Simple assignment works. Doh! Will fix in the next pushed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From kcr at openjdk.java.net Thu May 26 23:28:36 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 26 May 2022 23:28:36 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by kcr (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From mseledtsov at openjdk.java.net Fri May 27 00:56:34 2022 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 27 May 2022 00:56:34 GMT Subject: RFR: 8287352: DockerTestUtils::execute shows incorrect elapsed time [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 15:17:22 GMT, Ioi Lam wrote: >> Please review this small change to improve the test reporting: >> >> - Calculating elapsed time after child process has exited >> - Do not print `"Child process STDOUT is trimmed ..."` unless the lines are really trimmed. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Renamed trimLines() -> limitLines() Looks good to me, thank you. ------------- Marked as reviewed by mseledtsov (Committer). PR: https://git.openjdk.java.net/jdk/pull/8897 From yyang at openjdk.java.net Fri May 27 02:15:40 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 27 May 2022 02:15:40 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Thu, 26 May 2022 22:17:17 GMT, David Holmes wrote: >> Beside my general points, I think this patch makes sense. I agree with @kelthuzadx that counting Classspace twice is wrong, whatever the intention of this API originally was. > > Yes counting it twice is wrong but this is the wrong fix. The pools are not defined correctly. > Sorry for chiming in in a not very helpful way, but I am not sure what even the point is of this API. > > I'm seriously interested in who uses it, and for what. Calculating real memory usage is notoriously difficult. This one seems to be just an arbitrary selection of stuff. It leaves out C-heap usage (VM, outer JDK, and third party libs), native mappings, sometimes massive system library overhead, text segments, thread stacks... that it counts class space twice is probably its smallest problem... AFAIK, some DevOps platforms monitor JVM memory occupation by MemoryMXBean: ![image](https://user-images.githubusercontent.com/5010047/170614454-84e7fe3e-71bb-4277-8c03-db0f461d6ccf.png) Users are confused about why `HeapMemory+NonHeapMemory` is not equal to resident memory(top->res). It's still not clear what NonHeap means from `Java Doc`, I tried to understand the definition of NonHeap in source code, then found this bug... ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From iris at openjdk.java.net Fri May 27 04:04:35 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 27 May 2022 04:04:35 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From iklam at openjdk.java.net Fri May 27 04:34:45 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 27 May 2022 04:34:45 GMT Subject: RFR: 8287352: DockerTestUtils::execute shows incorrect elapsed time [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 08:58:13 GMT, Thomas Stuefe wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Renamed trimLines() -> limitLines() > > Looks good. > > I was confused btw by the name `trimLines` since that indicates that the lines where whitespace trimmed when in fact it just returns the first n lines from the input. Maybe rename that function? If you do, I don't need another review. > > Thanks, Thomas Thanks @tstuefe and @mseledts for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8897 From iklam at openjdk.java.net Fri May 27 04:34:47 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 27 May 2022 04:34:47 GMT Subject: Integrated: 8287352: DockerTestUtils::execute shows incorrect elapsed time In-Reply-To: References: Message-ID: On Thu, 26 May 2022 04:55:00 GMT, Ioi Lam wrote: > Please review this small change to improve the test reporting: > > - Calculating elapsed time after child process has exited > - Do not print `"Child process STDOUT is trimmed ..."` unless the lines are really trimmed. This pull request has now been integrated. Changeset: ec97da93 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/ec97da93c1d5bfcb80c19c15169f41926e59517b Stats: 13 lines in 1 file changed: 5 ins; 1 del; 7 mod 8287352: DockerTestUtils::execute shows incorrect elapsed time Reviewed-by: stuefe, mseledtsov ------------- PR: https://git.openjdk.java.net/jdk/pull/8897 From dholmes at openjdk.java.net Fri May 27 04:56:30 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 27 May 2022 04:56:30 GMT Subject: RFR: 8271406: Kitchensink failed with "assert(early->flag() == current->flag()) failed: Should be the same" In-Reply-To: References: Message-ID: On Thu, 26 May 2022 18:11:29 GMT, Zhengyu Gu wrote: > There is a narrow race window if nmt baseline is executed between reserving a virtual region and setting it nmt type, that can result the assertion failure. > > Thanks @coleenp for testing the patch, as it is an Oracle internal test. Seems fine. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8906 From dholmes at openjdk.java.net Fri May 27 05:04:28 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 27 May 2022 05:04:28 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Fri, 27 May 2022 02:12:32 GMT, Yi Yang wrote: >> Yes counting it twice is wrong but this is the wrong fix. The pools are not defined correctly. > >> Sorry for chiming in in a not very helpful way, but I am not sure what even the point is of this API. >> >> I'm seriously interested in who uses it, and for what. Calculating real memory usage is notoriously difficult. This one seems to be just an arbitrary selection of stuff. It leaves out C-heap usage (VM, outer JDK, and third party libs), native mappings, sometimes massive system library overhead, text segments, thread stacks... that it counts class space twice is probably its smallest problem... > > AFAIK, some DevOps platforms monitor JVM memory occupation by MemoryMXBean: > > ![image](https://user-images.githubusercontent.com/5010047/170614454-84e7fe3e-71bb-4277-8c03-db0f461d6ccf.png) > > Users are confused about why `HeapMemory+NonHeapMemory` is not equal to resident memory(top->res). It's still not clear what NonHeap means from `Java Doc`, I tried to understand the definition of NonHeap in source code, then found this bug... "non-heap" is any memory not part of the Java heap. But it is up to an implementation to decide what kinds of non-heap memory are represented by memory pools. The JavaDoc can only give possible examples not numerate an actual required set. ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From dholmes at openjdk.java.net Fri May 27 05:34:33 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 27 May 2022 05:34:33 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Mon, 23 May 2022 07:28:41 GMT, Yi Yang wrote: > It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. > > Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)` > > ==> CodeHeap 'non-nmethods' 1532544 (Used) > ==> CodeHeap 'profiled nmethods' 0 > ==> CodeHeap 'non-profiled nmethods' 13952 > ==> Metaspace 506696 > ==> Compressed Class Space 43312 > init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K) > > In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`. The basic problem is that we have two non-heap pools: - `MetaspacePool` - consists of `ClassType` and `NonClassType` parts - `CompressedKlassSpacePool` but the `CompressedKlassSpacePool` is actually the "ClassType" part of the `MetaspacePool`! I think the right fix is to just convert the `MetaspacePool` into `NonClassMetaspacePool` and only report the non-class values. AFAICS this will only be visible via the MXBean. ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From iklam at openjdk.java.net Fri May 27 06:20:03 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 27 May 2022 06:20:03 GMT Subject: RFR: 8287398: Allow concurrent execution of hotspot docker tests Message-ID: Remove the `exclusiveAccess.dirs=.` configuration (and thus the entire TEST.properties file) so that the test/hotspot/jtreg/containers/docker/*.java tests can be executed concurrently. This reduces total execution from about 8 minuets to about 2.5 minuets on my machine. In early days of JDK support for docker, we disabled concurrent execution as a precaution to avoid collisions in docker operations, such as building an image. Such collisions should no longer happen (each image is uniquely named). In comparison, in tests/jdk/jdk/internal/platform/docker there are no such limitations, and the 6 docker tests there can be executed in parallel without issue. ------------- Commit messages: - 8287398: Allow concurrent execution of hotspot docker tests Changes: https://git.openjdk.java.net/jdk/pull/8914/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8914&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287398 Stats: 24 lines in 1 file changed: 0 ins; 24 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8914.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8914/head:pull/8914 PR: https://git.openjdk.java.net/jdk/pull/8914 From dholmes at openjdk.java.net Fri May 27 06:22:36 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 27 May 2022 06:22:36 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From iklam at openjdk.java.net Fri May 27 06:25:31 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 27 May 2022 06:25:31 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Fri, 27 May 2022 05:31:24 GMT, David Holmes wrote: > The basic problem is that we have two non-heap pools: > > * `MetaspacePool` > > * consists of `ClassType` and `NonClassType` parts > * `CompressedKlassSpacePool` > > but the `CompressedKlassSpacePool` is actually the "ClassType" part of the `MetaspacePool`! > > I think the right fix is to just convert the `MetaspacePool` into `NonClassMetaspacePool` and only report the non-class values. > > AFAICS this will only be visible via the MXBean. When CDS is enabled, the CompressedKlassSpacePool actually contains more than Klass objects. It can contain other metadata such as Method, ConstantPool, etc. So calling these pools "class" and "non-class" is not 100% correct. Is there any reason for separating the CompressedKlassSpacePool from other metadata? I know in the past it was possible to run out of spaces in CompressedKlassSpace, so there might be a reason to monitor it separately? ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From yyang at openjdk.java.net Fri May 27 06:29:39 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 27 May 2022 06:29:39 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Fri, 27 May 2022 06:22:36 GMT, Ioi Lam wrote: > I think the right fix is to just convert the MetaspacePool into NonClassMetaspacePool and only report the non-class values. Yes, it's okay for me. But I have another concern. The compressed class pool is not directly used by other VM components. However, memory pools are exposed via java management APIs. At JDK level, users could obtain memory pools and choose a specified pool by name. If adapting the first solution, I guess it's somewhat strange for users to understand what is `Non Class Space`: private static MemoryPoolMXBean getMemoryPool(String name) { List pools = ManagementFactory.getMemoryPoolMXBeans(); for (MemoryPoolMXBean pool : pools) { if (pool.getName().equals(name)) { return pool; } } throw new RuntimeException("Expected to find a memory pool with name " + name); } public static void foo() { MemoryPoolMXBean a = getMemoryPool("Compressed Class Space"); MemoryPoolMXBean a = getMemoryPool("Non Class Space"); } If we remove `CompressedClassSpace`, we can only `getMemoryPool("Metaspace")`. Although metaspace is not baked in the specification, IMHO it's easier for developers to understand what is `metaspace` compared to the concepts of `Non Class Space` and `Compressed Class Space`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From stuefe at openjdk.java.net Fri May 27 07:27:49 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 27 May 2022 07:27:49 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Fri, 27 May 2022 06:22:36 GMT, Ioi Lam wrote: > > The basic problem is that we have two non-heap pools: > > > > * `MetaspacePool` > > > > * consists of `ClassType` and `NonClassType` parts > > * `CompressedKlassSpacePool` > > > > but the `CompressedKlassSpacePool` is actually the "ClassType" part of the `MetaspacePool`! > > I think the right fix is to just convert the `MetaspacePool` into `NonClassMetaspacePool` and only report the non-class values. > > AFAICS this will only be visible via the MXBean. > > When CDS is enabled, the CompressedKlassSpacePool actually contains more than Klass objects. It can contain other metadata such as Method, ConstantPool, etc. So calling these pools "class" and "non-class" is not 100% correct. > > Is there any reason for separating the CompressedKlassSpacePool from other metadata? I know in the past it was possible to run out of spaces in CompressedKlassSpace, so there might be a reason to monitor it separately? Yes, you can run out of Class space separately from Metaspace. ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From stuefe at openjdk.java.net Fri May 27 07:27:51 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 27 May 2022 07:27:51 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Fri, 27 May 2022 06:25:45 GMT, Yi Yang wrote: > > If we remove `CompressedClassSpace`, we can only `getMemoryPool("Metaspace")`. Although metaspace is not baked in the specification, IMHO it's easier for developers to understand what is `metaspace` compared to the concepts of `Non Class Space` and `Compressed Class Space`. I personally think that would be totally fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From shade at openjdk.java.net Fri May 27 07:58:35 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 27 May 2022 07:58:35 GMT Subject: RFR: 8287398: Allow concurrent execution of hotspot docker tests In-Reply-To: References: Message-ID: On Fri, 27 May 2022 05:36:08 GMT, Ioi Lam wrote: > Remove the `exclusiveAccess.dirs=.` configuration (and thus the entire TEST.properties file) so that the test/hotspot/jtreg/containers/docker/*.java tests can be executed concurrently. This reduces total execution from about 8 minuets to about 2.5 minuets on my machine. > > In early days of JDK support for docker, we disabled concurrent execution as a precaution to avoid collisions in docker operations, such as building an image. Such collisions should no longer happen (each image is uniquely named). > > In comparison, in tests/jdk/jdk/internal/platform/docker there are no such limitations, and the 6 docker tests there can be executed in parallel without issue. Unfortunately, collisions still happen, see the uses of `Common.imageName`. I see at least two conflicts: - `TestMemoryAwareness` and `TestMemoryWithCgroupV1` - `TestPids` and `TestPidsLimit` The first pair of tests nearly reliably fails on sufficiently large desktop after this patch. Please take a large machine and maybe test with `make test TEST=containers/docker JTREG="REPEAT_COUNT=50"`? ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8914 From stuefe at openjdk.java.net Fri May 27 11:32:55 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 27 May 2022 11:32:55 GMT Subject: RFR: 8271406: Kitchensink failed with "assert(early->flag() == current->flag()) failed: Should be the same" In-Reply-To: References: Message-ID: On Thu, 26 May 2022 18:11:29 GMT, Zhengyu Gu wrote: > There is a narrow race window if nmt baseline is executed between reserving a virtual region and setting it nmt type, that can result the assertion failure. > > Thanks @coleenp for testing the patch, as it is an Oracle internal test. Looks good. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8906 From mdoerr at openjdk.java.net Fri May 27 12:04:31 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 27 May 2022 12:04:31 GMT Subject: RFR: 8287437: Temporarily disable Continuations::enabled() for platforms which don't have an implementation, yet Message-ID: Hello, I'd like to disable `Continuations::enabled()` for platforms, which don't support Loom, yet. This enables working on Panama which is also controlled by `--enable-preview`. I'm proposing this for all platforms which have an unresolved porting issue here: [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) Please review and provide feedback if this makes sense for your platform. ------------- Commit messages: - 8287437: Temporarily disable Continuations::enabled() for platforms which don't have an implementation, yet Changes: https://git.openjdk.java.net/jdk/pull/8919/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8919&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287437 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8919.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8919/head:pull/8919 PR: https://git.openjdk.java.net/jdk/pull/8919 From shade at openjdk.java.net Fri May 27 12:14:42 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 27 May 2022 12:14:42 GMT Subject: RFR: 8287437: Temporarily disable Continuations::enabled() for platforms which don't have an implementation, yet In-Reply-To: References: Message-ID: On Fri, 27 May 2022 11:56:52 GMT, Martin Doerr wrote: > Hello, > > I'd like to disable `Continuations::enabled()` for platforms, which don't support Loom, yet. This enables working on Panama which is also controlled by `--enable-preview`. > > I'm proposing this for all platforms which have an unresolved porting issue here: > [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) > > Please review and provide feedback if this makes sense for your platform. That is actually a much better idea than chasing problemlists for x86_32! I'd probably just define the platforms where Loom *is* implemented: `AMD64` and `AARCH64`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8919 From zgu at openjdk.java.net Fri May 27 12:18:57 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 27 May 2022 12:18:57 GMT Subject: RFR: 8271406: Kitchensink failed with "assert(early->flag() == current->flag()) failed: Should be the same" In-Reply-To: References: Message-ID: On Thu, 26 May 2022 18:26:39 GMT, Coleen Phillimore wrote: >> There is a narrow race window if nmt baseline is executed between reserving a virtual region and setting it nmt type, that can result the assertion failure. >> >> Thanks @coleenp for testing the patch, as it is an Oracle internal test. > > Looks good! Thank you for fixing it. Thanks, @coleenp @dholmes-ora and @tstuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8906 From zgu at openjdk.java.net Fri May 27 12:18:58 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 27 May 2022 12:18:58 GMT Subject: Integrated: 8271406: Kitchensink failed with "assert(early->flag() == current->flag()) failed: Should be the same" In-Reply-To: References: Message-ID: On Thu, 26 May 2022 18:11:29 GMT, Zhengyu Gu wrote: > There is a narrow race window if nmt baseline is executed between reserving a virtual region and setting it nmt type, that can result the assertion failure. > > Thanks @coleenp for testing the patch, as it is an Oracle internal test. This pull request has now been integrated. Changeset: f2bc4476 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/f2bc4476593938094263f0d85fc9bdd369e95237 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8271406: Kitchensink failed with "assert(early->flag() == current->flag()) failed: Should be the same" Reviewed-by: coleenp, dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8906 From erikj at openjdk.java.net Fri May 27 12:24:52 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 27 May 2022 12:24:52 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From alanb at openjdk.java.net Fri May 27 13:06:36 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 27 May 2022 13:06:36 GMT Subject: RFR: 8287437: Temporarily disable Continuations::enabled() for platforms which don't have an implementation, yet In-Reply-To: References: Message-ID: On Fri, 27 May 2022 11:56:52 GMT, Martin Doerr wrote: > Hello, > > I'd like to disable `Continuations::enabled()` for platforms, which don't support Loom, yet. This enables working on Panama which is also controlled by `--enable-preview`. > > I'm proposing this for all platforms which have an unresolved porting issue here: > [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) > > Please review and provide feedback if this makes sense for your platform. > I'd probably just define the platforms where Loom _is_ implemented: `AMD64` and `AARCH64`. I think that would be better too. I hope to propose changes soon that adds an alternative virtual thread implementation that is backed by a platform thread (1-1 mapping). This clearly won't scale but it should be enough to pass conformance tests on platforms that might not have VM support for continuations for some time. Part of that needs to separate "supported by VM" from "preview features are enabled" as it has to be surfaced to the library code so it can choose the implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/8919 From mdoerr at openjdk.java.net Fri May 27 13:20:39 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 27 May 2022 13:20:39 GMT Subject: RFR: 8287437: Temporarily disable Continuations::enabled() for platforms which don't have an implementation, yet [v2] In-Reply-To: References: Message-ID: > Hello, > > I'd like to disable `Continuations::enabled()` for platforms, which don't support Loom, yet. This enables working on Panama which is also controlled by `--enable-preview`. > > I'm proposing this for all platforms which have an unresolved porting issue here: > [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) > > Please review and provide feedback if this makes sense for your platform. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Invert check: Platforms which do support Loom ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8919/files - new: https://git.openjdk.java.net/jdk/pull/8919/files/64556dda..d9084e43 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8919&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8919&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8919.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8919/head:pull/8919 PR: https://git.openjdk.java.net/jdk/pull/8919 From mdoerr at openjdk.java.net Fri May 27 13:20:40 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 27 May 2022 13:20:40 GMT Subject: RFR: 8287437: Temporarily disable Continuations::enabled() for platforms which don't have an implementation, yet In-Reply-To: References: Message-ID: <7T1hVQXBifqEpZirFe-5xd4THW-44HzEBy1gwGxIjNU=.f2782e5c-3b4a-43ff-8633-954e7ffbcf6d@github.com> On Fri, 27 May 2022 13:03:18 GMT, Alan Bateman wrote: > > I'd probably just define the platforms where Loom _is_ implemented: `AMD64` and `AARCH64`. > > I think that would be better too. Thanks for the feedback! I've changed it. > I hope to propose changes soon that adds an alternative virtual thread implementation that is backed by a platform thread (1-1 mapping). This clearly won't scale but it should be enough to pass conformance tests on platforms that might not have VM support for continuations for some time. Part of that needs to separate "supported by VM" from "preview features are enabled" as it has to be surfaced to the library code so it can choose the implementation. That sounds great! ------------- PR: https://git.openjdk.java.net/jdk/pull/8919 From shade at openjdk.java.net Fri May 27 14:08:26 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 27 May 2022 14:08:26 GMT Subject: RFR: 8287437: Temporarily disable Continuations::enabled() for platforms which don't have an implementation, yet [v2] In-Reply-To: References: Message-ID: On Fri, 27 May 2022 13:20:39 GMT, Martin Doerr wrote: >> Hello, >> >> I'd like to disable `Continuations::enabled()` for platforms, which don't support Loom, yet. This enables working on Panama which is also controlled by `--enable-preview`. >> >> I'm proposing this for all platforms which have an unresolved porting issue here: >> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) >> >> Please review and provide feedback if this makes sense for your platform. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Invert check: Platforms which do support Loom Looks fine to me. I tested x86_64 and AArch64 with `jdk_loom hotspot_loom`, and they pass. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8919 From alanb at openjdk.java.net Fri May 27 15:06:33 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 27 May 2022 15:06:33 GMT Subject: RFR: 8287437: Temporarily disable Continuations::enabled() for platforms which don't have an implementation, yet [v2] In-Reply-To: References: Message-ID: <0mpmBY3iI9uPFyV5d1NZQ9Woawb9Q7wLNH6F6W8HDSw=.d7408018-2377-40f4-90af-f8c54fbc73cc@github.com> On Fri, 27 May 2022 13:20:39 GMT, Martin Doerr wrote: >> Hello, >> >> I'd like to disable `Continuations::enabled()` for platforms, which don't support Loom, yet. This enables working on Panama which is also controlled by `--enable-preview`. >> >> I'm proposing this for all platforms which have an unresolved porting issue here: >> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) >> >> Please review and provide feedback if this makes sense for your platform. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Invert check: Platforms which do support Loom Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8919 From aph at openjdk.java.net Fri May 27 16:26:45 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 27 May 2022 16:26:45 GMT Subject: RFR: 8287437: Temporarily disable Continuations::enabled() for platforms which don't have an implementation, yet In-Reply-To: <7T1hVQXBifqEpZirFe-5xd4THW-44HzEBy1gwGxIjNU=.f2782e5c-3b4a-43ff-8633-954e7ffbcf6d@github.com> References: <7T1hVQXBifqEpZirFe-5xd4THW-44HzEBy1gwGxIjNU=.f2782e5c-3b4a-43ff-8633-954e7ffbcf6d@github.com> Message-ID: On Fri, 27 May 2022 13:17:13 GMT, Martin Doerr wrote: > I hope to propose changes soon that adds an alternative virtual thread implementation that is backed by a platform thread (1-1 mapping). This clearly won't scale but it should be enough to pass conformance tests on platforms that might not have VM support for continuations for some time. Part of that needs to separate "supported by VM" from "preview features are enabled" as it has to be surfaced to the library code so it can choose the implementation. That's excellent news. Thank you. ------------- PR: https://git.openjdk.java.net/jdk/pull/8919 From iklam at openjdk.java.net Fri May 27 16:27:40 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 27 May 2022 16:27:40 GMT Subject: RFR: 8287398: Allow concurrent execution of hotspot docker tests [v2] In-Reply-To: References: Message-ID: > Remove the `exclusiveAccess.dirs=.` configuration (and thus the entire TEST.properties file) so that the test/hotspot/jtreg/containers/docker/*.java tests can be executed concurrently. This reduces total execution from about 8 minuets to about 2.5 minuets on my machine. > > In early days of JDK support for docker, we disabled concurrent execution as a precaution to avoid collisions in docker operations, such as building an image. Such collisions should no longer happen (each image is uniquely named). > > In comparison, in tests/jdk/jdk/internal/platform/docker there are no such limitations, and the 6 docker tests there can be executed in parallel without issue. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: updated Common.imageName() to generate unique names ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8914/files - new: https://git.openjdk.java.net/jdk/pull/8914/files/65161a89..fe2c5c3c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8914&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8914&range=00-01 Stats: 35 lines in 1 file changed: 26 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8914.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8914/head:pull/8914 PR: https://git.openjdk.java.net/jdk/pull/8914 From iklam at openjdk.java.net Fri May 27 16:27:41 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 27 May 2022 16:27:41 GMT Subject: RFR: 8287398: Allow concurrent execution of hotspot docker tests [v2] In-Reply-To: References: Message-ID: On Fri, 27 May 2022 07:55:11 GMT, Aleksey Shipilev wrote: > Unfortunately, collisions still happen, see the uses of `Common.imageName`. I see at least two conflicts: > > * `TestMemoryAwareness` and `TestMemoryWithCgroupV1` > * `TestPids` and `TestPidsLimit` > > The first pair of tests nearly reliably fails on sufficiently large desktop after this patch. Please take a large machine and maybe test with `make test TEST=containers/docker JTREG="REPEAT_COUNT=50"`? I updated `Common.imageName()` to generate a unique name using the `"test.name"` system property. The `suffix` parameter isn't necessary anymore, but I left it there to avoid modifying all the test cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/8914 From iris at openjdk.java.net Fri May 27 17:50:46 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 27 May 2022 17:50:46 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From mseledtsov at openjdk.java.net Fri May 27 19:59:46 2022 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 27 May 2022 19:59:46 GMT Subject: RFR: 8287398: Allow concurrent execution of hotspot docker tests [v2] In-Reply-To: References: Message-ID: On Fri, 27 May 2022 16:27:40 GMT, Ioi Lam wrote: >> Remove the `exclusiveAccess.dirs=.` configuration (and thus the entire TEST.properties file) so that the test/hotspot/jtreg/containers/docker/*.java tests can be executed concurrently. This reduces total execution from about 8 minuets to about 2.5 minuets on my machine. >> >> In early days of JDK support for docker, we disabled concurrent execution as a precaution to avoid collisions in docker operations, such as building an image. Such collisions should no longer happen (each image is uniquely named). >> >> In comparison, in tests/jdk/jdk/internal/platform/docker there are no such limitations, and the 6 docker tests there can be executed in parallel without issue. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > updated Common.imageName() to generate unique names Looks good to me, thanks. ------------- Marked as reviewed by mseledtsov (Committer). PR: https://git.openjdk.java.net/jdk/pull/8914 From iklam at openjdk.java.net Fri May 27 21:45:42 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 27 May 2022 21:45:42 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Fri, 27 May 2022 07:22:11 GMT, Thomas Stuefe wrote: > > If we remove `CompressedClassSpace`, we can only `getMemoryPool("Metaspace")`. Although metaspace is not baked in the specification, IMHO it's easier for developers to understand what is `metaspace` compared to the concepts of `Non Class Space` and `Compressed Class Space`. > > I personally think that would be totally fine. I also vote for removing `CompressedClassSpacePool` ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From stuefe at openjdk.java.net Sun May 29 06:11:37 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 29 May 2022 06:11:37 GMT Subject: Withdrawn: JDK-8283674: Pad ObjectMonitor allocation size to cache line size In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 09:02:28 GMT, Thomas Stuefe wrote: > See discussion under [1]. > > Since the libc malloc allocator may place ObjectMonitor instances adjacent to each other, we should pad the size of ObjectMonitor to fill a whole cache line to prevent false sharing between adjacent OMs. > > [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2022-March/054187.html This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7955 From alanb at openjdk.java.net Sun May 29 16:17:41 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 29 May 2022 16:17:41 GMT Subject: RFR: 8287437: Temporarily disable Continuations::enabled() for platforms which don't have an implementation, yet In-Reply-To: References: <7T1hVQXBifqEpZirFe-5xd4THW-44HzEBy1gwGxIjNU=.f2782e5c-3b4a-43ff-8633-954e7ffbcf6d@github.com> Message-ID: On Fri, 27 May 2022 16:23:22 GMT, Andrew Haley wrote: > That's excellent news. Thank you. I've created [PR 8939](https://github.com/openjdk/jdk/pull/8939) and hope to have it ready for review in a few days. ------------- PR: https://git.openjdk.java.net/jdk/pull/8919 From stefank at openjdk.java.net Mon May 30 07:01:35 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 30 May 2022 07:01:35 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v9] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 13:28:45 GMT, Johan Sj?l?n wrote: >> May I please have a review of this PR which adds non-interleaving log streams to UL? >> >> In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. >> >> Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: >> >> 1. `ttyLocker` + `(x)tty` >> Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. >> >> 2. `stringStream` + `outputStream*` >> In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. >> >> Passes tier 1. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Update full name I pushed a second patch to my review branch, to clean up the last few inconsistencies. If you accept those suggestions, I'll go ahead and sponsor this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From shade at openjdk.java.net Mon May 30 07:07:34 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 30 May 2022 07:07:34 GMT Subject: RFR: 8287398: Allow concurrent execution of hotspot docker tests [v2] In-Reply-To: References: Message-ID: On Fri, 27 May 2022 16:27:40 GMT, Ioi Lam wrote: >> Remove the `exclusiveAccess.dirs=.` configuration (and thus the entire TEST.properties file) so that the test/hotspot/jtreg/containers/docker/*.java tests can be executed concurrently. This reduces total execution from about 8 minuets to about 2.5 minuets on my machine. >> >> In early days of JDK support for docker, we disabled concurrent execution as a precaution to avoid collisions in docker operations, such as building an image. Such collisions should no longer happen (each image is uniquely named). >> >> In comparison, in tests/jdk/jdk/internal/platform/docker there are no such limitations, and the 6 docker tests there can be executed in parallel without issue. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > updated Common.imageName() to generate unique names Okay, as long as multiple iterations of these tests pass. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8914 From duke at openjdk.java.net Mon May 30 08:06:52 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 30 May 2022 08:06:52 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v10] In-Reply-To: References: Message-ID: > May I please have a review of this PR which adds non-interleaving log streams to UL? > > In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. > > Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: > > 1. `ttyLocker` + `(x)tty` > Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. > > 2. `stringStream` + `outputStream*` > In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. > > Passes tier 1. Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision: - Update full name - Review comments 2 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8748/files - new: https://git.openjdk.java.net/jdk/pull/8748/files/f267bd45..6bc3a44f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8748&range=08-09 Stats: 74 lines in 5 files changed: 28 ins; 33 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8748/head:pull/8748 PR: https://git.openjdk.java.net/jdk/pull/8748 From duke at openjdk.java.net Mon May 30 08:06:53 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 30 May 2022 08:06:53 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v9] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 13:28:45 GMT, Johan Sj?l?n wrote: >> May I please have a review of this PR which adds non-interleaving log streams to UL? >> >> In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. >> >> Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: >> >> 1. `ttyLocker` + `(x)tty` >> Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. >> >> 2. `stringStream` + `outputStream*` >> In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. >> >> Passes tier 1. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Update full name I pulled in your changes. Once again LGTM. ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From rrich at openjdk.java.net Mon May 30 08:43:25 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 30 May 2022 08:43:25 GMT Subject: RFR: 8287437: Temporarily disable Continuations::enabled() for platforms which don't have an implementation, yet [v2] In-Reply-To: References: Message-ID: On Fri, 27 May 2022 13:20:39 GMT, Martin Doerr wrote: >> Hello, >> >> I'd like to disable `Continuations::enabled()` for platforms, which don't support Loom, yet. This enables working on Panama which is also controlled by `--enable-preview`. >> >> I'm proposing this for all platforms which have an unresolved porting issue here: >> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) >> >> Please review and provide feedback if this makes sense for your platform. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Invert check: Platforms which do support Loom Hi Martin, the change looks good to me. Thanks, Richard. ------------- Marked as reviewed by rrich (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8919 From rehn at openjdk.java.net Mon May 30 08:58:23 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 30 May 2022 08:58:23 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: On Thu, 19 May 2022 19:17:09 GMT, Patricio Chilano Mateo wrote: > On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. > To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things: > - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state. > - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. > > I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases. > > I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that. > > Thanks, > Patricio @dholmes-ora originally the idea was that if a JT is on a ThreadsList it will respond to handshakes. Note that while on the ThreadsList it may participate in safepoints. Since we also touch oops after "thread is exiting" we cannot stop responding to handshake after this stage. (ensure_join) At one point I actually had a patch which removed the terminated state all together, and instead used on or off ThreadsList, which I think is the right approach, reducing complexity. Anyhow a way longer discussion, this seems fine for now @pchilano , thanks! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8795 From mdoerr at openjdk.java.net Mon May 30 09:06:25 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 30 May 2022 09:06:25 GMT Subject: RFR: 8287437: Temporarily disable Continuations::enabled() for platforms which don't have an implementation, yet [v2] In-Reply-To: References: Message-ID: <85bI8V0OI8MyJgI0b0OOtPhbqUHxs2xVeKUCEmOkbDg=.aebb7e93-17c1-4e5b-9804-87a2d3fa23c1@github.com> On Fri, 27 May 2022 13:20:39 GMT, Martin Doerr wrote: >> Hello, >> >> I'd like to disable `Continuations::enabled()` for platforms, which don't support Loom, yet. This enables working on Panama which is also controlled by `--enable-preview`. >> >> I'm proposing this for all platforms which have an unresolved porting issue here: >> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) >> >> Please review and provide feedback if this makes sense for your platform. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Invert check: Platforms which do support Loom Thanks for the reviews! And thanks for working on https://github.com/openjdk/jdk/pull/8939 which is an interesting approach. ------------- PR: https://git.openjdk.java.net/jdk/pull/8919 From mdoerr at openjdk.java.net Mon May 30 09:06:26 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 30 May 2022 09:06:26 GMT Subject: Integrated: 8287437: Temporarily disable Continuations::enabled() for platforms which don't have an implementation, yet In-Reply-To: References: Message-ID: On Fri, 27 May 2022 11:56:52 GMT, Martin Doerr wrote: > Hello, > > I'd like to disable `Continuations::enabled()` for platforms, which don't support Loom, yet. This enables working on Panama which is also controlled by `--enable-preview`. > > I'm proposing this for all platforms which have an unresolved porting issue here: > [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) > > Please review and provide feedback if this makes sense for your platform. This pull request has now been integrated. Changeset: b1b96746 Author: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/b1b96746633487901cbc504ccd074cb856ed5327 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8287437: Temporarily disable Continuations::enabled() for platforms which don't have an implementation, yet Reviewed-by: shade, alanb, rrich ------------- PR: https://git.openjdk.java.net/jdk/pull/8919 From dholmes at openjdk.java.net Mon May 30 09:59:28 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 30 May 2022 09:59:28 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v10] In-Reply-To: References: Message-ID: On Mon, 30 May 2022 08:06:52 GMT, Johan Sj?l?n wrote: >> May I please have a review of this PR which adds non-interleaving log streams to UL? >> >> In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. >> >> Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: >> >> 1. `ttyLocker` + `(x)tty` >> Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. >> >> 2. `stringStream` + `outputStream*` >> In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. >> >> Passes tier 1. > > Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision: > > - Update full name > - Review comments 2 Still okay. :) ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8748 From dholmes at openjdk.java.net Mon May 30 10:05:25 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 30 May 2022 10:05:25 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: <_cEH6KdoeVBddc3n1qzIowiDtkwT_VrSBNy2p1q0quk=.7684d9c8-a519-4bb0-bc4a-45c0b6b097c0@github.com> On Mon, 30 May 2022 08:54:44 GMT, Robbin Ehn wrote: >> On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. >> To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things: >> - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state. >> - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. >> >> I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases. >> >> I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that. >> >> Thanks, >> Patricio > > @dholmes-ora originally the idea was that if a JT is on a ThreadsList it will respond to handshakes. Note that while on the ThreadsList it may participate in safepoints. > Since we also touch oops after "thread is exiting" we cannot stop responding to handshake after this stage. (ensure_join) > > At one point I actually had a patch which removed the terminated state all together, and instead used on or off ThreadsList, which I think is the right approach, reducing complexity. > > Anyhow a way longer discussion, this seems fine for now @pchilano , thanks! @robehn Using on/off the ThreadsList does not seem right to me. Removal from the main thread-list happens much later than the point at which handshaking a terminating thread makes no sense; and removal from all threads-lists may not occur under we get into ThreadSMR::delete. To me it makes perfect sense for a thread to have a terminating state, like is_exiting, which effectively hides it from the rest of the VM in terms of interacting with it. To all and intents and purposes such a thread has already terminated as far as most of the outside world is concerned. ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From sgehwolf at openjdk.java.net Mon May 30 10:22:25 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 30 May 2022 10:22:25 GMT Subject: RFR: 8287398: Allow concurrent execution of hotspot docker tests [v2] In-Reply-To: References: Message-ID: On Fri, 27 May 2022 16:27:40 GMT, Ioi Lam wrote: >> Remove the `exclusiveAccess.dirs=.` configuration (and thus the entire TEST.properties file) so that the test/hotspot/jtreg/containers/docker/*.java tests can be executed concurrently. This reduces total execution from about 8 minuets to about 2.5 minuets on my machine. >> >> In early days of JDK support for docker, we disabled concurrent execution as a precaution to avoid collisions in docker operations, such as building an image. Such collisions should no longer happen (each image is uniquely named). >> >> In comparison, in tests/jdk/jdk/internal/platform/docker there are no such limitations, and the 6 docker tests there can be executed in parallel without issue. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > updated Common.imageName() to generate unique names Seems fine. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8914 From rehn at openjdk.java.net Mon May 30 10:28:33 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 30 May 2022 10:28:33 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: On Mon, 30 May 2022 08:54:44 GMT, Robbin Ehn wrote: >> On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. >> To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things: >> - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state. >> - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. >> >> I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases. >> >> I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that. >> >> Thanks, >> Patricio > > @dholmes-ora originally the idea was that if a JT is on a ThreadsList it will respond to handshakes. Note that while on the ThreadsList it may participate in safepoints. > Since we also touch oops after "thread is exiting" we cannot stop responding to handshake after this stage. (ensure_join) > > At one point I actually had a patch which removed the terminated state all together, and instead used on or off ThreadsList, which I think is the right approach, reducing complexity. > > Anyhow a way longer discussion, this seems fine for now @pchilano , thanks! > @robehn Using on/off the ThreadsList does not seem right to me. Removal from the main thread-list happens much later than the point at which handshaking a terminating thread makes no sense; and removal from all threads-lists may not occur under we get into ThreadSMR::delete. To me it makes perfect sense for a thread to have a terminating state, like is_exiting, which effectively hides it from the rest of the VM in terms of interacting with it. To all and intents and purposes such a thread has already terminated as far as most of the outside world is concerned. The state which hides it from the rest of the VM is the removal from the ThreadsList. Since the JT after the state "is_exiting" still uses oops and interacts with Java, it's no where close to be hidden. It participates in safepoint, still does JVM TI callbacks, it generates JFR events, etc.. (I guess posting contended monitor enter after posting thread end is a bug). The basically the only subsystem that care about terminated flag is JVM TI and other 'serviceability'. You can see the comment: "These things needs to be done while we are still a Java Thread" And while we are a JavaThread we must participate in safepoints and handshakes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From rpressler at openjdk.java.net Mon May 30 11:30:59 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Mon, 30 May 2022 11:30:59 GMT Subject: RFR: 8287512: continuationEntry.hpp has incomplete definitions Message-ID: Please review this small change, which cleans up continuationEntry.hpp and fixes incomplete definitions. Passes tier1 ------------- Commit messages: - Clean up continuationEntry.hpp Changes: https://git.openjdk.java.net/jdk/pull/8944/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8944&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287512 Stats: 19 lines in 3 files changed: 7 ins; 7 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8944.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8944/head:pull/8944 PR: https://git.openjdk.java.net/jdk/pull/8944 From shade at openjdk.java.net Mon May 30 12:18:47 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 30 May 2022 12:18:47 GMT Subject: RFR: 8287512: continuationEntry.hpp has incomplete definitions In-Reply-To: References: Message-ID: On Mon, 30 May 2022 10:34:34 GMT, Ron Pressler wrote: > Please review this small change, which cleans up continuationEntry.hpp and fixes incomplete definitions. > > Passes tier1 src/hotspot/share/runtime/continuationEntry.cpp line 38: > 36: address ContinuationEntry::return_pc = nullptr; > 37: > 38: void ContinuationEntry::set_enter_nmethod(CompiledMethod* cm) { This looks weird. Do we really have `CompiledMethod*` arguments for this call? If so, it would be weird to call it `set_enter_*nmethod*`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8944 From stefank at openjdk.java.net Mon May 30 12:19:42 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 30 May 2022 12:19:42 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v10] In-Reply-To: References: Message-ID: On Mon, 30 May 2022 08:06:52 GMT, Johan Sj?l?n wrote: >> May I please have a review of this PR which adds non-interleaving log streams to UL? >> >> In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. >> >> Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: >> >> 1. `ttyLocker` + `(x)tty` >> Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. >> >> 2. `stringStream` + `outputStream*` >> In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. >> >> Passes tier 1. > > Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision: > > - Update full name > - Review comments 2 Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From rpressler at openjdk.java.net Mon May 30 12:46:44 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Mon, 30 May 2022 12:46:44 GMT Subject: RFR: 8287512: continuationEntry.hpp has incomplete definitions In-Reply-To: References: Message-ID: On Mon, 30 May 2022 12:15:03 GMT, Aleksey Shipilev wrote: >> Please review this small change, which cleans up continuationEntry.hpp and fixes incomplete definitions. >> >> Passes tier1 > > src/hotspot/share/runtime/continuationEntry.cpp line 38: > >> 36: address ContinuationEntry::return_pc = nullptr; >> 37: >> 38: void ContinuationEntry::set_enter_nmethod(CompiledMethod* cm) { > > This looks weird. Do we really have `CompiledMethod*` arguments for this call? If so, it would be weird to call it `set_enter_*nmethod*`. `CompiledMethod` is all that's required here, and I also want to try calling that method from elsewhere (Method::set_code) where we only have `CompiledMethod`. But if it bothers anyone I can leave it an nmethod. ------------- PR: https://git.openjdk.java.net/jdk/pull/8944 From duke at openjdk.java.net Mon May 30 15:36:47 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 30 May 2022 15:36:47 GMT Subject: RFR: 8286180: Enable construction of LogStreamImpl from LogMessageImpl [v10] In-Reply-To: References: Message-ID: On Mon, 30 May 2022 08:06:52 GMT, Johan Sj?l?n wrote: >> May I please have a review of this PR which adds non-interleaving log streams to UL? >> >> In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. >> >> Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: >> >> 1. `ttyLocker` + `(x)tty` >> Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. >> >> 2. `stringStream` + `outputStream*` >> In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. >> >> Passes tier 1. > > Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision: > > - Update full name > - Review comments 2 Re-ran tier1, passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From duke at openjdk.java.net Mon May 30 16:57:49 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 30 May 2022 16:57:49 GMT Subject: Integrated: 8286180: Enable construction of LogStreamImpl from LogMessageImpl In-Reply-To: References: Message-ID: On Tue, 17 May 2022 12:55:35 GMT, Johan Sj?l?n wrote: > May I please have a review of this PR which adds non-interleaving log streams to UL? > > In `LogMessageImpl` I remove templates and instead directly store a reference to `LogTagSet` and change `LogTagHandle` to be consistent (from pointer to reference) with `LogMessageImpl`. > > Adding a non-interleaving log stream enables UL to replace two patterns found in HotSpot: > > 1. `ttyLocker` + `(x)tty` > Instead of taking the global tty lock in order to ensure non-interleaving logs we can now make a `NonInterleavingLogstream` and pass that around to various `print_on(outputStream*)` functions. > > 2. `stringStream` + `outputStream*` > In order to avoid taking the lock and being able to take arbitrary output streams a `stringStream` is created and finally printed through `print_raw(ss.as_string())`. This however requires a `ResourceMark`, which `NonInterleavingLogStream` does not require. > > Passes tier 1. This pull request has now been integrated. Changeset: b2ba9fc9 Author: Johan Sj?l?n Committer: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/b2ba9fc9f696fe3d452ad809d540f4618f5f215a Stats: 260 lines in 6 files changed: 150 ins; 29 del; 81 mod 8286180: Enable construction of LogStreamImpl from LogMessageImpl Reviewed-by: dholmes, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/8748 From dholmes at openjdk.java.net Mon May 30 21:54:33 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 30 May 2022 21:54:33 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: On Mon, 30 May 2022 10:25:08 GMT, Robbin Ehn wrote: > Since the JT after the state "is_exiting" still uses oops and interacts with Java, it's no where close to be hidden. Setting is_exiting is the start of hiding the thread from the rest of the system. The only interaction with "Java" after that is ensure_join to perform the ObjectMonitor notification and to mark the Thread's own Java state as "dead". This is the point at which this thread is dead to Java code and thus "hidden". The is_exiting state should be a gate for any JVMTI callbacks and JFR events as they don't apply to "terminated" threads - for JFR we call on_thread_exit shortly after setting the is_exiting state and just before that we could still post monitor exit events). The thread must participate in safepoints up until its last oop-touch, which means after barrier_set->on_thread_detach() it does not need to participate in safepoints - and shouldn't hit any more polling points after that anyway. A handshake with a thread is only needed to interact with that thread in some way and we don't interact with "terminated" threads - so no handshakes needed. We have a two-stage termination sequence (is_exiting then terminated) precisely because the vast majority of interactions with a thread cease after is_exiting, and everything after "is terminated". So we're really only discussing the relatively small window between those two points. I'm arguing that there is no need to process handshakes from the start of that Window, rather than from the end. The basic sequence is: 1. set is_exiting -> thread is no longer of interest to JVM TI or any handshakes related to JVM TI or Java code 2. set java.lang.Thread status to TERMINATED -> thread is now dead to Java 3. JFR::on_thread_exit() -> thread is now "dead" to JFR 4. barrier_set()->on_thread_deatch() -> no more oop interaction so no need for further safepoints 5. ThreadSMRSupport::remove_thread -> thread no longer in main ThreadsList 6. set _thread_terminated > You can see the comment: "These things needs to be done while we are still a Java Thread" That comment is referring to the thread destructor process where we must still be seen to be a JavaThread and not a basic Thread - ie those actions must happen before the end of ~JavaThread. (We had issues where we made calls to virtual functions from ~Thread which didn't dispatch correctly.) ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From tschatzl at openjdk.java.net Tue May 31 07:50:02 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 31 May 2022 07:50:02 GMT Subject: RFR: 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark Message-ID: Hi all, can I have reviews for this change that makes a few CLDG iterations no-keepalive during GC pauses? This fixes a bug where the `VerifyDuringGC` verification otherwise kept alive all classes, effectively disabling class unloading during (g1) concurrent mark. Afaict this verification code is only every called during GC pauses, so the change should be fine. As for the change itself, I tried to avoid cluttering the code with `ClassLoaderDataGraphIterator<>` by using typedefs - unfortunately only C++ 17 allows omitting the `<>` if all template parameters are defaulted. There is also a new test case for just this. Testing: tier1-5 Thanks, Thomas ------------- Commit messages: - 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark Changes: https://git.openjdk.java.net/jdk/pull/8949/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8949&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280454 Stats: 124 lines in 4 files changed: 111 ins; 4 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8949.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8949/head:pull/8949 PR: https://git.openjdk.java.net/jdk/pull/8949 From rehn at openjdk.java.net Tue May 31 07:54:38 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 31 May 2022 07:54:38 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: On Mon, 30 May 2022 21:51:37 GMT, David Holmes wrote: > A handshake with a thread is only needed to interact with that thread in some way and we don't interact with "terminated" threads - so no handshakes needed. We interact with all JT on a ThreadsList, that's what ThreadsList do, stop the JT from exiting so we can interact with it. > 4. barrier_set()->on_thread_deatch() -> no more oop interaction so no need for further safepoints Safepoints and handshakes are the same, a GC needs to beable to access the GC data in the JT until 4. Regardless if the GC choose to access them via handshake or a safepoint. ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From coleenp at openjdk.java.net Tue May 31 11:52:42 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 31 May 2022 11:52:42 GMT Subject: RFR: 8287512: continuationEntry.hpp has incomplete definitions In-Reply-To: References: Message-ID: On Mon, 30 May 2022 12:42:55 GMT, Ron Pressler wrote: >> src/hotspot/share/runtime/continuationEntry.cpp line 38: >> >>> 36: address ContinuationEntry::return_pc = nullptr; >>> 37: >>> 38: void ContinuationEntry::set_enter_nmethod(CompiledMethod* cm) { >> >> This looks weird. Do we really have `CompiledMethod*` arguments for this call? If so, it would be weird to call it `set_enter_*nmethod*`. > > `CompiledMethod` is all that's required here, and I also want to try calling that method from elsewhere (Method::set_code) where we only have `CompiledMethod`. But if it bothers anyone I can leave it an nmethod. I agree, maybe rename to set_enter_method or set_enter_code() ? Also the static data members don't have underscores, so I had to look to see what return_pc is, ie what this function did. Was there a reason? If not, please add leading underscores to these nonstatic data members. ------------- PR: https://git.openjdk.java.net/jdk/pull/8944 From coleenp at openjdk.java.net Tue May 31 11:52:44 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 31 May 2022 11:52:44 GMT Subject: RFR: 8287512: continuationEntry.hpp has incomplete definitions In-Reply-To: References: Message-ID: On Mon, 30 May 2022 10:34:34 GMT, Ron Pressler wrote: > Please review this small change, which cleans up continuationEntry.hpp and fixes incomplete definitions. > > Passes tier1 src/hotspot/share/runtime/continuationEntry.hpp line 56: > 54: public: > 55: static int return_pc_offset; // friend gen_continuation_enter > 56: static void set_enter_nmethod(CompiledMethod* nm); // friend SharedRuntime::generate_native_wrapper Do you need a forward declaration of CompiledMethod instead of nmethod at line 33? ------------- PR: https://git.openjdk.java.net/jdk/pull/8944 From pchilanomate at openjdk.java.net Tue May 31 15:27:47 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 31 May 2022 15:27:47 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: On Mon, 30 May 2022 21:51:37 GMT, David Holmes wrote: >>> @robehn Using on/off the ThreadsList does not seem right to me. Removal from the main thread-list happens much later than the point at which handshaking a terminating thread makes no sense; and removal from all threads-lists may not occur under we get into ThreadSMR::delete. To me it makes perfect sense for a thread to have a terminating state, like is_exiting, which effectively hides it from the rest of the VM in terms of interacting with it. To all and intents and purposes such a thread has already terminated as far as most of the outside world is concerned. >> >> The state which hides it from the rest of the VM is the removal from the ThreadsList. >> Since the JT after the state "is_exiting" still uses oops and interacts with Java, it's no where close to be hidden. >> It participates in safepoint, still does JVM TI callbacks, it generates JFR events, etc.. (I guess posting contended monitor enter after posting thread end is a bug). >> Basically the only subsystem that care about terminated flag is JVM TI and other 'serviceability'. >> You can see the comment: "These things needs to be done while we are still a Java Thread" >> And while we are a JavaThread we must participate in safepoints and handshakes. > >> Since the JT after the state "is_exiting" still uses oops and interacts with Java, it's no where close to be hidden. > > Setting is_exiting is the start of hiding the thread from the rest of the system. The only interaction with "Java" after that is ensure_join to perform the ObjectMonitor notification and to mark the Thread's own Java state as "dead". This is the point at which this thread is dead to Java code and thus "hidden". The is_exiting state should be a gate for any JVMTI callbacks and JFR events as they don't apply to "terminated" threads - for JFR we call on_thread_exit shortly after setting the is_exiting state and just before that we could still post monitor exit events). > > The thread must participate in safepoints up until its last oop-touch, which means after barrier_set->on_thread_detach() it does not need to participate in safepoints - and shouldn't hit any more polling points after that anyway. > > A handshake with a thread is only needed to interact with that thread in some way and we don't interact with "terminated" threads - so no handshakes needed. > > We have a two-stage termination sequence (is_exiting then terminated) precisely because the vast majority of interactions with a thread cease after is_exiting, and everything after "is terminated". So we're really only discussing the relatively small window between those two points. I'm arguing that there is no need to process handshakes from the start of that Window, rather than from the end. The basic sequence is: > > 1. set is_exiting -> thread is no longer of interest to JVM TI or any handshakes related to JVM TI or Java code > 2. set java.lang.Thread status to TERMINATED -> thread is now dead to Java > 3. JFR::on_thread_exit() -> thread is now "dead" to JFR > 4. barrier_set()->on_thread_deatch() -> no more oop interaction so no need for further safepoints > 5. ThreadSMRSupport::remove_thread -> thread no longer in main ThreadsList > 6. set _thread_terminated > >> You can see the comment: "These things needs to be done while we are still a Java Thread" > > That comment is referring to the thread destructor process where we must still be seen to be a JavaThread and not a basic Thread - ie those actions must happen before the end of ~JavaThread. (We had issues where we made calls to virtual functions from ~Thread which didn't dispatch correctly.) > @dholmes-ora originally the idea was that if a JT is on a ThreadsList it will respond to handshakes. Note that while on the ThreadsList it may participate in safepoints. Since we also touch oops after "thread is exiting" we cannot stop responding to handshake after this stage. (ensure_join) > > At one point I actually had a patch which removed the terminated state all together, and instead used on or off ThreadsList, which I think is the right approach, reducing complexity. > > Anyhow a way longer discussion, this seems fine for now @pchilano , thanks! > Thanks for the review Robbin! ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From rpressler at openjdk.java.net Tue May 31 15:33:27 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Tue, 31 May 2022 15:33:27 GMT Subject: RFR: 8287512: continuationEntry.hpp has incomplete definitions [v2] In-Reply-To: References: Message-ID: > Please review this small change, which cleans up continuationEntry.hpp and fixes incomplete definitions. > > Passes tier1 Ron Pressler has updated the pull request incrementally with one additional commit since the last revision: Rename ContinuationEntry::set_enter_nmethod and static fields ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8944/files - new: https://git.openjdk.java.net/jdk/pull/8944/files/4783d9c4..5e32d7fc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8944&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8944&range=00-01 Stats: 14 lines in 4 files changed: 0 ins; 1 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8944.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8944/head:pull/8944 PR: https://git.openjdk.java.net/jdk/pull/8944 From rpressler at openjdk.java.net Tue May 31 15:33:27 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Tue, 31 May 2022 15:33:27 GMT Subject: RFR: 8287512: continuationEntry.hpp has incomplete definitions [v2] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 11:49:13 GMT, Coleen Phillimore wrote: >> `CompiledMethod` is all that's required here, and I also want to try calling that method from elsewhere (Method::set_code) where we only have `CompiledMethod`. But if it bothers anyone I can leave it an nmethod. > > I agree, maybe rename to set_enter_method or set_enter_code() ? > Also the static data members don't have underscores, so I had to look to see what return_pc is, ie what this function did. Was there a reason? If not, please add leading underscores to these nonstatic data members. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/8944 From coleenp at openjdk.java.net Tue May 31 16:01:44 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 31 May 2022 16:01:44 GMT Subject: RFR: 8287512: continuationEntry.hpp has incomplete definitions [v2] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 15:33:27 GMT, Ron Pressler wrote: >> Please review this small change, which cleans up continuationEntry.hpp and fixes incomplete definitions. >> >> Passes tier1 > > Ron Pressler has updated the pull request incrementally with one additional commit since the last revision: > > Rename ContinuationEntry::set_enter_nmethod and static fields Looks good, thank you! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8944 From darcy at openjdk.java.net Tue May 31 20:32:13 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 31 May 2022 20:32:13 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v3] In-Reply-To: References: Message-ID: <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com> > Time to start getting ready for JDK 20... Joe Darcy 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 36 additional commits since the last revision: - Update deprecated options test. - Merge branch 'master' into JDK-8284858 - Respond to review feedback. - Update symbol information for JDK 19 b24. - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Update symbol information for JDK 19 b23. - ... and 26 more: https://git.openjdk.java.net/jdk/compare/57d97d36...eedd36bd ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8236/files - new: https://git.openjdk.java.net/jdk/pull/8236/files/96be1787..eedd36bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=01-02 Stats: 41686 lines in 344 files changed: 18832 ins; 17644 del; 5210 mod Patch: https://git.openjdk.java.net/jdk/pull/8236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236 PR: https://git.openjdk.java.net/jdk/pull/8236 From iris at openjdk.java.net Tue May 31 21:47:40 2022 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 31 May 2022 21:47:40 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v3] In-Reply-To: <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com> References: <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com> Message-ID: On Tue, 31 May 2022 20:32:13 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy 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 36 additional commits since the last revision: > > - Update deprecated options test. > - Merge branch 'master' into JDK-8284858 > - Respond to review feedback. > - Update symbol information for JDK 19 b24. > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Update symbol information for JDK 19 b23. > - ... and 26 more: https://git.openjdk.java.net/jdk/compare/d01d01b5...eedd36bd Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8236