From david.holmes at oracle.com Thu Jul 1 01:44:54 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Jul 2021 11:44:54 +1000 Subject: RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc In-Reply-To: References: Message-ID: <7b6c20dd-219b-be6d-6d65-daf6b2bb824e@oracle.com> Hi Christoph, On 24/06/2021 10:06 pm, Christoph G?ttschkes wrote: > Hi, > > please review the following change, which was way too long on my chest. It fixes an assertion in the template interpreter for ARM32-softfp. > > For ARM32-softfp, the template interpreter calls into the runtime to load a double constant using the ldc bytecode. After the interpreter loaded the constants, the assert block does some sanity checks on the cached constants. But if the double constant is the first constant to be loaded, the cache is not yet initialized and the check results in a SIGSEGV. > > I guarded the usage of `ConstantPool::cp_to_object_index` by another check, which tests if there are any resolved references and if that's the case, the cache has already been initialized and the sanity checks can be performed. Why isn't this something that should be fixed in the ARM code rather than the shared code? I admit I'm struggling to understand exactly how the problem arises - ldc is not to be used for long/double values. Thanks, David ----- > ------------- > > Commit messages: > - Guard resolve ldc assertion. > > Changes: https://git.openjdk.java.net/jdk/pull/4582/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4582&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8230797 > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jdk/pull/4582.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/4582/head:pull/4582 > > PR: https://git.openjdk.java.net/jdk/pull/4582 > From david.holmes at oracle.com Thu Jul 1 01:59:03 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Jul 2021 11:59:03 +1000 Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v2] In-Reply-To: References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> Message-ID: <4a866a63-e9b9-7cf3-9f54-91b11839f69c@oracle.com> On 1/07/2021 4:56 am, Coleen Phillimore wrote: > On Wed, 30 Jun 2021 18:44:33 GMT, Coleen Phillimore wrote: > >>> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Fixed copyright years in hpp files >> >> src/hotspot/share/runtime/thread.cpp line 3935: >> >>> 3933: // in that case. However, since this must work and we do not allow >>> 3934: // exceptions anyway, check and abort if this fails. >>> 3935: if (thread == nullptr || thread->osthread() == nullptr) { >> >> thread shouldn't be NULL here if you haven't used a nothrow version of new to allocate the thread. > > Since you're no longer holding the JavaThreads_lock here, it seems like you could do this from the JavaThread constructor instead of adding this function. Except for the case for the JFR thread and JVMTI. So maybe you need this. This code is only for system Java Thread's where failure to initialize during VM init (very unlikely) will abort the VM. It doesn't apply to all system JavaThread's nor the JavaThread's we create in response to starting java.lang.Thread instances. > Maybe fix the comment at the end of JavaThread constructor that says you're holding a lock and are going to throw OOM and those details. What comment ?? Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4629 > From david.holmes at oracle.com Thu Jul 1 01:59:30 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Jul 2021 11:59:30 +1000 Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v2] In-Reply-To: References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> Message-ID: <866c8f7c-2af9-26ae-c1c7-cdc037f0b596@oracle.com> Thanks for the review Patricio. David On 1/07/2021 1:57 am, Patricio Chilano Mateo wrote: > On Wed, 30 Jun 2021 01:31:30 GMT, David Holmes wrote: > >>> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread. >>> >>> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE. >>> >>> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock. >>> >>> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary). >>> >>> The trickiest changes related to the CompilerThreads, so they need particular scrutiny. >>> >>> Testing: tiers 1-3 >>> >>> Thanks, >>> David >> >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed copyright years in hpp files > > Hi David, > > Changes look good to me. > > Thanks, > Patricio > > ------------- > > Marked as reviewed by pchilanomate (Committer). > > PR: https://git.openjdk.java.net/jdk/pull/4629 > From david.holmes at oracle.com Thu Jul 1 02:09:15 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Jul 2021 12:09:15 +1000 Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v2] In-Reply-To: <4a866a63-e9b9-7cf3-9f54-91b11839f69c@oracle.com> References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> <4a866a63-e9b9-7cf3-9f54-91b11839f69c@oracle.com> Message-ID: On 1/07/2021 11:59 am, David Holmes wrote: > On 1/07/2021 4:56 am, Coleen Phillimore wrote: >> On Wed, 30 Jun 2021 18:44:33 GMT, Coleen Phillimore >> wrote: >> >>>> David Holmes has updated the pull request incrementally with one >>>> additional commit since the last revision: >>>> >>>> ?? Fixed copyright years in hpp files >>> >>> src/hotspot/share/runtime/thread.cpp line 3935: >>> >>>> 3933:?? // in that case. However, since this must work and we do not >>>> allow >>>> 3934:?? // exceptions anyway, check and abort if this fails. >>>> 3935:?? if (thread == nullptr || thread->osthread() == nullptr) { >>> >>> thread shouldn't be NULL here if you haven't used a nothrow version >>> of new to allocate the thread. >> >> Since you're no longer holding the JavaThreads_lock here, it seems >> like you could do this from the JavaThread constructor instead of >> adding this function. Except for the case for the JFR thread and >> JVMTI. So maybe you need this. > > This code is only for system Java Thread's where failure to initialize > during VM init (very unlikely) will abort the VM. It doesn't apply to > all system JavaThread's nor the JavaThread's we create in response to > starting java.lang.Thread instances. > >> Maybe fix the comment at the end of JavaThread constructor that says >> you're holding a lock and are going to throw OOM and those details. > > What comment ?? Sorry I see it now. Don't know why that isn't in the same place as the other constructors. That comment block still applies to the normal case of creating a JavaThread in JVM_StartThread. David ----- > Thanks, > David > >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/4629 >> From david.holmes at oracle.com Thu Jul 1 02:20:44 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Jul 2021 12:20:44 +1000 Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v2] In-Reply-To: References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> Message-ID: <7e465e12-a1bb-5ab7-1b96-e56e144ede23@oracle.com> Hi Coleen, Thanks for the review. On 1/07/2021 4:56 am, Coleen Phillimore wrote: > On Wed, 30 Jun 2021 01:31:30 GMT, David Holmes wrote: > >>> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread. >>> >>> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE. >>> >>> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock. >>> >>> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary). >>> >>> The trickiest changes related to the CompilerThreads, so they need particular scrutiny. >>> >>> Testing: tiers 1-3 >>> >>> Thanks, >>> David >> >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed copyright years in hpp files > > Some small change requests. > > src/hotspot/share/jfr/recorder/service/jfrRecorderThread.cpp line 49: > >> 47: assert(proc != NULL, "invariant"); >> 48: >> 49: JavaThread* new_thread = new JavaThread(proc); > > if new_thread allocation fails, the operator new will call vm_exit_out_of_memory and exit. It won't return NULL. Right. > src/hotspot/share/jfr/recorder/service/jfrRecorderThread.cpp line 54: > >> 52: // osthread was created for the JavaThread due to lack of memory. >> 53: if (new_thread == NULL || new_thread->osthread() == NULL) { >> 54: delete new_thread; > > Since new_thread can't be null, this delete is going to be ok, but it would better not to check for null. I've deleted the NULL check, but you can apply delete to NULL in any case. > src/hotspot/share/prims/jvmtiEnv.cpp line 1334: > >> 1332: // At this point it may be possible that no osthread was created for the >> 1333: // JavaThread due to lack of memory. >> 1334: if (new_thread == NULL || new_thread->osthread() == NULL) { > > Same here, unless there's some operator new overloading that doesn't use the nothrow operator new. Fixed. > src/hotspot/share/runtime/notificationThread.cpp line 61: > >> 59: vmSymbols::thread_void_signature(), >> 60: thread_oop, >> 61: THREAD); > > This was all the code that I thought was unnecessarily duplicated. The java.lang.Thread creation code will be fixed by JDK-8269652. > > src/hotspot/share/runtime/thread.cpp line 3935: > >> 3933: // in that case. However, since this must work and we do not allow >> 3934: // exceptions anyway, check and abort if this fails. >> 3935: if (thread == nullptr || thread->osthread() == nullptr) { > > thread shouldn't be NULL here if you haven't used a nothrow version of new to allocate the thread. Fixed. I also updated the comments there. Thanks, David ----- > ------------- > > Changes requested by coleenp (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/4629 > From david.holmes at oracle.com Thu Jul 1 02:44:08 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Jul 2021 12:44:08 +1000 Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v2] In-Reply-To: References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> Message-ID: <51270f1d-6c7a-9d94-ea55-c8390468feb1@oracle.com> Hi Dan, Thanks for the review. On 1/07/2021 3:08 am, Daniel D.Daugherty wrote: > On Wed, 30 Jun 2021 01:31:30 GMT, David Holmes wrote: > >>> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread. >>> >>> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE. >>> >>> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock. >>> >>> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary). >>> >>> The trickiest changes related to the CompilerThreads, so they need particular scrutiny. >>> >>> Testing: tiers 1-3 >>> >>> Thanks, >>> David >> >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed copyright years in hpp files > > Finished my re-review without the whitespace noise. I have to say > that really reveals how nice this cleanup is! Thanks for doing it. > > I only added some nits. Feel free to fix or not. > > src/hotspot/share/compiler/compileBroker.cpp line 938: > >> 936: if (UseDynamicNumberOfCompilerThreads && type == compiler_t >> 937: && comp->num_compiler_threads() > 0) { >> 938: // the new thread is not known to Thread-SMR yet so we can just delete > > nit: s/the/The/ and add a period to the end of the sentence. Okay > src/hotspot/share/prims/jvmtiEnv.cpp line 1335: > >> 1333: // JavaThread due to lack of memory. >> 1334: if (new_thread == NULL || new_thread->osthread() == NULL) { >> 1335: // the new thread is not known to Thread-SMR yet so we can just delete > > nit: s/the/The/ and add a period to the end of the sentence. Okay > src/hotspot/share/runtime/monitorDeflationThread.cpp line 51: > >> 49: CHECK); >> 50: >> 51: MonitorDeflationThread* thread = new MonitorDeflationThread(&monitor_deflation_thread_entry); > > nit: s/= new/= new/ > > (Not your typo, but please fix it while you're in here.) Fixed > src/hotspot/share/runtime/notificationThread.cpp line 63: > >> 61: THREAD); >> 62: >> 63: NotificationThread* thread = new NotificationThread(¬ification_thread_entry); > > nit: s/= new/= new/ > > (Not your typo, but please fix it while you're in here.) Fixed (also ServiceThread) > src/hotspot/share/runtime/thread.cpp line 3911: > >> 3909: MutexLocker mu(current, Threads_lock); >> 3910: >> 3911: // Initialize the fields of the thread_oop first > > nit: please add a period to the end of the sentence. Ok > src/hotspot/share/runtime/thread.cpp line 3923: > >> 3921: java_lang_Thread::set_daemon(thread_oop()); >> 3922: >> 3923: // Now bind the thread_oop to the target JavaThread > > nit: please add a period to the end of the sentence. Ok. I generally don't consider that single line comments need to be grammatical sentences. > src/hotspot/share/services/attachListener.cpp line 490: > >> 488: JavaThread::vm_exit_on_thread_allocation_failure(thread); >> 489: >> 490: JavaThread::start_internal_daemon(THREAD, thread, thread_oop, NoPriority); > > I wonder if the lack of a specific priority for the attach listener is a > contributing factor to some of the timeouts in attach that we observe. > @plummercj and @sspitsyn - You might be interested here... Given that we don't use thread native priorities by default except on Windows, that seems unlikely to be a source of problems. But who can say for sure ... Thanks, David > ------------- > > Marked as reviewed by dcubed (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/4629 > From minqi at openjdk.java.net Thu Jul 1 02:47:12 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 1 Jul 2021 02:47:12 GMT Subject: RFR: 8264735: Make dynamic dump repeatable Message-ID: Hi, Please review Currently after dynamic dump, dump time tables (`_dumptime_talbles, _dumptime_lambda_proxy_class_dictionary and _saved_shared_path_table`) are corrupted and could not be used for next dump. The patch clones the three tables, and after dump restore them so the next dump is possible. With the fix, jcmd VM.cds dynamic_dump can do multiple dump to the same live process. Tests: tier1,tier2,tier3,tier4 Thanks Yumin ------------- Commit messages: - 8264735: Make dynamic dump repeatable Changes: https://git.openjdk.java.net/jdk/pull/4646/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4646&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264735 Stats: 231 lines in 14 files changed: 195 ins; 19 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/4646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4646/head:pull/4646 PR: https://git.openjdk.java.net/jdk/pull/4646 From dholmes at openjdk.java.net Thu Jul 1 04:18:28 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 1 Jul 2021 04:18:28 GMT Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v3] In-Reply-To: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> Message-ID: <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> > Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread. > > This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE. > > The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock. > > A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary). > > The trickiest changes related to the CompilerThreads, so they need particular scrutiny. > > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with three additional commits since the last revision: - Rename vm_exit_on_thread_allocation_failure to vm_exit_on_osthread_failure - Adjust comment - Comments from PR review: - remove unnecessary new_thread NULL checks - adjust some comments - fix whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4629/files - new: https://git.openjdk.java.net/jdk/pull/4629/files/e547e0a5..8275b184 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4629&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4629&range=01-02 Stats: 28 lines in 10 files changed: 1 ins; 0 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/4629.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4629/head:pull/4629 PR: https://git.openjdk.java.net/jdk/pull/4629 From dholmes at openjdk.java.net Thu Jul 1 06:31:11 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 1 Jul 2021 06:31:11 GMT Subject: RFR: 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) Message-ID: Please review this simple enhancement that: 1. Retries OS thread creation of it fails due to EAGAIN This is potentially of limited use as you would need some resources to be released for subsequent calls to succeed. 2. Prints the name of the thread being started in the warning/log messages This is also of limited use as JavaThread's do not have their correct name at this stage, nor do some system threads. But others do, so it can be informative. I looked at trying to (separately) unify this code into a Posix version, but the platform differences are such that it makes it very difficult to try and share code. So this simply updates each the existing code in place. Testing: - builds from tiers 1-3 and GHA - manual inspection of output from a simple thread exhaustion test (runtime/Thread/ThreadCountLimit.java) - manual inspection of os+thread logging on java -version Thanks, David ------------- Commit messages: - 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) Changes: https://git.openjdk.java.net/jdk/pull/4648/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4648&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268773 Stats: 49 lines in 4 files changed: 22 ins; 0 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/4648.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4648/head:pull/4648 PR: https://git.openjdk.java.net/jdk/pull/4648 From stuefe at openjdk.java.net Thu Jul 1 07:00:03 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 1 Jul 2021 07:00:03 GMT Subject: RFR: 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 06:24:02 GMT, David Holmes wrote: > Please review this simple enhancement that: > > 1. Retries OS thread creation of it fails due to EAGAIN > > This is potentially of limited use as you would need some resources to be released for subsequent calls to succeed. > > 2. Prints the name of the thread being started in the warning/log messages > > This is also of limited use as JavaThread's do not have their correct name at this stage, nor do some system threads. But others do, so it can be informative. > > I looked at trying to (separately) unify this code into a Posix version, but the platform differences are such that it makes it very difficult to try and share code. So this simply updates each the existing code in place. > > Testing: > - builds from tiers 1-3 and GHA > - manual inspection of output from a simple thread exhaustion test (runtime/Thread/ThreadCountLimit.java) > - manual inspection of os+thread logging on java -version > > Thanks, > David Hi David, I am not sure this is useful. If you cannot start threads you ran into one of a multiple of possible limits (max number of tasks or out of memory/address space for stacks or out of number of vmas to establish guard pages...). In my experience these exhaustion cases don't solve themselves quickly. And even in the unlikely case a subsequent thread creation succeeds: the next fork/thread creation error is right around the corner. It would be better to fail here and let the user or admin fix the setup instead of stumbling along. Printing the name of the particular thread I also don't find that helpful (though it does no harm, probably), but I am not sure it is safe to call `JavaThread::get_thread_name()` at this point. In these situations it is seldom interesting which particular thread could not be started but why we hit a limit at all. So what would be good is if we were to log information about the limit we hit. In its very simplest form this could be a printout of limits (though there are many, e.g. on cgroups level). In a more sophisticated form the VM could do some platform specific analysis as to which limit hit us. But that is not that easy. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/4648 From david.holmes at oracle.com Thu Jul 1 07:24:13 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Jul 2021 17:24:13 +1000 Subject: RFR: 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) In-Reply-To: References: Message-ID: <3437a96d-da45-b0a1-5551-75e0b86b1544@oracle.com> Hi Thomas, Thanks for looking at this. On 1/07/2021 5:00 pm, Thomas Stuefe wrote: > On Thu, 1 Jul 2021 06:24:02 GMT, David Holmes wrote: > >> Please review this simple enhancement that: >> >> 1. Retries OS thread creation of it fails due to EAGAIN >> >> This is potentially of limited use as you would need some resources to be released for subsequent calls to succeed. >> >> 2. Prints the name of the thread being started in the warning/log messages >> >> This is also of limited use as JavaThread's do not have their correct name at this stage, nor do some system threads. But others do, so it can be informative. >> >> I looked at trying to (separately) unify this code into a Posix version, but the platform differences are such that it makes it very difficult to try and share code. So this simply updates each the existing code in place. >> >> Testing: >> - builds from tiers 1-3 and GHA >> - manual inspection of output from a simple thread exhaustion test (runtime/Thread/ThreadCountLimit.java) >> - manual inspection of os+thread logging on java -version >> >> Thanks, >> David > > Hi David, > > I am not sure this is useful. Makes two of us - see comments in JBS. But if it is also not harmful ... > > If you cannot start threads you ran into one of a multiple of possible limits (max number of tasks or out of memory/address space for stacks or out of number of vmas to establish guard pages...). In my experience these exhaustion cases don't solve themselves quickly. And even in the unlikely case a subsequent thread creation succeeds: the next fork/thread creation error is right around the corner. It would be better to fail here and let the user or admin fix the setup instead of stumbling along. Yep as I stated very unlikely a retry will help. Bit like redoing a failed malloc() hoping someone else might have done a free(). You might get lucky but really you've already run off the edge of the cliff. > Printing the name of the particular thread I also don't find that helpful (though it does no harm, probably), but I am not sure it is safe to call `JavaThread::get_thread_name()` at this point. In these situations it is seldom interesting which particular thread could not be started but why we hit a limit at all. It is safe to call and will just delegate to Thread::name() due to the new JavaThread not being a "protected" JavaThread. Though there is a fair bit of overhead for that call chain ... I also thought the name was of limited use, but from testing I was surprised to see that the thread that failed to be started was not the thread I was expecting, so it can have some use. :) > So what would be good is if we were to log information about the limit we hit. In its very simplest form this could be a printout of limits (though there are many, e.g. on cgroups level). In a more sophisticated form the VM could do some platform specific analysis as to which limit hit us. But that is not that easy. We already print various bits of system information to help in that regard. But in any case that would be a different RFE. Cheers, David > Cheers, Thomas > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4648 > From christoph.goettschkes at microdoc.com Thu Jul 1 07:56:35 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Thu, 1 Jul 2021 09:56:35 +0200 Subject: RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc In-Reply-To: <7b6c20dd-219b-be6d-6d65-daf6b2bb824e@oracle.com> References: <7b6c20dd-219b-be6d-6d65-daf6b2bb824e@oracle.com> Message-ID: <39gtxry8s5-1@m0246576.ppops.net> Hi David On 7/1/21 3:44 AM, David Holmes wrote: > Hi Christoph, > > On 24/06/2021 10:06 pm, Christoph G?ttschkes wrote: >> Hi, >> >> please review the following change, which was way too long on my chest. It fixes an assertion in the template interpreter for ARM32-softfp. >> >> For ARM32-softfp, the template interpreter calls into the runtime to load a double constant using the ldc bytecode. After the interpreter loaded the constants, the assert block does some sanity checks on the cached constants. But if the double constant is the first constant to be loaded, the cache is not yet initialized and the check results in a SIGSEGV. >> >> I guarded the usage of `ConstantPool::cp_to_object_index` by another check, which tests if there are any resolved references and if that's the case, the cache has already been initialized and the sanity checks can be performed. > > Why isn't this something that should be fixed in the ARM code rather than the shared code? I admit I'm struggling to understand exactly how the problem arises - ldc is not to be used for long/double values. Sorry for confusing you. Hopefully the following explanation clears things up. The runtime executes the ldc2_w bytecode to load the double constant. For ARM32-softfp this uses the TemplateTable::condy_helper method, which calls InterpreterRuntime::resolve_ldc to load the constant. resolve_ldc is used for all kinds of bytecodes. I probably wrote "calls into the runtime to load a double constant using the ldc bytecode" because of the name resolve_ldc. I guess ARM32-softfp is the only platform which uses resolve_ldc for double constants. From the way resolve_ldc is written, it also looks like it should be able to handle ldc2_w bytecodes. There are multiple assertions which check for correct bytecodes etc. and ldc2_w is explicitly among the supported bytecodes. We could still think about not using the condy_helper and resolve_ldc for loading double constants on ARM32-softfp, but after that change we would still have a resolve_ldc implementation, which works for ldc2_w, but fails in debug VMs because of the ASSERT check. So I think we have to address both things even if we change the ARM interpreter behavior for ldc2_w. > > Thanks, > David > ----- > -- Christoph From thomas.stuefe at gmail.com Thu Jul 1 08:47:39 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 1 Jul 2021 10:47:39 +0200 Subject: RFR: 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) In-Reply-To: <3437a96d-da45-b0a1-5551-75e0b86b1544@oracle.com> References: <3437a96d-da45-b0a1-5551-75e0b86b1544@oracle.com> Message-ID: On Thu, Jul 1, 2021 at 9:24 AM David Holmes wrote: > Hi Thomas, > > Thanks for looking at this. > > On 1/07/2021 5:00 pm, Thomas Stuefe wrote: > > On Thu, 1 Jul 2021 06:24:02 GMT, David Holmes > wrote: > > > >> Please review this simple enhancement that: > >> > >> 1. Retries OS thread creation of it fails due to EAGAIN > >> > >> This is potentially of limited use as you would need some resources to > be released for subsequent calls to succeed. > >> > >> 2. Prints the name of the thread being started in the warning/log > messages > >> > >> This is also of limited use as JavaThread's do not have their correct > name at this stage, nor do some system threads. But others do, so it can be > informative. > >> > >> I looked at trying to (separately) unify this code into a Posix > version, but the platform differences are such that it makes it very > difficult to try and share code. So this simply updates each the existing > code in place. > >> > >> Testing: > >> - builds from tiers 1-3 and GHA > >> - manual inspection of output from a simple thread exhaustion test > (runtime/Thread/ThreadCountLimit.java) > >> - manual inspection of os+thread logging on java -version > >> > >> Thanks, > >> David > > > > Hi David, > > > > I am not sure this is useful. > > Makes two of us - see comments in JBS. But if it is also not harmful ... > > > > > If you cannot start threads you ran into one of a multiple of possible > limits (max number of tasks or out of memory/address space for stacks or > out of number of vmas to establish guard pages...). In my experience these > exhaustion cases don't solve themselves quickly. And even in the unlikely > case a subsequent thread creation succeeds: the next fork/thread creation > error is right around the corner. It would be better to fail here and let > the user or admin fix the setup instead of stumbling along. > > Yep as I stated very unlikely a retry will help. Bit like redoing a > failed malloc() hoping someone else might have done a free(). You might > get lucky but really you've already run off the edge of the cliff. > > > Printing the name of the particular thread I also don't find that > helpful (though it does no harm, probably), but I am not sure it is safe to > call `JavaThread::get_thread_name()` at this point. In these situations it > is seldom interesting which particular thread could not be started but why > we hit a limit at all. > > It is safe to call and will just delegate to Thread::name() due to the > new JavaThread not being a "protected" JavaThread. Though there is a > fair bit of overhead for that call chain ... > > I also thought the name was of limited use, but from testing I was > surprised to see that the thread that failed to be started was not the > thread I was expecting, so it can have some use. :) > > > So what would be good is if we were to log information about the limit > we hit. In its very simplest form this could be a printout of limits > (though there are many, e.g. on cgroups level). In a more sophisticated > form the VM could do some platform specific analysis as to which limit hit > us. But that is not that easy. > > We already print various bits of system information to help in that > regard. But in any case that would be a different RFE. > The more I think about this the more I think the right way would be to enable (some form of) CrashOnOutOfMemoryError for thread resource exhaustion. You'd get the hs-err file (which can also be streamed to stdout with ErrorFileToStdout). Remember ? :) We do that downstream now btw: https://github.com/SAP/SapMachine/wiki/Handling-of-OnOutOfMemoryError-switches-in-the-SapMachine - and our support is _very_ happy with that behavior, not only the fact that we can stop on thread exhaustion, but also e.g. that we suppress cores on OOM crashes by default. Cheers, Thomas > > ------------- > > > > PR: https://git.openjdk.java.net/jdk/pull/4648 > > > From coleenp at openjdk.java.net Thu Jul 1 12:10:01 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Jul 2021 12:10:01 GMT Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v3] In-Reply-To: <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> Message-ID: On Thu, 1 Jul 2021 04:18:28 GMT, David Holmes wrote: >> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread. >> >> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE. >> >> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock. >> >> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary). >> >> The trickiest changes related to the CompilerThreads, so they need particular scrutiny. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with three additional commits since the last revision: > > - Rename vm_exit_on_thread_allocation_failure to vm_exit_on_osthread_failure > - Adjust comment > - Comments from PR review: > - remove unnecessary new_thread NULL checks > - adjust some comments > - fix whitespace Marked as reviewed by coleenp (Reviewer). src/hotspot/share/runtime/thread.cpp line 3910: > 3908: Handle thread_oop, ThreadPriority prio) { > 3909: MutexLocker mu(current, Threads_lock); > 3910: Could you add an assert that target->os_thread() != NULL here? Just to make sure everything checked. ------------- PR: https://git.openjdk.java.net/jdk/pull/4629 From coleenp at openjdk.java.net Thu Jul 1 12:10:03 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Jul 2021 12:10:03 GMT Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v2] In-Reply-To: References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> Message-ID: <7xYz2Qtk8SqjnFyX0BLqqxyqJoslGqezRk4BfCiigo8=.54517e36-285e-4198-b5b1-223a7c96ebd4@github.com> On Wed, 30 Jun 2021 18:37:40 GMT, Coleen Phillimore wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed copyright years in hpp files > > src/hotspot/share/runtime/notificationThread.cpp line 61: > >> 59: vmSymbols::thread_void_signature(), >> 60: thread_oop, >> 61: THREAD); > > This was all the code that I thought was unnecessarily duplicated. I don't know why I don't see your reply in the PR anywhere, but I'm glad you're addressing it in JDK-JDK-8269652. ------------- PR: https://git.openjdk.java.net/jdk/pull/4629 From coleenp at openjdk.java.net Thu Jul 1 12:15:05 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Jul 2021 12:15:05 GMT Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v3] In-Reply-To: <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> Message-ID: On Thu, 1 Jul 2021 04:18:28 GMT, David Holmes wrote: >> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread. >> >> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE. >> >> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock. >> >> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary). >> >> The trickiest changes related to the CompilerThreads, so they need particular scrutiny. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with three additional commits since the last revision: > > - Rename vm_exit_on_thread_allocation_failure to vm_exit_on_osthread_failure > - Adjust comment > - Comments from PR review: > - remove unnecessary new_thread NULL checks > - adjust some comments > - fix whitespace This is a nice cleanup! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4629 From dcubed at openjdk.java.net Thu Jul 1 14:18:59 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 1 Jul 2021 14:18:59 GMT Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v3] In-Reply-To: <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> Message-ID: On Thu, 1 Jul 2021 04:18:28 GMT, David Holmes wrote: >> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread. >> >> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE. >> >> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock. >> >> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary). >> >> The trickiest changes related to the CompilerThreads, so they need particular scrutiny. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with three additional commits since the last revision: > > - Rename vm_exit_on_thread_allocation_failure to vm_exit_on_osthread_failure > - Adjust comment > - Comments from PR review: > - remove unnecessary new_thread NULL checks > - adjust some comments > - fix whitespace Re-reviewed the v02 incremental webrev. Thumbs up! ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4629 From kvn at openjdk.java.net Thu Jul 1 16:22:59 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 1 Jul 2021 16:22:59 GMT Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v3] In-Reply-To: <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> Message-ID: On Thu, 1 Jul 2021 04:18:28 GMT, David Holmes wrote: >> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread. >> >> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE. >> >> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock. >> >> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary). >> >> The trickiest changes related to the CompilerThreads, so they need particular scrutiny. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with three additional commits since the last revision: > > - Rename vm_exit_on_thread_allocation_failure to vm_exit_on_osthread_failure > - Adjust comment > - Comments from PR review: > - remove unnecessary new_thread NULL checks > - adjust some comments > - fix whitespace Few comments for compileBroker.cpp changes. src/hotspot/share/compiler/compileBroker.cpp line 909: > 907: // JavaThread due to lack of resources. We will handle that failure below. > 908: > 909: if (new_thread->osthread() != NULL) { I think you do need to check `new_thread != NULL` here to please Parfait for `default:` case. src/hotspot/share/compiler/compileBroker.cpp line 939: > 937: && comp->num_compiler_threads() > 0) { > 938: // The new thread is not known to Thread-SMR yet so we can just delete. > 939: delete new_thread; Need `new_thread != NULL` check if you do as I suggested in previous comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/4629 From sspitsyn at openjdk.java.net Thu Jul 1 16:30:03 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 1 Jul 2021 16:30:03 GMT Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v3] In-Reply-To: <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> Message-ID: On Thu, 1 Jul 2021 04:18:28 GMT, David Holmes wrote: >> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread. >> >> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE. >> >> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock. >> >> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary). >> >> The trickiest changes related to the CompilerThreads, so they need particular scrutiny. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with three additional commits since the last revision: > > - Rename vm_exit_on_thread_allocation_failure to vm_exit_on_osthread_failure > - Adjust comment > - Comments from PR review: > - remove unnecessary new_thread NULL checks > - adjust some comments > - fix whitespace Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4629 From sgehwolf at openjdk.java.net Thu Jul 1 17:35:10 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 1 Jul 2021 17:35:10 GMT Subject: RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 Message-ID: This fix simplifies the `if` condition to use a default 64-bit library path including default setting when `_LP64` is defined (os has 64-bitness). This should be safe IMHO and seems better than explicitly enumerating all 64 bit Linux architectures. An alternative patch would be: diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp index 4ebf50ef0d3..5db22f8dff3 100644 --- a/src/hotspot/os/linux/os_linux.cpp +++ b/src/hotspot/os/linux/os_linux.cpp @@ -412,7 +412,7 @@ void os::init_system_properties_values() { // ... // 7: The default directories, normally /lib and /usr/lib. #ifndef OVERRIDE_LIBPATH - #if defined(AMD64) || (defined(_LP64) && defined(SPARC)) || defined(PPC64) || defined(S390) + #if defined(AMD64) || (defined(_LP64) && defined(SPARC)) || defined(PPC64) || defined(S390) || defined(AARCH64) #define DEFAULT_LIBPATH "/usr/lib64:/lib64:/lib:/usr/lib" #else #define DEFAULT_LIBPATH "/lib:/usr/lib" This issue affects older releases and I'd like to get this fix into JDK 17 too. With that in mind, please let me know what the preference is. Note that SPARC support has been removed with JEP 381 in JDK 15. Thoughts? ------------- Commit messages: - Change the condition on defined(_LP64) rather than enumerating arches Changes: https://git.openjdk.java.net/jdk/pull/4657/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4657&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269668 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4657.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4657/head:pull/4657 PR: https://git.openjdk.java.net/jdk/pull/4657 From coleenp at openjdk.java.net Thu Jul 1 17:36:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Jul 2021 17:36:10 GMT Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v3] In-Reply-To: References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> Message-ID: <1ywsxUI_B9ZGVP_Us0O5lecBx4qtglIzGSI6hVXz6gM=.ad566e05-2bdd-4bb9-a5f5-bdb38c768a3a@github.com> On Thu, 1 Jul 2021 16:14:22 GMT, Vladimir Kozlov wrote: >> David Holmes has updated the pull request incrementally with three additional commits since the last revision: >> >> - Rename vm_exit_on_thread_allocation_failure to vm_exit_on_osthread_failure >> - Adjust comment >> - Comments from PR review: >> - remove unnecessary new_thread NULL checks >> - adjust some comments >> - fix whitespace > > src/hotspot/share/compiler/compileBroker.cpp line 909: > >> 907: // JavaThread due to lack of resources. We will handle that failure below. >> 908: >> 909: if (new_thread->osthread() != NULL) { > > I think you do need to check `new_thread != NULL` here to please Parfait for `default:` case. Really? We have this sort of code everywhere. We don't check the result of a new expression anywhere else. ------------- PR: https://git.openjdk.java.net/jdk/pull/4629 From david.holmes at oracle.com Thu Jul 1 21:58:07 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 2 Jul 2021 07:58:07 +1000 Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v3] In-Reply-To: <1ywsxUI_B9ZGVP_Us0O5lecBx4qtglIzGSI6hVXz6gM=.ad566e05-2bdd-4bb9-a5f5-bdb38c768a3a@github.com> References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> <1ywsxUI_B9ZGVP_Us0O5lecBx4qtglIzGSI6hVXz6gM=.ad566e05-2bdd-4bb9-a5f5-bdb38c768a3a@github.com> Message-ID: <7be12b0c-c962-e9bc-8216-a44669f4e304@oracle.com> On 2/07/2021 3:36 am, Coleen Phillimore wrote: > On Thu, 1 Jul 2021 16:14:22 GMT, Vladimir Kozlov wrote: > >>> David Holmes has updated the pull request incrementally with three additional commits since the last revision: >>> >>> - Rename vm_exit_on_thread_allocation_failure to vm_exit_on_osthread_failure >>> - Adjust comment >>> - Comments from PR review: >>> - remove unnecessary new_thread NULL checks >>> - adjust some comments >>> - fix whitespace >> >> src/hotspot/share/compiler/compileBroker.cpp line 909: >> >>> 907: // JavaThread due to lack of resources. We will handle that failure below. >>> 908: >>> 909: if (new_thread->osthread() != NULL) { >> >> I think you do need to check `new_thread != NULL` here to please Parfait for `default:` case. > > Really? We have this sort of code everywhere. We don't check the result of a new expression anywhere else. It isn't the result of the new expression that needs checking. The switch statement has a default: clause which calls ShouldNotReachHere(). IIRC Parfait does not understand things like ShouldNotReachHere() never return, and so it thinks "new_thread" may still be NULL if we followed the default: path through the switch. I will restore this NULL check with a comment. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4629 > From dholmes at openjdk.java.net Thu Jul 1 22:06:00 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 1 Jul 2021 22:06:00 GMT Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v3] In-Reply-To: References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> Message-ID: On Thu, 1 Jul 2021 16:18:50 GMT, Vladimir Kozlov wrote: >> David Holmes has updated the pull request incrementally with three additional commits since the last revision: >> >> - Rename vm_exit_on_thread_allocation_failure to vm_exit_on_osthread_failure >> - Adjust comment >> - Comments from PR review: >> - remove unnecessary new_thread NULL checks >> - adjust some comments >> - fix whitespace > > src/hotspot/share/compiler/compileBroker.cpp line 939: > >> 937: && comp->num_compiler_threads() > 0) { >> 938: // The new thread is not known to Thread-SMR yet so we can just delete. >> 939: delete new_thread; > > Need `new_thread != NULL` check if you do as I suggested in previous comment. I don't think so, you can apply `delete` to a NULL pointer (whereas previously we could not call `smr_delete` on a NULL pointer. ------------- PR: https://git.openjdk.java.net/jdk/pull/4629 From dholmes at openjdk.java.net Thu Jul 1 22:05:59 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 1 Jul 2021 22:05:59 GMT Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v3] In-Reply-To: <1ywsxUI_B9ZGVP_Us0O5lecBx4qtglIzGSI6hVXz6gM=.ad566e05-2bdd-4bb9-a5f5-bdb38c768a3a@github.com> References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> <1ywsxUI_B9ZGVP_Us0O5lecBx4qtglIzGSI6hVXz6gM=.ad566e05-2bdd-4bb9-a5f5-bdb38c768a3a@github.com> Message-ID: On Thu, 1 Jul 2021 17:33:02 GMT, Coleen Phillimore wrote: >> src/hotspot/share/compiler/compileBroker.cpp line 909: >> >>> 907: // JavaThread due to lack of resources. We will handle that failure below. >>> 908: >>> 909: if (new_thread->osthread() != NULL) { >> >> I think you do need to check `new_thread != NULL` here to please Parfait for `default:` case. > > Really? We have this sort of code everywhere. We don't check the result of a new expression anywhere else. It isn't the result of the new expression that needs checking. The switch statement has a default: clause which calls ShouldNotReachHere(). IIRC Parfait does not understand things like ShouldNotReachHere() never return, and so it thinks "new_thread" may still be NULL if we followed the default: path through the switch. I will restore this NULL check with a comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/4629 From dholmes at openjdk.java.net Thu Jul 1 22:12:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 1 Jul 2021 22:12:06 GMT Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v3] In-Reply-To: References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> Message-ID: On Thu, 1 Jul 2021 12:07:10 GMT, Coleen Phillimore wrote: >> David Holmes has updated the pull request incrementally with three additional commits since the last revision: >> >> - Rename vm_exit_on_thread_allocation_failure to vm_exit_on_osthread_failure >> - Adjust comment >> - Comments from PR review: >> - remove unnecessary new_thread NULL checks >> - adjust some comments >> - fix whitespace > > src/hotspot/share/runtime/thread.cpp line 3910: > >> 3908: Handle thread_oop, ThreadPriority prio) { >> 3909: MutexLocker mu(current, Threads_lock); >> 3910: > > Could you add an assert that target->os_thread() != NULL here? Just to make sure everything checked. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/4629 From dholmes at openjdk.java.net Thu Jul 1 22:17:27 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 1 Jul 2021 22:17:27 GMT Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v4] In-Reply-To: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> Message-ID: > Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread. > > This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE. > > The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock. > > A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary). > > The trickiest changes related to the CompilerThreads, so they need particular scrutiny. > > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Restore null check to appease static analysis. Add assertion on osthread() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4629/files - new: https://git.openjdk.java.net/jdk/pull/4629/files/8275b184..c081ea69 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4629&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4629&range=02-03 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4629.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4629/head:pull/4629 PR: https://git.openjdk.java.net/jdk/pull/4629 From david.holmes at oracle.com Thu Jul 1 22:45:32 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 2 Jul 2021 08:45:32 +1000 Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v3] In-Reply-To: References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> Message-ID: <977fa56f-0d49-4283-ac06-8bda8684fb8b@oracle.com> Thanks for the review Serguei! David On 2/07/2021 2:30 am, Serguei Spitsyn wrote: > On Thu, 1 Jul 2021 04:18:28 GMT, David Holmes wrote: > >>> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread. >>> >>> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE. >>> >>> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock. >>> >>> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary). >>> >>> The trickiest changes related to the CompilerThreads, so they need particular scrutiny. >>> >>> Testing: tiers 1-3 >>> >>> Thanks, >>> David >> >> David Holmes has updated the pull request incrementally with three additional commits since the last revision: >> >> - Rename vm_exit_on_thread_allocation_failure to vm_exit_on_osthread_failure >> - Adjust comment >> - Comments from PR review: >> - remove unnecessary new_thread NULL checks >> - adjust some comments >> - fix whitespace > > Marked as reviewed by sspitsyn (Reviewer). > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4629 > From kvn at openjdk.java.net Thu Jul 1 22:54:05 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 1 Jul 2021 22:54:05 GMT Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v4] In-Reply-To: References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> Message-ID: On Thu, 1 Jul 2021 22:17:27 GMT, David Holmes wrote: >> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread. >> >> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE. >> >> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock. >> >> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary). >> >> The trickiest changes related to the CompilerThreads, so they need particular scrutiny. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Restore null check to appease static analysis. > Add assertion on osthread() Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4629 From kvn at openjdk.java.net Thu Jul 1 22:54:06 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 1 Jul 2021 22:54:06 GMT Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v3] In-Reply-To: References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> <2kQHKSNGqbk-Y9Yqo8GbuZS4n4DCb7W_-yE9mKB_-vQ=.d20b8dcd-78a1-4ce3-9875-1e3d36b608b1@github.com> Message-ID: On Thu, 1 Jul 2021 22:02:40 GMT, David Holmes wrote: >> src/hotspot/share/compiler/compileBroker.cpp line 939: >> >>> 937: && comp->num_compiler_threads() > 0) { >>> 938: // The new thread is not known to Thread-SMR yet so we can just delete. >>> 939: delete new_thread; >> >> Need `new_thread != NULL` check if you do as I suggested in previous comment. > > I don't think so, you can apply `delete` to a NULL pointer (whereas previously we could not call `smr_delete` on a NULL pointer. okay then. ------------- PR: https://git.openjdk.java.net/jdk/pull/4629 From dholmes at openjdk.java.net Fri Jul 2 01:22:00 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 2 Jul 2021 01:22:00 GMT Subject: RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 17:28:48 GMT, Severin Gehwolf wrote: > This fix simplifies the `if` condition to use a default 64-bit library path including default setting when `_LP64` is defined (os has 64-bitness). This should be safe IMHO and seems better than explicitly enumerating all 64 bit Linux architectures. An alternative patch would be: > > > diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp > index 4ebf50ef0d3..5db22f8dff3 100644 > --- a/src/hotspot/os/linux/os_linux.cpp > +++ b/src/hotspot/os/linux/os_linux.cpp > @@ -412,7 +412,7 @@ void os::init_system_properties_values() { > // ... > // 7: The default directories, normally /lib and /usr/lib. > #ifndef OVERRIDE_LIBPATH > - #if defined(AMD64) || (defined(_LP64) && defined(SPARC)) || defined(PPC64) || defined(S390) > + #if defined(AMD64) || (defined(_LP64) && defined(SPARC)) || defined(PPC64) || defined(S390) || defined(AARCH64) > #define DEFAULT_LIBPATH "/usr/lib64:/lib64:/lib:/usr/lib" > #else > #define DEFAULT_LIBPATH "/lib:/usr/lib" > > > This issue affects older releases and I'd like to get this fix into JDK 17 too. With that in mind, please let me know what the preference is. Note that SPARC support has been removed with JEP 381 in JDK 15. Thoughts? Hi Severin, I think this is a good simplifying change. I also think it is fine for 17. I've bumped the JBS issue to P3 with a justification. You can either re-do a PR for 17 (which will automatically get forward ported to 18) or else fix in 18 and manually backport. The former is preferable IMO. It needs to be done soon though as RDP2 approaches. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4657 From dholmes at openjdk.java.net Fri Jul 2 04:33:07 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 2 Jul 2021 04:33:07 GMT Subject: RFR: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads [v2] In-Reply-To: References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> Message-ID: On Wed, 30 Jun 2021 15:54:12 GMT, Patricio Chilano Mateo wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed copyright years in hpp files > > Hi David, > > Changes look good to me. > > Thanks, > Patricio Thanks for the reviews: @pchilano , @coleenp , @dcubed-ojdk , @sspitsyn , @vnkozlov ------------- PR: https://git.openjdk.java.net/jdk/pull/4629 From dholmes at openjdk.java.net Fri Jul 2 04:33:08 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 2 Jul 2021 04:33:08 GMT Subject: Integrated: 8269466: Factor out the common code for initializing and starting internal VM JavaThreads In-Reply-To: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com> Message-ID: On Tue, 29 Jun 2021 21:55:04 GMT, David Holmes wrote: > Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread. > > This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE. > > The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock. > > A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary). > > The trickiest changes related to the CompilerThreads, so they need particular scrutiny. > > Testing: tiers 1-3 > > Thanks, > David This pull request has now been integrated. Changeset: 4107dcf6 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/4107dcf6ec3fb7fd6eb0e12cdc404a2dee9ccaa1 Stats: 284 lines in 13 files changed: 65 ins; 138 del; 81 mod 8269466: Factor out the common code for initializing and starting internal VM JavaThreads Reviewed-by: sspitsyn, pchilanomate, dcubed, coleenp, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/4629 From dholmes at openjdk.java.net Fri Jul 2 07:16:13 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 2 Jul 2021 07:16:13 GMT Subject: RFR: 8269652: Factor out the common code for creating system j.l.Thread objects Message-ID: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> Please review this simple refactoring to share the common code used to create j.l.Thread instances for the internal VM JavaThreads. (Also fix a missing space from my previous change in thread.cpp.) It is all very straight-forward. Compiler folk I can go one step further and remove CompileBroker::create_thread_oop if desired. Testing: tiers 1-3, GHA Thanks, David ------------- Commit messages: - 8269652: Factor out the common code for creating system j.l.Thread objects Changes: https://git.openjdk.java.net/jdk/pull/4663/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4663&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269652 Stats: 140 lines in 8 files changed: 43 ins; 87 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4663/head:pull/4663 PR: https://git.openjdk.java.net/jdk/pull/4663 From sgehwolf at openjdk.java.net Fri Jul 2 07:58:05 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 2 Jul 2021 07:58:05 GMT Subject: Withdrawn: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 17:28:48 GMT, Severin Gehwolf wrote: > This fix simplifies the `if` condition to use a default 64-bit library path including default setting when `_LP64` is defined (os has 64-bitness). This should be safe IMHO and seems better than explicitly enumerating all 64 bit Linux architectures. An alternative patch would be: > > > diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp > index 4ebf50ef0d3..5db22f8dff3 100644 > --- a/src/hotspot/os/linux/os_linux.cpp > +++ b/src/hotspot/os/linux/os_linux.cpp > @@ -412,7 +412,7 @@ void os::init_system_properties_values() { > // ... > // 7: The default directories, normally /lib and /usr/lib. > #ifndef OVERRIDE_LIBPATH > - #if defined(AMD64) || (defined(_LP64) && defined(SPARC)) || defined(PPC64) || defined(S390) > + #if defined(AMD64) || (defined(_LP64) && defined(SPARC)) || defined(PPC64) || defined(S390) || defined(AARCH64) > #define DEFAULT_LIBPATH "/usr/lib64:/lib64:/lib:/usr/lib" > #else > #define DEFAULT_LIBPATH "/lib:/usr/lib" > > > This issue affects older releases and I'd like to get this fix into JDK 17 too. With that in mind, please let me know what the preference is. Note that SPARC support has been removed with JEP 381 in JDK 15. Thoughts? This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4657 From sgehwolf at openjdk.java.net Fri Jul 2 07:58:05 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 2 Jul 2021 07:58:05 GMT Subject: RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 17:28:48 GMT, Severin Gehwolf wrote: > This fix simplifies the `if` condition to use a default 64-bit library path including default setting when `_LP64` is defined (os has 64-bitness). This should be safe IMHO and seems better than explicitly enumerating all 64 bit Linux architectures. An alternative patch would be: > > > diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp > index 4ebf50ef0d3..5db22f8dff3 100644 > --- a/src/hotspot/os/linux/os_linux.cpp > +++ b/src/hotspot/os/linux/os_linux.cpp > @@ -412,7 +412,7 @@ void os::init_system_properties_values() { > // ... > // 7: The default directories, normally /lib and /usr/lib. > #ifndef OVERRIDE_LIBPATH > - #if defined(AMD64) || (defined(_LP64) && defined(SPARC)) || defined(PPC64) || defined(S390) > + #if defined(AMD64) || (defined(_LP64) && defined(SPARC)) || defined(PPC64) || defined(S390) || defined(AARCH64) > #define DEFAULT_LIBPATH "/usr/lib64:/lib64:/lib:/usr/lib" > #else > #define DEFAULT_LIBPATH "/lib:/usr/lib" > > > This issue affects older releases and I'd like to get this fix into JDK 17 too. With that in mind, please let me know what the preference is. Note that SPARC support has been removed with JEP 381 in JDK 15. Thoughts? OK. Re-doing it for JDK 17 then. ------------- PR: https://git.openjdk.java.net/jdk/pull/4657 From sgehwolf at openjdk.java.net Fri Jul 2 08:10:07 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 2 Jul 2021 08:10:07 GMT Subject: RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 17:28:48 GMT, Severin Gehwolf wrote: > This fix simplifies the `if` condition to use a default 64-bit library path including default setting when `_LP64` is defined (os has 64-bitness). This should be safe IMHO and seems better than explicitly enumerating all 64 bit Linux architectures. An alternative patch would be: > > > diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp > index 4ebf50ef0d3..5db22f8dff3 100644 > --- a/src/hotspot/os/linux/os_linux.cpp > +++ b/src/hotspot/os/linux/os_linux.cpp > @@ -412,7 +412,7 @@ void os::init_system_properties_values() { > // ... > // 7: The default directories, normally /lib and /usr/lib. > #ifndef OVERRIDE_LIBPATH > - #if defined(AMD64) || (defined(_LP64) && defined(SPARC)) || defined(PPC64) || defined(S390) > + #if defined(AMD64) || (defined(_LP64) && defined(SPARC)) || defined(PPC64) || defined(S390) || defined(AARCH64) > #define DEFAULT_LIBPATH "/usr/lib64:/lib64:/lib:/usr/lib" > #else > #define DEFAULT_LIBPATH "/lib:/usr/lib" > > > This issue affects older releases and I'd like to get this fix into JDK 17 too. With that in mind, please let me know what the preference is. Note that SPARC support has been removed with JEP 381 in JDK 15. Thoughts? JDK 17 PR is here: https://github.com/openjdk/jdk17/pull/200 ------------- PR: https://git.openjdk.java.net/jdk/pull/4657 From aph at redhat.com Fri Jul 2 08:12:12 2021 From: aph at redhat.com (Andrew Haley) Date: Fri, 2 Jul 2021 09:12:12 +0100 Subject: RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: References: Message-ID: <06f6a2f3-0e3b-15f7-d75e-6914929b8005@redhat.com> On 7/2/21 2:22 AM, David Holmes wrote: > This fix simplifies the `if` condition to use a default 64-bit > library path including default setting when `_LP64` is defined (os > has 64-bitness). This should be safe IMHO and seems better than > explicitly enumerating all 64 bit Linux architectures. An > alternative patch would be: I'm trying to think of ways this might break. I'm not sure about "should be safe". I'm not an expert on Debian and Ubuntu, but AFAIK /usr/lib is the installed system's default arch, with multi-arch stuff like /usr/lib/i386-linux-gnu, etc. On such systems I believe that /usr/lib64 is often symlinked to point to /usr/lib, but it might not be: it wouldn't be completely insane to have some other arrangement. It could be argued that if the Debians want to violate the FHS it's on them to patch around it, but this patch is a change of behaviour, so it may not be entirely safe for back-porting. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at openjdk.java.net Fri Jul 2 08:12:10 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 2 Jul 2021 08:12:10 GMT Subject: [jdk17] RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 Message-ID: This fix simplifies the `if` condition to use a default 64-bit library path including default setting when `_LP64` is defined (os has 64-bitness). This should be safe IMHO and seems better than explicitly enumerating all 64 bit Linux architectures. This issue affects older releases and I'd like to get this fix into JDK 17. Thoughts? ------------- Commit messages: - 8269668: [aarch64] java.library.path not including /usr/lib64 Changes: https://git.openjdk.java.net/jdk17/pull/200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=200&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269668 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/200.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/200/head:pull/200 PR: https://git.openjdk.java.net/jdk17/pull/200 From cgo at openjdk.java.net Fri Jul 2 08:47:03 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Fri, 2 Jul 2021 08:47:03 GMT Subject: RFR: 8269135: TestDifferentProtectionDomains runs into timeout in client VM [v2] In-Reply-To: <7q8s-FfshjTWLoRa0VNJyqt1mLqiKt3SQ1PKRbfokNI=.adfc440f-b3c8-4476-a055-2f90d557180e@github.com> References: <7q8s-FfshjTWLoRa0VNJyqt1mLqiKt3SQ1PKRbfokNI=.adfc440f-b3c8-4476-a055-2f90d557180e@github.com> Message-ID: On Wed, 23 Jun 2021 10:44:53 GMT, Christoph G?ttschkes wrote: >> The test tries to compile a method using the WhiteBox with optimization level 4, which is not available in client VMs. The WhiteBox only prints out a warning, and the call to enqueueMethodForCompilation succeeds. After that, the test case goes into an endless loop to wait for the compilation to finish, which never happens, because the method is not enqueued for compilation. >> >> I fixed this by choosing a different compilation level, if C2 is not included in the JVM. I think this test should be enough, since there is already an `@requires` which checks, that we are in mixed mode and that C2 should be used. >> >> In addition, I bound the loop in order to fail with a timeout more early, if the compilation does not happen (or takes too long because of platform restrictions). > > Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: > > Adds requires compiler2 & revert compilation level detection. Hearing no objections, I guess we can integrate it then? ------------- PR: https://git.openjdk.java.net/jdk/pull/4558 From aph at openjdk.java.net Fri Jul 2 08:48:01 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 2 Jul 2021 08:48:01 GMT Subject: [jdk17] RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 08:06:07 GMT, Severin Gehwolf wrote: > This fix simplifies the `if` condition to use a default 64-bit library path including default setting when `_LP64` is defined (os has 64-bitness). This should be safe IMHO and seems better than explicitly enumerating all 64 bit Linux architectures. > > This issue affects older releases and I'd like to get this fix into JDK 17. Thoughts? I'm trying to think of ways this might break. I'm not sure about "should be safe". I'm not an expert on Debian and Ubuntu, but AFAIK /usr/lib is the installed system's default arch, with multi-arch stuff like /usr/lib/i386-linux-gnu, etc. On such systems I believe that /usr/lib64 is often symlinked to point to ------------- PR: https://git.openjdk.java.net/jdk17/pull/200 From sgehwolf at openjdk.java.net Fri Jul 2 09:24:06 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 2 Jul 2021 09:24:06 GMT Subject: [jdk17] RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: References: Message-ID: <3oEzc3iC1Vp6rXOfzOSvkqdeNBpy7R4z7Ehhcet88Kk=.420b8f4e-14f9-4e42-8b17-14e381a0dac1@github.com> On Fri, 2 Jul 2021 08:44:44 GMT, Andrew Haley wrote: > I'm trying to think of ways this might break. Good, thanks! I came up empty where adding 64-bit paths in addition (and earlier on the lookup path) might actually be a problem. > I'm not sure about "should be safe". :) That comment was meant to be seen in the context of JDK 17/18. I agree for backporting I'd rather use the alternative patch as suggested in https://github.com/openjdk/jdk/pull/4657. Now, in the context of JDK 17 (and JDK 18) which has the SPARC port removed, it seems that simplification does make sense. It might not be 100% safe, I agree. > I'm not an expert on Debian and > Ubuntu, but AFAIK /usr/lib is the installed system's default arch, > with multi-arch stuff like /usr/lib/i386-linux-gnu, etc. On such > systems I believe that /usr/lib64 is often symlinked to point to > /usr/lib, but it might not be: it wouldn't be completely insane to > have some other arrangement. It could be argued that if the Debians > want to violate the FHS it's on them to patch around it, but this > patch is a change of behaviour, so it may not be entirely safe for > back-porting. Yes, agreed. Not safe for backporting. ------------- PR: https://git.openjdk.java.net/jdk17/pull/200 From dholmes at openjdk.java.net Fri Jul 2 10:58:00 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 2 Jul 2021 10:58:00 GMT Subject: [jdk17] RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 08:06:07 GMT, Severin Gehwolf wrote: > This fix simplifies the `if` condition to use a default 64-bit library path including default setting when `_LP64` is defined (os has 64-bitness). This should be safe IMHO and seems better than explicitly enumerating all 64 bit Linux architectures. > > This issue affects older releases and I'd like to get this fix into JDK 17. Thoughts? I'm a bit confused. On all 64-bit Linux platforms we set the same default paths, but the change for Aarch64 was overlooked. So unless these distributions set different paths for different architectures surely we want the same behaviour on all Linux platforms? ------------- PR: https://git.openjdk.java.net/jdk17/pull/200 From aph at openjdk.java.net Fri Jul 2 11:12:58 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 2 Jul 2021 11:12:58 GMT Subject: [jdk17] RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: References: Message-ID: <-XsOSE-ikOOD6Yjm-wGtp2ZlfpjqaOxcDDSAgZohTF4=.3401e095-868b-4f37-8450-cd132bc03a48@github.com> On Fri, 2 Jul 2021 10:55:17 GMT, David Holmes wrote: > I'm a bit confused. On all 64-bit Linux platforms we set the same default paths, but the change for Aarch64 was overlooked. So unless these distributions set different paths for different architectures surely we want the same behaviour on all Linux platforms? We do now, sure, except for platforms that use "/lib" for 64-bit libraries. These days "/lib64" is used on all FHS-compliant systems, but Debian is not FHS-compliant and some Linux systems date from before "/lib64" was decided on ------------- PR: https://git.openjdk.java.net/jdk17/pull/200 From sgehwolf at openjdk.java.net Fri Jul 2 12:06:01 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 2 Jul 2021 12:06:01 GMT Subject: [jdk17] RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: <-XsOSE-ikOOD6Yjm-wGtp2ZlfpjqaOxcDDSAgZohTF4=.3401e095-868b-4f37-8450-cd132bc03a48@github.com> References: <-XsOSE-ikOOD6Yjm-wGtp2ZlfpjqaOxcDDSAgZohTF4=.3401e095-868b-4f37-8450-cd132bc03a48@github.com> Message-ID: On Fri, 2 Jul 2021 11:09:39 GMT, Andrew Haley wrote: > > I'm a bit confused. On all 64-bit Linux platforms we set the same default paths, but the change for Aarch64 was overlooked. So unless these distributions set different paths for different architectures surely we want the same behaviour on all Linux platforms? > > We do now, sure, except for platforms that use "/lib" for 64-bit libraries. These days "/lib64" is used on all FHS-compliant systems, but Debian is not FHS-compliant and some Linux systems date from before "/lib64" was decided on Considering a platform that has a 64-bit library `foo` in `/lib` (over `/lib64`), then a call to `System.loadLibrary("foo")` would continue to work (as this patch just adds more default paths). It would only break on those systems that have `/lib64/libfoo.so` *and* `/lib/libfoo.so` where the former is actually different. I wonder how likely this is. For ppc64, s390x, amd64 we already have the 64-bit including default paths. In addition, since JDK-8214332 - JDK 12 -, there is `--with-jni-libpath` configure option to override all that. All things considered, the post-patch fallback default library path seems reasonable. ------------- PR: https://git.openjdk.java.net/jdk17/pull/200 From aph at openjdk.java.net Fri Jul 2 12:34:59 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 2 Jul 2021 12:34:59 GMT Subject: [jdk17] RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 08:06:07 GMT, Severin Gehwolf wrote: > This fix simplifies the `if` condition to use a default 64-bit library path including default setting when `_LP64` is defined (os has 64-bitness). This should be safe IMHO and seems better than explicitly enumerating all 64 bit Linux architectures. > > This issue affects older releases and I'd like to get this fix into JDK 17. Thoughts? > Considering a platform that has a 64-bit library `foo` in `/lib` (over `/lib64`), then a call to `System.loadLibrary("foo")` would continue to work (as this patch just adds more default paths). It would only break on those systems that have `/lib64/libfoo.so` _and_ `/lib/libfoo.so` where the former is actually different. I wonder how likely this is. For ppc64, s390x, amd64 we already have the 64-bit including default paths. In addition, since JDK-8214332 - JDK 12 -, there is `--with-jni-libpath` configure option to override all that. > > All things considered, the post-patch fallback default library path seems reasonable. Make it `/lib:/lib64` for backports and you don't have to worry about that possibility. All this nonsense could be avoided if we used ldconfig rather than hard-coded strings, but we are where we are. ------------- PR: https://git.openjdk.java.net/jdk17/pull/200 From sgehwolf at openjdk.java.net Fri Jul 2 13:14:58 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 2 Jul 2021 13:14:58 GMT Subject: [jdk17] RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: References: Message-ID: <1Ai242SIxOM3fmCZCppEVmsL8SJ15-Ym-xu5lo33IFI=.53d55487-0f8b-4d62-8674-6f7d557b89d6@github.com> On Fri, 2 Jul 2021 12:31:56 GMT, Andrew Haley wrote: > Make it `/lib:/lib64` for backports and you don't have to worry about that possibility. Yes, I'll be sure to not go straight to backporting this patch verbatim. A more conservative fix would be needed there. ------------- PR: https://git.openjdk.java.net/jdk17/pull/200 From sgehwolf at openjdk.java.net Fri Jul 2 13:14:58 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 2 Jul 2021 13:14:58 GMT Subject: [jdk17] RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 08:06:07 GMT, Severin Gehwolf wrote: > This fix simplifies the `if` condition to use a default 64-bit library path including default setting when `_LP64` is defined (os has 64-bitness). This should be safe IMHO and seems better than explicitly enumerating all 64 bit Linux architectures. > > This issue affects older releases and I'd like to get this fix into JDK 17. Thoughts? OK for JDK 17? ------------- PR: https://git.openjdk.java.net/jdk17/pull/200 From aph at openjdk.java.net Fri Jul 2 14:50:49 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 2 Jul 2021 14:50:49 GMT Subject: [jdk17] RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 08:06:07 GMT, Severin Gehwolf wrote: > This fix simplifies the `if` condition to use a default 64-bit library path including default setting when `_LP64` is defined (os has 64-bitness). This should be safe IMHO and seems better than explicitly enumerating all 64 bit Linux architectures. > > This issue affects older releases and I'd like to get this fix into JDK 17. Thoughts? Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/200 From dcubed at openjdk.java.net Fri Jul 2 15:14:58 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 2 Jul 2021 15:14:58 GMT Subject: RFR: 8269135: TestDifferentProtectionDomains runs into timeout in client VM [v2] In-Reply-To: <7q8s-FfshjTWLoRa0VNJyqt1mLqiKt3SQ1PKRbfokNI=.adfc440f-b3c8-4476-a055-2f90d557180e@github.com> References: <7q8s-FfshjTWLoRa0VNJyqt1mLqiKt3SQ1PKRbfokNI=.adfc440f-b3c8-4476-a055-2f90d557180e@github.com> Message-ID: On Wed, 23 Jun 2021 10:44:53 GMT, Christoph G?ttschkes wrote: >> The test tries to compile a method using the WhiteBox with optimization level 4, which is not available in client VMs. The WhiteBox only prints out a warning, and the call to enqueueMethodForCompilation succeeds. After that, the test case goes into an endless loop to wait for the compilation to finish, which never happens, because the method is not enqueued for compilation. >> >> I fixed this by choosing a different compilation level, if C2 is not included in the JVM. I think this test should be enough, since there is already an `@requires` which checks, that we are in mixed mode and that C2 should be used. >> >> In addition, I bound the loop in order to fail with a timeout more early, if the compilation does not happen (or takes too long because of platform restrictions). > > Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: > > Adds requires compiler2 & revert compilation level detection. HotSpot changes require two reviewers and it doesn't look like @eastig has marked this PR as reviewed. I've gone ahead and reviewed your changes. Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4558 From cgo at openjdk.java.net Fri Jul 2 15:19:55 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Fri, 2 Jul 2021 15:19:55 GMT Subject: Integrated: 8269135: TestDifferentProtectionDomains runs into timeout in client VM In-Reply-To: References: Message-ID: <9CSG-_JYs3BsmDComwgsTjsvkkapM_x03LYTk6WC_lQ=.533bf306-7222-4e35-b973-43399abffcd3@github.com> On Tue, 22 Jun 2021 13:34:43 GMT, Christoph G?ttschkes wrote: > The test tries to compile a method using the WhiteBox with optimization level 4, which is not available in client VMs. The WhiteBox only prints out a warning, and the call to enqueueMethodForCompilation succeeds. After that, the test case goes into an endless loop to wait for the compilation to finish, which never happens, because the method is not enqueued for compilation. > > I fixed this by choosing a different compilation level, if C2 is not included in the JVM. I think this test should be enough, since there is already an `@requires` which checks, that we are in mixed mode and that C2 should be used. > > In addition, I bound the loop in order to fail with a timeout more early, if the compilation does not happen (or takes too long because of platform restrictions). This pull request has now been integrated. Changeset: 53ad903a Author: Christoph G?ttschkes Committer: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/53ad903a820b6892dbb273357defe7cf5c7e24ab Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod 8269135: TestDifferentProtectionDomains runs into timeout in client VM Reviewed-by: dholmes, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/4558 From dcubed at openjdk.java.net Fri Jul 2 16:16:12 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 2 Jul 2021 16:16:12 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced Message-ID: This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this piece of history that I'm finally getting around to cleaning up. While this macro has been with us for a long time, its time has passed... Tested with Mach5 Tier[1-3]. ------------- Commit messages: - 8193559.cr0 Changes: https://git.openjdk.java.net/jdk/pull/4671/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4671&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8193559 Stats: 22 lines in 1 file changed: 8 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/4671.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4671/head:pull/4671 PR: https://git.openjdk.java.net/jdk/pull/4671 From ccheung at openjdk.java.net Fri Jul 2 18:02:53 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 2 Jul 2021 18:02:53 GMT Subject: RFR: 8264735: Make dynamic dump repeatable In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 02:39:07 GMT, Yumin Qi wrote: > Hi, Please review > > Currently after dynamic dump, dump time tables (`_dumptime_talbles, _dumptime_lambda_proxy_class_dictionary and _saved_shared_path_table`) are corrupted and could not be used for next dump. The patch clones the three tables, and after dump restore them so the next dump is possible. With the fix, jcmd VM.cds dynamic_dump can do multiple dump to the same live process. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Looks good. I have a few minor comments. src/hotspot/share/cds/dumpTimeClassInfo.cpp line 73: > 71: } > 72: if (_verifier_constraint_flags == NULL) { > 73: _verifier_constraint_flags = new (ResourceObj::C_HEAP, mtClass) GrowableArray(4, mtClass); Why add extra blank space after "new"? src/hotspot/share/cds/dynamicArchive.cpp line 167: > 165: post_dump(); > 166: > 167: // Restore dumptime talbes Typo: talbes -> tables src/hotspot/share/cds/filemap.cpp line 492: > 490: "No modular java runtime image present when allocating the CDS classpath entry table"); > 491: > 492: // After dynamic dump, _saved_shared_path_table is corrupt, can not be used again. Typo: can not -> cannot src/hotspot/share/cds/lambdaProxyClassDictionary.hpp line 113: > 111: void add_proxy_klass(InstanceKlass* proxy_klass) { > 112: if (_proxy_klasses == NULL) { > 113: _proxy_klasses = new (ResourceObj::C_HEAP, mtClassShared) GrowableArray(5, mtClassShared); Extra blank space added before ?GrowableArray?. src/hotspot/share/classfile/systemDictionaryShared.cpp line 1554: > 1552: } > 1553: bool do_entry(InstanceKlass* k, DumpTimeClassInfo& info) { > 1554: if (!info.is_excluded()) { Should assert_lock_strong(DumpTimeTable_lock) be added like at line 1574 below? src/hotspot/share/classfile/systemDictionaryShared.cpp line 1605: > 1603: > 1604: void SystemDictionaryShared::restore_dumptime_tables() { > 1605: // FileMapInfo::clean_cloned_shared_path_table(); Please delete line 1605 if it is not needed. ------------- Changes requested by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4646 From coleenp at openjdk.java.net Fri Jul 2 18:27:53 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 2 Jul 2021 18:27:53 GMT Subject: RFR: 8269652: Factor out the common code for creating system j.l.Thread objects In-Reply-To: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> References: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> Message-ID: <2if4Yfi5AupNoZkYgFgL65wuh7ij4Un5fSQSFQWEWEU=.2b8b6b68-66e3-4f2a-9d99-169fbb24b797@github.com> On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes wrote: > Please review this simple refactoring to share the common code used to create j.l.Thread instances for the internal VM JavaThreads. (Also fix a missing space from my previous change in thread.cpp.) > > It is all very straight-forward. > > Compiler folk I can go one step further and remove CompileBroker::create_thread_oop if desired. > > Testing: tiers 1-3, GHA > > Thanks, > David Looks good! Explains the difference between the cases that add to the threadGroup and the ones that don't. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4663 From minqi at openjdk.java.net Fri Jul 2 19:10:53 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 2 Jul 2021 19:10:53 GMT Subject: RFR: 8264735: Make dynamic dump repeatable In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 17:58:54 GMT, Calvin Cheung wrote: >> Hi, Please review >> >> Currently after dynamic dump, dump time tables (`_dumptime_talbles, _dumptime_lambda_proxy_class_dictionary and _saved_shared_path_table`) are corrupted and could not be used for next dump. The patch clones the three tables, and after dump restore them so the next dump is possible. With the fix, jcmd VM.cds dynamic_dump can do multiple dump to the same live process. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > src/hotspot/share/cds/dumpTimeClassInfo.cpp line 73: > >> 71: } >> 72: if (_verifier_constraint_flags == NULL) { >> 73: _verifier_constraint_flags = new (ResourceObj::C_HEAP, mtClass) GrowableArray(4, mtClass); > > Why add extra blank space after "new"? To keep consistent usage style of operator 'new'. > src/hotspot/share/cds/filemap.cpp line 492: > >> 490: "No modular java runtime image present when allocating the CDS classpath entry table"); >> 491: >> 492: // After dynamic dump, _saved_shared_path_table is corrupt, can not be used again. > > Typo: can not -> cannot Will update. > src/hotspot/share/cds/lambdaProxyClassDictionary.hpp line 113: > >> 111: void add_proxy_klass(InstanceKlass* proxy_klass) { >> 112: if (_proxy_klasses == NULL) { >> 113: _proxy_klasses = new (ResourceObj::C_HEAP, mtClassShared) GrowableArray(5, mtClassShared); > > Extra blank space added before ?GrowableArray?. The usage style is like new (args...) type. This has been in hotspot and just want to keep with that. > src/hotspot/share/classfile/systemDictionaryShared.cpp line 1605: > >> 1603: >> 1604: void SystemDictionaryShared::restore_dumptime_tables() { >> 1605: // FileMapInfo::clean_cloned_shared_path_table(); > > Please delete line 1605 if it is not needed. Ah, forget to delete it. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/4646 From minqi at openjdk.java.net Fri Jul 2 19:18:52 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 2 Jul 2021 19:18:52 GMT Subject: RFR: 8264735: Make dynamic dump repeatable In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 17:59:35 GMT, Calvin Cheung wrote: >> Hi, Please review >> >> Currently after dynamic dump, dump time tables (`_dumptime_talbles, _dumptime_lambda_proxy_class_dictionary and _saved_shared_path_table`) are corrupted and could not be used for next dump. The patch clones the three tables, and after dump restore them so the next dump is possible. With the fix, jcmd VM.cds dynamic_dump can do multiple dump to the same live process. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > src/hotspot/share/classfile/systemDictionaryShared.cpp line 1554: > >> 1552: } >> 1553: bool do_entry(InstanceKlass* k, DumpTimeClassInfo& info) { >> 1554: if (!info.is_excluded()) { > > Should assert_lock_strong(DumpTimeTable_lock) be added like at line 1574 below? should check lock, thank. ------------- PR: https://git.openjdk.java.net/jdk/pull/4646 From github.com+42899633+eastig at openjdk.java.net Fri Jul 2 20:11:56 2021 From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich) Date: Fri, 2 Jul 2021 20:11:56 GMT Subject: RFR: 8269135: TestDifferentProtectionDomains runs into timeout in client VM [v2] In-Reply-To: <7q8s-FfshjTWLoRa0VNJyqt1mLqiKt3SQ1PKRbfokNI=.adfc440f-b3c8-4476-a055-2f90d557180e@github.com> References: <7q8s-FfshjTWLoRa0VNJyqt1mLqiKt3SQ1PKRbfokNI=.adfc440f-b3c8-4476-a055-2f90d557180e@github.com> Message-ID: On Wed, 23 Jun 2021 10:44:53 GMT, Christoph G?ttschkes wrote: >> The test tries to compile a method using the WhiteBox with optimization level 4, which is not available in client VMs. The WhiteBox only prints out a warning, and the call to enqueueMethodForCompilation succeeds. After that, the test case goes into an endless loop to wait for the compilation to finish, which never happens, because the method is not enqueued for compilation. >> >> I fixed this by choosing a different compilation level, if C2 is not included in the JVM. I think this test should be enough, since there is already an `@requires` which checks, that we are in mixed mode and that C2 should be used. >> >> In addition, I bound the loop in order to fail with a timeout more early, if the compilation does not happen (or takes too long because of platform restrictions). > > Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: > > Adds requires compiler2 & revert compilation level detection. Sorry for missing this. LGTM. ------------- PR: https://git.openjdk.java.net/jdk/pull/4558 From minqi at openjdk.java.net Fri Jul 2 20:12:23 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 2 Jul 2021 20:12:23 GMT Subject: RFR: 8264735: Make dynamic dump repeatable [v2] In-Reply-To: References: Message-ID: > Hi, Please review > > Currently after dynamic dump, dump time tables (`_dumptime_talbles, _dumptime_lambda_proxy_class_dictionary and _saved_shared_path_table`) are corrupted and could not be used for next dump. The patch clones the three tables, and after dump restore them so the next dump is possible. With the fix, jcmd VM.cds dynamic_dump can do multiple dump to the same live process. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fix comments, added check holding for DumpTimeTable_lock ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4646/files - new: https://git.openjdk.java.net/jdk/pull/4646/files/6245a80e..9b64a16f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4646&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4646&range=00-01 Stats: 5 lines in 3 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4646/head:pull/4646 PR: https://git.openjdk.java.net/jdk/pull/4646 From eosterlund at openjdk.java.net Fri Jul 2 21:01:52 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 2 Jul 2021 21:01:52 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 16:03:57 GMT, Daniel D. Daugherty wrote: > This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." > Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this > piece of history that I'm finally getting around to cleaning up. While this macro has > been with us for a long time, its time has passed... > > Tested with Mach5 Tier[1-3]. Goodbye ugly macro. You have served us well. Looks good Dan. Thanks for cleaning up. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4671 From dcubed at openjdk.java.net Fri Jul 2 21:12:48 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 2 Jul 2021 21:12:48 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 20:58:23 GMT, Erik ?sterlund wrote: >> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." >> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this >> piece of history that I'm finally getting around to cleaning up. While this macro has >> been with us for a long time, its time has passed... >> >> Tested with Mach5 Tier[1-3]. > > Goodbye ugly macro. You have served us well. Looks good Dan. Thanks for cleaning up. @fisk - Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From ayang at openjdk.java.net Fri Jul 2 21:45:48 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 2 Jul 2021 21:45:48 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 16:03:57 GMT, Daniel D. Daugherty wrote: > This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." > Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this > piece of history that I'm finally getting around to cleaning up. While this macro has > been with us for a long time, its time has passed... > > Tested with Mach5 Tier[1-3]. Marked as reviewed by ayang (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From dcubed at openjdk.java.net Fri Jul 2 21:58:51 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 2 Jul 2021 21:58:51 GMT Subject: RFR: 8269652: Factor out the common code for creating system j.l.Thread objects In-Reply-To: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> References: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> Message-ID: On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes wrote: > Please review this simple refactoring to share the common code used to create j.l.Thread instances for the internal VM JavaThreads. (Also fix a missing space from my previous change in thread.cpp.) > > It is all very straight-forward. > > Compiler folk I can go one step further and remove CompileBroker::create_thread_oop if desired. > > Testing: tiers 1-3, GHA > > Thanks, > David Very nice cleanup. Thumbs up! ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4663 From kbarrett at openjdk.java.net Fri Jul 2 21:59:52 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 2 Jul 2021 21:59:52 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 16:03:57 GMT, Daniel D. Daugherty wrote: > This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." > Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this > piece of history that I'm finally getting around to cleaning up. While this macro has > been with us for a long time, its time has passed... > > Tested with Mach5 Tier[1-3]. Changes requested by kbarrett (Reviewer). src/hotspot/share/runtime/thread.cpp line 2470: > 2468: > 2469: JavaThreadPrefetchedIterator(ThreadsList* list) : > 2470: _list(list), _end(list->threads() + list->length()), _current(list->threads()) {} I don't see any uses of the `_list` member. src/hotspot/share/runtime/thread.cpp line 2484: > 2482: > 2483: #define DO_JAVA_THREADS(LIST, X) \ > 2484: for (JavaThreadPrefetchedIterator iter(LIST); JavaThread* X = iter.current(); iter.next()) The condition is an implicit conversion to bool, which is disallowed by the style guide. In fact, it's a declaration, which is specifically called out by the style guide. When I revised the style guide I made explicit mention of that usage because I'd tried to use that sort of thing several years ago and got several complaints. So it's not that I personally think that usage is bad; rather, I was hoping someone would take on the little project of convincing the team it was good. I don't have any objection to this part of the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From david.holmes at oracle.com Fri Jul 2 22:55:08 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 3 Jul 2021 08:55:08 +1000 Subject: RFR: 8269652: Factor out the common code for creating system j.l.Thread objects In-Reply-To: <2if4Yfi5AupNoZkYgFgL65wuh7ij4Un5fSQSFQWEWEU=.2b8b6b68-66e3-4f2a-9d99-169fbb24b797@github.com> References: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> <2if4Yfi5AupNoZkYgFgL65wuh7ij4Un5fSQSFQWEWEU=.2b8b6b68-66e3-4f2a-9d99-169fbb24b797@github.com> Message-ID: <91e57b6e-dba1-9596-4a27-866b997033a8@oracle.com> On 3/07/2021 4:27 am, Coleen Phillimore wrote: > On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes wrote: > >> Please review this simple refactoring to share the common code used to create j.l.Thread instances for the internal VM JavaThreads. (Also fix a missing space from my previous change in thread.cpp.) >> >> It is all very straight-forward. >> >> Compiler folk I can go one step further and remove CompileBroker::create_thread_oop if desired. >> >> Testing: tiers 1-3, GHA >> >> Thanks, >> David > > Looks good! Explains the difference between the cases that add to the threadGroup and the ones that don't. Thanks for the review Coleen. David > ------------- > > Marked as reviewed by coleenp (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/4663 > From david.holmes at oracle.com Fri Jul 2 22:55:26 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 3 Jul 2021 08:55:26 +1000 Subject: RFR: 8269652: Factor out the common code for creating system j.l.Thread objects In-Reply-To: References: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> Message-ID: <8e4fdcd1-8039-99fa-727e-7e8179add668@oracle.com> On 3/07/2021 7:58 am, Daniel D.Daugherty wrote: > On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes wrote: > >> Please review this simple refactoring to share the common code used to create j.l.Thread instances for the internal VM JavaThreads. (Also fix a missing space from my previous change in thread.cpp.) >> >> It is all very straight-forward. >> >> Compiler folk I can go one step further and remove CompileBroker::create_thread_oop if desired. >> >> Testing: tiers 1-3, GHA >> >> Thanks, >> David > > Very nice cleanup. Thumbs up! Thanks for the review Dan. David > ------------- > > Marked as reviewed by dcubed (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/4663 > From dholmes at openjdk.java.net Fri Jul 2 23:02:49 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 2 Jul 2021 23:02:49 GMT Subject: [jdk17] RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 08:06:07 GMT, Severin Gehwolf wrote: > This fix simplifies the `if` condition to use a default 64-bit library path including default setting when `_LP64` is defined (os has 64-bitness). This should be safe IMHO and seems better than explicitly enumerating all 64 bit Linux architectures. > > This issue affects older releases and I'd like to get this fix into JDK 17. Thoughts? My take is that this should not be an architecture specific setting, so if it is desirable and works on existing x86_64, PPC64 and S390 platforms then it should also be desirable and work for Aarch64. If some distribution differs for a given architecture then that distribution can rebuild with OVERRIDE_LIBPATH as appropriate. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/200 From kvn at openjdk.java.net Sat Jul 3 00:40:52 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 3 Jul 2021 00:40:52 GMT Subject: RFR: 8269652: Factor out the common code for creating system j.l.Thread objects In-Reply-To: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> References: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> Message-ID: <6mrbh5AIZqkSewf1hlOsdbA7RP12nBnHYjhXipl8x0Q=.11fc3e13-4225-400f-9fc2-9bb406f8283d@github.com> On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes wrote: > Please review this simple refactoring to share the common code used to create j.l.Thread instances for the internal VM JavaThreads. (Also fix a missing space from my previous change in thread.cpp.) > > It is all very straight-forward. > > Compiler folk I can go one step further and remove CompileBroker::create_thread_oop if desired. > > Testing: tiers 1-3, GHA > > Thanks, > David Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4663 From xliu at openjdk.java.net Sat Jul 3 03:10:49 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Sat, 3 Jul 2021 03:10:49 GMT Subject: RFR: 8269652: Factor out the common code for creating system j.l.Thread objects In-Reply-To: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> References: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> Message-ID: <8UqudKdKpJvnbPfhzBr-HbbJ5MaLCvRTJhADwAvTjH8=.4e35a805-d46b-4303-853c-f22e410ee2aa@github.com> On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes wrote: > Please review this simple refactoring to share the common code used to create j.l.Thread instances for the internal VM JavaThreads. (Also fix a missing space from my previous change in thread.cpp.) > > It is all very straight-forward. > > Compiler folk I can go one step further and remove CompileBroker::create_thread_oop if desired. > > Testing: tiers 1-3, GHA > > Thanks, > David Hi, David, I found you wrote the same comment twice. one is in thread.hpp. the other one is thread.cpp. Is it necessary? if we only need to keep one copy, should we write comments in header file or impl file? The second thing your change is not exactly same for attachListener.cpp. Originally, it returns if JavaCalls::construct_new_instance() has trouble, ie. `has_init_error(THREAD)` returns true. In your change, you call "add group" but check error later. I guess call "call_special" should throw a java exception instead of just setting its state "AL_NOT_INITIALIZED". Does it matter? Other part of code looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/4663 From dcubed at openjdk.java.net Sat Jul 3 03:40:13 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 3 Jul 2021 03:40:13 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 21:43:15 GMT, Albert Mingkun Yang wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> kbarrett CR - delete unused _list member. > > Marked as reviewed by ayang (Committer). @albertnetymk - Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From dcubed at openjdk.java.net Sat Jul 3 03:40:12 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 3 Jul 2021 03:40:12 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2] In-Reply-To: References: Message-ID: > This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." > Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this > piece of history that I'm finally getting around to cleaning up. While this macro has > been with us for a long time, its time has passed... > > Tested with Mach5 Tier[1-3]. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: kbarrett CR - delete unused _list member. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4671/files - new: https://git.openjdk.java.net/jdk/pull/4671/files/3f653c53..5ee49914 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4671&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4671&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4671.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4671/head:pull/4671 PR: https://git.openjdk.java.net/jdk/pull/4671 From dcubed at openjdk.java.net Sat Jul 3 03:40:15 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 3 Jul 2021 03:40:15 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2] In-Reply-To: References: Message-ID: <3e_ySPWMRm6NSgmQkcdrr_upq-cw8H3lyFfS1yF2_4w=.4dfa82ef-fc62-4354-bab2-a657ce54f1ec@github.com> On Fri, 2 Jul 2021 21:56:55 GMT, Kim Barrett wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> kbarrett CR - delete unused _list member. > > src/hotspot/share/runtime/thread.cpp line 2470: > >> 2468: >> 2469: JavaThreadPrefetchedIterator(ThreadsList* list) : >> 2470: _list(list), _end(list->threads() + list->length()), _current(list->threads()) {} > > I don't see any uses of the `_list` member. Nice catch. I don't see any either. > src/hotspot/share/runtime/thread.cpp line 2484: > >> 2482: >> 2483: #define DO_JAVA_THREADS(LIST, X) \ >> 2484: for (JavaThreadPrefetchedIterator iter(LIST); JavaThread* X = iter.current(); iter.next()) > > The condition is an implicit conversion to bool, which is disallowed > by the style guide. In fact, it's a declaration, which is > specifically called out by the style guide. When I revised the style > guide I made explicit mention of that usage because I'd tried to use > that sort of thing several years ago and got several complaints. So > it's not that I personally think that usage is bad; rather, I was > hoping someone would take on the little project of convincing the team > it was good. I don't have any objection to this part of the change. I'll take a look at fixing that. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From dcubed at openjdk.java.net Sat Jul 3 03:40:15 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 3 Jul 2021 03:40:15 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2] In-Reply-To: <3e_ySPWMRm6NSgmQkcdrr_upq-cw8H3lyFfS1yF2_4w=.4dfa82ef-fc62-4354-bab2-a657ce54f1ec@github.com> References: <3e_ySPWMRm6NSgmQkcdrr_upq-cw8H3lyFfS1yF2_4w=.4dfa82ef-fc62-4354-bab2-a657ce54f1ec@github.com> Message-ID: On Fri, 2 Jul 2021 22:18:08 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/thread.cpp line 2470: >> >>> 2468: >>> 2469: JavaThreadPrefetchedIterator(ThreadsList* list) : >>> 2470: _list(list), _end(list->threads() + list->length()), _current(list->threads()) {} >> >> I don't see any uses of the `_list` member. > > Nice catch. I don't see any either. Fixed that. >> src/hotspot/share/runtime/thread.cpp line 2484: >> >>> 2482: >>> 2483: #define DO_JAVA_THREADS(LIST, X) \ >>> 2484: for (JavaThreadPrefetchedIterator iter(LIST); JavaThread* X = iter.current(); iter.next()) >> >> The condition is an implicit conversion to bool, which is disallowed >> by the style guide. In fact, it's a declaration, which is >> specifically called out by the style guide. When I revised the style >> guide I made explicit mention of that usage because I'd tried to use >> that sort of thing several years ago and got several complaints. So >> it's not that I personally think that usage is bad; rather, I was >> hoping someone would take on the little project of convincing the team >> it was good. I don't have any objection to this part of the change. > > I'll take a look at fixing that. I can't find a way to fix that without adding back some of the crazy things in the original macro. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From david.holmes at oracle.com Sat Jul 3 11:39:01 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 3 Jul 2021 21:39:01 +1000 Subject: RFR: 8269652: Factor out the common code for creating system j.l.Thread objects In-Reply-To: <8UqudKdKpJvnbPfhzBr-HbbJ5MaLCvRTJhADwAvTjH8=.4e35a805-d46b-4303-853c-f22e410ee2aa@github.com> References: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> <8UqudKdKpJvnbPfhzBr-HbbJ5MaLCvRTJhADwAvTjH8=.4e35a805-d46b-4303-853c-f22e410ee2aa@github.com> Message-ID: <1078d3e5-ca9f-c972-8ced-1fd84518426c@oracle.com> Hi Xin, Thanks for taking a look at this. On 3/07/2021 1:10 pm, Xin Liu wrote: > On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes wrote: > >> Please review this simple refactoring to share the common code used to create j.l.Thread instances for the internal VM JavaThreads. (Also fix a missing space from my previous change in thread.cpp.) >> >> It is all very straight-forward. >> >> Compiler folk I can go one step further and remove CompileBroker::create_thread_oop if desired. >> >> Testing: tiers 1-3, GHA >> >> Thanks, >> David > > Hi, David, > > I found you wrote the same comment twice. one is in thread.hpp. the other one is thread.cpp. Is it necessary? if we only need to keep one copy, should we write comments in header file or impl file? Good question- - there is no consistent style for this. I don't have a problem commenting both to some degree. > The second thing your change is not exactly same for attachListener.cpp. Originally, it returns if JavaCalls::construct_new_instance() has trouble, ie. `has_init_error(THREAD)` returns true. In your change, you call "add group" but check error later. I guess call "call_special" should throw a java exception instead of just setting its state "AL_NOT_INITIALIZED". Does it matter? The code is the same. The CHECK_NH macro will return from create_system_thread_object if any of the calls result in an exception pending. > Other part of code looks good. Thanks, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4663 > From david.holmes at oracle.com Sat Jul 3 11:39:25 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 3 Jul 2021 21:39:25 +1000 Subject: RFR: 8269652: Factor out the common code for creating system j.l.Thread objects In-Reply-To: <6mrbh5AIZqkSewf1hlOsdbA7RP12nBnHYjhXipl8x0Q=.11fc3e13-4225-400f-9fc2-9bb406f8283d@github.com> References: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> <6mrbh5AIZqkSewf1hlOsdbA7RP12nBnHYjhXipl8x0Q=.11fc3e13-4225-400f-9fc2-9bb406f8283d@github.com> Message-ID: On 3/07/2021 10:40 am, Vladimir Kozlov wrote: > On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes wrote: > >> Please review this simple refactoring to share the common code used to create j.l.Thread instances for the internal VM JavaThreads. (Also fix a missing space from my previous change in thread.cpp.) >> >> It is all very straight-forward. >> >> Compiler folk I can go one step further and remove CompileBroker::create_thread_oop if desired. >> >> Testing: tiers 1-3, GHA >> >> Thanks, >> David > > Good. Thanks for the review Vladimir! David > ------------- > > Marked as reviewed by kvn (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/4663 > From dcubed at openjdk.java.net Sat Jul 3 14:25:04 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 3 Jul 2021 14:25:04 GMT Subject: RFR: 8249004: Reduce ThreadListHandle overhead in relation to direct handshakes Message-ID: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> A trivial fix to reduce ThreadListHandle overhead in relation to handshakes. This refactoring was tested with Mach5 Tier[1-3]. ------------- Commit messages: - 8249004: Reduce ThreadListHandle overhead in relation to direct handshakes Changes: https://git.openjdk.java.net/jdk/pull/4677/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249004 Stats: 10 lines in 3 files changed: 7 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4677.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4677/head:pull/4677 PR: https://git.openjdk.java.net/jdk/pull/4677 From kbarrett at openjdk.java.net Sat Jul 3 17:13:52 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 3 Jul 2021 17:13:52 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2] In-Reply-To: References: <3e_ySPWMRm6NSgmQkcdrr_upq-cw8H3lyFfS1yF2_4w=.4dfa82ef-fc62-4354-bab2-a657ce54f1ec@github.com> Message-ID: <_QR2JVWXyT9p_PDGG10cLeRjYmN_J_6QnnqccgT2gfo=.d28f293b-ef8a-48d2-898a-f64809f8760e@github.com> On Sat, 3 Jul 2021 03:33:51 GMT, Daniel D. Daugherty wrote: >> I'll take a look at fixing that. > > I can't find a way to fix that without adding back some of the crazy things > in the original macro. I wasn't expecting any change based on that comment, just pointing out that the code *is* contrary to the style guide, in a place where I think the guide should be changed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From kbarrett at openjdk.java.net Sat Jul 3 17:21:53 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 3 Jul 2021 17:21:53 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2] In-Reply-To: References: Message-ID: On Sat, 3 Jul 2021 03:40:12 GMT, Daniel D. Daugherty wrote: >> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." >> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this >> piece of history that I'm finally getting around to cleaning up. While this macro has >> been with us for a long time, its time has passed... >> >> Tested with Mach5 Tier[1-3]. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > kbarrett CR - delete unused _list member. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4671 From xliu at openjdk.java.net Sat Jul 3 17:36:53 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Sat, 3 Jul 2021 17:36:53 GMT Subject: RFR: 8269652: Factor out the common code for creating system j.l.Thread objects In-Reply-To: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> References: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> Message-ID: On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes wrote: > Please review this simple refactoring to share the common code used to create j.l.Thread instances for the internal VM JavaThreads. (Also fix a missing space from my previous change in thread.cpp.) > > It is all very straight-forward. > > Compiler folk I can go one step further and remove CompileBroker::create_thread_oop if desired. > > Testing: tiers 1-3, GHA > > Thanks, > David LGTM ------------- Marked as reviewed by xliu (Committer). PR: https://git.openjdk.java.net/jdk/pull/4663 From dholmes at openjdk.java.net Sun Jul 4 12:25:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 4 Jul 2021 12:25:55 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2] In-Reply-To: <_QR2JVWXyT9p_PDGG10cLeRjYmN_J_6QnnqccgT2gfo=.d28f293b-ef8a-48d2-898a-f64809f8760e@github.com> References: <3e_ySPWMRm6NSgmQkcdrr_upq-cw8H3lyFfS1yF2_4w=.4dfa82ef-fc62-4354-bab2-a657ce54f1ec@github.com> <_QR2JVWXyT9p_PDGG10cLeRjYmN_J_6QnnqccgT2gfo=.d28f293b-ef8a-48d2-898a-f64809f8760e@github.com> Message-ID: On Sat, 3 Jul 2021 17:11:20 GMT, Kim Barrett wrote: >> I can't find a way to fix that without adding back some of the crazy things >> in the original macro. > > I wasn't expecting any change based on that comment, just pointing out that the code > *is* contrary to the style guide, in a place where I think the guide should be changed. I'm surprised that a declaration is even legal in that position - but then I should never be surprised at the crazy things C++ allows. :( I do think it looks truly awful to have a declaration there. Surely we do not have to reduce this to being a single-line macro that emulates a for-loop? That said I can't make any sense out of the original macro so sure this is a less-ugly macro. But why does this have to be so obscure - aren't we just walking the current threads-list ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From dholmes at openjdk.java.net Sun Jul 4 22:01:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 4 Jul 2021 22:01:56 GMT Subject: Integrated: 8269652: Factor out the common code for creating system j.l.Thread objects In-Reply-To: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> References: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> Message-ID: On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes wrote: > Please review this simple refactoring to share the common code used to create j.l.Thread instances for the internal VM JavaThreads. (Also fix a missing space from my previous change in thread.cpp.) > > It is all very straight-forward. > > Compiler folk I can go one step further and remove CompileBroker::create_thread_oop if desired. > > Testing: tiers 1-3, GHA > > Thanks, > David This pull request has now been integrated. Changeset: 390d1025 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/390d1025ca620666d500443e056a1f383b12d0a9 Stats: 140 lines in 8 files changed: 43 ins; 87 del; 10 mod 8269652: Factor out the common code for creating system j.l.Thread objects Reviewed-by: coleenp, dcubed, kvn, xliu ------------- PR: https://git.openjdk.java.net/jdk/pull/4663 From dholmes at openjdk.java.net Sun Jul 4 22:01:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 4 Jul 2021 22:01:55 GMT Subject: RFR: 8269652: Factor out the common code for creating system j.l.Thread objects In-Reply-To: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> References: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com> Message-ID: On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes wrote: > Please review this simple refactoring to share the common code used to create j.l.Thread instances for the internal VM JavaThreads. (Also fix a missing space from my previous change in thread.cpp.) > > It is all very straight-forward. > > Compiler folk I can go one step further and remove CompileBroker::create_thread_oop if desired. > > Testing: tiers 1-3, GHA > > Thanks, > David Thanks for all the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/4663 From kbarrett at openjdk.java.net Sun Jul 4 22:32:59 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 4 Jul 2021 22:32:59 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2] In-Reply-To: References: <3e_ySPWMRm6NSgmQkcdrr_upq-cw8H3lyFfS1yF2_4w=.4dfa82ef-fc62-4354-bab2-a657ce54f1ec@github.com> <_QR2JVWXyT9p_PDGG10cLeRjYmN_J_6QnnqccgT2gfo=.d28f293b-ef8a-48d2-898a-f64809f8760e@github.com> Message-ID: <6H4AyrJIVrYLzRomzJ_g5Br_BBR3ziePOe0RFBAlqbc=.506b6994-ed67-4f38-bdf4-870e92f64b76@github.com> On Sun, 4 Jul 2021 12:22:47 GMT, David Holmes wrote: >> I wasn't expecting any change based on that comment, just pointing out that the code >> *is* contrary to the style guide, in a place where I think the guide should be changed. > > I'm surprised that a declaration is even legal in that position - but then I should never be surprised at the crazy things C++ allows. :( I do think it looks truly awful to have a declaration there. Surely we do not have to reduce this to being a single-line macro that emulates a for-loop? That said I can't make any sense out of the original macro so sure this is a less-ugly macro. But why does this have to be so obscure - aren't we just walking the current threads-list ?? I failed to notice previously that the new macro introduces the "iter" variable into the body scope. The old macro used naming conventions to avoid adding any "simple" names that could inadvertently affect the meaning of the code. Thinking about David's reply, I'm also wondering if it might be possible to do better by making use of range-based for. It would involve defining a compliant iterator rather than the JavaThreadPrefetchedIterator, but that's not very hard. (And I can help with that.) Doing so would really simplify the macro, or perhaps even render it so trivial as to not be worth using any more. So I'm rescinding my approval of this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From kbarrett at openjdk.java.net Sun Jul 4 22:32:58 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 4 Jul 2021 22:32:58 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2] In-Reply-To: References: Message-ID: <0yNOkRrweFvaVauhMHJz8RVSKurahOukCJ9VKQReuZw=.4309a359-d1de-4979-88d2-f49a4075a03c@github.com> On Sat, 3 Jul 2021 03:40:12 GMT, Daniel D. Daugherty wrote: >> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." >> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this >> piece of history that I'm finally getting around to cleaning up. While this macro has >> been with us for a long time, its time has passed... >> >> Tested with Mach5 Tier[1-3]. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > kbarrett CR - delete unused _list member. Changes requested by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From dholmes at openjdk.java.net Sun Jul 4 23:41:58 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 4 Jul 2021 23:41:58 GMT Subject: RFR: 8249004: Reduce ThreadListHandle overhead in relation to direct handshakes In-Reply-To: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: On Sat, 3 Jul 2021 14:15:54 GMT, Daniel D. Daugherty wrote: > A trivial fix to reduce ThreadListHandle overhead in relation to handshakes. > > This refactoring was tested with Mach5 Tier[1-3]. Hi Dan, I just updated the bug report. This really isn't addressing the reasons the RFE was filed. David ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From kbarrett at openjdk.java.net Mon Jul 5 07:05:57 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 5 Jul 2021 07:05:57 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2] In-Reply-To: References: Message-ID: On Sat, 3 Jul 2021 03:40:12 GMT, Daniel D. Daugherty wrote: >> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." >> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this >> piece of history that I'm finally getting around to cleaning up. While this macro has >> been with us for a long time, its time has passed... >> >> Tested with Mach5 Tier[1-3]. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > kbarrett CR - delete unused _list member. src/hotspot/share/runtime/thread.cpp line 2464: > 2462: } > 2463: > 2464: struct JavaThreadPrefetchedIterator { I think the only really important difference between this new iterator class and the existing JavaThreadIterator and JavaThreadIteratorWithHandle is that the prefetched iterator prefetches. It seems like if that's useful there then it's probably useful for the other two as well. I think these could all be collapsed down to one iterator over ThreadsList that is typically used via range-based for. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From sgehwolf at openjdk.java.net Mon Jul 5 08:04:54 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 5 Jul 2021 08:04:54 GMT Subject: [jdk17] RFR: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 08:06:07 GMT, Severin Gehwolf wrote: > This fix simplifies the `if` condition to use a default 64-bit library path including default setting when `_LP64` is defined (os has 64-bitness). This should be safe IMHO and seems better than explicitly enumerating all 64 bit Linux architectures. > > This issue affects older releases and I'd like to get this fix into JDK 17. Thoughts? Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk17/pull/200 From sgehwolf at openjdk.java.net Mon Jul 5 08:04:55 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 5 Jul 2021 08:04:55 GMT Subject: [jdk17] Integrated: 8269668: [aarch64] java.library.path not including /usr/lib64 In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 08:06:07 GMT, Severin Gehwolf wrote: > This fix simplifies the `if` condition to use a default 64-bit library path including default setting when `_LP64` is defined (os has 64-bitness). This should be safe IMHO and seems better than explicitly enumerating all 64 bit Linux architectures. > > This issue affects older releases and I'd like to get this fix into JDK 17. Thoughts? This pull request has now been integrated. Changeset: e14801cd Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk17/commit/e14801cdd9b108aa4ca47d0bc1dc67fca575764c Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8269668: [aarch64] java.library.path not including /usr/lib64 Reviewed-by: aph, dholmes ------------- PR: https://git.openjdk.java.net/jdk17/pull/200 From david.holmes at oracle.com Tue Jul 6 00:27:23 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Jul 2021 10:27:23 +1000 Subject: RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc In-Reply-To: <39h20eu5e3-1@m0246577.ppops.net> References: <7b6c20dd-219b-be6d-6d65-daf6b2bb824e@oracle.com> <39h20eu5e3-1@m0246577.ppops.net> Message-ID: <59a19326-38fc-1ed4-5b64-db2082b497bc@oracle.com> Hi Christoph, Sorry for the delay getting back to this. On 1/07/2021 5:56 pm, Christoph G?ttschkes wrote: > Hi David > > On 7/1/21 3:44 AM, David Holmes wrote: >> Hi Christoph, >> >> On 24/06/2021 10:06 pm, Christoph G?ttschkes wrote: >>> Hi, >>> >>> please review the following change, which was way too long on my >>> chest. It fixes an assertion in the template interpreter for >>> ARM32-softfp. >>> >>> For ARM32-softfp, the template interpreter calls into the runtime to >>> load a double constant using the ldc bytecode. After the interpreter >>> loaded the constants, the assert block does some sanity checks on the >>> cached constants. But if the double constant is the first constant to >>> be loaded, the cache is not yet initialized and the check results in >>> a SIGSEGV. >>> >>> I guarded the usage of `ConstantPool::cp_to_object_index` by another >>> check, which tests if there are any resolved references and if that's >>> the case, the cache has already been initialized and the sanity >>> checks can be performed. >> >> Why isn't this something that should be fixed in the ARM code rather >> than the shared code? I admit I'm struggling to understand exactly how >> the problem arises - ldc is not to be used for long/double values. > > Sorry for confusing you. Hopefully the following explanation clears > things up. > > The runtime executes the ldc2_w bytecode to load the double constant. > For ARM32-softfp this uses the TemplateTable::condy_helper method, which > calls InterpreterRuntime::resolve_ldc to load the constant. resolve_ldc > is used for all kinds of bytecodes. I probably wrote "calls into the > runtime to load a double constant using the ldc bytecode" because of the > name resolve_ldc. > > I guess ARM32-softfp is the only platform which uses resolve_ldc for > double constants. From the way resolve_ldc is written, it also looks > like it should be able to handle ldc2_w bytecodes. There are multiple > assertions which check for correct bytecodes etc. and ldc2_w is > explicitly among the supported bytecodes. > > We could still think about not using the condy_helper and resolve_ldc > for loading double constants on ARM32-softfp, but after that change we > would still have a resolve_ldc implementation, which works for ldc2_w, > but fails in debug VMs because of the ASSERT check. So I think we have > to address both things even if we change the ARM interpreter behavior > for ldc2_w. I do find this somewhat inconsistent and confusing. Looking at x86 and Aarch64 for example, TemplateTable::ldc2_w doesn't use condy_helper for long/double, yet condy_helper has case statements for _ldc2_w to handle long and double; which occur after the call to InterpreterRuntime::resolve_ldc. For ARM32 we have two cases. For __ABI_HARD__ condy_helper is not used for double; but otherwise it is. And again condy_helper has explicit case statements for _ldc2_w, but after the call to InterpreterRuntime::resolve_ldc. And resolve_ldc itself seems to be catering for all kinds of constants, except the ASSERT block. It seems to me that logic is only intended for use with ldc's relating to objects not primitives. Now maybe cp_to_object_index is expected to handle that and just return the _no_index_sentinel, or perhaps this just happens to work by accident (as long as the map is initialized)? I'm really not sure. And those ConstantPool methods should really have their own asserts to check that the reference_map() has in fact been initialized. Your proposed workaround, doesn't really address any of the underlying confusion and inconsistency, but does at least attempt to get things working again on ARM32. That said, I think you need to be using ConstantPool::resolved_references_or_null() as resolved_references() still relies on _cache being initialized. Thanks, David ----- >> >> Thanks, >> David >> ----- >> > -- Christoph > From dholmes at openjdk.java.net Tue Jul 6 00:32:51 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Jul 2021 00:32:51 GMT Subject: RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 11:57:20 GMT, Christoph G?ttschkes wrote: > Hi, > > please review the following change, which was way too long on my chest. It fixes an assertion in the template interpreter for ARM32-softfp. > > For ARM32-softfp, the template interpreter calls into the runtime to load a double constant using the ldc bytecode. After the interpreter loaded the constants, the assert block does some sanity checks on the cached constants. But if the double constant is the first constant to be loaded, the cache is not yet initialized and the check results in a SIGSEGV. > > I guarded the usage of `ConstantPool::cp_to_object_index` by another check, which tests if there are any resolved references and if that's the case, the cache has already been initialized and the sanity checks can be performed. Changes requested by dholmes (Reviewer). src/hotspot/share/interpreter/interpreterRuntime.cpp line 193: > 191: Bytecode_loadconstant ldc2(m, last_frame.bci()); > 192: int rindex = ldc2.cache_index(); > 193: if (rindex < 0 && m->constants()->resolved_references() != NULL) Should be `resolved_references_or_null()` ------------- PR: https://git.openjdk.java.net/jdk/pull/4582 From kbarrett at openjdk.java.net Tue Jul 6 02:19:52 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 6 Jul 2021 02:19:52 GMT Subject: RFR: 8269882: stack-use-after-scope in NewObjectA In-Reply-To: References: Message-ID: <3Q7Xyeb1G9TUTtzkwUCYHZpOvUtueaFkxWpqmkK5Opk=.553e20dd-e86d-42f7-aa9e-560226085ea8@github.com> On Mon, 5 Jul 2021 23:06:19 GMT, David Holmes wrote: > Please review this trivial fix to add '&' so that a macro parameter is passed as a reference. > > See bug for details. > > Thanks, > David Looks good, and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4683 From dholmes at openjdk.java.net Tue Jul 6 02:19:53 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Jul 2021 02:19:53 GMT Subject: RFR: 8269882: stack-use-after-scope in NewObjectA In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 23:06:19 GMT, David Holmes wrote: > Please review this trivial fix to add '&' so that a macro parameter is passed as a reference. > > See bug for details. > > Thanks, > David Thanks for the review Kim. ------------- PR: https://git.openjdk.java.net/jdk/pull/4683 From dholmes at openjdk.java.net Tue Jul 6 02:23:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Jul 2021 02:23:56 GMT Subject: Integrated: 8269882: stack-use-after-scope in NewObjectA In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 23:06:19 GMT, David Holmes wrote: > Please review this trivial fix to add '&' so that a macro parameter is passed as a reference. > > See bug for details. > > Thanks, > David This pull request has now been integrated. Changeset: 20eba355 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/20eba35515073c4daf1fa8ac78a37196ea196690 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8269882: stack-use-after-scope in NewObjectA Reviewed-by: kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/4683 From yyang at openjdk.java.net Tue Jul 6 02:27:53 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 6 Jul 2021 02:27:53 GMT Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format one [v5] In-Reply-To: References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com> Message-ID: On Wed, 30 Jun 2021 06:38:30 GMT, Yi Yang wrote: >> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid `. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool. >> >> Jstack Before: >> >> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable >> >> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable >> >> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable >> >> Jstack After: >> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable >> >> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable >> >> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable >> >> Top: >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java >> 71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb >> 50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java >> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java >> 99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > use \p{XDigit} @dholmes-ora David, can you please take a look at the latest versions. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4449 From lzang at openjdk.java.net Tue Jul 6 03:03:14 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Tue, 6 Jul 2021 03:03:14 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test Message-ID: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. ------------- Commit messages: - 8269886: Inaccurate error message for compressed hprof test Changes: https://git.openjdk.java.net/jdk/pull/4685/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4685&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269886 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4685.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4685/head:pull/4685 PR: https://git.openjdk.java.net/jdk/pull/4685 From dholmes at openjdk.java.net Tue Jul 6 03:11:57 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Jul 2021 03:11:57 GMT Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format one [v5] In-Reply-To: References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com> Message-ID: On Wed, 30 Jun 2021 06:38:30 GMT, Yi Yang wrote: >> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid `. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool. >> >> Jstack Before: >> >> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable >> >> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable >> >> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable >> >> Jstack After: >> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable >> >> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable >> >> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable >> >> Top: >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java >> 71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb >> 50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java >> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java >> 99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > use \p{XDigit} src/hotspot/share/runtime/osThread.cpp line 41: > 39: // Printing > 40: void OSThread::print_on(outputStream *st) const { > 41: st->print("nid=" UINT64_FORMAT " ", (uint64_t)thread_id()); Why are you forcing this to be a 64-bit type? ------------- PR: https://git.openjdk.java.net/jdk/pull/4449 From dholmes at openjdk.java.net Tue Jul 6 03:16:48 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Jul 2021 03:16:48 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test In-Reply-To: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: On Tue, 6 Jul 2021 02:55:37 GMT, Lin Zang wrote: > The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. > > This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. The existing message is a generic message covering the general operation of the whole try block. It seems far more appropriate than your new message, which only seems to apply to the final step. ??? David ------------- PR: https://git.openjdk.java.net/jdk/pull/4685 From yyang at openjdk.java.net Tue Jul 6 03:25:57 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 6 Jul 2021 03:25:57 GMT Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format one [v5] In-Reply-To: References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com> Message-ID: On Tue, 6 Jul 2021 03:08:42 GMT, David Holmes wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> use \p{XDigit} > > src/hotspot/share/runtime/osThread.cpp line 41: > >> 39: // Printing >> 40: void OSThread::print_on(outputStream *st) const { >> 41: st->print("nid=" UINT64_FORMAT " ", (uint64_t)thread_id()); > > Why are you forcing this to be a 64-bit type? IMHO, I prefer using `%d` since a large portion of existing code using `%d`. Thomas suggests using UINT64_FORMAT rather than `%d`: > You'd do: > print("nid: " UINT64_FORMAT, (uint64_t) id):; > thread_t is, among other things, pthread_t, which is opaque. Any current code treating that as signed int is incorrect too. There is no uniform format for the formatted output of thread_id in hotspot. As far as I can see, `%ld` `%d` and `UINTX_FORMAT` are used, so I want to left the decision to reviewers. ------------- PR: https://git.openjdk.java.net/jdk/pull/4449 From david.holmes at oracle.com Tue Jul 6 03:31:26 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Jul 2021 13:31:26 +1000 Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format one [v5] In-Reply-To: References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com> Message-ID: <2928e4d8-8889-f289-5b15-3f434df3f742@oracle.com> On 6/07/2021 1:25 pm, Yi Yang wrote: > On Tue, 6 Jul 2021 03:08:42 GMT, David Holmes wrote: > >>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >>> >>> use \p{XDigit} >> >> src/hotspot/share/runtime/osThread.cpp line 41: >> >>> 39: // Printing >>> 40: void OSThread::print_on(outputStream *st) const { >>> 41: st->print("nid=" UINT64_FORMAT " ", (uint64_t)thread_id()); >> >> Why are you forcing this to be a 64-bit type? > > IMHO, I prefer using `%d` since a large portion of existing code using `%d`. Thomas suggests using UINT64_FORMAT rather than `%d`: >> You'd do: > >> print("nid: " UINT64_FORMAT, (uint64_t) id):; > >> thread_t is, among other things, pthread_t, which is opaque. Any current code treating that as signed int is incorrect too. > > There is no uniform format for the formatted output of thread_id in hotspot. As far as I can see, `%ld` `%d` and `UINTX_FORMAT` are used, so I want to left the decision to reviewers. Okay. This is a mess but that's not your issue. At least a 64-bit decimal value won't show any leading zeroes so it doesn't really matter. If Thomas and Keven are happy with the latest changes then that is fine. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4449 > From lzang at openjdk.java.net Tue Jul 6 03:33:53 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Tue, 6 Jul 2021 03:33:53 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test In-Reply-To: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: On Tue, 6 Jul 2021 02:55:37 GMT, Lin Zang wrote: > The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. > > This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. Hi David, Thanks for review and comments. > The existing message is a generic message covering the general operation of the whole try block. It seems far more appropriate than your new message, which only seems to apply to the final step. ??? IMO, the whole method named getStack() is used to get the stack trace for the hprof file. And the try block could throw exceptions by serveral reasons as decribed, so IMHO printing "Can not decompress the compressed hprof file" is not accurate. The proposed change is to print a generic error message that the getStack() fail when processing compressed hprof. And the extra 'e' argument in the changed line would give detailed reason. So may be change error message to "Can not process the compressed hprof file" is better? what do you think? BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/4685 From david.holmes at oracle.com Tue Jul 6 04:12:09 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Jul 2021 14:12:09 +1000 Subject: RFR: 8269886: Inaccurate error message for compressed hprof test In-Reply-To: References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: <63b04a0d-fbb0-9929-9b37-b40e390c6b91@oracle.com> Hi Lin, On 6/07/2021 1:33 pm, Lin Zang wrote: > On Tue, 6 Jul 2021 02:55:37 GMT, Lin Zang wrote: > >> The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. >> >> This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. > > Hi David, > Thanks for review and comments. > >> The existing message is a generic message covering the general operation of the whole try block. It seems far more appropriate than your new message, which only seems to apply to the final step. ??? > > IMO, the whole method named getStack() is used to get the stack trace for the hprof file. And the try block could throw exceptions by serveral reasons as decribed, so IMHO printing "Can not decompress the compressed hprof file" is not accurate. The proposed change is to print a generic error message that the getStack() fail when processing compressed hprof. And the extra 'e' argument in the changed line would give detailed reason. > > So may be change error message to "Can not process the compressed hprof file" is better? what do you think? Yes that seems a good middle ground. Alternatively, but more effort, have different try/catch blocks for the two sections of the code. The first to decompress and write out; the second to extract the stack traces. It isn't obvious that exceptions are possible from both parts. Thanks, David > BRs, > Lin > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4685 > From lzang at openjdk.java.net Tue Jul 6 06:32:12 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Tue, 6 Jul 2021 06:32:12 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v2] In-Reply-To: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: <_UWscp9Rnm8LJL3YDJ3r6aj1TVK4QsWtQl_FoRMxjOM=.e17fb67c-8601-4138-8157-16c5253a0bc2@github.com> > The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. > > This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. Lin Zang has updated the pull request incrementally with one additional commit since the last revision: divid the try block ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4685/files - new: https://git.openjdk.java.net/jdk/pull/4685/files/4ee240f6..76a69c38 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4685&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4685&range=00-01 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4685.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4685/head:pull/4685 PR: https://git.openjdk.java.net/jdk/pull/4685 From lzang at openjdk.java.net Tue Jul 6 06:32:12 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Tue, 6 Jul 2021 06:32:12 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test In-Reply-To: References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: On Tue, 6 Jul 2021 03:14:15 GMT, David Holmes wrote: >> The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. >> >> This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. > > The existing message is a generic message covering the general operation of the whole try block. It seems far more appropriate than your new message, which only seems to apply to the final step. ??? > > David Hi @dholmes-ora? Thanks for your suggestion! I have update the PR which split the try block into two seperate ones to process different exceptions. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/4685 From xliu at openjdk.java.net Tue Jul 6 06:50:05 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 6 Jul 2021 06:50:05 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX Message-ID: This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration only decrements _sem 1 but dequeues N messages. If logging threads keep preempting async logging thread, it may cause the value of _sem accumulates until overflow! The patch corrects the value of _sem after write(). n messages are dequeued/processed. We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration decrements n instead of 1. ------------- Commit messages: - 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX Changes: https://git.openjdk.java.net/jdk17/pull/216/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=216&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269865 Stats: 10 lines in 2 files changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk17/pull/216.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/216/head:pull/216 PR: https://git.openjdk.java.net/jdk17/pull/216 From dholmes at openjdk.java.net Tue Jul 6 06:50:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Jul 2021 06:50:52 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v2] In-Reply-To: <_UWscp9Rnm8LJL3YDJ3r6aj1TVK4QsWtQl_FoRMxjOM=.e17fb67c-8601-4138-8157-16c5253a0bc2@github.com> References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> <_UWscp9Rnm8LJL3YDJ3r6aj1TVK4QsWtQl_FoRMxjOM=.e17fb67c-8601-4138-8157-16c5253a0bc2@github.com> Message-ID: On Tue, 6 Jul 2021 06:32:12 GMT, Lin Zang wrote: >> The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. >> >> This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > divid the try block These changes are fine in themselves. This code is not very well written though - the file streams do not get closed and the decompressed output file doesn't seem to get deleted when I would expect. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4685 From lzang at openjdk.java.net Tue Jul 6 07:01:51 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Tue, 6 Jul 2021 07:01:51 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v2] In-Reply-To: <_UWscp9Rnm8LJL3YDJ3r6aj1TVK4QsWtQl_FoRMxjOM=.e17fb67c-8601-4138-8157-16c5253a0bc2@github.com> References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> <_UWscp9Rnm8LJL3YDJ3r6aj1TVK4QsWtQl_FoRMxjOM=.e17fb67c-8601-4138-8157-16c5253a0bc2@github.com> Message-ID: On Tue, 6 Jul 2021 06:32:12 GMT, Lin Zang wrote: >> The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. >> >> This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > divid the try block Hi David? Thanks for reviewing! > This code is not very well written though - the file streams do not get closed and the decompressed output file doesn't seem to get deleted when I would expect. Agree. I will create a seperate issue to fix it. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/4685 From dholmes at openjdk.java.net Tue Jul 6 07:16:48 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Jul 2021 07:16:48 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 06:43:24 GMT, Xin Liu wrote: > This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. > Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration > only decrements _sem 1 but dequeues N messages. If logging threads keep preempting > async logging thread, it may cause the value of _sem accumulates until overflow! > > The patch corrects the value of _sem after write(). n messages are dequeued/processed. > We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration > decrements n instead of 1. Hi Xin, I wasn't expecting to see an attempt to balance the semaphore count on each write, but this seems to be okay. One simplification suggested below. Thanks, David src/hotspot/share/logging/logAsyncWriter.cpp line 163: > 161: > 162: int n = write(); > 163: for (int i = n - 1; i > 0; --i) { `while (--n > 0) { // pre-decrement as we already performed the first wait` ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/216 From dholmes at openjdk.java.net Tue Jul 6 07:32:50 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Jul 2021 07:32:50 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 06:43:24 GMT, Xin Liu wrote: > This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. > Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration > only decrements _sem 1 but dequeues N messages. If logging threads keep preempting > async logging thread, it may cause the value of _sem accumulates until overflow! > > The patch corrects the value of _sem after write(). n messages are dequeued/processed. > We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration > decrements n instead of 1. Sorry I have to withdraw my initial review approval. This certainly helps allow the writer thread to catch up sooner, but there is still no guarantee that it will keep up with the loggers sufficient to avoid the overflow. What we have to ensure in addition is that the number of outstanding log messages permitted by the buffer size is always less than the max value allow by the semaphore. Unfortunately we don't know what that value is. David ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/216 From xliu at openjdk.java.net Tue Jul 6 07:56:51 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 6 Jul 2021 07:56:51 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 07:29:27 GMT, David Holmes wrote: > What we have to ensure in addition is that the number of outstanding log messages permitted by the buffer size is always less than the max value allow by the semaphore. Unfortunately we don't know what that value is. On Linux, SEM_VALUE_MAX is defined in . we can add an assertion that `assert(_buffer_max_size < SEM_VALUE_MAX) `. Currently, it seems that hotspot needs to support 3 semaphores. 1. Posix semaphore of glibc. -- SEM_VALUE_MAX 2. Windows API -- LONG_MAX 3. MacOS -- I have found document for this. Yes, you just unveil another issue. I found _buffer_max_size is 91k if I use `-XX:AsyncLogBufferSize=50M`. That value is bigger than SEM_VALUE_MAX of AIX. `The maximum entries of AsyncLogBuffer: 91022` ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From xliu at openjdk.java.net Tue Jul 6 08:06:17 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 6 Jul 2021 08:06:17 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v2] In-Reply-To: References: Message-ID: > This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. > Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration > only decrements _sem 1 but dequeues N messages. If logging threads keep preempting > async logging thread, it may cause the value of _sem accumulates until overflow! > > The patch corrects the value of _sem after write(). n messages are dequeued/processed. > We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration > decrements n instead of 1. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Fix build issue on Windows and simplify the loop. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/216/files - new: https://git.openjdk.java.net/jdk17/pull/216/files/269a1580..e385f42f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=216&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=216&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/216.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/216/head:pull/216 PR: https://git.openjdk.java.net/jdk17/pull/216 From dholmes at openjdk.java.net Tue Jul 6 09:32:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Jul 2021 09:32:52 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 08:06:17 GMT, Xin Liu wrote: >> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >> async logging thread, it may cause the value of _sem accumulates until overflow! >> >> The patch corrects the value of _sem after write(). n messages are dequeued/processed. >> We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration >> decrements n instead of 1. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Fix build issue on Windows and simplify the loop. I don't like the idea of trying to limit the log size based on a platform specific private implementation detail - and you'd have to check that against any user supplied buffer size and reject a too large buffer. The other option is revert these changes and expose a way to ignore the ERANGE error in Semaphore. ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From christoph.goettschkes at microdoc.com Tue Jul 6 13:15:11 2021 From: christoph.goettschkes at microdoc.com (=?UTF-8?Q?Christoph_G=c3=b6ttschkes?=) Date: Tue, 6 Jul 2021 15:15:11 +0200 Subject: RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc In-Reply-To: <59a19326-38fc-1ed4-5b64-db2082b497bc@oracle.com> References: <7b6c20dd-219b-be6d-6d65-daf6b2bb824e@oracle.com> <39h20eu5e3-1@m0246577.ppops.net> <59a19326-38fc-1ed4-5b64-db2082b497bc@oracle.com> Message-ID: <39kshav06e-1@m0246572.ppops.net> Hi David. On 7/6/21 2:27 AM, David Holmes wrote: > > I do find this somewhat inconsistent and confusing. Looking at x86 and Aarch64 for example, TemplateTable::ldc2_w doesn't use condy_helper for long/double, yet condy_helper has case statements for _ldc2_w to handle long and double; which occur after the call to InterpreterRuntime::resolve_ldc. > > For ARM32 we have two cases. For __ABI_HARD__ condy_helper is not used for double; but otherwise it is. And again condy_helper has explicit case statements for _ldc2_w, but after the call to InterpreterRuntime::resolve_ldc. > > And resolve_ldc itself seems to be catering for all kinds of constants, except the ASSERT block. It seems to me that logic is only intended for use with ldc's relating to objects not primitives. Now maybe cp_to_object_index is expected to handle that and just return the _no_index_sentinel, or perhaps this just happens to work by accident (as long as the map is initialized)? I'm really not sure. And those ConstantPool methods should really have their own asserts to check that the reference_map() has in fact been initialized. > I looked into this now in depth. Thanks for your input, it really helped me getting through it. I think I was able to find the root cause now. condy_helper and resolve_ldc should only be used for CONSTANT_dynamic. The ldc, ldc_w, and ldc2_w bytecodes are all valid with CONSTANT_dynamic and therefore it makes sense that the condy_helper has a case for those bytecodes. Also, I think it makes sense that the Assert block always thinks that something has been cached, since for a CONSTANT_dynamic, something always needs to be cached, even if the constant is a double. So I think the confusion comes, because you think ldc2_w should only be used for double and long. That's true, but because of CONSTANT_dynamic, the special handling of the interpreter isn't used and the condy_helper is called (hopefully that makes sense, I am by no means an expert on condy, but the hotspot enum for the constant pool entries has JVM_CONSTANT_Double, JVM_CONSTANT_Long and JVM_CONSTANT_Dynamic, and those constants are used for the checks in the template interpreter). All the handling around ldc, ldc_w, and ldc2_w in resolve_ldc comes from the initial condy implementation [1] [2]. For the ARM32 case, it looks like the initial condy implementation introduced the wrong behavior [3]. Before condy, the template interpreter loaded double and long identically for softp [4]. With the condy implementation, a new check was introduced [5] and it was overlooked that from now on, CONSTANT_double was no longer loaded using the interpreter templates alone, but with the help of the condy_helper and the InterpreterRuntime::resolve_ldc. Maybe there is also something wrong/strange in resolve_ldc about the assumption of caching, but I think that should be looked after by someone more familiar with condy. > Your proposed workaround, doesn't really address any of the underlying confusion and inconsistency, but does at least attempt to get things working again on ARM32. That said, I think you need to be using ConstantPool::resolved_references_or_null() as resolved_references() still relies on _cache being initialized. I am not so sure on how to go forward now. I would like to stick with the current fix and will open a new bug which I will fix in the near future. I don't have a softfp setup right now and need to organize some hardware to make proper tests. I will update the PR with your suggestion, even though I think that the cache itself should always be initialized and never be null, if we are already executing a method of a class. It might be that there are no resolved references in the cache (like in the case this issue addresses). But on the other hand, an additional NULL check doesn't hurt. Is that OK for you, or do you think we should make a new bug and close this one as won't fix? [1] https://bugs.openjdk.java.net/browse/JDK-8186046 [2] https://hg.openjdk.java.net/jdk/hs/rev/c4d9d1b08e2e#l18.6 [3] https://github.com/openjdk/jdk/commit/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a [4] https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L529 [5] https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L545 Thanks, Christoph From cgo at openjdk.java.net Tue Jul 6 13:17:17 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Tue, 6 Jul 2021 13:17:17 GMT Subject: RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 00:29:36 GMT, David Holmes wrote: >> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: >> >> Adds an additional NULL check for the CP _cache. > > src/hotspot/share/interpreter/interpreterRuntime.cpp line 193: > >> 191: Bytecode_loadconstant ldc2(m, last_frame.bci()); >> 192: int rindex = ldc2.cache_index(); >> 193: if (rindex < 0 && m->constants()->resolved_references() != NULL) > > Should be `resolved_references_or_null()` I think the cache should always be initialized. The problem are the resolved symbols in the cache. But I don't see any harm in adding this check as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/4582 From cgo at openjdk.java.net Tue Jul 6 13:17:16 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Tue, 6 Jul 2021 13:17:16 GMT Subject: RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc [v2] In-Reply-To: References: Message-ID: > Hi, > > please review the following change, which was way too long on my chest. It fixes an assertion in the template interpreter for ARM32-softfp. > > For ARM32-softfp, the template interpreter calls into the runtime to load a double constant using the ldc bytecode. After the interpreter loaded the constants, the assert block does some sanity checks on the cached constants. But if the double constant is the first constant to be loaded, the cache is not yet initialized and the check results in a SIGSEGV. > > I guarded the usage of `ConstantPool::cp_to_object_index` by another check, which tests if there are any resolved references and if that's the case, the cache has already been initialized and the sanity checks can be performed. Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: Adds an additional NULL check for the CP _cache. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4582/files - new: https://git.openjdk.java.net/jdk/pull/4582/files/8d0d5ea3..667966f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4582&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4582&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4582.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4582/head:pull/4582 PR: https://git.openjdk.java.net/jdk/pull/4582 From cgo at openjdk.java.net Tue Jul 6 14:24:50 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Tue, 6 Jul 2021 14:24:50 GMT Subject: RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 13:17:16 GMT, Christoph G?ttschkes wrote: >> Hi, >> >> please review the following change, which was way too long on my chest. It fixes an assertion in the template interpreter for ARM32-softfp. >> >> For ARM32-softfp, the template interpreter calls into the runtime to load a double constant using the ldc bytecode. After the interpreter loaded the constants, the assert block does some sanity checks on the cached constants. But if the double constant is the first constant to be loaded, the cache is not yet initialized and the check results in a SIGSEGV. >> >> I guarded the usage of `ConstantPool::cp_to_object_index` by another check, which tests if there are any resolved references and if that's the case, the cache has already been initialized and the sanity checks can be performed. > > Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: > > Adds an additional NULL check for the CP _cache. For some reason, the bot is missing the mailing list conversation. See here: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2021-July/049901.html ------------- PR: https://git.openjdk.java.net/jdk/pull/4582 From clanger at openjdk.java.net Tue Jul 6 15:52:49 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 6 Jul 2021 15:52:49 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v4] In-Reply-To: References: Message-ID: On Sun, 6 Jun 2021 08:50:22 GMT, Anton Kozlov wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix windows flags (although complied fine) > > Thanks for the comments! Indeed, the change is about the "overwrite" option only. The CSR describes why the option is necessary, and sockets and pipes are just examples. I have rephrased CSR to be more explicit about the option, but not examples. > @AntonKozlov This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! Please keep this open :) We're waiting for the CSR. @jddarcy, is there any update? ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From ccheung at openjdk.java.net Tue Jul 6 16:16:53 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 6 Jul 2021 16:16:53 GMT Subject: RFR: 8264735: Make dynamic dump repeatable [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 20:12:23 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Currently after dynamic dump, dump time tables (`_dumptime_talbles, _dumptime_lambda_proxy_class_dictionary and _saved_shared_path_table`) are corrupted and could not be used for next dump. The patch clones the three tables, and after dump restore them so the next dump is possible. With the fix, jcmd VM.cds dynamic_dump can do multiple dump to the same live process. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, added check holding for DumpTimeTable_lock Marked as reviewed by ccheung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4646 From dcubed at openjdk.java.net Tue Jul 6 17:04:03 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 6 Jul 2021 17:04:03 GMT Subject: Integrated: 8269935: ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on windows Message-ID: A trivial fix to ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on windows. ------------- Commit messages: - 8269935: ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on windows Changes: https://git.openjdk.java.net/jdk/pull/4692/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4692&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269935 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4692.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4692/head:pull/4692 PR: https://git.openjdk.java.net/jdk/pull/4692 From jjg at openjdk.java.net Tue Jul 6 17:04:03 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 6 Jul 2021 17:04:03 GMT Subject: Integrated: 8269935: ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on windows In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 16:54:27 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on windows. Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4692 From dcubed at openjdk.java.net Tue Jul 6 17:04:03 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 6 Jul 2021 17:04:03 GMT Subject: Integrated: 8269935: ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on windows In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 16:57:20 GMT, Jonathan Gibbons wrote: >> A trivial fix to ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on windows. > > Marked as reviewed by jjg (Reviewer). @jonathan-gibbons - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4692 From dcubed at openjdk.java.net Tue Jul 6 17:04:04 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 6 Jul 2021 17:04:04 GMT Subject: Integrated: 8269935: ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on windows In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 16:54:27 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on windows. This pull request has now been integrated. Changeset: 4dfcf53a Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/4dfcf53a8bf2ca8717e418b1cbd66ba263b77980 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8269935: ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on windows Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/4692 From minqi at openjdk.java.net Tue Jul 6 17:24:01 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 6 Jul 2021 17:24:01 GMT Subject: RFR: 8263538: SharedArchiveConsistency.java should test -Xshare:auto as well Message-ID: Hi, please review When this test run with -Xshare:on, it will exit when the shared archive is corrupted or mismatch. Make it run with -Xshare:auto will expand code coverage and to keep app run without using the CDS. Tests: Mach5 tier1,tier4 Thanks Yumin ------------- Commit messages: - Fix extra white space at end of line 397 - 8263538: SharedArchiveConsistency.java should test -Xshare:auto as well Changes: https://git.openjdk.java.net/jdk/pull/4694/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4694&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263538 Stats: 44 lines in 1 file changed: 31 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/4694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4694/head:pull/4694 PR: https://git.openjdk.java.net/jdk/pull/4694 From cjplummer at openjdk.java.net Tue Jul 6 17:48:50 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 6 Jul 2021 17:48:50 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v2] In-Reply-To: <_UWscp9Rnm8LJL3YDJ3r6aj1TVK4QsWtQl_FoRMxjOM=.e17fb67c-8601-4138-8157-16c5253a0bc2@github.com> References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> <_UWscp9Rnm8LJL3YDJ3r6aj1TVK4QsWtQl_FoRMxjOM=.e17fb67c-8601-4138-8157-16c5253a0bc2@github.com> Message-ID: On Tue, 6 Jul 2021 06:32:12 GMT, Lin Zang wrote: >> The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. >> >> This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > divid the try block You need 2 reviews. Please don't integrate yet. I'll provide more comments shortly. ------------- PR: https://git.openjdk.java.net/jdk/pull/4685 From cjplummer at openjdk.java.net Tue Jul 6 18:14:49 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 6 Jul 2021 18:14:49 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v2] In-Reply-To: <_UWscp9Rnm8LJL3YDJ3r6aj1TVK4QsWtQl_FoRMxjOM=.e17fb67c-8601-4138-8157-16c5253a0bc2@github.com> References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> <_UWscp9Rnm8LJL3YDJ3r6aj1TVK4QsWtQl_FoRMxjOM=.e17fb67c-8601-4138-8157-16c5253a0bc2@github.com> Message-ID: <4DyDn_qhAvYVQ5RAvniXvNMjaluYJfd9-mgR4vm8uZA=.ce307615-2060-487c-afdd-7017f2e55dfe@github.com> On Tue, 6 Jul 2021 06:32:12 GMT, Lin Zang wrote: >> The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. >> >> This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > divid the try block After decompressing, no error or exception is thrown if MAGIC_NUMBER is not found. It just silently fails to print the stack trace. Please use "cannot" instead of "can not". Both are grammatically correct, but "cannot" is what is normally used. ------------- PR: https://git.openjdk.java.net/jdk/pull/4685 From zgu at openjdk.java.net Tue Jul 6 19:02:59 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 6 Jul 2021 19:02:59 GMT Subject: RFR: 8269923: runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java failed with "FATAL ERROR in native method: Primitive type array expected but not received for JNI array operation" Message-ID: On Posix compatible platforms, when abort with code dump, it exits with os:abort(), which has exit code 134. if (dump_core) { LINUX_ONLY(if (DumpPrivateMappingsInCore) ClassLoader::close_jrt_image();) ::abort(); // dump core } but not on Windows, where it still exits with 1. CloseHandle(dumpFile); win32::exit_process_or_thread(win32::EPT_PROCESS, 1); The test expects exit code 134 when jni check fails, so it fails on Windows. Maybe we should have Windows also to return 134 for consistence? The fix changes the check to non-zero exit code. ------------- Commit messages: - remove test from problem list - Merge branch 'master' into JDK-8269923-exit-code - v0 Changes: https://git.openjdk.java.net/jdk/pull/4696/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4696&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269923 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4696.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4696/head:pull/4696 PR: https://git.openjdk.java.net/jdk/pull/4696 From iklam at openjdk.java.net Tue Jul 6 20:09:04 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Jul 2021 20:09:04 GMT Subject: [jdk17] RFR: 8268778: CDS check_excluded_classes needs DumpTimeTable_lock Message-ID: Please review this clean backport from openjdk/jdk to jdk17. Since the fix may impact timing and locking order, I decided to apply the fix in the mainline repo first. After 2 weeks of testing there, no problems are found. So it should be safe to integrate the fix into JDK 17. ------------- Commit messages: - 8268778: CDS check_excluded_classes needs DumpTimeTable_lock Changes: https://git.openjdk.java.net/jdk17/pull/220/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=220&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268778 Stats: 10 lines in 3 files changed: 5 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/220.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/220/head:pull/220 PR: https://git.openjdk.java.net/jdk17/pull/220 From minqi at openjdk.java.net Tue Jul 6 20:19:48 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 6 Jul 2021 20:19:48 GMT Subject: [jdk17] RFR: 8268778: CDS check_excluded_classes needs DumpTimeTable_lock In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 20:00:23 GMT, Ioi Lam wrote: > Please review this clean backport from openjdk/jdk to jdk17. > > Since the fix may impact timing and locking order, I decided to apply the fix in the mainline repo first. After 2 weeks of testing there, no problems are found. So it should be safe to integrate the fix into JDK 17. Looks good! ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/220 From dcubed at openjdk.java.net Tue Jul 6 20:46:50 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 6 Jul 2021 20:46:50 GMT Subject: RFR: 8269923: runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java failed with "FATAL ERROR in native method: Primitive type array expected but not received for JNI array operation" In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 18:52:46 GMT, Zhengyu Gu wrote: > On Posix compatible platforms, when abort with code dump, it exits with os:abort(), which has exit code 134. > > if (dump_core) { > LINUX_ONLY(if (DumpPrivateMappingsInCore) ClassLoader::close_jrt_image();) > ::abort(); // dump core > } > > > but not on Windows, where it still exits with 1. > > > CloseHandle(dumpFile); > win32::exit_process_or_thread(win32::EPT_PROCESS, 1); > > > The test expects exit code 134 when jni check fails, so it fails on Windows. Maybe we should have Windows also to return 134 for consistence? > > The fix changes the check to non-zero exit code. Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4696 From ccheung at openjdk.java.net Tue Jul 6 20:47:49 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 6 Jul 2021 20:47:49 GMT Subject: [jdk17] RFR: 8268778: CDS check_excluded_classes needs DumpTimeTable_lock In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 20:00:23 GMT, Ioi Lam wrote: > Please review this clean backport from openjdk/jdk to jdk17. > > Since the fix may impact timing and locking order, I decided to apply the fix in the mainline repo first. After 2 weeks of testing there, no problems are found. So it should be safe to integrate the fix into JDK 17. LGTM. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/220 From dcubed at openjdk.java.net Tue Jul 6 20:54:52 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 6 Jul 2021 20:54:52 GMT Subject: RFR: 8269923: runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java failed with "FATAL ERROR in native method: Primitive type array expected but not received for JNI array operation" In-Reply-To: References: Message-ID: <9Ca8-svf-Kn25QEQYrVth96xUpyQWKUU8tFwqQWrHV8=.ecdfe239-7986-4982-8279-1869e648ea18@github.com> On Tue, 6 Jul 2021 18:52:46 GMT, Zhengyu Gu wrote: > On Posix compatible platforms, when abort with code dump, it exits with os:abort(), which has exit code 134. > > if (dump_core) { > LINUX_ONLY(if (DumpPrivateMappingsInCore) ClassLoader::close_jrt_image();) > ::abort(); // dump core > } > > > but not on Windows, where it still exits with 1. > > > CloseHandle(dumpFile); > win32::exit_process_or_thread(win32::EPT_PROCESS, 1); > > > The test expects exit code 134 when jni check fails, so it fails on Windows. Maybe we should have Windows also to return 134 for consistence? > > The fix changes the check to non-zero exit code. @zhengyu123 - I forgot to ask about what testing has been done? ------------- PR: https://git.openjdk.java.net/jdk/pull/4696 From iklam at openjdk.java.net Tue Jul 6 21:31:47 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Jul 2021 21:31:47 GMT Subject: RFR: 8263538: SharedArchiveConsistency.java should test -Xshare:auto as well In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 17:08:31 GMT, Yumin Qi wrote: > Hi, please review > > When this test run with -Xshare:on, it will exit when the shared archive is corrupted or mismatch. Make it run with -Xshare:auto will expand code coverage and to keep app run without using the CDS. > > Tests: Mach5 tier1,tier4 > > Thanks > Yumin test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java line 437: > 435: if (!shareAuto) { > 436: output.shouldContain("Hello World"); > 437: } Are lines 431-437 still necessary, now that both -Xshare:on and -Xshare:off are already executed for this test scenario. ------------- PR: https://git.openjdk.java.net/jdk/pull/4694 From minqi at openjdk.java.net Tue Jul 6 21:59:52 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 6 Jul 2021 21:59:52 GMT Subject: RFR: 8263538: SharedArchiveConsistency.java should test -Xshare:auto as well In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 21:25:04 GMT, Ioi Lam wrote: >> Hi, please review >> >> When this test run with -Xshare:on, it will exit when the shared archive is corrupted or mismatch. Make it run with -Xshare:auto will expand code coverage and to keep app run without using the CDS. >> >> Tests: Mach5 tier1,tier4 >> >> Thanks >> Yumin > > test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java line 437: > >> 435: if (!shareAuto) { >> 436: output.shouldContain("Hello World"); >> 437: } > > Are lines 431-437 still necessary, now that both -Xshare:on and -Xshare:off are already executed for this test scenario. I was thinking of that either, the comment said using same archive. The other run with new created archive ---- though they have same contents. I could delete this part. ------------- PR: https://git.openjdk.java.net/jdk/pull/4694 From iklam at openjdk.java.net Tue Jul 6 22:01:56 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Jul 2021 22:01:56 GMT Subject: RFR: 8264735: Make dynamic dump repeatable [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 20:12:23 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Currently after dynamic dump, dump time tables (`_dumptime_talbles, _dumptime_lambda_proxy_class_dictionary and _saved_shared_path_table`) are corrupted and could not be used for next dump. The patch clones the three tables, and after dump restore them so the next dump is possible. With the fix, jcmd VM.cds dynamic_dump can do multiple dump to the same live process. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, added check holding for DumpTimeTable_lock Changes requested by iklam (Reviewer). src/hotspot/share/cds/dynamicArchive.cpp line 168: > 166: > 167: // Restore dumptime tables > 168: SystemDictionaryShared::restore_dumptime_tables(); Maybe this should be put inside post_dump as well? src/hotspot/share/cds/filemap.cpp line 497: > 495: // if (_saved_shared_path_table.size() > 0) { > 496: // MetadataFactory::free_array(loader_data, _saved_shared_path_table->_table); > 497: // } In `FileMapInfo::copy_shared_path_table()`: Array* array = MetadataFactory::new_array(loader_data, (int)bytes, CHECK); _saved_shared_path_table = SharedPathTable(array, _shared_path_table.size()); You can remember the `array` pointer, e.g. _saved_shared_path_table_array = array; and then call `MetadataFactory::free_array(_saved_shared_path_table_array)` in this function. src/hotspot/share/cds/lambdaProxyClassDictionary.hpp line 167: > 165: // We could not use default ctor, it will destroy allocation_type in debug version and fail to delete. > 166: // see bug 8269537 > 167: DumpTimeLambdaProxyClassDictionary() : _count(0) {} Since you changed the construction call from (ResourceObj::C_HEAP, mtClass)DumpTimeLambdaProxyClassDictionary(); to (ResourceObj::C_HEAP, mtClass)DumpTimeLambdaProxyClassDictionary; I think it's no longer necessary to add the `RunTimeLambdaProxyClassInfo()` and `DumpTimeSharedClassTable()` constructors in this PR. In 8269537, we should find a generic way to prevent this bug from happening. ------------- PR: https://git.openjdk.java.net/jdk/pull/4646 From xliu at openjdk.java.net Tue Jul 6 22:09:13 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 6 Jul 2021 22:09:13 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v3] In-Reply-To: References: Message-ID: > This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. > Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration > only decrements _sem 1 but dequeues N messages. If logging threads keep preempting > async logging thread, it may cause the value of _sem accumulates until overflow! > > The patch corrects the value of _sem after write(). n messages are dequeued/processed. > We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration > decrements n instead of 1. Xin Liu has updated the pull request incrementally with three additional commits since the last revision: - Ignore sem_post failure when _sem of AsyncLogWriter is overflown. - Revert "8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX" This reverts commit 269a1580990fa955c1f9d37ce1d04a6349959992. - Revert "Fix build issue on Windows and simplify the loop." This reverts commit e385f42fa4e03510242039518281077e3c9897cf. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/216/files - new: https://git.openjdk.java.net/jdk17/pull/216/files/e385f42f..10bfce91 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=216&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=216&range=01-02 Stats: 40 lines in 8 files changed: 19 ins; 9 del; 12 mod Patch: https://git.openjdk.java.net/jdk17/pull/216.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/216/head:pull/216 PR: https://git.openjdk.java.net/jdk17/pull/216 From minqi at openjdk.java.net Tue Jul 6 22:09:18 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 6 Jul 2021 22:09:18 GMT Subject: RFR: 8263538: SharedArchiveConsistency.java should test -Xshare:auto as well [v2] In-Reply-To: References: Message-ID: > Hi, please review > > When this test run with -Xshare:on, it will exit when the shared archive is corrupted or mismatch. Make it run with -Xshare:auto will expand code coverage and to keep app run without using the CDS. > > Tests: Mach5 tier1,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Remove special run for -Xshare:auto ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4694/files - new: https://git.openjdk.java.net/jdk/pull/4694/files/7d59a4ea..8544e5dd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4694&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4694&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4694.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4694/head:pull/4694 PR: https://git.openjdk.java.net/jdk/pull/4694 From iklam at openjdk.java.net Tue Jul 6 22:09:18 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Jul 2021 22:09:18 GMT Subject: RFR: 8263538: SharedArchiveConsistency.java should test -Xshare:auto as well [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 22:06:27 GMT, Yumin Qi wrote: >> Hi, please review >> >> When this test run with -Xshare:on, it will exit when the shared archive is corrupted or mismatch. Make it run with -Xshare:auto will expand code coverage and to keep app run without using the CDS. >> >> Tests: Mach5 tier1,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Remove special run for -Xshare:auto LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4694 From iklam at openjdk.java.net Tue Jul 6 22:24:54 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Jul 2021 22:24:54 GMT Subject: [jdk17] RFR: 8268778: CDS check_excluded_classes needs DumpTimeTable_lock In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 20:45:22 GMT, Calvin Cheung wrote: >> Please review this clean backport from openjdk/jdk to jdk17. >> >> Since the fix may impact timing and locking order, I decided to apply the fix in the mainline repo first. After 2 weeks of testing there, no problems are found. So it should be safe to integrate the fix into JDK 17. > > LGTM. Thanks @calvinccheung and @yminqi for the review. Mach5 tiers1/2 testing came out clean (except for known failures). ------------- PR: https://git.openjdk.java.net/jdk17/pull/220 From iklam at openjdk.java.net Tue Jul 6 22:24:55 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Jul 2021 22:24:55 GMT Subject: [jdk17] Integrated: 8268778: CDS check_excluded_classes needs DumpTimeTable_lock In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 20:00:23 GMT, Ioi Lam wrote: > Please review this clean backport from openjdk/jdk to jdk17. > > Since the fix may impact timing and locking order, I decided to apply the fix in the mainline repo first. After 2 weeks of testing there, no problems are found. So it should be safe to integrate the fix into JDK 17. This pull request has now been integrated. Changeset: 0ebf8aa9 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk17/commit/0ebf8aa9d7835ef46394fb6536882b8eac65ea2c Stats: 10 lines in 3 files changed: 5 ins; 3 del; 2 mod 8268778: CDS check_excluded_classes needs DumpTimeTable_lock Reviewed-by: minqi, ccheung ------------- PR: https://git.openjdk.java.net/jdk17/pull/220 From ccheung at openjdk.java.net Tue Jul 6 22:29:51 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 6 Jul 2021 22:29:51 GMT Subject: RFR: 8263538: SharedArchiveConsistency.java should test -Xshare:auto as well [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 22:09:18 GMT, Yumin Qi wrote: >> Hi, please review >> >> When this test run with -Xshare:on, it will exit when the shared archive is corrupted or mismatch. Make it run with -Xshare:auto will expand code coverage and to keep app run without using the CDS. >> >> Tests: Mach5 tier1,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Remove special run for -Xshare:auto Looks good. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4694 From minqi at openjdk.java.net Tue Jul 6 22:29:51 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 6 Jul 2021 22:29:51 GMT Subject: RFR: 8263538: SharedArchiveConsistency.java should test -Xshare:auto as well [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 22:05:14 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove special run for -Xshare:auto > > LGTM. @iklam @calvinccheung Thanks for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4694 From minqi at openjdk.java.net Tue Jul 6 22:29:52 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 6 Jul 2021 22:29:52 GMT Subject: Integrated: 8263538: SharedArchiveConsistency.java should test -Xshare:auto as well In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 17:08:31 GMT, Yumin Qi wrote: > Hi, please review > > When this test run with -Xshare:on, it will exit when the shared archive is corrupted or mismatch. Make it run with -Xshare:auto will expand code coverage and to keep app run without using the CDS. > > Tests: Mach5 tier1,tier4 > > Thanks > Yumin This pull request has now been integrated. Changeset: e8206dbb Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/e8206dbb1758325ce10ac23768c82cb567eed704 Stats: 41 lines in 1 file changed: 26 ins; 3 del; 12 mod 8263538: SharedArchiveConsistency.java should test -Xshare:auto as well Reviewed-by: iklam, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/4694 From dholmes at openjdk.java.net Tue Jul 6 22:42:12 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Jul 2021 22:42:12 GMT Subject: RFR: 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) [v2] In-Reply-To: References: Message-ID: > Please review this simple enhancement that: > > 1. Retries OS thread creation of it fails due to EAGAIN > > This is potentially of limited use as you would need some resources to be released for subsequent calls to succeed. > > 2. Prints the name of the thread being started in the warning/log messages > > This is also of limited use as JavaThread's do not have their correct name at this stage, nor do some system threads. But others do, so it can be informative. > > I looked at trying to (separately) unify this code into a Posix version, but the platform differences are such that it makes it very difficult to try and share code. So this simply updates each the existing code in place. > > Testing: > - builds from tiers 1-3 and GHA > - manual inspection of output from a simple thread exhaustion test (runtime/Thread/ThreadCountLimit.java) > - manual inspection of os+thread logging on java -version > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Update expected output now that thread name is included ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4648/files - new: https://git.openjdk.java.net/jdk/pull/4648/files/330deff1..f30a3e63 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4648&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4648&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4648.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4648/head:pull/4648 PR: https://git.openjdk.java.net/jdk/pull/4648 From minqi at openjdk.java.net Tue Jul 6 23:05:56 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 6 Jul 2021 23:05:56 GMT Subject: RFR: 8264735: Make dynamic dump repeatable [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 21:40:46 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comments, added check holding for DumpTimeTable_lock > > src/hotspot/share/cds/dynamicArchive.cpp line 168: > >> 166: >> 167: // Restore dumptime tables >> 168: SystemDictionaryShared::restore_dumptime_tables(); > > Maybe this should be put inside post_dump as well? It would be better to keep it here with SystemDictionaryShared::clone_dumptime_table(). ------------- PR: https://git.openjdk.java.net/jdk/pull/4646 From coleenp at openjdk.java.net Tue Jul 6 23:05:57 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 6 Jul 2021 23:05:57 GMT Subject: RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 13:17:16 GMT, Christoph G?ttschkes wrote: >> Hi, >> >> please review the following change, which was way too long on my chest. It fixes an assertion in the template interpreter for ARM32-softfp. >> >> For ARM32-softfp, the template interpreter calls into the runtime to load a double constant using the ldc bytecode. After the interpreter loaded the constants, the assert block does some sanity checks on the cached constants. But if the double constant is the first constant to be loaded, the cache is not yet initialized and the check results in a SIGSEGV. >> >> I guarded the usage of `ConstantPool::cp_to_object_index` by another check, which tests if there are any resolved references and if that's the case, the cache has already been initialized and the sanity checks can be performed. > > Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: > > Adds an additional NULL check for the CP _cache. src/hotspot/share/interpreter/interpreterRuntime.cpp line 193: > 191: Bytecode_loadconstant ldc2(m, last_frame.bci()); > 192: int rindex = ldc2.cache_index(); > 193: if (rindex < 0 && m->constants()->resolved_references_or_null() != NULL) I don't see how the code can be running in the interpreter before the rewriter runs, which is in the link stage. The cp_to_object_index() should return a negative number for the condy on primitive type case. ------------- PR: https://git.openjdk.java.net/jdk/pull/4582 From dholmes at openjdk.java.net Tue Jul 6 23:08:49 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Jul 2021 23:08:49 GMT Subject: RFR: 8269923: runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java failed with "FATAL ERROR in native method: Primitive type array expected but not received for JNI array operation" In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 18:52:46 GMT, Zhengyu Gu wrote: > On Posix compatible platforms, when abort with code dump, it exits with os:abort(), which has exit code 134. > > if (dump_core) { > LINUX_ONLY(if (DumpPrivateMappingsInCore) ClassLoader::close_jrt_image();) > ::abort(); // dump core > } > > > but not on Windows, where it still exits with 1. > > > CloseHandle(dumpFile); > win32::exit_process_or_thread(win32::EPT_PROCESS, 1); > > > The test expects exit code 134 when jni check fails, so it fails on Windows. Maybe we should have Windows also to return 134 for consistence? > > The fix changes the check to non-zero exit code. The fix is good. The 134 exit code on Posix systems comes from the fact that abort() raises SIGABRT, which is signal number 6 (b0110) . The exit code of the process is set by the OS in the lower 8 bits of the return value: bits 0-6 contains the signal number; bit 7 is set if a core dump occurs. So we have an exit value of b10000110 == decimal 134. It is debatable whether we should make Windows behave the same for our os::abort. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4696 From dholmes at openjdk.java.net Wed Jul 7 00:42:51 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 7 Jul 2021 00:42:51 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 22:09:13 GMT, Xin Liu wrote: >> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >> async logging thread, it may cause the value of _sem accumulates until overflow! >> >> The patch corrects the value of _sem after write(). n messages are dequeued/processed. >> We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration >> decrements n instead of 1. > > Xin Liu has updated the pull request incrementally with three additional commits since the last revision: > > - Ignore sem_post failure when _sem of AsyncLogWriter is overflown. > - Revert "8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX" > > This reverts commit 269a1580990fa955c1f9d37ce1d04a6349959992. > - Revert "Fix build issue on Windows and simplify the loop." > > This reverts commit e385f42fa4e03510242039518281077e3c9897cf. I've been thinking about how to handle the ERANGE/EOVERFLOW in the Semaphore API. A default arg is one way. I was also considering a specific signal_xx method that allows overflow; or report to the caller that overflow happened. Not sure what might be best. What you have might be simplest for 17 but there are still some issues that need further investigation. See comments below. I think we need other opinions here too. I'm surprised macOS has no overflow checks, it looks like its counter will just wrap when it overflows - which would break things, but of course is very unlikely in real use. Thanks, David src/hotspot/os/windows/semaphore_windows.cpp line 42: > 40: } > 41: > 42: void WindowsSemaphore::signal(uint count, bool ignore_overflow) { I believe the Windows ReleaseSemaphore can also fail with the equivalent of EOVERFLOW if the count would exceed the maximum allowed. We either need to dig deeper into what value of GetlastError we would see, or else ignore all errors if ignore_overflow is set. I think I can tweak a gtest to see what happens. src/hotspot/share/logging/logAsyncWriter.hpp line 113: > 111: // it ignores errno ERANGE and EOVERFLOW. > 112: class AsyncLogSemaphore : public CHeapObj { > 113: SemaphoreImpl _impl; I don't think this is necessary, just call wait(1, true) where needed. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/216 From lzang at openjdk.java.net Wed Jul 7 00:44:11 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 7 Jul 2021 00:44:11 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v3] In-Reply-To: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: > The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. > > This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. Lin Zang has updated the pull request incrementally with two additional commits since the last revision: - Throw exception when decompressed data has incorrect magic number Also remove unreachable code after exception is added. - throw exception when magic number is incorrect in decompressed data ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4685/files - new: https://git.openjdk.java.net/jdk/pull/4685/files/76a69c38..facfb522 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4685&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4685&range=01-02 Stats: 8 lines in 1 file changed: 4 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4685.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4685/head:pull/4685 PR: https://git.openjdk.java.net/jdk/pull/4685 From lzang at openjdk.java.net Wed Jul 7 00:44:12 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 7 Jul 2021 00:44:12 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v2] In-Reply-To: <4DyDn_qhAvYVQ5RAvniXvNMjaluYJfd9-mgR4vm8uZA=.ce307615-2060-487c-afdd-7017f2e55dfe@github.com> References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> <_UWscp9Rnm8LJL3YDJ3r6aj1TVK4QsWtQl_FoRMxjOM=.e17fb67c-8601-4138-8157-16c5253a0bc2@github.com> <4DyDn_qhAvYVQ5RAvniXvNMjaluYJfd9-mgR4vm8uZA=.ce307615-2060-487c-afdd-7017f2e55dfe@github.com> Message-ID: On Tue, 6 Jul 2021 18:12:09 GMT, Chris Plummer wrote: >> Lin Zang has updated the pull request incrementally with one additional commit since the last revision: >> >> divid the try block > > After decompressing, no error or exception is thrown if MAGIC_NUMBER is not found. It just silently fails to print the stack trace. > > Please use "cannot" instead of "can not". Both are grammatically correct, but "cannot" is what is normally used. Hi @plummercj , Thanks for reviewing, I have updated the PR based on your comments, and remove unreachable code introduced by the updated code. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/4685 From dholmes at openjdk.java.net Wed Jul 7 01:17:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 7 Jul 2021 01:17:55 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v3] In-Reply-To: References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: On Wed, 7 Jul 2021 00:44:11 GMT, Lin Zang wrote: >> The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. >> >> This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. > > Lin Zang has updated the pull request incrementally with two additional commits since the last revision: > > - Throw exception when decompressed data has incorrect magic number > > Also remove unreachable code after exception is added. > - throw exception when magic number is incorrect in decompressed data Either deleting the out file needs to be handled correctly in all cases or it should left as-is and fixed in a different RFE that also handles stream closing *try-with-resources?) etc. to clean up the code. Otherwise the actual try/catch changes seem okay. Thanks, David test/lib/jdk/test/lib/hprof/parser/Reader.java line 175: > 173: true, debugLevel); > 174: r.read(); > 175: out.delete(); I thought this was going to handled by the separate RFE to fix the general logic? And you don't delete before throwing below. There should be a finally clause to handle deletion consistently. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4685 From coleenp at openjdk.java.net Wed Jul 7 01:21:06 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Jul 2021 01:21:06 GMT Subject: RFR: 8268635: Corrupt oop in ClassLoaderData Message-ID: We worked on writing a test for this but weren't successful. Based on analysis by @stefank this missing call may have been the cause of the crash. Tested with tier1-3. ------------- Commit messages: - 8268635: Corrupt oop in ClassLoaderData Changes: https://git.openjdk.java.net/jdk/pull/4701/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4701&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268635 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4701.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4701/head:pull/4701 PR: https://git.openjdk.java.net/jdk/pull/4701 From coleenp at openjdk.java.net Wed Jul 7 01:31:07 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Jul 2021 01:31:07 GMT Subject: RFR: 8268635: Corrupt oop in ClassLoaderData [v2] In-Reply-To: References: Message-ID: <5hYUbYj337EQmgbWNQL-j3iN02q_GSOUndNV_3XgchE=.fb25a69c-28ee-4a04-bbd9-33317a56d496@github.com> > We worked on writing a test for this but weren't successful. Based on analysis by @stefank this missing call may have been the cause of the crash. > Tested with tier1-3. Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8268635: Corrupt oop in ClassLoaderData ------------- Changes: https://git.openjdk.java.net/jdk/pull/4701/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4701&range=01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4701.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4701/head:pull/4701 PR: https://git.openjdk.java.net/jdk/pull/4701 From iklam at openjdk.java.net Wed Jul 7 01:31:08 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 7 Jul 2021 01:31:08 GMT Subject: RFR: 8268635: Corrupt oop in ClassLoaderData [v2] In-Reply-To: <5hYUbYj337EQmgbWNQL-j3iN02q_GSOUndNV_3XgchE=.fb25a69c-28ee-4a04-bbd9-33317a56d496@github.com> References: <5hYUbYj337EQmgbWNQL-j3iN02q_GSOUndNV_3XgchE=.fb25a69c-28ee-4a04-bbd9-33317a56d496@github.com> Message-ID: On Wed, 7 Jul 2021 01:28:04 GMT, Coleen Phillimore wrote: >> We worked on writing a test for this but weren't successful. Based on analysis by @stefank this missing call may have been the cause of the crash. >> Tested with tier1-3. > > Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8268635: Corrupt oop in ClassLoaderData LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4701 From coleenp at openjdk.java.net Wed Jul 7 01:31:08 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Jul 2021 01:31:08 GMT Subject: RFR: 8268635: Corrupt oop in ClassLoaderData In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 01:12:38 GMT, Coleen Phillimore wrote: > We worked on writing a test for this but weren't successful. Based on analysis by @stefank this missing call may have been the cause of the crash. > Tested with tier1-3. Thanks Ioi. Sorry about the force push. The github actions were failing because my repo was out of date. ------------- PR: https://git.openjdk.java.net/jdk/pull/4701 From yyang at openjdk.java.net Wed Jul 7 01:42:55 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 7 Jul 2021 01:42:55 GMT Subject: Integrated: 8268425: Show decimal nid of OSThread instead of hex format one In-Reply-To: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com> References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com> Message-ID: On Thu, 10 Jun 2021 02:07:36 GMT, Yi Yang wrote: > From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid `. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool. > > Jstack Before: > > "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable > > "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable > > "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable > > Jstack After: > "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable > > "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable > > "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable > > Top: > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java > 71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb > 50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java > 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java > 99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun This pull request has now been integrated. Changeset: a9e20101 Author: Yi Yang URL: https://git.openjdk.java.net/jdk/commit/a9e201016de119af4b0fd3ebb43768896fb9e5c5 Stats: 6 lines in 3 files changed: 1 ins; 0 del; 5 mod 8268425: Show decimal nid of OSThread instead of hex format one Reviewed-by: stuefe, kevinw ------------- PR: https://git.openjdk.java.net/jdk/pull/4449 From dholmes at openjdk.java.net Wed Jul 7 01:56:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 7 Jul 2021 01:56:52 GMT Subject: RFR: 8268635: Corrupt oop in ClassLoaderData [v2] In-Reply-To: <5hYUbYj337EQmgbWNQL-j3iN02q_GSOUndNV_3XgchE=.fb25a69c-28ee-4a04-bbd9-33317a56d496@github.com> References: <5hYUbYj337EQmgbWNQL-j3iN02q_GSOUndNV_3XgchE=.fb25a69c-28ee-4a04-bbd9-33317a56d496@github.com> Message-ID: On Wed, 7 Jul 2021 01:31:07 GMT, Coleen Phillimore wrote: >> We worked on writing a test for this but weren't successful. Based on analysis by @stefank this missing call may have been the cause of the crash. >> Tested with tier1-3. > > Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8268635: Corrupt oop in ClassLoaderData Hi Coleen, Given the code in `add_handle` this change seems appropriate. But in looking at the other code I did notice that this call to `record_modified_oops` in `ClassLoaderData::record_dependency` seems redundant: > Handle dependency(Thread::current(), to); > add_handle(dependency); > // Added a potentially young gen oop to the ClassLoaderData > record_modified_oops(); > And it did raise a question for me as to whether the code that checks (and potentially clears) _modified_oops can run concurrently with this code, as we set the flag before we actually do the addition in the other methods? Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4701 From lzang at openjdk.java.net Wed Jul 7 02:04:46 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 7 Jul 2021 02:04:46 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test In-Reply-To: References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: On Tue, 6 Jul 2021 03:14:15 GMT, David Holmes wrote: >> The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. >> >> This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. > > The existing message is a generic message covering the general operation of the whole try block. It seems far more appropriate than your new message, which only seems to apply to the final step. ??? > > David Hi @dholmes-ora > Either deleting the out file needs to be handled correctly in all cases or it should left as-is and fixed in a different RFE that also handles stream closing *try-with-resources?) etc. to clean up the code. I have created an issue in JBS (https://bugs.openjdk.java.net/browse/JDK-8269909) to use the try-with-resource for stream closing, and will submit a PR shortly. For out.delete(), I prefer to fix it in this PR as the introduction of throwing exception in my last update makes the original out.delete() unreachable, so I have to add logic to handle it. I will update this PR with a finally block in a minute. Thanks, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/4685 From dholmes at openjdk.java.net Wed Jul 7 02:37:50 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 7 Jul 2021 02:37:50 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 22:09:13 GMT, Xin Liu wrote: >> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >> async logging thread, it may cause the value of _sem accumulates until overflow! >> >> The patch corrects the value of _sem after write(). n messages are dequeued/processed. >> We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration >> decrements n instead of 1. > > Xin Liu has updated the pull request incrementally with three additional commits since the last revision: > > - Ignore sem_post failure when _sem of AsyncLogWriter is overflown. > - Revert "8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX" > > This reverts commit 269a1580990fa955c1f9d37ce1d04a6349959992. > - Revert "Fix build issue on Windows and simplify the loop." > > This reverts commit e385f42fa4e03510242039518281077e3c9897cf. I ran a test on Linux, Windows and OSX. As expected Linux gives EOVERFLOW. OSX the test just times out without error. On Windows we get error 298: ERROR_TOO_MANY_POSTS 298 (0x12A) Too many posts were made to a semaphore. so I think we should check for that and ignore it if ignoring overflow. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From lzang at openjdk.java.net Wed Jul 7 02:39:10 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 7 Jul 2021 02:39:10 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v4] In-Reply-To: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: > The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. > > This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. Lin Zang has updated the pull request incrementally with one additional commit since the last revision: fix the out.delete() logic ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4685/files - new: https://git.openjdk.java.net/jdk/pull/4685/files/facfb522..259b728d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4685&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4685&range=02-03 Stats: 5 lines in 1 file changed: 3 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4685.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4685/head:pull/4685 PR: https://git.openjdk.java.net/jdk/pull/4685 From dholmes at openjdk.java.net Wed Jul 7 02:55:46 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 7 Jul 2021 02:55:46 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v4] In-Reply-To: References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: <1SA6wCGe6JkYPeWqB6u_T0UCYM-KeIPNyeSlOvu0FjI=.bd01f1e5-8175-4e26-b270-d8ea6dfb967f@github.com> On Wed, 7 Jul 2021 02:39:10 GMT, Lin Zang wrote: >> The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. >> >> This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > fix the out.delete() logic I would have added a single try/finally block that encompasses all the code after: File out = new File(deCompressedFile); but what you have also does the job. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4685 From xliu at openjdk.java.net Wed Jul 7 03:20:53 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 7 Jul 2021 03:20:53 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v3] In-Reply-To: References: Message-ID: <02uQ6HksLZgieXB4E1ONXlIUd-xgFAMwrXWF4Sx9U7U=.3e999881-789a-4f40-a68a-a11f9d497acd@github.com> On Tue, 6 Jul 2021 22:09:13 GMT, Xin Liu wrote: >> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >> async logging thread, it may cause the value of _sem accumulates until overflow! >> >> The patch corrects the value of _sem after write(). n messages are dequeued/processed. >> We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration >> decrements n instead of 1. > > Xin Liu has updated the pull request incrementally with three additional commits since the last revision: > > - Ignore sem_post failure when _sem of AsyncLogWriter is overflown. > - Revert "8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX" > > This reverts commit 269a1580990fa955c1f9d37ce1d04a6349959992. > - Revert "Fix build issue on Windows and simplify the loop." > > This reverts commit e385f42fa4e03510242039518281077e3c9897cf. got it. I will cover Windows. ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From minqi at openjdk.java.net Wed Jul 7 04:42:49 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 7 Jul 2021 04:42:49 GMT Subject: RFR: 8264735: Make dynamic dump repeatable [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 21:48:52 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comments, added check holding for DumpTimeTable_lock > > src/hotspot/share/cds/filemap.cpp line 497: > >> 495: // if (_saved_shared_path_table.size() > 0) { >> 496: // MetadataFactory::free_array(loader_data, _saved_shared_path_table->_table); >> 497: // } > > In `FileMapInfo::copy_shared_path_table()`: > > > Array* array = MetadataFactory::new_array(loader_data, (int)bytes, CHECK); > _saved_shared_path_table = SharedPathTable(array, _shared_path_table.size()); > > > You can remember the `array` pointer, e.g. > > > _saved_shared_path_table_array = array; > > > > and then call `MetadataFactory::free_array(_saved_shared_path_table_array)` in this function. Thanks. Remembering for later deletion is OK. > src/hotspot/share/cds/lambdaProxyClassDictionary.hpp line 167: > >> 165: // We could not use default ctor, it will destroy allocation_type in debug version and fail to delete. >> 166: // see bug 8269537 >> 167: DumpTimeLambdaProxyClassDictionary() : _count(0) {} > > Since you changed the construction call from > > (ResourceObj::C_HEAP, mtClass)DumpTimeLambdaProxyClassDictionary(); > > to > > (ResourceObj::C_HEAP, mtClass)DumpTimeLambdaProxyClassDictionary; > > > I think it's no longer necessary to add the `RunTimeLambdaProxyClassInfo()` and `DumpTimeSharedClassTable()` constructors in this PR. In 8269537, we should find a generic way to prevent this bug from happening. Initialization of _count is still needed. I could remove DumpTimeSharedClassTable, but still, we should keep the ctor which initialize the two data members --- though they will be reset in update_counts. I will remove the comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/4646 From xliu at openjdk.java.net Wed Jul 7 05:26:51 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 7 Jul 2021 05:26:51 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v3] In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 00:40:10 GMT, David Holmes wrote: > I'm surprised macOS has no overflow checks, it looks like its counter will just wrap when it overflows - which would break things, but of course is very unlikely in real use. Unlike Posix and Win32, it's not easy for me to find any document about Darwin semaphore API. I guess this is the equivalence of glibc on MacOS. check out `semaphore_signal_internal`. https://opensource.apple.com/source/xnu/xnu-344.21.74/osfmk/kern/sync_sema.c.auto.html if count has overflown, it should return kr from `wait_queue_wakeup64_thread_locked`. ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From david.holmes at oracle.com Wed Jul 7 06:58:53 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Jul 2021 16:58:53 +1000 Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v3] In-Reply-To: References: Message-ID: On 7/07/2021 3:26 pm, Xin Liu wrote: > On Wed, 7 Jul 2021 00:40:10 GMT, David Holmes wrote: > >> I'm surprised macOS has no overflow checks, it looks like its counter will just wrap when it overflows - which would break things, but of course is very unlikely in real use. > > Unlike Posix and Win32, it's not easy for me to find any document about Darwin semaphore API. > > I guess this is the equivalence of glibc on MacOS. check out `semaphore_signal_internal`. > https://opensource.apple.com/source/xnu/xnu-344.21.74/osfmk/kern/sync_sema.c.auto.html > > if count has overflown, it should return kr from `wait_queue_wakeup64_thread_locked`. You mean if count++ wraps around to become negative then the next call to signal will potentially execute that code? As the count++ happens after this that doesn't tell us anything about what happens to the signal that actually causes the overflow. In any case due diligence has been done here. There is no documented error for overflow on macOS. A test for overflow failed to trigger any error within the test timeout period. I'm trying a modified test now to see if I can get any failure. David > ------------- > > PR: https://git.openjdk.java.net/jdk17/pull/216 > From xliu at openjdk.java.net Wed Jul 7 07:06:59 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 7 Jul 2021 07:06:59 GMT Subject: RFR: 8268635: Corrupt oop in ClassLoaderData [v2] In-Reply-To: <5hYUbYj337EQmgbWNQL-j3iN02q_GSOUndNV_3XgchE=.fb25a69c-28ee-4a04-bbd9-33317a56d496@github.com> References: <5hYUbYj337EQmgbWNQL-j3iN02q_GSOUndNV_3XgchE=.fb25a69c-28ee-4a04-bbd9-33317a56d496@github.com> Message-ID: On Wed, 7 Jul 2021 01:31:07 GMT, Coleen Phillimore wrote: >> We worked on writing a test for this but weren't successful. Based on analysis by @stefank this missing call may have been the cause of the crash. >> Tested with tier1-3. > > Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8268635: Corrupt oop in ClassLoaderData Hi, Coleen, Thank you for taking this issue. your code change looks good to me. IIUC, this PR covers the code path from`ModuleEntry::set_shared_protection_domain`, where needs record_modified_oops(). ClassLoaderData::record_dependency() seems to have a redundant `record_modified_oops`, but I don't think it affects correctness. thanks, --lx ------------- PR: https://git.openjdk.java.net/jdk/pull/4701 From xxinliu at amazon.com Wed Jul 7 08:03:19 2021 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 7 Jul 2021 01:03:19 -0700 Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v3] In-Reply-To: References: Message-ID: <89c91612-fba3-d4a2-4b27-6f6eb124c09c@amazon.com> I had a gtest. I think it can trigger overflow issue on different platforms. Since we don't know the cap, we have to increment it one by one. I can't hit any assert on MacOS. TEST(Semaphore, signal_overflow) { Semaphore sem(0); sem.signal((uint)-1); } On 7/6/21 11:58 PM, David Holmes wrote: > e due diligence From xliu at openjdk.java.net Wed Jul 7 08:08:10 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 7 Jul 2021 08:08:10 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v4] In-Reply-To: References: Message-ID: > This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. > Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration > only decrements _sem 1 but dequeues N messages. If logging threads keep preempting > async logging thread, it may cause the value of _sem accumulates until overflow! > > The patch corrects the value of _sem after write(). n messages are dequeued/processed. > We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration > decrements n instead of 1. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Use the new API signal_overflow of semaphore This patch handles overflow scenerios for Posix and Windows. MacOS platform doesn't have any error so we ignore it. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/216/files - new: https://git.openjdk.java.net/jdk17/pull/216/files/10bfce91..47cdfcfd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=216&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=216&range=02-03 Stats: 35 lines in 8 files changed: 6 ins; 17 del; 12 mod Patch: https://git.openjdk.java.net/jdk17/pull/216.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/216/head:pull/216 PR: https://git.openjdk.java.net/jdk17/pull/216 From zgu at openjdk.java.net Wed Jul 7 11:50:52 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 7 Jul 2021 11:50:52 GMT Subject: RFR: 8269923: runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java failed with "FATAL ERROR in native method: Primitive type array expected but not received for JNI array operation" In-Reply-To: <9Ca8-svf-Kn25QEQYrVth96xUpyQWKUU8tFwqQWrHV8=.ecdfe239-7986-4982-8279-1869e648ea18@github.com> References: <9Ca8-svf-Kn25QEQYrVth96xUpyQWKUU8tFwqQWrHV8=.ecdfe239-7986-4982-8279-1869e648ea18@github.com> Message-ID: On Tue, 6 Jul 2021 20:52:07 GMT, Daniel D. Daugherty wrote: >> On Posix compatible platforms, when abort with code dump, it exits with os:abort(), which has exit code 134. >> >> if (dump_core) { >> LINUX_ONLY(if (DumpPrivateMappingsInCore) ClassLoader::close_jrt_image();) >> ::abort(); // dump core >> } >> >> >> but not on Windows, where it still exits with 1. >> >> >> CloseHandle(dumpFile); >> win32::exit_process_or_thread(win32::EPT_PROCESS, 1); >> >> >> The test expects exit code 134 when jni check fails, so it fails on Windows. Maybe we should have Windows also to return 134 for consistence? >> >> The fix changes the check to non-zero exit code. > > @zhengyu123 - I forgot to ask about what testing has been done? @dcubed-ojdk @dholmes-ora Thanks for the reviews. GHA all clean. ------------- PR: https://git.openjdk.java.net/jdk/pull/4696 From zgu at openjdk.java.net Wed Jul 7 11:50:52 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 7 Jul 2021 11:50:52 GMT Subject: Integrated: 8269923: runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java failed with "FATAL ERROR in native method: Primitive type array expected but not received for JNI array operation" In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 18:52:46 GMT, Zhengyu Gu wrote: > On Posix compatible platforms, when abort with code dump, it exits with os:abort(), which has exit code 134. > > if (dump_core) { > LINUX_ONLY(if (DumpPrivateMappingsInCore) ClassLoader::close_jrt_image();) > ::abort(); // dump core > } > > > but not on Windows, where it still exits with 1. > > > CloseHandle(dumpFile); > win32::exit_process_or_thread(win32::EPT_PROCESS, 1); > > > The test expects exit code 134 when jni check fails, so it fails on Windows. Maybe we should have Windows also to return 134 for consistence? > > The fix changes the check to non-zero exit code. This pull request has now been integrated. Changeset: bffb1a71 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/bffb1a7199800ee05bf5fe32b7a6867fdd7bfbbf Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod 8269923: runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java failed with "FATAL ERROR in native method: Primitive type array expected but not received for JNI array operation" Reviewed-by: dcubed, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/4696 From coleenp at openjdk.java.net Wed Jul 7 12:46:54 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Jul 2021 12:46:54 GMT Subject: RFR: 8268635: Corrupt oop in ClassLoaderData [v2] In-Reply-To: <5hYUbYj337EQmgbWNQL-j3iN02q_GSOUndNV_3XgchE=.fb25a69c-28ee-4a04-bbd9-33317a56d496@github.com> References: <5hYUbYj337EQmgbWNQL-j3iN02q_GSOUndNV_3XgchE=.fb25a69c-28ee-4a04-bbd9-33317a56d496@github.com> Message-ID: <1pkcwFLlSrQ4h9cGeXIzKLyERfTVYKk3oHDfeU3Af5k=.6d7fc5df-5b41-4900-a4c0-c1f2dc7f9c89@github.com> On Wed, 7 Jul 2021 01:31:07 GMT, Coleen Phillimore wrote: >> We worked on writing a test for this but weren't successful. Based on analysis by @stefank this missing call may have been the cause of the crash. >> Tested with tier1-3. > > Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8268635: Corrupt oop in ClassLoaderData Thanks David and Xin, thanks for noticing the clearly redundant record_modified_oops. It was left over from when dependency oops were not in the _handles area. @dholmes-ora Serial and Parallel GC clear modified oops in a safepoint. I don't remember how G1 used this field. It has some mechanism of claiming the CLD. Maybe @tschatzl or Kim can check it out. ------------- PR: https://git.openjdk.java.net/jdk/pull/4701 From coleenp at openjdk.java.net Wed Jul 7 12:46:55 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Jul 2021 12:46:55 GMT Subject: RFR: 8268635: Corrupt oop in ClassLoaderData [v2] In-Reply-To: References: <5hYUbYj337EQmgbWNQL-j3iN02q_GSOUndNV_3XgchE=.fb25a69c-28ee-4a04-bbd9-33317a56d496@github.com> Message-ID: On Wed, 7 Jul 2021 01:27:02 GMT, Ioi Lam wrote: >> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> 8268635: Corrupt oop in ClassLoaderData > > LGTM Thanks @iklam for the review and help trying to write the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/4701 From coleenp at openjdk.java.net Wed Jul 7 12:46:55 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Jul 2021 12:46:55 GMT Subject: Integrated: 8268635: Corrupt oop in ClassLoaderData In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 01:12:38 GMT, Coleen Phillimore wrote: > We worked on writing a test for this but weren't successful. Based on analysis by @stefank this missing call may have been the cause of the crash. > Tested with tier1-3. This pull request has now been integrated. Changeset: 3586a233 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/3586a233a49c979e87fed9df148d0bf3df2df38b Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8268635: Corrupt oop in ClassLoaderData Reviewed-by: iklam, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/4701 From mgronlun at openjdk.java.net Wed Jul 7 14:09:09 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 7 Jul 2021 14:09:09 GMT Subject: Integrated: 8270027: ProblemList jdk/jfr/event/oldobject/TestObjectSize.java on macOS-x64 In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 13:58:59 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/jfr/event/oldobject/TestObjectSize.java on macOS-x64. Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4709 From dcubed at openjdk.java.net Wed Jul 7 14:09:09 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 7 Jul 2021 14:09:09 GMT Subject: Integrated: 8270027: ProblemList jdk/jfr/event/oldobject/TestObjectSize.java on macOS-x64 In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 14:02:45 GMT, Markus Gr?nlund wrote: >> A trivial fix to ProblemList jdk/jfr/event/oldobject/TestObjectSize.java on macOS-x64. > > Marked as reviewed by mgronlun (Reviewer). @mgronlun - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4709 From dcubed at openjdk.java.net Wed Jul 7 14:09:09 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 7 Jul 2021 14:09:09 GMT Subject: Integrated: 8270027: ProblemList jdk/jfr/event/oldobject/TestObjectSize.java on macOS-x64 Message-ID: A trivial fix to ProblemList jdk/jfr/event/oldobject/TestObjectSize.java on macOS-x64. ------------- Commit messages: - 8270027: ProblemList jdk/jfr/event/oldobject/TestObjectSize.java on macOS-x64 Changes: https://git.openjdk.java.net/jdk/pull/4709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4709&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270027 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4709/head:pull/4709 PR: https://git.openjdk.java.net/jdk/pull/4709 From dcubed at openjdk.java.net Wed Jul 7 14:09:10 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 7 Jul 2021 14:09:10 GMT Subject: Integrated: 8270027: ProblemList jdk/jfr/event/oldobject/TestObjectSize.java on macOS-x64 In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 13:58:59 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/jfr/event/oldobject/TestObjectSize.java on macOS-x64. This pull request has now been integrated. Changeset: 2209e3ec Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/2209e3ec655d6013adc8dd5a463235b5db4d73d4 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8270027: ProblemList jdk/jfr/event/oldobject/TestObjectSize.java on macOS-x64 Reviewed-by: mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/4709 From minqi at openjdk.java.net Wed Jul 7 14:59:19 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 7 Jul 2021 14:59:19 GMT Subject: RFR: 8264735: Make dynamic dump repeatable [v3] In-Reply-To: References: Message-ID: > Hi, Please review > > Currently after dynamic dump, dump time tables (`_dumptime_talbles, _dumptime_lambda_proxy_class_dictionary and _saved_shared_path_table`) are corrupted and could not be used for next dump. The patch clones the three tables, and after dump restore them so the next dump is possible. With the fix, jcmd VM.cds dynamic_dump can do multiple dump to the same live process. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Save SharedPathTable array for later reclaim, remove comments for ctors - Merge branch 'master' into jdk-8264735 - Fix comments, added check holding for DumpTimeTable_lock - 8264735: Make dynamic dump repeatable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4646/files - new: https://git.openjdk.java.net/jdk/pull/4646/files/9b64a16f..28dfcaf0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4646&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4646&range=01-02 Stats: 21819 lines in 383 files changed: 7345 ins; 12735 del; 1739 mod Patch: https://git.openjdk.java.net/jdk/pull/4646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4646/head:pull/4646 PR: https://git.openjdk.java.net/jdk/pull/4646 From cjplummer at openjdk.java.net Wed Jul 7 17:47:52 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 7 Jul 2021 17:47:52 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v4] In-Reply-To: References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: On Wed, 7 Jul 2021 02:39:10 GMT, Lin Zang wrote: >> The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. >> >> This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > fix the out.delete() logic There is still an inconsistency exception handling. For the outer bad MAGIC_NUMBER handling you have: 186 throw new IOException("Unrecognized magic number: " + i); But the decompressed handling results in: 178 throw new IOException("Unrecognized magic number of decompressed data: " + i); Which is caught and wrapped by: 181 throw new IOException("Cannot get stack trace from the compressed hprof file", e); Also, nothing is wrapping exceptions thrown by the following code: 143 HprofReader r 144 = new HprofReader(heapFile, in, dumpNumber, 145 true, debugLevel); 146 r.read(); 147 return r.printStackTraces(); But any exception thrown by the following code is wrapped and rethrown at line 181: 172 HprofReader r 173 = new HprofReader(deCompressedFile, in2, dumpNumber, 174 true, debugLevel); 175 r.read(); 176 return r.printStackTraces(); ------------- PR: https://git.openjdk.java.net/jdk/pull/4685 From iklam at openjdk.java.net Wed Jul 7 19:26:59 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 7 Jul 2021 19:26:59 GMT Subject: RFR: 8264735: Make dynamic dump repeatable [v3] In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 14:59:19 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Currently after dynamic dump, dump time tables (`_dumptime_talbles, _dumptime_lambda_proxy_class_dictionary and _saved_shared_path_table`) are corrupted and could not be used for next dump. The patch clones the three tables, and after dump restore them so the next dump is possible. With the fix, jcmd VM.cds dynamic_dump can do multiple dump to the same live process. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Save SharedPathTable array for later reclaim, remove comments for ctors > - Merge branch 'master' into jdk-8264735 > - Fix comments, added check holding for DumpTimeTable_lock > - 8264735: Make dynamic dump repeatable LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4646 From cjplummer at openjdk.java.net Wed Jul 7 19:42:54 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 7 Jul 2021 19:42:54 GMT Subject: RFR: 8269962: SA has unused Hashtable, Dictionary classes In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 13:27:49 GMT, Coleen Phillimore wrote: > See bug for more details. This code is unused and is soon going to be not in hotspot. > I left in logBytesPerWord() from my previous change because it might be useful in the SA. I could remove it if opinion warrants. > Ran tier1-3. Nice cleanup! ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4708 From minqi at openjdk.java.net Wed Jul 7 19:45:00 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 7 Jul 2021 19:45:00 GMT Subject: RFR: 8264735: Make dynamic dump repeatable [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 16:13:29 GMT, Calvin Cheung wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comments, added check holding for DumpTimeTable_lock > > Marked as reviewed by ccheung (Reviewer). @calvinccheung @iklam Thanks for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4646 From minqi at openjdk.java.net Wed Jul 7 19:45:01 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 7 Jul 2021 19:45:01 GMT Subject: Integrated: 8264735: Make dynamic dump repeatable In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 02:39:07 GMT, Yumin Qi wrote: > Hi, Please review > > Currently after dynamic dump, dump time tables (`_dumptime_talbles, _dumptime_lambda_proxy_class_dictionary and _saved_shared_path_table`) are corrupted and could not be used for next dump. The patch clones the three tables, and after dump restore them so the next dump is possible. With the fix, jcmd VM.cds dynamic_dump can do multiple dump to the same live process. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin This pull request has now been integrated. Changeset: f741e4ca Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/f741e4ca7499193d1d0d07fb27d11cbc0a6de6c1 Stats: 227 lines in 14 files changed: 191 ins; 19 del; 17 mod 8264735: Make dynamic dump repeatable Reviewed-by: ccheung, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/4646 From lzang at openjdk.java.net Wed Jul 7 22:40:51 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 7 Jul 2021 22:40:51 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v4] In-Reply-To: References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: On Wed, 7 Jul 2021 17:45:10 GMT, Chris Plummer wrote: >> Lin Zang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix the out.delete() logic > > There is still an inconsistency exception handling. For the outer bad MAGIC_NUMBER handling you have: > > 186 throw new IOException("Unrecognized magic number: " + i); > > But the decompressed handling results in: > > 178 throw new IOException("Unrecognized magic number of decompressed data: " + i); > > Which is caught and wrapped by: > > 181 throw new IOException("Cannot get stack trace from the compressed hprof file", e); > > Also, nothing is wrapping exceptions thrown by the following code: > > 143 HprofReader r > 144 = new HprofReader(heapFile, in, dumpNumber, > 145 true, debugLevel); > 146 r.read(); > 147 return r.printStackTraces(); > > But any exception thrown by the following code is wrapped and rethrown at line 181: > > 172 HprofReader r > 173 = new HprofReader(deCompressedFile, in2, dumpNumber, > 174 true, debugLevel); > 175 r.read(); > 176 return r.printStackTraces(); Hi @plummercj, Thanks for point it out! I think the throw at line 181 could be removed and the `new = HprofReader(); r.read()` code should be in try block consistently in both situation (compressed/uncompressed). I will make the change. -Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/4685 From coleenp at openjdk.java.net Wed Jul 7 22:45:48 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Jul 2021 22:45:48 GMT Subject: RFR: 8269962: SA has unused Hashtable, Dictionary classes In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 13:27:49 GMT, Coleen Phillimore wrote: > See bug for more details. This code is unused and is soon going to be not in hotspot. > I left in logBytesPerWord() from my previous change because it might be useful in the SA. I could remove it if opinion warrants. > Ran tier1-3. Thank you so much Chris. I was going to send you a note so you'd see this! ------------- PR: https://git.openjdk.java.net/jdk/pull/4708 From lzang at openjdk.java.net Wed Jul 7 22:52:50 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 7 Jul 2021 22:52:50 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v4] In-Reply-To: References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: <52ybGZAxByhmlrzYqMwrgcKsQBnTaTp9W_zy_gjxWB4=.3224a4d0-31a5-4776-b10c-726cb97aed3a@github.com> On Wed, 7 Jul 2021 17:45:10 GMT, Chris Plummer wrote: >> Lin Zang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix the out.delete() logic > > There is still an inconsistency exception handling. For the outer bad MAGIC_NUMBER handling you have: > > 186 throw new IOException("Unrecognized magic number: " + i); > > But the decompressed handling results in: > > 178 throw new IOException("Unrecognized magic number of decompressed data: " + i); > > Which is caught and wrapped by: > > 181 throw new IOException("Cannot get stack trace from the compressed hprof file", e); > > Also, nothing is wrapping exceptions thrown by the following code: > > 143 HprofReader r > 144 = new HprofReader(heapFile, in, dumpNumber, > 145 true, debugLevel); > 146 r.read(); > 147 return r.printStackTraces(); > > But any exception thrown by the following code is wrapped and rethrown at line 181: > > 172 HprofReader r > 173 = new HprofReader(deCompressedFile, in2, dumpNumber, > 174 true, debugLevel); > 175 r.read(); > 176 return r.printStackTraces(); Hi @plummercj, I just found that maybe there is no need to catch exception from `HprofReader` in this method, just keep it as what it originally did - throw any exception from HprofReader directly. The information from HprofReader's exception is enough for root cause analysis in this case. I will test it and make the change. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/4685 From david.holmes at oracle.com Wed Jul 7 23:40:31 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Jul 2021 09:40:31 +1000 Subject: [EXTERNAL] [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v3] In-Reply-To: <89c91612-fba3-d4a2-4b27-6f6eb124c09c@amazon.com> References: <89c91612-fba3-d4a2-4b27-6f6eb124c09c@amazon.com> Message-ID: On 7/07/2021 6:03 pm, Liu, Xin wrote: > I had a gtest. I think it can trigger overflow issue on different > platforms. Since we don't know the cap, we have to increment it one by > one. I can't hit any assert on MacOS. > > TEST(Semaphore, signal_overflow) { > Semaphore sem(0); > sem.signal((uint)-1); > } Similar here: Semaphore sem(MAX_INT-1); for (uintx i = 0; i < max_uintx; i++) { sem.signal(); } Test times out after 10 minutes on macOS no errors reported. David > > On 7/6/21 11:58 PM, David Holmes wrote: >> e due diligence From iklam at openjdk.java.net Wed Jul 7 23:55:51 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 7 Jul 2021 23:55:51 GMT Subject: RFR: 8269962: SA has unused Hashtable, Dictionary classes In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 13:27:49 GMT, Coleen Phillimore wrote: > See bug for more details. This code is unused and is soon going to be not in hotspot. > I left in logBytesPerWord() from my previous change because it might be useful in the SA. I could remove it if opinion warrants. > Ran tier1-3. LGTM. Thanks for the cleanup. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4708 From dholmes at openjdk.java.net Thu Jul 8 00:26:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Jul 2021 00:26:52 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v4] In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 08:08:10 GMT, Xin Liu wrote: >> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >> async logging thread, it may cause the value of _sem accumulates until overflow! >> >> The patch corrects the value of _sem after write(). n messages are dequeued/processed. >> We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration >> decrements n instead of 1. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Use the new API signal_overflow of semaphore > > This patch handles overflow scenerios for Posix and Windows. > MacOS platform doesn't have any error so we ignore it. Figuring out the best way to handle this is proving to be quite tricky - sorry. I need to think some more about it. Unfortunately I'm away for a few days after today. David src/hotspot/share/runtime/semaphore.hpp line 53: > 51: ~Semaphore() {} > 52: > 53: void signal(uint count = 1) { _impl.signal(count, false /* ignore_overflow */); } Please change comment to: `/* don't ignore overflow */` as that describes what the `false` argument actually means, rather than just showing what parameter it is providing the value for. src/hotspot/share/runtime/semaphore.hpp line 56: > 54: > 55: // Ignore error of overflow > 56: void signal_overflow(uint count = 1) { I'm a bit unsure about how to name and describe this given that the overflow check only relates to debug builds - in a product build both `signal` and `signal_overflow` are identical. I had missed previously that the `ignore_overflow` parameter was only in the impl API not the main public API. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/216 From dholmes at openjdk.java.net Thu Jul 8 01:10:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Jul 2021 01:10:06 GMT Subject: RFR: 8269962: SA has unused Hashtable, Dictionary classes In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 13:27:49 GMT, Coleen Phillimore wrote: > See bug for more details. This code is unused and is soon going to be not in hotspot. > I left in logBytesPerWord() from my previous change because it might be useful in the SA. I could remove it if opinion warrants. > Ran tier1-3. LGTM too. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4708 From xliu at openjdk.java.net Thu Jul 8 01:23:49 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 8 Jul 2021 01:23:49 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v4] In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 00:23:17 GMT, David Holmes wrote: >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> Use the new API signal_overflow of semaphore >> >> This patch handles overflow scenerios for Posix and Windows. >> MacOS platform doesn't have any error so we ignore it. > > src/hotspot/share/runtime/semaphore.hpp line 56: > >> 54: >> 55: // Ignore error of overflow >> 56: void signal_overflow(uint count = 1) { > > I'm a bit unsure about how to name and describe this given that the overflow check only relates to debug builds - in a product build both `signal` and `signal_overflow` are identical. > > I had missed previously that the `ignore_overflow` parameter was only in the impl API not the main public API. Thanks you for reviewing this change. The reason we only had ignore_overflow in impl API because I defined my own platform-independent Semaphore class, aka. AsyncLogSemaphore in previous revision. I changed type of _sem from Sempahore to AsyncLogSemaphore. I "overloaded" signal(uint count) in that way so I don't pollute "public API". > I don't think this is necessary, just call wait(1, true) where needed. I think your opinion is that it's not necessary. how about I just add a second parameter ignore_overflow to Semaphore::signal with the default value = false? ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From david.holmes at oracle.com Thu Jul 8 01:37:36 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Jul 2021 11:37:36 +1000 Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v4] In-Reply-To: References: Message-ID: <9e2139ca-c4ba-5052-48f5-7c04b5be166a@oracle.com> On 8/07/2021 11:23 am, Xin Liu wrote: > On Thu, 8 Jul 2021 00:23:17 GMT, David Holmes wrote: > >>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Use the new API signal_overflow of semaphore >>> >>> This patch handles overflow scenerios for Posix and Windows. >>> MacOS platform doesn't have any error so we ignore it. >> >> src/hotspot/share/runtime/semaphore.hpp line 56: >> >>> 54: >>> 55: // Ignore error of overflow >>> 56: void signal_overflow(uint count = 1) { >> >> I'm a bit unsure about how to name and describe this given that the overflow check only relates to debug builds - in a product build both `signal` and `signal_overflow` are identical. >> >> I had missed previously that the `ignore_overflow` parameter was only in the impl API not the main public API. > > Thanks you for reviewing this change. > > The reason we only had ignore_overflow in impl API because I defined my own platform-independent Semaphore class, aka. AsyncLogSemaphore in previous revision. I changed type of _sem from Sempahore to AsyncLogSemaphore. I "overloaded" signal(uint count) in that way so I don't pollute "public API". > > >> I don't think this is necessary, just call wait(1, true) where needed. > > I think your opinion is that it's not necessary. how about I just add a second parameter ignore_overflow to Semaphore::signal with the default value = false? Sorry I need to think more about the options here. I don't like modifying the public API for a debug-only condition, and I'm not sure how best to address that. David > ------------- > > PR: https://git.openjdk.java.net/jdk17/pull/216 > From xliu at openjdk.java.net Thu Jul 8 01:39:52 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 8 Jul 2021 01:39:52 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v4] In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 08:08:10 GMT, Xin Liu wrote: >> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >> async logging thread, it may cause the value of _sem accumulates until overflow! >> >> The patch corrects the value of _sem after write(). n messages are dequeued/processed. >> We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration >> decrements n instead of 1. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Use the new API signal_overflow of semaphore > > This patch handles overflow scenerios for Posix and Windows. > MacOS platform doesn't have any error so we ignore it. Hi, @tstuefe , Do you mind trying this patch? David and I think we should ignore `sem_post` error when its value has been overflown. It happens rarely and ignoring this error won't affect correctness. I just wonder if this approach can solve the LogConfigurationTest.reconfigure_decorators_MT_vm failure on AIX? > Figuring out the best way to handle this is proving to be quite tricky If it works out, the one open issue is what we should do on MacOS. My option is that we just leave it alone since `semaphore_signal`(not posix semaphore) on Darwin doesn't overflow. We can revisit this later if the assumption turns out false in the future. ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From david.holmes at oracle.com Thu Jul 8 02:01:59 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Jul 2021 12:01:59 +1000 Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v4] In-Reply-To: References: Message-ID: On 8/07/2021 11:39 am, Xin Liu wrote: > On Wed, 7 Jul 2021 08:08:10 GMT, Xin Liu wrote: > >>> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >>> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >>> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >>> async logging thread, it may cause the value of _sem accumulates until overflow! >>> >>> The patch corrects the value of _sem after write(). n messages are dequeued/processed. >>> We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration >>> decrements n instead of 1. >> >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> Use the new API signal_overflow of semaphore >> >> This patch handles overflow scenerios for Posix and Windows. >> MacOS platform doesn't have any error so we ignore it. > > Hi, @tstuefe , > Do you mind trying this patch? David and I think we should ignore `sem_post` error when its value has been overflown. It happens rarely and ignoring this error won't affect correctness. I just wonder if this approach can solve the LogConfigurationTest.reconfigure_decorators_MT_vm failure on AIX? > >> Figuring out the best way to handle this is proving to be quite tricky > > If it works out, the one open issue is what we should do on MacOS. My option is that we just leave it alone since `semaphore_signal`(not posix semaphore) on Darwin doesn't overflow. We can revisit this later if the assumption turns out false in the future. It isn't that it doesn't overflow, but that it doesn't appear to detect the overflow. So what we don't know is what happens to the operation of the semaphore after an overflow occurs - we might incur a situation where wait() will not return until we increment from a huge negative number back to a positive one. I'm also thinking that perhaps we need to handle overflow in product builds, which means changing the API even more. For example: bool signal(int n = 1) and return false if we hit an error like EOVERFLOW. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk17/pull/216 > From mseledtsov at openjdk.java.net Thu Jul 8 02:05:11 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Thu, 8 Jul 2021 02:05:11 GMT Subject: [jdk17] RFR: 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for Linux-aarch64 In-Reply-To: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com> References: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com> Message-ID: On Thu, 8 Jul 2021 01:59:25 GMT, Mikhailo Seledtsov wrote: > Now that "JDK-8268212 Build linux-aarch64 natively" added support for default CDS archive, time to update test configuration for this platform. This is a very small one-line change. Testing: Grepped test sources for isDefaultCDSArchiveSupported. Found the following tests references: test/hotspot/jtreg/runtime/cds/CheckDefaultArchiveFile.java,test/hotspot/jtreg/runtime/cds/CheckSharingWithDefaultArchive.java,test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java Running these tests on Linux-aarch64. @ioilam @calvinccheung @lmesnik Could you please review this one-liner when you have a chance? ------------- PR: https://git.openjdk.java.net/jdk17/pull/229 From mseledtsov at openjdk.java.net Thu Jul 8 02:05:11 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Thu, 8 Jul 2021 02:05:11 GMT Subject: [jdk17] RFR: 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for Linux-aarch64 Message-ID: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com> Now that "JDK-8268212 Build linux-aarch64 natively" added support for default CDS archive, time to update test configuration for this platform. This is a very small one-line change. ------------- Commit messages: - 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for Linux-aarch64 Changes: https://git.openjdk.java.net/jdk17/pull/229/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=229&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269840 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/229.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/229/head:pull/229 PR: https://git.openjdk.java.net/jdk17/pull/229 From minqi at openjdk.java.net Thu Jul 8 02:28:52 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 8 Jul 2021 02:28:52 GMT Subject: [jdk17] RFR: 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for Linux-aarch64 In-Reply-To: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com> References: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com> Message-ID: On Thu, 8 Jul 2021 01:59:25 GMT, Mikhailo Seledtsov wrote: > Now that "JDK-8268212 Build linux-aarch64 natively" added support for default CDS archive, time to update test configuration for this platform. This is a very small one-line change. LGTM. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/229 From iklam at openjdk.java.net Thu Jul 8 03:18:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 8 Jul 2021 03:18:52 GMT Subject: [jdk17] RFR: 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for Linux-aarch64 In-Reply-To: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com> References: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com> Message-ID: On Thu, 8 Jul 2021 01:59:25 GMT, Mikhailo Seledtsov wrote: > Now that "JDK-8268212 Build linux-aarch64 natively" added support for default CDS archive, time to update test configuration for this platform. This is a very small one-line change. Looks good, but this returns true also for osx-aarch64 and windows-aarch64, so the comment message needs to be updated. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/229 From lzang at openjdk.java.net Thu Jul 8 03:28:10 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 8 Jul 2021 03:28:10 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v5] In-Reply-To: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: > The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. > > This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. Lin Zang has updated the pull request incrementally with one additional commit since the last revision: donot wrap the exception from HprofReader ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4685/files - new: https://git.openjdk.java.net/jdk/pull/4685/files/259b728d..0631abe1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4685&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4685&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4685.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4685/head:pull/4685 PR: https://git.openjdk.java.net/jdk/pull/4685 From cjplummer at openjdk.java.net Thu Jul 8 03:42:48 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 8 Jul 2021 03:42:48 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v5] In-Reply-To: References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: On Thu, 8 Jul 2021 03:28:10 GMT, Lin Zang wrote: >> The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. >> >> This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > donot wrap the exception from HprofReader Looks good other than cleaning up the exception message. test/lib/jdk/test/lib/hprof/parser/Reader.java line 178: > 176: return r.printStackTraces(); > 177: } else { > 178: throw new IOException("Unrecognized magic number of decompressed data: " + i); "of decompressed data" just doesn't sound right. I'd suggest either removing it, or maybe instead say "...found in decompressed data". ------------- Changes requested by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4685 From lzang at openjdk.java.net Thu Jul 8 03:47:09 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 8 Jul 2021 03:47:09 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v6] In-Reply-To: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: > The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. > > This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. Lin Zang has updated the pull request incrementally with one additional commit since the last revision: refine error message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4685/files - new: https://git.openjdk.java.net/jdk/pull/4685/files/0631abe1..d91ffd83 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4685&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4685&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4685.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4685/head:pull/4685 PR: https://git.openjdk.java.net/jdk/pull/4685 From dholmes at openjdk.java.net Thu Jul 8 03:59:50 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Jul 2021 03:59:50 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v6] In-Reply-To: References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: On Thu, 8 Jul 2021 03:47:09 GMT, Lin Zang wrote: >> The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. >> >> This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > refine error message LGTM. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4685 From lzang at openjdk.java.net Thu Jul 8 03:59:51 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 8 Jul 2021 03:59:51 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v6] In-Reply-To: References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: On Thu, 8 Jul 2021 03:47:09 GMT, Lin Zang wrote: >> The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. >> >> This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > refine error message I will mark this PR with integrate. Thanks Chris and David for your reviewing! BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/4685 From stuefe at openjdk.java.net Thu Jul 8 04:43:48 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 8 Jul 2021 04:43:48 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v4] In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 08:08:10 GMT, Xin Liu wrote: >> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >> async logging thread, it may cause the value of _sem accumulates until overflow! >> >> The patch corrects the value of _sem after write(). n messages are dequeued/processed. >> We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration >> decrements n instead of 1. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Use the new API signal_overflow of semaphore > > This patch handles overflow scenerios for Posix and Windows. > MacOS platform doesn't have any error so we ignore it. Sorry for dropping out, I'm snowed in. I put the patch into our AIX CI. Due to the slowness of our AIX hardware, this may take a day or two. ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From cjplummer at openjdk.java.net Thu Jul 8 05:58:48 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 8 Jul 2021 05:58:48 GMT Subject: RFR: 8269886: Inaccurate error message for compressed hprof test [v6] In-Reply-To: References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: On Thu, 8 Jul 2021 03:47:09 GMT, Lin Zang wrote: >> The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. >> >> This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > refine error message Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4685 From lzang at openjdk.java.net Thu Jul 8 06:33:49 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 8 Jul 2021 06:33:49 GMT Subject: Integrated: 8269886: Inaccurate error message for compressed hprof test In-Reply-To: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com> Message-ID: On Tue, 6 Jul 2021 02:55:37 GMT, Lin Zang wrote: > The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis. > > This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info. This pull request has now been integrated. Changeset: 4fbcce11 Author: Lin Zang Committer: David Holmes URL: https://git.openjdk.java.net/jdk/commit/4fbcce119b1736455cb74d0a585097eca617593c Stats: 12 lines in 1 file changed: 7 ins; 2 del; 3 mod 8269886: Inaccurate error message for compressed hprof test Reviewed-by: dholmes, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/4685 From xliu at openjdk.java.net Thu Jul 8 06:38:48 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 8 Jul 2021 06:38:48 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v4] In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 08:08:10 GMT, Xin Liu wrote: >> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >> async logging thread, it may cause the value of _sem accumulates until overflow! >> >> The patch corrects the value of _sem after write(). n messages are dequeued/processed. >> We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration >> decrements n instead of 1. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Use the new API signal_overflow of semaphore > > This patch handles overflow scenerios for Posix and Windows. > MacOS platform doesn't have any error so we ignore it. Thanks! Let's see the result. Meanwhile, allow me refactor this patch and spend more time semaphore of [Darwin-XNU](https://github.com/apple/darwin-xnu) ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From lzang at openjdk.java.net Thu Jul 8 08:24:08 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 8 Jul 2021 08:24:08 GMT Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource Message-ID: 8269909: getStack method in hprof.parser.Reader should use try-with-resource ------------- Commit messages: - 8269909: getStack method in hprof.parser.Reader should use try-with-resource Changes: https://git.openjdk.java.net/jdk/pull/4717/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4717&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269909 Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4717.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4717/head:pull/4717 PR: https://git.openjdk.java.net/jdk/pull/4717 From david.holmes at oracle.com Thu Jul 8 09:31:49 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Jul 2021 19:31:49 +1000 Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v4] In-Reply-To: References: Message-ID: <04104608-643d-e815-a649-f39a9e8b3774@oracle.com> On 8/07/2021 4:38 pm, Xin Liu wrote: > On Wed, 7 Jul 2021 08:08:10 GMT, Xin Liu wrote: > >>> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >>> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >>> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >>> async logging thread, it may cause the value of _sem accumulates until overflow! >>> >>> The patch corrects the value of _sem after write(). n messages are dequeued/processed. >>> We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration >>> decrements n instead of 1. >> >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> Use the new API signal_overflow of semaphore >> >> This patch handles overflow scenerios for Posix and Windows. >> MacOS platform doesn't have any error so we ignore it. > > Thanks! Let's see the result. Meanwhile, allow me refactor this patch and spend more time semaphore of [Darwin-XNU](https://github.com/apple/darwin-xnu) One possibility is to change the code to use a Monitor that acts as the asynclog lock and the wakeup mechanism, with a suitable guard in the writing code so that we don't try to use the Monitor until after it has been initialised (which is after the first log writes may occur). David > ------------- > > PR: https://git.openjdk.java.net/jdk17/pull/216 > From cgo at openjdk.java.net Thu Jul 8 11:02:54 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Thu, 8 Jul 2021 11:02:54 GMT Subject: RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 23:02:50 GMT, Coleen Phillimore wrote: >> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: >> >> Adds an additional NULL check for the CP _cache. > > src/hotspot/share/interpreter/interpreterRuntime.cpp line 193: > >> 191: Bytecode_loadconstant ldc2(m, last_frame.bci()); >> 192: int rindex = ldc2.cache_index(); >> 193: if (rindex < 0 && m->constants()->resolved_references_or_null() != NULL) > > I don't see how the code can be running in the interpreter before the rewriter runs, which is in the link stage. > The cp_to_object_index() should return a negative number for the condy on primitive type case. I am not sure if I follow you. The problem here is that resolve_ldc is **not** called for a condy, but for a CONSTANT_double. Did you follow the discussion on the mailing list? The bot linked it just now, so you might have missed it. But regardless, returning _no_index_sentinel in cp_to_object_index would solve the current problem as well. Regardless of what we do for this issue, I have to fix the root cause of all of this later on anyway (making arm32-softfp no longer try to load a CONSTANT_double using the condy helper methods). ------------- PR: https://git.openjdk.java.net/jdk/pull/4582 From cgo at openjdk.java.net Thu Jul 8 11:09:55 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Thu, 8 Jul 2021 11:09:55 GMT Subject: RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc [v2] In-Reply-To: References: Message-ID: <8cc72Bk1NYbmJZ7VRvJdzdKAzOOf-CwHx4oSBOMHLtk=.6484ee1e-fdba-49c9-95ce-34547e069f7f@github.com> On Tue, 6 Jul 2021 13:17:16 GMT, Christoph G?ttschkes wrote: >> Hi, >> >> please review the following change, which was way too long on my chest. It fixes an assertion in the template interpreter for ARM32-softfp. >> >> For ARM32-softfp, the template interpreter calls into the runtime to load a double constant using the ldc bytecode. After the interpreter loaded the constants, the assert block does some sanity checks on the cached constants. But if the double constant is the first constant to be loaded, the cache is not yet initialized and the check results in a SIGSEGV. >> >> I guarded the usage of `ConstantPool::cp_to_object_index` by another check, which tests if there are any resolved references and if that's the case, the cache has already been initialized and the sanity checks can be performed. > > Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: > > Adds an additional NULL check for the CP _cache. I just created [JDK-8270086](https://bugs.openjdk.java.net/browse/JDK-8270086) as a follow up for this one, to fix the template interpreter to no longer use the condy helpers for CONSTANT_double types. ------------- PR: https://git.openjdk.java.net/jdk/pull/4582 From david.holmes at oracle.com Thu Jul 8 13:16:22 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Jul 2021 23:16:22 +1000 Subject: RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc [v2] In-Reply-To: <8cc72Bk1NYbmJZ7VRvJdzdKAzOOf-CwHx4oSBOMHLtk=.6484ee1e-fdba-49c9-95ce-34547e069f7f@github.com> References: <8cc72Bk1NYbmJZ7VRvJdzdKAzOOf-CwHx4oSBOMHLtk=.6484ee1e-fdba-49c9-95ce-34547e069f7f@github.com> Message-ID: <7da1b719-82ac-50eb-ea5b-e6b924d469dd@oracle.com> On 8/07/2021 9:09 pm, Christoph G?ttschkes wrote: > On Tue, 6 Jul 2021 13:17:16 GMT, Christoph G?ttschkes wrote: > >>> Hi, >>> >>> please review the following change, which was way too long on my chest. It fixes an assertion in the template interpreter for ARM32-softfp. >>> >>> For ARM32-softfp, the template interpreter calls into the runtime to load a double constant using the ldc bytecode. After the interpreter loaded the constants, the assert block does some sanity checks on the cached constants. But if the double constant is the first constant to be loaded, the cache is not yet initialized and the check results in a SIGSEGV. >>> >>> I guarded the usage of `ConstantPool::cp_to_object_index` by another check, which tests if there are any resolved references and if that's the case, the cache has already been initialized and the sanity checks can be performed. >> >> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: >> >> Adds an additional NULL check for the CP _cache. > > I just created [JDK-8270086](https://bugs.openjdk.java.net/browse/JDK-8270086) as a follow up for this one, to fix the template interpreter to no longer use the condy helpers for CONSTANT_double types. I'm confused. It seems to me there is only one problem here: using condy_helper for a non-condy situation. David PS. Apologies in advance as I saw this just before starting a few days vacation. > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4582 > From coleenp at openjdk.java.net Thu Jul 8 14:31:57 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Jul 2021 14:31:57 GMT Subject: Integrated: 8269962: SA has unused Hashtable, Dictionary classes In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 13:27:49 GMT, Coleen Phillimore wrote: > See bug for more details. This code is unused and is soon going to be not in hotspot. > I left in logBytesPerWord() from my previous change because it might be useful in the SA. I could remove it if opinion warrants. > Ran tier1-3. This pull request has now been integrated. Changeset: bca570c5 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/bca570c56ee17cb4735a8360ec79a3ca22049d05 Stats: 669 lines in 14 files changed: 0 ins; 666 del; 3 mod 8269962: SA has unused Hashtable, Dictionary classes Reviewed-by: cjplummer, iklam, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/4708 From coleenp at openjdk.java.net Thu Jul 8 14:31:56 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Jul 2021 14:31:56 GMT Subject: RFR: 8269962: SA has unused Hashtable, Dictionary classes In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 13:27:49 GMT, Coleen Phillimore wrote: > See bug for more details. This code is unused and is soon going to be not in hotspot. > I left in logBytesPerWord() from my previous change because it might be useful in the SA. I could remove it if opinion warrants. > Ran tier1-3. Thanks Ioi and David. ------------- PR: https://git.openjdk.java.net/jdk/pull/4708 From dcubed at openjdk.java.net Thu Jul 8 19:26:06 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 8 Jul 2021 19:26:06 GMT Subject: [jdk17] Integrated: 8270109: ProblemList 4 SA tests on macOS-aarch64 Message-ID: A trivial fix to ProblemList 4 SA tests on macOS-aarch64 ------------- Commit messages: - 8270109: ProblemList 4 SA tests on macOS-aarch64 Changes: https://git.openjdk.java.net/jdk17/pull/234/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=234&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270109 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/234.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/234/head:pull/234 PR: https://git.openjdk.java.net/jdk17/pull/234 From mikael at openjdk.java.net Thu Jul 8 19:26:06 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 8 Jul 2021 19:26:06 GMT Subject: [jdk17] Integrated: 8270109: ProblemList 4 SA tests on macOS-aarch64 In-Reply-To: References: Message-ID: <-tiyR4al6BXPZEmk5ZggZ-tAcB9dUfRlymp18RAIP-E=.c413592d-caa6-4e6d-9038-3a87b6951e32@github.com> On Thu, 8 Jul 2021 19:17:53 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList 4 SA tests on macOS-aarch64 Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/234 From dcubed at openjdk.java.net Thu Jul 8 19:26:06 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 8 Jul 2021 19:26:06 GMT Subject: [jdk17] Integrated: 8270109: ProblemList 4 SA tests on macOS-aarch64 In-Reply-To: <-tiyR4al6BXPZEmk5ZggZ-tAcB9dUfRlymp18RAIP-E=.c413592d-caa6-4e6d-9038-3a87b6951e32@github.com> References: <-tiyR4al6BXPZEmk5ZggZ-tAcB9dUfRlymp18RAIP-E=.c413592d-caa6-4e6d-9038-3a87b6951e32@github.com> Message-ID: On Thu, 8 Jul 2021 19:21:20 GMT, Mikael Vidstedt wrote: >> A trivial fix to ProblemList 4 SA tests on macOS-aarch64 > > Marked as reviewed by mikael (Reviewer). @vidmik - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk17/pull/234 From dcubed at openjdk.java.net Thu Jul 8 19:26:07 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 8 Jul 2021 19:26:07 GMT Subject: [jdk17] Integrated: 8270109: ProblemList 4 SA tests on macOS-aarch64 In-Reply-To: References: Message-ID: <-Fsi2b-BSGPy8rZYTYufdzrV4bFHbIxGMnxuT3kXE80=.f340fb80-8162-415e-a7f7-9f55eedb1e4f@github.com> On Thu, 8 Jul 2021 19:17:53 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList 4 SA tests on macOS-aarch64 This pull request has now been integrated. Changeset: 9acb2a69 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk17/commit/9acb2a69a9f80a6aeae38ce2bf1c9770d4e8a146 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8270109: ProblemList 4 SA tests on macOS-aarch64 Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk17/pull/234 From mseledtsov at openjdk.java.net Thu Jul 8 19:52:53 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Thu, 8 Jul 2021 19:52:53 GMT Subject: [jdk17] RFR: 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for aarch64 platforms In-Reply-To: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com> References: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com> Message-ID: On Thu, 8 Jul 2021 01:59:25 GMT, Mikhailo Seledtsov wrote: > Now that "JDK-8268212 Build linux-aarch64 natively" added support for default CDS archive, time to update test configuration for this platform. This is a very small one-line change. Thanks Ioi. I have updated the issue description and PR description to "Update Platform.isDefaultCDSArchiveSupported() to return true for aarch64 platforms". I can test on Linux-aarch64 and MacOsx-aarch64. I presume Windows-aarch64 is built natively by the OpenJDK community members (if it is built and tested), then this should be fine. ------------- PR: https://git.openjdk.java.net/jdk17/pull/229 From naoto at openjdk.java.net Thu Jul 8 22:07:15 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 8 Jul 2021 22:07:15 GMT Subject: RFR: 8260265: UTF-8 by Default Message-ID: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 ------------- Commit messages: - 8260265: UTF-8 by Default Changes: https://git.openjdk.java.net/jdk/pull/4733/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260265 Stats: 297 lines in 18 files changed: 184 ins; 9 del; 104 mod Patch: https://git.openjdk.java.net/jdk/pull/4733.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4733/head:pull/4733 PR: https://git.openjdk.java.net/jdk/pull/4733 From xliu at openjdk.java.net Thu Jul 8 22:12:23 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 8 Jul 2021 22:12:23 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v5] In-Reply-To: References: Message-ID: > This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. > Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration > only decrements _sem 1 but dequeues N messages. If logging threads keep preempting > async logging thread, it may cause the value of _sem accumulates until overflow! > > The patch corrects the value of _sem after write(). n messages are dequeued/processed. > We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration > decrements n instead of 1. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Refactor code with API change. Semaphore::signal returns a boolean value to indicate it's succeed or not. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/216/files - new: https://git.openjdk.java.net/jdk17/pull/216/files/47cdfcfd..d064af15 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=216&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=216&range=03-04 Stats: 36 lines in 8 files changed: 19 ins; 3 del; 14 mod Patch: https://git.openjdk.java.net/jdk17/pull/216.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/216/head:pull/216 PR: https://git.openjdk.java.net/jdk17/pull/216 From xliu at openjdk.java.net Fri Jul 9 01:33:51 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 9 Jul 2021 01:33:51 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX In-Reply-To: <04104608-643d-e815-a649-f39a9e8b3774@oracle.com> References: <04104608-643d-e815-a649-f39a9e8b3774@oracle.com> Message-ID: On Thu, 8 Jul 2021 09:43:11 GMT, David Holmes wrote: > One possibility is to change the code to use a Monitor that acts as the asynclog lock and the wakeup mechanism, with a suitable guard in the writing code so that we don't try to use the Monitor until after it has been initialised (which is after the first log writes may occur). I am not sure about that. The current code derived from there. HotSpot Monitor needs Thread::current(), but the logging event spans from the very beginning to the very end of JVM. We have to circumvent those cases. On the other hand, I carefully read the implementation of semaphore_signal on Darwin. I am pretty sure it returns KERN_SUCCESS when overflow happens. I added a line of comment in the last revision. Could you take a look at that? ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From coleenp at openjdk.java.net Fri Jul 9 01:43:54 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 9 Jul 2021 01:43:54 GMT Subject: RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 10:59:40 GMT, Christoph G?ttschkes wrote: >> src/hotspot/share/interpreter/interpreterRuntime.cpp line 193: >> >>> 191: Bytecode_loadconstant ldc2(m, last_frame.bci()); >>> 192: int rindex = ldc2.cache_index(); >>> 193: if (rindex < 0 && m->constants()->resolved_references_or_null() != NULL) >> >> I don't see how the code can be running in the interpreter before the rewriter runs, which is in the link stage. >> The cp_to_object_index() should return a negative number for the condy on primitive type case. > > I am not sure if I follow you. The problem here is that resolve_ldc is **not** called for a condy, but for a CONSTANT_double. Did you follow the discussion on the mailing list? The bot linked it just now, so you might have missed it. > But regardless, returning _no_index_sentinel in cp_to_object_index would solve the current problem as well. > > Regardless of what we do for this issue, I have to fix the root cause of all of this later on anyway (making arm32-softfp no longer try to load a CONSTANT_double using the condy helper methods). I read but didn't match the discussion to the code that I was looking at, which wasn't the arm 32 code. int ConstantPool::cp_to_object_index(int cp_index) { // this is harder don't do this so much. int i = reference_map()->find(cp_index); <==== should crash here // We might not find the index for jsr292 call. return (i < 0) ? _no_index_sentinel : i; } The initial comment in the PR says something about the Double being the first thing executed before the cache is initialized, which is wrong, because the interpreter won't run before linking. Linking creates the resolved_references and reference_map fields in the constant pool and cpCache. The problem is that if you fall through and use the condy for Double and there are NO other condys or anything creating the resolved_references array, the assert code should crash in cp_to_object_index. This is because this pointer and _resolved_references aren't initialized for this class. So the guard before cp_to_object_index would be fine, but put a comment like this. // For ARM soft float, there may not be any resolved references. ------------- PR: https://git.openjdk.java.net/jdk/pull/4582 From coleenp at openjdk.java.net Fri Jul 9 01:47:48 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 9 Jul 2021 01:47:48 GMT Subject: RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 01:40:33 GMT, Coleen Phillimore wrote: >> I am not sure if I follow you. The problem here is that resolve_ldc is **not** called for a condy, but for a CONSTANT_double. Did you follow the discussion on the mailing list? The bot linked it just now, so you might have missed it. >> But regardless, returning _no_index_sentinel in cp_to_object_index would solve the current problem as well. >> >> Regardless of what we do for this issue, I have to fix the root cause of all of this later on anyway (making arm32-softfp no longer try to load a CONSTANT_double using the condy helper methods). > > I read but didn't match the discussion to the code that I was looking at, which wasn't the arm 32 code. > > > int ConstantPool::cp_to_object_index(int cp_index) { > // this is harder don't do this so much. > int i = reference_map()->find(cp_index); <==== should crash here > // We might not find the index for jsr292 call. > return (i < 0) ? _no_index_sentinel : i; > } > > > The initial comment in the PR says something about the Double being the first thing executed before the cache is initialized, which is wrong, because the interpreter won't run before linking. Linking creates the resolved_references and reference_map fields in the constant pool and cpCache. The problem is that if you fall through and use the condy for Double and there are NO other condys or anything creating the resolved_references array, the assert code should crash in cp_to_object_index. This is because this pointer and _resolved_references aren't initialized for this class. > > So the guard before cp_to_object_index would be fine, but put a comment like this. > // For ARM soft float, there may not be any resolved references. I wonder if this also a problem if we only condy to a primitive type in the class file so that the resolved_references aren't created. Code from the rewriter: if (tag.is_method_handle() || tag.is_method_type() || tag.is_string() || (tag.is_dynamic_constant() && // keep regular ldc interpreter logic for condy primitives is_reference_type(Signature::basic_type(_pool->uncached_signature_ref_at(cp_index)))) ) { int ref_index = cp_entry_to_resolved_references(cp_index); ------------- PR: https://git.openjdk.java.net/jdk/pull/4582 From mseledtsov at openjdk.java.net Fri Jul 9 01:58:55 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 9 Jul 2021 01:58:55 GMT Subject: [jdk17] Integrated: 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for aarch64 platforms In-Reply-To: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com> References: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com> Message-ID: On Thu, 8 Jul 2021 01:59:25 GMT, Mikhailo Seledtsov wrote: > Now that "JDK-8268212 Build linux-aarch64 natively" added support for default CDS archive, time to update test configuration for this platform. This is a very small one-line change. This pull request has now been integrated. Changeset: 46c610cb Author: Mikhailo Seledtsov URL: https://git.openjdk.java.net/jdk17/commit/46c610cbd84fc19c3f6591c9a6672768fb90c481 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for aarch64 platforms Reviewed-by: minqi, iklam ------------- PR: https://git.openjdk.java.net/jdk17/pull/229 From mseledtsov at openjdk.java.net Fri Jul 9 01:58:55 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 9 Jul 2021 01:58:55 GMT Subject: [jdk17] RFR: 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for aarch64 platforms In-Reply-To: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com> References: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com> Message-ID: On Thu, 8 Jul 2021 01:59:25 GMT, Mikhailo Seledtsov wrote: > Now that "JDK-8268212 Build linux-aarch64 natively" added support for default CDS archive, time to update test configuration for this platform. This is a very small one-line change. Yumin, Ioi, thanks for the review. All relevant tests passed. ------------- PR: https://git.openjdk.java.net/jdk17/pull/229 From stuefe at openjdk.java.net Fri Jul 9 04:57:35 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 9 Jul 2021 04:57:35 GMT Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v3] In-Reply-To: References: Message-ID: On Fri, 25 Jun 2021 06:22:37 GMT, Thomas Stuefe wrote: >> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process. >> >> >> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not. >> >> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes. >> >> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System. >> >> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day. >> >> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes: >> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory >> - as a stop gap measure it allows to release pressure from a high footprint scenario. >> >> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT. >> >> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd. >> >> CSR for this command: https://bugs.openjdk.java.net/browse/JDK-8269345 >> >> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later. >> >> ========= >> >> This patch: >> >> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms. >> - includes a (rather basic) test >> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space) >> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information. >> >> ========= >> >> Example: >> >> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc: >> >> >> >> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident >> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K) >> ^^^^^^^^ >> >> >> We execute the new trim command via jcmd: >> >> >> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap >> 18770: >> Attempting trim... >> Done. >> Virtual size before: 28849744k, after: 28849724k, (-20k) >> RSS before: 8685896k, after: 920740k, (-7765156k) <<<< >> Swap before: 0k, after: 0k, (0k) >> >> >> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory: >> >> >> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident >> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K) >> ^^^^^^^ >> >> >> When the VM is started with -Xlog:os, this is also logged: >> >> >> [139,068s][info][os] malloc_trim: >> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k) >> RSS before: 8685896k, after: 920740k, (-7765156k) >> Swap before: 0k, after: 0k, (0k) > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Volker feedback > - Merge > - Feedback Severin; renamed query function > - start I renamed the command as agreed upon in the CSR discussion. ------------- PR: https://git.openjdk.java.net/jdk/pull/4510 From stuefe at openjdk.java.net Fri Jul 9 04:57:27 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 9 Jul 2021 04:57:27 GMT Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v4] In-Reply-To: References: Message-ID: > Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process. > > > The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not. > > This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes. > > The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System. > > This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day. > > Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes: > - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory > - as a stop gap measure it allows to release pressure from a high footprint scenario. > > Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT. > > I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd. > > CSR for this command: https://bugs.openjdk.java.net/browse/JDK-8269345 > > Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later. > > ========= > > This patch: > > - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms. > - includes a (rather basic) test > - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space) > - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information. > > ========= > > Example: > > A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc: > > > > thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident > Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K) > ^^^^^^^^ > > > We execute the new trim command via jcmd: > > > thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap > 18770: > Attempting trim... > Done. > Virtual size before: 28849744k, after: 28849724k, (-20k) > RSS before: 8685896k, after: 920740k, (-7765156k) <<<< > Swap before: 0k, after: 0k, (0k) > > > It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory: > > > thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident > Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K) > ^^^^^^^ > > > When the VM is started with -Xlog:os, this is also logged: > > > [139,068s][info][os] malloc_trim: > [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k) > RSS before: 8685896k, after: 920740k, (-7765156k) > Swap before: 0k, after: 0k, (0k) Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Rename command (see CSR) - Merge - Volker feedback - Merge - Feedback Severin; renamed query function - start ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4510/files - new: https://git.openjdk.java.net/jdk/pull/4510/files/29807b26..c3f055a1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4510&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4510&range=02-03 Stats: 39473 lines in 836 files changed: 15140 ins; 20856 del; 3477 mod Patch: https://git.openjdk.java.net/jdk/pull/4510.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4510/head:pull/4510 PR: https://git.openjdk.java.net/jdk/pull/4510 From lzang at openjdk.java.net Fri Jul 9 08:21:21 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 9 Jul 2021 08:21:21 GMT Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource [v2] In-Reply-To: References: Message-ID: > 8269909: getStack method in hprof.parser.Reader should use try-with-resource Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into try - 8269909: getStack method in hprof.parser.Reader should use try-with-resource ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4717/files - new: https://git.openjdk.java.net/jdk/pull/4717/files/f2ef4460..161ab172 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4717&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4717&range=00-01 Stats: 1780 lines in 49 files changed: 894 ins; 752 del; 134 mod Patch: https://git.openjdk.java.net/jdk/pull/4717.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4717/head:pull/4717 PR: https://git.openjdk.java.net/jdk/pull/4717 From shade at openjdk.java.net Fri Jul 9 12:20:32 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Jul 2021 12:20:32 GMT Subject: RFR: 8270155: ARM32: Improve register dump in hs_err Message-ID: Noticed that ARM32 hs_errs are formatted weirdly, there is a newline after register value, and it prints the register value twice. `print_location` already prints the value and does the CR for us, so we should just delegate there. Excerpt tefore: Register to memory mapping: r0 = 0xb6b54430 0xb6b54430: in /jdk/lib/server/libjvm.so at 0xb5ceb000 r1 = 0x00000501 0x00000501 is an unknown value r2 = 0xb6b54ef8 0xb6b54ef8: in /jdk/lib/server/libjvm.so at 0xb5ceb000 r3 = 0xb6b54eb4 0xb6b54eb4: in /jdk/lib/server/libjvm.so at 0xb5ceb000 r4 = 0xb6f54000 0xb6f54000 points into unknown readable memory: 0x00000058 | 58 00 00 00 Excerpt after: Register to memory mapping: r0 = 0xb6b3fa70: in /home/pi/shipilev-jdk/build/linux-arm-server-fastdebug/images/jdk/lib/server/libjvm.so at 0xb574a000 r1 = 0x00000501 is an unknown value r2 = 0xb6b40544: in /home/pi/shipilev-jdk/build/linux-arm-server-fastdebug/images/jdk/lib/server/libjvm.so at 0xb574a000 r3 = 0xb6b40500: in /home/pi/shipilev-jdk/build/linux-arm-server-fastdebug/images/jdk/lib/server/libjvm.so at 0xb574a000 r4 = 0x70d6a83c points into unknown readable memory: 0xb6ce8b64 | 64 8b ce b6 Additional testing: - [x] Eyeballing ARM32 crash logs ------------- Commit messages: - 8270155: ARM32: Improve register dump in hs_err Changes: https://git.openjdk.java.net/jdk/pull/4739/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4739&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270155 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4739.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4739/head:pull/4739 PR: https://git.openjdk.java.net/jdk/pull/4739 From minqi at openjdk.java.net Fri Jul 9 19:58:17 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 9 Jul 2021 19:58:17 GMT Subject: RFR: 8267281: Investigate calling MetaspaceShared::link_and_cleanup_shared_classes for jcmd dynamic_dump [v2] In-Reply-To: References: Message-ID: <2ds5F1Io2WVyVNl7pF0hTMrvc69i7TR2Fy6hmyGL0M0=.cce79a0b-bca3-45cf-9970-2f3015e5a83b@github.com> > Hi, Please review > > When using 'jcmd VM.cds dynamic_dump' to dump dynamic archive, we did not call MetaspaceShared::link_and_cleanup_shared_classes, which is linking linkable shared classes before dump. The classes should be those loaded but not yet linked or loaded during verification. It also will regenerate the lambda form invoker holder classes (those recorded in static archive plus loaded during app run time). For static dump, a separate process spawned to dump the static archive, and for dynamic dump without using jcmd, after dump the process will exit, so this function only called once. > With jcmd, we can do multiple dumps to same live process (See bug 8264735) so we need to check if calling this function is safe (do not change runtime data consistency). The lambda form invoker holder classes will be generated every time this function is called either. > The function name is renamed to link_shared_classes, since the cleanup work is no longer done by this function. > > Tests: tier1,tier3,tier4 (going on to finish, without failure found). > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Modified log message and test case for checking this message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4736/files - new: https://git.openjdk.java.net/jdk/pull/4736/files/474cd5fa..e6004a47 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4736&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4736&range=00-01 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4736.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4736/head:pull/4736 PR: https://git.openjdk.java.net/jdk/pull/4736 From wkemper at openjdk.java.net Fri Jul 9 23:19:01 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Fri, 9 Jul 2021 23:19:01 GMT Subject: [jdk17] RFR: 8268635: Corrupt oop in ClassLoaderData Message-ID: Hi all, This pull request contains a backport of commit 3586a233 from the openjdk/jdk repository. The commit being backported was authored by Coleen Phillimore on 7 Jul 2021 and was reviewed by Ioi Lam and David Holmes. Thanks! ------------- Commit messages: - Backport 3586a233a49c979e87fed9df148d0bf3df2df38b Changes: https://git.openjdk.java.net/jdk17/pull/240/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=240&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268635 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/240.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/240/head:pull/240 PR: https://git.openjdk.java.net/jdk17/pull/240 From coleenp at openjdk.java.net Sun Jul 11 18:14:51 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Sun, 11 Jul 2021 18:14:51 GMT Subject: [jdk17] RFR: 8268635: Corrupt oop in ClassLoaderData In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 23:08:55 GMT, William Kemper wrote: > Hi all, > > This pull request contains a backport of commit 3586a233 from the openjdk/jdk repository. > > The commit being backported was authored by Coleen Phillimore on 7 Jul 2021 and was reviewed by Ioi Lam and David Holmes. > > Thanks! Looks good. Thank you for verifying the fix. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/240 From cgo at openjdk.java.net Mon Jul 12 09:56:53 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Mon, 12 Jul 2021 09:56:53 GMT Subject: RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 01:44:07 GMT, Coleen Phillimore wrote: >> I read but didn't match the discussion to the code that I was looking at, which wasn't the arm 32 code. >> >> >> int ConstantPool::cp_to_object_index(int cp_index) { >> // this is harder don't do this so much. >> int i = reference_map()->find(cp_index); <==== should crash here >> // We might not find the index for jsr292 call. >> return (i < 0) ? _no_index_sentinel : i; >> } >> >> >> The initial comment in the PR says something about the Double being the first thing executed before the cache is initialized, which is wrong, because the interpreter won't run before linking. Linking creates the resolved_references and reference_map fields in the constant pool and cpCache. The problem is that if you fall through and use the condy for Double and there are NO other condys or anything creating the resolved_references array, the assert code should crash in cp_to_object_index. This is because this pointer and _resolved_references aren't initialized for this class. >> >> So the guard before cp_to_object_index would be fine, but put a comment like this. >> // For ARM soft float, there may not be any resolved references. > > I wonder if this also a problem if we only condy to a primitive type in the class file so that the resolved_references aren't created. Code from the rewriter: > > > if (tag.is_method_handle() || > tag.is_method_type() || > tag.is_string() || > (tag.is_dynamic_constant() && > // keep regular ldc interpreter logic for condy primitives > is_reference_type(Signature::basic_type(_pool->uncached_signature_ref_at(cp_index)))) > ) { > int ref_index = cp_entry_to_resolved_references(cp_index); I looked through the available condy test cases and think that this case should be covered by `CondyReturnPrimitiveTest.java` and probably `TestDynamicConstant.java`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4582 From akozlov at openjdk.java.net Mon Jul 12 11:15:57 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 12 Jul 2021 11:15:57 GMT Subject: Integrated: 8267666: Add option to jcmd GC.heap_dump to use existing file In-Reply-To: References: Message-ID: On Tue, 25 May 2021 11:23:33 GMT, Anton Kozlov wrote: > Please review a small change that adds an option to GC.heap_dump to use an existing file. > > The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. > > Reviews of the CSR linked to the bug would be appreciated as well. This pull request has now been integrated. Changeset: 7cbb67a3 Author: Anton Kozlov URL: https://git.openjdk.java.net/jdk/commit/7cbb67a3f8adc83a5b51c092a66480d7b22a6bea Stats: 35 lines in 11 files changed: 12 ins; 8 del; 15 mod 8267666: Add option to jcmd GC.heap_dump to use existing file Reviewed-by: rschmelter, clanger ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From rkennke at redhat.com Mon Jul 12 14:04:13 2021 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 12 Jul 2021 16:04:13 +0200 Subject: Why is mark read as MO_RELAXED in read_stable_mark()? Message-ID: <5080550c-1b90-3ca6-1a51-44e47ddd5b4e@redhat.com> Hi Hotspot runtime devs, I am messing a little bit with read_stable_mark() in synchronizer.cpp in Lilliput project (because I want to load the Klass* from the header). I notice that, in read_stable_mark(), we are loading the header with MO_RELAXED memory ordering, even though the INFLATING header is stored either via CAS or (re-)stored with MO_RELEASE. Wouldn't it be more consequential to load the header with MO_ACQUIRE instead? Thanks, Roman From github.com+154109+jglick at openjdk.java.net Mon Jul 12 16:34:57 2021 From: github.com+154109+jglick at openjdk.java.net (Jesse Glick) Date: Mon, 12 Jul 2021 16:34:57 GMT Subject: RFR: 8260265: UTF-8 by Default In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: On Thu, 8 Jul 2021 21:23:00 GMT, Naoto Sato wrote: > This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. > > JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 > CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 I would have expected `System.out` and `.err` to use the console encoding, but application-constructed `PrintStream`s to use UTF-8 by default. ------------- PR: https://git.openjdk.java.net/jdk/pull/4733 From patricio.chilano.mateo at oracle.com Mon Jul 12 17:19:06 2021 From: patricio.chilano.mateo at oracle.com (patricio.chilano.mateo at oracle.com) Date: Mon, 12 Jul 2021 14:19:06 -0300 Subject: Why is mark read as MO_RELAXED in read_stable_mark()? In-Reply-To: <5080550c-1b90-3ca6-1a51-44e47ddd5b4e@redhat.com> References: <5080550c-1b90-3ca6-1a51-44e47ddd5b4e@redhat.com> Message-ID: Hi Roman, On 7/12/21 11:04 AM, Roman Kennke wrote: > Hi Hotspot runtime devs, > > I am messing a little bit with read_stable_mark() in synchronizer.cpp > in Lilliput project (because I want to load the Klass* from the header). > > I notice that, in read_stable_mark(), we are loading the header with > MO_RELAXED memory ordering, even though the INFLATING header is stored > either via CAS or (re-)stored with MO_RELEASE. Wouldn't it be more > consequential to load the header with MO_ACQUIRE instead? For the monitor case I think we already have an address dependency in the reader so there is no need for the acquire. So we first read the monitor address and then use that address to access the _header field(FastHashCode() case) or _owner field(current_thread_holds_lock() and get_lock_owner() cases). The writer in turn orders the stores to _owner/_header and the publishing of the monitor address by using a release store in inflate() (I think this is the one you are referring to). Patricio > Thanks, > Roman > From iklam at openjdk.java.net Mon Jul 12 17:57:59 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 12 Jul 2021 17:57:59 GMT Subject: RFR: 8267281: Investigate calling MetaspaceShared::link_and_cleanup_shared_classes for jcmd dynamic_dump [v2] In-Reply-To: <2ds5F1Io2WVyVNl7pF0hTMrvc69i7TR2Fy6hmyGL0M0=.cce79a0b-bca3-45cf-9970-2f3015e5a83b@github.com> References: <2ds5F1Io2WVyVNl7pF0hTMrvc69i7TR2Fy6hmyGL0M0=.cce79a0b-bca3-45cf-9970-2f3015e5a83b@github.com> Message-ID: On Fri, 9 Jul 2021 19:58:17 GMT, Yumin Qi wrote: >> Hi, Please review >> >> When using 'jcmd VM.cds dynamic_dump' to dump dynamic archive, we did not call MetaspaceShared::link_and_cleanup_shared_classes, which is linking linkable shared classes before dump. The classes should be those loaded but not yet linked or loaded during verification. It also will regenerate the lambda form invoker holder classes (those recorded in static archive plus loaded during app run time). For static dump, a separate process spawned to dump the static archive, and for dynamic dump without using jcmd, after dump the process will exit, so this function only called once. >> With jcmd, we can do multiple dumps to same live process (See bug 8264735) so we need to check if calling this function is safe (do not change runtime data consistency). The lambda form invoker holder classes will be generated every time this function is called either. >> The function name is renamed to link_shared_classes, since the cleanup work is no longer done by this function. >> >> Tests: tier1,tier3,tier4 (going on to finish, without failure found). >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Modified log message and test case for checking this message LGTM, but I think the issue title should be changed to something like "call prepare_for_dynamic_dumping for jcmd dynamic_dump". ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4736 From ccheung at openjdk.java.net Mon Jul 12 18:28:58 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 12 Jul 2021 18:28:58 GMT Subject: RFR: 8267281: Investigate calling MetaspaceShared::link_and_cleanup_shared_classes for jcmd dynamic_dump [v2] In-Reply-To: <2ds5F1Io2WVyVNl7pF0hTMrvc69i7TR2Fy6hmyGL0M0=.cce79a0b-bca3-45cf-9970-2f3015e5a83b@github.com> References: <2ds5F1Io2WVyVNl7pF0hTMrvc69i7TR2Fy6hmyGL0M0=.cce79a0b-bca3-45cf-9970-2f3015e5a83b@github.com> Message-ID: <6zn6DnDXJ582RmBh8KTghjNu9kspvgyrkXmQW7DggHU=.3ccb9c13-9954-4030-ad3a-243392548b32@github.com> On Fri, 9 Jul 2021 19:58:17 GMT, Yumin Qi wrote: >> Hi, Please review >> >> When using 'jcmd VM.cds dynamic_dump' to dump dynamic archive, we did not call MetaspaceShared::link_and_cleanup_shared_classes, which is linking linkable shared classes before dump. The classes should be those loaded but not yet linked or loaded during verification. It also will regenerate the lambda form invoker holder classes (those recorded in static archive plus loaded during app run time). For static dump, a separate process spawned to dump the static archive, and for dynamic dump without using jcmd, after dump the process will exit, so this function only called once. >> With jcmd, we can do multiple dumps to same live process (See bug 8264735) so we need to check if calling this function is safe (do not change runtime data consistency). The lambda form invoker holder classes will be generated every time this function is called either. >> The function name is renamed to link_shared_classes, since the cleanup work is no longer done by this function. >> >> Tests: tier1,tier3,tier4 (going on to finish, without failure found). >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Modified log message and test case for checking this message Looks good. Just one comment. src/hotspot/share/cds/metaspaceShared.cpp line 597: > 595: void MetaspaceShared::link_shared_classes(TRAPS) { > 596: // Collect all loaded ClassLoaderData. > 597: ResourceMark rm; (This is pre-existing) I think the ResourceMark can be removed. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4736 From minqi at openjdk.java.net Mon Jul 12 19:08:57 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 12 Jul 2021 19:08:57 GMT Subject: RFR: 8267281: Call prepare_for_dynamic_dumping for jcmd dynamic_dump [v2] In-Reply-To: <6zn6DnDXJ582RmBh8KTghjNu9kspvgyrkXmQW7DggHU=.3ccb9c13-9954-4030-ad3a-243392548b32@github.com> References: <2ds5F1Io2WVyVNl7pF0hTMrvc69i7TR2Fy6hmyGL0M0=.cce79a0b-bca3-45cf-9970-2f3015e5a83b@github.com> <6zn6DnDXJ582RmBh8KTghjNu9kspvgyrkXmQW7DggHU=.3ccb9c13-9954-4030-ad3a-243392548b32@github.com> Message-ID: On Mon, 12 Jul 2021 18:25:16 GMT, Calvin Cheung wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Modified log message and test case for checking this message > > src/hotspot/share/cds/metaspaceShared.cpp line 597: > >> 595: void MetaspaceShared::link_shared_classes(TRAPS) { >> 596: // Collect all loaded ClassLoaderData. >> 597: ResourceMark rm; > > (This is pre-existing) I think the ResourceMark can be removed. The function is called by both static and dynamic dump, for dynamic caller already set ResourceMark, but static. I will leave this as it is, it may need more check to see if it should be removed. Maybe it can be removed since I did not see any use of the it in the call and its callees. ------------- PR: https://git.openjdk.java.net/jdk/pull/4736 From minqi at openjdk.java.net Mon Jul 12 19:08:56 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 12 Jul 2021 19:08:56 GMT Subject: RFR: 8267281: Call prepare_for_dynamic_dumping for jcmd dynamic_dump [v2] In-Reply-To: References: <2ds5F1Io2WVyVNl7pF0hTMrvc69i7TR2Fy6hmyGL0M0=.cce79a0b-bca3-45cf-9970-2f3015e5a83b@github.com> Message-ID: On Mon, 12 Jul 2021 17:54:41 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Modified log message and test case for checking this message > > LGTM, but I think the issue title should be changed to something like "call prepare_for_dynamic_dumping for jcmd dynamic_dump". @iklam @calvinccheung Thanks for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4736 From minqi at openjdk.java.net Mon Jul 12 19:08:58 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 12 Jul 2021 19:08:58 GMT Subject: Integrated: 8267281: Call prepare_for_dynamic_dumping for jcmd dynamic_dump In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 02:42:07 GMT, Yumin Qi wrote: > Hi, Please review > > When using 'jcmd VM.cds dynamic_dump' to dump dynamic archive, we did not call MetaspaceShared::link_and_cleanup_shared_classes, which is linking linkable shared classes before dump. The classes should be those loaded but not yet linked or loaded during verification. It also will regenerate the lambda form invoker holder classes (those recorded in static archive plus loaded during app run time). For static dump, a separate process spawned to dump the static archive, and for dynamic dump without using jcmd, after dump the process will exit, so this function only called once. > With jcmd, we can do multiple dumps to same live process (See bug 8264735) so we need to check if calling this function is safe (do not change runtime data consistency). The lambda form invoker holder classes will be generated every time this function is called either. > The function name is renamed to link_shared_classes, since the cleanup work is no longer done by this function. > > Tests: tier1,tier3,tier4 (going on to finish, without failure found). > > Thanks > Yumin This pull request has now been integrated. Changeset: a4e5f08f Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/a4e5f08fefac50a1ced7ff4178d9d76f90797949 Stats: 15 lines in 7 files changed: 3 ins; 0 del; 12 mod 8267281: Call prepare_for_dynamic_dumping for jcmd dynamic_dump Reviewed-by: iklam, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/4736 From rkennke at redhat.com Mon Jul 12 19:26:22 2021 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 12 Jul 2021 21:26:22 +0200 Subject: Why is mark read as MO_RELAXED in read_stable_mark()? In-Reply-To: References: <5080550c-1b90-3ca6-1a51-44e47ddd5b4e@redhat.com> Message-ID: <3c8c57e0-03c7-9dfe-ec7b-36ecef35f625@redhat.com> >> Hi Hotspot runtime devs, >> >> I am messing a little bit with read_stable_mark() in synchronizer.cpp >> in Lilliput project (because I want to load the Klass* from the header). >> >> I notice that, in read_stable_mark(), we are loading the header with >> MO_RELAXED memory ordering, even though the INFLATING header is stored >> either via CAS or (re-)stored with MO_RELEASE. Wouldn't it be more >> consequential to load the header with MO_ACQUIRE instead? > For the monitor case I think we already have an address dependency in > the reader so there is no need for the acquire. So we first read the > monitor address and then use that address to access the _header > field(FastHashCode() case) or _owner field(current_thread_holds_lock() > and get_lock_owner() cases). The writer in turn orders the stores to > _owner/_header and the publishing of the monitor address by using a > release store in inflate() (I think this is the one you are referring to). > Thanks Patricio, I am not quite sure that I follow you. On the reader side, given an object, when a thread calls into FastHashCode() or any locking that causes inflation, it needs to read the object header, and that is always done with a plain read. In particular, read_stable_mark() does that, while waiting for the header to become != INFLATING. On the writer side, we use CAS (using MO_SEQ_CST) to temporarily turn on INFLATING(with release_store() to write back the original header, and store with MO_RELEASE to write back the original header. It probably doesn't matter all that much. I am wondering about this because I am currently moving the Klass* into the object header, which means that for klass() implementation, we need to load the header similar to how we do it for hashcode(). In particular it involves read_stable_mark(). Now, there is a variant of klass-accessor that implies acquire-semantics: oopDesc::klass_or_null_acquire(). I am not quite sure why exactly we need acquire semantics there, but in order to implement it, I believe we would have to make a variant of read_stable_mark() that uses acquire semantics to load the header, instead of plain reads. But I'm thinking it may be cleaner overall to always use acquire semantics in read_stable_mark() (mirroring the release-store and seq-cst-CAS), which would make the acquire-accessors for klass() superfluous. What do you think? From patricio.chilano.mateo at oracle.com Mon Jul 12 21:18:50 2021 From: patricio.chilano.mateo at oracle.com (patricio.chilano.mateo at oracle.com) Date: Mon, 12 Jul 2021 18:18:50 -0300 Subject: [External] : Re: Why is mark read as MO_RELAXED in read_stable_mark()? In-Reply-To: <3c8c57e0-03c7-9dfe-ec7b-36ecef35f625@redhat.com> References: <5080550c-1b90-3ca6-1a51-44e47ddd5b4e@redhat.com> <3c8c57e0-03c7-9dfe-ec7b-36ecef35f625@redhat.com> Message-ID: <0b59fc50-b792-b8e1-5ce5-0a8345a3dd5b@oracle.com> On 7/12/21 4:26 PM, Roman Kennke wrote: >>> Hi Hotspot runtime devs, >>> >>> I am messing a little bit with read_stable_mark() in >>> synchronizer.cpp in Lilliput project (because I want to load the >>> Klass* from the header). >>> >>> I notice that, in read_stable_mark(), we are loading the header with >>> MO_RELAXED memory ordering, even though the INFLATING header is >>> stored either via CAS or (re-)stored with MO_RELEASE. Wouldn't it be >>> more consequential to load the header with MO_ACQUIRE instead? >> For the monitor case I think we already have an address dependency in >> the reader so there is no need for the acquire. So we first read the >> monitor address and then use that address to access the _header >> field(FastHashCode() case) or _owner >> field(current_thread_holds_lock() and get_lock_owner() cases). The >> writer in turn orders the stores to _owner/_header and the publishing >> of the monitor address by using a release store in inflate() (I think >> this is the one you are referring to). >> > > Thanks Patricio, > > I am not quite sure that I follow you. > > On the reader side, given an object, when a thread calls into > FastHashCode() or any locking that causes inflation, it needs to read > the object header, and that is always done with a plain read. In > particular, read_stable_mark() does that, while waiting for the header > to become != INFLATING. On the writer side, we use CAS (using > MO_SEQ_CST) to temporarily turn on INFLATING(with release_store() to > write back the original header, and store with MO_RELEASE to write > back the original header. > > It probably doesn't matter all that much. > > I am wondering about this because I am currently moving the Klass* > into the object header, which means that for klass() implementation, > we need to load the header similar to how we do it for hashcode(). In > particular it involves read_stable_mark(). Now, there is a variant of > klass-accessor that implies acquire-semantics: > oopDesc::klass_or_null_acquire(). I am not quite sure why exactly we > need acquire semantics there, but in order to implement it, I believe > we would have to make a variant of read_stable_mark() that uses > acquire semantics to load the header, instead of plain reads. > > But I'm thinking it may be cleaner overall to always use acquire > semantics in read_stable_mark() (mirroring the release-store and > seq-cst-CAS), which would make the acquire-accessors for klass() > superfluous. > > What do you think? It definitely doesn't break correctness if you add it and probably doesn't change anything in terms of performance. Now, looking back in history, klass_or_null_acquire() was added in 8166583 to protect against reading a partially allocated object. The description of the issue actually argues to explicitly have klass_or_null_acquire() instead of making klass_or_null() quietly have acquire semantics. If that is the case then I think you would still need to have a version with a plain load without the extra fence. You could probably have two versions of read_stable_mark() by refactoring everything except the load of the mark and check into a separate shared function. Also by removing the uneeded extra code before the 'for' loop will make them even shorter. Another option, although more conservative in terms of memory ordering on certain cpus, is to keep read_stable_mark() as is and have klass_or_null_acquire() use a standalone OrderAccess::acquire() fence before returning. I think any solution would work, but maybe wait for somebody else to chime in to hear other thoughts. Thanks, Patricio From mseledtsov at openjdk.java.net Mon Jul 12 23:40:52 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Mon, 12 Jul 2021 23:40:52 GMT Subject: [jdk17] RFR: 8268612: a few runtime/memory tests don't check exit code In-Reply-To: References: Message-ID: On Fri, 18 Jun 2021 10:55:08 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that adds checks of exit code to a few `runtime/memory` tests? > from JBS: >> `ReserveMemory.java`, `ReadFromNoaccessArea.java` and `TestLargePagesFlags.java` tests spawn new JVMs but don't check their exit code which might lead to both type-I and type-II errors > > in `ReadFromNoaccessArea.java`, the patch removes throwing of an exception in `DummyClassWithMainTryingToReadFromNoaccessArea` (child process), so we will get 0 as an exit code if/when we don't crash. > > testing: `runtime/memory` tests on `{linux,windows,macosx}-x64` > > Thanks, > -- Igor Looks good to me. ------------- Marked as reviewed by mseledtsov (Committer). PR: https://git.openjdk.java.net/jdk17/pull/97 From david.holmes at oracle.com Tue Jul 13 01:16:46 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Jul 2021 11:16:46 +1000 Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX In-Reply-To: References: <04104608-643d-e815-a649-f39a9e8b3774@oracle.com> Message-ID: <36e2a959-2361-6ffa-af72-b7982ca1b957@oracle.com> On 9/07/2021 11:33 am, Xin Liu wrote: > On Thu, 8 Jul 2021 09:43:11 GMT, David Holmes wrote: > >> One possibility is to change the code to use a Monitor that acts as the > asynclog lock and the wakeup mechanism, with a suitable guard in the > writing code so that we don't try to use the Monitor until after it has > been initialised (which is after the first log writes may occur). > > I am not sure about that. The current code derived from there. HotSpot Monitor needs Thread::current(), but the logging event spans from the very beginning to the very end of JVM. We have to circumvent those cases. But we already circumvent that for async logging. We can't use async logging until after we have called AsyncLogWriter::initialize(). So the synchronization objects used by AsyncLogWriter can be plain Mutex/Monitor, they don't need to be Semaphore. > On the other hand, I carefully read the implementation of semaphore_signal on Darwin. I am pretty sure it returns KERN_SUCCESS when overflow happens. I added a line of comment in the last revision. Could you take a look at that? The issue is not what it returns but how it actually behaves. David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk17/pull/216 > From xliu at openjdk.java.net Tue Jul 13 01:41:57 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 13 Jul 2021 01:41:57 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX In-Reply-To: <36e2a959-2361-6ffa-af72-b7982ca1b957@oracle.com> References: <36e2a959-2361-6ffa-af72-b7982ca1b957@oracle.com> Message-ID: On Tue, 13 Jul 2021 01:18:28 GMT, David Holmes wrote: > But we already circumvent that for async logging. We can't use async logging until after we have called AsyncLogWriter::initialize(). So the synchronization objects used by AsyncLogWriter can be plain Mutex/Monitor, they don't need to be Semaphore. That is not true. I deleted finalize() because it was complex and not necessary after we switch from Monitor to Semaphore. A thread may emit logs even it has deletes itself. I reviewed this line. https://github.com/apple/darwin-xnu/blob/main/osfmk/kern/sync_sema.c#L400 In my understanding, `semaphore_signal` will try to wait up one in the wait queue of the semaphore. if kr != KERN_SUCCESS, it will reset counter to 0 because no one is waiting on that. In our case, we should take this route. I think the behavior is defined. thanks, --lx ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From dholmes at openjdk.java.net Tue Jul 13 02:43:00 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 13 Jul 2021 02:43:00 GMT Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 08:21:21 GMT, Lin Zang wrote: >> 8269909: getStack method in hprof.parser.Reader should use try-with-resource > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into try > - 8269909: getStack method in hprof.parser.Reader should use try-with-resource Hi Lin, I think this is only a partial conversion to try-with-resources. David test/lib/jdk/test/lib/hprof/parser/Reader.java line 154: > 152: File out = new File(deCompressedFile); > 153: // Decompress to get dump file. > 154: try (GZIPInputStream gis = new GZIPInputStream(new FileInputStream(heapFile)); GZipInutStream close() doesn't say anything about closing the original stream, so I think you need to expand this so that you first create the FIS, then the GZIPIS then the FOS. test/lib/jdk/test/lib/hprof/parser/Reader.java line 167: > 165: // Check dump data header and print stack trace. > 166: try (PositionDataInputStream in2 = new PositionDataInputStream( > 167: new BufferedInputStream(new FileInputStream(out)))) { Similarly here. You first need to define and create the FIS, then the BIS, then the PDIS. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4717 From dholmes at openjdk.java.net Tue Jul 13 02:51:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 13 Jul 2021 02:51:56 GMT Subject: RFR: 8270155: ARM32: Improve register dump in hs_err In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 12:12:32 GMT, Aleksey Shipilev wrote: > Noticed that ARM32 hs_errs are formatted weirdly, there is a newline after register value, and it prints the register value twice. `print_location` already prints the value and does the CR for us, so we should just delegate there. > > Excerpt tefore: > > > Register to memory mapping: > > r0 = 0xb6b54430 > 0xb6b54430: in /jdk/lib/server/libjvm.so at 0xb5ceb000 > > r1 = 0x00000501 > 0x00000501 is an unknown value > > r2 = 0xb6b54ef8 > 0xb6b54ef8: in /jdk/lib/server/libjvm.so at 0xb5ceb000 > > r3 = 0xb6b54eb4 > 0xb6b54eb4: in /jdk/lib/server/libjvm.so at 0xb5ceb000 > > r4 = 0xb6f54000 > 0xb6f54000 points into unknown readable memory: 0x00000058 | 58 00 00 00 > > > Excerpt after: > > > Register to memory mapping: > > r0 = 0xb6b3fa70: in /home/pi/shipilev-jdk/build/linux-arm-server-fastdebug/images/jdk/lib/server/libjvm.so at 0xb574a000 > r1 = 0x00000501 is an unknown value > r2 = 0xb6b40544: in /home/pi/shipilev-jdk/build/linux-arm-server-fastdebug/images/jdk/lib/server/libjvm.so at 0xb574a000 > r3 = 0xb6b40500: in /home/pi/shipilev-jdk/build/linux-arm-server-fastdebug/images/jdk/lib/server/libjvm.so at 0xb574a000 > r4 = 0x70d6a83c points into unknown readable memory: 0xb6ce8b64 | 64 8b ce b6 > > > Additional testing: > - [x] Eyeballing ARM32 crash logs Seems fine - and consistent with what is done on some other platforms (x86, PPC) Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4739 From david.holmes at oracle.com Tue Jul 13 03:03:12 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Jul 2021 13:03:12 +1000 Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX In-Reply-To: References: <36e2a959-2361-6ffa-af72-b7982ca1b957@oracle.com> Message-ID: On 13/07/2021 11:41 am, Xin Liu wrote: > On Tue, 13 Jul 2021 01:18:28 GMT, David Holmes wrote: > >> But we already circumvent that for async logging. We can't use async > logging until after we have called AsyncLogWriter::initialize(). So the > synchronization objects used by AsyncLogWriter can be plain > Mutex/Monitor, they don't need to be Semaphore. > > That is not true. I deleted finalize() because it was complex and not necessary after we switch from Monitor to Semaphore. > A thread may emit logs even it has deletes itself. Ah - sorry. I was looking at the VM initialization issue not the thread termination issue. Pity. > I reviewed this line. https://github.com/apple/darwin-xnu/blob/main/osfmk/kern/sync_sema.c#L400 > In my understanding, `semaphore_signal` will try to wait up one in the wait queue of the semaphore. if kr != KERN_SUCCESS, it will reset counter to 0 because no one is waiting on that. In our case, we should take this route. I think the behavior is defined. Sorry but there is no way I'm going to trust any ad-hoc guesses about what exactly that code will do. I don't know any of the invariants of the data structure, exactly what the different fields represent, or how exactly they are maintained. Heck we don't even know that really is the code involved! I will continue to think this about this problem, but I'm not seeing any solution I like so far. Thanks, David ----- > > thanks, > --lx > > ------------- > > PR: https://git.openjdk.java.net/jdk17/pull/216 > From david.holmes at oracle.com Tue Jul 13 04:39:40 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Jul 2021 14:39:40 +1000 Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX In-Reply-To: References: <36e2a959-2361-6ffa-af72-b7982ca1b957@oracle.com> Message-ID: On 13/07/2021 1:03 pm, David Holmes wrote: > On 13/07/2021 11:41 am, Xin Liu wrote: >> On Tue, 13 Jul 2021 01:18:28 GMT, David Holmes >> wrote: >> >>> But we already circumvent that for async logging. We can't use async >> logging until after we have called AsyncLogWriter::initialize(). So the >> synchronization objects used by AsyncLogWriter can be plain >> Mutex/Monitor, they don't need to be Semaphore. >> >> That is not true. I deleted finalize() because it was complex and not >> necessary after we switch from Monitor to Semaphore. >> A thread may emit logs even it has deletes itself. > > Ah - sorry. I was looking at the VM initialization issue not the thread > termination issue. Pity. As @pchilano has pointed out to me we can use the lower-level PlatformMonitor to avoid the problems with Monitor. It is of a similar low-level as Semaphore. Instead of having a binary semaphore to control access to the _buffer, and a counting semaphore to control the wakeup of the async writer thread, we can just use a PlatformMonitor with a _data_available state field e.g (rough outline). void AsyncLogWriter::write() { AsyncLogBuffer logs; { // critical region AsyncLogLocker locker; _buffer.pop_all(&logs); // append meta-messages of dropped counters AsyncLogMapIterator dropped_counters_iter(logs); _stats.iterate(&dropped_counters_iter); _data_available = false; } ... } void AsyncLogWriter::run() { while (true) { { AsyncLogLocker locker; while (!_data_available) _lock.wait(); } write(); } } void AsyncLogWriter::enqueue_locked(const AsyncLogMessage& msg) { ... _buffer.push_back(msg); _data_available = true; _lock.notify(); } David ----- >> I reviewed this line. >> https://github.com/apple/darwin-xnu/blob/main/osfmk/kern/sync_sema.c#L400 >> In my understanding, `semaphore_signal` will try to wait up one in the >> wait queue of the semaphore. if kr != KERN_SUCCESS, it will reset >> counter to 0 because no one is waiting on that. In our case, we should >> take this route.? I think the behavior is defined. > > Sorry but there is no way I'm going to trust any ad-hoc guesses about > what exactly that code will do. I don't know any of the invariants of > the data structure, exactly what the different fields represent, or how > exactly they are maintained. Heck we don't even know that really is the > code involved! > > I will continue to think this about this problem, but I'm not seeing any > solution I like so far. > > Thanks, > David > ----- > > >> >> thanks, >> --lx >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk17/pull/216 >> From cashford at openjdk.java.net Tue Jul 13 04:55:06 2021 From: cashford at openjdk.java.net (Corey Ashford) Date: Tue, 13 Jul 2021 04:55:06 GMT Subject: RFR: JDK-8270340: Base64 decodeBlock intrinsic for Power64 needs cleanup Message-ID: This series of commits was written to accomplish several cleanup and Power10 optimization tasks for the Base64 decodeBlock intrinsic for Power64: * Remove the ISA 3.1+ (Power10+) pextd instruction optimization in decodeBlock. This "optimization" turned out to actually cause a performance hit. Removing it gains back about 3% in performance. * Introduce a constant block, similar to that in use by encodeBlock() to speed up constant loading. * Add the ISA 3.1+ xxpermx instruction and align_prefix() method for use in a Power10 optimization for decodeBlock. Please see the commit log for my concerns about this change. * Implement the xxpermx-based decodeBlock algorithm for Power10+, which gives about a 5% performance boost. More details can be found in the commit logs. I want to note here that I looked into changing the loop_unrolls constant, and found that at large buffer sizes, the values of 2 and 4 give some extra performance gain. For example, on a 20001-byte destination buffer, I see an increase from 4.7X over intrinsic disabled (loop_unrolls=1), to 5.3X over intrinsic disabled (loop_unrolls=4), but on smaller buffer sizes, up to about 512, it causes performance degradation over loop_unrolls=1, so I have decided to stick with the original value of 1, since I don't know where to focus the performance versus buffer length tradeoff. ------------- Commit messages: - macroAssembler_ppc.cpp: fix whitespace error - stubGenerator_ppc.cpp: decodeBlock(): Use xxpermx to improve performance of decodeBlock on Power10+ - Add xxpermx instruction, and align_prefix() method - stubGenerator_cpp.cpp: decodeBlock(): use constant block for loading constants into vector registers for cleaner and faster code - stubGenerator_ppc.cpp: Remove p10 pextd optimization Changes: https://git.openjdk.java.net/jdk/pull/4762/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4762&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270340 Stats: 437 lines in 5 files changed: 206 ins; 126 del; 105 mod Patch: https://git.openjdk.java.net/jdk/pull/4762.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4762/head:pull/4762 PR: https://git.openjdk.java.net/jdk/pull/4762 From stuefe at openjdk.java.net Tue Jul 13 05:03:53 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 13 Jul 2021 05:03:53 GMT Subject: RFR: 8270155: ARM32: Improve register dump in hs_err In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 12:12:32 GMT, Aleksey Shipilev wrote: > Noticed that ARM32 hs_errs are formatted weirdly, there is a newline after register value, and it prints the register value twice. `print_location` already prints the value and does the CR for us, so we should just delegate there. > > Excerpt tefore: > > > Register to memory mapping: > > r0 = 0xb6b54430 > 0xb6b54430: in /jdk/lib/server/libjvm.so at 0xb5ceb000 > > r1 = 0x00000501 > 0x00000501 is an unknown value > > r2 = 0xb6b54ef8 > 0xb6b54ef8: in /jdk/lib/server/libjvm.so at 0xb5ceb000 > > r3 = 0xb6b54eb4 > 0xb6b54eb4: in /jdk/lib/server/libjvm.so at 0xb5ceb000 > > r4 = 0xb6f54000 > 0xb6f54000 points into unknown readable memory: 0x00000058 | 58 00 00 00 > > > Excerpt after: > > > Register to memory mapping: > > r0 = 0xb6b3fa70: in /home/pi/shipilev-jdk/build/linux-arm-server-fastdebug/images/jdk/lib/server/libjvm.so at 0xb574a000 > r1 = 0x00000501 is an unknown value > r2 = 0xb6b40544: in /home/pi/shipilev-jdk/build/linux-arm-server-fastdebug/images/jdk/lib/server/libjvm.so at 0xb574a000 > r3 = 0xb6b40500: in /home/pi/shipilev-jdk/build/linux-arm-server-fastdebug/images/jdk/lib/server/libjvm.so at 0xb574a000 > r4 = 0x70d6a83c points into unknown readable memory: 0xb6ce8b64 | 64 8b ce b6 > > > Additional testing: > - [x] Eyeballing ARM32 crash logs LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4739 From stuefe at openjdk.java.net Tue Jul 13 05:06:51 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 13 Jul 2021 05:06:51 GMT Subject: RFR: 8270155: ARM32: Improve register dump in hs_err In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 02:48:49 GMT, David Holmes wrote: > Seems fine - and consistent with what is done on some other platforms (x86, PPC) > > Thanks, > David Note that there is an inconsistency between platforms. Some versions (aarch64, aix) just print the raw context, some do `print_location` which does a whole lot more. I would feel better with separate steps: writing the context first, then attempting to interpret the register contents. So if print_location crashes, you at least have the raw register values. Maybe for a future RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/4739 From xliu at openjdk.java.net Tue Jul 13 06:10:57 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 13 Jul 2021 06:10:57 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v5] In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 22:12:23 GMT, Xin Liu wrote: >> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >> async logging thread, it may cause the value of _sem accumulates until overflow! >> >> The patch corrects the value of _sem after write(). n messages are dequeued/processed. >> We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration >> decrements n instead of 1. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Refactor code with API change. > > Semaphore::signal returns a boolean value to indicate it's succeed or not. Aha, os::PlatformMonitor is just the cross-platform condition variable, no strings attached! I think it is a better solution. TBH, I don't like 'ignore_overflow'. it's a hack solution. let's save it as a back-up solution. We still have 2 week before phase-2 rampdown. Let me also take a look how JFR handle this case. It is said JFR also has an asynchronous buffer too. ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From david.holmes at oracle.com Tue Jul 13 07:17:56 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Jul 2021 17:17:56 +1000 Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v5] In-Reply-To: References: Message-ID: <614a838c-a5df-c647-54f6-cff78f38f37c@oracle.com> On 13/07/2021 4:10 pm, Xin Liu wrote: > On Thu, 8 Jul 2021 22:12:23 GMT, Xin Liu wrote: > >>> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >>> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >>> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >>> async logging thread, it may cause the value of _sem accumulates until overflow! >>> >>> The patch corrects the value of _sem after write(). n messages are dequeued/processed. >>> We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration >>> decrements n instead of 1. >> >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor code with API change. >> >> Semaphore::signal returns a boolean value to indicate it's succeed or not. > > Aha, os::PlatformMonitor is just the cross-platform condition variable, no strings attached! > I think it is a better solution. TBH, I don't like 'ignore_overflow'. it's a hack solution. let's save it as a back-up solution. > > We still have 2 week before phase-2 rampdown. Let me also take a look how JFR handle this case. It is said JFR also has an asynchronous buffer too. JDK 17 will enter Rampdown Phase Two this Thursday, 15 July, at 15:00 UTC. This needs to be handled promptly. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk17/pull/216 > From xliu at openjdk.java.net Tue Jul 13 07:47:54 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 13 Jul 2021 07:47:54 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v5] In-Reply-To: References: Message-ID: <3UyL6XvpnMfzc9ViezbpYiqQDDzN7Ku5GovP-yRf7Xw=.e5f96987-fdb3-479f-9647-a4f781046b39@github.com> On Thu, 8 Jul 2021 22:12:23 GMT, Xin Liu wrote: >> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >> async logging thread, it may cause the value of _sem accumulates until overflow! >> >> The patch corrects the value of _sem after write(). n messages are dequeued/processed. >> We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration >> decrements n instead of 1. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Refactor code with API change. > > Semaphore::signal returns a boolean value to indicate it's succeed or not. okay. copy that. I will send out a new revision soon. ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From xliu at openjdk.java.net Tue Jul 13 10:20:49 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 13 Jul 2021 10:20:49 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v6] In-Reply-To: References: Message-ID: > This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. > Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration > only decrements _sem 1 but dequeues N messages. If logging threads keep preempting > async logging thread, it may cause the value of _sem accumulates until overflow! > > The patch corrects the value of _sem after write(). n messages are dequeued/processed. > We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration > decrements n instead of 1. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Replace counting semaphaore with os::PlatformMonitor. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/216/files - new: https://git.openjdk.java.net/jdk17/pull/216/files/d064af15..7ac1c26c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=216&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=216&range=04-05 Stats: 60 lines in 9 files changed: 12 ins; 27 del; 21 mod Patch: https://git.openjdk.java.net/jdk17/pull/216.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/216/head:pull/216 PR: https://git.openjdk.java.net/jdk17/pull/216 From dholmes at openjdk.java.net Tue Jul 13 11:30:00 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 13 Jul 2021 11:30:00 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v6] In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 10:20:49 GMT, Xin Liu wrote: >> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >> async logging thread, it may cause the value of _sem accumulates until overflow! >> >> The patch corrects the value of _sem after write(). n messages are dequeued/processed. >> We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration >> decrements n instead of 1. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Replace counting semaphaore with os::PlatformMonitor. Sorry this isn't right at all. David src/hotspot/share/logging/logAsyncWriter.cpp line 163: > 161: while (!_data_available) { > 162: _lock.signal(); > 163: _cv.wait(0/* no timeout */); You can't call wait() on an unlocked monitor - that's not how monitors are used. src/hotspot/share/logging/logAsyncWriter.hpp line 141: > 139: Semaphore _lock; > 140: Semaphore _flush_sem; > 141: os::PlatformMonitor _cv; No this isn't what you need. The _lock is the PlatformMonitor. You lock/unlock in AsyncLogLocker for the critical regions, and then use the wait/notify operations for the coordination. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/216 From cgo at openjdk.java.net Tue Jul 13 13:22:58 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Tue, 13 Jul 2021 13:22:58 GMT Subject: RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc [v2] In-Reply-To: References: Message-ID: <8xiKC-3k4vfnaz6lEplZGVZuFih9IvxWefYJqpO1_y0=.a2b57a50-ccaa-46bc-9359-8ab831f9c6d3@github.com> On Tue, 6 Jul 2021 13:17:16 GMT, Christoph G?ttschkes wrote: >> Hi, >> >> please review the following change, which was way too long on my chest. It fixes an assertion in the template interpreter for ARM32-softfp. >> >> For ARM32-softfp, the template interpreter calls into the runtime to load a double constant using the ldc bytecode. After the interpreter loaded the constants, the assert block does some sanity checks on the cached constants. But if the double constant is the first constant to be loaded, the cache is not yet initialized and the check results in a SIGSEGV. >> >> I guarded the usage of `ConstantPool::cp_to_object_index` by another check, which tests if there are any resolved references and if that's the case, the cache has already been initialized and the sanity checks can be performed. > > Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: > > Adds an additional NULL check for the CP _cache. I will close this PR. I created a fix for the root cause of this issue, please see #4767 ------------- PR: https://git.openjdk.java.net/jdk/pull/4582 From cgo at openjdk.java.net Tue Jul 13 13:22:59 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Tue, 13 Jul 2021 13:22:59 GMT Subject: Withdrawn: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc In-Reply-To: References: Message-ID: On Thu, 24 Jun 2021 11:57:20 GMT, Christoph G?ttschkes wrote: > Hi, > > please review the following change, which was way too long on my chest. It fixes an assertion in the template interpreter for ARM32-softfp. > > For ARM32-softfp, the template interpreter calls into the runtime to load a double constant using the ldc bytecode. After the interpreter loaded the constants, the assert block does some sanity checks on the cached constants. But if the double constant is the first constant to be loaded, the cache is not yet initialized and the check results in a SIGSEGV. > > I guarded the usage of `ConstantPool::cp_to_object_index` by another check, which tests if there are any resolved references and if that's the case, the cache has already been initialized and the sanity checks can be performed. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4582 From vlivanov at openjdk.java.net Tue Jul 13 14:03:56 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 13 Jul 2021 14:03:56 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC In-Reply-To: References: Message-ID: <-CKmdxtDz9PebGwjDU6XEUMukYMC9CKmW2rhm6xZKWM=.8a88e29e-7b17-4647-9848-7a5bd2927fef@github.com> On Fri, 25 Jun 2021 17:38:32 GMT, Jorn Vernee wrote: > This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title. > > Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread. > > The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks. > > FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob. > > Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3 Looks good. src/hotspot/cpu/x86/frame_x86.cpp line 356: > 354: } > 355: > 356: OptimizedEntryBlob::FrameData* OptimizedEntryBlob::frame_data_for_frame(const frame& frame) const { It makes sense to assert that `frame` refers to optimized entry frame (`assert(frame->is_optimized_entry_frame(), "wrong frame");`. src/hotspot/share/runtime/thread.hpp line 1128: > 1126: > 1127: private: > 1128: DEBUG_ONLY(void verify_frame_info();) If you declare `verify_frame_info` as returning a `bool` (and just put a `return true;` at the end of `JavaThread::verify_frame_info()`), you can call it as: assert(verify_frame_info(), "unexpected frame info"); ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/149 From jvernee at openjdk.java.net Tue Jul 13 15:01:57 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 13 Jul 2021 15:01:57 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC In-Reply-To: <-CKmdxtDz9PebGwjDU6XEUMukYMC9CKmW2rhm6xZKWM=.8a88e29e-7b17-4647-9848-7a5bd2927fef@github.com> References: <-CKmdxtDz9PebGwjDU6XEUMukYMC9CKmW2rhm6xZKWM=.8a88e29e-7b17-4647-9848-7a5bd2927fef@github.com> Message-ID: On Tue, 13 Jul 2021 13:52:18 GMT, Vladimir Ivanov wrote: >> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title. >> >> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread. >> >> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks. >> >> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob. >> >> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3 > > src/hotspot/cpu/x86/frame_x86.cpp line 356: > >> 354: } >> 355: >> 356: OptimizedEntryBlob::FrameData* OptimizedEntryBlob::frame_data_for_frame(const frame& frame) const { > > It makes sense to assert that `frame` refers to optimized entry frame (`assert(frame->is_optimized_entry_frame(), "wrong frame");`. Good idea. Thanks > src/hotspot/share/runtime/thread.hpp line 1128: > >> 1126: >> 1127: private: >> 1128: DEBUG_ONLY(void verify_frame_info();) > > If you declare `verify_frame_info` as returning a `bool` (and just put a `return true;` at the end of `JavaThread::verify_frame_info()`), you can call it as: > > assert(verify_frame_info(), "unexpected frame info"); Thanks for the suggestion. I'd like to keep it the way it is though, so that the assert message contains the `has_last_frame` & `java_call_counter` values. (this was one of the reason I did this refactor as well, since the assert I was hitting out of those 3 didn't contain that info). ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From jvernee at openjdk.java.net Tue Jul 13 15:16:26 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 13 Jul 2021 15:16:26 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2] In-Reply-To: References: Message-ID: > This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title. > > Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread. > > The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks. > > FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob. > > Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Assert frame is correct type in frame_data_for_frame ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/149/files - new: https://git.openjdk.java.net/jdk17/pull/149/files/c90416f5..211bf316 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=149&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=149&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/149.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/149/head:pull/149 PR: https://git.openjdk.java.net/jdk17/pull/149 From xliu at openjdk.java.net Tue Jul 13 16:30:17 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 13 Jul 2021 16:30:17 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v6] In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 11:25:17 GMT, David Holmes wrote: >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace counting semaphaore with os::PlatformMonitor. > > src/hotspot/share/logging/logAsyncWriter.hpp line 141: > >> 139: Semaphore _lock; >> 140: Semaphore _flush_sem; >> 141: os::PlatformMonitor _cv; > > No this isn't what you need. The _lock is the PlatformMonitor. You lock/unlock in AsyncLogLocker for the critical regions, and then use the wait/notify operations for the coordination. you mean I should use os::PlatformMonitor _lock as a combination of mutux and cv, right? ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From vlivanov at openjdk.java.net Tue Jul 13 17:09:12 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 13 Jul 2021 17:09:12 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2] In-Reply-To: References: <-CKmdxtDz9PebGwjDU6XEUMukYMC9CKmW2rhm6xZKWM=.8a88e29e-7b17-4647-9848-7a5bd2927fef@github.com> Message-ID: On Tue, 13 Jul 2021 14:59:07 GMT, Jorn Vernee wrote: >> src/hotspot/share/runtime/thread.hpp line 1128: >> >>> 1126: >>> 1127: private: >>> 1128: DEBUG_ONLY(void verify_frame_info();) >> >> If you declare `verify_frame_info` as returning a `bool` (and just put a `return true;` at the end of `JavaThread::verify_frame_info()`), you can call it as: >> >> assert(verify_frame_info(), "unexpected frame info"); > > Thanks for the suggestion. I'd like to keep it the way it is though, so that the assert message contains the `has_last_frame` & `java_call_counter` values. (this was one of the reason I did this refactor as well, since the assert I was hitting out of those 3 didn't contain that info). You can keep the assert inside `verify_frame_info()` which dumps additional data. (Yes, it's a bit confusing: assert inside an assert :-) ) ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From vlivanov at openjdk.java.net Tue Jul 13 17:09:12 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 13 Jul 2021 17:09:12 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2] In-Reply-To: References: <-CKmdxtDz9PebGwjDU6XEUMukYMC9CKmW2rhm6xZKWM=.8a88e29e-7b17-4647-9848-7a5bd2927fef@github.com> Message-ID: On Tue, 13 Jul 2021 17:05:25 GMT, Vladimir Ivanov wrote: >> Thanks for the suggestion. I'd like to keep it the way it is though, so that the assert message contains the `has_last_frame` & `java_call_counter` values. (this was one of the reason I did this refactor as well, since the assert I was hitting out of those 3 didn't contain that info). > > You can keep the assert inside `verify_frame_info()` which dumps additional data. (Yes, it's a bit confusing: assert inside an assert :-) ) FTR I'm fine with it either way. ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From xliu at openjdk.java.net Tue Jul 13 19:08:47 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 13 Jul 2021 19:08:47 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v7] In-Reply-To: References: Message-ID: > This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. > Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration > only decrements _sem 1 but dequeues N messages. If logging threads keep preempting > async logging thread, it may cause the value of _sem accumulates until overflow! > > The patch corrects the value of _sem after write(). n messages are dequeued/processed. > We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration > decrements n instead of 1. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Replace counting semaphore with os::PlatformMontor. Second attempt. This patch also removed semaphore-based lock because PlatformMonitor can also be used as a Mutex lock. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/216/files - new: https://git.openjdk.java.net/jdk17/pull/216/files/7ac1c26c..0816eb2d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=216&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=216&range=05-06 Stats: 11 lines in 2 files changed: 0 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jdk17/pull/216.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/216/head:pull/216 PR: https://git.openjdk.java.net/jdk17/pull/216 From xliu at openjdk.java.net Tue Jul 13 22:11:15 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 13 Jul 2021 22:11:15 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v3] In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 02:35:12 GMT, David Holmes wrote: >> Xin Liu has updated the pull request incrementally with three additional commits since the last revision: >> >> - Ignore sem_post failure when _sem of AsyncLogWriter is overflown. >> - Revert "8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX" >> >> This reverts commit 269a1580990fa955c1f9d37ce1d04a6349959992. >> - Revert "Fix build issue on Windows and simplify the loop." >> >> This reverts commit e385f42fa4e03510242039518281077e3c9897cf. > > I ran a test on Linux, Windows and OSX. As expected Linux gives EOVERFLOW. OSX the test just times out without error. > > On Windows we get error 298: > > ERROR_TOO_MANY_POSTS > 298 (0x12A) > Too many posts were made to a semaphore. > > so I think we should check for that and ignore it if ignoring overflow. > > Thanks, > David hi, @dholmes-ora @pchilano, Thank you for letting me know os::PlatformMonitor. I used to think Monitor is a higher-level synchronization construct than Semaphore. it turns out that os::PlatformMonitor is as low-level as semaphore. Lesson learned. Could you take a look at this change and see if I use it correctly? thanks, --lx ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From dholmes at openjdk.java.net Tue Jul 13 23:51:16 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 13 Jul 2021 23:51:16 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v7] In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 19:08:47 GMT, Xin Liu wrote: >> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >> async logging thread, it may cause the value of _sem accumulates until overflow! >> >> The patch corrects the value of _sem after write(). n messages are dequeued/processed. >> We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration >> decrements n instead of 1. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Replace counting semaphore with os::PlatformMontor. > > Second attempt. This patch also removed semaphore-based lock because > PlatformMonitor can also be used as a Mutex lock. Hi Xin, This looks good. I'll run it through our testing. I'll also try to get @pchilano to review it. Thanks, David src/hotspot/share/logging/logAsyncWriter.hpp line 139: > 137: static AsyncLogWriter* _instance; > 138: Semaphore _flush_sem; > 139: os::PlatformMonitor _lock; Please add a comment before this: // Can't use a Monitor here as we need a low-level API that can be used // late in a thread's termination process. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/216 From dholmes at openjdk.java.net Wed Jul 14 01:01:15 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Jul 2021 01:01:15 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2] In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 15:16:26 GMT, Jorn Vernee wrote: >> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title. >> >> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread. >> >> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks. >> >> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob. >> >> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Assert frame is correct type in frame_data_for_frame Hi Jorn, I can't comment on all the details here - especially in the x86_64 upcall handler code. The mapping to JavaCallWrapper seems reasonable but there are a few differences that I'm now assuming stem from the fact upcalls start _thread_in_native while JCW starts from _thread_in_vm? Some minor comments and queries below (mostly issues with existing code that you copied). Thanks, David src/hotspot/share/prims/universalUpcallHandler.cpp line 76: > 74: > 75: // modelled after JavaCallWrapper::JavaCallWrapper > 76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) { This should return JavaThread not Thread. src/hotspot/share/prims/universalUpcallHandler.cpp line 77: > 75: // modelled after JavaCallWrapper::JavaCallWrapper > 76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) { > 77: JavaThread* thread = maybe_attach_and_get_thread(&context->should_detach)->as_Java_thread(); Nit: if `maybe_attach_and_get_thread` has to return a JavaThread it should be typed to return a JavaThread. src/hotspot/share/prims/universalUpcallHandler.cpp line 86: > 84: context->new_handles = JNIHandleBlock::allocate_block(thread); > 85: > 86: // After this, we are official in Java Code. This needs to be done before we change any of the thread local typo: s/official/officially/ (I see this was copied from Javacalls) src/hotspot/share/prims/universalUpcallHandler.cpp line 92: > 90: // Make sure that we handle asynchronous stops and suspends _before_ we clear all thread state > 91: // in OptimizedEntryBlob::FrameData. This way, we can decide if we need to do any pd actions > 92: // to prepare for stop/suspend (flush register windows on sparcs, cache sp, or other state). No sparcs any more (again I see this was copied from Javacalls) src/hotspot/share/prims/universalUpcallHandler.cpp line 114: > 112: thread->set_active_handles(context->new_handles); // install new handle block and reset Java frame linkage > 113: > 114: assert (thread->thread_state() != _thread_in_native, "cannot set native pc to NULL"); You transitioned to _thread_in_Java above so how can you possibly have changed state again ?? (okay again copied from javaCalls ...) src/hotspot/share/prims/universalUpcallHandler.cpp line 117: > 115: > 116: // clear any pending exception in thread (native calls start with no exception pending) > 117: if(clear_pending_exception) { Nit: space after 'if' src/hotspot/share/prims/universalUpcallHandler.cpp line 121: > 119: } > 120: > 121: MACOS_AARCH64_ONLY(thread->enable_wx(WXExec)); Not clear why this is needed? JavaCallWrapper doesn't use it. src/hotspot/share/prims/universalUpcallHandler.cpp line 146: > 144: // Do this after the transition because this allows us to put an assert > 145: // the Java->native transition which checks to see that stack is not walkable > 146: // on sparc/ia64 which will catch violations of the reseting of last_Java_frame Again archaic comment copied across :) src/hotspot/share/runtime/thread.cpp line 1972: > 1970: (has_last_Java_frame() && java_call_counter() > 0), > 1971: "unexpected frame info: has_last_frame=%d, java_call_counter=%d", > 1972: has_last_Java_frame(), java_call_counter()); I see this was relocated code, but as has_last_java_frame() returns bool, it shouldn't be treated as an int without a cast (or better use %s and report true or false). ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From dholmes at openjdk.java.net Wed Jul 14 01:01:16 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Jul 2021 01:01:16 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2] In-Reply-To: References: Message-ID: On Fri, 25 Jun 2021 21:04:27 GMT, Jorn Vernee wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Assert frame is correct type in frame_data_for_frame > > src/hotspot/share/runtime/safepoint.cpp line 931: > >> 929: // See if return type is an oop. >> 930: bool return_oop = nm->method()->is_returning_oop(); >> 931: HandleMark hm(self); > > I was seeing an `assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark` when the existing code allocates the Handle for `return_value` in the code down below. It seems to be a simple case of a missing handle mark, so I've added it here. (looking at the stack trace in the error log, the caller frame is native code, so I don't think we can expect the caller to have a HandleMark). How does native code reach a safepoint polling point? ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From pchilanomate at openjdk.java.net Wed Jul 14 01:21:17 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 14 Jul 2021 01:21:17 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v7] In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 19:08:47 GMT, Xin Liu wrote: >> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >> async logging thread, it may cause the value of _sem accumulates until overflow! >> >> We decide to ditch counting semaphore. os::PlatformMonitor can be used as low-level >> combination of Mutex/CondVar. It may work if we simply ignore Semaphore::signal failure >> due to value overflow, but we have to pollute Semaphore interface. Also it seems that MacOS >> semaphore which is non-posix doesn't fail in this case. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Replace counting semaphore with os::PlatformMontor. > > Second attempt. This patch also removed semaphore-based lock because > PlatformMonitor can also be used as a Mutex lock. Hi Xin, Looks good to me too. The only small suggestion is that you could do the pop_all() and _stats.iterate when coming out of wait() since you are already holding the monitor, and then pass the logs to write(). Either way is fine though. Thanks, Patricio ------------- Marked as reviewed by pchilanomate (Committer). PR: https://git.openjdk.java.net/jdk17/pull/216 From xliu at openjdk.java.net Wed Jul 14 01:32:10 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 14 Jul 2021 01:32:10 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v7] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 01:18:17 GMT, Patricio Chilano Mateo wrote: > The only small suggestion is that you could do the pop_all() and _stats.iterate when coming out of wait() since you are already holding the monitor, and then pass the logs to write(). Either way is fine though. Thanks for reviewing. I see what you mean. I take a note on that. yes, we may gain something if we merge two critical areas. I will take it as a follow-up. ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From xliu at openjdk.java.net Wed Jul 14 01:38:40 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 14 Jul 2021 01:38:40 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v8] In-Reply-To: References: Message-ID: > This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. > Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration > only decrements _sem 1 but dequeues N messages. If logging threads keep preempting > async logging thread, it may cause the value of _sem accumulates until overflow! > > We decide to ditch counting semaphore. os::PlatformMonitor can be used as low-level > combination of Mutex/CondVar. It may work if we simply ignore Semaphore::signal failure > due to value overflow, but we have to pollute Semaphore interface. Also it seems that MacOS > semaphore which is non-posix doesn't fail in this case. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Add a comment to explain why we choose os::PlatformMonitor over Semaphore. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/216/files - new: https://git.openjdk.java.net/jdk17/pull/216/files/0816eb2d..f6a9fd58 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=216&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=216&range=06-07 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/216.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/216/head:pull/216 PR: https://git.openjdk.java.net/jdk17/pull/216 From xliu at openjdk.java.net Wed Jul 14 01:38:41 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 14 Jul 2021 01:38:41 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v7] In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 23:47:17 GMT, David Holmes wrote: >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace counting semaphore with os::PlatformMontor. >> >> Second attempt. This patch also removed semaphore-based lock because >> PlatformMonitor can also be used as a Mutex lock. > > src/hotspot/share/logging/logAsyncWriter.hpp line 139: > >> 137: static AsyncLogWriter* _instance; >> 138: Semaphore _flush_sem; >> 139: os::PlatformMonitor _lock; > > Please add a comment before this: > > // Can't use a Monitor here as we need a low-level API that can be used > // late in a thread's termination process. done. ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From david.holmes at oracle.com Wed Jul 14 01:40:57 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Jul 2021 11:40:57 +1000 Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v7] In-Reply-To: References: Message-ID: <3ce45c00-a25d-3bf5-2b53-b679e0341f59@oracle.com> On 14/07/2021 11:32 am, Xin Liu wrote: > On Wed, 14 Jul 2021 01:18:17 GMT, Patricio Chilano Mateo wrote: > >> The only small suggestion is that you could do the pop_all() and _stats.iterate when coming out of wait() since you are already holding the monitor, and then pass the logs to write(). Either way is fine though. > > Thanks for reviewing. I see what you mean. I take a note on that. yes, we may gain something if we merge two critical areas. > I will take it as a follow-up. I think it is cleaner as-is. Testing tiers 1-3 passed with no problems, so I think this can be integrated now. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk17/pull/216 > From xliu at openjdk.java.net Wed Jul 14 01:43:13 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 14 Jul 2021 01:43:13 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v8] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 01:38:40 GMT, Xin Liu wrote: >> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >> async logging thread, it may cause the value of _sem accumulates until overflow! >> >> We decide to ditch counting semaphore. os::PlatformMonitor can be used as low-level >> combination of Mutex/CondVar. It may work if we simply ignore Semaphore::signal failure >> due to value overflow, but we have to pollute Semaphore interface. Also it seems that MacOS >> semaphore which is non-posix doesn't fail in this case. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Add a comment to explain why we choose os::PlatformMonitor over Semaphore. Hi, Reviewers, Thanks a lot. I append a comment to explain why we choose PlatformMonitor over Semaphore. Meanwhile, I defer performance-wise change. Please let me know the results of test. I hope we can make it to jdk17 **safely** before the window is close. ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From dholmes at openjdk.java.net Wed Jul 14 01:47:20 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Jul 2021 01:47:20 GMT Subject: [jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v8] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 01:38:40 GMT, Xin Liu wrote: >> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. >> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration >> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting >> async logging thread, it may cause the value of _sem accumulates until overflow! >> >> We decide to ditch counting semaphore. os::PlatformMonitor can be used as low-level >> combination of Mutex/CondVar. It may work if we simply ignore Semaphore::signal failure >> due to value overflow, but we have to pollute Semaphore interface. Also it seems that MacOS >> semaphore which is non-posix doesn't fail in this case. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Add a comment to explain why we choose os::PlatformMonitor over Semaphore. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From xliu at openjdk.java.net Wed Jul 14 01:47:21 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 14 Jul 2021 01:47:21 GMT Subject: [jdk17] Integrated: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 06:43:24 GMT, Xin Liu wrote: > This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW. > Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration > only decrements _sem 1 but dequeues N messages. If logging threads keep preempting > async logging thread, it may cause the value of _sem accumulates until overflow! > > We decide to ditch counting semaphore. os::PlatformMonitor can be used as low-level > combination of Mutex/CondVar. It may work if we simply ignore Semaphore::signal failure > due to value overflow, but we have to pollute Semaphore interface. Also it seems that MacOS > semaphore which is non-posix doesn't fail in this case. This pull request has now been integrated. Changeset: 67273ae6 Author: Xin Liu URL: https://git.openjdk.java.net/jdk17/commit/67273ae63c3dbebccf124929c13a363dea05a0da Stats: 25 lines in 2 files changed: 11 ins; 5 del; 9 mod 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX Reviewed-by: dholmes, pchilanomate ------------- PR: https://git.openjdk.java.net/jdk17/pull/216 From lzang at openjdk.java.net Wed Jul 14 02:27:14 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 14 Jul 2021 02:27:14 GMT Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 08:21:21 GMT, Lin Zang wrote: >> 8269909: getStack method in hprof.parser.Reader should use try-with-resource > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into try > - 8269909: getStack method in hprof.parser.Reader should use try-with-resource Hi David, Thanks for pointing it out, I found there are similar codes in other place in this file that need to be revised. will update the PR soon. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/4717 From lzang at openjdk.java.net Wed Jul 14 02:38:38 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 14 Jul 2021 02:38:38 GMT Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource [v3] In-Reply-To: References: Message-ID: > 8269909: getStack method in hprof.parser.Reader should use try-with-resource Lin Zang has updated the pull request incrementally with one additional commit since the last revision: revise code to handle the closing of embeded streams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4717/files - new: https://git.openjdk.java.net/jdk/pull/4717/files/161ab172..36a30d84 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4717&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4717&range=01-02 Stats: 14 lines in 1 file changed: 4 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4717.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4717/head:pull/4717 PR: https://git.openjdk.java.net/jdk/pull/4717 From iklam at openjdk.java.net Wed Jul 14 02:45:25 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 14 Jul 2021 02:45:25 GMT Subject: RFR: 8270333: -XX:+VerifyStringTableAtExit should not do linear search Message-ID: The implementation of `-XX:+VerifyStringTableAtExit` used a linear search to check for duplicated strings in the interned string table. This would be excessively slow if there were more than a few thousand strings. This PR uses a hashtable so we can avoid doing a linear search. The table is sized such that each bucket has 8 items on average. Since this code is executed only for verification, I added a new `java_lang_String::hash_code_noupdate(oop)` function, so we can avoid causing side effects. ------------- Commit messages: - 8270333: -XX:+VerifyStringTableAtExit should not do linear search Changes: https://git.openjdk.java.net/jdk/pull/4772/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4772&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270333 Stats: 47 lines in 3 files changed: 26 ins; 8 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/4772.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4772/head:pull/4772 PR: https://git.openjdk.java.net/jdk/pull/4772 From cjplummer at openjdk.java.net Wed Jul 14 03:51:15 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 14 Jul 2021 03:51:15 GMT Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 02:38:38 GMT, Lin Zang wrote: >> 8269909: getStack method in hprof.parser.Reader should use try-with-resource > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > revise code to handle the closing of embeded streams Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4717 From dholmes at openjdk.java.net Wed Jul 14 04:25:13 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Jul 2021 04:25:13 GMT Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 02:38:38 GMT, Lin Zang wrote: >> 8269909: getStack method in hprof.parser.Reader should use try-with-resource > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > revise code to handle the closing of embeded streams Looks complete now - thanks. Please fix alignment issues flagged before integrating. Thanks, David test/lib/jdk/test/lib/hprof/parser/Reader.java line 90: > 88: try (FileInputStream fis = new FileInputStream(heapFile); > 89: BufferedInputStream bis = new BufferedInputStream(fis); > 90: PositionDataInputStream in = new PositionDataInputStream(bis)) { Please fix indentation so that the type names align. test/lib/jdk/test/lib/hprof/parser/Reader.java line 100: > 98: in.close(); > 99: try (BufferedInputStream bis2 = new BufferedInputStream(access.asStream(0)); > 100: PositionDataInputStream in2 = new PositionDataInputStream(bis2)) { Please fix indentation so that the type names align. Also minor nit: the '2' suffix is not needed for any of the variables now as they are scoped to the try-block. test/lib/jdk/test/lib/hprof/parser/Reader.java line 142: > 140: try (FileInputStream fis= new FileInputStream(heapFile); > 141: BufferedInputStream bis = new BufferedInputStream(fis); > 142: PositionDataInputStream in = new PositionDataInputStream(bis)) { Please fix indentation so that the type names align. test/lib/jdk/test/lib/hprof/parser/Reader.java line 158: > 156: try (FileInputStream fis2 = new FileInputStream(heapFile); > 157: GZIPInputStream gis = new GZIPInputStream(fis2); > 158: FileOutputStream fos = new FileOutputStream(out)) { Please fix indentation so that the type names align. test/lib/jdk/test/lib/hprof/parser/Reader.java line 171: > 169: try (FileInputStream fis3 = new FileInputStream(out); > 170: BufferedInputStream bis2 = new BufferedInputStream(fis3); > 171: PositionDataInputStream in2 = new PositionDataInputStream(bis2)) { Please fix indentation so that the type names align. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4717 From stuefe at openjdk.java.net Wed Jul 14 04:38:18 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 14 Jul 2021 04:38:18 GMT Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v4] In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 04:57:27 GMT, Thomas Stuefe wrote: >> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process. >> >> >> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not. >> >> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes. >> >> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System. >> >> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day. >> >> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes: >> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory >> - as a stop gap measure it allows to release pressure from a high footprint scenario. >> >> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT. >> >> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd. >> >> CSR for this command: https://bugs.openjdk.java.net/browse/JDK-8269345 >> >> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later. >> >> ========= >> >> This patch: >> >> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms. >> - includes a (rather basic) test >> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space) >> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information. >> >> ========= >> >> Example: >> >> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc: >> >> >> >> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident >> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K) >> ^^^^^^^^ >> >> >> We execute the new trim command via jcmd: >> >> >> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap >> 18770: >> Attempting trim... >> Done. >> Virtual size before: 28849744k, after: 28849724k, (-20k) >> RSS before: 8685896k, after: 920740k, (-7765156k) <<<< >> Swap before: 0k, after: 0k, (0k) >> >> >> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory: >> >> >> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident >> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K) >> ^^^^^^^ >> >> >> When the VM is started with -Xlog:os, this is also logged: >> >> >> [139,068s][info][os] malloc_trim: >> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k) >> RSS before: 8685896k, after: 920740k, (-7765156k) >> Swap before: 0k, after: 0k, (0k) > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Rename command (see CSR) > - Merge > - Volker feedback > - Merge > - Feedback Severin; renamed query function > - start Gentle ping. Need a second review. @dholmes-ora ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4510 From lzang at openjdk.java.net Wed Jul 14 04:48:41 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 14 Jul 2021 04:48:41 GMT Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource [v4] In-Reply-To: References: Message-ID: > 8269909: getStack method in hprof.parser.Reader should use try-with-resource Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - fix indentation issue - Merge branch 'master' into try - revise code to handle the closing of embeded streams - Merge branch 'master' into try - 8269909: getStack method in hprof.parser.Reader should use try-with-resource ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4717/files - new: https://git.openjdk.java.net/jdk/pull/4717/files/36a30d84..ac2675f2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4717&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4717&range=02-03 Stats: 5179 lines in 279 files changed: 2861 ins; 1357 del; 961 mod Patch: https://git.openjdk.java.net/jdk/pull/4717.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4717/head:pull/4717 PR: https://git.openjdk.java.net/jdk/pull/4717 From lzang at openjdk.java.net Wed Jul 14 04:48:46 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 14 Jul 2021 04:48:46 GMT Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource [v3] In-Reply-To: References: Message-ID: <3iQxjLw4JuH6GonjG1TRTrXCJFQpuKPE3AR5wnRsjCU=.b0ffc58c-c7e8-42b0-8327-17ebb8102c0b@github.com> On Wed, 14 Jul 2021 04:19:56 GMT, David Holmes wrote: >> Lin Zang has updated the pull request incrementally with one additional commit since the last revision: >> >> revise code to handle the closing of embeded streams > > test/lib/jdk/test/lib/hprof/parser/Reader.java line 100: > >> 98: in.close(); >> 99: try (BufferedInputStream bis2 = new BufferedInputStream(access.asStream(0)); >> 100: PositionDataInputStream in2 = new PositionDataInputStream(bis2)) { > > Please fix indentation so that the type names align. > > Also minor nit: the '2' suffix is not needed for any of the variables now as they are scoped to the try-block. Hi David, Removing the `2` suffix here makes build error, as they are conflict with the outer try() at line 88. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4717 From david.holmes at oracle.com Wed Jul 14 05:04:02 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Jul 2021 15:04:02 +1000 Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource [v3] In-Reply-To: <3iQxjLw4JuH6GonjG1TRTrXCJFQpuKPE3AR5wnRsjCU=.b0ffc58c-c7e8-42b0-8327-17ebb8102c0b@github.com> References: <3iQxjLw4JuH6GonjG1TRTrXCJFQpuKPE3AR5wnRsjCU=.b0ffc58c-c7e8-42b0-8327-17ebb8102c0b@github.com> Message-ID: <01d30669-04a7-90fc-a303-cba55a97dbc1@oracle.com> On 14/07/2021 2:48 pm, Lin Zang wrote: > On Wed, 14 Jul 2021 04:19:56 GMT, David Holmes wrote: > >>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision: >>> >>> revise code to handle the closing of embeded streams >> >> test/lib/jdk/test/lib/hprof/parser/Reader.java line 100: >> >>> 98: in.close(); >>> 99: try (BufferedInputStream bis2 = new BufferedInputStream(access.asStream(0)); >>> 100: PositionDataInputStream in2 = new PositionDataInputStream(bis2)) { >> >> Please fix indentation so that the type names align. >> >> Also minor nit: the '2' suffix is not needed for any of the variables now as they are scoped to the try-block. > > Hi David, > Removing the `2` suffix here makes build error, as they are conflict with the outer try() at line 88. Thanks. Ah okay. I didn't spot the nesting from the diff view - sorry. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4717 > From dholmes at openjdk.java.net Wed Jul 14 05:05:24 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Jul 2021 05:05:24 GMT Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v4] In-Reply-To: References: Message-ID: <7XKHDRZiy9DSZzDPUQ4Zde87tnclj7U4bS69Y38TPGI=.f516576d-a7b3-4475-a44b-69f084271166@github.com> On Fri, 9 Jul 2021 04:57:27 GMT, Thomas Stuefe wrote: >> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process. >> >> >> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not. >> >> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes. >> >> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System. >> >> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day. >> >> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes: >> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory >> - as a stop gap measure it allows to release pressure from a high footprint scenario. >> >> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT. >> >> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd. >> >> CSR for this command: https://bugs.openjdk.java.net/browse/JDK-8269345 >> >> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later. >> >> ========= >> >> This patch: >> >> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms. >> - includes a (rather basic) test >> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space) >> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information. >> >> ========= >> >> Example: >> >> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc: >> >> >> >> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident >> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K) >> ^^^^^^^^ >> >> >> We execute the new trim command via jcmd: >> >> >> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap >> 18770: >> Attempting trim... >> Done. >> Virtual size before: 28849744k, after: 28849724k, (-20k) >> RSS before: 8685896k, after: 920740k, (-7765156k) <<<< >> Swap before: 0k, after: 0k, (0k) >> >> >> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory: >> >> >> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident >> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K) >> ^^^^^^^ >> >> >> When the VM is started with -Xlog:os, this is also logged: >> >> >> [139,068s][info][os] malloc_trim: >> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k) >> RSS before: 8685896k, after: 920740k, (-7765156k) >> Swap before: 0k, after: 0k, (0k) > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Rename command (see CSR) > - Merge > - Volker feedback > - Merge > - Feedback Severin; renamed query function > - start Hi Thomas, This seems okay to me. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4510 From dholmes at openjdk.java.net Wed Jul 14 05:08:18 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Jul 2021 05:08:18 GMT Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource [v4] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 04:48:41 GMT, Lin Zang wrote: >> 8269909: getStack method in hprof.parser.Reader should use try-with-resource > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - fix indentation issue > - Merge branch 'master' into try > - revise code to handle the closing of embeded streams > - Merge branch 'master' into try > - 8269909: getStack method in hprof.parser.Reader should use try-with-resource The indentation of the first two try-with-resources blocks is still wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/4717 From dholmes at openjdk.java.net Wed Jul 14 05:17:12 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Jul 2021 05:17:12 GMT Subject: RFR: 8270333: -XX:+VerifyStringTableAtExit should not do linear search In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 02:34:19 GMT, Ioi Lam wrote: > The implementation of `-XX:+VerifyStringTableAtExit` used a linear search to check for duplicated strings in the interned string table. This would be excessively slow if there were more than a few thousand strings. > > This PR uses a hashtable so we can avoid doing a linear search. The table is sized such that each bucket has 8 items on average. > > Since this code is executed only for verification, I added a new `java_lang_String::hash_code_noupdate(oop)` function, so we can avoid causing side effects. Changes seem fine, but I don't like your use of templates here. Thanks, David src/hotspot/share/classfile/javaClasses.cpp line 506: > 504: > 505: template > 506: unsigned int java_lang_String::hash_code_impl(oop java_string) { This looks like a really weird way to pass a parameter! Why do we want a template here? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4772 From iklam at openjdk.java.net Wed Jul 14 05:37:55 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 14 Jul 2021 05:37:55 GMT Subject: RFR: 8270333: -XX:+VerifyStringTableAtExit should not do linear search [v2] In-Reply-To: References: Message-ID: > The implementation of `-XX:+VerifyStringTableAtExit` used a linear search to check for duplicated strings in the interned string table. This would be excessively slow if there were more than a few thousand strings. > > This PR uses a hashtable so we can avoid doing a linear search. The table is sized such that each bucket has 8 items on average. > > Since this code is executed only for verification, I added a new `java_lang_String::hash_code_noupdate(oop)` function, so we can avoid causing side effects. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: replace template with inline function ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4772/files - new: https://git.openjdk.java.net/jdk/pull/4772/files/2285cf94..cf913b1c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4772&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4772&range=00-01 Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4772.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4772/head:pull/4772 PR: https://git.openjdk.java.net/jdk/pull/4772 From iklam at openjdk.java.net Wed Jul 14 05:37:57 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 14 Jul 2021 05:37:57 GMT Subject: RFR: 8270333: -XX:+VerifyStringTableAtExit should not do linear search [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 05:09:41 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> replace template with inline function > > src/hotspot/share/classfile/javaClasses.cpp line 506: > >> 504: >> 505: template >> 506: unsigned int java_lang_String::hash_code_impl(oop java_string) { > > This looks like a really weird way to pass a parameter! Why do we want a template here? Hi David, thanks for the review. I replaced the template function with an inline function. ------------- PR: https://git.openjdk.java.net/jdk/pull/4772 From iklam at openjdk.java.net Wed Jul 14 06:02:35 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 14 Jul 2021 06:02:35 GMT Subject: RFR: 8270333: -XX:+VerifyStringTableAtExit should not do linear search [v3] In-Reply-To: References: Message-ID: > The implementation of `-XX:+VerifyStringTableAtExit` used a linear search to check for duplicated strings in the interned string table. This would be excessively slow if there were more than a few thousand strings. > > This PR uses a hashtable so we can avoid doing a linear search. The table is sized such that each bucket has 8 items on average. > > Since this code is executed only for verification, I added a new `java_lang_String::hash_code_noupdate(oop)` function, so we can avoid causing side effects. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed build and make sure table size is not zero ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4772/files - new: https://git.openjdk.java.net/jdk/pull/4772/files/cf913b1c..66c4d4ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4772&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4772&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4772.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4772/head:pull/4772 PR: https://git.openjdk.java.net/jdk/pull/4772 From dholmes at openjdk.java.net Wed Jul 14 06:36:11 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Jul 2021 06:36:11 GMT Subject: RFR: 8270333: -XX:+VerifyStringTableAtExit should not do linear search [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 06:02:35 GMT, Ioi Lam wrote: >> The implementation of `-XX:+VerifyStringTableAtExit` used a linear search to check for duplicated strings in the interned string table. This would be excessively slow if there were more than a few thousand strings. >> >> This PR uses a hashtable so we can avoid doing a linear search. The table is sized such that each bucket has 8 items on average. >> >> Since this code is executed only for verification, I added a new `java_lang_String::hash_code_noupdate(oop)` function, so we can avoid causing side effects. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed build and make sure table size is not zero Okay ... I'm not sure why you want the code to be duplicated though? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4772 From iklam at openjdk.java.net Wed Jul 14 06:46:09 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 14 Jul 2021 06:46:09 GMT Subject: RFR: 8270333: -XX:+VerifyStringTableAtExit should not do linear search [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 06:32:58 GMT, David Holmes wrote: > Okay ... I'm not sure why you want the code to be duplicated though? I could add a new `bool update` parameter to `java_lang_String::hash_code(oop java_string)`, but I worry about performance impacts. It probably doesn't matter, but I just don't want to deal with any potential performance issues when changing code used only for debugging. ------------- PR: https://git.openjdk.java.net/jdk/pull/4772 From shade at openjdk.java.net Wed Jul 14 08:17:16 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 14 Jul 2021 08:17:16 GMT Subject: RFR: 8270155: ARM32: Improve register dump in hs_err In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 12:12:32 GMT, Aleksey Shipilev wrote: > Noticed that ARM32 hs_errs are formatted weirdly, there is a newline after register value, and it prints the register value twice. `print_location` already prints the value and does the CR for us, so we should just delegate there. > > Excerpt tefore: > > > Register to memory mapping: > > r0 = 0xb6b54430 > 0xb6b54430: in /jdk/lib/server/libjvm.so at 0xb5ceb000 > > r1 = 0x00000501 > 0x00000501 is an unknown value > > r2 = 0xb6b54ef8 > 0xb6b54ef8: in /jdk/lib/server/libjvm.so at 0xb5ceb000 > > r3 = 0xb6b54eb4 > 0xb6b54eb4: in /jdk/lib/server/libjvm.so at 0xb5ceb000 > > r4 = 0xb6f54000 > 0xb6f54000 points into unknown readable memory: 0x00000058 | 58 00 00 00 > > > Excerpt after: > > > Register to memory mapping: > > r0 = 0xb6b3fa70: in /home/pi/shipilev-jdk/build/linux-arm-server-fastdebug/images/jdk/lib/server/libjvm.so at 0xb574a000 > r1 = 0x00000501 is an unknown value > r2 = 0xb6b40544: in /home/pi/shipilev-jdk/build/linux-arm-server-fastdebug/images/jdk/lib/server/libjvm.so at 0xb574a000 > r3 = 0xb6b40500: in /home/pi/shipilev-jdk/build/linux-arm-server-fastdebug/images/jdk/lib/server/libjvm.so at 0xb574a000 > r4 = 0x70d6a83c points into unknown readable memory: 0xb6ce8b64 | 64 8b ce b6 > > > Additional testing: > - [x] Eyeballing ARM32 crash logs Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4739 From shade at openjdk.java.net Wed Jul 14 08:17:16 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 14 Jul 2021 08:17:16 GMT Subject: Integrated: 8270155: ARM32: Improve register dump in hs_err In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 12:12:32 GMT, Aleksey Shipilev wrote: > Noticed that ARM32 hs_errs are formatted weirdly, there is a newline after register value, and it prints the register value twice. `print_location` already prints the value and does the CR for us, so we should just delegate there. > > Excerpt tefore: > > > Register to memory mapping: > > r0 = 0xb6b54430 > 0xb6b54430: in /jdk/lib/server/libjvm.so at 0xb5ceb000 > > r1 = 0x00000501 > 0x00000501 is an unknown value > > r2 = 0xb6b54ef8 > 0xb6b54ef8: in /jdk/lib/server/libjvm.so at 0xb5ceb000 > > r3 = 0xb6b54eb4 > 0xb6b54eb4: in /jdk/lib/server/libjvm.so at 0xb5ceb000 > > r4 = 0xb6f54000 > 0xb6f54000 points into unknown readable memory: 0x00000058 | 58 00 00 00 > > > Excerpt after: > > > Register to memory mapping: > > r0 = 0xb6b3fa70: in /home/pi/shipilev-jdk/build/linux-arm-server-fastdebug/images/jdk/lib/server/libjvm.so at 0xb574a000 > r1 = 0x00000501 is an unknown value > r2 = 0xb6b40544: in /home/pi/shipilev-jdk/build/linux-arm-server-fastdebug/images/jdk/lib/server/libjvm.so at 0xb574a000 > r3 = 0xb6b40500: in /home/pi/shipilev-jdk/build/linux-arm-server-fastdebug/images/jdk/lib/server/libjvm.so at 0xb574a000 > r4 = 0x70d6a83c points into unknown readable memory: 0xb6ce8b64 | 64 8b ce b6 > > > Additional testing: > - [x] Eyeballing ARM32 crash logs This pull request has now been integrated. Changeset: 589a1d53 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/589a1d53df0f53c064fda8a2ac491e0a536ea487 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8270155: ARM32: Improve register dump in hs_err Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/4739 From stuefe at openjdk.java.net Wed Jul 14 09:46:12 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 14 Jul 2021 09:46:12 GMT Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v4] In-Reply-To: <7XKHDRZiy9DSZzDPUQ4Zde87tnclj7U4bS69Y38TPGI=.f516576d-a7b3-4475-a44b-69f084271166@github.com> References: <7XKHDRZiy9DSZzDPUQ4Zde87tnclj7U4bS69Y38TPGI=.f516576d-a7b3-4475-a44b-69f084271166@github.com> Message-ID: On Wed, 14 Jul 2021 05:01:49 GMT, David Holmes wrote: > Hi Thomas, > > This seems okay to me. > > Thanks, > David Thank you David and Volker! ------------- PR: https://git.openjdk.java.net/jdk/pull/4510 From stuefe at openjdk.java.net Wed Jul 14 09:55:48 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 14 Jul 2021 09:55:48 GMT Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v5] In-Reply-To: References: Message-ID: <8POs-ek7fxeLPey8_s8PwkBPEQBAgJj4ci5JgPY0ChM=.2ec38ba5-e2ef-4324-b4ae-59dfa56a5fc7@github.com> > Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process. > > > The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not. > > This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes. > > The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System. > > This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day. > > Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes: > - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory > - as a stop gap measure it allows to release pressure from a high footprint scenario. > > Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT. > > I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd. > > CSR for this command: https://bugs.openjdk.java.net/browse/JDK-8269345 > > Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later. > > ========= > > This patch: > > - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms. > - includes a (rather basic) test > - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space) > - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information. > > ========= > > Example: > > A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc: > > > > thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident > Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K) > ^^^^^^^^ > > > We execute the new trim command via jcmd: > > > thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap > 18770: > Attempting trim... > Done. > Virtual size before: 28849744k, after: 28849724k, (-20k) > RSS before: 8685896k, after: 920740k, (-7765156k) <<<< > Swap before: 0k, after: 0k, (0k) > > > It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory: > > > thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident > Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K) > ^^^^^^^ > > > When the VM is started with -Xlog:os, this is also logged: > > > [139,068s][info][os] malloc_trim: > [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k) > RSS before: 8685896k, after: 920740k, (-7765156k) > Swap before: 0k, after: 0k, (0k) Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge - Rename command (see CSR) - Merge - Volker feedback - Merge - Feedback Severin; renamed query function - start ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4510/files - new: https://git.openjdk.java.net/jdk/pull/4510/files/c3f055a1..c9e73550 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4510&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4510&range=03-04 Stats: 5173 lines in 278 files changed: 2861 ins; 1357 del; 955 mod Patch: https://git.openjdk.java.net/jdk/pull/4510.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4510/head:pull/4510 PR: https://git.openjdk.java.net/jdk/pull/4510 From github.com+12575901+gbaso at openjdk.java.net Wed Jul 14 12:45:17 2021 From: github.com+12575901+gbaso at openjdk.java.net (Giacomo Baso) Date: Wed, 14 Jul 2021 12:45:17 GMT Subject: RFR: 8260265: UTF-8 by Default In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: On Thu, 8 Jul 2021 21:23:00 GMT, Naoto Sato wrote: > This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. > > JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 > CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 > Consider an application that creates a java.io.FileWriter with its one-argument constructor and then uses it to write some text to a file. The resulting file will contain a sequence of bytes encoded using the default charset of the JDK running the application. A second application, run on a different machine or by a different user on the same machine, creates a java.io.FileReader with its one-argument constructor and uses it to read the bytes in that file. The resulting text contains a sequence of characters decoded using the default charset of the JDK running the second application. If the default charset differs between the JDK of the first application and the JDK of the second application, then the resulting text may be silently corrupted or incomplete, since these APIs replace erroneous input rather than fail. It's even worse than that, because many OpenSSH installs are configured by default to [forward](https://man.openbsd.org/ssh_config.5#SendEnv) and [accept](https://man.openbsd.org/sshd_config.5#AcceptEnv) the user locale (see e.g. for [RHEL 7](https://access.redhat.com/solutions/974273)). So a single application, on a single remote machine, can be unknowingly started by a single user with different locales, and therefore different encodings, depending on how the user connected to the remote machine. For example, on Windows connecting via powershell results in `LANG=en_US.UTF-8`, while using WSL2 results in `LANG=C.UTF-8`. On Java 11 in a RHEL7 machine, `file.encoding` results in `UTF-8` in the first case, but `ANSI_X3.4-1968` in the second, leading to a default charset `ASCII`. Worth mentioning is also that `Charset.forName("default")` is just an alias to `ASCII`, per `sun.nio.cs.StandardCharsets$Aliases`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4733 From sgehwolf at openjdk.java.net Wed Jul 14 13:53:15 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 14 Jul 2021 13:53:15 GMT Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v5] In-Reply-To: <8POs-ek7fxeLPey8_s8PwkBPEQBAgJj4ci5JgPY0ChM=.2ec38ba5-e2ef-4324-b4ae-59dfa56a5fc7@github.com> References: <8POs-ek7fxeLPey8_s8PwkBPEQBAgJj4ci5JgPY0ChM=.2ec38ba5-e2ef-4324-b4ae-59dfa56a5fc7@github.com> Message-ID: On Wed, 14 Jul 2021 09:55:48 GMT, Thomas Stuefe wrote: >> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process. >> >> >> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not. >> >> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes. >> >> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System. >> >> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day. >> >> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes: >> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory >> - as a stop gap measure it allows to release pressure from a high footprint scenario. >> >> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT. >> >> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd. >> >> CSR for this command: https://bugs.openjdk.java.net/browse/JDK-8269345 >> >> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later. >> >> ========= >> >> This patch: >> >> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms. >> - includes a (rather basic) test >> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space) >> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information. >> >> ========= >> >> Example: >> >> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc: >> >> >> >> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident >> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K) >> ^^^^^^^^ >> >> >> We execute the new trim command via jcmd: >> >> >> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap >> 18770: >> Attempting trim... >> Done. >> Virtual size before: 28849744k, after: 28849724k, (-20k) >> RSS before: 8685896k, after: 920740k, (-7765156k) <<<< >> Swap before: 0k, after: 0k, (0k) >> >> >> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory: >> >> >> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident >> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K) >> ^^^^^^^ >> >> >> When the VM is started with -Xlog:os, this is also logged: >> >> >> [139,068s][info][os] malloc_trim: >> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k) >> RSS before: 8685896k, after: 920740k, (-7765156k) >> Swap before: 0k, after: 0k, (0k) > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge > - Rename command (see CSR) > - Merge > - Volker feedback > - Merge > - Feedback Severin; renamed query function > - start The CSR https://bugs.openjdk.java.net/browse/JDK-8269345 is in Provisional. Once it's approved it should become ready for integration. ------------- PR: https://git.openjdk.java.net/jdk/pull/4510 From minqi at openjdk.java.net Wed Jul 14 15:09:09 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 14 Jul 2021 15:09:09 GMT Subject: RFR: 8270333: -XX:+VerifyStringTableAtExit should not do linear search [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 06:02:35 GMT, Ioi Lam wrote: >> The implementation of `-XX:+VerifyStringTableAtExit` used a linear search to check for duplicated strings in the interned string table. This would be excessively slow if there were more than a few thousand strings. >> >> This PR uses a hashtable so we can avoid doing a linear search. The table is sized such that each bucket has 8 items on average. >> >> Since this code is executed only for verification, I added a new `java_lang_String::hash_code_noupdate(oop)` function, so we can avoid causing side effects. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed build and make sure table size is not zero Looks good, but one question. src/hotspot/share/classfile/stringTable.cpp line 613: > 611: public: > 612: size_t _errors; > 613: VerifyCompStrings() : _table(unsigned(_items_count + 8 / 8)), _errors(0) {} I guess you mean unsigned((_items_count + 8) / 8)? ------------- PR: https://git.openjdk.java.net/jdk/pull/4772 From rriggs at openjdk.java.net Wed Jul 14 15:46:15 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 14 Jul 2021 15:46:15 GMT Subject: RFR: 8260265: UTF-8 by Default In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: On Thu, 8 Jul 2021 21:23:00 GMT, Naoto Sato wrote: > This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. > > JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 > CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 291: > 289: * method, which takes an encoding-name or charset argument, > 290: * or the {@code toString()} method, which uses the default > 291: * charset. Fold to previous line. src/java.base/share/classes/java/io/Console.java line 587: > 585: try { > 586: cs = Charset.forName(csname); > 587: } catch (Exception ignored) { } A separate enhancement... I've long thought that should be a way to avoid the exception here. For example, a Charset.forName(csname, default); The caller might have a default in mind or supply null and then be able to test for null. src/java.base/share/classes/java/io/FileReader.java line 41: > 39: * @see InputStreamReader > 40: * @see FileInputStream > 41: * @see java.nio.charset.Charset#defaultCharset() The @ see duplicates the link above, the javadoc can do without the @ see. src/java.base/share/classes/java/io/InputStreamReader.java line 39: > 37: * java.nio.charset.Charset charset}. The charset that it uses > 38: * may be specified by name or may be given explicitly, or the > 39: * {@link Charset#defaultCharset() default charset} may be accepted. "may be accepted" seems like the API has some choice in the matter. Perhaps "accepted" -> "used". And in other classes below if there's a suitable replacement. src/java.base/share/classes/java/io/PrintStream.java line 49: > 47: *

All characters printed by a {@code PrintStream} are converted into > 48: * bytes using the given encoding or charset, or the default > 49: * console charset if not specified. JEP 400 doesn't give a rationale for using the console charset for PrintStream. PrintStreams are used for output to files and other media other than just a tty/console. The charset of system.out/err should use the console charset. src/java.base/share/classes/java/lang/System.java line 802: > 800: * {@systemProperty file.encoding} > 801: * The name of the default charset. Users may specify > 802: * {@code UTF-8} or {@code COMPAT} on the command line to the value. The wording could imply that only those two values can be supplied. It could be rephrased to say that *if* the property is supplied on the command line it overrides the default UTF-8. src/java.base/share/classes/java/net/URLDecoder.java line 92: > 90: > 91: // The default charset > 92: static String dfltEncName = URLEncoder.dfltEncName; Perhaps add the value of file.encoding to the StaticProperties either as a string or as the Charset. That would allow a few different lookups of the property to be simplified. src/java.base/share/classes/java/net/URLEncoder.java line 165: > 163: try { > 164: str = encode(s, dfltEncName); > 165: } catch (UnsupportedEncodingException e) { Perhaps a separate cleanup, the Charset should be cached, not just the name and use the `encode(s, charset)` method. src/java.base/share/classes/java/nio/charset/Charset.java line 601: > 599: * value designates {@code COMPAT}, the default charset is derived from > 600: * the {@code native.encoding} system property, which typically depends > 601: * upon the locale and charset of the underlying operating system. The description in java.lang.System of the file.encoding property does not indicate it is 'implementation specific'. In that context, it appears to be part of the JavaSE spec. Having the spec in a single place with references to it from others could avoid duplication. ------------- PR: https://git.openjdk.java.net/jdk/pull/4733 From stuefe at openjdk.java.net Wed Jul 14 15:55:14 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 14 Jul 2021 15:55:14 GMT Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v5] In-Reply-To: References: <8POs-ek7fxeLPey8_s8PwkBPEQBAgJj4ci5JgPY0ChM=.2ec38ba5-e2ef-4324-b4ae-59dfa56a5fc7@github.com> Message-ID: On Wed, 14 Jul 2021 13:49:52 GMT, Severin Gehwolf wrote: > The CSR https://bugs.openjdk.java.net/browse/JDK-8269345 is in Provisional. Once it's approved it should become ready for integration. Oh, you are right. Good that skara caught that. ------------- PR: https://git.openjdk.java.net/jdk/pull/4510 From github.com+154109+jglick at openjdk.java.net Wed Jul 14 16:23:13 2021 From: github.com+154109+jglick at openjdk.java.net (Jesse Glick) Date: Wed, 14 Jul 2021 16:23:13 GMT Subject: RFR: 8260265: UTF-8 by Default In-Reply-To: References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: On Wed, 14 Jul 2021 15:09:41 GMT, Roger Riggs wrote: >> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. >> >> JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 > > src/java.base/share/classes/java/io/PrintStream.java line 49: > >> 47: *

All characters printed by a {@code PrintStream} are converted into >> 48: * bytes using the given encoding or charset, or the default >> 49: * console charset if not specified. > > JEP 400 doesn't give a rationale for using the console charset for PrintStream. > PrintStreams are used for output to files and other media other than just a tty/console. > The charset of system.out/err should use the console charset. This was my thinking in https://github.com/openjdk/jdk/pull/4733#issuecomment-876793372. ------------- PR: https://git.openjdk.java.net/jdk/pull/4733 From iklam at openjdk.java.net Wed Jul 14 16:45:49 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 14 Jul 2021 16:45:49 GMT Subject: RFR: 8270333: -XX:+VerifyStringTableAtExit should not do linear search [v4] In-Reply-To: References: Message-ID: > The implementation of `-XX:+VerifyStringTableAtExit` used a linear search to check for duplicated strings in the interned string table. This would be excessively slow if there were more than a few thousand strings. > > This PR uses a hashtable so we can avoid doing a linear search. The table is sized such that each bucket has 8 items on average. > > Since this code is executed only for verification, I added a new `java_lang_String::hash_code_noupdate(oop)` function, so we can avoid causing side effects. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @yminqi comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4772/files - new: https://git.openjdk.java.net/jdk/pull/4772/files/66c4d4ea..72d0f8e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4772&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4772&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4772.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4772/head:pull/4772 PR: https://git.openjdk.java.net/jdk/pull/4772 From iklam at openjdk.java.net Wed Jul 14 16:45:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 14 Jul 2021 16:45:52 GMT Subject: RFR: 8270333: -XX:+VerifyStringTableAtExit should not do linear search [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 15:03:52 GMT, Yumin Qi wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed build and make sure table size is not zero > > src/hotspot/share/classfile/stringTable.cpp line 613: > >> 611: public: >> 612: size_t _errors; >> 613: VerifyCompStrings() : _table(unsigned(_items_count + 8 / 8)), _errors(0) {} > > I guess you mean unsigned((_items_count + 8) / 8)? Thanks for the review. I changed it to `_table(unsigned(_items_count / 8) + 1)` ------------- PR: https://git.openjdk.java.net/jdk/pull/4772 From minqi at openjdk.java.net Wed Jul 14 17:10:10 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 14 Jul 2021 17:10:10 GMT Subject: RFR: 8270333: -XX:+VerifyStringTableAtExit should not do linear search [v4] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 16:45:49 GMT, Ioi Lam wrote: >> The implementation of `-XX:+VerifyStringTableAtExit` used a linear search to check for duplicated strings in the interned string table. This would be excessively slow if there were more than a few thousand strings. >> >> This PR uses a hashtable so we can avoid doing a linear search. The table is sized such that each bucket has 8 items on average. >> >> Since this code is executed only for verification, I added a new `java_lang_String::hash_code_noupdate(oop)` function, so we can avoid causing side effects. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @yminqi comments LGTM. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4772 From naoto at openjdk.java.net Wed Jul 14 21:01:56 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 14 Jul 2021 21:01:56 GMT Subject: RFR: 8260265: UTF-8 by Default In-Reply-To: References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: On Wed, 14 Jul 2021 12:39:46 GMT, Giacomo Baso wrote: > > Consider an application that creates a java.io.FileWriter with its one-argument constructor and then uses it to write some text to a file. The resulting file will contain a sequence of bytes encoded using the default charset of the JDK running the application. A second application, run on a different machine or by a different user on the same machine, creates a java.io.FileReader with its one-argument constructor and uses it to read the bytes in that file. The resulting text contains a sequence of characters decoded using the default charset of the JDK running the second application. If the default charset differs between the JDK of the first application and the JDK of the second application, then the resulting text may be silently corrupted or incomplete, since these APIs replace erroneous input rather than fail. > > It's even worse than that, because many OpenSSH installs are configured by default to [forward](https://man.openbsd.org/ssh_config.5#SendEnv) and [accept](https://man.openbsd.org/sshd_config.5#AcceptEnv) the user locale (see e.g. for [RHEL 7](https://access.redhat.com/solutions/974273)). > > So a single application, on a single remote machine, can be unknowingly started by a single user with different locales, and therefore different encodings, depending on how the user connected to the remote machine. For example, on Windows connecting via powershell results in `LANG=en_US.UTF-8`, while using WSL2 results in `LANG=C.UTF-8`. On Java 11 in a RHEL7 machine, `file.encoding` results in `UTF-8` in the first case, but `ANSI_X3.4-1968` in the second, leading to a default charset `ASCII`. > > Worth mentioning is also that `Charset.forName("default")` is just an alias to `ASCII`, per `sun.nio.cs.StandardCharsets$Aliases`. Thanks. Updated the JEP. ------------- PR: https://git.openjdk.java.net/jdk/pull/4733 From naoto at openjdk.java.net Wed Jul 14 21:01:55 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 14 Jul 2021 21:01:55 GMT Subject: RFR: 8260265: UTF-8 by Default [v2] In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: > This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. > > JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 > CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Reflects review comments - Merge branch 'master' into JDK-8260265 - 8260265: UTF-8 by Default ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4733/files - new: https://git.openjdk.java.net/jdk/pull/4733/files/107210cf..981200f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=00-01 Stats: 6434 lines in 314 files changed: 3877 ins; 1452 del; 1105 mod Patch: https://git.openjdk.java.net/jdk/pull/4733.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4733/head:pull/4733 PR: https://git.openjdk.java.net/jdk/pull/4733 From naoto at openjdk.java.net Wed Jul 14 21:02:06 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 14 Jul 2021 21:02:06 GMT Subject: RFR: 8260265: UTF-8 by Default [v2] In-Reply-To: References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: <9b5I8UB7Gga5-GGr5MOQ9XkQczDYXLFULQqboIFq-yw=.dd407e26-aa6d-45d5-8bfc-c12cacb6b008@github.com> On Wed, 14 Jul 2021 14:55:39 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Reflects review comments >> - Merge branch 'master' into JDK-8260265 >> - 8260265: UTF-8 by Default > > src/java.base/share/classes/java/io/Console.java line 587: > >> 585: try { >> 586: cs = Charset.forName(csname); >> 587: } catch (Exception ignored) { } > > A separate enhancement... > I've long thought that should be a way to avoid the exception here. > For example, a Charset.forName(csname, default); > The caller might have a default in mind or supply null and then be able to test for null. Agreed. Will file an RFE for this. > src/java.base/share/classes/java/io/FileReader.java line 41: > >> 39: * @see InputStreamReader >> 40: * @see FileInputStream >> 41: * @see java.nio.charset.Charset#defaultCharset() > > The @ see duplicates the link above, the javadoc can do without the @ see. If I remove that `@see`, I don't see the link in `See Also` section. Am I missing something? > src/java.base/share/classes/java/lang/System.java line 802: > >> 800: * {@systemProperty file.encoding} >> 801: * The name of the default charset. Users may specify >> 802: * {@code UTF-8} or {@code COMPAT} on the command line to the value. > > The wording could imply that only those two values can be supplied. > It could be rephrased to say that *if* the property is supplied on the command line > it overrides the default UTF-8. That was intentional. Only those two are supported, others continue to work as before (but not supported). > src/java.base/share/classes/java/nio/charset/Charset.java line 601: > >> 599: * value designates {@code COMPAT}, the default charset is derived from >> 600: * the {@code native.encoding} system property, which typically depends >> 601: * upon the locale and charset of the underlying operating system. > > The description in java.lang.System of the file.encoding property does not indicate it is 'implementation specific'. > In that context, it appears to be part of the JavaSE spec. > Having the spec in a single place with references to it from others could avoid duplication. `file.encoding` is listed under `@implNote` tag in `System.getProperties()`, so it is implementation-specific. ------------- PR: https://git.openjdk.java.net/jdk/pull/4733 From naoto at openjdk.java.net Wed Jul 14 21:02:07 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 14 Jul 2021 21:02:07 GMT Subject: RFR: 8260265: UTF-8 by Default [v2] In-Reply-To: References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: <43ZOj506cWqOBeux12Q8eBEE_iCtGWW_6YiCzazQDiY=.a29fcbce-3195-4fa0-b22b-4b8f4fefc1b5@github.com> On Wed, 14 Jul 2021 16:20:28 GMT, Jesse Glick wrote: >> src/java.base/share/classes/java/io/PrintStream.java line 49: >> >>> 47: *

All characters printed by a {@code PrintStream} are converted into >>> 48: * bytes using the given encoding or charset, or the default >>> 49: * console charset if not specified. >> >> JEP 400 doesn't give a rationale for using the console charset for PrintStream. >> PrintStreams are used for output to files and other media other than just a tty/console. >> The charset of system.out/err should use the console charset. > > This was my thinking in https://github.com/openjdk/jdk/pull/4733#issuecomment-876793372. OK, I am now conviced. Modified not to default to Console.charset() for generic PrintStream w/o charset constructor. ------------- PR: https://git.openjdk.java.net/jdk/pull/4733 From rriggs at openjdk.java.net Wed Jul 14 21:09:15 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 14 Jul 2021 21:09:15 GMT Subject: RFR: 8260265: UTF-8 by Default [v2] In-Reply-To: <9b5I8UB7Gga5-GGr5MOQ9XkQczDYXLFULQqboIFq-yw=.dd407e26-aa6d-45d5-8bfc-c12cacb6b008@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> <9b5I8UB7Gga5-GGr5MOQ9XkQczDYXLFULQqboIFq-yw=.dd407e26-aa6d-45d5-8bfc-c12cacb6b008@github.com> Message-ID: <9jHHvVP67dsNtuMevEoMYxNq9P35RXOygFNlqCg3rdI=.228cb59e-3924-4d8b-961e-1e6e28f4ee38@github.com> On Wed, 14 Jul 2021 20:53:34 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/io/FileReader.java line 41: >> >>> 39: * @see InputStreamReader >>> 40: * @see FileInputStream >>> 41: * @see java.nio.charset.Charset#defaultCharset() >> >> The @ see duplicates the link above, the javadoc can do without the @ see. > > If I remove that `@see`, I don't see the link in `See Also` section. Am I missing something? In my view the @ linkplain is sufficient to allow the reader to navigate; but YMMV. >> src/java.base/share/classes/java/lang/System.java line 802: >> >>> 800: * {@systemProperty file.encoding} >>> 801: * The name of the default charset. Users may specify >>> 802: * {@code UTF-8} or {@code COMPAT} on the command line to the value. >> >> The wording could imply that only those two values can be supplied. >> It could be rephrased to say that *if* the property is supplied on the command line >> it overrides the default UTF-8. > > That was intentional. Only those two are supported, others continue to work as before (but not supported). Still it leaves an uncomfortable feeling, perhaps remedied by an "other values have unspecified behavior" or the "other values are implementation specific". ------------- PR: https://git.openjdk.java.net/jdk/pull/4733 From naoto at openjdk.java.net Wed Jul 14 22:02:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 14 Jul 2021 22:02:40 GMT Subject: RFR: 8260265: UTF-8 by Default [v3] In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: > This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. > > JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 > CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflects comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4733/files - new: https://git.openjdk.java.net/jdk/pull/4733/files/981200f7..182dcb6d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=01-02 Stats: 28 lines in 2 files changed: 0 ins; 0 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/4733.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4733/head:pull/4733 PR: https://git.openjdk.java.net/jdk/pull/4733 From naoto at openjdk.java.net Wed Jul 14 22:02:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 14 Jul 2021 22:02:40 GMT Subject: RFR: 8260265: UTF-8 by Default [v3] In-Reply-To: <9jHHvVP67dsNtuMevEoMYxNq9P35RXOygFNlqCg3rdI=.228cb59e-3924-4d8b-961e-1e6e28f4ee38@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> <9b5I8UB7Gga5-GGr5MOQ9XkQczDYXLFULQqboIFq-yw=.dd407e26-aa6d-45d5-8bfc-c12cacb6b008@github.com> <9jHHvVP67dsNtuMevEoMYxNq9P35RXOygFNlqCg3rdI=.228cb59e-3924-4d8b-961e-1e6e28f4ee38@github.com> Message-ID: On Wed, 14 Jul 2021 21:03:53 GMT, Roger Riggs wrote: >> That was intentional. Only those two are supported, others continue to work as before (but not supported). > > Still it leaves an uncomfortable feeling, perhaps remedied by an "other values have unspecified behavior" > or the "other values are implementation specific". Added the clarifying sentence to the spec. ------------- PR: https://git.openjdk.java.net/jdk/pull/4733 From naoto at openjdk.java.net Wed Jul 14 22:07:16 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 14 Jul 2021 22:07:16 GMT Subject: RFR: 8260265: UTF-8 by Default [v3] In-Reply-To: <9b5I8UB7Gga5-GGr5MOQ9XkQczDYXLFULQqboIFq-yw=.dd407e26-aa6d-45d5-8bfc-c12cacb6b008@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> <9b5I8UB7Gga5-GGr5MOQ9XkQczDYXLFULQqboIFq-yw=.dd407e26-aa6d-45d5-8bfc-c12cacb6b008@github.com> Message-ID: On Wed, 14 Jul 2021 20:52:54 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/io/Console.java line 587: >> >>> 585: try { >>> 586: cs = Charset.forName(csname); >>> 587: } catch (Exception ignored) { } >> >> A separate enhancement... >> I've long thought that should be a way to avoid the exception here. >> For example, a Charset.forName(csname, default); >> The caller might have a default in mind or supply null and then be able to test for null. > > Agreed. Will file an RFE for this. https://bugs.openjdk.java.net/browse/JDK-8270490 ------------- PR: https://git.openjdk.java.net/jdk/pull/4733 From dholmes at openjdk.java.net Thu Jul 15 01:54:17 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Jul 2021 01:54:17 GMT Subject: RFR: 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 22:42:12 GMT, David Holmes wrote: >> Please review this simple enhancement that: >> >> 1. Retries OS thread creation of it fails due to EAGAIN >> >> This is potentially of limited use as you would need some resources to be released for subsequent calls to succeed. >> >> 2. Prints the name of the thread being started in the warning/log messages >> >> This is also of limited use as JavaThread's do not have their correct name at this stage, nor do some system threads. But others do, so it can be informative. >> >> I looked at trying to (separately) unify this code into a Posix version, but the platform differences are such that it makes it very difficult to try and share code. So this simply updates each the existing code in place. >> >> Testing: >> - builds from tiers 1-3 and GHA >> - manual inspection of output from a simple thread exhaustion test (runtime/Thread/ThreadCountLimit.java) >> - manual inspection of os+thread logging on java -version >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Update expected output now that thread name is included I'm closing this PR to retackle the logging updates a different way, in different locations where more information is available - at least for JavaThreads. ------------- PR: https://git.openjdk.java.net/jdk/pull/4648 From dholmes at openjdk.java.net Thu Jul 15 01:54:17 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Jul 2021 01:54:17 GMT Subject: Withdrawn: 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 06:24:02 GMT, David Holmes wrote: > Please review this simple enhancement that: > > 1. Retries OS thread creation of it fails due to EAGAIN > > This is potentially of limited use as you would need some resources to be released for subsequent calls to succeed. > > 2. Prints the name of the thread being started in the warning/log messages > > This is also of limited use as JavaThread's do not have their correct name at this stage, nor do some system threads. But others do, so it can be informative. > > I looked at trying to (separately) unify this code into a Posix version, but the platform differences are such that it makes it very difficult to try and share code. So this simply updates each the existing code in place. > > Testing: > - builds from tiers 1-3 and GHA > - manual inspection of output from a simple thread exhaustion test (runtime/Thread/ThreadCountLimit.java) > - manual inspection of os+thread logging on java -version > > Thanks, > David This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4648 From aoqi at openjdk.java.net Thu Jul 15 04:10:21 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Thu, 15 Jul 2021 04:10:21 GMT Subject: RFR: 8270517: Add Zero support for LoongArch Message-ID: LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. linux-loongarch64-zero-{release, fastdebug} build tested: $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version openjdk version "18-internal" 2022-03-15 OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) ------------- Commit messages: - 8270517: Add Zero support for LoongArch Changes: https://git.openjdk.java.net/jdk/pull/4787/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4787&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270517 Stats: 22 lines in 3 files changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4787.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4787/head:pull/4787 PR: https://git.openjdk.java.net/jdk/pull/4787 From dholmes at openjdk.java.net Thu Jul 15 04:41:13 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Jul 2021 04:41:13 GMT Subject: RFR: 8270517: Add Zero support for LoongArch In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 04:04:08 GMT, Ao Qi wrote: > LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. > > linux-loongarch64-zero-{release, fastdebug} build tested: > > $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version > openjdk version "18-internal" 2022-03-15 > OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) > OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) The hotspot changes seem fine. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4787 From iklam at openjdk.java.net Thu Jul 15 05:18:18 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 15 Jul 2021 05:18:18 GMT Subject: RFR: 8270333: -XX:+VerifyStringTableAtExit should not do linear search [v3] In-Reply-To: References: Message-ID: <2QggTtU-rbrmq8DmN8HBnvbJYOQnWKhOM-u030wK4L8=.04239e72-92f4-4256-9aab-596fe83912f8@github.com> On Wed, 14 Jul 2021 06:32:58 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed build and make sure table size is not zero > > Okay ... I'm not sure why you want the code to be duplicated though? Thanks @dholmes-ora and @yminqi for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/4772 From iklam at openjdk.java.net Thu Jul 15 05:18:18 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 15 Jul 2021 05:18:18 GMT Subject: Integrated: 8270333: -XX:+VerifyStringTableAtExit should not do linear search In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 02:34:19 GMT, Ioi Lam wrote: > The implementation of `-XX:+VerifyStringTableAtExit` used a linear search to check for duplicated strings in the interned string table. This would be excessively slow if there were more than a few thousand strings. > > This PR uses a hashtable so we can avoid doing a linear search. The table is sized such that each bucket has 8 items on average. > > Since this code is executed only for verification, I added a new `java_lang_String::hash_code_noupdate(oop)` function, so we can avoid causing side effects. This pull request has now been integrated. Changeset: 1ebd9469 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/1ebd9469db1adada9f5ad41f8599e9458da58399 Stats: 45 lines in 3 files changed: 24 ins; 8 del; 13 mod 8270333: -XX:+VerifyStringTableAtExit should not do linear search Reviewed-by: dholmes, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/4772 From erikj at openjdk.java.net Thu Jul 15 06:35:13 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 15 Jul 2021 06:35:13 GMT Subject: RFR: 8270517: Add Zero support for LoongArch In-Reply-To: References: Message-ID: <_AMKiWZ9E5nHHsIv14njAJ0ZKFqFzkQb8IkVYPS16SQ=.01b5963d-6ea3-4db9-a186-3cf0f0e8c540@github.com> On Thu, 15 Jul 2021 04:04:08 GMT, Ao Qi wrote: > LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. > > linux-loongarch64-zero-{release, fastdebug} build tested: > > $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version > openjdk version "18-internal" 2022-03-15 > OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) > OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4787 From shade at openjdk.java.net Thu Jul 15 06:41:14 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 15 Jul 2021 06:41:14 GMT Subject: RFR: 8270517: Add Zero support for LoongArch In-Reply-To: References: Message-ID: <0TPPBbR-_VfALh6nIU_YF84iE0XywjXZq6bl4M0sZ9Q=.e163e50b-14c4-4d68-8c97-d5576dcc9292@github.com> On Thu, 15 Jul 2021 04:04:08 GMT, Ao Qi wrote: > LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. > > linux-loongarch64-zero-{release, fastdebug} build tested: > > $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version > openjdk version "18-internal" 2022-03-15 > OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) > OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) Looks good for me (from Zero maintenance standpoint). A minor suggestion below. src/hotspot/os/linux/os_linux.cpp line 1701: > 1699: {EM_AARCH64, EM_AARCH64, ELFCLASS64, ELFDATA2LSB, (char*)"AARCH64"}, > 1700: {EM_RISCV, EM_RISCV, ELFCLASS64, ELFDATA2LSB, (char*)"RISC-V"}, > 1701: {EM_LOONGARCH, EM_LOONGARCH, ELFCLASS64, ELFDATA2LSB, (char*)"LoongArch"}, Suggestion: {EM_LOONGARCH, EM_LOONGARCH, ELFCLASS64, ELFDATA2LSB, (char*)"LoongArch"}, ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4787 From aoqi at openjdk.java.net Thu Jul 15 07:27:11 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Thu, 15 Jul 2021 07:27:11 GMT Subject: RFR: 8270517: Add Zero support for LoongArch In-Reply-To: <0TPPBbR-_VfALh6nIU_YF84iE0XywjXZq6bl4M0sZ9Q=.e163e50b-14c4-4d68-8c97-d5576dcc9292@github.com> References: <0TPPBbR-_VfALh6nIU_YF84iE0XywjXZq6bl4M0sZ9Q=.e163e50b-14c4-4d68-8c97-d5576dcc9292@github.com> Message-ID: On Thu, 15 Jul 2021 06:30:24 GMT, Aleksey Shipilev wrote: >> LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. >> >> linux-loongarch64-zero-{release, fastdebug} build tested: >> >> $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version >> openjdk version "18-internal" 2022-03-15 >> OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) >> OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) > > src/hotspot/os/linux/os_linux.cpp line 1701: > >> 1699: {EM_AARCH64, EM_AARCH64, ELFCLASS64, ELFDATA2LSB, (char*)"AARCH64"}, >> 1700: {EM_RISCV, EM_RISCV, ELFCLASS64, ELFDATA2LSB, (char*)"RISC-V"}, >> 1701: {EM_LOONGARCH, EM_LOONGARCH, ELFCLASS64, ELFDATA2LSB, (char*)"LoongArch"}, > > Suggestion: > > {EM_LOONGARCH, EM_LOONGARCH, ELFCLASS64, ELFDATA2LSB, (char*)"LoongArch"}, I added some additional whitespaces according to EM_MIPS_RS3_LE line, which is also too long. Your suggestion is fine to me. I will fix it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4787 From dholmes at openjdk.java.net Thu Jul 15 07:35:28 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Jul 2021 07:35:28 GMT Subject: RFR: 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) Message-ID: Take 2. Summary of changes: 1. If the low-level thread creation fails with EAGAIN we retry three times This is unlikely to be that helpful as the chances the needed resources have been freed since the previous attempt, are very low. But it doesn't hurt (it just delays reporting an error). 2. If the low-level thread creation fails we print a warning which now includes the thread name. And for symmetry we also report the name when creation is successful. For regular JavaThreads (and some system threads) the name is not set/available at the time of this logging so it reports "unknown thread" at this level. 3. For application Java threads JVM_StartThread now also produces a logging statement, if the native thread creation failed, that can show the actual name. Hence we will see e.g.: [1.068s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 0k, detached. [1.068s][warning][os,thread] Failed to start the native thread for java.lang.Thread "Thread-3581" I didn't include a new logging statement for successful thread creation, just to show the name, as it seemed unnecessary. But that could be added if requested. 4. I had to adjust the notion of `is_protected_JavaThread` to account for a newly created but unstarted JavaThread. 5. One test of Java thread logging needed adjusting to account for the name now appearing. Testing: - manual checking via thread exhaustion test - tiers 1-3 Thanks, David ------------- Commit messages: - 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) Changes: https://git.openjdk.java.net/jdk/pull/4788/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4788&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268773 Stats: 76 lines in 8 files changed: 46 ins; 0 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/4788.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4788/head:pull/4788 PR: https://git.openjdk.java.net/jdk/pull/4788 From aoqi at openjdk.java.net Thu Jul 15 07:42:33 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Thu, 15 Jul 2021 07:42:33 GMT Subject: RFR: 8270517: Add Zero support for LoongArch [v2] In-Reply-To: References: Message-ID: > LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. > > linux-loongarch64-zero-{release, fastdebug} build tested: > > $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version > openjdk version "18-internal" 2022-03-15 > OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) > OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) Ao Qi has updated the pull request incrementally with one additional commit since the last revision: removed redundant whitespaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4787/files - new: https://git.openjdk.java.net/jdk/pull/4787/files/bd626159..5dbfe543 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4787&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4787&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4787.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4787/head:pull/4787 PR: https://git.openjdk.java.net/jdk/pull/4787 From dholmes at openjdk.java.net Thu Jul 15 07:57:12 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Jul 2021 07:57:12 GMT Subject: RFR: 8270517: Add Zero support for LoongArch [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 07:42:33 GMT, Ao Qi wrote: >> LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. >> >> linux-loongarch64-zero-{release, fastdebug} build tested: >> >> $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version >> openjdk version "18-internal" 2022-03-15 >> OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) >> OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) > > Ao Qi has updated the pull request incrementally with one additional commit since the last revision: > > removed redundant whitespaces Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4787 From aoqi at openjdk.java.net Thu Jul 15 08:15:17 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Thu, 15 Jul 2021 08:15:17 GMT Subject: RFR: 8270517: Add Zero support for LoongArch [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 07:54:41 GMT, David Holmes wrote: >> Ao Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> removed redundant whitespaces > > Marked as reviewed by dholmes (Reviewer). @dholmes-ora @erikj79 and @shipilev , thanks for the fast review! I also did a release bootcycle-images test and a jcstress test. They are passed. Could you help to sponsor it? ------------- PR: https://git.openjdk.java.net/jdk/pull/4787 From aoqi at openjdk.java.net Thu Jul 15 08:31:14 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Thu, 15 Jul 2021 08:31:14 GMT Subject: Integrated: 8270517: Add Zero support for LoongArch In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 04:04:08 GMT, Ao Qi wrote: > LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. > > linux-loongarch64-zero-{release, fastdebug} build tested: > > $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version > openjdk version "18-internal" 2022-03-15 > OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) > OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) This pull request has now been integrated. Changeset: e92e2fd4 Author: Ao Qi Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/e92e2fd4e0bc805d8f7d70f632cce0282eb1809b Stats: 22 lines in 3 files changed: 21 ins; 0 del; 1 mod 8270517: Add Zero support for LoongArch Reviewed-by: dholmes, erikj, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/4787 From shade at openjdk.java.net Thu Jul 15 08:31:14 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 15 Jul 2021 08:31:14 GMT Subject: RFR: 8270517: Add Zero support for LoongArch [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 07:42:33 GMT, Ao Qi wrote: >> LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. >> >> linux-loongarch64-zero-{release, fastdebug} build tested: >> >> $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version >> openjdk version "18-internal" 2022-03-15 >> OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) >> OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) > > Ao Qi has updated the pull request incrementally with one additional commit since the last revision: > > removed redundant whitespaces Oh wait, the PR is only 4 hours old, so I removed my `/sponsor` comment, but it was apparently too late. I should have waited for a bit longer. No harm seems to be done yet. We shall do any followups, if any problems arise. ------------- PR: https://git.openjdk.java.net/jdk/pull/4787 From aoqi at openjdk.java.net Thu Jul 15 08:38:16 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Thu, 15 Jul 2021 08:38:16 GMT Subject: RFR: 8270517: Add Zero support for LoongArch [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 07:42:33 GMT, Ao Qi wrote: >> LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. >> >> linux-loongarch64-zero-{release, fastdebug} build tested: >> >> $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version >> openjdk version "18-internal" 2022-03-15 >> OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) >> OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) > > Ao Qi has updated the pull request incrementally with one additional commit since the last revision: > > removed redundant whitespaces I apologized that I type "/integrate" too early. I will pay close attention to this issue in the next few days in case any problems arise. ------------- PR: https://git.openjdk.java.net/jdk/pull/4787 From jvernee at openjdk.java.net Thu Jul 15 10:50:36 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 15 Jul 2021 10:50:36 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2] In-Reply-To: References: Message-ID: <66vtM23dULcHDhjAYzZipQHy0KQHxwNKleKJIUlFnDo=.fe454def-a1a6-4475-94c2-06e85eea53e9@github.com> On Wed, 14 Jul 2021 00:24:38 GMT, David Holmes wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Assert frame is correct type in frame_data_for_frame > > src/hotspot/share/prims/universalUpcallHandler.cpp line 86: > >> 84: context->new_handles = JNIHandleBlock::allocate_block(thread); >> 85: >> 86: // After this, we are official in Java Code. This needs to be done before we change any of the thread local > > typo: s/official/officially/ > (I see this was copied from Javacalls) Thanks, I wasn't sure whether to leave the comments in or not. > src/hotspot/share/prims/universalUpcallHandler.cpp line 114: > >> 112: thread->set_active_handles(context->new_handles); // install new handle block and reset Java frame linkage >> 113: >> 114: assert (thread->thread_state() != _thread_in_native, "cannot set native pc to NULL"); > > You transitioned to _thread_in_Java above so how can you possibly have changed state again ?? (okay again copied from javaCalls ...) Yeah, it seemed paranoid to me as well. I'll remove this > src/hotspot/share/prims/universalUpcallHandler.cpp line 121: > >> 119: } >> 120: >> 121: MACOS_AARCH64_ONLY(thread->enable_wx(WXExec)); > > Not clear why this is needed? JavaCallWrapper doesn't use it. I took this from JavaCallWrapper. Seems to have been added in 17 for the mach aarch64 port: https://github.com/openjdk/jdk17/blame/a32d2eefea12771522b942b32985df0fe50119e8/src/hotspot/share/runtime/javaCalls.cpp#L112 ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From jvernee at openjdk.java.net Thu Jul 15 11:06:13 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 15 Jul 2021 11:06:13 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 00:50:44 GMT, David Holmes wrote: >> src/hotspot/share/runtime/safepoint.cpp line 931: >> >>> 929: // See if return type is an oop. >>> 930: bool return_oop = nm->method()->is_returning_oop(); >>> 931: HandleMark hm(self); >> >> I was seeing an `assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark` when the existing code allocates the Handle for `return_value` in the code down below. It seems to be a simple case of a missing handle mark, so I've added it here. (looking at the stack trace in the error log, the caller frame is native code, so I don't think we can expect the caller to have a HandleMark). > > How does native code reach a safepoint polling point? The stack trace looks like this: Current thread (0x000002a2489f0b50): JavaThread "Thread-4551" [_thread_in_Java, id=24920, stack(0x000000d9e0500000,0x000000d9e0600000)] Stack: [0x000000d9e0500000,0x000000d9e0600000] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0xae6651] os::platform_print_native_stack+0xf1 (os_windows_x86.cpp:235) V [jvm.dll+0xda3f25] VMError::report+0x1005 (vmError.cpp:739) V [jvm.dll+0xda58ae] VMError::report_and_die+0x7fe (vmError.cpp:1549) V [jvm.dll+0xda5fe4] VMError::report_and_die+0x64 (vmError.cpp:1330) V [jvm.dll+0x4ceca7] report_vm_error+0xb7 (debug.cpp:282) V [jvm.dll+0x6511be] HandleArea::allocate_handle+0x3e (handles.cpp:35) V [jvm.dll+0xb8e334] ThreadSafepointState::handle_polling_page_exception+0x314 (safepoint.cpp:939) C 0x000002a035d8caa7 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) v ~SafepointBlob J 639 c1 java.lang.invoke.LambdaForm$MH+0x000000080101b800.invoke(Ljava/lang/Object;)V java.base at 18-internal (87 bytes) @ 0x000002a03635f7b4 [0x000002a03635f4a0+0x0000000000000314] J 620 c1 java.lang.invoke.LambdaForm$MH+0x0000000801018c00.invoke(Ljava/lang/Object;)V java.base at 18-internal (37 bytes) @ 0x000002a036353e0c [0x000002a036353720+0x00000000000006ec] v ~BufferBlob::m?Y?????G? So I think the 'native code' is something being called by the safepoint blob, but I'm not sure why it's marked with a `C` instead of `V` in the stack trace (maybe just a stack unwind failure?). FWIW, this part has already been fixed as part of: https://github.com/openjdk/jdk17/pull/173 (not sure why it still shows up in the diff) ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From stuefe at openjdk.java.net Thu Jul 15 11:33:10 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 15 Jul 2021 11:33:10 GMT Subject: RFR: 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 07:18:05 GMT, David Holmes wrote: > Take 2. > > Summary of changes: > > 1. If the low-level thread creation fails with EAGAIN we retry three times > > This is unlikely to be that helpful as the chances the needed resources have been freed since the previous attempt, are very low. But it doesn't hurt (it just delays reporting an error). > > 2. If the low-level thread creation fails we print a warning which now includes the thread name. And for symmetry we also report the name when creation is successful. > > For regular JavaThreads (and some system threads) the name is not set/available at the time of this logging so it reports "unknown thread" at this level. > > 3. For application Java threads JVM_StartThread now also produces a logging statement, if the native thread creation failed, that can show the actual name. Hence we will see e.g.: > > [1.068s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 0k, detached. > [1.068s][warning][os,thread] Failed to start the native thread for java.lang.Thread "Thread-3581" > > I didn't include a new logging statement for successful thread creation, just to show the name, as it seemed unnecessary. But that could be added if requested. > > 4. I had to adjust the notion of `is_protected_JavaThread` to account for a newly created but unstarted JavaThread. > > 5. One test of Java thread logging needed adjusting to account for the name now appearing. > > Testing: > - manual checking via thread exhaustion test > - tiers 1-3 > > Thanks, > David This looks good. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4788 From jvernee at openjdk.java.net Thu Jul 15 12:29:26 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 15 Jul 2021 12:29:26 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 00:47:47 GMT, David Holmes wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Assert frame is correct type in frame_data_for_frame > > src/hotspot/share/prims/universalUpcallHandler.cpp line 76: > >> 74: >> 75: // modelled after JavaCallWrapper::JavaCallWrapper >> 76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) { > > This should return JavaThread not Thread. Thanks. I've been careful here to return a `Thread*` since the result is stored in `r15_thread` and I thought converting between sub and super types could potentially result in different pointers due to the way super types are laid out within a subtype. I thought it worked like this: Subclass +--- | {Subclass vtable pointer} | +--- (base class Super) | | {Super vtable pointer} | +--- +--- So, I thought plainly using a `JavaThread*` in generated machine code where a `Thread*` was expected could cause trouble, since the pointer needs to be offset for the type conversion. But now that I'm looking at some cases with compiler explorer, the pointer offset only seems to be needed when using multiple inheritance, for instance: class SuperA { public: virtual void foo(); }; class SuperB { public: virtual void bar(); }; class Sub : public SuperA, public SuperB { public: virtual void baz(); }; Results in: class Sub size(16): +--- 0 | +--- (base class SuperA) 0 | | {vfptr} | +--- 8 | +--- (base class SuperB) 8 | | {vfptr} | +--- +--- Sub::$vftable at SuperA@: | &Sub_meta | 0 0 | &SuperA::foo 1 | &Sub::baz Sub::$vftable at SuperB@: | -8 0 | &SuperB::bar Sub::baz this adjustor: 0 (https://godbolt.org/z/rq9bT8d9d) It seems that the sub type just reuses the vtable pointer of the first super type (probably to avoid having to do this pointer offsetting). Though, converting between `SuperB*` and `Sub*` would require offsetting the pointer. I'm still not sure this is guaranteed to work like this with all compilers though (the example is with MSVC, which has options to dump class layouts). The result of `on_entry` is stored in `r15_thread`, so I guess I'm wondering if it's safe to store a `JavaThread*` instead of a `Thread*` in `r15`, and other code, which may expect `r15` to hold a `Thread*`, is guaranteed to keep working? (FWIW, after changing the return type to `JavaThread*` the tests that exercise this code still pass on Windows with MSVC, and on WSL Linux with GCC). ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From jvernee at openjdk.java.net Thu Jul 15 12:41:33 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 15 Jul 2021 12:41:33 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 00:58:38 GMT, David Holmes wrote: > The mapping to JavaCallWrapper seems reasonable but there are a few differences that I'm now assuming stem from the fact upcalls start _thread_in_native while JCW starts from _thread_in_vm? The main difference stems from the fact that, since these upcalls can come from non-JNI native code, we can not assume that the thread is already attached to the VM, so we do that on the fly instead, and we detach the thread again after the upcall (if needed). Those are what the call to `maybe_attach_and_get_thread` at the start of `on_entry`, and `detach_thread` call at the end of `on_exit` are for. The other thing is that there is no stack watermark check at the end of `on_exit`. This check is guarded by a check if the thread has any pending exceptions in `JavaCallWrapper`, but since a panama upcall is not allowed to throw any exceptions, I've changed that to an `assert` that checks that there are no pending exceptions at that point instead. The last thing is that we transition directly from `_thread_in_native` to `_thread_in_Java`, which changes some of the thread transition code. Other than that, I've tried to mimic what `JavaCallWrapper` does as closely as possible. Is there anything else that looks different? ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From david.holmes at oracle.com Thu Jul 15 12:44:39 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Jul 2021 22:44:39 +1000 Subject: RFR: 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) In-Reply-To: References: Message-ID: <0c5480de-5d08-5c82-2c6c-d7157ae9a8b0@oracle.com> On 15/07/2021 9:33 pm, Thomas Stuefe wrote: > On Thu, 15 Jul 2021 07:18:05 GMT, David Holmes wrote: > >> Take 2. >> >> Summary of changes: >> >> 1. If the low-level thread creation fails with EAGAIN we retry three times >> >> This is unlikely to be that helpful as the chances the needed resources have been freed since the previous attempt, are very low. But it doesn't hurt (it just delays reporting an error). >> >> 2. If the low-level thread creation fails we print a warning which now includes the thread name. And for symmetry we also report the name when creation is successful. >> >> For regular JavaThreads (and some system threads) the name is not set/available at the time of this logging so it reports "unknown thread" at this level. >> >> 3. For application Java threads JVM_StartThread now also produces a logging statement, if the native thread creation failed, that can show the actual name. Hence we will see e.g.: >> >> [1.068s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 0k, detached. >> [1.068s][warning][os,thread] Failed to start the native thread for java.lang.Thread "Thread-3581" >> >> I didn't include a new logging statement for successful thread creation, just to show the name, as it seemed unnecessary. But that could be added if requested. >> >> 4. I had to adjust the notion of `is_protected_JavaThread` to account for a newly created but unstarted JavaThread. >> >> 5. One test of Java thread logging needed adjusting to account for the name now appearing. >> >> Testing: >> - manual checking via thread exhaustion test >> - tiers 1-3 >> >> Thanks, >> David > > This looks good. Thanks for the review Thomas! David ----- > ------------- > > Marked as reviewed by stuefe (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/4788 > From jvernee at openjdk.java.net Thu Jul 15 12:47:22 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 15 Jul 2021 12:47:22 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 12:25:54 GMT, Jorn Vernee wrote: >> src/hotspot/share/prims/universalUpcallHandler.cpp line 76: >> >>> 74: >>> 75: // modelled after JavaCallWrapper::JavaCallWrapper >>> 76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) { >> >> This should return JavaThread not Thread. > > Thanks. > > I've been careful here to return a `Thread*` since the result is stored in `r15_thread` and I thought converting between sub and super types could potentially result in different pointers due to the way super types are laid out within a subtype. I thought it worked like this: > > > Subclass > +--- > | {Subclass vtable pointer} > | +--- (base class Super) > | | {Super vtable pointer} > | +--- > +--- > > > So, I thought plainly using a `JavaThread*` in generated machine code where a `Thread*` was expected could cause trouble, since the pointer needs to be offset for the type conversion. > > But now that I'm looking at some cases with compiler explorer, the pointer offset only seems to be needed when using multiple inheritance, for instance: > > > class SuperA { > public: > virtual void foo(); > }; > > class SuperB { > public: > virtual void bar(); > }; > > class Sub : public SuperA, public SuperB { > public: > virtual void baz(); > }; > > > Results in: > > > class Sub size(16): > +--- > 0 | +--- (base class SuperA) > 0 | | {vfptr} > | +--- > 8 | +--- (base class SuperB) > 8 | | {vfptr} > | +--- > +--- > > Sub::$vftable at SuperA@: > | &Sub_meta > | 0 > 0 | &SuperA::foo > 1 | &Sub::baz > > Sub::$vftable at SuperB@: > | -8 > 0 | &SuperB::bar > > Sub::baz this adjustor: 0 > > > (https://godbolt.org/z/1665fWzff) > > It seems that the sub type just reuses the vtable pointer of the first super type (probably to avoid having to do this pointer offsetting). Though, converting between `SuperB*` and `Sub*` would require offsetting the pointer. I'm still not sure this is guaranteed to work like this with all compilers though (the example is with MSVC, which has options to dump class layouts). > > The result of `on_entry` is stored in `r15_thread`, so I guess I'm wondering if it's safe to store a `JavaThread*` instead of a `Thread*` in `r15`, and other code, which may expect `r15` to hold a `Thread*`, is guaranteed to keep working? (FWIW, after changing the return type to `JavaThread*` the tests that exercise this code still pass on Windows with MSVC, and on WSL Linux with GCC). Sorry, I sent the wrong godbolt link: https://godbolt.org/z/1665fWzff ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From david.holmes at oracle.com Thu Jul 15 12:54:39 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Jul 2021 22:54:39 +1000 Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2] In-Reply-To: References: Message-ID: On 15/07/2021 10:29 pm, Jorn Vernee wrote: > On Wed, 14 Jul 2021 00:47:47 GMT, David Holmes wrote: > >>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Assert frame is correct type in frame_data_for_frame >> >> src/hotspot/share/prims/universalUpcallHandler.cpp line 76: >> >>> 74: >>> 75: // modelled after JavaCallWrapper::JavaCallWrapper >>> 76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) { >> >> This should return JavaThread not Thread. > > Thanks. > > I've been careful here to return a `Thread*` since the result is stored in `r15_thread` and I thought converting between sub and super types could potentially result in different pointers due to the way super types are laid out within a subtype. I thought it worked like this: Wow! Okay I've never seen anyone query this before. AFAIK whatever we store in r15_thread is required to be a correct pointer to the current thread object whatever its exact subtype may be. The returned pointer has to work correctly for virtual functions and can't be a "sliced" Thread instead of the real type. So as far as I know this "just works" and I think we'd be in big trouble if it didn't work. But I don't deal with the under-the-covers parts of the C++ compiler. David ----- > > Subclass > +--- > | {Subclass vtable pointer} > | +--- (base class Super) > | | {Super vtable pointer} > | +--- > +--- > > > So, I thought plainly using a `JavaThread*` in generated machine code where a `Thread*` was expected could cause trouble, since the pointer needs to be offset for the type conversion. > > But now that I'm looking at some cases with compiler explorer, the pointer offset only seems to be needed when using multiple inheritance, for instance: > > > class SuperA { > public: > virtual void foo(); > }; > > class SuperB { > public: > virtual void bar(); > }; > > class Sub : public SuperA, public SuperB { > public: > virtual void baz(); > }; > > > Results in: > > > class Sub size(16): > +--- > 0 | +--- (base class SuperA) > 0 | | {vfptr} > | +--- > 8 | +--- (base class SuperB) > 8 | | {vfptr} > | +--- > +--- > > Sub::$vftable at SuperA@: > | &Sub_meta > | 0 > 0 | &SuperA::foo > 1 | &Sub::baz > > Sub::$vftable at SuperB@: > | -8 > 0 | &SuperB::bar > > Sub::baz this adjustor: 0 > > > (https://godbolt.org/z/rq9bT8d9d) > > It seems that the sub type just reuses the vtable pointer of the first super type (probably to avoid having to do this pointer offsetting). Though, converting between `SuperB*` and `Sub*` would require offsetting the pointer. I'm still not sure this is guaranteed to work like this with all compilers though (the example is with MSVC, which has options to dump class layouts). > > The result of `on_entry` is stored in `r15_thread`, so I guess I'm wondering if it's safe to store a `JavaThread*` instead of a `Thread*` in `r15`, and other code, which may expect `r15` to hold a `Thread*`, is guaranteed to keep working? (FWIW, after changing the return type to `JavaThread*` the tests that exercise this code still pass on Windows with MSVC, and on WSL Linux with GCC). > > ------------- > > PR: https://git.openjdk.java.net/jdk17/pull/149 > From jvernee at openjdk.java.net Thu Jul 15 15:54:50 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 15 Jul 2021 15:54:50 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3] In-Reply-To: References: Message-ID: > This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title. > > Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread. > > The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks. > > FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob. > > Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Address David's review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/149/files - new: https://git.openjdk.java.net/jdk17/pull/149/files/211bf316..128f48db Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=149&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=149&range=01-02 Stats: 20 lines in 3 files changed: 0 ins; 8 del; 12 mod Patch: https://git.openjdk.java.net/jdk17/pull/149.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/149/head:pull/149 PR: https://git.openjdk.java.net/jdk17/pull/149 From jvernee at openjdk.java.net Thu Jul 15 15:58:16 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 15 Jul 2021 15:58:16 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 15:54:50 GMT, Jorn Vernee wrote: >> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title. >> >> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread. >> >> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks. >> >> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob. >> >> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Address David's review comments David, I've addressed your review comments. For now I went with changing the return type of `on_entry` to `JavaThread*`, assuming the potential pointer conversion is not an issue. I tried for a while to implement a static assert to check that `Thread*` is trivial convertible to `JavaThread*` as well, but couldn't find a way to do that at compile time, so left it for now. It looks like C++ 20 has a type trait to check this: https://en.cppreference.com/w/cpp/types/is_pointer_interconvertible_base_of (I think this does what we want). I thought maybe we could just mimic the reference implementation, but looking at for instance the MSVC STL implementation, this type trait is implemented as a compiler intrinsic, so I think we'll have to wait until we are on C++ 20 before adding such a static assert. ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From wkemper at openjdk.java.net Thu Jul 15 16:31:15 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 15 Jul 2021 16:31:15 GMT Subject: [jdk17] Integrated: 8268635: Corrupt oop in ClassLoaderData In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 23:08:55 GMT, William Kemper wrote: > Hi all, > > This pull request contains a backport of commit 3586a233 from the openjdk/jdk repository. > > The commit being backported was authored by Coleen Phillimore on 7 Jul 2021 and was reviewed by Ioi Lam and David Holmes. > > Thanks! This pull request has now been integrated. Changeset: e104dede Author: William Kemper Committer: Christoph Langer URL: https://git.openjdk.java.net/jdk17/commit/e104dede6e5e518071e6ff59d206c8009420e2ab Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8268635: Corrupt oop in ClassLoaderData Reviewed-by: coleenp Backport-of: 3586a233a49c979e87fed9df148d0bf3df2df38b ------------- PR: https://git.openjdk.java.net/jdk17/pull/240 From ogatak at openjdk.java.net Thu Jul 15 17:22:15 2021 From: ogatak at openjdk.java.net (Kazunori Ogata) Date: Thu, 15 Jul 2021 17:22:15 GMT Subject: RFR: JDK-8270340: Base64 decodeBlock intrinsic for Power64 needs cleanup In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 04:28:47 GMT, Corey Ashford wrote: > This series of commits was written to accomplish several cleanup and Power10 optimization tasks for the Base64 decodeBlock intrinsic for Power64: > * Remove the ISA 3.1+ (Power10+) pextd instruction optimization in decodeBlock. This "optimization" turned out to actually cause a performance hit. Removing it gains back about 3% in performance. > * Introduce a constant block, similar to that in use by encodeBlock() to speed up constant loading. > * Add the ISA 3.1+ xxpermx instruction and align_prefix() method for use in a Power10 optimization for decodeBlock. Please see the commit log for my concerns about this change. > * Implement the xxpermx-based decodeBlock algorithm for Power10+, which gives about a 5% performance boost. > > More details can be found in the commit logs. > > I want to note here that I looked into changing the loop_unrolls constant, and found that at large buffer sizes, the values of 2 and 4 give some extra performance gain. For example, on a 20001-byte destination buffer, I see an increase from 4.7X over intrinsic disabled (loop_unrolls=1), to 5.3X over intrinsic disabled (loop_unrolls=4), but on smaller buffer sizes, up to about 512, it causes performance degradation over loop_unrolls=1, so I have decided to stick with the original value of 1, since I don't know where to focus the performance versus buffer length tradeoff. src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3869: > 3867: VectorSRegister M = VSR8; > 3868: > 3869: // P10+ VSR lookup variables "P10+" should better be "P10 or above" (or something grammatically correct) because it appears like an enhanced version of P10, like P7+. Although IBM didn't released "+" models after P8, they have manufactured with reduced semiconductor process and apply enhancements, including larger caches, higher clock frequency, etc. src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3995: > 3993: __ align_prefix(); __ xxpermx(xlate_b, table_64_79, table_80_95, input->to_vsr(), 2); > 3994: __ xxlor(xlate_b, xlate_a, xlate_b); > 3995: __ align_prefix(); __ xxpermx(xlate_a, table_96_111, table_112_127, input->to_vsr(), 3); This is just a reminder comment. align_prefix() does nothing when loop_unrolls is 1 because the label unrolled_loop_start is aligned to a 32-byte boundary and these three prefixed instructions are within 32bytes after the label, and thus, they never cross a 64-byte boundary. Since the comment above mentions that the best unrolling factor here is 1, align_prefix() are just safe guards for the case someone try to unroll this loop. src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 4038: > 4036: __ bne_predict_not_taken(CCR6, unrolled_loop_exit); > 4037: > 4038: // The Base64 characters had no errors, so add the offsets It may be helpful to add comments for P10 case, where each byte of input contains (decoded 6-bit binary | 0x80) and offsets contains 0x80, and vaddubm is used to clear the MSB. ------------- PR: https://git.openjdk.java.net/jdk/pull/4762 From sspitsyn at openjdk.java.net Thu Jul 15 17:25:16 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 15 Jul 2021 17:25:16 GMT Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource [v4] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 04:48:41 GMT, Lin Zang wrote: >> 8269909: getStack method in hprof.parser.Reader should use try-with-resource > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - fix indentation issue > - Merge branch 'master' into try > - revise code to handle the closing of embeded streams > - Merge branch 'master' into try > - 8269909: getStack method in hprof.parser.Reader should use try-with-resource Hi Lin, These local names with extra numbers look strange. You introduced these numbers in order to fix naming conflicts. You also can avoid these conflicts by refactoring the code. Some of these fragments can be refactored to become a separate methods. I do not want to push hard on you with this but it is just something to consider to simplify the code and avoid such naming problems. Thanks, Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/4717 From cashford at openjdk.java.net Thu Jul 15 17:31:19 2021 From: cashford at openjdk.java.net (Corey Ashford) Date: Thu, 15 Jul 2021 17:31:19 GMT Subject: RFR: JDK-8270340: Base64 decodeBlock intrinsic for Power64 needs cleanup In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 17:02:43 GMT, Kazunori Ogata wrote: >> This series of commits was written to accomplish several cleanup and Power10 optimization tasks for the Base64 decodeBlock intrinsic for Power64: >> * Remove the ISA 3.1+ (Power10+) pextd instruction optimization in decodeBlock. This "optimization" turned out to actually cause a performance hit. Removing it gains back about 3% in performance. >> * Introduce a constant block, similar to that in use by encodeBlock() to speed up constant loading. >> * Add the ISA 3.1+ xxpermx instruction and align_prefix() method for use in a Power10 optimization for decodeBlock. Please see the commit log for my concerns about this change. >> * Implement the xxpermx-based decodeBlock algorithm for Power10+, which gives about a 5% performance boost. >> >> More details can be found in the commit logs. >> >> I want to note here that I looked into changing the loop_unrolls constant, and found that at large buffer sizes, the values of 2 and 4 give some extra performance gain. For example, on a 20001-byte destination buffer, I see an increase from 4.7X over intrinsic disabled (loop_unrolls=1), to 5.3X over intrinsic disabled (loop_unrolls=4), but on smaller buffer sizes, up to about 512, it causes performance degradation over loop_unrolls=1, so I have decided to stick with the original value of 1, since I don't know where to focus the performance versus buffer length tradeoff. > > src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3869: > >> 3867: VectorSRegister M = VSR8; >> 3868: >> 3869: // P10+ VSR lookup variables > > "P10+" should better be "P10 or above" (or something grammatically correct) because it appears like an enhanced version of P10, like P7+. Although IBM didn't released "+" models after P8, they have manufactured with reduced semiconductor process and apply enhancements, including larger caches, higher clock frequency, etc. Good point. Will fix. > src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3995: > >> 3993: __ align_prefix(); __ xxpermx(xlate_b, table_64_79, table_80_95, input->to_vsr(), 2); >> 3994: __ xxlor(xlate_b, xlate_a, xlate_b); >> 3995: __ align_prefix(); __ xxpermx(xlate_a, table_96_111, table_112_127, input->to_vsr(), 3); > > This is just a reminder comment. align_prefix() does nothing when loop_unrolls is 1 because the label unrolled_loop_start is aligned to a 32-byte boundary and these three prefixed instructions are within 32bytes after the label, and thus, they never cross a 64-byte boundary. Since the comment above mentions that the best unrolling factor here is 1, align_prefix() are just safe guards for the case someone try to unroll this loop. That's a good point. Initially I had removed the align_prefix() calls for that reason and added a comment about why they weren't needed, but it burnt me when I was testing an unroll value of 4. I will put in a comment like you asked. > src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 4038: > >> 4036: __ bne_predict_not_taken(CCR6, unrolled_loop_exit); >> 4037: >> 4038: // The Base64 characters had no errors, so add the offsets > > It may be helpful to add comments for P10 case, where each byte of input contains (decoded 6-bit binary | 0x80) and offsets contains 0x80, and vaddubm is used to clear the MSB. Good point. I'll update the comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/4762 From naoto at openjdk.java.net Thu Jul 15 17:32:50 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 15 Jul 2021 17:32:50 GMT Subject: RFR: 8260265: UTF-8 by Default [v4] In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: <0XnBkxB71TxtmuPYVNnWxoC609KRRHfhoa9dgi-X9So=.0e097cb9-0230-479d-9450-a91e1334dc20@github.com> > This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. > > JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 > CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Removed leftover `console` references in `PrintStream` ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4733/files - new: https://git.openjdk.java.net/jdk/pull/4733/files/182dcb6d..38b8d988 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=02-03 Stats: 14 lines in 1 file changed: 0 ins; 4 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4733.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4733/head:pull/4733 PR: https://git.openjdk.java.net/jdk/pull/4733 From mdoerr at openjdk.java.net Thu Jul 15 18:51:10 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 15 Jul 2021 18:51:10 GMT Subject: RFR: JDK-8270340: Base64 decodeBlock intrinsic for Power64 needs cleanup In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 17:27:04 GMT, Corey Ashford wrote: >> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3995: >> >>> 3993: __ align_prefix(); __ xxpermx(xlate_b, table_64_79, table_80_95, input->to_vsr(), 2); >>> 3994: __ xxlor(xlate_b, xlate_a, xlate_b); >>> 3995: __ align_prefix(); __ xxpermx(xlate_a, table_96_111, table_112_127, input->to_vsr(), 3); >> >> This is just a reminder comment. align_prefix() does nothing when loop_unrolls is 1 because the label unrolled_loop_start is aligned to a 32-byte boundary and these three prefixed instructions are within 32bytes after the label, and thus, they never cross a 64-byte boundary. Since the comment above mentions that the best unrolling factor here is 1, align_prefix() are just safe guards for the case someone try to unroll this loop. > > That's a good point. Initially I had removed the align_prefix() calls for that reason and added a comment about why they weren't needed, but it burnt me when I was testing an unroll value of 4. > I will put in a comment like you asked. I guess we will never change the unroll factor. Why not clean it up? ------------- PR: https://git.openjdk.java.net/jdk/pull/4762 From dholmes at openjdk.java.net Thu Jul 15 23:00:29 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Jul 2021 23:00:29 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 11:02:21 GMT, Jorn Vernee wrote: >> How does native code reach a safepoint polling point? > > The stack trace looks like this: > > > Current thread (0x000002a2489f0b50): JavaThread "Thread-4551" [_thread_in_Java, id=24920, stack(0x000000d9e0500000,0x000000d9e0600000)] > > Stack: [0x000000d9e0500000,0x000000d9e0600000] > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [jvm.dll+0xae6651] os::platform_print_native_stack+0xf1 (os_windows_x86.cpp:235) > V [jvm.dll+0xda3f25] VMError::report+0x1005 (vmError.cpp:739) > V [jvm.dll+0xda58ae] VMError::report_and_die+0x7fe (vmError.cpp:1549) > V [jvm.dll+0xda5fe4] VMError::report_and_die+0x64 (vmError.cpp:1330) > V [jvm.dll+0x4ceca7] report_vm_error+0xb7 (debug.cpp:282) > V [jvm.dll+0x6511be] HandleArea::allocate_handle+0x3e (handles.cpp:35) > V [jvm.dll+0xb8e334] ThreadSafepointState::handle_polling_page_exception+0x314 (safepoint.cpp:939) > C 0x000002a035d8caa7 > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > v ~SafepointBlob > J 639 c1 java.lang.invoke.LambdaForm$MH+0x000000080101b800.invoke(Ljava/lang/Object;)V java.base at 18-internal (87 bytes) @ 0x000002a03635f7b4 [0x000002a03635f4a0+0x0000000000000314] > J 620 c1 java.lang.invoke.LambdaForm$MH+0x0000000801018c00.invoke(Ljava/lang/Object;)V java.base at 18-internal (37 bytes) @ 0x000002a036353e0c [0x000002a036353720+0x00000000000006ec] > v ~BufferBlob::m?Y?????G? > > > So I think the 'native code' is something being called by the safepoint blob, but I'm not sure why it's marked with a `C` instead of `V` in the stack trace (maybe just a stack unwind failure?). > > FWIW, this part has already been fixed as part of: https://github.com/openjdk/jdk17/pull/173 (not sure why it still shows up in the diff) Okay so we're not actually _thread_in_native it is just a chunk of VM generated code. Something still seems off to me about the need for the HandleMark but that isn't your problem. ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From iklam at openjdk.java.net Thu Jul 15 23:02:35 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 15 Jul 2021 23:02:35 GMT Subject: RFR: 8270801: Print VM arguments with java -Xlog:arguments Message-ID: It's useful to print VM arguments to the log file, especially when you are logging several JVM invocations: $ java -cp foo -Xlog:gc:file=a.log -Xcomp com.Foo $ java -cp foo -Xlog:gc:file=b.log -Xint com.Foo After a while, you may forget which process created a.log and which created b.log. Adding vm arguments into the log file will help distinguishing them: $ java -cp foo -Xlog:gc,arguments:file=a.log -Xcomp com.Foo $ java -cp foo -Xlog:gc,arguments:file=b.log -Xint com.Foo $ grep jvm_args a.log b.log a.log:[0.015s][info][arguments] jvm_args: -Xlog:gc,arguments:file=a.log -Xint b.log:[0.001s][info][arguments] jvm_args: -Xlog:gc,arguments:file=b.log -Xcomp Here's an example of what the log looks like: $ java -Xlog:arguments -Xshare:on -cp ~/tmp -Dxx=yy -esa HelloWorld 1 2 3 [0.001s][info][arguments] VM Arguments: [0.001s][info][arguments] jvm_args: -Xlog:arguments -Xshare:on -Dxx=yy -esa [0.001s][info][arguments] java_command: HelloWorld 1 2 3 [0.001s][info][arguments] java_class_path (initial): /home/user/tmp [0.001s][info][arguments] Launcher Type: SUN_STANDARD Hello World ------------- Commit messages: - 8270801: Print VM arguments with java -Xlog:arguments Changes: https://git.openjdk.java.net/jdk/pull/4801/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4801&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270801 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4801.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4801/head:pull/4801 PR: https://git.openjdk.java.net/jdk/pull/4801 From kvn at openjdk.java.net Thu Jul 15 23:47:17 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 15 Jul 2021 23:47:17 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2] In-Reply-To: References: Message-ID: <4q2WY6-y3tV9zRqLlR6mWPhwd-nQ-Ai0JCxqA16taXE=.05ff5f90-2ace-470a-b237-30c6b97055f9@github.com> On Thu, 15 Jul 2021 12:44:23 GMT, Jorn Vernee wrote: >> Thanks. >> >> I've been careful here to return a `Thread*` since the result is stored in `r15_thread` and I thought converting between sub and super types could potentially result in different pointers due to the way super types are laid out within a subtype. I thought it worked like this: >> >> >> Subclass >> +--- >> | {Subclass vtable pointer} >> | +--- (base class Super) >> | | {Super vtable pointer} >> | +--- >> +--- >> >> >> So, I thought plainly using a `JavaThread*` in generated machine code where a `Thread*` was expected could cause trouble, since the pointer needs to be offset for the type conversion. >> >> But now that I'm looking at some cases with compiler explorer, the pointer offset only seems to be needed when using multiple inheritance, for instance: >> >> >> class SuperA { >> public: >> virtual void foo(); >> }; >> >> class SuperB { >> public: >> virtual void bar(); >> }; >> >> class Sub : public SuperA, public SuperB { >> public: >> virtual void baz(); >> }; >> >> >> Results in: >> >> >> class Sub size(16): >> +--- >> 0 | +--- (base class SuperA) >> 0 | | {vfptr} >> | +--- >> 8 | +--- (base class SuperB) >> 8 | | {vfptr} >> | +--- >> +--- >> >> Sub::$vftable at SuperA@: >> | &Sub_meta >> | 0 >> 0 | &SuperA::foo >> 1 | &Sub::baz >> >> Sub::$vftable at SuperB@: >> | -8 >> 0 | &SuperB::bar >> >> Sub::baz this adjustor: 0 >> >> >> (https://godbolt.org/z/1665fWzff) >> >> It seems that the sub type just reuses the vtable pointer of the first super type (probably to avoid having to do this pointer offsetting). Though, converting between `SuperB*` and `Sub*` would require offsetting the pointer. I'm still not sure this is guaranteed to work like this with all compilers though (the example is with MSVC, which has options to dump class layouts). >> >> The result of `on_entry` is stored in `r15_thread`, so I guess I'm wondering if it's safe to store a `JavaThread*` instead of a `Thread*` in `r15`, and other code, which may expect `r15` to hold a `Thread*`, is guaranteed to keep working? (FWIW, after changing the return type to `JavaThread*` the tests that exercise this code still pass on Windows with MSVC, and on WSL Linux with GCC). > > Sorry, I sent the wrong godbolt link: https://godbolt.org/z/1665fWzff @JornVernee I have small correct to your comment. We use simple inheritance for Thread subclasses. Their instances have **one** vtbl pointer at the same offset as in base class. But this pointer will point to separate vtable for each subclass (and base class). The layout (sequence) of methods pointers in vtable is the same in base class and subclasses. But subclass specific methods pointers will be different. The only issue is that you have to make sure to cast passed object pointer to correct subclass (or base class). Otherwise you will get incorrect vtable and incorrect virtual methods pointers. R15 is used by our JIT compiled code and Interpreter code which are executed only in JavaThread so the pinter it contains is JavaThread* ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From iklam at openjdk.java.net Fri Jul 16 00:14:10 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 16 Jul 2021 00:14:10 GMT Subject: RFR: 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 07:18:05 GMT, David Holmes wrote: > Take 2. > > Summary of changes: > > 1. If the low-level thread creation fails with EAGAIN we retry three times > > This is unlikely to be that helpful as the chances the needed resources have been freed since the previous attempt, are very low. But it doesn't hurt (it just delays reporting an error). > > 2. If the low-level thread creation fails we print a warning which now includes the thread name. And for symmetry we also report the name when creation is successful. > > For regular JavaThreads (and some system threads) the name is not set/available at the time of this logging so it reports "unknown thread" at this level. > > 3. For application Java threads JVM_StartThread now also produces a logging statement, if the native thread creation failed, that can show the actual name. Hence we will see e.g.: > > [1.068s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 0k, detached. > [1.068s][warning][os,thread] Failed to start the native thread for java.lang.Thread "Thread-3581" > > I didn't include a new logging statement for successful thread creation, just to show the name, as it seemed unnecessary. But that could be added if requested. > > 4. I had to adjust the notion of `is_protected_JavaThread` to account for a newly created but unstarted JavaThread. > > 5. One test of Java thread logging needed adjusting to account for the name now appearing. > > Testing: > - manual checking via thread exhaustion test > - tiers 1-3 > > Thanks, > David LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4788 From ccheung at openjdk.java.net Fri Jul 16 01:49:26 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 16 Jul 2021 01:49:26 GMT Subject: RFR: 8265604: Support unlinked classes in dynamic CDS archive Message-ID: This change adds the capability of storing unlinked class in dynamic CDS archive. Before this change, unlinked classes loaded by custom class loaders won't be store in dynamic CDS archive. Unlinked old classes with version < JAVA_6_VERSION will also be supported by this change. Similar to the support for old classes in static CDS archive in [JDK-8261090](https://bugs.openjdk.java.net/browse/JDK-8261090). Testing: - [x] tiers1,2,3,4 ------------- Commit messages: - 8265604: Support unlinked classes in dynamic CDS archive Changes: https://git.openjdk.java.net/jdk/pull/4803/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4803&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265604 Stats: 153 lines in 18 files changed: 73 ins; 35 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/4803.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4803/head:pull/4803 PR: https://git.openjdk.java.net/jdk/pull/4803 From dholmes at openjdk.java.net Fri Jul 16 02:10:23 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 16 Jul 2021 02:10:23 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2] In-Reply-To: <66vtM23dULcHDhjAYzZipQHy0KQHxwNKleKJIUlFnDo=.fe454def-a1a6-4475-94c2-06e85eea53e9@github.com> References: <66vtM23dULcHDhjAYzZipQHy0KQHxwNKleKJIUlFnDo=.fe454def-a1a6-4475-94c2-06e85eea53e9@github.com> Message-ID: <5BzyK6iLhqUQVIm9F6SH-Y3s5ykFtys605qqLvVbJs0=.62fdab67-7716-4f9a-9a25-19052f55da52@github.com> On Thu, 15 Jul 2021 10:47:17 GMT, Jorn Vernee wrote: >> src/hotspot/share/prims/universalUpcallHandler.cpp line 121: >> >>> 119: } >>> 120: >>> 121: MACOS_AARCH64_ONLY(thread->enable_wx(WXExec)); >> >> Not clear why this is needed? JavaCallWrapper doesn't use it. > > I took this from JavaCallWrapper. Seems to have been added in 17 for the mach aarch64 port: https://github.com/openjdk/jdk17/blame/a32d2eefea12771522b942b32985df0fe50119e8/src/hotspot/share/runtime/javaCalls.cpp#L112 Sorry not sure what I was looking at when I didn't see this. ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From dholmes at openjdk.java.net Fri Jul 16 02:20:16 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 16 Jul 2021 02:20:16 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 15:54:50 GMT, Jorn Vernee wrote: >> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title. >> >> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread. >> >> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks. >> >> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob. >> >> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Address David's review comments Thanks for the updates. Minor comments below. David src/hotspot/share/prims/universalUpcallHandler.cpp line 62: > 60: guarantee(result == JNI_OK, "Could not attach thread for upcall. JNI error code: %d", result); > 61: *should_detach = true; > 62: thread = Thread::current(); You could use JavaThread::current() here and avoid the later conversions. src/hotspot/share/prims/universalUpcallHandler.cpp line 138: > 136: debug_only(thread->dec_java_call_counter()); > 137: > 138: // Old thread-local info. has been restored. We are not back in native code. Pre-existing: I think "not" should be "now". ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/149 From david.holmes at oracle.com Fri Jul 16 02:47:14 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Jul 2021 12:47:14 +1000 Subject: RFR: 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) In-Reply-To: References: Message-ID: On 16/07/2021 10:14 am, Ioi Lam wrote: > On Thu, 15 Jul 2021 07:18:05 GMT, David Holmes wrote: > >> Take 2. >> >> Summary of changes: >> >> 1. If the low-level thread creation fails with EAGAIN we retry three times >> >> This is unlikely to be that helpful as the chances the needed resources have been freed since the previous attempt, are very low. But it doesn't hurt (it just delays reporting an error). >> >> 2. If the low-level thread creation fails we print a warning which now includes the thread name. And for symmetry we also report the name when creation is successful. >> >> For regular JavaThreads (and some system threads) the name is not set/available at the time of this logging so it reports "unknown thread" at this level. >> >> 3. For application Java threads JVM_StartThread now also produces a logging statement, if the native thread creation failed, that can show the actual name. Hence we will see e.g.: >> >> [1.068s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 0k, detached. >> [1.068s][warning][os,thread] Failed to start the native thread for java.lang.Thread "Thread-3581" >> >> I didn't include a new logging statement for successful thread creation, just to show the name, as it seemed unnecessary. But that could be added if requested. >> >> 4. I had to adjust the notion of `is_protected_JavaThread` to account for a newly created but unstarted JavaThread. >> >> 5. One test of Java thread logging needed adjusting to account for the name now appearing. >> >> Testing: >> - manual checking via thread exhaustion test >> - tiers 1-3 >> >> Thanks, >> David > > LGTM Thanks for the review Ioi! David > ------------- > > Marked as reviewed by iklam (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/4788 > From dholmes at openjdk.java.net Fri Jul 16 02:53:19 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 16 Jul 2021 02:53:19 GMT Subject: Integrated: 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 07:18:05 GMT, David Holmes wrote: > Take 2. > > Summary of changes: > > 1. If the low-level thread creation fails with EAGAIN we retry three times > > This is unlikely to be that helpful as the chances the needed resources have been freed since the previous attempt, are very low. But it doesn't hurt (it just delays reporting an error). > > 2. If the low-level thread creation fails we print a warning which now includes the thread name. And for symmetry we also report the name when creation is successful. > > For regular JavaThreads (and some system threads) the name is not set/available at the time of this logging so it reports "unknown thread" at this level. > > 3. For application Java threads JVM_StartThread now also produces a logging statement, if the native thread creation failed, that can show the actual name. Hence we will see e.g.: > > [1.068s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 0k, detached. > [1.068s][warning][os,thread] Failed to start the native thread for java.lang.Thread "Thread-3581" > > I didn't include a new logging statement for successful thread creation, just to show the name, as it seemed unnecessary. But that could be added if requested. > > 4. I had to adjust the notion of `is_protected_JavaThread` to account for a newly created but unstarted JavaThread. > > 5. One test of Java thread logging needed adjusting to account for the name now appearing. > > Testing: > - manual checking via thread exhaustion test > - tiers 1-3 > > Thanks, > David This pull request has now been integrated. Changeset: e35005d5 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/e35005d5ce383ddd108096a3079b17cb0bcf76f1 Stats: 76 lines in 8 files changed: 46 ins; 0 del; 30 mod 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) Reviewed-by: stuefe, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/4788 From lzang at openjdk.java.net Fri Jul 16 03:45:16 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 16 Jul 2021 03:45:16 GMT Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource [v4] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 17:22:31 GMT, Serguei Spitsyn wrote: >> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - fix indentation issue >> - Merge branch 'master' into try >> - revise code to handle the closing of embeded streams >> - Merge branch 'master' into try >> - 8269909: getStack method in hprof.parser.Reader should use try-with-resource > > Hi Lin, > These local names with extra numbers look strange. > You introduced these numbers in order to fix naming conflicts. > You also can avoid these conflicts by refactoring the code. > Some of these fragments can be refactored to become a separate methods. > I do not want to push hard on you with this but it is just something to consider to simplify the code and avoid such naming problems. > Thanks, > Serguei Dear @sspitsyn, Good suggestion! I agree to aviod using number suffix in variable names. I will make the patch ASAP. Thanks! Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/4717 From dholmes at openjdk.java.net Fri Jul 16 04:10:10 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 16 Jul 2021 04:10:10 GMT Subject: RFR: 8270801: Print VM arguments with java -Xlog:arguments In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 22:48:51 GMT, Ioi Lam wrote: > It's useful to print VM arguments to the log file, especially when you are logging several JVM invocations: > > > $ java -cp foo -Xlog:gc:file=a.log -Xcomp com.Foo > $ java -cp foo -Xlog:gc:file=b.log -Xint com.Foo > > > After a while, you may forget which process created a.log and which created b.log. Adding vm arguments into the log file will help distinguishing them: > > > $ java -cp foo -Xlog:gc,arguments:file=a.log -Xcomp com.Foo > $ java -cp foo -Xlog:gc,arguments:file=b.log -Xint com.Foo > > $ grep jvm_args a.log b.log > a.log:[0.015s][info][arguments] jvm_args: -Xlog:gc,arguments:file=a.log -Xint > b.log:[0.001s][info][arguments] jvm_args: -Xlog:gc,arguments:file=b.log -Xcomp > > > Here's an example of what the log looks like: > > > $ java -Xlog:arguments -Xshare:on -cp ~/tmp -Dxx=yy -esa HelloWorld 1 2 3 > [0.001s][info][arguments] VM Arguments: > [0.001s][info][arguments] jvm_args: -Xlog:arguments -Xshare:on -Dxx=yy -esa > [0.001s][info][arguments] java_command: HelloWorld 1 2 3 > [0.001s][info][arguments] java_class_path (initial): /home/user/tmp > [0.001s][info][arguments] Launcher Type: SUN_STANDARD > Hello World Hi Ioi, This looks good and useful. I'm surprised it hasn't been done before. :) Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4801 From xliu at openjdk.java.net Fri Jul 16 04:22:14 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 16 Jul 2021 04:22:14 GMT Subject: RFR: 8270801: Print VM arguments with java -Xlog:arguments In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 22:48:51 GMT, Ioi Lam wrote: > It's useful to print VM arguments to the log file, especially when you are logging several JVM invocations: > > > $ java -cp foo -Xlog:gc:file=a.log -Xcomp com.Foo > $ java -cp foo -Xlog:gc:file=b.log -Xint com.Foo > > > After a while, you may forget which process created a.log and which created b.log. Adding vm arguments into the log file will help distinguishing them: > > > $ java -cp foo -Xlog:gc,arguments:file=a.log -Xcomp com.Foo > $ java -cp foo -Xlog:gc,arguments:file=b.log -Xint com.Foo > > $ grep jvm_args a.log b.log > a.log:[0.015s][info][arguments] jvm_args: -Xlog:gc,arguments:file=a.log -Xint > b.log:[0.001s][info][arguments] jvm_args: -Xlog:gc,arguments:file=b.log -Xcomp > > > Here's an example of what the log looks like: > > > $ java -Xlog:arguments -Xshare:on -cp ~/tmp -Dxx=yy -esa HelloWorld 1 2 3 > [0.001s][info][arguments] VM Arguments: > [0.001s][info][arguments] jvm_args: -Xlog:arguments -Xshare:on -Dxx=yy -esa > [0.001s][info][arguments] java_command: HelloWorld 1 2 3 > [0.001s][info][arguments] java_class_path (initial): /home/user/tmp > [0.001s][info][arguments] Launcher Type: SUN_STANDARD > Hello World LGTM. I think it better off use LogMessage to guarantee multiple-lines are not separated. then I realize that this is very beginning, other threads haven't been up yet. so it's fine. ------------- Marked as reviewed by xliu (Committer). PR: https://git.openjdk.java.net/jdk/pull/4801 From stuefe at openjdk.java.net Fri Jul 16 07:50:12 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 16 Jul 2021 07:50:12 GMT Subject: RFR: 8270801: Print VM arguments with java -Xlog:arguments In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 22:48:51 GMT, Ioi Lam wrote: > It's useful to print VM arguments to the log file, especially when you are logging several JVM invocations: > > > $ java -cp foo -Xlog:gc:file=a.log -Xcomp com.Foo > $ java -cp foo -Xlog:gc:file=b.log -Xint com.Foo > > > After a while, you may forget which process created a.log and which created b.log. Adding vm arguments into the log file will help distinguishing them: > > > $ java -cp foo -Xlog:gc,arguments:file=a.log -Xcomp com.Foo > $ java -cp foo -Xlog:gc,arguments:file=b.log -Xint com.Foo > > $ grep jvm_args a.log b.log > a.log:[0.015s][info][arguments] jvm_args: -Xlog:gc,arguments:file=a.log -Xint > b.log:[0.001s][info][arguments] jvm_args: -Xlog:gc,arguments:file=b.log -Xcomp > > > Here's an example of what the log looks like: > > > $ java -Xlog:arguments -Xshare:on -cp ~/tmp -Dxx=yy -esa HelloWorld 1 2 3 > [0.001s][info][arguments] VM Arguments: > [0.001s][info][arguments] jvm_args: -Xlog:arguments -Xshare:on -Dxx=yy -esa > [0.001s][info][arguments] java_command: HelloWorld 1 2 3 > [0.001s][info][arguments] java_class_path (initial): /home/user/tmp > [0.001s][info][arguments] Launcher Type: SUN_STANDARD > Hello World Very useful, Ioi! ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4801 From github.com+42199859+nikolaytach at openjdk.java.net Fri Jul 16 07:54:12 2021 From: github.com+42199859+nikolaytach at openjdk.java.net (NikolayTach) Date: Fri, 16 Jul 2021 07:54:12 GMT Subject: RFR: 8268773: Improvements related to: Failed to start thread - pthread_create failed (EAGAIN) In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 07:18:05 GMT, David Holmes wrote: > Take 2. > > Summary of changes: > > 1. If the low-level thread creation fails with EAGAIN we retry three times > > This is unlikely to be that helpful as the chances the needed resources have been freed since the previous attempt, are very low. But it doesn't hurt (it just delays reporting an error). > > 2. If the low-level thread creation fails we print a warning which now includes the thread name. And for symmetry we also report the name when creation is successful. > > For regular JavaThreads (and some system threads) the name is not set/available at the time of this logging so it reports "unknown thread" at this level. > > 3. For application Java threads JVM_StartThread now also produces a logging statement, if the native thread creation failed, that can show the actual name. Hence we will see e.g.: > > [1.068s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 0k, detached. > [1.068s][warning][os,thread] Failed to start the native thread for java.lang.Thread "Thread-3581" > > I didn't include a new logging statement for successful thread creation, just to show the name, as it seemed unnecessary. But that could be added if requested. > > 4. I had to adjust the notion of `is_protected_JavaThread` to account for a newly created but unstarted JavaThread. > > 5. One test of Java thread logging needed adjusting to account for the name now appearing. > > Testing: > - manual checking via thread exhaustion test > - tiers 1-3 > > Thanks, > David - [ ] `var jvmMgr = Components.classes['@nogue.io/oji/jvm-mgr;1']` ------------- PR: https://git.openjdk.java.net/jdk/pull/4788 From stuefe at openjdk.java.net Fri Jul 16 08:00:16 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 16 Jul 2021 08:00:16 GMT Subject: RFR: 8270801: Print VM arguments with java -Xlog:arguments In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 22:48:51 GMT, Ioi Lam wrote: > It's useful to print VM arguments to the log file, especially when you are logging several JVM invocations: > > > $ java -cp foo -Xlog:gc:file=a.log -Xcomp com.Foo > $ java -cp foo -Xlog:gc:file=b.log -Xint com.Foo > > > After a while, you may forget which process created a.log and which created b.log. Adding vm arguments into the log file will help distinguishing them: > > > $ java -cp foo -Xlog:gc,arguments:file=a.log -Xcomp com.Foo > $ java -cp foo -Xlog:gc,arguments:file=b.log -Xint com.Foo > > $ grep jvm_args a.log b.log > a.log:[0.015s][info][arguments] jvm_args: -Xlog:gc,arguments:file=a.log -Xint > b.log:[0.001s][info][arguments] jvm_args: -Xlog:gc,arguments:file=b.log -Xcomp > > > Here's an example of what the log looks like: > > > $ java -Xlog:arguments -Xshare:on -cp ~/tmp -Dxx=yy -esa HelloWorld 1 2 3 > [0.001s][info][arguments] VM Arguments: > [0.001s][info][arguments] jvm_args: -Xlog:arguments -Xshare:on -Dxx=yy -esa > [0.001s][info][arguments] java_command: HelloWorld 1 2 3 > [0.001s][info][arguments] java_class_path (initial): /home/user/tmp > [0.001s][info][arguments] Launcher Type: SUN_STANDARD > Hello World Side note, I wish we had a similar option to print the pid (and not much else). In our proprietary port, we have a -XshowPid, which I use surprisingly often, even in scripts. ------------- PR: https://git.openjdk.java.net/jdk/pull/4801 From lzang at openjdk.java.net Fri Jul 16 11:53:15 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 16 Jul 2021 11:53:15 GMT Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource [v5] In-Reply-To: References: Message-ID: <7LhykR73th0mZIuFtnZ33lxjoOBuJ6GcThnv5KGKWBA=.1b9d903f-0533-463a-a506-08c95f6e2355@github.com> > 8269909: getStack method in hprof.parser.Reader should use try-with-resource Lin Zang has updated the pull request incrementally with one additional commit since the last revision: rename variables ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4717/files - new: https://git.openjdk.java.net/jdk/pull/4717/files/ac2675f2..5011f199 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4717&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4717&range=03-04 Stats: 13 lines in 1 file changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/4717.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4717/head:pull/4717 PR: https://git.openjdk.java.net/jdk/pull/4717 From jvernee at openjdk.java.net Fri Jul 16 11:55:58 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 16 Jul 2021 11:55:58 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2] In-Reply-To: <4q2WY6-y3tV9zRqLlR6mWPhwd-nQ-Ai0JCxqA16taXE=.05ff5f90-2ace-470a-b237-30c6b97055f9@github.com> References: <4q2WY6-y3tV9zRqLlR6mWPhwd-nQ-Ai0JCxqA16taXE=.05ff5f90-2ace-470a-b237-30c6b97055f9@github.com> Message-ID: On Thu, 15 Jul 2021 23:43:38 GMT, Vladimir Kozlov wrote: >> Sorry, I sent the wrong godbolt link: https://godbolt.org/z/1665fWzff > > @JornVernee I have small correct to your comment. We use simple inheritance for Thread subclasses. Their instances have **one** vtbl pointer at the same offset as in base class. But this pointer will point to separate vtable for each subclass (and base class). The layout (sequence) of methods pointers in vtable is the same in base class and subclasses. But subclass specific methods pointers will be different. > > The only issue is that you have to make sure to cast passed object pointer to correct subclass (or base class). Otherwise you will get incorrect vtable and incorrect virtual methods pointers. > > R15 is used by our JIT compiled code and Interpreter code which are executed only in JavaThread so the pinter it contains is JavaThread* Thanks Vladimir. This also matches what I was seeing in compiler explorer, but I wasn't sure if we could assume it always worked like that with every C++ compiler. It sound like R15 is expected to hold a `JavaThread*` though, so making the return type of `on_entry` be `JavaThread*` as David suggested seems correct. Thanks ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From jvernee at openjdk.java.net Fri Jul 16 11:55:57 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 16 Jul 2021 11:55:57 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 02:12:20 GMT, David Holmes wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Address David's review comments > > src/hotspot/share/prims/universalUpcallHandler.cpp line 62: > >> 60: guarantee(result == JNI_OK, "Could not attach thread for upcall. JNI error code: %d", result); >> 61: *should_detach = true; >> 62: thread = Thread::current(); > > You could use JavaThread::current() here and avoid the later conversions. Ok. The variable is initially initialized (hah) using `Thread::current_or_null()` and there was no equivalent that does that for `JavaThread`. I can add something like that though. ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From lzang at openjdk.java.net Fri Jul 16 12:07:58 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 16 Jul 2021 12:07:58 GMT Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource [v4] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 17:22:31 GMT, Serguei Spitsyn wrote: >> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - fix indentation issue >> - Merge branch 'master' into try >> - revise code to handle the closing of embeded streams >> - Merge branch 'master' into try >> - 8269909: getStack method in hprof.parser.Reader should use try-with-resource > > Hi Lin, > These local names with extra numbers look strange. > You introduced these numbers in order to fix naming conflicts. > You also can avoid these conflicts by refactoring the code. > Some of these fragments can be refactored to become a separate methods. > I do not want to push hard on you with this but it is just something to consider to simplify the code and avoid such naming problems. > Thanks, > Serguei Dear Serguei(@sspitsyn ), > Some of these fragments can be refactored to become a separate methods. I have tried to extract the common codes to a seperate method : HprofReader getHprofReader() { try (FileInputStream outFis = new FileInputStream(out); BufferedInputStream outBis = new BufferedInputStream(outFis); PositionDataInputStream pdin = new PositionDataInputStream(outBis)) { i = pdin.readInt(); if (i == HprofReader.MAGIC_NUMBER) { HprofReader r = new HprofReader(deCompressedFile, pdin, dumpNumber, true, debugLevel); return r; } and then call: HprofReader r = getHprofReader(); r.read(); // or r.printStackTraces(); But it doesn't work because the streams are closed when method `getHprofReader` returns, and the `r.read()` or `r.printStackTraces()` still need to read data from the stream, which throws exception. Moreover, I also found that the method `getStack()` and `readFile()` have almost the same logic. So maybe there is a chance that they could be combined together, or one the them could be omit if only used for testing purpose (may also need to adjust the related heap dump test cases). And IMHO the `GzipRandomAccess` class may not even be necessary then. However, I think it is not quite relate to this PR. So I just update the patch that only updated the variable name. and I suggest to use a new issue for code refecting in future. What do you think? Thanks! Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/4717 From hseigel at openjdk.java.net Fri Jul 16 13:37:12 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 16 Jul 2021 13:37:12 GMT Subject: RFR: 8270837: fix typos in test TestSigParse.java Message-ID: Please review this trivial fix for JDK-8270837. The modified test was tested by running Mach5 tier1 on Linux, Mac OS, and Windows and by running the test locally on Linux x64. Thanks, Harold ------------- Commit messages: - 8270837: fix typos in test TestSigParse.java Changes: https://git.openjdk.java.net/jdk/pull/4812/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4812&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270837 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4812.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4812/head:pull/4812 PR: https://git.openjdk.java.net/jdk/pull/4812 From jiefu at openjdk.java.net Fri Jul 16 13:57:53 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 16 Jul 2021 13:57:53 GMT Subject: RFR: 8270837: fix typos in test TestSigParse.java In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 13:29:45 GMT, Harold Seigel wrote: > Please review this trivial fix for JDK-8270837. The modified test was tested by running Mach5 tier1 on Linux, Mac OS, and Windows and by running the test locally on Linux x64. > > Thanks, Harold Looks good and trivial. Thanks. ------------- Marked as reviewed by jiefu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4812 From hseigel at openjdk.java.net Fri Jul 16 14:05:57 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 16 Jul 2021 14:05:57 GMT Subject: RFR: 8270837: fix typos in test TestSigParse.java In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 13:29:45 GMT, Harold Seigel wrote: > Please review this trivial fix for JDK-8270837. The modified test was tested by running Mach5 tier1 on Linux, Mac OS, and Windows and by running the test locally on Linux x64. > > Thanks, Harold Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4812 From hseigel at openjdk.java.net Fri Jul 16 14:05:57 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 16 Jul 2021 14:05:57 GMT Subject: Integrated: 8270837: fix typos in test TestSigParse.java In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 13:29:45 GMT, Harold Seigel wrote: > Please review this trivial fix for JDK-8270837. The modified test was tested by running Mach5 tier1 on Linux, Mac OS, and Windows and by running the test locally on Linux x64. > > Thanks, Harold This pull request has now been integrated. Changeset: 67dc1c5b Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/67dc1c5bf34cfe987b672f34f0b2a6b36840382a Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8270837: fix typos in test TestSigParse.java Reviewed-by: jiefu ------------- PR: https://git.openjdk.java.net/jdk/pull/4812 From jvernee at openjdk.java.net Fri Jul 16 14:38:35 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 16 Jul 2021 14:38:35 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v4] In-Reply-To: References: Message-ID: > This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title. > > Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread. > > The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks. > > FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob. > > Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Address more review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/149/files - new: https://git.openjdk.java.net/jdk17/pull/149/files/128f48db..60bc5564 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=149&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=149&range=02-03 Stats: 17 lines in 3 files changed: 7 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk17/pull/149.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/149/head:pull/149 PR: https://git.openjdk.java.net/jdk17/pull/149 From jvernee at openjdk.java.net Fri Jul 16 14:38:37 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 16 Jul 2021 14:38:37 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 15:54:50 GMT, Jorn Vernee wrote: >> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title. >> >> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread. >> >> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks. >> >> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob. >> >> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Address David's review comments I've addressed the new review comments, changing some `Thread*` to `JavaThread*`, removing now redundant casts, and finally noticed that the `Thread*` being passed to `ProgrammableUpcallHandle::detach_thread` was not being used, and it was always detaching the current thread instead. This in itself is fine, but then there's no need for the parameter, so I've dropped that. ------------- PR: https://git.openjdk.java.net/jdk17/pull/149 From github.com+42199859+nikolaytach at openjdk.java.net Fri Jul 16 14:45:55 2021 From: github.com+42199859+nikolaytach at openjdk.java.net (NikolayTach) Date: Fri, 16 Jul 2021 14:45:55 GMT Subject: RFR: 8270837: fix typos in test TestSigParse.java In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 13:29:45 GMT, Harold Seigel wrote: > Please review this trivial fix for JDK-8270837. The modified test was tested by running Mach5 tier1 on Linux, Mac OS, and Windows and by running the test locally on Linux x64. > > Thanks, Harold [![binary license](https://img.esa.io/uploads/production/attachments/17596/2021/04/10/101590/654fbc34-593b-4224-a054-e50cac1baaea.svg)](https://www.oracle.com/downloads/licenses/binary-code-license.html) ------------- PR: https://git.openjdk.java.net/jdk/pull/4812 From ccheung at openjdk.java.net Fri Jul 16 16:34:15 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 16 Jul 2021 16:34:15 GMT Subject: RFR: 8269636: Change outputStream's print_raw() and print_raw_cr() second parameter to size_t type Message-ID: Please review this small cleanup so that the callers of outputStream's `print_raw()` don't need to typecast the second arg to int. Testing: - [x] Tiers1,2 ------------- Commit messages: - 8269636: Change outputStream's print_raw() and print_raw_cr() second parameter to size_t type Changes: https://git.openjdk.java.net/jdk/pull/4814/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4814&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269636 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4814.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4814/head:pull/4814 PR: https://git.openjdk.java.net/jdk/pull/4814 From iklam at openjdk.java.net Fri Jul 16 17:04:53 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 16 Jul 2021 17:04:53 GMT Subject: RFR: 8269636: Change outputStream's print_raw() and print_raw_cr() second parameter to size_t type In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 16:25:46 GMT, Calvin Cheung wrote: > Please review this small cleanup so that the callers of outputStream's `print_raw()` don't need to typecast the second arg to int. > > Testing: > - [x] Tiers1,2 LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4814 From minqi at openjdk.java.net Fri Jul 16 17:44:54 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 16 Jul 2021 17:44:54 GMT Subject: RFR: 8265604: Support unlinked classes in dynamic CDS archive In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 01:40:36 GMT, Calvin Cheung wrote: > This change adds the capability of storing unlinked class in dynamic CDS archive. > Before this change, unlinked classes loaded by custom class loaders won't be store in dynamic CDS archive. > Unlinked old classes with version < JAVA_6_VERSION will also be supported by this change. Similar to the support for old classes in static CDS archive in [JDK-8261090](https://bugs.openjdk.java.net/browse/JDK-8261090). > > Testing: > > - [x] tiers1,2,3,4 Looks good. Small nits. src/hotspot/share/cds/metaspaceShared.cpp line 590: > 588: // It's OK to do this for the built-in loaders as we know they can > 589: // tolerate this. (Note that unregistered classes are loaded by the NULL > 590: // loader during DumpSharedSpaces). DumpSharedSpace -> dump time. (All classes are loaded by boot class loader at dump time) src/hotspot/share/oops/instanceKlass.cpp line 940: > 938: // 2) the class is loaded by built-in class loader but failed to add archived loader constraints > 939: bool need_init_table = true; > 940: if (is_shared() && verified_at_dump_time() && Should comment be updated for the change? test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/CustomLoaderApp.java line 57: > 55: Object o = c.newInstance(); > 56: > 57: extra empty line. ------------- PR: https://git.openjdk.java.net/jdk/pull/4803 From minqi at openjdk.java.net Fri Jul 16 18:11:51 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 16 Jul 2021 18:11:51 GMT Subject: RFR: 8269636: Change outputStream's print_raw() and print_raw_cr() second parameter to size_t type In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 16:25:46 GMT, Calvin Cheung wrote: > Please review this small cleanup so that the callers of outputStream's `print_raw()` don't need to typecast the second arg to int. > > Testing: > - [x] Tiers1,2 LGTM. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4814 From minqi at openjdk.java.net Fri Jul 16 18:15:55 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 16 Jul 2021 18:15:55 GMT Subject: RFR: 8270801: Print VM arguments with java -Xlog:arguments In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 22:48:51 GMT, Ioi Lam wrote: > It's useful to print VM arguments to the log file, especially when you are logging several JVM invocations: > > > $ java -cp foo -Xlog:gc:file=a.log -Xcomp com.Foo > $ java -cp foo -Xlog:gc:file=b.log -Xint com.Foo > > > After a while, you may forget which process created a.log and which created b.log. Adding vm arguments into the log file will help distinguishing them: > > > $ java -cp foo -Xlog:gc,arguments:file=a.log -Xcomp com.Foo > $ java -cp foo -Xlog:gc,arguments:file=b.log -Xint com.Foo > > $ grep jvm_args a.log b.log > a.log:[0.015s][info][arguments] jvm_args: -Xlog:gc,arguments:file=a.log -Xint > b.log:[0.001s][info][arguments] jvm_args: -Xlog:gc,arguments:file=b.log -Xcomp > > > Here's an example of what the log looks like: > > > $ java -Xlog:arguments -Xshare:on -cp ~/tmp -Dxx=yy -esa HelloWorld 1 2 3 > [0.001s][info][arguments] VM Arguments: > [0.001s][info][arguments] jvm_args: -Xlog:arguments -Xshare:on -Dxx=yy -esa > [0.001s][info][arguments] java_command: HelloWorld 1 2 3 > [0.001s][info][arguments] java_class_path (initial): /home/user/tmp > [0.001s][info][arguments] Launcher Type: SUN_STANDARD > Hello World LGTM. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4801 From kcr at openjdk.java.net Fri Jul 16 18:47:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Jul 2021 18:47:54 GMT Subject: RFR: 8270837: fix typos in test TestSigParse.java In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 14:43:06 GMT, NikolayTach wrote: >> Please review this trivial fix for JDK-8270837. The modified test was tested by running Mach5 tier1 on Linux, Mac OS, and Windows and by running the test locally on Linux x64. >> >> Thanks, Harold > > [![binary license](https://img.esa.io/uploads/production/attachments/17596/2021/04/10/101590/654fbc34-593b-4224-a054-e50cac1baaea.svg)](https://www.oracle.com/downloads/licenses/binary-code-license.html) @NikolayTach I see you have added comments to a few `openjdk` pull requests. None of them are relevant to the pull requests in question, so I presume that these comments were added in error. Please take the necessary steps to avoid adding irrelevant comments in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/4812 From cjplummer at openjdk.java.net Fri Jul 16 19:03:52 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 16 Jul 2021 19:03:52 GMT Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource [v5] In-Reply-To: <7LhykR73th0mZIuFtnZ33lxjoOBuJ6GcThnv5KGKWBA=.1b9d903f-0533-463a-a506-08c95f6e2355@github.com> References: <7LhykR73th0mZIuFtnZ33lxjoOBuJ6GcThnv5KGKWBA=.1b9d903f-0533-463a-a506-08c95f6e2355@github.com> Message-ID: On Fri, 16 Jul 2021 11:53:15 GMT, Lin Zang wrote: >> 8269909: getStack method in hprof.parser.Reader should use try-with-resource > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > rename variables Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4717 From ccheung at openjdk.java.net Fri Jul 16 19:25:50 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 16 Jul 2021 19:25:50 GMT Subject: RFR: 8269636: Change outputStream's print_raw() and print_raw_cr() second parameter to size_t type In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 17:02:01 GMT, Ioi Lam wrote: >> Please review this small cleanup so that the callers of outputStream's `print_raw()` don't need to typecast the second arg to int. >> >> Testing: >> - [x] Tiers1,2 > > LGTM @iklam, @yminqi, Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/4814 From ccheung at openjdk.java.net Fri Jul 16 19:25:51 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 16 Jul 2021 19:25:51 GMT Subject: Integrated: 8269636: Change outputStream's print_raw() and print_raw_cr() second parameter to size_t type In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 16:25:46 GMT, Calvin Cheung wrote: > Please review this small cleanup so that the callers of outputStream's `print_raw()` don't need to typecast the second arg to int. > > Testing: > - [x] Tiers1,2 This pull request has now been integrated. Changeset: 58f1ada2 Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/58f1ada2710d2efcb885db9441f6ad8ec4f88905 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod 8269636: Change outputStream's print_raw() and print_raw_cr() second parameter to size_t type Reviewed-by: iklam, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/4814 From iklam at openjdk.java.net Fri Jul 16 20:18:49 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 16 Jul 2021 20:18:49 GMT Subject: RFR: 8270801: Print VM arguments with java -Xlog:arguments In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 07:57:26 GMT, Thomas Stuefe wrote: > Side note, I wish we had a similar option to print the pid (and not much else). In our proprietary port, we have a -XshowPid, which I use surprisingly often, even in scripts. We have a few choices: - `-Xlog:pid` : but this seems too limited to introduce a new log tag - `-Xlog:identifyprocess`: print all relevant info that helps identifying the process. This would include both the arguments, the pid, and perhaps some other info as well (owner id, etc??). If the second makes sense, we should think of a good tag name :-) I will hold the integration of the current PR for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/4801 From cashford at openjdk.java.net Sat Jul 17 00:05:50 2021 From: cashford at openjdk.java.net (Corey Ashford) Date: Sat, 17 Jul 2021 00:05:50 GMT Subject: RFR: JDK-8270340: Base64 decodeBlock intrinsic for Power64 needs cleanup In-Reply-To: References: Message-ID: <2MGEbbqycE1PB8pY5U0Ups5OhB4WgC6sTZXFDjmzlFY=.330056df-bee3-4c05-94b9-e988afc0f35a@github.com> On Thu, 15 Jul 2021 18:48:37 GMT, Martin Doerr wrote: > I guess we will never change the unroll factor. Why not clean it up? I debated with myself back and forth on that. My thinking was that perhaps it will make sense on later processors, like Power11. On the other hand, it's some technical debt to have that complexity without the need. I'll push another commit to remove it (after testing it, of course) ------------- PR: https://git.openjdk.java.net/jdk/pull/4762 From ccheung at openjdk.java.net Sat Jul 17 00:25:55 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Sat, 17 Jul 2021 00:25:55 GMT Subject: RFR: 8265604: Support unlinked classes in dynamic CDS archive In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 17:33:51 GMT, Yumin Qi wrote: >> This change adds the capability of storing unlinked class in dynamic CDS archive. >> Before this change, unlinked classes loaded by custom class loaders won't be store in dynamic CDS archive. >> Unlinked old classes with version < JAVA_6_VERSION will also be supported by this change. Similar to the support for old classes in static CDS archive in [JDK-8261090](https://bugs.openjdk.java.net/browse/JDK-8261090). >> >> Testing: >> >> - [x] tiers1,2,3,4 > > src/hotspot/share/cds/metaspaceShared.cpp line 590: > >> 588: // It's OK to do this for the built-in loaders as we know they can >> 589: // tolerate this. (Note that unregistered classes are loaded by the NULL >> 590: // loader during DumpSharedSpaces). > > DumpSharedSpace -> dump time. (All classes are loaded by boot class loader at dump time) During dynamic dump, an unregistered class could be loaded by a custom loader. > src/hotspot/share/oops/instanceKlass.cpp line 940: > >> 938: // 2) the class is loaded by built-in class loader but failed to add archived loader constraints >> 939: bool need_init_table = true; >> 940: if (is_shared() && verified_at_dump_time() && > > Should comment be updated for the change? I will update the comment to the following: // 1) the class is loaded by custom class loader or // 2) the class is loaded by built-in class loader but failed to add archived loader constraints or // 3) the class was not verified during dump time > test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/CustomLoaderApp.java line 57: > >> 55: Object o = c.newInstance(); >> 56: >> 57: > > extra empty line. I'll delete the empty lines. Thanks for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/4803 From ccheung at openjdk.java.net Sat Jul 17 00:31:40 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Sat, 17 Jul 2021 00:31:40 GMT Subject: RFR: 8265604: Support unlinked classes in dynamic CDS archive [v2] In-Reply-To: References: Message-ID: > This change adds the capability of storing unlinked class in dynamic CDS archive. > Before this change, unlinked classes loaded by custom class loaders won't be store in dynamic CDS archive. > Unlinked old classes with version < JAVA_6_VERSION will also be supported by this change. Similar to the support for old classes in static CDS archive in [JDK-8261090](https://bugs.openjdk.java.net/browse/JDK-8261090). > > Testing: > > - [x] tiers1,2,3,4 Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: @yminqi comments and add a new test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4803/files - new: https://git.openjdk.java.net/jdk/pull/4803/files/2a8b1417..6a572478 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4803&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4803&range=00-01 Stats: 138 lines in 4 files changed: 135 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4803.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4803/head:pull/4803 PR: https://git.openjdk.java.net/jdk/pull/4803 From dholmes at openjdk.java.net Sat Jul 17 00:33:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 17 Jul 2021 00:33:55 GMT Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use try-with-resource [v5] In-Reply-To: <7LhykR73th0mZIuFtnZ33lxjoOBuJ6GcThnv5KGKWBA=.1b9d903f-0533-463a-a506-08c95f6e2355@github.com> References: <7LhykR73th0mZIuFtnZ33lxjoOBuJ6GcThnv5KGKWBA=.1b9d903f-0533-463a-a506-08c95f6e2355@github.com> Message-ID: On Fri, 16 Jul 2021 11:53:15 GMT, Lin Zang wrote: >> 8269909: getStack method in hprof.parser.Reader should use try-with-resource > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > rename variables LGTM. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4717 From dholmes at openjdk.java.net Sat Jul 17 00:37:59 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 17 Jul 2021 00:37:59 GMT Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v4] In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 14:38:35 GMT, Jorn Vernee wrote: >> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title. >> >> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread. >> >> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks. >> >> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob. >> >> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Address more review comments Updates look good. Thanks, David src/hotspot/share/runtime/thread.hpp line 1427: > 1425: static inline JavaThread* current(); > 1426: // Returns the current thread as a JavaThread, or NULL if not attached > 1427: static inline JavaThread* current_or_null(); I hadn't intended to suggest the introduction of this method, but I see now how my comment led to it. It is fine. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/149 From amenkov at openjdk.java.net Sat Jul 17 00:45:01 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Sat, 17 Jul 2021 00:45:01 GMT Subject: RFR: 8213714: AttachingConnector/attach/attach001 failed due to "bind failed: Address already in use" Message-ID: The fix updates the tests to use dynamic port launching debuggee and get the listening port from the debugee output ------------- Commit messages: - Fixed AttachingConnector tests Changes: https://git.openjdk.java.net/jdk/pull/4817/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4817&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8213714 Stats: 130 lines in 4 files changed: 63 ins; 41 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/4817.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4817/head:pull/4817 PR: https://git.openjdk.java.net/jdk/pull/4817 From cashford at openjdk.java.net Sat Jul 17 02:01:26 2021 From: cashford at openjdk.java.net (Corey Ashford) Date: Sat, 17 Jul 2021 02:01:26 GMT Subject: RFR: 8270340: Base64 decodeBlock intrinsic for Power64 needs cleanup [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 17:27:18 GMT, Corey Ashford wrote: >> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3869: >> >>> 3867: VectorSRegister M = VSR8; >>> 3868: >>> 3869: // P10+ VSR lookup variables >> >> "P10+" should better be "P10 or above" (or something grammatically correct) because it appears like an enhanced version of P10, like P7+. Although IBM didn't released "+" models after P8, they have manufactured with reduced semiconductor process and apply enhancements, including larger caches, higher clock frequency, etc. > > Good point. Will fix. I believe I have resolved this with my latest commit to this PR. Please double check. >> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 4038: >> >>> 4036: __ bne_predict_not_taken(CCR6, unrolled_loop_exit); >>> 4037: >>> 4038: // The Base64 characters had no errors, so add the offsets >> >> It may be helpful to add comments for P10 case, where each byte of input contains (decoded 6-bit binary | 0x80) and offsets contains 0x80, and vaddubm is used to clear the MSB. > > Good point. I'll update the comment. I believe I have resolved this with my latest commit to this PR. Please double check. ------------- PR: https://git.openjdk.java.net/jdk/pull/4762 From cashford at openjdk.java.net Sat Jul 17 02:01:23 2021 From: cashford at openjdk.java.net (Corey Ashford) Date: Sat, 17 Jul 2021 02:01:23 GMT Subject: RFR: 8270340: Base64 decodeBlock intrinsic for Power64 needs cleanup [v2] In-Reply-To: References: Message-ID: > This series of commits was written to accomplish several cleanup and Power10 optimization tasks for the Base64 decodeBlock intrinsic for Power64: > * Remove the ISA 3.1+ (Power10+) pextd instruction optimization in decodeBlock. This "optimization" turned out to actually cause a performance hit. Removing it gains back about 3% in performance. > * Introduce a constant block, similar to that in use by encodeBlock() to speed up constant loading. > * Add the ISA 3.1+ xxpermx instruction and align_prefix() method for use in a Power10 optimization for decodeBlock. Please see the commit log for my concerns about this change. > * Implement the xxpermx-based decodeBlock algorithm for Power10+, which gives about a 5% performance boost. > > More details can be found in the commit logs. > > I want to note here that I looked into changing the loop_unrolls constant, and found that at large buffer sizes, the values of 2 and 4 give some extra performance gain. For example, on a 20001-byte destination buffer, I see an increase from 4.7X over intrinsic disabled (loop_unrolls=1), to 5.3X over intrinsic disabled (loop_unrolls=4), but on smaller buffer sizes, up to about 512, it causes performance degradation over loop_unrolls=1, so I have decided to stick with the original value of 1, since I don't know where to focus the performance versus buffer length tradeoff. Corey Ashford has updated the pull request incrementally with one additional commit since the last revision: stubGenerator_ppc.cpp: fixes for feedback from Kazunori Ogata and Martin Doerr decodeBlock changes: * Remove unroll loop and associated comments * Change comments referring to "P10+" to "P10 (or later)" to remove ambiguity * Make clear the lack of need for "aligh_prefix()" calls when using xxpermx due to the align(32) call The following change isn't based on feedback: encodeBlock changes: * Fix a comment that still referred to "unrolled loop". Unrolling was removed in an earlier commit. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4762/files - new: https://git.openjdk.java.net/jdk/pull/4762/files/bfa1d3be..1400e26d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4762&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4762&range=00-01 Stats: 275 lines in 1 file changed: 103 ins; 127 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/4762.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4762/head:pull/4762 PR: https://git.openjdk.java.net/jdk/pull/4762 From cashford at openjdk.java.net Sat Jul 17 02:01:28 2021 From: cashford at openjdk.java.net (Corey Ashford) Date: Sat, 17 Jul 2021 02:01:28 GMT Subject: RFR: 8270340: Base64 decodeBlock intrinsic for Power64 needs cleanup [v2] In-Reply-To: <2MGEbbqycE1PB8pY5U0Ups5OhB4WgC6sTZXFDjmzlFY=.330056df-bee3-4c05-94b9-e988afc0f35a@github.com> References: <2MGEbbqycE1PB8pY5U0Ups5OhB4WgC6sTZXFDjmzlFY=.330056df-bee3-4c05-94b9-e988afc0f35a@github.com> Message-ID: On Sat, 17 Jul 2021 00:03:12 GMT, Corey Ashford wrote: >> I guess we will never change the unroll factor. Why not clean it up? > >> I guess we will never change the unroll factor. Why not clean it up? > > I debated with myself back and forth on that. My thinking was that perhaps it will make sense on later processors, like Power11. On the other hand, it's some technical debt to have that complexity without the need. > > I'll push another commit to remove it (after testing it, of course) I believe I have resolved this with my latest commit to this PR. Please double check. ------------- PR: https://git.openjdk.java.net/jdk/pull/4762 From stuefe at openjdk.java.net Sat Jul 17 04:10:53 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 17 Jul 2021 04:10:53 GMT Subject: RFR: 8270801: Print VM arguments with java -Xlog:arguments In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 20:16:06 GMT, Ioi Lam wrote: > > Side note, I wish we had a similar option to print the pid (and not much else). In our proprietary port, we have a -XshowPid, which I use surprisingly often, even in scripts. > > We have a few choices: > > * `-Xlog:pid` : but this seems too limited to introduce a new log tag > * `-Xlog:identifyprocess`: print all relevant info that helps identifying the process. This would include both the arguments, the pid, and perhaps some other info as well (owner id, etc??). > > If the second makes sense, we should think of a good tag name :-) I will hold the integration of the current PR for now. After thinking about this, I think either a new "-Xlog:process", or we could just log it under "-Xlog:os". The latter could maybe benefit from some cleaning up to reduce the noise at info level. ------------- PR: https://git.openjdk.java.net/jdk/pull/4801 From iklam at openjdk.java.net Sat Jul 17 04:55:51 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 17 Jul 2021 04:55:51 GMT Subject: RFR: 8270801: Print VM arguments with java -Xlog:arguments In-Reply-To: References: Message-ID: <8fzQ7AMEiOwQ0AePWgB843ZeWE5mKdX67Qypla_MF9M=.888af905-d691-4466-b2fe-84f5cd4017b5@github.com> On Sat, 17 Jul 2021 04:08:03 GMT, Thomas Stuefe wrote: > > > Side note, I wish we had a similar option to print the pid (and not much else). In our proprietary port, we have a -XshowPid, which I use surprisingly often, even in scripts. > > > > > > We have a few choices: > > > > * `-Xlog:pid` : but this seems too limited to introduce a new log tag > > * `-Xlog:identifyprocess`: print all relevant info that helps identifying the process. This would include both the arguments, the pid, and perhaps some other info as well (owner id, etc??). > > > > If the second makes sense, we should think of a good tag name :-) I will hold the integration of the current PR for now. > > After thinking about this, I think either a new "-Xlog:process", or we could just log it under "-Xlog:os". The latter could maybe benefit from some cleaning up to reduce the noise at info level. Adding to `-Xlog:os` seems the right place. I tried `-Xlog:os` with Eclipse and it wasn't too verbose -- only about 30 lines are printed. I filed https://bugs.openjdk.java.net/browse/JDK-8270865 ------------- PR: https://git.openjdk.java.net/jdk/pull/4801 From iklam at openjdk.java.net Sat Jul 17 04:55:51 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 17 Jul 2021 04:55:51 GMT Subject: RFR: 8270801: Print VM arguments with java -Xlog:arguments In-Reply-To: References: Message-ID: On Fri, 16 Jul 2021 04:19:28 GMT, Xin Liu wrote: >> It's useful to print VM arguments to the log file, especially when you are logging several JVM invocations: >> >> >> $ java -cp foo -Xlog:gc:file=a.log -Xcomp com.Foo >> $ java -cp foo -Xlog:gc:file=b.log -Xint com.Foo >> >> >> After a while, you may forget which process created a.log and which created b.log. Adding vm arguments into the log file will help distinguishing them: >> >> >> $ java -cp foo -Xlog:gc,arguments:file=a.log -Xcomp com.Foo >> $ java -cp foo -Xlog:gc,arguments:file=b.log -Xint com.Foo >> >> $ grep jvm_args a.log b.log >> a.log:[0.015s][info][arguments] jvm_args: -Xlog:gc,arguments:file=a.log -Xint >> b.log:[0.001s][info][arguments] jvm_args: -Xlog:gc,arguments:file=b.log -Xcomp >> >> >> Here's an example of what the log looks like: >> >> >> $ java -Xlog:arguments -Xshare:on -cp ~/tmp -Dxx=yy -esa HelloWorld 1 2 3 >> [0.001s][info][arguments] VM Arguments: >> [0.001s][info][arguments] jvm_args: -Xlog:arguments -Xshare:on -Dxx=yy -esa >> [0.001s][info][arguments] java_command: HelloWorld 1 2 3 >> [0.001s][info][arguments] java_class_path (initial): /home/user/tmp >> [0.001s][info][arguments] Launcher Type: SUN_STANDARD >> Hello World > > I think it better off use LogMessage to guarantee multiple-lines are not separated. > then I realize that this is very beginning, other threads haven't been up yet. so it's fine. Thanks @navyxliu @tstuefe @dholmes-ora @yminqi for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/4801 From iklam at openjdk.java.net Sat Jul 17 04:55:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 17 Jul 2021 04:55:52 GMT Subject: Integrated: 8270801: Print VM arguments with java -Xlog:arguments In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 22:48:51 GMT, Ioi Lam wrote: > It's useful to print VM arguments to the log file, especially when you are logging several JVM invocations: > > > $ java -cp foo -Xlog:gc:file=a.log -Xcomp com.Foo > $ java -cp foo -Xlog:gc:file=b.log -Xint com.Foo > > > After a while, you may forget which process created a.log and which created b.log. Adding vm arguments into the log file will help distinguishing them: > > > $ java -cp foo -Xlog:gc,arguments:file=a.log -Xcomp com.Foo > $ java -cp foo -Xlog:gc,arguments:file=b.log -Xint com.Foo > > $ grep jvm_args a.log b.log > a.log:[0.015s][info][arguments] jvm_args: -Xlog:gc,arguments:file=a.log -Xint > b.log:[0.001s][info][arguments] jvm_args: -Xlog:gc,arguments:file=b.log -Xcomp > > > Here's an example of what the log looks like: > > > $ java -Xlog:arguments -Xshare:on -cp ~/tmp -Dxx=yy -esa HelloWorld 1 2 3 > [0.001s][info][arguments] VM Arguments: > [0.001s][info][arguments] jvm_args: -Xlog:arguments -Xshare:on -Dxx=yy -esa > [0.001s][info][arguments] java_command: HelloWorld 1 2 3 > [0.001s][info][arguments] java_class_path (initial): /home/user/tmp > [0.001s][info][arguments] Launcher Type: SUN_STANDARD > Hello World This pull request has now been integrated. Changeset: f8ec3b68 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/f8ec3b68f3e8f86eacf5c0de06c91827e88c7b30 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8270801: Print VM arguments with java -Xlog:arguments Reviewed-by: dholmes, xliu, stuefe, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/4801 From ogatak at openjdk.java.net Sun Jul 18 20:11:54 2021 From: ogatak at openjdk.java.net (Kazunori Ogata) Date: Sun, 18 Jul 2021 20:11:54 GMT Subject: RFR: 8270340: Base64 decodeBlock intrinsic for Power64 needs cleanup [v2] In-Reply-To: References: Message-ID: On Sat, 17 Jul 2021 02:01:23 GMT, Corey Ashford wrote: >> This series of commits was written to accomplish several cleanup and Power10 optimization tasks for the Base64 decodeBlock intrinsic for Power64: >> * Remove the ISA 3.1+ (Power10+) pextd instruction optimization in decodeBlock. This "optimization" turned out to actually cause a performance hit. Removing it gains back about 3% in performance. >> * Introduce a constant block, similar to that in use by encodeBlock() to speed up constant loading. >> * Add the ISA 3.1+ xxpermx instruction and align_prefix() method for use in a Power10 optimization for decodeBlock. Please see the commit log for my concerns about this change. >> * Implement the xxpermx-based decodeBlock algorithm for Power10+, which gives about a 5% performance boost. >> >> More details can be found in the commit logs. >> >> I want to note here that I looked into changing the loop_unrolls constant, and found that at large buffer sizes, the values of 2 and 4 give some extra performance gain. For example, on a 20001-byte destination buffer, I see an increase from 4.7X over intrinsic disabled (loop_unrolls=1), to 5.3X over intrinsic disabled (loop_unrolls=4), but on smaller buffer sizes, up to about 512, it causes performance degradation over loop_unrolls=1, so I have decided to stick with the original value of 1, since I don't know where to focus the performance versus buffer length tradeoff. > > Corey Ashford has updated the pull request incrementally with one additional commit since the last revision: > > stubGenerator_ppc.cpp: fixes for feedback from Kazunori Ogata and Martin Doerr > > decodeBlock changes: > > * Remove unroll loop and associated comments > * Change comments referring to "P10+" to "P10 (or later)" to remove ambiguity > * Make clear the lack of need for "aligh_prefix()" calls when using xxpermx due to the align(32) call > > The following change isn't based on feedback: > > encodeBlock changes: > * Fix a comment that still referred to "unrolled loop". Unrolling was removed in an earlier commit. The changes look fine to me besides the comment about align_prefix(), though I'm not a Reviewer. src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3966: > 3964: // Note that due to align(32) call above, the xxpermx instructions do > 3965: // not require align_prefix() calls, since the final xxpermx > 3966: // prefix+opcode is at byte 24. The question is whether we should leave align_prefix() in macroAssembler.[ch]pp. Since it appears convenient, someone may want to use it without noticing its intention that is only allowed (or acceptable) for generating intrinsics. If we leave it, I think it is better to add assertion statement to check if it is used for intrinsics generation (though I don't know how to implement it.) ------------- PR: https://git.openjdk.java.net/jdk/pull/4762 From david.holmes at oracle.com Mon Jul 19 00:35:37 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 19 Jul 2021 10:35:37 +1000 Subject: [External] : Re: Why is mark read as MO_RELAXED in read_stable_mark()? In-Reply-To: <0b59fc50-b792-b8e1-5ce5-0a8345a3dd5b@oracle.com> References: <5080550c-1b90-3ca6-1a51-44e47ddd5b4e@redhat.com> <3c8c57e0-03c7-9dfe-ec7b-36ecef35f625@redhat.com> <0b59fc50-b792-b8e1-5ce5-0a8345a3dd5b@oracle.com> Message-ID: <45e34415-9ab9-4877-0157-50f1c85bb792@oracle.com> Hi Roman, Sorry for the delay in getting to this ... On 13/07/2021 7:18 am, patricio.chilano.mateo at oracle.com wrote: > > On 7/12/21 4:26 PM, Roman Kennke wrote: >>>> Hi Hotspot runtime devs, >>>> >>>> I am messing a little bit with read_stable_mark() in >>>> synchronizer.cpp in Lilliput project (because I want to load the >>>> Klass* from the header). >>>> >>>> I notice that, in read_stable_mark(), we are loading the header with >>>> MO_RELAXED memory ordering, even though the INFLATING header is >>>> stored either via CAS or (re-)stored with MO_RELEASE. Wouldn't it be >>>> more consequential to load the header with MO_ACQUIRE instead? >>> For the monitor case I think we already have an address dependency in >>> the reader so there is no need for the acquire. So we first read the >>> monitor address and then use that address to access the _header >>> field(FastHashCode() case) or _owner >>> field(current_thread_holds_lock() and get_lock_owner() cases). The >>> writer in turn orders the stores to _owner/_header and the publishing >>> of the monitor address by using a release store in inflate() (I think >>> this is the one you are referring to). >>> >> >> Thanks Patricio, >> >> I am not quite sure that I follow you. >> >> On the reader side, given an object, when a thread calls into >> FastHashCode() or any locking that causes inflation, it needs to read >> the object header, and that is always done with a plain read. In >> particular, read_stable_mark() does that, while waiting for the header >> to become != INFLATING. On the writer side, we use CAS (using >> MO_SEQ_CST) to temporarily turn on INFLATING(with release_store() to >> write back the original header, and store with MO_RELEASE to write >> back the original header. >> >> It probably doesn't matter all that much. >> >> I am wondering about this because I am currently moving the Klass* >> into the object header, which means that for klass() implementation, >> we need to load the header similar to how we do it for hashcode(). In >> particular it involves read_stable_mark(). Now, there is a variant of >> klass-accessor that implies acquire-semantics: >> oopDesc::klass_or_null_acquire(). I am not quite sure why exactly we >> need acquire semantics there, but in order to implement it, I believe >> we would have to make a variant of read_stable_mark() that uses >> acquire semantics to load the header, instead of plain reads. >> >> But I'm thinking it may be cleaner overall to always use acquire >> semantics in read_stable_mark() (mirroring the release-store and >> seq-cst-CAS), which would make the acquire-accessors for klass() >> superfluous. >> >> What do you think? > It definitely doesn't break correctness if you add it and probably > doesn't change anything in terms of performance. Now, looking back in > history, klass_or_null_acquire() was added in 8166583 to protect against > reading a partially allocated object. The description of the issue > actually argues to explicitly have klass_or_null_acquire() instead of > making klass_or_null() quietly have acquire semantics. If that is the > case then I think you would still need to have a version with a plain > load without the extra fence. You could probably have two versions of > read_stable_mark() by refactoring everything except the load of the mark > and check into a separate shared function. Also by removing the uneeded > extra code before the 'for' loop will make them even shorter. Another > option, although more conservative in terms of memory ordering on > certain cpus, is to keep read_stable_mark() as is and have > klass_or_null_acquire() use a standalone OrderAccess::acquire() fence > before returning. I think any solution would work, but maybe wait for > somebody else to chime in to hear other thoughts. Looking at the uses of read_stable_mark() I would say that FastHashCode and get_lock_owner() should have acquire semantics to match the implied release semantics used when there is inflation and those methods have to read fields of the monitor. I'm not convinced we can rely on any address dependency for semantics in shared code - and it seems too subtle a point even if we can. The other uses don't need acquire semantics, so I'd argue for adding a memory order parameter to read_stable_mark so that it can be controlled explicitly. That memory ordering parameter would then need to be passed through to the call to obj->mark() - either as a memory order parameter or by calling mark() or a new mark_acquire() (adding mark_acquire() seems more in keeping with current oopDesc API design style). Cheers, David > Thanks, > Patricio From dholmes at openjdk.java.net Mon Jul 19 02:52:18 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 19 Jul 2021 02:52:18 GMT Subject: RFR: 8270875: Deprecate the FilterSpuriousWakeups flag so it can be removed Message-ID: Please review this simple change to deprecate the archaic FilterSpuriousWakeups flag. See JBS issue for more details. Testing: manual Thanks, David ------------- Commit messages: - 8270875: Deprecate the FilterSpuriousWakeups flag so it can be removed Changes: https://git.openjdk.java.net/jdk/pull/4821/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4821&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270875 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4821.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4821/head:pull/4821 PR: https://git.openjdk.java.net/jdk/pull/4821 From kbarrett at openjdk.java.net Mon Jul 19 03:44:51 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 19 Jul 2021 03:44:51 GMT Subject: RFR: 8270875: Deprecate the FilterSpuriousWakeups flag so it can be removed In-Reply-To: References: Message-ID: On Mon, 19 Jul 2021 02:37:29 GMT, David Holmes wrote: > Please review this simple change to deprecate the archaic FilterSpuriousWakeups flag. > > See JBS issue for more details. > > Testing: manual > > Thanks, > David Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4821 From dholmes at openjdk.java.net Mon Jul 19 04:04:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 19 Jul 2021 04:04:55 GMT Subject: RFR: 8270875: Deprecate the FilterSpuriousWakeups flag so it can be removed In-Reply-To: References: Message-ID: <3mXBClZh8PYR6NFu158nR0KxCGSJM_j9W1cpQ5ALmJI=.bc00cc9d-a71c-48c4-9e81-c32893972666@github.com> On Mon, 19 Jul 2021 03:42:14 GMT, Kim Barrett wrote: >> Please review this simple change to deprecate the archaic FilterSpuriousWakeups flag. >> >> See JBS issue for more details. >> >> Testing: manual >> >> Thanks, >> David > > Looks good. Thanks for the review @kimbarrett ! ------------- PR: https://git.openjdk.java.net/jdk/pull/4821 From rkennke at redhat.com Mon Jul 19 10:05:16 2021 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 19 Jul 2021 12:05:16 +0200 Subject: [External] : Re: Why is mark read as MO_RELAXED in read_stable_mark()? In-Reply-To: <45e34415-9ab9-4877-0157-50f1c85bb792@oracle.com> References: <5080550c-1b90-3ca6-1a51-44e47ddd5b4e@redhat.com> <3c8c57e0-03c7-9dfe-ec7b-36ecef35f625@redhat.com> <0b59fc50-b792-b8e1-5ce5-0a8345a3dd5b@oracle.com> <45e34415-9ab9-4877-0157-50f1c85bb792@oracle.com> Message-ID: Hi David, >>>>> I am messing a little bit with read_stable_mark() in >>>>> synchronizer.cpp in Lilliput project (because I want to load the >>>>> Klass* from the header). >>>>> >>>>> I notice that, in read_stable_mark(), we are loading the header >>>>> with MO_RELAXED memory ordering, even though the INFLATING header >>>>> is stored either via CAS or (re-)stored with MO_RELEASE. Wouldn't >>>>> it be more consequential to load the header with MO_ACQUIRE instead? >>>> For the monitor case I think we already have an address dependency >>>> in the reader so there is no need for the acquire. So we first read >>>> the monitor address and then use that address to access the _header >>>> field(FastHashCode() case) or _owner >>>> field(current_thread_holds_lock() and get_lock_owner() cases). The >>>> writer in turn orders the stores to _owner/_header and the >>>> publishing of the monitor address by using a release store in >>>> inflate() (I think this is the one you are referring to). >>>> >>> >>> Thanks Patricio, >>> >>> I am not quite sure that I follow you. >>> >>> On the reader side, given an object, when a thread calls into >>> FastHashCode() or any locking that causes inflation, it needs to read >>> the object header, and that is always done with a plain read. In >>> particular, read_stable_mark() does that, while waiting for the >>> header to become != INFLATING. On the writer side, we use CAS (using >>> MO_SEQ_CST) to temporarily turn on INFLATING(with release_store() to >>> write back the original header, and store with MO_RELEASE to write >>> back the original header. >>> >>> It probably doesn't matter all that much. >>> >>> I am wondering about this because I am currently moving the Klass* >>> into the object header, which means that for klass() implementation, >>> we need to load the header similar to how we do it for hashcode(). In >>> particular it involves read_stable_mark(). Now, there is a variant of >>> klass-accessor that implies acquire-semantics: >>> oopDesc::klass_or_null_acquire(). I am not quite sure why exactly we >>> need acquire semantics there, but in order to implement it, I believe >>> we would have to make a variant of read_stable_mark() that uses >>> acquire semantics to load the header, instead of plain reads. >>> >>> But I'm thinking it may be cleaner overall to always use acquire >>> semantics in read_stable_mark() (mirroring the release-store and >>> seq-cst-CAS), which would make the acquire-accessors for klass() >>> superfluous. >>> >>> What do you think? >> It definitely doesn't break correctness if you add it and probably >> doesn't change anything in terms of performance. Now, looking back in >> history, klass_or_null_acquire() was added in 8166583 to protect >> against reading a partially allocated object. The description of the >> issue actually argues to explicitly have klass_or_null_acquire() >> instead of making klass_or_null() quietly have acquire semantics. If >> that is the case then I think you would still need to have a version >> with a plain load without the extra fence. You could probably have two >> versions of read_stable_mark() by refactoring everything except the >> load of the mark and check into a separate shared function. Also by >> removing the uneeded extra code before the 'for' loop will make them >> even shorter. Another option, although more conservative in terms of >> memory ordering on certain cpus, is to keep read_stable_mark() as is >> and have klass_or_null_acquire() use a standalone >> OrderAccess::acquire() fence before returning. I think any solution >> would work, but maybe wait for somebody else to chime in to hear other >> thoughts. > > Looking at the uses of read_stable_mark() I would say that FastHashCode > and get_lock_owner() should have acquire semantics to match the implied > release semantics used when there is inflation and those methods have to > read fields of the monitor. I'm not convinced we can rely on any address > dependency for semantics in shared code - and it seems too subtle a > point even if we can. Ok, I agree. > The other uses don't need acquire semantics Why do you think so? I see a use in current_thread_holds_lock(), and how is that different from get_lock_owner() ? It also reads a field of the monitor after loading the header word. And then I see another use in ::inflate(), which seems to me the primary use where acquire is needed. It certainly reads from the monitor after loading the header. I'd actually go a little further here, and also give acquire semantics to the first plain header-loads in that method. (In-fact, why not restructure the retry-loop to do read_stable_mark() once at the loop-entry?) , so I'd argue for adding a > memory order parameter to read_stable_mark so that it can be controlled > explicitly. That memory ordering parameter would then need to be passed > through to the call to obj->mark() - either as a memory order parameter > or by calling mark() or a new mark_acquire() (adding mark_acquire() > seems more in keeping with current oopDesc API design style). In my local prototype, I have added a template parameter to read_stable_mark and pass that to (a new) oopDesc::mark() that also takes the MO template parameter to load the header word. I filed: https://bugs.openjdk.java.net/browse/JDK-8270894 Thanks, Roman From david.holmes at oracle.com Mon Jul 19 11:29:35 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 19 Jul 2021 21:29:35 +1000 Subject: [External] : Re: Why is mark read as MO_RELAXED in read_stable_mark()? In-Reply-To: References: <5080550c-1b90-3ca6-1a51-44e47ddd5b4e@redhat.com> <3c8c57e0-03c7-9dfe-ec7b-36ecef35f625@redhat.com> <0b59fc50-b792-b8e1-5ce5-0a8345a3dd5b@oracle.com> <45e34415-9ab9-4877-0157-50f1c85bb792@oracle.com> Message-ID: On 19/07/2021 8:05 pm, Roman Kennke wrote: > Hi David, > >>>>>> I am messing a little bit with read_stable_mark() in >>>>>> synchronizer.cpp in Lilliput project (because I want to load the >>>>>> Klass* from the header). >>>>>> >>>>>> I notice that, in read_stable_mark(), we are loading the header >>>>>> with MO_RELAXED memory ordering, even though the INFLATING header >>>>>> is stored either via CAS or (re-)stored with MO_RELEASE. Wouldn't >>>>>> it be more consequential to load the header with MO_ACQUIRE instead? >>>>> For the monitor case I think we already have an address dependency >>>>> in the reader so there is no need for the acquire. So we first read >>>>> the monitor address and then use that address to access the _header >>>>> field(FastHashCode() case) or _owner >>>>> field(current_thread_holds_lock() and get_lock_owner() cases). The >>>>> writer in turn orders the stores to _owner/_header and the >>>>> publishing of the monitor address by using a release store in >>>>> inflate() (I think this is the one you are referring to). >>>>> >>>> >>>> Thanks Patricio, >>>> >>>> I am not quite sure that I follow you. >>>> >>>> On the reader side, given an object, when a thread calls into >>>> FastHashCode() or any locking that causes inflation, it needs to >>>> read the object header, and that is always done with a plain read. >>>> In particular, read_stable_mark() does that, while waiting for the >>>> header to become != INFLATING. On the writer side, we use CAS (using >>>> MO_SEQ_CST) to temporarily turn on INFLATING(with release_store() to >>>> write back the original header, and store with MO_RELEASE to write >>>> back the original header. >>>> >>>> It probably doesn't matter all that much. >>>> >>>> I am wondering about this because I am currently moving the Klass* >>>> into the object header, which means that for klass() implementation, >>>> we need to load the header similar to how we do it for hashcode(). >>>> In particular it involves read_stable_mark(). Now, there is a >>>> variant of klass-accessor that implies acquire-semantics: >>>> oopDesc::klass_or_null_acquire(). I am not quite sure why exactly we >>>> need acquire semantics there, but in order to implement it, I >>>> believe we would have to make a variant of read_stable_mark() that >>>> uses acquire semantics to load the header, instead of plain reads. >>>> >>>> But I'm thinking it may be cleaner overall to always use acquire >>>> semantics in read_stable_mark() (mirroring the release-store and >>>> seq-cst-CAS), which would make the acquire-accessors for klass() >>>> superfluous. >>>> >>>> What do you think? >>> It definitely doesn't break correctness if you add it and probably >>> doesn't change anything in terms of performance. Now, looking back in >>> history, klass_or_null_acquire() was added in 8166583 to protect >>> against reading a partially allocated object. The description of the >>> issue actually argues to explicitly have klass_or_null_acquire() >>> instead of making klass_or_null() quietly have acquire semantics. If >>> that is the case then I think you would still need to have a version >>> with a plain load without the extra fence. You could probably have >>> two versions of read_stable_mark() by refactoring everything except >>> the load of the mark and check into a separate shared function. Also >>> by removing the uneeded extra code before the 'for' loop will make >>> them even shorter. Another option, although more conservative in >>> terms of memory ordering on certain cpus, is to keep >>> read_stable_mark() as is and have klass_or_null_acquire() use a >>> standalone OrderAccess::acquire() fence before returning. I think any >>> solution would work, but maybe wait for somebody else to chime in to >>> hear other thoughts. >> >> Looking at the uses of read_stable_mark() I would say that >> FastHashCode and get_lock_owner() should have acquire semantics to >> match the implied release semantics used when there is inflation and >> those methods have to read fields of the monitor. I'm not convinced we >> can rely on any address dependency for semantics in shared code - and >> it seems too subtle a point even if we can. > > Ok, I agree. > >> The other uses don't need acquire semantics > > Why do you think so? > > I see a use in current_thread_holds_lock(), and how is that different > from get_lock_owner() ? It also reads a field of the monitor after > loading the header word. Because that thread is only interested in correctly seeing values written by itself. It can't get any kind of false positive. If it is the owner it must see its own writes; if it is not the owner it can't see itself incorrectly listed as the owner. > And then I see another use in ::inflate(), which seems to me the primary > use where acquire is needed. It certainly reads from the monitor after > loading the header. I'd actually go a little further here, and also give > acquire semantics to the first plain header-loads in that method. > (In-fact, why not restructure the retry-loop to do read_stable_mark() > once at the loop-entry?) Yes you're right I didn't reason correctly about inflate. Just taking the first inflated case we read the displaced markword, but without acquire semantics on the original markWord, we're not guaranteed to see the displaced header (except by the previously mentioned address dependency). Cheers, David > > , so I'd argue for adding a >> memory order parameter to read_stable_mark so that it can be >> controlled explicitly. That memory ordering parameter would then need >> to be passed through to the call to obj->mark() - either as a memory >> order parameter or by calling mark() or a new mark_acquire() (adding >> mark_acquire() seems more in keeping with current oopDesc API design >> style). > > In my local prototype, I have added a template parameter to > read_stable_mark and pass that to (a new) oopDesc::mark() that also > takes the MO template parameter to load the header word. > > I filed: > https://bugs.openjdk.java.net/browse/JDK-8270894 > > Thanks, > Roman > From rkennke at redhat.com Mon Jul 19 13:16:27 2021 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 19 Jul 2021 15:16:27 +0200 Subject: [External] : Re: Why is mark read as MO_RELAXED in read_stable_mark()? In-Reply-To: References: <5080550c-1b90-3ca6-1a51-44e47ddd5b4e@redhat.com> <3c8c57e0-03c7-9dfe-ec7b-36ecef35f625@redhat.com> <0b59fc50-b792-b8e1-5ce5-0a8345a3dd5b@oracle.com> <45e34415-9ab9-4877-0157-50f1c85bb792@oracle.com> Message-ID: <57e41bba-3798-70d3-945b-6e3838e4f28a@redhat.com> >>> Looking at the uses of read_stable_mark() I would say that >>> FastHashCode and get_lock_owner() should have acquire semantics to >>> match the implied release semantics used when there is inflation and >>> those methods have to read fields of the monitor. I'm not convinced >>> we can rely on any address dependency for semantics in shared code - >>> and it seems too subtle a point even if we can. >> >> Ok, I agree. >> >>> The other uses don't need acquire semantics >> >> Why do you think so? >> >> I see a use in current_thread_holds_lock(), and how is that different >> from get_lock_owner() ? It also reads a field of the monitor after >> loading the header word. > > Because that thread is only interested in correctly seeing values > written by itself. It can't get any kind of false positive. If it is the > owner it must see its own writes; if it is not the owner it can't see > itself incorrectly listed as the owner. Right. Is it reasonable to make the distinction for that single case, though? Adding acquire semantics should not make much of a difference (if at all) to performance, in light of the other things that the method does? Roman From david.holmes at oracle.com Mon Jul 19 23:04:36 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Jul 2021 09:04:36 +1000 Subject: [External] : Re: Why is mark read as MO_RELAXED in read_stable_mark()? In-Reply-To: <57e41bba-3798-70d3-945b-6e3838e4f28a@redhat.com> References: <5080550c-1b90-3ca6-1a51-44e47ddd5b4e@redhat.com> <3c8c57e0-03c7-9dfe-ec7b-36ecef35f625@redhat.com> <0b59fc50-b792-b8e1-5ce5-0a8345a3dd5b@oracle.com> <45e34415-9ab9-4877-0157-50f1c85bb792@oracle.com> <57e41bba-3798-70d3-945b-6e3838e4f28a@redhat.com> Message-ID: On 19/07/2021 11:16 pm, Roman Kennke wrote: >>>> Looking at the uses of read_stable_mark() I would say that >>>> FastHashCode and get_lock_owner() should have acquire semantics to >>>> match the implied release semantics used when there is inflation and >>>> those methods have to read fields of the monitor. I'm not convinced >>>> we can rely on any address dependency for semantics in shared code - >>>> and it seems too subtle a point even if we can. >>> >>> Ok, I agree. >>> >>>> The other uses don't need acquire semantics >>> >>> Why do you think so? >>> >>> I see a use in current_thread_holds_lock(), and how is that different >>> from get_lock_owner() ? It also reads a field of the monitor after >>> loading the header word. >> >> Because that thread is only interested in correctly seeing values >> written by itself. It can't get any kind of false positive. If it is >> the owner it must see its own writes; if it is not the owner it can't >> see itself incorrectly listed as the owner. > > Right. Is it reasonable to make the distinction for that single case, > though? Adding acquire semantics should not make much of a difference > (if at all) to performance, in light of the other things that the method > does? No I don't think it needs to make the distinction here. There are only three callers of this method anyway: - Thread.holdsLock - an obscure part of classloading (double-lock-wait) - an assert Thanks, David > Roman > From patricio.chilano.mateo at oracle.com Tue Jul 20 01:17:18 2021 From: patricio.chilano.mateo at oracle.com (patricio.chilano.mateo at oracle.com) Date: Mon, 19 Jul 2021 22:17:18 -0300 Subject: [External] : Re: Why is mark read as MO_RELAXED in read_stable_mark()? In-Reply-To: <45e34415-9ab9-4877-0157-50f1c85bb792@oracle.com> References: <5080550c-1b90-3ca6-1a51-44e47ddd5b4e@redhat.com> <3c8c57e0-03c7-9dfe-ec7b-36ecef35f625@redhat.com> <0b59fc50-b792-b8e1-5ce5-0a8345a3dd5b@oracle.com> <45e34415-9ab9-4877-0157-50f1c85bb792@oracle.com> Message-ID: On 7/18/21 9:35 PM, David Holmes wrote: > Hi Roman, > > Sorry for the delay in getting to this ... > > On 13/07/2021 7:18 am, patricio.chilano.mateo at oracle.com wrote: >> >> On 7/12/21 4:26 PM, Roman Kennke wrote: >>>>> Hi Hotspot runtime devs, >>>>> >>>>> I am messing a little bit with read_stable_mark() in >>>>> synchronizer.cpp in Lilliput project (because I want to load the >>>>> Klass* from the header). >>>>> >>>>> I notice that, in read_stable_mark(), we are loading the header >>>>> with MO_RELAXED memory ordering, even though the INFLATING header >>>>> is stored either via CAS or (re-)stored with MO_RELEASE. Wouldn't >>>>> it be more consequential to load the header with MO_ACQUIRE instead? >>>> For the monitor case I think we already have an address dependency >>>> in the reader so there is no need for the acquire. So we first read >>>> the monitor address and then use that address to access the _header >>>> field(FastHashCode() case) or _owner >>>> field(current_thread_holds_lock() and get_lock_owner() cases). The >>>> writer in turn orders the stores to _owner/_header and the >>>> publishing of the monitor address by using a release store in >>>> inflate() (I think this is the one you are referring to). > I'm not convinced we can rely on any address dependency for semantics > in shared code - and it seems too subtle a point even if we can. I did some investigation to try to answer that and see how reliable the current code is. It is indeed possible for the stores to _header and _owner in inflate() to still not be visible to the reader after it reads the new monitor address, although in practice that could only happen on DEC Alpha which doesn't preserve data dependency ordering ([1], [2]), or when compiler optimizations such as value speculation break the dependency chain [3] (although I don't think there is much room for that in these cases). C++ consume semantics(temporarily deprecated in C++17) appears to have been introduced to guarantee memory ordering in these cases where dependencies can be used to avoid the more expensive acquire semantics. Patricio [1] https://preshing.com/20140709/the-purpose-of-memory_order_consume-in-cpp11/#data-dependency-ordering [2] http://www.cs.umd.edu/~pugh/java/memoryModel/AlphaReordering.html [3] https://lwn.net/Articles/588300/ > Cheers, > David > >> Thanks, >> Patricio From pchilanomate at openjdk.java.net Wed Jul 21 21:25:23 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 21 Jul 2021 21:25:23 GMT Subject: [jdk17] RFR: 8270085: Suspend during block transition may deadlock if lock held [v3] In-Reply-To: References: Message-ID: > Hi all, > > The following patch fixes deadlocks issues that could occur when checking for suspension while holding VM locks. See the bug description for a concrete case. The solution is to avoid checking for suspend requests when using the TBIVM wrapper. The original patch was actually written by @robehn(now on vacations) and I only made small changes. > > Tested in mach5 tiers1-7. I also verified that the new added test SuspendBlocked.java deadlocks with the current bits and passes with this patch. > > Thanks, > > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: fix comment in should_process_no_suspend() ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/257/files - new: https://git.openjdk.java.net/jdk17/pull/257/files/6ad7c4ea..6cfa7712 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=257&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=257&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/257.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/257/head:pull/257 PR: https://git.openjdk.java.net/jdk17/pull/257 From pchilanomate at openjdk.java.net Wed Jul 21 21:25:26 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 21 Jul 2021 21:25:26 GMT Subject: [jdk17] RFR: 8270085: Suspend during block transition may deadlock if lock held [v2] In-Reply-To: References: Message-ID: <3aJ7x0xtRwvwXIZ4SrFo-z9ZkXwPjCD-Y2dvI-fHZk8=.b445d6ce-4bb4-4e8f-b84e-96e72a1a2a5b@github.com> On Wed, 21 Jul 2021 01:50:09 GMT, Patricio Chilano Mateo wrote: >> Hi all, >> >> The following patch fixes deadlocks issues that could occur when checking for suspension while holding VM locks. See the bug description for a concrete case. The solution is to avoid checking for suspend requests when using the TBIVM wrapper. The original patch was actually written by @robehn(now on vacations) and I only made small changes. >> >> Tested in mach5 tiers1-7. I also verified that the new added test SuspendBlocked.java deadlocks with the current bits and passes with this patch. >> >> Thanks, >> >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > remove /testlibrary from SuspendBlocked.java While chatting with Coleen I realized the comment in should_process_no_suspend() wasn't accurate so I fixed it. Not necessarily there will be a suspend request when reaching that path. The poll could be armed just because a safepoint or a non-suspend handshake operation was executed while the thread was safepoint safe. ------------- PR: https://git.openjdk.java.net/jdk17/pull/257 From dcubed at openjdk.java.net Wed Jul 21 21:40:49 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Jul 2021 21:40:49 GMT Subject: [jdk17] RFR: 8270085: Suspend during block transition may deadlock if lock held [v3] In-Reply-To: References: Message-ID: <85wtN4jVHfizXbqsWErqitELl491UEqf0GC7vJYqztY=.313ed992-5416-4e3c-ac73-f88be0d45d90@github.com> On Wed, 21 Jul 2021 21:25:23 GMT, Patricio Chilano Mateo wrote: >> Hi all, >> >> The following patch fixes deadlocks issues that could occur when checking for suspension while holding VM locks. See the bug description for a concrete case. The solution is to avoid checking for suspend requests when using the TBIVM wrapper. The original patch was actually written by @robehn(now on vacations) and I only made small changes. >> >> Tested in mach5 tiers1-7. I also verified that the new added test SuspendBlocked.java deadlocks with the current bits and passes with this patch. >> >> Thanks, >> >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > fix comment in should_process_no_suspend() Thanks for adjusting the comment. Still good. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/257 From coleenp at openjdk.java.net Wed Jul 21 22:03:48 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 21 Jul 2021 22:03:48 GMT Subject: [jdk17] RFR: 8270085: Suspend during block transition may deadlock if lock held [v3] In-Reply-To: References: <82iEKClghjBigalWMHHUApIO-Uugmaw5GpWzMYDaROM=.0ea40bce-3749-45f9-9172-3a05c93bfd0d@github.com> Message-ID: On Wed, 21 Jul 2021 16:58:07 GMT, Patricio Chilano Mateo wrote: >> We should document the order of events why this code is needed in a future RFE, because this comment doesn't really explain it to me and knowing where to put all these process_if_requested() and process() calls is far from obvious. I believe you and Robbin, but there are too many mysteries. > > I commented the line and run all the serviceability/ tests to look for issues. The only test that failed was SuspendWithCurrentThread.java due to the recent 8264663 change (https://github.com/openjdk/jdk/commit/b5c6351315eeec64fe9c06fc7c8719efa08dc8a6). The patch aimed to verify that the self-suspending thread actually suspended and didn't exited, but the check is too restrictive because it doesn't consider that the JT will still suspend when going back to Java. That check can be moved to Java to verify the suspender didn't return from suspendTestedThreads(). > Maybe I should do that in another RFE along with removing this code? Yes, that would be good to clear up in a future RFE. ------------- PR: https://git.openjdk.java.net/jdk17/pull/257 From iignatyev at openjdk.java.net Wed Jul 21 23:11:12 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 21 Jul 2021 23:11:12 GMT Subject: [jdk17] RFR: 8271093: remove deadcode from runtime/Thread/TestThreadDumpSMRInfo.java test Message-ID: Hi all, could you please review this trivial test-only clean-up? from JBS: > TestThreadDumpSMRInfo::usage isn't used by anyone and should be removed PS alternatively, `TestThreadDumpSMRInfo::usage` can be called in an else branch at L70, but I don't see much point in that Thanks, -- Igor ------------- Commit messages: - 8271093 Changes: https://git.openjdk.java.net/jdk17/pull/265/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=265&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271093 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/265.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/265/head:pull/265 PR: https://git.openjdk.java.net/jdk17/pull/265 From jiefu at openjdk.java.net Wed Jul 21 23:22:47 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 21 Jul 2021 23:22:47 GMT Subject: [jdk17] RFR: 8271093: remove deadcode from runtime/Thread/TestThreadDumpSMRInfo.java test In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 23:03:46 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial test-only clean-up? > from JBS: >> TestThreadDumpSMRInfo::usage isn't used by anyone and should be removed > > > PS alternatively, `TestThreadDumpSMRInfo::usage` can be called in an else branch at L70, but I don't see much point in that > > Thanks, > -- Igor Hi @iignatev , I'm not sure changes like this should go into jdk17 since we are already in RDP2 [1]. Thanks. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-July/005758.html ------------- PR: https://git.openjdk.java.net/jdk17/pull/265 From iignatyev at openjdk.java.net Wed Jul 21 23:26:48 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 21 Jul 2021 23:26:48 GMT Subject: [jdk17] RFR: 8271093: remove deadcode from runtime/Thread/TestThreadDumpSMRInfo.java test In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 23:19:30 GMT, Jie Fu wrote: >> Hi all, >> >> could you please review this trivial test-only clean-up? >> from JBS: >>> TestThreadDumpSMRInfo::usage isn't used by anyone and should be removed >> >> >> PS alternatively, `TestThreadDumpSMRInfo::usage` can be called in an else branch at L70, but I don't see much point in that >> >> Thanks, >> -- Igor > > Hi @iignatev , > > I'm not sure changes like this should go into jdk17 since we are already in RDP2 [1]. > Thanks. > > [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-July/005758.html Hi @DamonFool , according to JEP3, P1?P5 doc/test bugs are allowed in RDP2[1] and do not require approval. so I don't see any reason why it should not go into jdk17. Thanks, -- Igor [1] https://openjdk.java.net/jeps/3#rdp-2 [2] https://openjdk.java.net/jeps/3#Test-and-documentation-bugs ------------- PR: https://git.openjdk.java.net/jdk17/pull/265 From iignatyev at openjdk.java.net Wed Jul 21 23:27:00 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 21 Jul 2021 23:27:00 GMT Subject: [jdk17] RFR: 8271094: runtime/duplAttributes/DuplAttributesTest.java doesn't check exit code Message-ID: Hi all, could you please review this trivial test-only patch that adds a check of the exit code to `runtime/duplAttributes/DuplAttributesTest.java` test? Thanks, -- Igor ------------- Commit messages: - 8271094 Changes: https://git.openjdk.java.net/jdk17/pull/266/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=266&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271094 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/266.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/266/head:pull/266 PR: https://git.openjdk.java.net/jdk17/pull/266 From jiefu at openjdk.java.net Wed Jul 21 23:31:48 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 21 Jul 2021 23:31:48 GMT Subject: [jdk17] RFR: 8271093: remove deadcode from runtime/Thread/TestThreadDumpSMRInfo.java test In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 23:03:46 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial test-only clean-up? > from JBS: >> TestThreadDumpSMRInfo::usage isn't used by anyone and should be removed > > > PS alternatively, `TestThreadDumpSMRInfo::usage` can be called in an else branch at L70, but I don't see much point in that > > Thanks, > -- Igor Looks good and trivial. Thanks. ------------- Marked as reviewed by jiefu (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/265 From jiefu at openjdk.java.net Wed Jul 21 23:31:49 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 21 Jul 2021 23:31:49 GMT Subject: [jdk17] RFR: 8271093: remove deadcode from runtime/Thread/TestThreadDumpSMRInfo.java test In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 23:24:06 GMT, Igor Ignatyev wrote: > according to JEP3, P1?P5 doc/test bugs are allowed in RDP2[1] and do not require approval. so I don't see any reason why it should not go into jdk17. Okay, I see. ------------- PR: https://git.openjdk.java.net/jdk17/pull/265 From jiefu at openjdk.java.net Wed Jul 21 23:33:45 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 21 Jul 2021 23:33:45 GMT Subject: [jdk17] RFR: 8271094: runtime/duplAttributes/DuplAttributesTest.java doesn't check exit code In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 23:19:31 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial test-only patch that adds a check of the exit code to `runtime/duplAttributes/DuplAttributesTest.java` test? > > Thanks, > -- Igor Looks good and trivial. Thanks. ------------- Marked as reviewed by jiefu (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/266 From dholmes at openjdk.java.net Thu Jul 22 01:36:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Jul 2021 01:36:55 GMT Subject: [jdk17] RFR: 8270085: Suspend during block transition may deadlock if lock held [v3] In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 21:25:23 GMT, Patricio Chilano Mateo wrote: >> Hi all, >> >> The following patch fixes deadlocks issues that could occur when checking for suspension while holding VM locks. See the bug description for a concrete case. The solution is to avoid checking for suspend requests when using the TBIVM wrapper. The original patch was actually written by @robehn(now on vacations) and I only made small changes. >> >> Tested in mach5 tiers1-7. I also verified that the new added test SuspendBlocked.java deadlocks with the current bits and passes with this patch. >> >> Thanks, >> >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > fix comment in should_process_no_suspend() Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/257 From dholmes at openjdk.java.net Thu Jul 22 01:40:47 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Jul 2021 01:40:47 GMT Subject: [jdk17] RFR: 8271093: remove deadcode from runtime/Thread/TestThreadDumpSMRInfo.java test In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 23:03:46 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial test-only clean-up? > from JBS: >> TestThreadDumpSMRInfo::usage isn't used by anyone and should be removed > > > PS alternatively, `TestThreadDumpSMRInfo::usage` can be called in an else branch at L70, but I don't see much point in that > > Thanks, > -- Igor LGTM. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/265 From dholmes at openjdk.java.net Thu Jul 22 01:42:01 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Jul 2021 01:42:01 GMT Subject: [jdk17] RFR: 8271094: runtime/duplAttributes/DuplAttributesTest.java doesn't check exit code In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 23:19:31 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial test-only patch that adds a check of the exit code to `runtime/duplAttributes/DuplAttributesTest.java` test? > > Thanks, > -- Igor LGTM. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/266 From stuefe at openjdk.java.net Thu Jul 22 04:10:52 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 22 Jul 2021 04:10:52 GMT Subject: Integrated: JDK-8268893: jcmd to trim the glibc heap In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 12:57:44 GMT, Thomas Stuefe wrote: > Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process. > > > The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not. > > This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes. > > The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System. > > This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day. > > Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes: > - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory > - as a stop gap measure it allows to release pressure from a high footprint scenario. > > Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT. > > I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd. > > CSR for this command: https://bugs.openjdk.java.net/browse/JDK-8269345 > > Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later. > > ========= > > This patch: > > - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms. > - includes a (rather basic) test > - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space) > - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information. > > ========= > > Example: > > A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc: > > > > thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident > Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K) > ^^^^^^^^ > > > We execute the new trim command via jcmd: > > > thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap > 18770: > Attempting trim... > Done. > Virtual size before: 28849744k, after: 28849724k, (-20k) > RSS before: 8685896k, after: 920740k, (-7765156k) <<<< > Swap before: 0k, after: 0k, (0k) > > > It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory: > > > thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident > Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K) > ^^^^^^^ > > > When the VM is started with -Xlog:os, this is also logged: > > > [139,068s][info][os] malloc_trim: > [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k) > RSS before: 8685896k, after: 920740k, (-7765156k) > Swap before: 0k, after: 0k, (0k) This pull request has now been integrated. Changeset: 6096dd97 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/6096dd9765eaf280890f65c0ff1ab64864b9316a Stats: 248 lines in 6 files changed: 222 ins; 9 del; 17 mod 8268893: jcmd to trim the glibc heap Reviewed-by: simonis, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/4510 From cgo at openjdk.java.net Thu Jul 22 07:57:50 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Thu, 22 Jul 2021 07:57:50 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 13:17:58 GMT, Christoph G?ttschkes wrote: > Hi, > > please review this fix for the template interpreter for ARM32-softfp. > > With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. > > https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 > > I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. > > Old ldc2_w implementation (before condy was implemented for ARM32): > > https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 > > Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 @dholmes-ora or @coleenp, could you maybe have a look at this, since you already looked into #4582? ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From alanb at openjdk.java.net Thu Jul 22 08:30:52 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 22 Jul 2021 08:30:52 GMT Subject: RFR: 8260265: UTF-8 by Default [v6] In-Reply-To: References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com> Message-ID: On Wed, 21 Jul 2021 17:34:15 GMT, Naoto Sato wrote: >> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted. >> >> JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8260266 > > Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Merge branch 'master' into JDK-8260265 > - Refined `file.encoding` description > - Merge branch 'master' into JDK-8260265 > - Reflects comments > - Removed leftover `console` references in `PrintStream` > - Reflects comments > - Reflects review comments > - Merge branch 'master' into JDK-8260265 > - 8260265: UTF-8 by Default Thanks for incorporating the suggestion for the getProperties text. I think it looks good now. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4733 From dholmes at openjdk.java.net Thu Jul 22 09:58:45 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Jul 2021 09:58:45 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 07:55:16 GMT, Christoph G?ttschkes wrote: >> Hi, >> >> please review this fix for the template interpreter for ARM32-softfp. >> >> With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. >> >> https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 >> >> I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. >> >> Old ldc2_w implementation (before condy was implemented for ARM32): >> >> https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 >> >> Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 > > @dholmes-ora or @coleenp, could you maybe have a look at this, since you already looked into #4582? Sorry @mychris I never noticed this PR mail. I have taken a look and the logic seems sounds to me but I'm no expert at writing ARM code so I can't really approve it in detail. David ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From dcubed at openjdk.java.net Thu Jul 22 14:08:10 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Jul 2021 14:08:10 GMT Subject: [jdk17] Integrated: 8271126: ProblemList runtime/InvocationTests/invokevirtualTests.java Message-ID: A trivial fix to ProblemList runtime/InvocationTests/invokevirtualTests.java. ------------- Commit messages: - 8271126: ProblemList runtime/InvocationTests/invokevirtualTests.java Changes: https://git.openjdk.java.net/jdk17/pull/268/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=268&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271126 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/268.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/268/head:pull/268 PR: https://git.openjdk.java.net/jdk17/pull/268 From dcubed at openjdk.java.net Thu Jul 22 14:08:11 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Jul 2021 14:08:11 GMT Subject: [jdk17] Integrated: 8271126: ProblemList runtime/InvocationTests/invokevirtualTests.java In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 13:41:20 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList runtime/InvocationTests/invokevirtualTests.java. This pull request has now been integrated. Changeset: 39b486db Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk17/commit/39b486db6d83605deb8e49536892e0bc461b4531 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8271126: ProblemList runtime/InvocationTests/invokevirtualTests.java Backport-of: d1257d54f9352fa84207036d14b764a1244a9545 ------------- PR: https://git.openjdk.java.net/jdk17/pull/268 From pchilanomate at openjdk.java.net Thu Jul 22 14:30:48 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 22 Jul 2021 14:30:48 GMT Subject: [jdk17] RFR: 8270085: Suspend during block transition may deadlock if lock held [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 01:34:01 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> fix comment in should_process_no_suspend() > > Marked as reviewed by dholmes (Reviewer). Thanks @dholmes-ora, @dcubed-ojdk and @coleenp for the reviews! ------------- PR: https://git.openjdk.java.net/jdk17/pull/257 From pchilanomate at openjdk.java.net Thu Jul 22 14:33:55 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 22 Jul 2021 14:33:55 GMT Subject: [jdk17] Integrated: 8270085: Suspend during block transition may deadlock if lock held In-Reply-To: References: Message-ID: <7FGjvoL1_6TNkfiKcOhGyG_T_J18JTamC8ly8yGZNto=.63b0c3c4-2ae1-4b7d-a56c-91146b698609@github.com> On Tue, 20 Jul 2021 20:06:12 GMT, Patricio Chilano Mateo wrote: > Hi all, > > The following patch fixes deadlocks issues that could occur when checking for suspension while holding VM locks. See the bug description for a concrete case. The solution is to avoid checking for suspend requests when using the TBIVM wrapper. The original patch was actually written by @robehn(now on vacations) and I only made small changes. > > Tested in mach5 tiers1-7. I also verified that the new added test SuspendBlocked.java deadlocks with the current bits and passes with this patch. > > Thanks, > > Patricio This pull request has now been integrated. Changeset: e7f90093 Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk17/commit/e7f9009315f1fdf33d6539c413c224f925c9ffb0 Stats: 219 lines in 9 files changed: 157 ins; 35 del; 27 mod 8270085: Suspend during block transition may deadlock if lock held Co-authored-by: Robbin Ehn Co-authored-by: Patricio Chilano Mateo Reviewed-by: dcubed, dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk17/pull/257 From dcubed at openjdk.java.net Thu Jul 22 15:37:55 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Jul 2021 15:37:55 GMT Subject: [jdk17] RFR: 8271093: remove deadcode from runtime/Thread/TestThreadDumpSMRInfo.java test In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 23:03:46 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial test-only clean-up? > from JBS: >> TestThreadDumpSMRInfo::usage isn't used by anyone and should be removed > > > PS alternatively, `TestThreadDumpSMRInfo::usage` can be called in an else branch at L70, but I don't see much point in that > > Thanks, > -- Igor Thumbs up. Looks good to me also. I usually have those usage() calls in with the argument processing logic. The proper place is in an else branch at L70 (as you mentioned). I wonder if I forgot to do it or if I somehow lost those lines before integrating the test (so very long ago...). ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/265 From iignatyev at openjdk.java.net Thu Jul 22 17:07:05 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 17:07:05 GMT Subject: [jdk17] RFR: 8271093: remove deadcode from runtime/Thread/TestThreadDumpSMRInfo.java test In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 23:03:46 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial test-only clean-up? > from JBS: >> TestThreadDumpSMRInfo::usage isn't used by anyone and should be removed > > > PS alternatively, `TestThreadDumpSMRInfo::usage` can be called in an else branch at L70, but I don't see much point in that > > Thanks, > -- Igor thank you all for your reviews! ------------- PR: https://git.openjdk.java.net/jdk17/pull/265 From iignatyev at openjdk.java.net Thu Jul 22 17:07:31 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 17:07:31 GMT Subject: [jdk17] RFR: 8271094: runtime/duplAttributes/DuplAttributesTest.java doesn't check exit code In-Reply-To: References: Message-ID: <65_eXB7iSmMQdDW_bSPCNsqj1HKrmbnbh86woQhA2AU=.dc3ac0c7-1580-4156-af46-6ef291d26ab2@github.com> On Wed, 21 Jul 2021 23:19:31 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial test-only patch that adds a check of the exit code to `runtime/duplAttributes/DuplAttributesTest.java` test? > > Thanks, > -- Igor David and Jie, thank you for your reviews. ------------- PR: https://git.openjdk.java.net/jdk17/pull/266 From iignatyev at openjdk.java.net Thu Jul 22 17:17:09 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 17:17:09 GMT Subject: [jdk17] Integrated: 8271093: remove deadcode from runtime/Thread/TestThreadDumpSMRInfo.java test In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 23:03:46 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial test-only clean-up? > from JBS: >> TestThreadDumpSMRInfo::usage isn't used by anyone and should be removed > > > PS alternatively, `TestThreadDumpSMRInfo::usage` can be called in an else branch at L70, but I don't see much point in that > > Thanks, > -- Igor This pull request has now been integrated. Changeset: 6a9ab6a2 Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk17/commit/6a9ab6a2cf5b341adf3cb6bc3e8a287db265c2a1 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod 8271093: remove deadcode from runtime/Thread/TestThreadDumpSMRInfo.java test Reviewed-by: jiefu, dholmes, dcubed ------------- PR: https://git.openjdk.java.net/jdk17/pull/265 From iignatyev at openjdk.java.net Thu Jul 22 17:18:12 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 17:18:12 GMT Subject: [jdk17] Integrated: 8271094: runtime/duplAttributes/DuplAttributesTest.java doesn't check exit code In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 23:19:31 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial test-only patch that adds a check of the exit code to `runtime/duplAttributes/DuplAttributesTest.java` test? > > Thanks, > -- Igor This pull request has now been integrated. Changeset: 4812e537 Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk17/commit/4812e537919dc1b1c08a2a8ddc0c9cb1c69a7744 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8271094: runtime/duplAttributes/DuplAttributesTest.java doesn't check exit code Reviewed-by: jiefu, dholmes ------------- PR: https://git.openjdk.java.net/jdk17/pull/266 From iignatyev at openjdk.java.net Thu Jul 22 19:19:25 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 19:19:25 GMT Subject: [jdk17] RFR: 8271158: runtime/handshake/HandshakeTimeoutTest.java test doesn't check exit code Message-ID: Hi all, could you please review this one-liner that adds an exit code check to `runtime/handshake/HandshakeTimeoutTest.java` test? Thanks, -- Igor ------------- Commit messages: - 8271158 Changes: https://git.openjdk.java.net/jdk17/pull/270/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=270&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271158 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/270.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/270/head:pull/270 PR: https://git.openjdk.java.net/jdk17/pull/270 From dcubed at openjdk.java.net Thu Jul 22 19:36:04 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Jul 2021 19:36:04 GMT Subject: [jdk17] RFR: 8271158: runtime/handshake/HandshakeTimeoutTest.java test doesn't check exit code In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 19:12:27 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this one-liner that adds an exit code check to `runtime/handshake/HandshakeTimeoutTest.java` test? > > Thanks, > -- Igor Changes requested by dcubed (Reviewer). test/hotspot/jtreg/runtime/handshake/HandshakeTimeoutTest.java line 63: > 61: output.reportDiagnosticSummary(); > 62: // In rare cases the target wakes up and performs the handshake at the same time as we timeout. > 63: // Therefore it's not certain the timeout will find any thread. The comment on L62-63 indicates that this line: L64: output.shouldMatch("has not cleared handshake op|No thread with an unfinished handshake op"); will sometimes finish with "No thread with an unfinished handshake op". In that case, won't the test finish with an exit code of zero? If I'm right about that, you've introduced a rare case where the test will fail (because the exit code is 0) when it would have passed before. ------------- PR: https://git.openjdk.java.net/jdk17/pull/270 From mseledtsov at openjdk.java.net Thu Jul 22 19:44:20 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Thu, 22 Jul 2021 19:44:20 GMT Subject: [jdk17] RFR: 8269037: jsig/Testjsig.java doesn't have to be restricted to linux only In-Reply-To: References: Message-ID: On Sun, 20 Jun 2021 11:08:21 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that enables `runtime/jsig/Testjsig.java` test and compilation of its native library on all platforms but windows? > from JBS: >> `runtime/jsig/Testjsig.java` test currently `@requires (os.family == "linux")` and `test/hotspot/jtreg/runtime/jsig/libTestJNI.c` compilation is resticted to linux only, howere there seems to be nothing in the test code that prevents it from execution on a system that supports POSIX. > > testing: `runtime/jsig/Testjsig.java` on `{linux,windows,macosx}-x64` > > > Thanks, > -- Igor Looks good to me ------------- Marked as reviewed by mseledtsov (Committer). PR: https://git.openjdk.java.net/jdk17/pull/105 From iignatyev at openjdk.java.net Thu Jul 22 19:47:10 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 19:47:10 GMT Subject: [jdk17] RFR: 8271158: runtime/handshake/HandshakeTimeoutTest.java test doesn't check exit code In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 19:28:17 GMT, Daniel D. Daugherty wrote: >> Hi all, >> >> could you please review this one-liner that adds an exit code check to `runtime/handshake/HandshakeTimeoutTest.java` test? >> >> Thanks, >> -- Igor > > test/hotspot/jtreg/runtime/handshake/HandshakeTimeoutTest.java line 63: > >> 61: output.reportDiagnosticSummary(); >> 62: // In rare cases the target wakes up and performs the handshake at the same time as we timeout. >> 63: // Therefore it's not certain the timeout will find any thread. > > The comment on L62-63 indicates that this line: > > L64: output.shouldMatch("has not cleared handshake op|No thread with an unfinished handshake op"); > > will sometimes finish with "No thread with an unfinished handshake op". In that case, > won't the test finish with an exit code of zero? > > If I'm right about that, you've introduced a rare case where the test will > fail (because the exit code is 0) when it would have passed before. given `HandshakeTimeoutTest$Test` will work till it crashes, its exit code can't be 0. which, I *guess*, means we will always have "has not cleared handshake op". ------------- PR: https://git.openjdk.java.net/jdk17/pull/270 From iignatyev at openjdk.java.net Thu Jul 22 19:54:06 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 19:54:06 GMT Subject: [jdk17] RFR: 8271158: runtime/handshake/HandshakeTimeoutTest.java test doesn't check exit code In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 19:43:46 GMT, Igor Ignatyev wrote: >> test/hotspot/jtreg/runtime/handshake/HandshakeTimeoutTest.java line 63: >> >>> 61: output.reportDiagnosticSummary(); >>> 62: // In rare cases the target wakes up and performs the handshake at the same time as we timeout. >>> 63: // Therefore it's not certain the timeout will find any thread. >> >> The comment on L62-63 indicates that this line: >> >> L64: output.shouldMatch("has not cleared handshake op|No thread with an unfinished handshake op"); >> >> will sometimes finish with "No thread with an unfinished handshake op". In that case, >> won't the test finish with an exit code of zero? >> >> If I'm right about that, you've introduced a rare case where the test will >> fail (because the exit code is 0) when it would have passed before. > > given `HandshakeTimeoutTest$Test` will work till it crashes, its exit code can't be 0. which, I *guess*, means we will always have "has not cleared handshake op". actually, both `No thread with an unfinished handshake op` and `has not cleared handshake op` lead to a call of `fatal()`: ```open/src/hotspot/share/runtime/handshake.cpp: 180 static void handle_timeout(HandshakeOperation* op, JavaThread* target) { 181 JavaThreadIteratorWithHandle jtiwh; 182 183 log_error(handshake)("Handshake timeout: %s(" INTPTR_FORMAT "), pending threads: " INT32_FORMAT, 184 op->name(), p2i(op), op->pending_threads()); 185 186 if (target == NULL) { 187 for ( ; JavaThread* thr = jtiwh.next(); ) { 188 if (thr->handshake_state()->operation_pending(op)) { 189 log_error(handshake)("JavaThread " INTPTR_FORMAT " has not cleared handshake op: " INTPTR_FORMAT, p2i(thr), p2i(op)); 190 // Remember the last one found for more diagnostics below. 191 target = thr; 192 } 193 } 194 } else { 195 log_error(handshake)("JavaThread " INTPTR_FORMAT " has not cleared handshake op: " INTPTR_FORMAT, p2i(target), p2i(op)); 196 } 197 198 if (target != NULL) { 199 if (os::signal_thread(target, SIGILL, "cannot be handshaked")) { 200 // Give target a chance to report the error and terminate the VM. 201 os::naked_sleep(3000); 202 } 203 } else { 204 log_error(handshake)("No thread with an unfinished handshake op(" INTPTR_FORMAT ") found.", p2i(op)); 205 } 206 fatal("Handshake timeout"); 207 } ------------- PR: https://git.openjdk.java.net/jdk17/pull/270 From iignatyev at openjdk.java.net Thu Jul 22 20:13:49 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 20:13:49 GMT Subject: [jdk17] RFR: 8271160: runtime/jni/checked/TestCheckedJniExceptionCheck.java doesn't set -Djava.library.path Message-ID: Hi all, could you please review this small patch that sets `-Djava.library.path` to ` test.nativepath` for `TestCheckedJniExceptionCheck`'s child JVM so it will be able to locate the library? from JBS: > TestCheckedJniExceptionCheck spawns a child JVM that uses a test native library, TestCheckedJniExceptionCheck, but it doesn't add/set test.nativepath value to -Djava.library.path, so the child JVM can't find the library and fails. > > this issue hasn't been noticed early b/c TestCheckedJniExceptionCheck doesn't check the exit code of the child JVM. Thanks, -- Igor ------------- Commit messages: - check exit code - fixed import - reformat code - propagate -Djava.library.path Changes: https://git.openjdk.java.net/jdk17/pull/273/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=273&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271160 Stats: 9 lines in 1 file changed: 3 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk17/pull/273.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/273/head:pull/273 PR: https://git.openjdk.java.net/jdk17/pull/273 From dcubed at openjdk.java.net Thu Jul 22 20:16:05 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Jul 2021 20:16:05 GMT Subject: [jdk17] RFR: 8271158: runtime/handshake/HandshakeTimeoutTest.java test doesn't check exit code In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 19:12:27 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this one-liner that adds an exit code check to `runtime/handshake/HandshakeTimeoutTest.java` test? > > Thanks, > -- Igor Thanks for digging up the code that generates those mesgs! I agree with your analysis. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/270 From iignatyev at openjdk.java.net Thu Jul 22 21:00:09 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 21:00:09 GMT Subject: [jdk17] RFR: 8271160: runtime/jni/checked/TestCheckedJniExceptionCheck.java doesn't set -Djava.library.path In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 20:07:09 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that sets `-Djava.library.path` to ` test.nativepath` for `TestCheckedJniExceptionCheck`'s child JVM so it will be able to locate the library? > > from JBS: >> TestCheckedJniExceptionCheck spawns a child JVM that uses a test native library, TestCheckedJniExceptionCheck, but it doesn't add/set test.nativepath value to -Djava.library.path, so the child JVM can't find the library and fails. >> >> this issue hasn't been noticed early b/c TestCheckedJniExceptionCheck doesn't check the exit code of the child JVM. > > Thanks, > -- Igor Thanks, Dan. as I usually do for similar changes, I just run the changed test on `{linux,windows,macos}-x64` in OOB configuration. ------------- PR: https://git.openjdk.java.net/jdk17/pull/273 From dcubed at openjdk.java.net Thu Jul 22 21:00:09 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Jul 2021 21:00:09 GMT Subject: [jdk17] RFR: 8271160: runtime/jni/checked/TestCheckedJniExceptionCheck.java doesn't set -Djava.library.path In-Reply-To: References: Message-ID: <5UhpjIXXokBAMZtva49Lx-Ox1weqtSvcxB_i83vu248=.8b1d93d0-63d0-4224-ab15-0fe88c033c2f@github.com> On Thu, 22 Jul 2021 20:07:09 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that sets `-Djava.library.path` to ` test.nativepath` for `TestCheckedJniExceptionCheck`'s child JVM so it will be able to locate the library? > > from JBS: >> TestCheckedJniExceptionCheck spawns a child JVM that uses a test native library, TestCheckedJniExceptionCheck, but it doesn't add/set test.nativepath value to -Djava.library.path, so the child JVM can't find the library and fails. >> >> this issue hasn't been noticed early b/c TestCheckedJniExceptionCheck doesn't check the exit code of the child JVM. > > Thanks, > -- Igor Thumbs up on the changes. What kind of testing has been done? I don't see any testing details in the PR. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/273 From dcubed at openjdk.java.net Thu Jul 22 21:20:04 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Jul 2021 21:20:04 GMT Subject: [jdk17] RFR: 8271160: runtime/jni/checked/TestCheckedJniExceptionCheck.java doesn't set -Djava.library.path In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 20:07:09 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that sets `-Djava.library.path` to ` test.nativepath` for `TestCheckedJniExceptionCheck`'s child JVM so it will be able to locate the library? > > from JBS: >> TestCheckedJniExceptionCheck spawns a child JVM that uses a test native library, TestCheckedJniExceptionCheck, but it doesn't add/set test.nativepath value to -Djava.library.path, so the child JVM can't find the library and fails. >> >> this issue hasn't been noticed early b/c TestCheckedJniExceptionCheck doesn't check the exit code of the child JVM. > > Thanks, > -- Igor Thanks for the testing info! ------------- PR: https://git.openjdk.java.net/jdk17/pull/273 From iignatyev at openjdk.java.net Thu Jul 22 21:42:23 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 21:42:23 GMT Subject: [jdk17] RFR: 8271162: runtime/StackTrace/LargeClassTest.java can be run in driver mode Message-ID: Hi all, could you please review this small and trivial patch that changes `LargeClassTest` to be executed in a driver mode and removes the redundant, due to an implicit `@build` action associated with `@run`, `@compile` action? testing: `runtime/StackTrace/LargeClassTest.java` on `{linux,windows,macos}-x64` Thanks, -- Igor ------------- Commit messages: - 8271162 Changes: https://git.openjdk.java.net/jdk17/pull/274/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=274&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271162 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/274.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/274/head:pull/274 PR: https://git.openjdk.java.net/jdk17/pull/274 From dholmes at openjdk.java.net Thu Jul 22 21:49:14 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Jul 2021 21:49:14 GMT Subject: [jdk17] RFR: 8271160: runtime/jni/checked/TestCheckedJniExceptionCheck.java doesn't set -Djava.library.path In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 20:07:09 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that sets `-Djava.library.path` to ` test.nativepath` for `TestCheckedJniExceptionCheck`'s child JVM so it will be able to locate the library? > > from JBS: >> TestCheckedJniExceptionCheck spawns a child JVM that uses a test native library, TestCheckedJniExceptionCheck, but it doesn't add/set test.nativepath value to -Djava.library.path, so the child JVM can't find the library and fails. >> >> this issue hasn't been noticed early b/c TestCheckedJniExceptionCheck doesn't check the exit code of the child JVM. > > Thanks, > -- Igor I don't have any issues with the change, but I will point out that this is another case of being bitten by jtreg's differing behaviour in agent mode and non-agent mode. Default execution locally works perfectly fine because the default mode will also set LD_LIBRARY_PATH in the environment and so the child VM works correctly. Whereas the jtreg mode used in our CI testing doesn't. I also don't think the lack of checking for a zero exit code would cause this to spuriously pass either as there is expected output that would not be found if the test failed with UnsatisfiedLinkException due to the native library. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/273 From dholmes at openjdk.java.net Thu Jul 22 21:57:09 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Jul 2021 21:57:09 GMT Subject: [jdk17] RFR: 8271160: runtime/jni/checked/TestCheckedJniExceptionCheck.java doesn't set -Djava.library.path In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 20:07:09 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that sets `-Djava.library.path` to ` test.nativepath` for `TestCheckedJniExceptionCheck`'s child JVM so it will be able to locate the library? > > from JBS: >> TestCheckedJniExceptionCheck spawns a child JVM that uses a test native library, TestCheckedJniExceptionCheck, but it doesn't add/set test.nativepath value to -Djava.library.path, so the child JVM can't find the library and fails. >> >> this issue hasn't been noticed early b/c TestCheckedJniExceptionCheck doesn't check the exit code of the child JVM. > > Thanks, > -- Igor No I am wrong - the test does spuriously pass if the library is not found. Interesting ... ------------- PR: https://git.openjdk.java.net/jdk17/pull/273 From iignatyev at openjdk.java.net Thu Jul 22 21:57:09 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 21:57:09 GMT Subject: [jdk17] RFR: 8271160: runtime/jni/checked/TestCheckedJniExceptionCheck.java doesn't set -Djava.library.path In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 21:46:12 GMT, David Holmes wrote: > I also don't think the lack of checking for a zero exit code would cause this to spuriously pass either as there is expected output that would not be found if the test failed with UnsatisfiedLinkException due to the native library. Hi David, the lack of checking is exactly how I found this issue. the test passed as it skipped all its checks in `checkOuputForCorrectWarnings` b/c it didn't meet "TEST STARTED" line. I guess we can improve `checkOuputForCorrectWarnings` to be more rigid in its check. Thanks, -- Igor ------------- PR: https://git.openjdk.java.net/jdk17/pull/273 From dholmes at openjdk.java.net Thu Jul 22 22:00:10 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Jul 2021 22:00:10 GMT Subject: [jdk17] RFR: 8271160: runtime/jni/checked/TestCheckedJniExceptionCheck.java doesn't set -Djava.library.path In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 20:07:09 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that sets `-Djava.library.path` to ` test.nativepath` for `TestCheckedJniExceptionCheck`'s child JVM so it will be able to locate the library? > > from JBS: >> TestCheckedJniExceptionCheck spawns a child JVM that uses a test native library, TestCheckedJniExceptionCheck, but it doesn't add/set test.nativepath value to -Djava.library.path, so the child JVM can't find the library and fails. >> >> this issue hasn't been noticed early b/c TestCheckedJniExceptionCheck doesn't check the exit code of the child JVM. > > Thanks, > -- Igor Right - I was just looking at that. The test should fail if the start line is not found. ------------- PR: https://git.openjdk.java.net/jdk17/pull/273 From iignatyev at openjdk.java.net Thu Jul 22 22:14:23 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 22:14:23 GMT Subject: [jdk17] RFR: 8271169: runtime/Safepoint/TestAbortVMOnSafepointTimeout.java can be run in driver mode Message-ID: <0dNEomkBK6jl-WBGKz37dpPrSLO-b7ObgyZQjkON4r4=.39b309e9-ad04-4b98-835d-2565473761ed@github.com> Hi all, could you please review this small and trivial test-only patch? from JBS: > `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` uses `main/othervm` so `TestAbortVMOnSafepointTimeout` is run w/ the flags required for WhiteBox API, yet `TestAbortVMOnSafepointTimeout` doesn't use WhiteBox API and can be run in driver mode. testing: `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` on `{linux,windows,macos}-x64` Thanks, -- Igor ------------- Commit messages: - 8271169 Changes: https://git.openjdk.java.net/jdk17/pull/275/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=275&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271169 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/275.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/275/head:pull/275 PR: https://git.openjdk.java.net/jdk17/pull/275 From iignatyev at openjdk.java.net Thu Jul 22 22:19:34 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 22:19:34 GMT Subject: [jdk17] RFR: 8271160: runtime/jni/checked/TestCheckedJniExceptionCheck.java doesn't set -Djava.library.path [v2] In-Reply-To: References: Message-ID: > Hi all, > > could you please review this small patch that sets `-Djava.library.path` to ` test.nativepath` for `TestCheckedJniExceptionCheck`'s child JVM so it will be able to locate the library? > > from JBS: >> TestCheckedJniExceptionCheck spawns a child JVM that uses a test native library, TestCheckedJniExceptionCheck, but it doesn't add/set test.nativepath value to -Djava.library.path, so the child JVM can't find the library and fails. >> >> this issue hasn't been noticed early b/c TestCheckedJniExceptionCheck doesn't check the exit code of the child JVM. > > Thanks, > -- Igor Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision: check that TEST_START has been met ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/273/files - new: https://git.openjdk.java.net/jdk17/pull/273/files/ff884103..c95674f6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=273&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=273&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/273.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/273/head:pull/273 PR: https://git.openjdk.java.net/jdk17/pull/273 From dholmes at openjdk.java.net Thu Jul 22 22:19:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Jul 2021 22:19:36 GMT Subject: [jdk17] RFR: 8271160: runtime/jni/checked/TestCheckedJniExceptionCheck.java doesn't set -Djava.library.path [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 22:15:43 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this small patch that sets `-Djava.library.path` to ` test.nativepath` for `TestCheckedJniExceptionCheck`'s child JVM so it will be able to locate the library? >> >> from JBS: >>> TestCheckedJniExceptionCheck spawns a child JVM that uses a test native library, TestCheckedJniExceptionCheck, but it doesn't add/set test.nativepath value to -Djava.library.path, so the child JVM can't find the library and fails. >>> >>> this issue hasn't been noticed early b/c TestCheckedJniExceptionCheck doesn't check the exit code of the child JVM. >> >> Thanks, >> -- Igor > > Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision: > > check that TEST_START has been met Update looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/273 From iignatyev at openjdk.java.net Thu Jul 22 22:19:38 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 22:19:38 GMT Subject: [jdk17] RFR: 8271160: runtime/jni/checked/TestCheckedJniExceptionCheck.java doesn't set -Djava.library.path In-Reply-To: References: Message-ID: <6K-fb_H--Sg6Gk1K0_imcQtk1FuKasErj_B6OnDn-Hk=.155a2055-0864-45d3-8d33-73fb54f9125b@github.com> On Thu, 22 Jul 2021 20:07:09 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that sets `-Djava.library.path` to ` test.nativepath` for `TestCheckedJniExceptionCheck`'s child JVM so it will be able to locate the library? > > from JBS: >> TestCheckedJniExceptionCheck spawns a child JVM that uses a test native library, TestCheckedJniExceptionCheck, but it doesn't add/set test.nativepath value to -Djava.library.path, so the child JVM can't find the library and fails. >> >> this issue hasn't been noticed early b/c TestCheckedJniExceptionCheck doesn't check the exit code of the child JVM. > > Thanks, > -- Igor Thanks, David. ------------- PR: https://git.openjdk.java.net/jdk17/pull/273 From iignatyev at openjdk.java.net Thu Jul 22 22:19:39 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 22:19:39 GMT Subject: [jdk17] Integrated: 8271160: runtime/jni/checked/TestCheckedJniExceptionCheck.java doesn't set -Djava.library.path In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 20:07:09 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that sets `-Djava.library.path` to ` test.nativepath` for `TestCheckedJniExceptionCheck`'s child JVM so it will be able to locate the library? > > from JBS: >> TestCheckedJniExceptionCheck spawns a child JVM that uses a test native library, TestCheckedJniExceptionCheck, but it doesn't add/set test.nativepath value to -Djava.library.path, so the child JVM can't find the library and fails. >> >> this issue hasn't been noticed early b/c TestCheckedJniExceptionCheck doesn't check the exit code of the child JVM. > > Thanks, > -- Igor This pull request has now been integrated. Changeset: 2d165a2b Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk17/commit/2d165a2bdf6efbfb1541af53d83492769bc0f616 Stats: 12 lines in 1 file changed: 6 ins; 2 del; 4 mod 8271160: runtime/jni/checked/TestCheckedJniExceptionCheck.java doesn't set -Djava.library.path Reviewed-by: dcubed, dholmes ------------- PR: https://git.openjdk.java.net/jdk17/pull/273 From dholmes at openjdk.java.net Thu Jul 22 22:53:19 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Jul 2021 22:53:19 GMT Subject: RFR: 8212961: [TESTBUG] vmTestbase/nsk/stress/jni/ native code cleanup Message-ID: Please review what is primarily a code style cleanup with some old native code: - add spaces around operators and after commas - fixed indent and line breaks - added braces to blocks - replaced raw malloc with c_malloc (check malloc) - fixed CE macro using and exception processing in general - added different CHECK macro for monitor enter/exit - removed some unreachable explicit exception checking code I staged this as multiple commits to try and make the changes more obvious at each step (and if you hide whitespace changes it simplifies quite a bit), but it may be easier to just look at the end results and see if anything jumps out as still needing changing. Note: there was no attempt to actually change the logic of any test or rewrite them in a better way - that is out of scope for the cleanup. The only logic changes relates to the CE macro and exception/error checking. Testing: - local running of the tests themselves - tier5 testing in our CI system (in progress). This may be of interest to @iignatev and @lmesnik . Thanks, David ------------- Commit messages: - - final misc cleanups: more missing spaces around operators - - Fixed the exception logic to restore original - - really fixed incorrectly added spaces - - fixed incorrectly added spaces - - step 7: add spaces after commas - - fixed incorrectly added spaces - - step 6: Fix up exception processing - - step 5: add missing braces - - step 4: replace malloc with c_malloc - - step 3: use CE macros from jnihelper.h - ... and 2 more: https://git.openjdk.java.net/jdk/compare/1eeb1791...64ae394c Changes: https://git.openjdk.java.net/jdk/pull/4882/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4882&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8212961 Stats: 780 lines in 8 files changed: 114 ins; 127 del; 539 mod Patch: https://git.openjdk.java.net/jdk/pull/4882.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4882/head:pull/4882 PR: https://git.openjdk.java.net/jdk/pull/4882 From dholmes at openjdk.java.net Thu Jul 22 22:56:04 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Jul 2021 22:56:04 GMT Subject: [jdk17] RFR: 8271162: runtime/StackTrace/LargeClassTest.java can be run in driver mode In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 21:33:53 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial patch that changes `LargeClassTest` to be executed in a driver mode and removes the redundant, due to an implicit `@build` action associated with `@run`, `@compile` action? > > testing: `runtime/StackTrace/LargeClassTest.java` on `{linux,windows,macos}-x64` > > Thanks, > -- Igor Seems fine and trivial. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/274 From dholmes at openjdk.java.net Thu Jul 22 22:59:04 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Jul 2021 22:59:04 GMT Subject: [jdk17] RFR: 8271169: runtime/Safepoint/TestAbortVMOnSafepointTimeout.java can be run in driver mode In-Reply-To: <0dNEomkBK6jl-WBGKz37dpPrSLO-b7ObgyZQjkON4r4=.39b309e9-ad04-4b98-835d-2565473761ed@github.com> References: <0dNEomkBK6jl-WBGKz37dpPrSLO-b7ObgyZQjkON4r4=.39b309e9-ad04-4b98-835d-2565473761ed@github.com> Message-ID: <_VgR2_qG2eVr2aercmcARzbCDDolKUL0tz34bIhzkt4=.e4dbe7ba-d816-43ea-962a-032abae3c036@github.com> On Thu, 22 Jul 2021 22:07:01 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial test-only patch? > from JBS: >> `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` uses `main/othervm` so `TestAbortVMOnSafepointTimeout` is run w/ the flags required for WhiteBox API, yet `TestAbortVMOnSafepointTimeout` doesn't use WhiteBox API and can be run in driver mode. > > testing: `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` on `{linux,windows,macos}-x64` > > Thanks, > -- Igor I agree with the analysis, this change seems fine. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/275 From dholmes at openjdk.java.net Thu Jul 22 23:11:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Jul 2021 23:11:36 GMT Subject: RFR: 8212961: [TESTBUG] vmTestbase/nsk/stress/jni/ native code cleanup [v2] In-Reply-To: References: Message-ID: > Please review what is primarily a code style cleanup with some old native code: > > - add spaces around operators and after commas > - fixed indent and line breaks > - added braces to blocks > - replaced raw malloc with c_malloc (check malloc) > - fixed CE macro using and exception processing in general > - added different CHECK macro for monitor enter/exit > - removed some unreachable explicit exception checking code > > I staged this as multiple commits to try and make the changes more obvious at each step (and if you hide whitespace changes it simplifies quite a bit), but it may be easier to just look at the end results and see if anything jumps out as still needing changing. > > Note: there was no attempt to actually change the logic of any test or rewrite them in a better way - that is out of scope for the cleanup. The only logic changes relates to the CE macro and exception/error checking. > > Testing: > - local running of the tests themselves > - tier5 testing in our CI system (in progress). > > This may be of interest to @iignatev and @lmesnik . > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Restored 'dead code' that led to compilation failure on Windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4882/files - new: https://git.openjdk.java.net/jdk/pull/4882/files/64ae394c..aa3c5c89 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4882&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4882&range=00-01 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4882.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4882/head:pull/4882 PR: https://git.openjdk.java.net/jdk/pull/4882 From iignatyev at openjdk.java.net Thu Jul 22 23:26:07 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 23:26:07 GMT Subject: [jdk17] RFR: 8271169: runtime/Safepoint/TestAbortVMOnSafepointTimeout.java can be run in driver mode In-Reply-To: <0dNEomkBK6jl-WBGKz37dpPrSLO-b7ObgyZQjkON4r4=.39b309e9-ad04-4b98-835d-2565473761ed@github.com> References: <0dNEomkBK6jl-WBGKz37dpPrSLO-b7ObgyZQjkON4r4=.39b309e9-ad04-4b98-835d-2565473761ed@github.com> Message-ID: On Thu, 22 Jul 2021 22:07:01 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial test-only patch? > from JBS: >> `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` uses `main/othervm` so `TestAbortVMOnSafepointTimeout` is run w/ the flags required for WhiteBox API, yet `TestAbortVMOnSafepointTimeout` doesn't use WhiteBox API and can be run in driver mode. > > testing: `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` on `{linux,windows,macos}-x64` > > Thanks, > -- Igor Thanks, David. ------------- PR: https://git.openjdk.java.net/jdk17/pull/275 From iignatyev at openjdk.java.net Thu Jul 22 23:26:07 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 23:26:07 GMT Subject: [jdk17] Integrated: 8271169: runtime/Safepoint/TestAbortVMOnSafepointTimeout.java can be run in driver mode In-Reply-To: <0dNEomkBK6jl-WBGKz37dpPrSLO-b7ObgyZQjkON4r4=.39b309e9-ad04-4b98-835d-2565473761ed@github.com> References: <0dNEomkBK6jl-WBGKz37dpPrSLO-b7ObgyZQjkON4r4=.39b309e9-ad04-4b98-835d-2565473761ed@github.com> Message-ID: On Thu, 22 Jul 2021 22:07:01 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial test-only patch? > from JBS: >> `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` uses `main/othervm` so `TestAbortVMOnSafepointTimeout` is run w/ the flags required for WhiteBox API, yet `TestAbortVMOnSafepointTimeout` doesn't use WhiteBox API and can be run in driver mode. > > testing: `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` on `{linux,windows,macos}-x64` > > Thanks, > -- Igor This pull request has now been integrated. Changeset: 84be910e Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk17/commit/84be910e1dfaf358a31f8e804f948adcab6984fd Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8271169: runtime/Safepoint/TestAbortVMOnSafepointTimeout.java can be run in driver mode Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk17/pull/275 From dcubed at openjdk.java.net Thu Jul 22 23:44:21 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Jul 2021 23:44:21 GMT Subject: RFR: 8271165: ProblemList serviceability/dcmd/gc/HeapDumpAllTest.java on X64 Message-ID: Trivial fixes: JDK-8271165 ProblemList serviceability/dcmd/gc/HeapDumpAllTest.java on X64 JDK-8271166 ProblemList applications/jcstress/copy.java on Linux-X64 ------------- Commit messages: - 8271166: ProblemList applications/jcstress/copy.java on Linux-X64 - 8271165: ProblemList serviceability/dcmd/gc/HeapDumpAllTest.java Changes: https://git.openjdk.java.net/jdk/pull/4881/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4881&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271165 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4881.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4881/head:pull/4881 PR: https://git.openjdk.java.net/jdk/pull/4881 From darcy at openjdk.java.net Thu Jul 22 23:54:06 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 22 Jul 2021 23:54:06 GMT Subject: RFR: 8271165: ProblemList serviceability/dcmd/gc/HeapDumpAllTest.java on X64 In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 21:51:30 GMT, Daniel D. Daugherty wrote: > Trivial fixes: > JDK-8271165 ProblemList serviceability/dcmd/gc/HeapDumpAllTest.java on X64 > JDK-8271166 ProblemList applications/jcstress/copy.java on Linux-X64 Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4881 From iignatyev at openjdk.java.net Thu Jul 22 23:55:08 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 23:55:08 GMT Subject: [jdk17] RFR: 8271162: runtime/StackTrace/LargeClassTest.java can be run in driver mode In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 21:33:53 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial patch that changes `LargeClassTest` to be executed in a driver mode and removes the redundant, due to an implicit `@build` action associated with `@run`, `@compile` action? > > testing: `runtime/StackTrace/LargeClassTest.java` on `{linux,windows,macos}-x64` > > Thanks, > -- Igor Thank you, David. ------------- PR: https://git.openjdk.java.net/jdk17/pull/274 From iignatyev at openjdk.java.net Thu Jul 22 23:57:05 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 23:57:05 GMT Subject: [jdk17] RFR: 8271158: runtime/handshake/HandshakeTimeoutTest.java test doesn't check exit code In-Reply-To: References: Message-ID: <1rcVYU-aStZLIXOn-fl5P8AB7gwm6iZxr62_F9q_rKE=.9d37d43a-df3f-4c0d-8dea-1ba34726deda@github.com> On Thu, 22 Jul 2021 19:12:27 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this one-liner that adds an exit code check to `runtime/handshake/HandshakeTimeoutTest.java` test? > > Thanks, > -- Igor Thanks, Dan. ------------- PR: https://git.openjdk.java.net/jdk17/pull/270 From iignatyev at openjdk.java.net Thu Jul 22 23:57:07 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 23:57:07 GMT Subject: [jdk17] Integrated: 8271162: runtime/StackTrace/LargeClassTest.java can be run in driver mode In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 21:33:53 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial patch that changes `LargeClassTest` to be executed in a driver mode and removes the redundant, due to an implicit `@build` action associated with `@run`, `@compile` action? > > testing: `runtime/StackTrace/LargeClassTest.java` on `{linux,windows,macos}-x64` > > Thanks, > -- Igor This pull request has now been integrated. Changeset: e3800e64 Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk17/commit/e3800e6497a14b64b96c71f6adff36a5e69a05cc Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8271162: runtime/StackTrace/LargeClassTest.java can be run in driver mode Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk17/pull/274 From iignatyev at openjdk.java.net Thu Jul 22 23:57:06 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 23:57:06 GMT Subject: [jdk17] Integrated: 8271158: runtime/handshake/HandshakeTimeoutTest.java test doesn't check exit code In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 19:12:27 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this one-liner that adds an exit code check to `runtime/handshake/HandshakeTimeoutTest.java` test? > > Thanks, > -- Igor This pull request has now been integrated. Changeset: ee93cef8 Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk17/commit/ee93cef8aa73f801456f2231ada4971ca0a5a154 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8271158: runtime/handshake/HandshakeTimeoutTest.java test doesn't check exit code Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk17/pull/270 From dcubed at openjdk.java.net Fri Jul 23 00:00:14 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 23 Jul 2021 00:00:14 GMT Subject: Integrated: 8271165: ProblemList serviceability/dcmd/gc/HeapDumpAllTest.java on X64 In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 21:51:30 GMT, Daniel D. Daugherty wrote: > Trivial fixes: > JDK-8271165 ProblemList serviceability/dcmd/gc/HeapDumpAllTest.java on X64 > JDK-8271166 ProblemList applications/jcstress/copy.java on Linux-X64 This pull request has now been integrated. Changeset: a7d30123 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/a7d30123f03d62a98e0164744d5b20425943641c Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8271165: ProblemList serviceability/dcmd/gc/HeapDumpAllTest.java on X64 8271166: ProblemList applications/jcstress/copy.java on Linux-X64 Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/4881 From dcubed at openjdk.java.net Fri Jul 23 00:00:13 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 23 Jul 2021 00:00:13 GMT Subject: RFR: 8271165: ProblemList serviceability/dcmd/gc/HeapDumpAllTest.java on X64 In-Reply-To: References: Message-ID: <3-S8p82ni_c2YWH2_O17hwYFnTFEHztuymPl-zA-o_w=.8fb73100-1184-48b1-887e-49684f87308c@github.com> On Thu, 22 Jul 2021 23:50:56 GMT, Joe Darcy wrote: >> Trivial fixes: >> JDK-8271165 ProblemList serviceability/dcmd/gc/HeapDumpAllTest.java on X64 >> JDK-8271166 ProblemList applications/jcstress/copy.java on Linux-X64 > > Marked as reviewed by darcy (Reviewer). @jddarcy - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4881 From iignatyev at openjdk.java.net Fri Jul 23 00:32:19 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 23 Jul 2021 00:32:19 GMT Subject: [jdk17] RFR: 8271174: runtime/ClassFile/UnsupportedClassFileVersion.java can be run in driver mode Message-ID: Hi all, could you please review this trivial patch that switches execution mode in `runtime/ClassFile/UnsupportedClassFileVersion.java` test to `driver`? testing: `runtime/ClassFile/UnsupportedClassFileVersion.java` on `{linux,windows,macos}-x64` Thanks, -- Igor ------------- Commit messages: - 8271174 Changes: https://git.openjdk.java.net/jdk17/pull/276/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=276&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271174 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/276.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/276/head:pull/276 PR: https://git.openjdk.java.net/jdk17/pull/276 From dholmes at openjdk.java.net Fri Jul 23 01:16:16 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 23 Jul 2021 01:16:16 GMT Subject: [jdk17] RFR: 8271158: runtime/handshake/HandshakeTimeoutTest.java test doesn't check exit code In-Reply-To: References: Message-ID: <20Ez5e52VYbSX6xsWUW6sblAbJb7ZRxh80anfVIZ9OE=.aea21bcc-2f32-400e-a034-d0bbf81c16e4@github.com> On Thu, 22 Jul 2021 19:12:27 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this one-liner that adds an exit code check to `runtime/handshake/HandshakeTimeoutTest.java` test? > > Thanks, > -- Igor This looks like it could also use driver mode. ------------- PR: https://git.openjdk.java.net/jdk17/pull/270 From dholmes at openjdk.java.net Fri Jul 23 01:33:03 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 23 Jul 2021 01:33:03 GMT Subject: [jdk17] RFR: 8271174: runtime/ClassFile/UnsupportedClassFileVersion.java can be run in driver mode In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 00:25:19 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial patch that switches execution mode in `runtime/ClassFile/UnsupportedClassFileVersion.java` test to `driver`? > > testing: `runtime/ClassFile/UnsupportedClassFileVersion.java` on `{linux,windows,macos}-x64` > > Thanks, > -- Igor test/hotspot/jtreg/runtime/ClassFile/UnsupportedClassFileVersion.java line 30: > 28: * java.base/jdk.internal.misc > 29: * java.management > 30: * @compile -XDignore.symbol.file UnsupportedClassFileVersion.java I can't find what -XDignore.symbol.file was used for, so am unsure if removing it is in fact okay in all circumstances. ?? ------------- PR: https://git.openjdk.java.net/jdk17/pull/276 From iignatyev at openjdk.java.net Fri Jul 23 05:19:17 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 23 Jul 2021 05:19:17 GMT Subject: [jdk17] RFR: 8271189: runtime/handshake/HandshakeTimeoutTest.java can be run in driver mode Message-ID: Hi all, could you please review this tiny patch? Thanks, -- Igor ------------- Commit messages: - 8271189 Changes: https://git.openjdk.java.net/jdk17/pull/278/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=278&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271189 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/278.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/278/head:pull/278 PR: https://git.openjdk.java.net/jdk17/pull/278 From stuefe at openjdk.java.net Fri Jul 23 05:41:04 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 23 Jul 2021 05:41:04 GMT Subject: RFR: 8212961: [TESTBUG] vmTestbase/nsk/stress/jni/ native code cleanup [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 23:11:36 GMT, David Holmes wrote: >> Please review what is primarily a code style cleanup with some old native code: >> >> - add spaces around operators and after commas >> - fixed indent and line breaks >> - added braces to blocks >> - replaced raw malloc with c_malloc (check malloc) >> - fixed CE macro using and exception processing in general >> - added different CHECK macro for monitor enter/exit >> - removed some unreachable explicit exception checking code >> >> I staged this as multiple commits to try and make the changes more obvious at each step (and if you hide whitespace changes it simplifies quite a bit), but it may be easier to just look at the end results and see if anything jumps out as still needing changing. >> >> Note: there was no attempt to actually change the logic of any test or rewrite them in a better way - that is out of scope for the cleanup. The only logic changes relates to the CE macro and exception/error checking. >> >> Testing: >> - local running of the tests themselves >> - tier5 testing in our CI system (in progress). >> >> This may be of interest to @iignatev and @lmesnik . >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Restored 'dead code' that led to compilation failure on Windows Looks good, small remarks inside. Cheers, Thomas test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress001.cpp line 250: > 248: } > 249: CHECK(env->MonitorExit(jobj)); > 250: return env->NewString(javachars->str[index - 1], elem_len); Should you check for exceptions after NewString? test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress003.cpp line 89: > 87: } else { > 88: boolBuf[i] = JNI_FALSE; > 89: } Shorten to `boolBuf[i] = (i % 2) ? JNI_TRUE : JNI_FALSE` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4882 From dholmes at openjdk.java.net Fri Jul 23 05:53:09 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 23 Jul 2021 05:53:09 GMT Subject: RFR: 8212961: [TESTBUG] vmTestbase/nsk/stress/jni/ native code cleanup [v2] In-Reply-To: References: Message-ID: <_fas9k-vLJ9JM_3-SzjcCDxTGyNJiztFWvkTJG365l8=.b19ecdf7-1306-4b24-9717-f6c15ed94a3b@github.com> On Fri, 23 Jul 2021 05:38:17 GMT, Thomas Stuefe wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Restored 'dead code' that led to compilation failure on Windows > > Looks good, small remarks inside. > > Cheers, Thomas Thanks for looking at this @tstuefe ! > test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress001.cpp line 250: > >> 248: } >> 249: CHECK(env->MonitorExit(jobj)); >> 250: return env->NewString(javachars->str[index - 1], elem_len); > > Should you check for exceptions after NewString? It isn't essential as any exception will be thrown in the calling Java code. It won't be as fail-fast as using CE but doesn't seem worth the effort to change. > test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress003.cpp line 89: > >> 87: } else { >> 88: boolBuf[i] = JNI_FALSE; >> 89: } > > Shorten to `boolBuf[i] = (i % 2) ? JNI_TRUE : JNI_FALSE` ? Sure :) ------------- PR: https://git.openjdk.java.net/jdk/pull/4882 From dholmes at openjdk.java.net Fri Jul 23 06:00:44 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 23 Jul 2021 06:00:44 GMT Subject: RFR: 8212961: [TESTBUG] vmTestbase/nsk/stress/jni/ native code cleanup [v2] In-Reply-To: <_fas9k-vLJ9JM_3-SzjcCDxTGyNJiztFWvkTJG365l8=.b19ecdf7-1306-4b24-9717-f6c15ed94a3b@github.com> References: <_fas9k-vLJ9JM_3-SzjcCDxTGyNJiztFWvkTJG365l8=.b19ecdf7-1306-4b24-9717-f6c15ed94a3b@github.com> Message-ID: On Fri, 23 Jul 2021 05:47:52 GMT, David Holmes wrote: >> test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress003.cpp line 89: >> >>> 87: } else { >>> 88: boolBuf[i] = JNI_FALSE; >>> 89: } >> >> Shorten to `boolBuf[i] = (i % 2) ? JNI_TRUE : JNI_FALSE` ? > > Sure :) but without the implicit boolean :) ------------- PR: https://git.openjdk.java.net/jdk/pull/4882 From dholmes at openjdk.java.net Fri Jul 23 06:00:42 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 23 Jul 2021 06:00:42 GMT Subject: RFR: 8212961: [TESTBUG] vmTestbase/nsk/stress/jni/ native code cleanup [v3] In-Reply-To: References: Message-ID: <7aP-08axd0yopgPxVTRkpm9F_QjQfPx6OmI3yXYca8c=.2b58565b-6004-42d6-9260-72c0832c8c2d@github.com> > Please review what is primarily a code style cleanup with some old native code: > > - add spaces around operators and after commas > - fixed indent and line breaks > - added braces to blocks > - replaced raw malloc with c_malloc (check malloc) > - fixed CE macro using and exception processing in general > - added different CHECK macro for monitor enter/exit > - removed some unreachable explicit exception checking code > > I staged this as multiple commits to try and make the changes more obvious at each step (and if you hide whitespace changes it simplifies quite a bit), but it may be easier to just look at the end results and see if anything jumps out as still needing changing. > > Note: there was no attempt to actually change the logic of any test or rewrite them in a better way - that is out of scope for the cleanup. The only logic changes relates to the CE macro and exception/error checking. > > Testing: > - local running of the tests themselves > - tier5 testing in our CI system (in progress). > > This may be of interest to @iignatev and @lmesnik . > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: @tstuefe feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4882/files - new: https://git.openjdk.java.net/jdk/pull/4882/files/aa3c5c89..95d28b61 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4882&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4882&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4882.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4882/head:pull/4882 PR: https://git.openjdk.java.net/jdk/pull/4882 From stuefe at openjdk.java.net Fri Jul 23 06:08:04 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 23 Jul 2021 06:08:04 GMT Subject: RFR: 8212961: [TESTBUG] vmTestbase/nsk/stress/jni/ native code cleanup [v3] In-Reply-To: <7aP-08axd0yopgPxVTRkpm9F_QjQfPx6OmI3yXYca8c=.2b58565b-6004-42d6-9260-72c0832c8c2d@github.com> References: <7aP-08axd0yopgPxVTRkpm9F_QjQfPx6OmI3yXYca8c=.2b58565b-6004-42d6-9260-72c0832c8c2d@github.com> Message-ID: <3PsLVZqDnDAR8zLCrJwQqydI1sDjr4wALp2YHqyA6Tg=.f760b035-c20e-424c-b918-f4d62c96bed8@github.com> On Fri, 23 Jul 2021 06:00:42 GMT, David Holmes wrote: >> Please review what is primarily a code style cleanup with some old native code: >> >> - add spaces around operators and after commas >> - fixed indent and line breaks >> - added braces to blocks >> - replaced raw malloc with c_malloc (check malloc) >> - fixed CE macro using and exception processing in general >> - added different CHECK macro for monitor enter/exit >> - removed some unreachable explicit exception checking code >> >> I staged this as multiple commits to try and make the changes more obvious at each step (and if you hide whitespace changes it simplifies quite a bit), but it may be easier to just look at the end results and see if anything jumps out as still needing changing. >> >> Note: there was no attempt to actually change the logic of any test or rewrite them in a better way - that is out of scope for the cleanup. The only logic changes relates to the CE macro and exception/error checking. >> >> Testing: >> - local running of the tests themselves >> - tier5 testing in our CI system (in progress). >> >> This may be of interest to @iignatev and @lmesnik . >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > @tstuefe feedback Looks good! ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4882 From dholmes at openjdk.java.net Fri Jul 23 06:38:59 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 23 Jul 2021 06:38:59 GMT Subject: [jdk17] RFR: 8271189: runtime/handshake/HandshakeTimeoutTest.java can be run in driver mode In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 05:11:59 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this tiny patch? > > Thanks, > -- Igor Looks good and trivial. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/278 From dholmes at openjdk.java.net Fri Jul 23 07:29:22 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 23 Jul 2021 07:29:22 GMT Subject: RFR: 8263840: PeriodicTask should declare its destructor virtual Message-ID: Please review this trivial fix. Testing tiers 1-3 as sanity check Thanks, David ------------- Commit messages: - 8263840: PeriodicTask should declare its destructor virtual Changes: https://git.openjdk.java.net/jdk/pull/4886/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4886&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263840 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4886/head:pull/4886 PR: https://git.openjdk.java.net/jdk/pull/4886 From xliu at openjdk.java.net Fri Jul 23 07:55:00 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 23 Jul 2021 07:55:00 GMT Subject: RFR: 8263840: PeriodicTask should declare its destructor virtual In-Reply-To: References: Message-ID: <44LBYqi-cdY5_XTSzNvReDuoOgfSiLRnzMLxuHEN7K4=.60a390af-ac8e-4caa-a582-e632867e3bc2@github.com> On Fri, 23 Jul 2021 07:20:48 GMT, David Holmes wrote: > Please review this trivial fix. > > Testing tiers 1-3 as sanity check > > Thanks, > David LGTM ------------- Marked as reviewed by xliu (Committer). PR: https://git.openjdk.java.net/jdk/pull/4886 From kbarrett at openjdk.java.net Fri Jul 23 07:59:05 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 23 Jul 2021 07:59:05 GMT Subject: RFR: 8263840: PeriodicTask should declare its destructor virtual In-Reply-To: References: Message-ID: <7H6qN1EUafRN-PxF1cOPyk317l89QGeBV73HSsrcS54=.ed5dc497-2ac7-4e73-9ca9-ef17feb488dc@github.com> On Fri, 23 Jul 2021 07:20:48 GMT, David Holmes wrote: > Please review this trivial fix. > > Testing tiers 1-3 as sanity check > > Thanks, > David Looks good, and trivial. For the record, the destructor could (currently) instead be left non-virtual but made protected, and that would also prevent slicing. All places that currently destroy a periodic task do so using a derived class pointer, so the base class destructor doesn't need to be public. But this class seems like one that might someday have clients that destroy using a base class pointer. Indeed, there seem to be some tasks that presently never get destroyed at all, like the ChunkPoolCleaner. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4886 From ysuenaga at openjdk.java.net Fri Jul 23 08:54:23 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 23 Jul 2021 08:54:23 GMT Subject: RFR: 8271186: Add UL option to replace newline char Message-ID: Most of UL entries would print log in one line, however some categories (e.g. `exceptions`) have multiline entries as following: [0.157s][info][exceptions] Exception thrown in interpreter method <{method} {0x00007f8335000248} 'main' '([Ljava/lang/String;)V' in 'Test'> at bci 9 for thread 0x00007f8330017160 (main) It is ease to parse with log shipper (Fluent Bit, Logstash, and more) if UL can print all logs in one line. Famous log shippers support multiline logs of course, but its configuration tends to be complex, and also some input plugins (e.g. TCP on Fluent Bit) do not support multiline logs. So I want to introduce new UL option newline to replace `\n` to other chars. For example, the user specifies `newline=\\n` to UL output, newline char (`\n`) will replace `\\n`. After this patch, we can get following logs with `newline=\\n`: [0.166s][info][exceptions] Exception \n thrown in interpreter method <{method} {0x00007fbc81000248} 'main' '([Ljava/lang/String;)V' in 'Test'>\n at bci 9 for thread 0x00007fbc9c0171a0 (main) I've also filed [CSR](https://bugs.openjdk.java.net/browse/JDK-8271188) for this issue, please review it. ------------- Commit messages: - add inclusion of os.hpp - 8271186: Add UL option to replace newline char Changes: https://git.openjdk.java.net/jdk/pull/4885/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4885&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271186 Stats: 82 lines in 4 files changed: 74 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4885.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4885/head:pull/4885 PR: https://git.openjdk.java.net/jdk/pull/4885 From rkennke at openjdk.java.net Fri Jul 23 10:45:03 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 23 Jul 2021 10:45:03 GMT Subject: Integrated: 8270894: Use acquire semantics in ObjectSynchronizer::read_stable_mark() In-Reply-To: References: Message-ID: On Mon, 19 Jul 2021 19:13:59 GMT, Roman Kennke wrote: > Currently, the object header is read using plain loads in read_stable_mark() (synchronizer.cpp). The matching stores use release semantics in corresponding CAS and release_store(). It seems reasonable to use acquire-semantics for the loads of the object header. > > See also discussion here: > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2021-July/050132.html > > I propose to use MO_ACQUIRE when reading the object header in read_stable_mark() and some related loads of the header. As discussed in the thread, current_thread_holds_lock() is the only place where we could do without acquire, but it doesn't seem worth to introduce extra complexity just to make this access relaxed, because it does not seem to be used in any place that looks very performance sensitive. > > If it were me, I'd probably also change the other mark() calls to MO_ACQUIRE for consistency, but that might be overkill. > > Testing: > - [x] tier1 > - [x] tier2 This pull request has now been integrated. Changeset: f2261903 Author: Roman Kennke URL: https://git.openjdk.java.net/jdk/commit/f22619032df2cf45664f110c71ddf509a5128900 Stats: 11 lines in 3 files changed: 6 ins; 0 del; 5 mod 8270894: Use acquire semantics in ObjectSynchronizer::read_stable_mark() Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/4829 From dholmes at openjdk.java.net Fri Jul 23 11:43:05 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 23 Jul 2021 11:43:05 GMT Subject: RFR: 8263840: PeriodicTask should declare its destructor virtual In-Reply-To: <44LBYqi-cdY5_XTSzNvReDuoOgfSiLRnzMLxuHEN7K4=.60a390af-ac8e-4caa-a582-e632867e3bc2@github.com> References: <44LBYqi-cdY5_XTSzNvReDuoOgfSiLRnzMLxuHEN7K4=.60a390af-ac8e-4caa-a582-e632867e3bc2@github.com> Message-ID: On Fri, 23 Jul 2021 07:51:50 GMT, Xin Liu wrote: >> Please review this trivial fix. >> >> Testing tiers 1-3 as sanity check >> >> Thanks, >> David > > LGTM Thanks for the reviews @navyxliu and @kimbarrett ! ------------- PR: https://git.openjdk.java.net/jdk/pull/4886 From dholmes at openjdk.java.net Fri Jul 23 11:43:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 23 Jul 2021 11:43:06 GMT Subject: Integrated: 8263840: PeriodicTask should declare its destructor virtual In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 07:20:48 GMT, David Holmes wrote: > Please review this trivial fix. > > Testing tiers 1-3 as sanity check > > Thanks, > David This pull request has now been integrated. Changeset: 8a789b71 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/8a789b71fe2e813a1ddbd4fb5dd43d54ac7c2425 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8263840: PeriodicTask should declare its destructor virtual Reviewed-by: xliu, kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/4886 From dholmes at openjdk.java.net Fri Jul 23 11:50:04 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 23 Jul 2021 11:50:04 GMT Subject: RFR: 8270894: Use acquire semantics in ObjectSynchronizer::read_stable_mark() In-Reply-To: References: Message-ID: On Mon, 19 Jul 2021 19:13:59 GMT, Roman Kennke wrote: > Currently, the object header is read using plain loads in read_stable_mark() (synchronizer.cpp). The matching stores use release semantics in corresponding CAS and release_store(). It seems reasonable to use acquire-semantics for the loads of the object header. > > See also discussion here: > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2021-July/050132.html > > I propose to use MO_ACQUIRE when reading the object header in read_stable_mark() and some related loads of the header. As discussed in the thread, current_thread_holds_lock() is the only place where we could do without acquire, but it doesn't seem worth to introduce extra complexity just to make this access relaxed, because it does not seem to be used in any place that looks very performance sensitive. > > If it were me, I'd probably also change the other mark() calls to MO_ACQUIRE for consistency, but that might be overkill. > > Testing: > - [x] tier1 > - [x] tier2 @rkennke two reviews are required for hotspot changes! ------------- PR: https://git.openjdk.java.net/jdk/pull/4829 From rkennke at openjdk.java.net Fri Jul 23 11:54:04 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 23 Jul 2021 11:54:04 GMT Subject: RFR: 8270894: Use acquire semantics in ObjectSynchronizer::read_stable_mark() In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 11:47:12 GMT, David Holmes wrote: > @rkennke two reviews are required for hotspot changes! Oh shit. I forgot, sorry! Do you want me to back it out? ------------- PR: https://git.openjdk.java.net/jdk/pull/4829 From adinn at redhat.com Fri Jul 23 12:22:33 2021 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 23 Jul 2021 13:22:33 +0100 Subject: RFR: 8270894: Use acquire semantics in ObjectSynchronizer::read_stable_mark() In-Reply-To: References: Message-ID: On 23/07/2021 12:54, Roman Kennke wrote: > On Fri, 23 Jul 2021 11:47:12 GMT, David Holmes wrote: > >> @rkennke two reviews are required for hotspot changes! > > Oh shit. I forgot, sorry! Do you want me to back it out? I have been reading this thread and I am happy to provide a second review if that will help. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From dholmes at openjdk.java.net Fri Jul 23 13:32:07 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 23 Jul 2021 13:32:07 GMT Subject: RFR: 8270894: Use acquire semantics in ObjectSynchronizer::read_stable_mark() In-Reply-To: References: Message-ID: On Mon, 19 Jul 2021 19:13:59 GMT, Roman Kennke wrote: > Currently, the object header is read using plain loads in read_stable_mark() (synchronizer.cpp). The matching stores use release semantics in corresponding CAS and release_store(). It seems reasonable to use acquire-semantics for the loads of the object header. > > See also discussion here: > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2021-July/050132.html > > I propose to use MO_ACQUIRE when reading the object header in read_stable_mark() and some related loads of the header. As discussed in the thread, current_thread_holds_lock() is the only place where we could do without acquire, but it doesn't seem worth to introduce extra complexity just to make this access relaxed, because it does not seem to be used in any place that looks very performance sensitive. > > If it were me, I'd probably also change the other mark() calls to MO_ACQUIRE for consistency, but that might be overkill. > > Testing: > - [x] tier1 > - [x] tier2 Perhaps solicit a second review from someone. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4829 From adinn at openjdk.java.net Fri Jul 23 14:37:10 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Fri, 23 Jul 2021 14:37:10 GMT Subject: RFR: 8270894: Use acquire semantics in ObjectSynchronizer::read_stable_mark() In-Reply-To: References: Message-ID: On Mon, 19 Jul 2021 19:13:59 GMT, Roman Kennke wrote: > Currently, the object header is read using plain loads in read_stable_mark() (synchronizer.cpp). The matching stores use release semantics in corresponding CAS and release_store(). It seems reasonable to use acquire-semantics for the loads of the object header. > > See also discussion here: > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2021-July/050132.html > > I propose to use MO_ACQUIRE when reading the object header in read_stable_mark() and some related loads of the header. As discussed in the thread, current_thread_holds_lock() is the only place where we could do without acquire, but it doesn't seem worth to introduce extra complexity just to make this access relaxed, because it does not seem to be used in any place that looks very performance sensitive. > > If it were me, I'd probably also change the other mark() calls to MO_ACQUIRE for consistency, but that might be overkill. > > Testing: > - [x] tier1 > - [x] tier2 This looks fine to me Reviewed ------------- PR: https://git.openjdk.java.net/jdk/pull/4829 From iignatyev at openjdk.java.net Fri Jul 23 15:36:03 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 23 Jul 2021 15:36:03 GMT Subject: [jdk17] RFR: 8271189: runtime/handshake/HandshakeTimeoutTest.java can be run in driver mode In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 05:11:59 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this tiny patch? > > Thanks, > -- Igor Thanks, David. ------------- PR: https://git.openjdk.java.net/jdk17/pull/278 From iignatyev at openjdk.java.net Fri Jul 23 15:36:03 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 23 Jul 2021 15:36:03 GMT Subject: [jdk17] Integrated: 8271189: runtime/handshake/HandshakeTimeoutTest.java can be run in driver mode In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 05:11:59 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this tiny patch? > > Thanks, > -- Igor This pull request has now been integrated. Changeset: b4c6229f Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk17/commit/b4c6229fd40940e3f67cf17b9bd0526932a346e6 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8271189: runtime/handshake/HandshakeTimeoutTest.java can be run in driver mode Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk17/pull/278 From dcubed at openjdk.java.net Fri Jul 23 15:48:19 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 23 Jul 2021 15:48:19 GMT Subject: RFR: 8271221: [BACKOUT] JDK-8271063 Print injected fields for InstanceKlass Message-ID: This reverts commit 9b27df6a4f0e5cdc7765144d6bcbc95700bdb6a3. ------------- Commit messages: - Revert "8271063: Print injected fields for InstanceKlass" Changes: https://git.openjdk.java.net/jdk/pull/4890/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4890&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271221 Stats: 88 lines in 4 files changed: 25 ins; 53 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4890.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4890/head:pull/4890 PR: https://git.openjdk.java.net/jdk/pull/4890 From coleenp at openjdk.java.net Fri Jul 23 15:48:19 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 23 Jul 2021 15:48:19 GMT Subject: RFR: 8271221: [BACKOUT] JDK-8271063 Print injected fields for InstanceKlass In-Reply-To: References: Message-ID: <7kGyo78_my6M5JOUa_kGAZyY5sKd9NPN2QbIzI2BUoY=.d52031fc-b316-4f3b-9df6-73bc9d4d1804@github.com> On Fri, 23 Jul 2021 15:37:37 GMT, Daniel D. Daugherty wrote: > This reverts commit 9b27df6a4f0e5cdc7765144d6bcbc95700bdb6a3. Thanks yes, this is trivial, please integrate it! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4890 From dcubed at openjdk.java.net Fri Jul 23 15:57:06 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 23 Jul 2021 15:57:06 GMT Subject: RFR: 8271221: [BACKOUT] JDK-8271063 Print injected fields for InstanceKlass In-Reply-To: <7kGyo78_my6M5JOUa_kGAZyY5sKd9NPN2QbIzI2BUoY=.d52031fc-b316-4f3b-9df6-73bc9d4d1804@github.com> References: <7kGyo78_my6M5JOUa_kGAZyY5sKd9NPN2QbIzI2BUoY=.d52031fc-b316-4f3b-9df6-73bc9d4d1804@github.com> Message-ID: On Fri, 23 Jul 2021 15:42:51 GMT, Coleen Phillimore wrote: >> This reverts commit 9b27df6a4f0e5cdc7765144d6bcbc95700bdb6a3. > > Thanks yes, this is trivial, please integrate it! @coleenp - Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4890 From dcubed at openjdk.java.net Fri Jul 23 15:57:07 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 23 Jul 2021 15:57:07 GMT Subject: Integrated: 8271221: [BACKOUT] JDK-8271063 Print injected fields for InstanceKlass In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 15:37:37 GMT, Daniel D. Daugherty wrote: > This reverts commit 9b27df6a4f0e5cdc7765144d6bcbc95700bdb6a3. This pull request has now been integrated. Changeset: ec71e2d8 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/ec71e2d891fdb9b102ce232f65cfcc5c6a1a9580 Stats: 88 lines in 4 files changed: 25 ins; 53 del; 10 mod 8271221: [BACKOUT] JDK-8271063 Print injected fields for InstanceKlass Reviewed-by: coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/4890 From iignatyev at openjdk.java.net Fri Jul 23 16:18:30 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 23 Jul 2021 16:18:30 GMT Subject: [jdk17] RFR: 8271222: two runtime/Monitor tests don't check exit code Message-ID: Hi all, could you please review this small and trivial patch? testing: `runtime/Monitor` tests on `{linux,windows,macos}-x64` Thanks, -- Igor ------------- Commit messages: - copyright year - 8271222 Changes: https://git.openjdk.java.net/jdk17/pull/280/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=280&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271222 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/280.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/280/head:pull/280 PR: https://git.openjdk.java.net/jdk17/pull/280 From iignatyev at openjdk.java.net Fri Jul 23 16:20:23 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 23 Jul 2021 16:20:23 GMT Subject: [jdk17] RFR: 8271223: two runtime/ClassFile tests don't check exit code Message-ID: Hi all, could you please review this small and trivial patch? testing: `runtime/ClassFile` tests on `{linux,windows,macos}-x64` Thanks, -- Igor ------------- Commit messages: - copyright year - 8271223 Changes: https://git.openjdk.java.net/jdk17/pull/281/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=281&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271223 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/281.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/281/head:pull/281 PR: https://git.openjdk.java.net/jdk17/pull/281 From iignatyev at openjdk.java.net Fri Jul 23 16:34:20 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 23 Jul 2021 16:34:20 GMT Subject: [jdk17] RFR: 8271175: runtime/jni/FindClassUtf8/FindClassUtf8.java doesn't have to be run in othervm Message-ID: Hi all, could you please review this small patch? testing: `runtime/jni/FindClassUtf8/FindClassUtf8.java` on `{linux,windows,macos}-x64` Thanks, -- Igor ------------- Commit messages: - 8271175 Changes: https://git.openjdk.java.net/jdk17/pull/282/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=282&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271175 Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk17/pull/282.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/282/head:pull/282 PR: https://git.openjdk.java.net/jdk17/pull/282 From mseledtsov at openjdk.java.net Fri Jul 23 21:50:02 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 23 Jul 2021 21:50:02 GMT Subject: RFR: 8271186: Add UL option to replace newline char In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 04:09:29 GMT, Yasumasa Suenaga wrote: > Most of UL entries would print log in one line, however some categories (e.g. `exceptions`) have multiline entries as following: > > > [0.157s][info][exceptions] Exception > thrown in interpreter method <{method} {0x00007f8335000248} 'main' '([Ljava/lang/String;)V' in 'Test'> > at bci 9 for thread 0x00007f8330017160 (main) > > > It is ease to parse with log shipper (Fluent Bit, Logstash, and more) if UL can print all logs in one line. > Famous log shippers support multiline logs of course, but its configuration tends to be complex, and also some input plugins (e.g. TCP on Fluent Bit) do not support multiline logs. > > So I want to introduce new UL option newline to replace `\n` to other chars. For example, the user specifies `newline=\\n` to UL output, newline char (`\n`) will replace `\\n`. > > After this patch, we can get following logs with `newline=\\n`: > > > [0.166s][info][exceptions] Exception \n thrown in interpreter method <{method} {0x00007fbc81000248} 'main' '([Ljava/lang/String;)V' in 'Test'>\n at bci 9 for thread 0x00007fbc9c0171a0 (main) > > > I've also filed [CSR](https://bugs.openjdk.java.net/browse/JDK-8271188) for this issue, please review it. Could you, please, consider adding a test for this issue? Or updating an existing test? ------------- PR: https://git.openjdk.java.net/jdk/pull/4885 From jwilhelm at openjdk.java.net Fri Jul 23 22:33:08 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 23 Jul 2021 22:33:08 GMT Subject: RFR: Merge jdk17 Message-ID: <4aCK96JpOk6n9yrXLvEWrdmsSVnhjAmJBRnTaJUACRM=.7566713a-7bdb-478a-b206-1e21d20c435e@github.com> Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8269984: [macos] JTabbedPane title looks like disabled - 8271173: serviceability/jvmti/GetObjectSizeClass.java doesn't check exit code - 8271189: runtime/handshake/HandshakeTimeoutTest.java can be run in driver mode The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jdk/pull/4896/files Stats: 29 lines in 3 files changed: 18 ins; 3 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4896.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4896/head:pull/4896 PR: https://git.openjdk.java.net/jdk/pull/4896 From jwilhelm at openjdk.java.net Sat Jul 24 01:11:08 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Sat, 24 Jul 2021 01:11:08 GMT Subject: Integrated: Merge jdk17 In-Reply-To: <4aCK96JpOk6n9yrXLvEWrdmsSVnhjAmJBRnTaJUACRM=.7566713a-7bdb-478a-b206-1e21d20c435e@github.com> References: <4aCK96JpOk6n9yrXLvEWrdmsSVnhjAmJBRnTaJUACRM=.7566713a-7bdb-478a-b206-1e21d20c435e@github.com> Message-ID: On Fri, 23 Jul 2021 22:24:14 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: 0dcfc42f Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/0dcfc42f230a4958c9349f4145093c5b02e06ad4 Stats: 29 lines in 3 files changed: 18 ins; 3 del; 8 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4896 From dholmes at openjdk.java.net Mon Jul 26 00:32:22 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 26 Jul 2021 00:32:22 GMT Subject: RFR: 8269523: runtime/Safepoint/TestAbortOnVMOperationTimeout.java failed when expecting 'VM operation took too long' Message-ID: Please review this simple test adjustment: - dropped 5ms timeout as we have seen execution as low as 2ms - enabled GC logging - report output in all cases to allow ease of analysis Testing: ran 10x on macos/linux/Windows x64 and macos Aarch64 to check execution times and adjusted test accordingly Thanks, David ------------- Commit messages: - 8269523: runtime/Safepoint/TestAbortOnVMOperationTimeout.java failed when expecting 'VM operation took too long' Changes: https://git.openjdk.java.net/jdk/pull/4901/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4901&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269523 Stats: 7 lines in 1 file changed: 2 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4901/head:pull/4901 PR: https://git.openjdk.java.net/jdk/pull/4901 From yyang at openjdk.java.net Mon Jul 26 02:26:28 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 26 Jul 2021 02:26:28 GMT Subject: RFR: 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack Message-ID: Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash. The attached test generates the following bytecode: void test(); descriptor: ()V flags: (0x0000) Code: stack=2, locals=3, args_size=1 0: iconst_1 1: istore_1 2: iload_1 3: bipush 100 5: if_icmpge 29 8: iinc 1, 1 11: goto 2 14: astore_2 15: iload_1 16: bipush 100 18: if_icmpge 27 21: iinc 1, 1 24: goto 15 27: aload_2 28: athrow 29: return Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug. Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this: void test(); descriptor: ()V flags: (0x0000) Code: stack=2, locals=3, args_size=1 0: iconst_1 1: istore_1 2: nop 3: iload_1 4: bipush 100 6: if_icmpge 30 9: iinc 1, 1 12: goto 3 15: astore_2 16: iload_1 17: bipush 100 19: if_icmpge 28 22: iinc 1, 1 25: goto 16 28: aload_2 29: athrow 30: return Exception table: from to target type 2 3 15 any However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion. ------------- Commit messages: - fix Changes: https://git.openjdk.java.net/jdk/pull/4902/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4902&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271055 Stats: 61 lines in 3 files changed: 59 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4902.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4902/head:pull/4902 PR: https://git.openjdk.java.net/jdk/pull/4902 From yyang at openjdk.java.net Mon Jul 26 02:50:46 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 26 Jul 2021 02:50:46 GMT Subject: RFR: 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack [v2] In-Reply-To: References: Message-ID: > Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash. > > The attached test generates the following bytecode: > > void test(); > descriptor: ()V > flags: (0x0000) > Code: > stack=2, locals=3, args_size=1 > 0: iconst_1 > 1: istore_1 > 2: iload_1 > 3: bipush 100 > 5: if_icmpge 29 > 8: iinc 1, 1 > 11: goto 2 > 14: astore_2 > 15: iload_1 > 16: bipush 100 > 18: if_icmpge 27 > 21: iinc 1, 1 > 24: goto 15 > 27: aload_2 > 28: athrow > 29: return > > > > Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug. > > Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this: > > void test(); > descriptor: ()V > flags: (0x0000) > Code: > stack=2, locals=3, args_size=1 > 0: iconst_1 > 1: istore_1 > 2: nop > 3: iload_1 > 4: bipush 100 > 6: if_icmpge 30 > 9: iinc 1, 1 > 12: goto 3 > 15: astore_2 > 16: iload_1 > 17: bipush 100 > 19: if_icmpge 28 > 22: iinc 1, 1 > 25: goto 16 > 28: aload_2 > 29: athrow > 30: return > Exception table: > from to target type > 2 3 15 any > > > However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion. Yi Yang has updated the pull request incrementally with three additional commits since the last revision: - Merge branch 'JDK-8271055' of https://github.com/kelthuzadx/jdk into JDK-8271055 - fix test - fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4902/files - new: https://git.openjdk.java.net/jdk/pull/4902/files/710d6d22..7b850f05 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4902&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4902&range=00-01 Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4902.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4902/head:pull/4902 PR: https://git.openjdk.java.net/jdk/pull/4902 From dholmes at openjdk.java.net Mon Jul 26 05:03:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 26 Jul 2021 05:03:36 GMT Subject: [jdk17] RFR: 8271175: runtime/jni/FindClassUtf8/FindClassUtf8.java doesn't have to be run in othervm In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 16:26:57 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch? > > testing: `runtime/jni/FindClassUtf8/FindClassUtf8.java` on `{linux,windows,macos}-x64` > > Thanks, > -- Igor Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/282 From dholmes at openjdk.java.net Mon Jul 26 05:04:07 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 26 Jul 2021 05:04:07 GMT Subject: [jdk17] RFR: 8271222: two runtime/Monitor tests don't check exit code In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 16:12:30 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial patch? > > testing: `runtime/Monitor` tests on `{linux,windows,macos}-x64` > > Thanks, > -- Igor Good and trivial. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/280 From dholmes at openjdk.java.net Mon Jul 26 05:08:16 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 26 Jul 2021 05:08:16 GMT Subject: [jdk17] RFR: 8271223: two runtime/ClassFile tests don't check exit code In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 16:13:17 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial patch? > > testing: `runtime/ClassFile` tests on `{linux,windows,macos}-x64` > > Thanks, > -- Igor Looks good and trivial. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk17/pull/281 From dholmes at openjdk.java.net Mon Jul 26 05:55:07 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 26 Jul 2021 05:55:07 GMT Subject: RFR: 8212961: [TESTBUG] vmTestbase/nsk/stress/jni/ native code cleanup [v3] In-Reply-To: <7aP-08axd0yopgPxVTRkpm9F_QjQfPx6OmI3yXYca8c=.2b58565b-6004-42d6-9260-72c0832c8c2d@github.com> References: <7aP-08axd0yopgPxVTRkpm9F_QjQfPx6OmI3yXYca8c=.2b58565b-6004-42d6-9260-72c0832c8c2d@github.com> Message-ID: On Fri, 23 Jul 2021 06:00:42 GMT, David Holmes wrote: >> Please review what is primarily a code style cleanup with some old native code: >> >> - add spaces around operators and after commas >> - fixed indent and line breaks >> - added braces to blocks >> - replaced raw malloc with c_malloc (check malloc) >> - fixed CE macro using and exception processing in general >> - added different CHECK macro for monitor enter/exit >> - removed some unreachable explicit exception checking code >> >> I staged this as multiple commits to try and make the changes more obvious at each step (and if you hide whitespace changes it simplifies quite a bit), but it may be easier to just look at the end results and see if anything jumps out as still needing changing. >> >> Note: there was no attempt to actually change the logic of any test or rewrite them in a better way - that is out of scope for the cleanup. The only logic changes relates to the CE macro and exception/error checking. >> >> Testing: >> - local running of the tests themselves >> - tier5 testing in our CI system (in progress). >> >> This may be of interest to @iignatev and @lmesnik . >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > @tstuefe feedback Looking for a second review please. ------------- PR: https://git.openjdk.java.net/jdk/pull/4882 From lzang at openjdk.java.net Mon Jul 26 06:49:37 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 26 Jul 2021 06:49:37 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v28] In-Reply-To: References: Message-ID: > 8252842: Extend jmap to support parallel heap dump Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: - Merge branch 'master' into par-dump - Merge branch 'master' into par-dump - Merge branch 'master' into par-dump - fix build issue after rebase and fix one issue - Merge branch 'master' - Merge branch 'master' into pd - update copyright info - Merge branch 'master' into par-dump - undo JMap.java - code refine and typo fix - ... and 27 more: https://git.openjdk.java.net/jdk/compare/e627caec...aac98ea8 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2261/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=27 Stats: 835 lines in 5 files changed: 648 ins; 57 del; 130 mod Patch: https://git.openjdk.java.net/jdk/pull/2261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261 PR: https://git.openjdk.java.net/jdk/pull/2261 From thartmann at openjdk.java.net Mon Jul 26 07:03:06 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 26 Jul 2021 07:03:06 GMT Subject: RFR: 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 02:50:46 GMT, Yi Yang wrote: >> Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash. >> >> The attached test generates the following bytecode: >> >> void test(); >> descriptor: ()V >> flags: (0x0000) >> Code: >> stack=2, locals=3, args_size=1 >> 0: iconst_1 >> 1: istore_1 >> 2: iload_1 >> 3: bipush 100 >> 5: if_icmpge 29 >> 8: iinc 1, 1 >> 11: goto 2 >> 14: astore_2 >> 15: iload_1 >> 16: bipush 100 >> 18: if_icmpge 27 >> 21: iinc 1, 1 >> 24: goto 15 >> 27: aload_2 >> 28: athrow >> 29: return >> >> >> >> Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug. >> >> Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this: >> >> void test(); >> descriptor: ()V >> flags: (0x0000) >> Code: >> stack=2, locals=3, args_size=1 >> 0: iconst_1 >> 1: istore_1 >> 2: nop >> 3: iload_1 >> 4: bipush 100 >> 6: if_icmpge 30 >> 9: iinc 1, 1 >> 12: goto 3 >> 15: astore_2 >> 16: iload_1 >> 17: bipush 100 >> 19: if_icmpge 28 >> 22: iinc 1, 1 >> 25: goto 16 >> 28: aload_2 >> 29: athrow >> 30: return >> Exception table: >> from to target type >> 2 3 15 any >> >> >> However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion. > > Yi Yang has updated the pull request incrementally with three additional commits since the last revision: > > - Merge branch 'JDK-8271055' of https://github.com/kelthuzadx/jdk into JDK-8271055 > - fix test > - fix Just wondering, did you sync up with @chhagedorn who (still) has this assigned? Not sure if he already started working on it. src/hotspot/share/runtime/deoptimization.cpp line 787: > 785: if (!Bytecodes::is_invoke(cur_code) && cur_code != Bytecodes::_athrow) { > 786: // Get expression stack size for the next bytecode > 787: if(UseNewCode) { I assume you intended to remove this from the final version of the patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/4902 From yyang at openjdk.java.net Mon Jul 26 07:14:09 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 26 Jul 2021 07:14:09 GMT Subject: Withdrawn: 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 02:10:18 GMT, Yi Yang wrote: > Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash. > > The attached test generates the following bytecode: > > void test(); > descriptor: ()V > flags: (0x0000) > Code: > stack=2, locals=3, args_size=1 > 0: iconst_1 > 1: istore_1 > 2: iload_1 > 3: bipush 100 > 5: if_icmpge 29 > 8: iinc 1, 1 > 11: goto 2 > 14: astore_2 > 15: iload_1 > 16: bipush 100 > 18: if_icmpge 27 > 21: iinc 1, 1 > 24: goto 15 > 27: aload_2 > 28: athrow > 29: return > > > > Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug. > > Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this: > > void test(); > descriptor: ()V > flags: (0x0000) > Code: > stack=2, locals=3, args_size=1 > 0: iconst_1 > 1: istore_1 > 2: nop > 3: iload_1 > 4: bipush 100 > 6: if_icmpge 30 > 9: iinc 1, 1 > 12: goto 3 > 15: astore_2 > 16: iload_1 > 17: bipush 100 > 19: if_icmpge 28 > 22: iinc 1, 1 > 25: goto 16 > 28: aload_2 > 29: athrow > 30: return > Exception table: > from to target type > 2 3 15 any > > > However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4902 From yyang at openjdk.java.net Mon Jul 26 07:14:08 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 26 Jul 2021 07:14:08 GMT Subject: RFR: 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 06:56:02 GMT, Tobias Hartmann wrote: >> Yi Yang has updated the pull request incrementally with three additional commits since the last revision: >> >> - Merge branch 'JDK-8271055' of https://github.com/kelthuzadx/jdk into JDK-8271055 >> - fix test >> - fix > > src/hotspot/share/runtime/deoptimization.cpp line 787: > >> 785: if (!Bytecodes::is_invoke(cur_code) && cur_code != Bytecodes::_athrow) { >> 786: // Get expression stack size for the next bytecode >> 787: if(UseNewCode) { > > I assume you intended to remove this from the final version of the patch. Sorry... I haven't sync up with @chhagedorn, I picked up a starter issue to work on it and missed assignee. I will update my query condition to filter unassigned issue later. ------------- PR: https://git.openjdk.java.net/jdk/pull/4902 From chagedorn at openjdk.java.net Mon Jul 26 07:21:10 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 26 Jul 2021 07:21:10 GMT Subject: RFR: 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 02:50:46 GMT, Yi Yang wrote: >> Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash. >> >> The attached test generates the following bytecode: >> >> void test(); >> descriptor: ()V >> flags: (0x0000) >> Code: >> stack=2, locals=3, args_size=1 >> 0: iconst_1 >> 1: istore_1 >> 2: iload_1 >> 3: bipush 100 >> 5: if_icmpge 29 >> 8: iinc 1, 1 >> 11: goto 2 >> 14: astore_2 >> 15: iload_1 >> 16: bipush 100 >> 18: if_icmpge 27 >> 21: iinc 1, 1 >> 24: goto 15 >> 27: aload_2 >> 28: athrow >> 29: return >> >> >> >> Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug. >> >> Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this: >> >> void test(); >> descriptor: ()V >> flags: (0x0000) >> Code: >> stack=2, locals=3, args_size=1 >> 0: iconst_1 >> 1: istore_1 >> 2: nop >> 3: iload_1 >> 4: bipush 100 >> 6: if_icmpge 30 >> 9: iinc 1, 1 >> 12: goto 3 >> 15: astore_2 >> 16: iload_1 >> 17: bipush 100 >> 19: if_icmpge 28 >> 22: iinc 1, 1 >> 25: goto 16 >> 28: aload_2 >> 29: athrow >> 30: return >> Exception table: >> from to target type >> 2 3 15 any >> >> >> However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion. > > Yi Yang has updated the pull request incrementally with three additional commits since the last revision: > > - Merge branch 'JDK-8271055' of https://github.com/kelthuzadx/jdk into JDK-8271055 > - fix test > - fix Hi @kelthuzadx, please make sure to always have a JBS issue assigned to you before creating a PR for it. If the issue is already assigned you can do a sync with the assignee and ask to take it over. In this case, I have not started working on it, yet, so you can take it over and reopen the PR again. ------------- PR: https://git.openjdk.java.net/jdk/pull/4902 From yyang at openjdk.java.net Mon Jul 26 07:30:12 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 26 Jul 2021 07:30:12 GMT Subject: RFR: 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 07:17:37 GMT, Christian Hagedorn wrote: >> Yi Yang has updated the pull request incrementally with three additional commits since the last revision: >> >> - Merge branch 'JDK-8271055' of https://github.com/kelthuzadx/jdk into JDK-8271055 >> - fix test >> - fix > > Hi @kelthuzadx, please make sure to always have a JBS issue assigned to you before creating a PR for it. If the issue is already assigned you can do a sync with the assignee and ask to take it over. > > In this case, I have not started working on it, yet, so you can take it over and reopen the PR again. Thank you @chhagedorn! I will take care of this later. ------------- PR: https://git.openjdk.java.net/jdk/pull/4902 From shade at openjdk.java.net Mon Jul 26 07:37:03 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 26 Jul 2021 07:37:03 GMT Subject: RFR: 8269523: runtime/Safepoint/TestAbortOnVMOperationTimeout.java failed when expecting 'VM operation took too long' In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 00:23:43 GMT, David Holmes wrote: > Please review this simple test adjustment: > - dropped 5ms timeout as we have seen execution as low as 2ms > - enabled GC logging > - report output in all cases to allow ease of analysis > > Testing: ran 10x on macos/linux/Windows x64 and macos Aarch64 to check execution times and adjusted test accordingly > > Thanks, > David I believe there are two slippery cases in the test, both stemming from the implicit reliancs on Serial GC to traverse the entire array. I can think of two failure modes: a) Serial invokes young GCs during the loop iteration, so that we traverse only the younger parts of the array; b) A compiler comes and eliminates `arr` altogether, as it is not globally reachable. I wonder if errors would go away if we do: static Object[] arr; public static void main(String[] args) throws Exception { if (args.length > 0) { arr = new Object[10_000_000]; for (int i = 0; i < arr.length; i++) { arr[i] = new Object(); } System.gc(); return; } ------------- PR: https://git.openjdk.java.net/jdk/pull/4901 From yyang at openjdk.java.net Mon Jul 26 07:43:39 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 26 Jul 2021 07:43:39 GMT Subject: RFR: 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack [v3] In-Reply-To: References: Message-ID: > Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash. > > The attached test generates the following bytecode: > > void test(); > descriptor: ()V > flags: (0x0000) > Code: > stack=2, locals=3, args_size=1 > 0: iconst_1 > 1: istore_1 > 2: iload_1 > 3: bipush 100 > 5: if_icmpge 29 > 8: iinc 1, 1 > 11: goto 2 > 14: astore_2 > 15: iload_1 > 16: bipush 100 > 18: if_icmpge 27 > 21: iinc 1, 1 > 24: goto 15 > 27: aload_2 > 28: athrow > 29: return > > > > Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug. > > Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this: > > void test(); > descriptor: ()V > flags: (0x0000) > Code: > stack=2, locals=3, args_size=1 > 0: iconst_1 > 1: istore_1 > 2: nop > 3: iload_1 > 4: bipush 100 > 6: if_icmpge 30 > 9: iinc 1, 1 > 12: goto 3 > 15: astore_2 > 16: iload_1 > 17: bipush 100 > 19: if_icmpge 28 > 22: iinc 1, 1 > 25: goto 16 > 28: aload_2 > 29: athrow > 30: return > Exception table: > from to target type > 2 3 15 any > > > However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion. Yi Yang has updated the pull request incrementally with one additional commit since the last revision: remove usenewcode ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4902/files - new: https://git.openjdk.java.net/jdk/pull/4902/files/7b850f05..97dc5de2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4902&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4902&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4902.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4902/head:pull/4902 PR: https://git.openjdk.java.net/jdk/pull/4902 From shade at openjdk.java.net Mon Jul 26 08:40:05 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 26 Jul 2021 08:40:05 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter In-Reply-To: References: Message-ID: <64GYFxcQJEOMO4XLAeXMS68LCLh6XgI3xXT_0wWq2gs=.eaf228d0-1fdf-4f90-affd-84fdbfe85a9d@github.com> On Tue, 13 Jul 2021 13:17:58 GMT, Christoph G?ttschkes wrote: > Hi, > > please review this fix for the template interpreter for ARM32-softfp. > > With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. > > https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 > > I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. > > Old ldc2_w implementation (before condy was implemented for ARM32): > > https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 > > Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 I see that this patch does, and I think it goes in the right direction. Let's follow the form of other arches `TemplateTable::ldc2_w` does, and what other places in ARM32 template interpreter do? These are my suggestions: - Rename label `Condy` to `NotLong` - Rename label `exit` to `Done` - Handle only double path under !_ABI_HARD_PATH Something like (drafting it blindly): Label NotDouble, NotLong, Done; __ cmp(Rtemp, JVM_CONSTANT_Double); __ b(NotDouble, ne); #ifdef __ABI_HARD__ __ ldr_double(D0_tos, Address(Rbase, base_offset)); #else __ ldr(R0_tos_lo, Address(Rbase, base_offset + 0 * wordSize)); __ ldr(R1_tos_hi, Address(Rbase, base_offset + 1 * wordSize)); #endif __ push(dtos); __ b(Done); __ bind(NotDouble); __ cmp(Rtemp, JVM_CONSTANT_Long); __ b(NotLong, ne); __ ldr(R0_tos_lo, Address(Rbase, base_offset + 0 * wordSize)); __ ldr(R1_tos_hi, Address(Rbase, base_offset + 1 * wordSize)); __ push(ltos); __ b(Done); __ bind(NotLong); condy_helper(Done); __ bind(Done); ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From shade at openjdk.java.net Mon Jul 26 08:49:04 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 26 Jul 2021 08:49:04 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 13:17:58 GMT, Christoph G?ttschkes wrote: > Hi, > > please review this fix for the template interpreter for ARM32-softfp. > > With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. > > https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 > > I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. > > Old ldc2_w implementation (before condy was implemented for ARM32): > > https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 > > Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 TBH, I am not even sure that we need to check `__ABI_HARD__` here instead of `__SOFTFP__` here. Looking at `TemplateTable::dload` and `load_category2_local`, I would have expected `__SOFTFP__`... ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From cgo at openjdk.java.net Mon Jul 26 09:49:10 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Mon, 26 Jul 2021 09:49:10 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 13:17:58 GMT, Christoph G?ttschkes wrote: > Hi, > > please review this fix for the template interpreter for ARM32-softfp. > > With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. > > https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 > > I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. > > Old ldc2_w implementation (before condy was implemented for ARM32): > > https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 > > Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 Thanks for looking into this, Aleksey. I will look into your suggestions. The reason I did a bigger #ifdef block was, because I think the problem was introduced because the softfp path was mixed into the hardfp one. For me, this makes the softfp path harder to understand, in contrast to my suggested solution. I know that having bigger #ifdef brings other problems with it. Do you think it is better to keep the #ifdef as small as possible and mix the softfp path into the hardfp? > TBH, I am not even sure that we need to check __ABI_HARD__ here instead of __SOFTFP__ here. Looking at TemplateTable::dload and load_category2_local, I would have expected __SOFTFP__... I don't quite understand what you mean here. Both, ABI_HARD and SOFTFP should be macros which specify which ABI should be used, so for me, if `__SOFTFP__` is `1`, `__ABI_HARD__` is `0`, or the other way around, or am I missing something? Could you elaborate why you think this should be changed? ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From shade at openjdk.java.net Mon Jul 26 10:05:07 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 26 Jul 2021 10:05:07 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 13:17:58 GMT, Christoph G?ttschkes wrote: > Hi, > > please review this fix for the template interpreter for ARM32-softfp. > > With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. > > https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 > > I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. > > Old ldc2_w implementation (before condy was implemented for ARM32): > > https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 > > Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 AFAICS, the real problem is that "double" path is not implemented for "!__ABI_HARD__" path, so it slides right into condy helper, right? Which calls for fixing that part, and that part only. This also avoids touching the "long" path and relying on the "ltos" being fine for doubles. Other parts of template interpreter deal with this already, see `TemplateTable::dload`. AFAIU, `ABI_HARD` and `SOFTFP` are defining different things. `SOFTFP` defines whether to use hardware instructions or software emulation to deal with FP. Whereas `ABI_HARD` covers the _ABI_ parts, i.e. which registers to use to pass FP values between calls. Here we don't call anything, but only do loads. This reasoning seems to be consistent with what `TemplateTable::dload` does. Seeing how `-mfloat-abi` takes three values, I can see `ABI_HARD` and `SOFTFP` might be not mutually exclusive? ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From cgo at openjdk.java.net Mon Jul 26 10:43:08 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Mon, 26 Jul 2021 10:43:08 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 13:17:58 GMT, Christoph G?ttschkes wrote: > Hi, > > please review this fix for the template interpreter for ARM32-softfp. > > With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. > > https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 > > I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. > > Old ldc2_w implementation (before condy was implemented for ARM32): > > https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 > > Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 > AFAIU, ABI_HARD and SOFTFP are defining different things. SOFTFP defines whether to use hardware instructions or software emulation to deal with FP. Whereas ABI_HARD covers the ABI parts, i.e. which registers to use to pass FP values between calls. Here we don't call anything, but only do loads. This reasoning seems to be consistent with what TemplateTable::dload does. Seeing how -mfloat-abi takes three values, I can see ABI_HARD and SOFTFP might be not mutually exclusive? That makes sense. I checked with my GCC: * `-mfloat-abi=soft` defines `__SOFTFP__` * `-mfloat-abi=softfp` defines neither `__ARM_PCS_VFP`, nor `__SOFTFP__` (`__ARM_PCS_VFP` is used to define `__ABI_HARD__` in `globalDefinitions_arm.hpp`) * `-mfloat-abi=hard` defines `__ARM_PCS_VFP` My assumption was that `__SOFTFP__` is defined for both, `-mfloat-abi=soft` and `-mfloat-abi=softfp`, which is not the case. Thanks for pointing that out. This suggests that we need to be consistent within the template interpreter and always use `__SOFTFP__` if we want to know which registers to use to pass floating point values inside the interpreter. `__ABI_HARD__` has to be used if it is required to follow the native ABI. ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From lzang at openjdk.java.net Mon Jul 26 11:26:06 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 26 Jul 2021 11:26:06 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v29] In-Reply-To: References: Message-ID: <7QYpM1WslbpFnNAsSiZlnO1bAEiUaHy_vq2OGWuZ6bI=.0ad9fab0-265b-4b54-9945-ada50d1f0b6b@github.com> > 8252842: Extend jmap to support parallel heap dump Lin Zang has updated the pull request incrementally with one additional commit since the last revision: fix build issue ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2261/files - new: https://git.openjdk.java.net/jdk/pull/2261/files/aac98ea8..16fb1e20 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=28 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=27-28 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261 PR: https://git.openjdk.java.net/jdk/pull/2261 From yyang at openjdk.java.net Mon Jul 26 14:58:13 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 26 Jul 2021 14:58:13 GMT Subject: RFR: 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 07:43:39 GMT, Yi Yang wrote: >> Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash. >> >> ---- >> >> The attached test generates the following bytecode: >> >> void test(); >> descriptor: ()V >> flags: (0x0000) >> Code: >> stack=2, locals=3, args_size=1 >> 0: iconst_1 >> 1: istore_1 >> 2: iload_1 >> 3: bipush 100 >> 5: if_icmpge 29 >> 8: iinc 1, 1 >> 11: goto 2 >> 14: astore_2 >> 15: iload_1 >> 16: bipush 100 >> 18: if_icmpge 27 >> 21: iinc 1, 1 >> 24: goto 15 >> 27: aload_2 >> 28: athrow >> 29: return >> >> >> >> Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug. >> >> Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this: >> >> void test(); >> descriptor: ()V >> flags: (0x0000) >> Code: >> stack=2, locals=3, args_size=1 >> 0: iconst_1 >> 1: istore_1 >> 2: nop >> 3: iload_1 >> 4: bipush 100 >> 6: if_icmpge 30 >> 9: iinc 1, 1 >> 12: goto 3 >> 15: astore_2 >> 16: iload_1 >> 17: bipush 100 >> 19: if_icmpge 28 >> 22: iinc 1, 1 >> 25: goto 16 >> 28: aload_2 >> 29: athrow >> 30: return >> Exception table: >> from to target type >> 2 3 15 any >> >> >> However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion. > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > remove usenewcode P.S. In summary, I think there are two bugs: one for javac, one for VM. -- Javac side: The proposed fix is to insert a "nop". I'm not good at this area, hope to have more experts' comments. --- VM side: To verify what I said, we can consider the below case which does not contain trap bytecodes in some unreachable basic blocks: public class VerifyStackWithUnreachableBlock { public static void main(String[] strArr) { VerifyStackWithUnreachableBlock _instance = new VerifyStackWithUnreachableBlock(); for (int i = 0; i < 10000; i++) { _instance.test(); } } void test() { int i8 = 1; try { int p=0; p++; } finally { for (; i8 < 100; i8++) { } } } } It crashes with the same assertion: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/qingfeng.yy/jdktip/src/hotspot/share/oops/generateOopMap.cpp:2220), pid=130592, tid=130631 # assert(bb->is_reachable()) failed: getting result from unreachable basicblock # # JRE version: OpenJDK Runtime Environment (18.0) (slowdebug build 18-internal+0-adhoc.qingfengyy.jdktip) # Java VM: OpenJDK 64-Bit Server VM (slowdebug 18-internal+0-adhoc.qingfengyy.jdktip, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0xa505b1] GenerateOopMap::result_for_basicblock(int)+0xb5 # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # --------------- S U M M A R Y ------------ Command Line: -Dtest.vm.opts= -Dtest.tool.vm.opts= -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/home/qingfeng.yy/jdktip/build/linux-x86_64-server-slowdebug/images/jdk -Dcompile.jdk=/home/qingfeng.yy/jdktip/build/linux-x86_64-server-slowdebug/images/jdk -Dtest.timeout.factor=1.0 -Dtest.root=/home/qingfeng.yy/jdktip/test/hotspot/jtreg -Dtest.name=compiler/interpreter/VerifyStackWithUnreachableBlock.java -Dtest.file=/home/qingfeng.yy/jdktip/test/hotspot/jtreg/compiler/interpreter/VerifyStackWithUnreachableBlock.java -Dtest.src=/home/qingfeng.yy/jdktip/test/hotspot/jtreg/compiler/interpreter -Dtest.src.path=/home/qingfeng.yy/jdktip/test/hotspot/jtreg/compiler/interpreter -Dtest.classes=/home/qingfeng.yy/jdktip/JTwork/classes/0/compiler/interpreter/VerifyStackWithUnreachableBlock.d -Dtest.class.path=/home/qingfeng.yy/jdktip/JTwork/classes/0/compiler/interpreter/VerifyStackWithUnreachableBlock.d -XX:+IgnoreUnrecognizedVMOptions -XX:+VerifyStack com.sun.javatest.regtest.agent.MainWra pper /home/qingfeng.yy/jdktip/JTwork/compiler/interpreter/VerifyStackWithUnreachableBlock.d/main.0.jta Host: e69e13043.et15sqa, Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz, 96 cores, 503G, Alibaba Group Enterprise Linux Server release 7.2 (Paladin) Time: Mon Jul 26 22:46:38 2021 CST elapsed time: 1.894403 seconds (0d 0h 0m 1s) --------------- T H R E A D --------------- Current thread (0x00007f415c3a5ab0): JavaThread "MainThread" [_thread_in_Java, id=130631, stack(0x00007f40cd9bc000,0x00007f40cdabd000)] Stack: [0x00007f40cd9bc000,0x00007f40cdabd000], sp=0x00007f40cdab8c50, free space=1011k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xa505b1] GenerateOopMap::result_for_basicblock(int)+0xb5 V [libjvm.so+0xfa41b3] OopMapForCacheEntry::compute_map(Thread*)+0x155 V [libjvm.so+0xfa4d23] OopMapCacheEntry::fill(methodHandle const&, int)+0xdd V [libjvm.so+0xfa5b4b] OopMapCache::compute_one_oop_map(methodHandle const&, int, InterpreterOopMap*)+0x4d V [libjvm.so+0x83ef0e] Deoptimization::unpack_frames(JavaThread*, int)+0x642 v ~DeoptimizationBlob .... After applying this patch, it works. ------------- PR: https://git.openjdk.java.net/jdk/pull/4902 From iignatyev at openjdk.java.net Mon Jul 26 17:14:45 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 26 Jul 2021 17:14:45 GMT Subject: RFR: 8212961: [TESTBUG] vmTestbase/nsk/stress/jni/ native code cleanup [v3] In-Reply-To: <7aP-08axd0yopgPxVTRkpm9F_QjQfPx6OmI3yXYca8c=.2b58565b-6004-42d6-9260-72c0832c8c2d@github.com> References: <7aP-08axd0yopgPxVTRkpm9F_QjQfPx6OmI3yXYca8c=.2b58565b-6004-42d6-9260-72c0832c8c2d@github.com> Message-ID: On Fri, 23 Jul 2021 06:00:42 GMT, David Holmes wrote: >> Please review what is primarily a code style cleanup with some old native code: >> >> - add spaces around operators and after commas >> - fixed indent and line breaks >> - added braces to blocks >> - replaced raw malloc with c_malloc (check malloc) >> - fixed CE macro using and exception processing in general >> - added different CHECK macro for monitor enter/exit >> - removed some unreachable explicit exception checking code >> >> I staged this as multiple commits to try and make the changes more obvious at each step (and if you hide whitespace changes it simplifies quite a bit), but it may be easier to just look at the end results and see if anything jumps out as still needing changing. >> >> Note: there was no attempt to actually change the logic of any test or rewrite them in a better way - that is out of scope for the cleanup. The only logic changes relates to the CE macro and exception/error checking. >> >> Testing: >> - local running of the tests themselves >> - tier5 testing in our CI system (in progress). >> >> This may be of interest to @iignatev and @lmesnik . >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > @tstuefe feedback LGTM ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4882 From iignatyev at openjdk.java.net Mon Jul 26 17:20:39 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 26 Jul 2021 17:20:39 GMT Subject: [jdk17] RFR: 8271223: two runtime/ClassFile tests don't check exit code In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 16:13:17 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial patch? > > testing: `runtime/ClassFile` tests on `{linux,windows,macos}-x64` > > Thanks, > -- Igor Thanks, David. ------------- PR: https://git.openjdk.java.net/jdk17/pull/281 From iignatyev at openjdk.java.net Mon Jul 26 17:21:50 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 26 Jul 2021 17:21:50 GMT Subject: [jdk17] Integrated: 8271222: two runtime/Monitor tests don't check exit code In-Reply-To: References: Message-ID: <71EZUwj29Olr3Czlul4hE6T3EvjMpUDDaCiTOSGM054=.1b7b8cd5-1e11-41e5-bfa2-9e46414d10f9@github.com> On Fri, 23 Jul 2021 16:12:30 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial patch? > > testing: `runtime/Monitor` tests on `{linux,windows,macos}-x64` > > Thanks, > -- Igor This pull request has now been integrated. Changeset: 3c27f919 Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk17/commit/3c27f919865584bcdcd85577306726afa5412571 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod 8271222: two runtime/Monitor tests don't check exit code Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk17/pull/280 From iignatyev at openjdk.java.net Mon Jul 26 17:21:49 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 26 Jul 2021 17:21:49 GMT Subject: [jdk17] RFR: 8271222: two runtime/Monitor tests don't check exit code In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 16:12:30 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial patch? > > testing: `runtime/Monitor` tests on `{linux,windows,macos}-x64` > > Thanks, > -- Igor Thanks, David. ------------- PR: https://git.openjdk.java.net/jdk17/pull/280 From iignatyev at openjdk.java.net Mon Jul 26 17:23:32 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 26 Jul 2021 17:23:32 GMT Subject: [jdk17] RFR: 8271175: runtime/jni/FindClassUtf8/FindClassUtf8.java doesn't have to be run in othervm In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 16:26:57 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch? > > testing: `runtime/jni/FindClassUtf8/FindClassUtf8.java` on `{linux,windows,macos}-x64` > > Thanks, > -- Igor Thanks, David. ------------- PR: https://git.openjdk.java.net/jdk17/pull/282 From iignatyev at openjdk.java.net Mon Jul 26 17:23:33 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 26 Jul 2021 17:23:33 GMT Subject: [jdk17] Integrated: 8271175: runtime/jni/FindClassUtf8/FindClassUtf8.java doesn't have to be run in othervm In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 16:26:57 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch? > > testing: `runtime/jni/FindClassUtf8/FindClassUtf8.java` on `{linux,windows,macos}-x64` > > Thanks, > -- Igor This pull request has now been integrated. Changeset: 7ddabbff Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk17/commit/7ddabbff74668b5f907f87e6d4d471823d1ac459 Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod 8271175: runtime/jni/FindClassUtf8/FindClassUtf8.java doesn't have to be run in othervm Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk17/pull/282 From iignatyev at openjdk.java.net Mon Jul 26 17:25:55 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 26 Jul 2021 17:25:55 GMT Subject: [jdk17] RFR: 8271223: two runtime/ClassFile tests don't check exit code In-Reply-To: References: Message-ID: <7tHFNdhQThXP_CI68_p5In8NimgURb9NwDo4n2HAr8o=.386c71f4-27a8-49df-b0e9-a5518b6a0850@github.com> On Mon, 26 Jul 2021 05:04:41 GMT, David Holmes wrote: >> Hi all, >> >> could you please review this small and trivial patch? >> >> testing: `runtime/ClassFile` tests on `{linux,windows,macos}-x64` >> >> Thanks, >> -- Igor > > Looks good and trivial. > > Thanks, > David @dholmes-ora , apparently, you haven't selected 'approve' when you posted your review message. ------------- PR: https://git.openjdk.java.net/jdk17/pull/281 From pchilanomate at openjdk.java.net Mon Jul 26 19:54:51 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 26 Jul 2021 19:54:51 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" Message-ID: Hi, Please review this small patch. When self-suspending, a JavaThread might reach SafepointSynchronize::block() with a state of _thread_in_vm which is not listed as a valid state for safepoint polling. There are a couple of simple ways to fix this. As suggested by @dholmes-ora we can avoid the handshake machinery altogether and directly self-suspend. Since this issue is intermittent and in tier7 which I didn't run as many times as other lower tiers it escaped my testing of 8270085. Testing in mach5 tiers1-7. I also reproduced the test failures locally and verified that now both hs202t002.java and ThreadSuspendSelf.java are passing. Thanks, Patricio ------------- Commit messages: - fix self-suspend handshake Changes: https://git.openjdk.java.net/jdk17/pull/283/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=283&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271251 Stats: 25 lines in 1 file changed: 13 ins; 7 del; 5 mod Patch: https://git.openjdk.java.net/jdk17/pull/283.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/283/head:pull/283 PR: https://git.openjdk.java.net/jdk17/pull/283 From dholmes at openjdk.java.net Mon Jul 26 21:21:31 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 26 Jul 2021 21:21:31 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 18:23:39 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review this small patch. When self-suspending, a JavaThread might reach SafepointSynchronize::block() with a state of _thread_in_vm which is not listed as a valid state for safepoint polling. There are a couple of simple ways to fix this. As suggested by @dholmes-ora we can avoid the handshake machinery altogether and directly self-suspend. Since this issue is intermittent and in tier7 which I didn't run as many times as other lower tiers it escaped my testing of 8270085. > > Testing in mach5 tiers1-7. I also reproduced the test failures locally and verified that now both hs202t002.java and ThreadSuspendSelf.java are passing. > > Thanks, > Patricio Looks good! Thanks for fixing this Patricio. A couple of minor suggestions. David src/hotspot/share/runtime/handshake.cpp line 615: > 613: assert(_lock.owned_by_self(), "Lock must be held"); > 614: assert(!_handshakee->has_last_Java_frame() || _handshakee->frame_anchor()->walkable(), "should have walkable stack"); > 615: Can we add an assert: `assert(_handshakee->thread_state() == _thread_blocked, "Caller should have transitioned to _thread_blocked); ` ? src/hotspot/share/runtime/handshake.cpp line 616: > 614: assert(!_handshakee->has_last_Java_frame() || _handshakee->frame_anchor()->walkable(), "should have walkable stack"); > 615: > 616: log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " suspended", p2i(_handshakee)); I think I prefer this logging to remain in the while loop. By placing it there you know the thread will actually wait() and you can also see if there are multiple suspend requests. It might even make sense to put the resume log statement in the loop after the wait() with an explicit check of is_suspended() to preclude a spurious wakeup. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/283 From dholmes at openjdk.java.net Mon Jul 26 21:38:31 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 26 Jul 2021 21:38:31 GMT Subject: RFR: 8269523: runtime/Safepoint/TestAbortOnVMOperationTimeout.java failed when expecting 'VM operation took too long' In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 00:23:43 GMT, David Holmes wrote: > Please review this simple test adjustment: > - dropped 5ms timeout as we have seen execution as low as 2ms > - enabled GC logging > - report output in all cases to allow ease of analysis > > Testing: ran 10x on macos/linux/Windows x64 and macos Aarch64 to check execution times and adjusted test accordingly > > Thanks, > David Hi Aleksey, I think both those suggestions make the test more robust, but I don't think they can really be the cause of any failures unless there is some really obscure non-determinism involved. The behaviour of the SerialGC should not vary - it either always does a young GC or never. The JIT optimisation could vary on different runs depending on flags but we don't observe that either - the very short VM ops occur under the same settings as the not short VMops. ------------- PR: https://git.openjdk.java.net/jdk/pull/4901 From pchilanomate at openjdk.java.net Mon Jul 26 22:16:04 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 26 Jul 2021 22:16:04 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 21:13:43 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> add assert in do_self_suspend > > src/hotspot/share/runtime/handshake.cpp line 615: > >> 613: assert(_lock.owned_by_self(), "Lock must be held"); >> 614: assert(!_handshakee->has_last_Java_frame() || _handshakee->frame_anchor()->walkable(), "should have walkable stack"); >> 615: > > Can we add an assert: > > `assert(_handshakee->thread_state() == _thread_blocked, "Caller should have transitioned to _thread_blocked); > ` > ? Done! > src/hotspot/share/runtime/handshake.cpp line 616: > >> 614: assert(!_handshakee->has_last_Java_frame() || _handshakee->frame_anchor()->walkable(), "should have walkable stack"); >> 615: >> 616: log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " suspended", p2i(_handshakee)); > > I think I prefer this logging to remain in the while loop. By placing it there you know the thread will actually wait() and you can also see if there are multiple suspend requests. It might even make sense to put the resume log statement in the loop after the wait() with an explicit check of is_suspended() to preclude a spurious wakeup. So for the resume log statement, once the target wakes up from wait() the _suspended flag could be set not necessarily because of a spurious wakeup but because another JT suspended the target right after the resume. But I can add a log statement in HandshakeState::resume() to track all resumes. As for the suspend log statement I thought about not moving it but then I saw that we are already logging suspends in HandshakeState::suspend_with_handshake(), and since all these logging statements are done under _lock held there is already a sequence of suspend/resume events (if adding log in HandshakeState::resume()). What do you think? ------------- PR: https://git.openjdk.java.net/jdk17/pull/283 From pchilanomate at openjdk.java.net Mon Jul 26 22:15:59 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 26 Jul 2021 22:15:59 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" [v2] In-Reply-To: References: Message-ID: > Hi, > > Please review this small patch. When self-suspending, a JavaThread might reach SafepointSynchronize::block() with a state of _thread_in_vm which is not listed as a valid state for safepoint polling. There are a couple of simple ways to fix this. As suggested by @dholmes-ora we can avoid the handshake machinery altogether and directly self-suspend. Since this issue is intermittent and in tier7 which I didn't run as many times as other lower tiers it escaped my testing of 8270085. > > Testing in mach5 tiers1-7. I also reproduced the test failures locally and verified that now both hs202t002.java and ThreadSuspendSelf.java are passing. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: add assert in do_self_suspend ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/283/files - new: https://git.openjdk.java.net/jdk17/pull/283/files/e040266f..4ecb736e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=283&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=283&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/283.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/283/head:pull/283 PR: https://git.openjdk.java.net/jdk17/pull/283 From dcubed at openjdk.java.net Mon Jul 26 22:31:38 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 26 Jul 2021 22:31:38 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 22:09:57 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/handshake.cpp line 615: >> >>> 613: assert(_lock.owned_by_self(), "Lock must be held"); >>> 614: assert(!_handshakee->has_last_Java_frame() || _handshakee->frame_anchor()->walkable(), "should have walkable stack"); >>> 615: >> >> Can we add an assert: >> >> `assert(_handshakee->thread_state() == _thread_blocked, "Caller should have transitioned to _thread_blocked); >> ` >> ? > > Done! Should be able to add that assert. The new code has only two callers to do_self_suspend() and both make sure we are in `_thread_blocked`. >> src/hotspot/share/runtime/handshake.cpp line 616: >> >>> 614: assert(!_handshakee->has_last_Java_frame() || _handshakee->frame_anchor()->walkable(), "should have walkable stack"); >>> 615: >>> 616: log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " suspended", p2i(_handshakee)); >> >> I think I prefer this logging to remain in the while loop. By placing it there you know the thread will actually wait() and you can also see if there are multiple suspend requests. It might even make sense to put the resume log statement in the loop after the wait() with an explicit check of is_suspended() to preclude a spurious wakeup. > > So for the resume log statement, once the target wakes up from wait() the _suspended flag could be set not necessarily because of a spurious wakeup but because another JT suspended the target right after the resume. But I can add a log statement in HandshakeState::resume() to track all resumes. > As for the suspend log statement I thought about not moving it but then I saw that we are already logging suspends in HandshakeState::suspend_with_handshake(), and since all these logging statements are done under _lock held there is already a sequence of suspend/resume events (if adding log in HandshakeState::resume()). > What do you think? I would not change any of the logging in the JDK17 fix unless there's a very good reason. We want the JDK17 fix to be as minimal as possible. ------------- PR: https://git.openjdk.java.net/jdk17/pull/283 From pchilanomate at openjdk.java.net Mon Jul 26 22:40:53 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 26 Jul 2021 22:40:53 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" [v3] In-Reply-To: References: Message-ID: > Hi, > > Please review this small patch. When self-suspending, a JavaThread might reach SafepointSynchronize::block() with a state of _thread_in_vm which is not listed as a valid state for safepoint polling. There are a couple of simple ways to fix this. As suggested by @dholmes-ora we can avoid the handshake machinery altogether and directly self-suspend. Since this issue is intermittent and in tier7 which I didn't run as many times as other lower tiers it escaped my testing of 8270085. > > Testing in mach5 tiers1-7. I also reproduced the test failures locally and verified that now both hs202t002.java and ThreadSuspendSelf.java are passing. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: move log statement back inside loop ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/283/files - new: https://git.openjdk.java.net/jdk17/pull/283/files/4ecb736e..a73c0094 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=283&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=283&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/283.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/283/head:pull/283 PR: https://git.openjdk.java.net/jdk17/pull/283 From pchilanomate at openjdk.java.net Mon Jul 26 22:40:53 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 26 Jul 2021 22:40:53 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 22:28:04 GMT, Daniel D. Daugherty wrote: >> So for the resume log statement, once the target wakes up from wait() the _suspended flag could be set not necessarily because of a spurious wakeup but because another JT suspended the target right after the resume. But I can add a log statement in HandshakeState::resume() to track all resumes. >> As for the suspend log statement I thought about not moving it but then I saw that we are already logging suspends in HandshakeState::suspend_with_handshake(), and since all these logging statements are done under _lock held there is already a sequence of suspend/resume events (if adding log in HandshakeState::resume()). >> What do you think? > > I would not change any of the logging in the JDK17 fix unless there's a very > good reason. We want the JDK17 fix to be as minimal as possible. Sounds good, I added the log statement back into the loop. ------------- PR: https://git.openjdk.java.net/jdk17/pull/283 From dcubed at openjdk.java.net Mon Jul 26 22:46:31 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 26 Jul 2021 22:46:31 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" [v3] In-Reply-To: References: Message-ID: <3_qBIyox_lsuVvZpMLJEtbPMyQOl4mtcRtlBRmpi5wo=.f5637161-04f3-4c25-aed1-259907f60ae6@github.com> On Mon, 26 Jul 2021 22:40:53 GMT, Patricio Chilano Mateo wrote: >> Hi, >> >> Please review this small patch. When self-suspending, a JavaThread might reach SafepointSynchronize::block() with a state of _thread_in_vm which is not listed as a valid state for safepoint polling. There are a couple of simple ways to fix this. As suggested by @dholmes-ora we can avoid the handshake machinery altogether and directly self-suspend. Since this issue is intermittent and in tier7 which I didn't run as many times as other lower tiers it escaped my testing of 8270085. >> >> Testing in mach5 tiers1-7. I also reproduced the test failures locally and verified that now both hs202t002.java and ThreadSuspendSelf.java are passing. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > move log statement back inside loop @pchilano - I've reviewed v0 and v2. I want to mull on this over night so I'll post my final review in the AM. ------------- PR: https://git.openjdk.java.net/jdk17/pull/283 From dholmes at openjdk.java.net Mon Jul 26 23:26:37 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 26 Jul 2021 23:26:37 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 22:40:53 GMT, Patricio Chilano Mateo wrote: >> Hi, >> >> Please review this small patch. When self-suspending, a JavaThread might reach SafepointSynchronize::block() with a state of _thread_in_vm which is not listed as a valid state for safepoint polling. There are a couple of simple ways to fix this. As suggested by @dholmes-ora we can avoid the handshake machinery altogether and directly self-suspend. Since this issue is intermittent and in tier7 which I didn't run as many times as other lower tiers it escaped my testing of 8270085. >> >> Testing in mach5 tiers1-7. I also reproduced the test failures locally and verified that now both hs202t002.java and ThreadSuspendSelf.java are passing. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > move log statement back inside loop Updates are good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/283 From dholmes at openjdk.java.net Mon Jul 26 23:32:53 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 26 Jul 2021 23:32:53 GMT Subject: RFR: 8269523: runtime/Safepoint/TestAbortOnVMOperationTimeout.java failed when expecting 'VM operation took too long' [v2] In-Reply-To: References: Message-ID: > Please review this simple test adjustment: > - dropped 5ms timeout as we have seen execution as low as 2ms > - enabled GC logging > - report output in all cases to allow ease of analysis > > Testing: ran 10x on macos/linux/Windows x64 and macos Aarch64 to check execution times and adjusted test accordingly > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Robustness suggestions from @shipilev ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4901/files - new: https://git.openjdk.java.net/jdk/pull/4901/files/7c1b32bc..26bd9307 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4901&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4901&range=00-01 Stats: 6 lines in 1 file changed: 5 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4901/head:pull/4901 PR: https://git.openjdk.java.net/jdk/pull/4901 From dholmes at openjdk.java.net Mon Jul 26 23:32:53 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 26 Jul 2021 23:32:53 GMT Subject: RFR: 8269523: runtime/Safepoint/TestAbortOnVMOperationTimeout.java failed when expecting 'VM operation took too long' In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 00:23:43 GMT, David Holmes wrote: > Please review this simple test adjustment: > - dropped 5ms timeout as we have seen execution as low as 2ms > - enabled GC logging > - report output in all cases to allow ease of analysis > > Testing: ran 10x on macos/linux/Windows x64 and macos Aarch64 to check execution times and adjusted test accordingly > > Thanks, > David I made the changes as suggested but they made no difference to the observed execution times. I still see execution as low as 2ms, so I still have to drop the 5ms test case. ------------- PR: https://git.openjdk.java.net/jdk/pull/4901 From pchilanomate at openjdk.java.net Mon Jul 26 23:41:40 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 26 Jul 2021 23:41:40 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 23:23:36 GMT, David Holmes wrote: > Updates are good. > Thanks for the review David! Patricio ------------- PR: https://git.openjdk.java.net/jdk17/pull/283 From jwilhelm at openjdk.java.net Tue Jul 27 00:10:16 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 27 Jul 2021 00:10:16 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8269150: UnicodeReader not translating \u005c\\u005d to \\] - 8271175: runtime/jni/FindClassUtf8/FindClassUtf8.java doesn't have to be run in othervm - 8271222: two runtime/Monitor tests don't check exit code - 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4907&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4907&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4907/files Stats: 118 lines in 6 files changed: 103 ins; 4 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/4907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4907/head:pull/4907 PR: https://git.openjdk.java.net/jdk/pull/4907 From jwilhelm at openjdk.java.net Tue Jul 27 01:01:43 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 27 Jul 2021 01:01:43 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: <-OT6zWAEV5o2OgQis1sjbtEDQD35nUYjxdaevupzDsg=.31df5a31-e2ba-4d9c-a682-275625c83bec@github.com> On Tue, 27 Jul 2021 00:00:03 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: eb6da888 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/eb6da88817f7bc903a51130271c9a5de928c603d Stats: 118 lines in 6 files changed: 103 ins; 4 del; 11 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4907 From dholmes at openjdk.java.net Tue Jul 27 02:47:34 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Jul 2021 02:47:34 GMT Subject: [jdk17] RFR: 8271223: two runtime/ClassFile tests don't check exit code In-Reply-To: References: Message-ID: <7yMMRDrOb0JtSfPAWpcG1Y72GwAREDKKHQbVpRDWbp8=.12940b9f-993a-4a51-923b-0d96075539bd@github.com> On Fri, 23 Jul 2021 16:13:17 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial patch? > > testing: `runtime/ClassFile` tests on `{linux,windows,macos}-x64` > > Thanks, > -- Igor Oops! Sorry about that. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/281 From dholmes at openjdk.java.net Tue Jul 27 02:52:32 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Jul 2021 02:52:32 GMT Subject: RFR: 8212961: [TESTBUG] vmTestbase/nsk/stress/jni/ native code cleanup [v3] In-Reply-To: References: <7aP-08axd0yopgPxVTRkpm9F_QjQfPx6OmI3yXYca8c=.2b58565b-6004-42d6-9260-72c0832c8c2d@github.com> Message-ID: <_yaUVCPtlWLBSQUsP74OgVFqU3DNHOTNzqReYtJl96A=.729b520d-8c9d-4be0-8b1b-cb46de26b77f@github.com> On Mon, 26 Jul 2021 17:12:01 GMT, Igor Ignatyev wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> @tstuefe feedback > > LGTM Thanks for the review @iignatev ! ------------- PR: https://git.openjdk.java.net/jdk/pull/4882 From dholmes at openjdk.java.net Tue Jul 27 02:52:33 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Jul 2021 02:52:33 GMT Subject: Integrated: 8212961: [TESTBUG] vmTestbase/nsk/stress/jni/ native code cleanup In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 22:42:20 GMT, David Holmes wrote: > Please review what is primarily a code style cleanup with some old native code: > > - add spaces around operators and after commas > - fixed indent and line breaks > - added braces to blocks > - replaced raw malloc with c_malloc (check malloc) > - fixed CE macro using and exception processing in general > - added different CHECK macro for monitor enter/exit > - removed some unreachable explicit exception checking code > > I staged this as multiple commits to try and make the changes more obvious at each step (and if you hide whitespace changes it simplifies quite a bit), but it may be easier to just look at the end results and see if anything jumps out as still needing changing. > > Note: there was no attempt to actually change the logic of any test or rewrite them in a better way - that is out of scope for the cleanup. The only logic changes relates to the CE macro and exception/error checking. > > Testing: > - local running of the tests themselves > - tier5 testing in our CI system (in progress). > > This may be of interest to @iignatev and @lmesnik . > > Thanks, > David This pull request has now been integrated. Changeset: fde18313 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/fde183130bc6379fe0d4624bbeaf252d0e9a15c8 Stats: 777 lines in 8 files changed: 111 ins; 121 del; 545 mod 8212961: [TESTBUG] vmTestbase/nsk/stress/jni/ native code cleanup Reviewed-by: stuefe, iignatyev ------------- PR: https://git.openjdk.java.net/jdk/pull/4882 From iignatyev at openjdk.java.net Tue Jul 27 03:03:40 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 27 Jul 2021 03:03:40 GMT Subject: [jdk17] RFR: 8271223: two runtime/ClassFile tests don't check exit code In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 16:13:17 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial patch? > > testing: `runtime/ClassFile` tests on `{linux,windows,macos}-x64` > > Thanks, > -- Igor Thank you again. ------------- PR: https://git.openjdk.java.net/jdk17/pull/281 From iignatyev at openjdk.java.net Tue Jul 27 03:03:41 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 27 Jul 2021 03:03:41 GMT Subject: [jdk17] Integrated: 8271223: two runtime/ClassFile tests don't check exit code In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 16:13:17 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial patch? > > testing: `runtime/ClassFile` tests on `{linux,windows,macos}-x64` > > Thanks, > -- Igor This pull request has now been integrated. Changeset: cea7bc2d Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk17/commit/cea7bc2dea8e179425db19998665f85c0b124d71 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod 8271223: two runtime/ClassFile tests don't check exit code Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk17/pull/281 From shade at openjdk.java.net Tue Jul 27 06:00:34 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 27 Jul 2021 06:00:34 GMT Subject: RFR: 8269523: runtime/Safepoint/TestAbortOnVMOperationTimeout.java failed when expecting 'VM operation took too long' [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 23:32:53 GMT, David Holmes wrote: >> Please review this simple test adjustment: >> - dropped 5ms timeout as we have seen execution as low as 2ms >> - enabled GC logging >> - report output in all cases to allow ease of analysis >> >> Testing: ran 10x on macos/linux/Windows x64 and macos Aarch64 to check execution times and adjusted test accordingly >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Robustness suggestions from @shipilev That's fine, thanks for trying. I have a minor suggestion. test/hotspot/jtreg/runtime/Safepoint/TestAbortOnVMOperationTimeout.java line 40: > 38: > 39: // A static array is unlikely to be optimised away by the JIT. > 40: static Object[] arr = new Object[10_000_000]; Initialization should be under `args.length > 0` check. We don't need it in the driver code. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4901 From shade at openjdk.java.net Tue Jul 27 07:12:53 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 27 Jul 2021 07:12:53 GMT Subject: RFR: 8269523: runtime/Safepoint/TestAbortOnVMOperationTimeout.java failed when expecting 'VM operation took too long' [v3] In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 07:09:41 GMT, David Holmes wrote: >> Please review this simple test adjustment: >> - dropped 5ms timeout as we have seen execution as low as 2ms >> - enabled GC logging >> - report output in all cases to allow ease of analysis >> >> Testing: ran 10x on macos/linux/Windows x64 and macos Aarch64 to check execution times and adjusted test accordingly >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fixed array initialization Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4901 From dholmes at openjdk.java.net Tue Jul 27 07:12:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Jul 2021 07:12:52 GMT Subject: RFR: 8269523: runtime/Safepoint/TestAbortOnVMOperationTimeout.java failed when expecting 'VM operation took too long' [v3] In-Reply-To: References: Message-ID: > Please review this simple test adjustment: > - dropped 5ms timeout as we have seen execution as low as 2ms > - enabled GC logging > - report output in all cases to allow ease of analysis > > Testing: ran 10x on macos/linux/Windows x64 and macos Aarch64 to check execution times and adjusted test accordingly > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Fixed array initialization ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4901/files - new: https://git.openjdk.java.net/jdk/pull/4901/files/26bd9307..76340d74 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4901&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4901&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4901/head:pull/4901 PR: https://git.openjdk.java.net/jdk/pull/4901 From cgo at openjdk.java.net Tue Jul 27 11:03:53 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Tue, 27 Jul 2021 11:03:53 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 13:17:58 GMT, Christoph G?ttschkes wrote: > Hi, > > please review this fix for the template interpreter for ARM32-softfp. > > With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. > > https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 > > I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. > > Old ldc2_w implementation (before condy was implemented for ARM32): > > https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 > > Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 I changed the code as suggested. Now __SOFTFP__ is used instead of ABI_HARD and the `#ifdef` is inside the `JVM_CONSTANT_Double` case only, loading double constants as needed. Other changes are only renaming labels. ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From cgo at openjdk.java.net Tue Jul 27 11:03:53 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Tue, 27 Jul 2021 11:03:53 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter [v2] In-Reply-To: References: Message-ID: > Hi, > > please review this fix for the template interpreter for ARM32-softfp. > > With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. > > https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 > > I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. > > Old ldc2_w implementation (before condy was implemented for ARM32): > > https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 > > Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: Use __SOFTFP__ instead of __ABI_HARD__, shrink ifdef blocks. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4767/files - new: https://git.openjdk.java.net/jdk/pull/4767/files/b0d8fa6a..13c7824a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4767&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4767&range=00-01 Stats: 27 lines in 1 file changed: 6 ins; 14 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4767.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4767/head:pull/4767 PR: https://git.openjdk.java.net/jdk/pull/4767 From shade at openjdk.java.net Tue Jul 27 12:10:33 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 27 Jul 2021 12:10:33 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter [v2] In-Reply-To: References: Message-ID: <6H9pm9A7sdioHrscLH-VhEzwxq1mR3LJJhtGyH1jgck=.360612cd-2c60-4a26-9379-da5051325f43@github.com> On Tue, 27 Jul 2021 11:03:53 GMT, Christoph G?ttschkes wrote: >> Hi, >> >> please review this fix for the template interpreter for ARM32-softfp. >> >> With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. >> >> https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 >> >> I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. >> >> Old ldc2_w implementation (before condy was implemented for ARM32): >> >> https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 >> >> Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 > > Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: > > Use __SOFTFP__ instead of __ABI_HARD__, shrink ifdef blocks. This looks fine to me, thanks! Assuming it passes `tier1` on soft/hard-float targets, we are good to go. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4767 From dcubed at openjdk.java.net Tue Jul 27 15:44:35 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 27 Jul 2021 15:44:35 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 22:40:53 GMT, Patricio Chilano Mateo wrote: >> Hi, >> >> Please review this small patch. When self-suspending, a JavaThread might reach SafepointSynchronize::block() with a state of _thread_in_vm which is not listed as a valid state for safepoint polling. There are a couple of simple ways to fix this. As suggested by @dholmes-ora we can avoid the handshake machinery altogether and directly self-suspend. Since this issue is intermittent and in tier7 which I didn't run as many times as other lower tiers it escaped my testing of 8270085. >> >> Testing in mach5 tiers1-7. I also reproduced the test failures locally and verified that now both hs202t002.java and ThreadSuspendSelf.java are passing. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > move log statement back inside loop Marked as reviewed by dcubed (Reviewer). In `src/hotspot/share/runtime/safepointMechanism.cpp`, I would love to see: void SafepointMechanism::process(JavaThread *thread, bool allow_suspend) { // Read global poll and has_handshake after local poll OrderAccess::loadload(); // local poll already checked, if used. bool need_rechecking; do { assert(is_a_block_safe_state(thread->thread_state()), "thread state is not safe for a SafepointSynchronize::block()"); if (global_poll()) { // Any load in ::block() must not pass the global poll load. // Otherwise we might load an old safepoint counter (for example). OrderAccess::loadload(); SafepointSynchronize::block(thread); } We don't have an `is_a_block_safe_state()` function so I would be okay with a simple check like this: assert(thread->thread_state() != _thread_in_vm, "thread state is not safe for a SafepointSynchronize::block()"); I looked at both `SafepointSynchronize::handshake_safe()` and `safepoint_safe_with()` and neither of those is quite right. I'm okay with the changes as they are, but I'd love to see an assert() added in `SafepointMechanism::process()` as I describe above. I think this would help catch any other unexpected go-to-a-safepoint from the wrong state errors. If you decide to add `is_a_block_safe_state()`, then add it above SafepointSynchronize::block() and use it to determine what safepoint safe states are accepted by SafepointSynchronize::block(), i.e., share the new function. ------------- PR: https://git.openjdk.java.net/jdk17/pull/283 From pchilanomate at openjdk.java.net Tue Jul 27 16:51:37 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 27 Jul 2021 16:51:37 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" [v3] In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 15:41:15 GMT, Daniel D. Daugherty wrote: > If you decide to add `is_a_block_safe_state()`, then add it above > SafepointSynchronize::block() and use it to determine what safepoint > safe states are accepted by SafepointSynchronize::block(), i.e., share > the new function. > So having an assert only for the _thread_in_vm case doesn't seem right to me since it would test only for this specific case that we are fixing. I can add the is_a_block_safe_state() method, but if we want to avoid code and check duplication I would have to remove the current switch statement from SafepointSynchronize::block(). Then the assert you want can be made a guarantee. Something like this: https://github.com/pchilano/jdk17/commit/db0f8eb4dba08d6a7250bd9e87816f2f024fa600 I defined is_a_block_safe_state() in safepoint.hpp to allow inlining in SafepointMechanism::process(). Unless you want to keep the check of state in ::block, in which case I can add the guarantee in ::block instead and leave it in process() as an assert. The duplicate check would be only in debug mode in that case. ------------- PR: https://git.openjdk.java.net/jdk17/pull/283 From kvn at openjdk.java.net Tue Jul 27 17:21:39 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 27 Jul 2021 17:21:39 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 22:40:53 GMT, Patricio Chilano Mateo wrote: >> Hi, >> >> Please review this small patch. When self-suspending, a JavaThread might reach SafepointSynchronize::block() with a state of _thread_in_vm which is not listed as a valid state for safepoint polling. There are a couple of simple ways to fix this. As suggested by @dholmes-ora we can avoid the handshake machinery altogether and directly self-suspend. Since this issue is intermittent and in tier7 which I didn't run as many times as other lower tiers it escaped my testing of 8270085. >> >> Testing in mach5 tiers1-7. I also reproduced the test failures locally and verified that now both hs202t002.java and ThreadSuspendSelf.java are passing. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > move log statement back inside loop Note, currently you need to get approval for JDK 17 fix according to: http://openjdk.java.net/jeps/3#Fix-Request-Process ------------- PR: https://git.openjdk.java.net/jdk17/pull/283 From pchilanomate at openjdk.java.net Tue Jul 27 17:28:38 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 27 Jul 2021 17:28:38 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 22:40:53 GMT, Patricio Chilano Mateo wrote: >> Hi, >> >> Please review this small patch. When self-suspending, a JavaThread might reach SafepointSynchronize::block() with a state of _thread_in_vm which is not listed as a valid state for safepoint polling. There are a couple of simple ways to fix this. As suggested by @dholmes-ora we can avoid the handshake machinery altogether and directly self-suspend. Since this issue is intermittent and in tier7 which I didn't run as many times as other lower tiers it escaped my testing of 8270085. >> >> Testing in mach5 tiers1-7. I also reproduced the test failures locally and verified that now both hs202t002.java and ThreadSuspendSelf.java are passing. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > move log statement back inside loop Hi Vladimir, > Note, currently you need to get approval for JDK 17 fix according to: > http://openjdk.java.net/jeps/3#Fix-Request-Process > Right, I was waiting for the 2 reviews before posting the fix request. I'll do that right after all comments are resolved. Thanks, Patricio ------------- PR: https://git.openjdk.java.net/jdk17/pull/283 From iignatyev at openjdk.java.net Tue Jul 27 18:19:53 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 27 Jul 2021 18:19:53 GMT Subject: [jdk17] RFR: 8271224: runtime/EnclosingMethodAttr/EnclMethodAttr.java doesn't check exit code Message-ID: Hi all, could you please review this small patch? Thanks, -- Igor ------------- Commit messages: - copyright year - 8271224 Changes: https://git.openjdk.java.net/jdk17/pull/284/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=284&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271224 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/284.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/284/head:pull/284 PR: https://git.openjdk.java.net/jdk17/pull/284 From pchilanomate at openjdk.java.net Tue Jul 27 18:36:42 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 27 Jul 2021 18:36:42 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" [v3] In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 16:48:14 GMT, Patricio Chilano Mateo wrote: > If you decide to add `is_a_block_safe_state()`, then add it above > SafepointSynchronize::block() and use it to determine what safepoint > safe states are accepted by SafepointSynchronize::block(), i.e., share > the new function. > So as we discussed offline in order to minimize changes going to 17 and given that it's simple to figure out by code inspection that all callers of process_if_requested() are either in a trans or Java state and the issue with the wrong state in 8270085 is clearly fixed, I created 8271348 to add the sanity check in 18 to guard against future code changes falling in this same issue. ------------- PR: https://git.openjdk.java.net/jdk17/pull/283 From pchilanomate at openjdk.java.net Tue Jul 27 18:36:42 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 27 Jul 2021 18:36:42 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 22:40:53 GMT, Patricio Chilano Mateo wrote: >> Hi, >> >> Please review this small patch. When self-suspending, a JavaThread might reach SafepointSynchronize::block() with a state of _thread_in_vm which is not listed as a valid state for safepoint polling. There are a couple of simple ways to fix this. As suggested by @dholmes-ora we can avoid the handshake machinery altogether and directly self-suspend. Since this issue is intermittent and in tier7 which I didn't run as many times as other lower tiers it escaped my testing of 8270085. >> >> Testing in mach5 tiers1-7. I also reproduced the test failures locally and verified that now both hs202t002.java and ThreadSuspendSelf.java are passing. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > move log statement back inside loop Thanks for the review Dan! ------------- PR: https://git.openjdk.java.net/jdk17/pull/283 From dcubed at openjdk.java.net Tue Jul 27 18:41:31 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 27 Jul 2021 18:41:31 GMT Subject: [jdk17] RFR: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" [v3] In-Reply-To: References: Message-ID: <7rHZOpNrjX4G4RSQ5BuB5bVj10eqYTq4KhcMW_rMKaQ=.fafaaf0a-d64a-48d0-9d31-e04ba1a499a9@github.com> On Mon, 26 Jul 2021 22:40:53 GMT, Patricio Chilano Mateo wrote: >> Hi, >> >> Please review this small patch. When self-suspending, a JavaThread might reach SafepointSynchronize::block() with a state of _thread_in_vm which is not listed as a valid state for safepoint polling. There are a couple of simple ways to fix this. As suggested by @dholmes-ora we can avoid the handshake machinery altogether and directly self-suspend. Since this issue is intermittent and in tier7 which I didn't run as many times as other lower tiers it escaped my testing of 8270085. >> >> Testing in mach5 tiers1-7. I also reproduced the test failures locally and verified that now both hs202t002.java and ThreadSuspendSelf.java are passing. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > move log statement back inside loop Thanks for filing: JDK-8271348 Add stronger sanity check of thread state when polling for safepoint/handshakes https://bugs.openjdk.java.net/browse/JDK-8271348 Still thumbs up! ------------- PR: https://git.openjdk.java.net/jdk17/pull/283 From iignatyev at openjdk.java.net Tue Jul 27 20:03:41 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 27 Jul 2021 20:03:41 GMT Subject: [jdk17] RFR: 8271350: runtime/Safepoint tests use OutputAnalyzer::shouldMatch instead of shouldContaint Message-ID: <6ye2hRwsEEziZrK1ljudm7evMp2WOA9eB2UcxqJrBJc=.e05743bb-66ca-4745-897d-8ef0a35a63f6@github.com> Hi all, could you please review this small patch? from JBS: > `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` and `TestAbortOnVMOperationTimeout.java` tests use `j.t.l.p.OutputAnalyzer::shouldMatch` method, which accepts a regular expression, yet pass a fixed string as an argument. testing: ``runtime/Safepoint/` on `{windows,linux,macos}-x64` Thanks, -- Igor ------------- Commit messages: - 8271350 Changes: https://git.openjdk.java.net/jdk17/pull/285/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=285&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271350 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk17/pull/285.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/285/head:pull/285 PR: https://git.openjdk.java.net/jdk17/pull/285 From mseledtsov at openjdk.java.net Tue Jul 27 20:13:29 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Tue, 27 Jul 2021 20:13:29 GMT Subject: [jdk17] RFR: 8271350: runtime/Safepoint tests use OutputAnalyzer::shouldMatch instead of shouldContaint In-Reply-To: <6ye2hRwsEEziZrK1ljudm7evMp2WOA9eB2UcxqJrBJc=.e05743bb-66ca-4745-897d-8ef0a35a63f6@github.com> References: <6ye2hRwsEEziZrK1ljudm7evMp2WOA9eB2UcxqJrBJc=.e05743bb-66ca-4745-897d-8ef0a35a63f6@github.com> Message-ID: On Tue, 27 Jul 2021 19:55:44 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch? > > from JBS: >> `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` and `TestAbortOnVMOperationTimeout.java` tests use `j.t.l.p.OutputAnalyzer::shouldMatch` method, which accepts a regular expression, yet pass a fixed string as an argument. > > testing: ``runtime/Safepoint/` on `{windows,linux,macos}-x64` > > Thanks, > -- Igor Change looks good to me. ------------- Marked as reviewed by mseledtsov (Committer). PR: https://git.openjdk.java.net/jdk17/pull/285 From mseledtsov at openjdk.java.net Tue Jul 27 20:15:38 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Tue, 27 Jul 2021 20:15:38 GMT Subject: [jdk17] RFR: 8271224: runtime/EnclosingMethodAttr/EnclMethodAttr.java doesn't check exit code In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 18:12:35 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch? > > Thanks, > -- Igor Looks good to me. ------------- Marked as reviewed by mseledtsov (Committer). PR: https://git.openjdk.java.net/jdk17/pull/284 From mseledtsov at openjdk.java.net Tue Jul 27 22:10:31 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Tue, 27 Jul 2021 22:10:31 GMT Subject: RFR: 8269523: runtime/Safepoint/TestAbortOnVMOperationTimeout.java failed when expecting 'VM operation took too long' [v3] In-Reply-To: References: Message-ID: <-i93oKIw9rwf0k_5Ql6-msJh_odYCXMuG4fU1SZuY_k=.c30a1dfd-63cc-4edc-8b55-8c0f78bdb02b@github.com> On Tue, 27 Jul 2021 07:12:52 GMT, David Holmes wrote: >> Please review this simple test adjustment: >> - dropped 5ms timeout as we have seen execution as low as 2ms >> - enabled GC logging >> - report output in all cases to allow ease of analysis >> >> Testing: ran 10x on macos/linux/Windows x64 and macos Aarch64 to check execution times and adjusted test accordingly >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fixed array initialization Change looks good to me. Please update copyright year before integration. ------------- Marked as reviewed by mseledtsov (Committer). PR: https://git.openjdk.java.net/jdk/pull/4901 From dholmes at openjdk.java.net Tue Jul 27 23:12:32 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Jul 2021 23:12:32 GMT Subject: [jdk17] RFR: 8271350: runtime/Safepoint tests use OutputAnalyzer::shouldMatch instead of shouldContaint In-Reply-To: <6ye2hRwsEEziZrK1ljudm7evMp2WOA9eB2UcxqJrBJc=.e05743bb-66ca-4745-897d-8ef0a35a63f6@github.com> References: <6ye2hRwsEEziZrK1ljudm7evMp2WOA9eB2UcxqJrBJc=.e05743bb-66ca-4745-897d-8ef0a35a63f6@github.com> Message-ID: <0clKhcHk-DENm5DPCgi9ktcxiRXluGLdBOJKwkbX81A=.d7659f29-2859-435c-bbf5-ebad3c04eceb@github.com> On Tue, 27 Jul 2021 19:55:44 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch? > > from JBS: >> `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` and `TestAbortOnVMOperationTimeout.java` tests use `j.t.l.p.OutputAnalyzer::shouldMatch` method, which accepts a regular expression, yet pass a fixed string as an argument. > > testing: ``runtime/Safepoint/` on `{windows,linux,macos}-x64` > > Thanks, > -- Igor This doesn't really make any difference but okay. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/285 From dholmes at openjdk.java.net Tue Jul 27 23:19:31 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Jul 2021 23:19:31 GMT Subject: RFR: 8269523: runtime/Safepoint/TestAbortOnVMOperationTimeout.java failed when expecting 'VM operation took too long' [v3] In-Reply-To: <-i93oKIw9rwf0k_5Ql6-msJh_odYCXMuG4fU1SZuY_k=.c30a1dfd-63cc-4edc-8b55-8c0f78bdb02b@github.com> References: <-i93oKIw9rwf0k_5Ql6-msJh_odYCXMuG4fU1SZuY_k=.c30a1dfd-63cc-4edc-8b55-8c0f78bdb02b@github.com> Message-ID: <10qCB_xVuEmr_3DIZfIVg_mmhkEiqfFWpOp0yqG9P9g=.5de36c0f-6314-44e5-bc2d-5be3dac33dc6@github.com> On Tue, 27 Jul 2021 22:07:03 GMT, Mikhailo Seledtsov wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed array initialization > > Change looks good to me. Please update copyright year before integration. @mseledts thanks for the review. The file only has a Red Hat copyright notice which I can't/shouldn't modify. The changes I made did not warrant IMO adding an Oracle copyright. So I left it as-is. ------------- PR: https://git.openjdk.java.net/jdk/pull/4901 From iignatyev at openjdk.java.net Tue Jul 27 23:21:33 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 27 Jul 2021 23:21:33 GMT Subject: [jdk17] RFR: 8271174: runtime/ClassFile/UnsupportedClassFileVersion.java can be run in driver mode In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 01:30:28 GMT, David Holmes wrote: >> Hi all, >> >> could you please review this trivial patch that switches execution mode in `runtime/ClassFile/UnsupportedClassFileVersion.java` test to `driver`? >> >> testing: `runtime/ClassFile/UnsupportedClassFileVersion.java` on `{linux,windows,macos}-x64` >> >> Thanks, >> -- Igor > > test/hotspot/jtreg/runtime/ClassFile/UnsupportedClassFileVersion.java line 30: > >> 28: * java.base/jdk.internal.misc >> 29: * java.management >> 30: * @compile -XDignore.symbol.file UnsupportedClassFileVersion.java > > I can't find what -XDignore.symbol.file was used for, so am unsure if removing it is in fact okay in all circumstances. ?? I believe we had to have it b/c we used JDK internal API, i.e. asm, now we have corresponding `@modules` tags, and `-XDignore.symbol.file` isn't need anymore. also, it's used at `@compile`, so if it is required, the test would fail fast and (largely) independently from JVM configurations. ------------- PR: https://git.openjdk.java.net/jdk17/pull/276 From iignatyev at openjdk.java.net Tue Jul 27 23:23:31 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 27 Jul 2021 23:23:31 GMT Subject: [jdk17] RFR: 8271350: runtime/Safepoint tests use OutputAnalyzer::shouldMatch instead of shouldContaint In-Reply-To: <0clKhcHk-DENm5DPCgi9ktcxiRXluGLdBOJKwkbX81A=.d7659f29-2859-435c-bbf5-ebad3c04eceb@github.com> References: <6ye2hRwsEEziZrK1ljudm7evMp2WOA9eB2UcxqJrBJc=.e05743bb-66ca-4745-897d-8ef0a35a63f6@github.com> <0clKhcHk-DENm5DPCgi9ktcxiRXluGLdBOJKwkbX81A=.d7659f29-2859-435c-bbf5-ebad3c04eceb@github.com> Message-ID: On Tue, 27 Jul 2021 23:09:15 GMT, David Holmes wrote: > This doesn't really make any difference but okay. in case of `Timed out while spinning to reach a safepoint.`, it does ;) thanks for the reviews! -- Igor ------------- PR: https://git.openjdk.java.net/jdk17/pull/285 From iignatyev at openjdk.java.net Tue Jul 27 23:23:32 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 27 Jul 2021 23:23:32 GMT Subject: [jdk17] Integrated: 8271350: runtime/Safepoint tests use OutputAnalyzer::shouldMatch instead of shouldContaint In-Reply-To: <6ye2hRwsEEziZrK1ljudm7evMp2WOA9eB2UcxqJrBJc=.e05743bb-66ca-4745-897d-8ef0a35a63f6@github.com> References: <6ye2hRwsEEziZrK1ljudm7evMp2WOA9eB2UcxqJrBJc=.e05743bb-66ca-4745-897d-8ef0a35a63f6@github.com> Message-ID: <-9NJHB4ngSbmYyF7Q7U4pa4W7nPGbp4bbtalHohgauk=.ff938a08-2966-4d96-a599-16b58ef02180@github.com> On Tue, 27 Jul 2021 19:55:44 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch? > > from JBS: >> `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` and `TestAbortOnVMOperationTimeout.java` tests use `j.t.l.p.OutputAnalyzer::shouldMatch` method, which accepts a regular expression, yet pass a fixed string as an argument. > > testing: ``runtime/Safepoint/` on `{windows,linux,macos}-x64` > > Thanks, > -- Igor This pull request has now been integrated. Changeset: f1e15c8c Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk17/commit/f1e15c8c8f598f3726fd6b3f65fe5ab155a2ee28 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod 8271350: runtime/Safepoint tests use OutputAnalyzer::shouldMatch instead of shouldContaint Reviewed-by: mseledtsov, dholmes ------------- PR: https://git.openjdk.java.net/jdk17/pull/285 From xliu at openjdk.java.net Tue Jul 27 23:45:40 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 27 Jul 2021 23:45:40 GMT Subject: RFR: 8271353: PerfDataManager::destroy crashes in VM_Exit Message-ID: This patch check PerfDataManager::_sampled and _constants is NULL. if it is, return -1. When the user enables UL `-Xlog:perf+datacreation=debug`, it may crash in PerfDataManager::destroy(). The following line will crash when _sampled is NULL. log_debug(perf, datacreation)("Total = %d, Sampled = %d, Constants = %d", _all->length(), _sampled->length(), _constants->length()); This only happens when UsePerfData is on and PerfDataManager::destroy() is invoked before StatSampler::initialize() which initializes PerfDataManager::_sampled. PerfDataManager::destroy() is called by VM_Exit which can be triggered by SIGINT on Linux anytime. A reproducible: invoke the following command and keep pressing Ctrl-c. $perf stat -r 100 java -Xlog:perf+datacreation=debug --version ------------- Commit messages: - 8271353: PerfDataManager::destroy crashes in VM_Exit Changes: https://git.openjdk.java.net/jdk/pull/4913/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4913&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271353 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4913.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4913/head:pull/4913 PR: https://git.openjdk.java.net/jdk/pull/4913 From mseledtsov at openjdk.java.net Wed Jul 28 02:39:30 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Wed, 28 Jul 2021 02:39:30 GMT Subject: [jdk17] RFR: 8271174: runtime/ClassFile/UnsupportedClassFileVersion.java can be run in driver mode In-Reply-To: References: Message-ID: <0_zakDzO0lTVAWH3O2mmujUYZ4RhoONC_Oz6Q62M1ls=.95ad0048-8d10-48df-81c8-f02b43cdd766@github.com> On Fri, 23 Jul 2021 00:25:19 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial patch that switches execution mode in `runtime/ClassFile/UnsupportedClassFileVersion.java` test to `driver`? > > testing: `runtime/ClassFile/UnsupportedClassFileVersion.java` on `{linux,windows,macos}-x64` > > Thanks, > -- Igor Marked as reviewed by mseledtsov (Committer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/276 From dholmes at openjdk.java.net Wed Jul 28 05:29:28 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Jul 2021 05:29:28 GMT Subject: RFR: 8271353: PerfDataManager::destroy crashes in VM_Exit In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 23:37:58 GMT, Xin Liu wrote: > This patch check PerfDataManager::_sampled and _constants is NULL. if it is, > return -1. > > When the user enables UL `-Xlog:perf+datacreation=debug`, it may crash in > PerfDataManager::destroy(). The following line will crash when _sampled is NULL. > > > log_debug(perf, datacreation)("Total = %d, Sampled = %d, Constants = %d", > _all->length(), _sampled->length(), _constants->length()); > > > This only happens when UsePerfData is on and PerfDataManager::destroy() is invoked before > StatSampler::initialize() which initializes PerfDataManager::_sampled. > PerfDataManager::destroy() is called by VM_Exit which can be triggered by SIGINT on Linux anytime. > > A reproducible: invoke the following command and keep pressing Ctrl-c. > $perf stat -r 100 java -Xlog:perf+datacreation=debug --version The additional NULL checks seem fine and trivial. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4913 From dholmes at openjdk.java.net Wed Jul 28 05:34:35 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Jul 2021 05:34:35 GMT Subject: [jdk17] RFR: 8271174: runtime/ClassFile/UnsupportedClassFileVersion.java can be run in driver mode In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 00:25:19 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial patch that switches execution mode in `runtime/ClassFile/UnsupportedClassFileVersion.java` test to `driver`? > > testing: `runtime/ClassFile/UnsupportedClassFileVersion.java` on `{linux,windows,macos}-x64` > > Thanks, > -- Igor Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/276 From dholmes at openjdk.java.net Wed Jul 28 05:34:35 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Jul 2021 05:34:35 GMT Subject: [jdk17] RFR: 8271174: runtime/ClassFile/UnsupportedClassFileVersion.java can be run in driver mode In-Reply-To: References: Message-ID: <_3kKT-Y0P5gCBKYR0jaaZwt7BiBwizO-FV3fnwzRBYo=.2a5f43bf-924a-46f2-a66f-e450716ee4d2@github.com> On Tue, 27 Jul 2021 23:18:06 GMT, Igor Ignatyev wrote: >> test/hotspot/jtreg/runtime/ClassFile/UnsupportedClassFileVersion.java line 30: >> >>> 28: * java.base/jdk.internal.misc >>> 29: * java.management >>> 30: * @compile -XDignore.symbol.file UnsupportedClassFileVersion.java >> >> I can't find what -XDignore.symbol.file was used for, so am unsure if removing it is in fact okay in all circumstances. ?? > > I believe we had to have it b/c we used JDK internal API, i.e. asm, now we have corresponding `@modules` tags, and `-XDignore.symbol.file` isn't need anymore. also, it's used at `@compile`, so if it is required, the test would fail fast and (largely) independently from JVM configurations. Okay, it seems it is not needed on this test as there are no warnings without it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk17/pull/276 From cgo at openjdk.java.net Wed Jul 28 07:34:31 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Wed, 28 Jul 2021 07:34:31 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 11:03:53 GMT, Christoph G?ttschkes wrote: >> Hi, >> >> please review this fix for the template interpreter for ARM32-softfp. >> >> With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. >> >> https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 >> >> I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. >> >> Old ldc2_w implementation (before condy was implemented for ARM32): >> >> https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 >> >> Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 > > Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: > > Use __SOFTFP__ instead of __ABI_HARD__, shrink ifdef blocks. Yes, hotspot tier1 on ARMv7-A (hard fload) and ARMv5TE (soft float) are passing. Windows build failure is unrelated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From shade at openjdk.java.net Wed Jul 28 07:50:30 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 28 Jul 2021 07:50:30 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter [v2] In-Reply-To: References: Message-ID: <2zrS_gQBosXqMCREqE4MkSNuXoY8-vdGL8ZtEqmXTUE=.b0b1c9bc-2201-42a3-9202-1c1d1edbea33@github.com> On Wed, 28 Jul 2021 07:31:50 GMT, Christoph G?ttschkes wrote: > Yes, hotspot tier1 on ARMv7-A (hard fload) and ARMv5TE (soft float) are passing. > Windows build failure is unrelated. OK, good. I'll be happy to sponsor this. ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From cgo at openjdk.java.net Wed Jul 28 08:28:32 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Wed, 28 Jul 2021 08:28:32 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 11:03:53 GMT, Christoph G?ttschkes wrote: >> Hi, >> >> please review this fix for the template interpreter for ARM32-softfp. >> >> With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. >> >> https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 >> >> I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. >> >> Old ldc2_w implementation (before condy was implemented for ARM32): >> >> https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 >> >> Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 > > Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: > > Use __SOFTFP__ instead of __ABI_HARD__, shrink ifdef blocks. Thanks, but don't we need a second reviewer, or is this change trivial enough? ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From shade at openjdk.java.net Wed Jul 28 08:39:30 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 28 Jul 2021 08:39:30 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jul 2021 08:25:56 GMT, Christoph G?ttschkes wrote: > Thanks, but don't we need a second reviewer, or is this change trivial enough? For ARM-specific code, I don't think you would get more Oracle reviewers. Maybe @bulasevich wants to take a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From dholmes at openjdk.java.net Wed Jul 28 10:12:49 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Jul 2021 10:12:49 GMT Subject: RFR: 8269934: RunThese24H.java failed with EXCEPTION_ACCESS_VIOLATION in java_lang_Thread::get_thread_status Message-ID: If a thread is attaching via JNI and has not yet created its Thread object it can be caught in a ThreadSnapshot during a thread dump (VM_DumpThreads) of all threads**, and the threadObj() will be NULL, so we can't pass it to get_thread_status(). ** JMM dumpThreads API The initial fix simply checks for a NULL threadObj() and reports thread status NEW in that case. Alternatively we could filter the attaching thread out completely in VM_DumpThreads::doit by expanding: if (jt->is_exiting() || jt->is_hidden_from_external_view()) { // skip terminating threads and hidden threads continue; } to also check jt->is_attaching_via_jni(). Note that higher-level code already filters out ThreadSnapshots with NULL threadObj() anyway so we could go either way. Testing: manual hacks - see bug report. - tier 1-3 sanity testing Thanks, David ------------- Commit messages: - 8269934: RunThese24H.java failed with EXCEPTION_ACCESS_VIOLATION in java_lang_Thread::get_thread_status Changes: https://git.openjdk.java.net/jdk/pull/4921/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4921&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269934 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4921.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4921/head:pull/4921 PR: https://git.openjdk.java.net/jdk/pull/4921 From github.com+42095927+borisulasevich at openjdk.java.net Wed Jul 28 11:12:34 2021 From: github.com+42095927+borisulasevich at openjdk.java.net (BorisUlasevich) Date: Wed, 28 Jul 2021 11:12:34 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 11:03:53 GMT, Christoph G?ttschkes wrote: >> Hi, >> >> please review this fix for the template interpreter for ARM32-softfp. >> >> With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. >> >> https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 >> >> I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. >> >> Old ldc2_w implementation (before condy was implemented for ARM32): >> >> https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 >> >> Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 > > Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: > > Use __SOFTFP__ instead of __ABI_HARD__, shrink ifdef blocks. (I am not a formal reviewer) I like the change. Though I do catch what was the original motivation, was it an incorrect behavior? Is there any test for that? And, frankly, I do not quite understand (NotLong && NotDouble) case for ldc2_w bytecode template which is designed to get long or double. Is condy_helper ever called here? ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From cgo at openjdk.java.net Wed Jul 28 11:34:35 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Wed, 28 Jul 2021 11:34:35 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 11:03:53 GMT, Christoph G?ttschkes wrote: >> Hi, >> >> please review this fix for the template interpreter for ARM32-softfp. >> >> With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. >> >> https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 >> >> I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. >> >> Old ldc2_w implementation (before condy was implemented for ARM32): >> >> https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 >> >> Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 > > Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: > > Use __SOFTFP__ instead of __ABI_HARD__, shrink ifdef blocks. Thanks for looking into this. The motivation is an incorrect behavior. The `ldc2_w` bytecode is used to load 3 different types of constants, `CONSTANT_Long`, `CONSTANT_Double`, and `CONSTANT_Dynamic`. The `condy_helper` should only be used to load constants of type `CONSTANT_Dynamic`. Currently it also loads `CONSTANT_Double` constants on soft-float targets, which is wrong and should not be done. For this specific faulty behavior, there is no test case and I don't think there can be one, as loading is done using the wrong path, but still succeeds. I don't think there are any test cases for loading primitive constants (as this is done while loading the runtime and therefor tested alot without a specific test case). There are some tests for constant dynamics in `test/hotspot/jtreg/runtime/condy`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From github.com+42095927+borisulasevich at openjdk.java.net Wed Jul 28 11:45:33 2021 From: github.com+42095927+borisulasevich at openjdk.java.net (BorisUlasevich) Date: Wed, 28 Jul 2021 11:45:33 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 11:03:53 GMT, Christoph G?ttschkes wrote: >> Hi, >> >> please review this fix for the template interpreter for ARM32-softfp. >> >> With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. >> >> https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 >> >> I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. >> >> Old ldc2_w implementation (before condy was implemented for ARM32): >> >> https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 >> >> Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 > > Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: > > Use __SOFTFP__ instead of __ABI_HARD__, shrink ifdef blocks. Ok, thanks. The change is good for me. ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From cgo at openjdk.java.net Wed Jul 28 13:15:31 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Wed, 28 Jul 2021 13:15:31 GMT Subject: RFR: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 11:03:53 GMT, Christoph G?ttschkes wrote: >> Hi, >> >> please review this fix for the template interpreter for ARM32-softfp. >> >> With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. >> >> https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 >> >> I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. >> >> Old ldc2_w implementation (before condy was implemented for ARM32): >> >> https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 >> >> Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 > > Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision: > > Use __SOFTFP__ instead of __ABI_HARD__, shrink ifdef blocks. Thank you. ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From cgo at openjdk.java.net Wed Jul 28 13:21:45 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Wed, 28 Jul 2021 13:21:45 GMT Subject: Integrated: 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 13:17:58 GMT, Christoph G?ttschkes wrote: > Hi, > > please review this fix for the template interpreter for ARM32-softfp. > > With the introduction of condy, the interpreter started to load double constants using the condy_helper, which is unnecessary. Also, the [resolve_ldc](https://github.com/openjdk/jdk/blob/8973867fb9568a3a527b763c9ce10cebdfb306d0/src/hotspot/share/interpreter/interpreterRuntime.cpp#L148) implementation of the interpreter runtime might not be designed to load constant values. It should only load strings and condy. > > https://github.com/openjdk/jdk/blob/2ee56fd1cf4acd634e19cc77b7c9a6858e1c315a/src/hotspot/cpu/arm/templateTable_arm.cpp#L515-L560 > > I refactored the ldc2_w bytecode imlpementation. Now, the ifdef between soft and hard float covers both types, CONSTANT_Long and CONSTANT_Double. I did this, because for the softfp, we can use a conditional cmp, since double and long are both placed on the stack in the same way. The same is also done for CONSTANT_Integer and CONSTANT_Float in the ldc bytecode implementation. Also, I think it is easier to follow the code this way. > > Old ldc2_w implementation (before condy was implemented for ARM32): > > https://github.com/openjdk/jdk/blob/7101b28dc3903be27cb46a00781f4d74f81f1114/src/hotspot/cpu/arm/templateTable_arm.cpp#L497-L537 > > Testing: ARMv7-A (hardfp) hotspot tier1, ARMv5TE (softfp) hotspot tier1 This pull request has now been integrated. Changeset: a066c7be Author: Christoph G?ttschkes Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/a066c7bed0f9aa45fb9384f75ae84943548cd859 Stats: 16 lines in 1 file changed: 5 ins; 4 del; 7 mod 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/4767 From stuefe at openjdk.java.net Wed Jul 28 14:24:29 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 28 Jul 2021 14:24:29 GMT Subject: RFR: 8271353: PerfDataManager::destroy crashes in VM_Exit In-Reply-To: References: Message-ID: <45O8u6-PD5NvUrA2BplqiRE1CLky2eg8NsNrz3jqNfE=.1072b550-934d-48eb-b62f-6d8fa47c22d5@github.com> On Tue, 27 Jul 2021 23:37:58 GMT, Xin Liu wrote: > This patch check PerfDataManager::_sampled and _constants is NULL. if it is, > return -1. > > When the user enables UL `-Xlog:perf+datacreation=debug`, it may crash in > PerfDataManager::destroy(). The following line will crash when _sampled is NULL. > > > log_debug(perf, datacreation)("Total = %d, Sampled = %d, Constants = %d", > _all->length(), _sampled->length(), _constants->length()); > > > This only happens when UsePerfData is on and PerfDataManager::destroy() is invoked before > StatSampler::initialize() which initializes PerfDataManager::_sampled. > PerfDataManager::destroy() is called by VM_Exit which can be triggered by SIGINT on Linux anytime. > > A reproducible: invoke the following command and keep pressing Ctrl-c. > $perf stat -r 100 java -Xlog:perf+datacreation=debug --version +1 ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4913 From stuefe at openjdk.java.net Wed Jul 28 14:25:34 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 28 Jul 2021 14:25:34 GMT Subject: RFR: 8269934: RunThese24H.java failed with EXCEPTION_ACCESS_VIOLATION in java_lang_Thread::get_thread_status In-Reply-To: References: Message-ID: On Wed, 28 Jul 2021 10:03:10 GMT, David Holmes wrote: > If a thread is attaching via JNI and has not yet created its Thread object it can be caught in a ThreadSnapshot during a thread dump (VM_DumpThreads) of all threads**, and the threadObj() will be NULL, so we can't pass it to get_thread_status(). > > ** JMM dumpThreads API > > The initial fix simply checks for a NULL threadObj() and reports thread status NEW in that case. > > Alternatively we could filter the attaching thread out completely in VM_DumpThreads::doit by expanding: > > if (jt->is_exiting() || > jt->is_hidden_from_external_view()) { > // skip terminating threads and hidden threads > continue; > } > > to also check jt->is_attaching_via_jni(). > > Note that higher-level code already filters out ThreadSnapshots with NULL threadObj() anyway so we could go either way. > > Testing: manual hacks - see bug report. > - tier 1-3 sanity testing > > Thanks, > David This looks good to me. ..Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4921 From dcubed at openjdk.java.net Wed Jul 28 15:24:31 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 28 Jul 2021 15:24:31 GMT Subject: RFR: 8269934: RunThese24H.java failed with EXCEPTION_ACCESS_VIOLATION in java_lang_Thread::get_thread_status In-Reply-To: References: Message-ID: <2q5ydXJwaul0jEF2X2c0mDL6dSPmksfoJ2l1a7T7_JM=.01c14a0f-e336-41db-a287-6807f85c1801@github.com> On Wed, 28 Jul 2021 10:03:10 GMT, David Holmes wrote: > If a thread is attaching via JNI and has not yet created its Thread object it can be caught in a ThreadSnapshot during a thread dump (VM_DumpThreads) of all threads**, and the threadObj() will be NULL, so we can't pass it to get_thread_status(). > > ** JMM dumpThreads API > > The initial fix simply checks for a NULL threadObj() and reports thread status NEW in that case. > > Alternatively we could filter the attaching thread out completely in VM_DumpThreads::doit by expanding: > > if (jt->is_exiting() || > jt->is_hidden_from_external_view()) { > // skip terminating threads and hidden threads > continue; > } > > to also check jt->is_attaching_via_jni(). > > Note that higher-level code already filters out ThreadSnapshots with NULL threadObj() anyway so we could go either way. > > Testing: manual hacks - see bug report. > - tier 1-3 sanity testing > > Thanks, > David Nice catch! I'm always happy when we find a reason for one of these 24 hour stress test failures. Thumbs up! Your call on whether to change the code as I mentioned in my other comment. @sspitsyn - It would be great to have a Serviceability person chime in on this review... src/hotspot/share/services/threadService.cpp line 879: > 877: // If thread is still attaching then threadObj will be NULL. > 878: _thread_status = threadObj == NULL ? JavaThreadStatus::NEW > 879: : java_lang_Thread::get_thread_status(threadObj); I like the use of `JavaThreadStatus::NEW` here. Since L867 creates the _threadObj OopHandle, do you want to change both uses of `threadObj` to `_threadObj()`? Is that still how we fetch the oop from an OopHandle? Or even use `threadObj()`... Then we don't have to reason about whether the `threadObj` oop is still good... ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4921 From iignatyev at openjdk.java.net Wed Jul 28 15:41:36 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 28 Jul 2021 15:41:36 GMT Subject: [jdk17] RFR: 8271174: runtime/ClassFile/UnsupportedClassFileVersion.java can be run in driver mode In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 00:25:19 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial patch that switches execution mode in `runtime/ClassFile/UnsupportedClassFileVersion.java` test to `driver`? > > testing: `runtime/ClassFile/UnsupportedClassFileVersion.java` on `{linux,windows,macos}-x64` > > Thanks, > -- Igor David, Misha, thank you for your reviews. ------------- PR: https://git.openjdk.java.net/jdk17/pull/276 From iignatyev at openjdk.java.net Wed Jul 28 15:41:37 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 28 Jul 2021 15:41:37 GMT Subject: [jdk17] Integrated: 8271174: runtime/ClassFile/UnsupportedClassFileVersion.java can be run in driver mode In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 00:25:19 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial patch that switches execution mode in `runtime/ClassFile/UnsupportedClassFileVersion.java` test to `driver`? > > testing: `runtime/ClassFile/UnsupportedClassFileVersion.java` on `{linux,windows,macos}-x64` > > Thanks, > -- Igor This pull request has now been integrated. Changeset: c8ae7e5b Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk17/commit/c8ae7e5b035e693c77060f6fdcc1f21da7ddc839 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8271174: runtime/ClassFile/UnsupportedClassFileVersion.java can be run in driver mode Reviewed-by: mseledtsov, dholmes ------------- PR: https://git.openjdk.java.net/jdk17/pull/276 From iignatyev at openjdk.java.net Wed Jul 28 15:58:54 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 28 Jul 2021 15:58:54 GMT Subject: [jdk17] RFR: 8271402: mark hotspot runtime/os tests which ignore external VM flags Message-ID: <1tjisbUzo3fdrj7ZT1OtaE5dc4iUqUUHkXfGgdicVPE=.e2017b2d-72e6-4d1b-86d9-ca9a3359720e@github.com> Hi all, could you please review this small patch? Thanks, -- Igor ------------- Commit messages: - 8271402 Changes: https://git.openjdk.java.net/jdk17/pull/288/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=288&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271402 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/288.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/288/head:pull/288 PR: https://git.openjdk.java.net/jdk17/pull/288 From iignatyev at openjdk.java.net Wed Jul 28 16:02:48 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 28 Jul 2021 16:02:48 GMT Subject: [jdk17] RFR: 8271403: mark hotspot runtime/memory tests which ignore external VM flags Message-ID: Hi all, could you please review this small patch? Thanks, -- Igor ------------- Commit messages: - 8271403 Changes: https://git.openjdk.java.net/jdk17/pull/289/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=289&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271403 Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/289.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/289/head:pull/289 PR: https://git.openjdk.java.net/jdk17/pull/289 From minqi at openjdk.java.net Wed Jul 28 16:35:30 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 28 Jul 2021 16:35:30 GMT Subject: RFR: 8271353: PerfDataManager::destroy crashes in VM_Exit In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 23:37:58 GMT, Xin Liu wrote: > This patch check PerfDataManager::_sampled and _constants is NULL. if it is, > return -1. > > When the user enables UL `-Xlog:perf+datacreation=debug`, it may crash in > PerfDataManager::destroy(). The following line will crash when _sampled is NULL. > > > log_debug(perf, datacreation)("Total = %d, Sampled = %d, Constants = %d", > _all->length(), _sampled->length(), _constants->length()); > > > This only happens when UsePerfData is on and PerfDataManager::destroy() is invoked before > StatSampler::initialize() which initializes PerfDataManager::_sampled. > PerfDataManager::destroy() is called by VM_Exit which can be triggered by SIGINT on Linux anytime. > > A reproducible: invoke the following command and keep pressing Ctrl-c. > $perf stat -r 100 java -Xlog:perf+datacreation=debug --version Hi, Xin The copyright year needs updated. Maybe '0' is more meaningful than '-1'? ------------- PR: https://git.openjdk.java.net/jdk/pull/4913 From pchilanomate at openjdk.java.net Wed Jul 28 17:03:39 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 28 Jul 2021 17:03:39 GMT Subject: [jdk17] Integrated: 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 18:23:39 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review this small patch. When self-suspending, a JavaThread might reach SafepointSynchronize::block() with a state of _thread_in_vm which is not listed as a valid state for safepoint polling. There are a couple of simple ways to fix this. As suggested by @dholmes-ora we can avoid the handshake machinery altogether and directly self-suspend. Since this issue is intermittent and in tier7 which I didn't run as many times as other lower tiers it escaped my testing of 8270085. > > Testing in mach5 tiers1-7. I also reproduced the test failures locally and verified that now both hs202t002.java and ThreadSuspendSelf.java are passing. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 6878b05f Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk17/commit/6878b05f8fbc7bd72e79ec29a868008dde2321c6 Stats: 24 lines in 1 file changed: 13 ins; 6 del; 5 mod 8271251: JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" Reviewed-by: dholmes, dcubed ------------- PR: https://git.openjdk.java.net/jdk17/pull/283 From xliu at openjdk.java.net Wed Jul 28 17:44:57 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 28 Jul 2021 17:44:57 GMT Subject: RFR: 8271353: PerfDataManager::destroy crashes in VM_Exit [v2] In-Reply-To: References: Message-ID: > This patch check PerfDataManager::_sampled and _constants is NULL. if it is, > return -1. > > When the user enables UL `-Xlog:perf+datacreation=debug`, it may crash in > PerfDataManager::destroy(). The following line will crash when _sampled is NULL. > > > log_debug(perf, datacreation)("Total = %d, Sampled = %d, Constants = %d", > _all->length(), _sampled->length(), _constants->length()); > > > This only happens when UsePerfData is on and PerfDataManager::destroy() is invoked before > StatSampler::initialize() which initializes PerfDataManager::_sampled. > PerfDataManager::destroy() is called by VM_Exit which can be triggered by SIGINT on Linux anytime. > > A reproducible: invoke the following command and keep pressing Ctrl-c. > $perf stat -r 100 java -Xlog:perf+datacreation=debug --version Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Print 0 instead of -1 when _sampled or _constants is not avaiable. also update copyright year. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4913/files - new: https://git.openjdk.java.net/jdk/pull/4913/files/d94c9d35..dca5f37b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4913&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4913&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4913.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4913/head:pull/4913 PR: https://git.openjdk.java.net/jdk/pull/4913 From xliu at openjdk.java.net Wed Jul 28 17:44:57 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 28 Jul 2021 17:44:57 GMT Subject: RFR: 8271353: PerfDataManager::destroy crashes in VM_Exit [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jul 2021 16:32:37 GMT, Yumin Qi wrote: > Hi, Xin > The copyright year needs updated. > Maybe '0' is more meaningful than '-1'? Thanks for the head-up. I agree that 0 is easier to understand. I will update it. PerfDataManager::add_item() "appends" a PerfData. if _sampled is not NULL, it should be at least 1. ------------- PR: https://git.openjdk.java.net/jdk/pull/4913 From minqi at openjdk.java.net Wed Jul 28 20:01:33 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 28 Jul 2021 20:01:33 GMT Subject: RFR: 8271353: PerfDataManager::destroy crashes in VM_Exit [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jul 2021 17:44:57 GMT, Xin Liu wrote: >> This patch check PerfDataManager::_sampled and _constants is NULL. if it is, >> return -1. >> >> When the user enables UL `-Xlog:perf+datacreation=debug`, it may crash in >> PerfDataManager::destroy(). The following line will crash when _sampled is NULL. >> >> >> log_debug(perf, datacreation)("Total = %d, Sampled = %d, Constants = %d", >> _all->length(), _sampled->length(), _constants->length()); >> >> >> This only happens when UsePerfData is on and PerfDataManager::destroy() is invoked before >> StatSampler::initialize() which initializes PerfDataManager::_sampled. >> PerfDataManager::destroy() is called by VM_Exit which can be triggered by SIGINT on Linux anytime. >> >> A reproducible: invoke the following command and keep pressing Ctrl-c. >> $perf stat -r 100 java -Xlog:perf+datacreation=debug --version > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Print 0 instead of -1 when _sampled or _constants is not avaiable. > > also update copyright year. Marked as reviewed by minqi (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4913 From xliu at openjdk.java.net Wed Jul 28 21:08:29 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 28 Jul 2021 21:08:29 GMT Subject: RFR: 8271353: PerfDataManager::destroy crashes in VM_Exit [v2] In-Reply-To: References: Message-ID: <2luejQ9uecNqb4pLgc3EQbQYRfxb20rxt1IvFDkqkuA=.e2f25a96-bcec-49ee-93c9-d56c49768a67@github.com> On Wed, 28 Jul 2021 17:44:57 GMT, Xin Liu wrote: >> This patch check PerfDataManager::_sampled and _constants is NULL. if it is, >> return -1. >> >> When the user enables UL `-Xlog:perf+datacreation=debug`, it may crash in >> PerfDataManager::destroy(). The following line will crash when _sampled is NULL. >> >> >> log_debug(perf, datacreation)("Total = %d, Sampled = %d, Constants = %d", >> _all->length(), _sampled->length(), _constants->length()); >> >> >> This only happens when UsePerfData is on and PerfDataManager::destroy() is invoked before >> StatSampler::initialize() which initializes PerfDataManager::_sampled. >> PerfDataManager::destroy() is called by VM_Exit which can be triggered by SIGINT on Linux anytime. >> >> A reproducible: invoke the following command and keep pressing Ctrl-c. >> $perf stat -r 100 java -Xlog:perf+datacreation=debug --version > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Print 0 instead of -1 when _sampled or _constants is not avaiable. > > also update copyright year. Thank all reviewers. ------------- PR: https://git.openjdk.java.net/jdk/pull/4913 From dholmes at openjdk.java.net Wed Jul 28 22:54:31 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Jul 2021 22:54:31 GMT Subject: RFR: 8271353: PerfDataManager::destroy crashes in VM_Exit [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jul 2021 17:44:57 GMT, Xin Liu wrote: >> This patch check PerfDataManager::_sampled and _constants is NULL. if it is, >> return -1. >> >> When the user enables UL `-Xlog:perf+datacreation=debug`, it may crash in >> PerfDataManager::destroy(). The following line will crash when _sampled is NULL. >> >> >> log_debug(perf, datacreation)("Total = %d, Sampled = %d, Constants = %d", >> _all->length(), _sampled->length(), _constants->length()); >> >> >> This only happens when UsePerfData is on and PerfDataManager::destroy() is invoked before >> StatSampler::initialize() which initializes PerfDataManager::_sampled. >> PerfDataManager::destroy() is called by VM_Exit which can be triggered by SIGINT on Linux anytime. >> >> A reproducible: invoke the following command and keep pressing Ctrl-c. >> $perf stat -r 100 java -Xlog:perf+datacreation=debug --version > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Print 0 instead of -1 when _sampled or _constants is not avaiable. > > also update copyright year. I actually preferred the -1 to indicate "not available", but it doesn't really matter. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4913 From dholmes at openjdk.java.net Wed Jul 28 22:58:42 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Jul 2021 22:58:42 GMT Subject: [jdk17] RFR: 8271402: mark hotspot runtime/os tests which ignore external VM flags In-Reply-To: <1tjisbUzo3fdrj7ZT1OtaE5dc4iUqUUHkXfGgdicVPE=.e2017b2d-72e6-4d1b-86d9-ca9a3359720e@github.com> References: <1tjisbUzo3fdrj7ZT1OtaE5dc4iUqUUHkXfGgdicVPE=.e2017b2d-72e6-4d1b-86d9-ca9a3359720e@github.com> Message-ID: On Wed, 28 Jul 2021 15:52:31 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch? > > Thanks, > -- Igor Looks good and trivial. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/288 From dholmes at openjdk.java.net Wed Jul 28 23:00:30 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Jul 2021 23:00:30 GMT Subject: [jdk17] RFR: 8271403: mark hotspot runtime/memory tests which ignore external VM flags In-Reply-To: References: Message-ID: On Wed, 28 Jul 2021 15:55:45 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch? > > Thanks, > -- Igor Looks good and trivial. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/289 From dholmes at openjdk.java.net Wed Jul 28 23:07:32 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Jul 2021 23:07:32 GMT Subject: RFR: 8269934: RunThese24H.java failed with EXCEPTION_ACCESS_VIOLATION in java_lang_Thread::get_thread_status In-Reply-To: References: Message-ID: <3zSeaaAp2WYCrlDGi5j0y44z892n1y2KpyhIiwKu8OI=.d8f7e9ad-07da-48ce-b3ea-1e8912e9e9b8@github.com> On Wed, 28 Jul 2021 14:22:07 GMT, Thomas Stuefe wrote: >> If a thread is attaching via JNI and has not yet created its Thread object it can be caught in a ThreadSnapshot during a thread dump (VM_DumpThreads) of all threads**, and the threadObj() will be NULL, so we can't pass it to get_thread_status(). >> >> ** JMM dumpThreads API >> >> The initial fix simply checks for a NULL threadObj() and reports thread status NEW in that case. >> >> Alternatively we could filter the attaching thread out completely in VM_DumpThreads::doit by expanding: >> >> if (jt->is_exiting() || >> jt->is_hidden_from_external_view()) { >> // skip terminating threads and hidden threads >> continue; >> } >> >> to also check jt->is_attaching_via_jni(). >> >> Note that higher-level code already filters out ThreadSnapshots with NULL threadObj() anyway so we could go either way. >> >> Testing: manual hacks - see bug report. >> - tier 1-3 sanity testing >> >> Thanks, >> David > > This looks good to me. > > ..Thomas Thanks for the reviews @tstuefe and @dcubed-ojdk ! ------------- PR: https://git.openjdk.java.net/jdk/pull/4921 From xliu at openjdk.java.net Wed Jul 28 23:10:31 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 28 Jul 2021 23:10:31 GMT Subject: Integrated: 8271353: PerfDataManager::destroy crashes in VM_Exit In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 23:37:58 GMT, Xin Liu wrote: > This patch check PerfDataManager::_sampled and _constants is NULL. if it is, > return -1. > > When the user enables UL `-Xlog:perf+datacreation=debug`, it may crash in > PerfDataManager::destroy(). The following line will crash when _sampled is NULL. > > > log_debug(perf, datacreation)("Total = %d, Sampled = %d, Constants = %d", > _all->length(), _sampled->length(), _constants->length()); > > > This only happens when UsePerfData is on and PerfDataManager::destroy() is invoked before > StatSampler::initialize() which initializes PerfDataManager::_sampled. > PerfDataManager::destroy() is called by VM_Exit which can be triggered by SIGINT on Linux anytime. > > A reproducible: invoke the following command and keep pressing Ctrl-c. > $perf stat -r 100 java -Xlog:perf+datacreation=debug --version This pull request has now been integrated. Changeset: 41b4c190 Author: Xin Liu URL: https://git.openjdk.java.net/jdk/commit/41b4c19086c0b238bdeea9f3f14ee9997253b2f2 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8271353: PerfDataManager::destroy crashes in VM_Exit Reviewed-by: dholmes, stuefe, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/4913 From xliu at openjdk.java.net Wed Jul 28 23:10:30 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 28 Jul 2021 23:10:30 GMT Subject: RFR: 8271353: PerfDataManager::destroy crashes in VM_Exit [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jul 2021 17:44:57 GMT, Xin Liu wrote: >> This patch check PerfDataManager::_sampled and _constants is NULL. if it is, >> return -1. >> >> When the user enables UL `-Xlog:perf+datacreation=debug`, it may crash in >> PerfDataManager::destroy(). The following line will crash when _sampled is NULL. >> >> >> log_debug(perf, datacreation)("Total = %d, Sampled = %d, Constants = %d", >> _all->length(), _sampled->length(), _constants->length()); >> >> >> This only happens when UsePerfData is on and PerfDataManager::destroy() is invoked before >> StatSampler::initialize() which initializes PerfDataManager::_sampled. >> PerfDataManager::destroy() is called by VM_Exit which can be triggered by SIGINT on Linux anytime. >> >> A reproducible: invoke the following command and keep pressing Ctrl-c. >> $perf stat -r 100 java -Xlog:perf+datacreation=debug --version > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Print 0 instead of -1 when _sampled or _constants is not avaiable. > > also update copyright year. I have a same thought at first, but 0 isn't normal state. We can use 0 for N/A. ------------- PR: https://git.openjdk.java.net/jdk/pull/4913 From iignatyev at openjdk.java.net Wed Jul 28 23:14:31 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 28 Jul 2021 23:14:31 GMT Subject: [jdk17] Integrated: 8271402: mark hotspot runtime/os tests which ignore external VM flags In-Reply-To: <1tjisbUzo3fdrj7ZT1OtaE5dc4iUqUUHkXfGgdicVPE=.e2017b2d-72e6-4d1b-86d9-ca9a3359720e@github.com> References: <1tjisbUzo3fdrj7ZT1OtaE5dc4iUqUUHkXfGgdicVPE=.e2017b2d-72e6-4d1b-86d9-ca9a3359720e@github.com> Message-ID: On Wed, 28 Jul 2021 15:52:31 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch? > > Thanks, > -- Igor This pull request has now been integrated. Changeset: e593e3de Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk17/commit/e593e3de4c171e359a1142333087af72593d234d Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod 8271402: mark hotspot runtime/os tests which ignore external VM flags Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk17/pull/288 From iignatyev at openjdk.java.net Wed Jul 28 23:14:30 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 28 Jul 2021 23:14:30 GMT Subject: [jdk17] RFR: 8271402: mark hotspot runtime/os tests which ignore external VM flags In-Reply-To: <1tjisbUzo3fdrj7ZT1OtaE5dc4iUqUUHkXfGgdicVPE=.e2017b2d-72e6-4d1b-86d9-ca9a3359720e@github.com> References: <1tjisbUzo3fdrj7ZT1OtaE5dc4iUqUUHkXfGgdicVPE=.e2017b2d-72e6-4d1b-86d9-ca9a3359720e@github.com> Message-ID: On Wed, 28 Jul 2021 15:52:31 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch? > > Thanks, > -- Igor Thanks, David. ------------- PR: https://git.openjdk.java.net/jdk17/pull/288 From iignatyev at openjdk.java.net Wed Jul 28 23:16:35 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 28 Jul 2021 23:16:35 GMT Subject: [jdk17] RFR: 8271403: mark hotspot runtime/memory tests which ignore external VM flags In-Reply-To: References: Message-ID: On Wed, 28 Jul 2021 15:55:45 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch? > > Thanks, > -- Igor Thanks, David. ------------- PR: https://git.openjdk.java.net/jdk17/pull/289 From iignatyev at openjdk.java.net Wed Jul 28 23:16:36 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 28 Jul 2021 23:16:36 GMT Subject: [jdk17] Integrated: 8271403: mark hotspot runtime/memory tests which ignore external VM flags In-Reply-To: References: Message-ID: <3VUfgi1D8HBpHMWfaUTWdSHDjibPqIBESYAJB_jZXfg=.4e893968-7268-40e0-aa20-d42c4cceab34@github.com> On Wed, 28 Jul 2021 15:55:45 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch? > > Thanks, > -- Igor This pull request has now been integrated. Changeset: 20d2dc1f Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk17/commit/20d2dc1f3524ff76fb7e9f7a4979bedb938a13fc Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod 8271403: mark hotspot runtime/memory tests which ignore external VM flags Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk17/pull/289 From cgo at openjdk.java.net Thu Jul 29 09:48:45 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Thu, 29 Jul 2021 09:48:45 GMT Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM Message-ID: Hi, please review this patch, which adds support for InlineIntrinsics to the 32-bit ARM port. The old aarch32 port had this intrinsic implemented and enabled by default. Like on many other platforms, the 32-bit ARM port simply calls into the `SharedRuntime` to intrinsify the basic `java.lang.Math` methods. InlineIntrinsics is already implemented for C1 on 32-bit ARM, which does the same thing. testing: hotspot tier1 on ARMv5TE (soft-float) and ARMv7-A (hard-float) There is already the micro benchmark `test/micro/org/openjdk/bench/java/lang/MathBench.java` which I used. The soft-float benchmarks are not that meaningful, since I performed them in QEMU. __hard-float__ `-Xint -XX:+InlineIntrinsics` | Benchmark | (seed) | Mode | Cnt | Score | Error | Units | | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: | | MathBench.absDouble | 0 | thrpt | 5 | 1169.574 | +/- 133.694 | ops/ms | | MathBench.cosDouble | 0 | thrpt | 5 | 759.902 | +/- 573.852 | ops/ms | | MathBench.expDouble | 0 | thrpt | 5 | 854.753 | +/- 67.217 | ops/ms | | MathBench.log10Double | 0 | thrpt | 5 | 902.034 | +/- 22.413 | ops/ms | | MathBench.logDouble | 0 | thrpt | 5 | 895.470 | +/- 113.811 | ops/ms | | MathBench.powDouble | 0 | thrpt | 5 | 936.136 | +/- 40.661 | ops/ms | | MathBench.sinDouble | 0 | thrpt | 5 | 864.670 | +/- 68.329 | ops/ms | | MathBench.sqrtDouble | 0 | thrpt | 5 | 1082.589 | +/- 92.570 | ops/ms | | MathBench.tanDouble | 0 | thrpt | 5 | 853.715 | +/- 122.427 | ops/ms | __hard-float__ `-Xint -XX:-InlineIntrinsics` | Benchmark | (seed) | Mode | Cnt | Score | Error | Units | | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: | | MathBench.absDouble | 0 | thrpt | 5 | 450.907 | +/- 10.402 | ops/ms | | MathBench.cosDouble | 0 | thrpt | 5 | 592.242 | +/- 14.011 | ops/ms | | MathBench.expDouble | 0 | thrpt | 5 | 167.614 | +/- 7.530 | ops/ms | | MathBench.log10Double | 0 | thrpt | 5 | 572.099 | +/- 55.089 | ops/ms | | MathBench.logDouble | 0 | thrpt | 5 | 596.588 | +/- 24.976 | ops/ms | | MathBench.powDouble | 0 | thrpt | 5 | 212.673 | +/- 4.060 | ops/ms | | MathBench.sinDouble | 0 | thrpt | 5 | 584.873 | +/- 42.774 | ops/ms | | MathBench.sqrtDouble | 0 | thrpt | 5 | 514.690 | +/- 30.568 | ops/ms | | MathBench.tanDouble | 0 | thrpt | 5 | 566.586 | +/- 23.995 | ops/ms | __soft-float__ `-Xint -XX:+InlineIntrinsics` | Benchmark | (seed) | Mode | Cnt | Score | Error | Units | | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: | | MathBench.absDouble | 0 | thrpt | 5 | 279.575 | +/- 56.455 | ops/ms | | MathBench.cosDouble | 0 | thrpt | 5 | 137.005 | +/- 72.561 | ops/ms | | MathBench.expDouble | 0 | thrpt | 5 | 117.778 | +/- 30.186 | ops/ms | | MathBench.log10Double | 0 | thrpt | 5 | 107.957 | +/- 10.158 | ops/ms | | MathBench.logDouble | 0 | thrpt | 5 | 101.341 | +/- 3.914 | ops/ms | | MathBench.powDouble | 0 | thrpt | 5 | 222.220 | +/- 3.854 | ops/ms | | MathBench.sinDouble | 0 | thrpt | 5 | 112.715 | +/- 9.088 | ops/ms | | MathBench.sqrtDouble | 0 | thrpt | 5 | 119.341 | +/- 76.528 | ops/ms | | MathBench.tanDouble | 0 | thrpt | 5 | 105.224 | +/- 30.477 | ops/ms | __soft-float__ `-Xint -XX:-InlineIntrinsics` | Benchmark | (seed) | Mode | Cnt | Score | Error | Units | | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: | | MathBench.absDouble | 0 | thrpt | 5 | 173.150 | +/- 36.279 | ops/ms | | MathBench.cosDouble | 0 | thrpt | 5 | 129.774 | +/- 8.795 | ops/ms | | MathBench.expDouble | 0 | thrpt | 5 | 53.524 | +/- 1.679 | ops/ms | | MathBench.log10Double | 0 | thrpt | 5 | 132.503 | +/- 4.274 | ops/ms | | MathBench.logDouble | 0 | thrpt | 5 | 135.483 | +/- 1.150 | ops/ms | | MathBench.powDouble | 0 | thrpt | 5 | 54.266 | +/- 0.699 | ops/ms | | MathBench.sinDouble | 0 | thrpt | 5 | 105.636 | +/- 4.647 | ops/ms | | MathBench.sqrtDouble | 0 | thrpt | 5 | 204.550 | +/- 7.206 | ops/ms | | MathBench.tanDouble | 0 | thrpt | 5 | 101.072 | +/- 3.701 | ops/ms | ------------- Commit messages: - 8271128: InlineIntrinsics support for 32-bit ARM Changes: https://git.openjdk.java.net/jdk/pull/4927/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4927&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271128 Stats: 111 lines in 4 files changed: 104 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4927.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4927/head:pull/4927 PR: https://git.openjdk.java.net/jdk/pull/4927 From shade at openjdk.java.net Thu Jul 29 10:08:31 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 29 Jul 2021 10:08:31 GMT Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM In-Reply-To: References: Message-ID: On Thu, 29 Jul 2021 09:40:08 GMT, Christoph G?ttschkes wrote: > Hi, > > please review this patch, which adds support for InlineIntrinsics to the 32-bit ARM port. The old aarch32 port had this intrinsic implemented and enabled by default. > > Like on many other platforms, the 32-bit ARM port simply calls into the `SharedRuntime` to intrinsify the basic `java.lang.Math` methods. InlineIntrinsics is already implemented for C1 on 32-bit ARM, which does the same thing. > > testing: hotspot tier1 on ARMv5TE (soft-float) and ARMv7-A (hard-float) > > There is already the micro benchmark `test/micro/org/openjdk/bench/java/lang/MathBench.java` which I used. The soft-float benchmarks are not that meaningful, since I performed them in QEMU. > > __hard-float__ `-Xint -XX:+InlineIntrinsics` > > | Benchmark | (seed) | Mode | Cnt | Score | Error | Units | > | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: | > | MathBench.absDouble | 0 | thrpt | 5 | 1169.574 | +/- 133.694 | ops/ms | > | MathBench.cosDouble | 0 | thrpt | 5 | 759.902 | +/- 573.852 | ops/ms | > | MathBench.expDouble | 0 | thrpt | 5 | 854.753 | +/- 67.217 | ops/ms | > | MathBench.log10Double | 0 | thrpt | 5 | 902.034 | +/- 22.413 | ops/ms | > | MathBench.logDouble | 0 | thrpt | 5 | 895.470 | +/- 113.811 | ops/ms | > | MathBench.powDouble | 0 | thrpt | 5 | 936.136 | +/- 40.661 | ops/ms | > | MathBench.sinDouble | 0 | thrpt | 5 | 864.670 | +/- 68.329 | ops/ms | > | MathBench.sqrtDouble | 0 | thrpt | 5 | 1082.589 | +/- 92.570 | ops/ms | > | MathBench.tanDouble | 0 | thrpt | 5 | 853.715 | +/- 122.427 | ops/ms | > > __hard-float__ `-Xint -XX:-InlineIntrinsics` > > | Benchmark | (seed) | Mode | Cnt | Score | Error | Units | > | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: | > | MathBench.absDouble | 0 | thrpt | 5 | 450.907 | +/- 10.402 | ops/ms | > | MathBench.cosDouble | 0 | thrpt | 5 | 592.242 | +/- 14.011 | ops/ms | > | MathBench.expDouble | 0 | thrpt | 5 | 167.614 | +/- 7.530 | ops/ms | > | MathBench.log10Double | 0 | thrpt | 5 | 572.099 | +/- 55.089 | ops/ms | > | MathBench.logDouble | 0 | thrpt | 5 | 596.588 | +/- 24.976 | ops/ms | > | MathBench.powDouble | 0 | thrpt | 5 | 212.673 | +/- 4.060 | ops/ms | > | MathBench.sinDouble | 0 | thrpt | 5 | 584.873 | +/- 42.774 | ops/ms | > | MathBench.sqrtDouble | 0 | thrpt | 5 | 514.690 | +/- 30.568 | ops/ms | > | MathBench.tanDouble | 0 | thrpt | 5 | 566.586 | +/- 23.995 | ops/ms | > > __soft-float__ `-Xint -XX:+InlineIntrinsics` > > | Benchmark | (seed) | Mode | Cnt | Score | Error | Units | > | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: | > | MathBench.absDouble | 0 | thrpt | 5 | 279.575 | +/- 56.455 | ops/ms | > | MathBench.cosDouble | 0 | thrpt | 5 | 137.005 | +/- 72.561 | ops/ms | > | MathBench.expDouble | 0 | thrpt | 5 | 117.778 | +/- 30.186 | ops/ms | > | MathBench.log10Double | 0 | thrpt | 5 | 107.957 | +/- 10.158 | ops/ms | > | MathBench.logDouble | 0 | thrpt | 5 | 101.341 | +/- 3.914 | ops/ms | > | MathBench.powDouble | 0 | thrpt | 5 | 222.220 | +/- 3.854 | ops/ms | > | MathBench.sinDouble | 0 | thrpt | 5 | 112.715 | +/- 9.088 | ops/ms | > | MathBench.sqrtDouble | 0 | thrpt | 5 | 119.341 | +/- 76.528 | ops/ms | > | MathBench.tanDouble | 0 | thrpt | 5 | 105.224 | +/- 30.477 | ops/ms | > > __soft-float__ `-Xint -XX:-InlineIntrinsics` > > | Benchmark | (seed) | Mode | Cnt | Score | Error | Units | > | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: | > | MathBench.absDouble | 0 | thrpt | 5 | 173.150 | +/- 36.279 | ops/ms | > | MathBench.cosDouble | 0 | thrpt | 5 | 129.774 | +/- 8.795 | ops/ms | > | MathBench.expDouble | 0 | thrpt | 5 | 53.524 | +/- 1.679 | ops/ms | > | MathBench.log10Double | 0 | thrpt | 5 | 132.503 | +/- 4.274 | ops/ms | > | MathBench.logDouble | 0 | thrpt | 5 | 135.483 | +/- 1.150 | ops/ms | > | MathBench.powDouble | 0 | thrpt | 5 | 54.266 | +/- 0.699 | ops/ms | > | MathBench.sinDouble | 0 | thrpt | 5 | 105.636 | +/- 4.647 | ops/ms | > | MathBench.sqrtDouble | 0 | thrpt | 5 | 204.550 | +/- 7.206 | ops/ms | > | MathBench.tanDouble | 0 | thrpt | 5 | 101.072 | +/- 3.701 | ops/ms | This looks okay to me, but I think `hotspot-tier1` testing is inadequate for this. Please run at least full `tier1`, which should include JDK tests for `java.lang.Math`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4927 From cgo at openjdk.java.net Thu Jul 29 12:01:29 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Thu, 29 Jul 2021 12:01:29 GMT Subject: RFR: 8271128: InlineIntrinsics support for 32-bit ARM In-Reply-To: References: Message-ID: On Thu, 29 Jul 2021 09:40:08 GMT, Christoph G?ttschkes wrote: > Hi, > > please review this patch, which adds support for InlineIntrinsics to the 32-bit ARM port. The old aarch32 port had this intrinsic implemented and enabled by default. > > Like on many other platforms, the 32-bit ARM port simply calls into the `SharedRuntime` to intrinsify the basic `java.lang.Math` methods. InlineIntrinsics is already implemented for C1 on 32-bit ARM, which does the same thing. > > testing: hotspot tier1 on ARMv5TE (soft-float) and ARMv7-A (hard-float) > > There is already the micro benchmark `test/micro/org/openjdk/bench/java/lang/MathBench.java` which I used. The soft-float benchmarks are not that meaningful, since I performed them in QEMU. > > __hard-float__ `-Xint -XX:+InlineIntrinsics` > > | Benchmark | (seed) | Mode | Cnt | Score | Error | Units | > | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: | > | MathBench.absDouble | 0 | thrpt | 5 | 1169.574 | +/- 133.694 | ops/ms | > | MathBench.cosDouble | 0 | thrpt | 5 | 759.902 | +/- 573.852 | ops/ms | > | MathBench.expDouble | 0 | thrpt | 5 | 854.753 | +/- 67.217 | ops/ms | > | MathBench.log10Double | 0 | thrpt | 5 | 902.034 | +/- 22.413 | ops/ms | > | MathBench.logDouble | 0 | thrpt | 5 | 895.470 | +/- 113.811 | ops/ms | > | MathBench.powDouble | 0 | thrpt | 5 | 936.136 | +/- 40.661 | ops/ms | > | MathBench.sinDouble | 0 | thrpt | 5 | 864.670 | +/- 68.329 | ops/ms | > | MathBench.sqrtDouble | 0 | thrpt | 5 | 1082.589 | +/- 92.570 | ops/ms | > | MathBench.tanDouble | 0 | thrpt | 5 | 853.715 | +/- 122.427 | ops/ms | > > __hard-float__ `-Xint -XX:-InlineIntrinsics` > > | Benchmark | (seed) | Mode | Cnt | Score | Error | Units | > | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: | > | MathBench.absDouble | 0 | thrpt | 5 | 450.907 | +/- 10.402 | ops/ms | > | MathBench.cosDouble | 0 | thrpt | 5 | 592.242 | +/- 14.011 | ops/ms | > | MathBench.expDouble | 0 | thrpt | 5 | 167.614 | +/- 7.530 | ops/ms | > | MathBench.log10Double | 0 | thrpt | 5 | 572.099 | +/- 55.089 | ops/ms | > | MathBench.logDouble | 0 | thrpt | 5 | 596.588 | +/- 24.976 | ops/ms | > | MathBench.powDouble | 0 | thrpt | 5 | 212.673 | +/- 4.060 | ops/ms | > | MathBench.sinDouble | 0 | thrpt | 5 | 584.873 | +/- 42.774 | ops/ms | > | MathBench.sqrtDouble | 0 | thrpt | 5 | 514.690 | +/- 30.568 | ops/ms | > | MathBench.tanDouble | 0 | thrpt | 5 | 566.586 | +/- 23.995 | ops/ms | > > __soft-float__ `-Xint -XX:+InlineIntrinsics` > > | Benchmark | (seed) | Mode | Cnt | Score | Error | Units | > | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: | > | MathBench.absDouble | 0 | thrpt | 5 | 279.575 | +/- 56.455 | ops/ms | > | MathBench.cosDouble | 0 | thrpt | 5 | 137.005 | +/- 72.561 | ops/ms | > | MathBench.expDouble | 0 | thrpt | 5 | 117.778 | +/- 30.186 | ops/ms | > | MathBench.log10Double | 0 | thrpt | 5 | 107.957 | +/- 10.158 | ops/ms | > | MathBench.logDouble | 0 | thrpt | 5 | 101.341 | +/- 3.914 | ops/ms | > | MathBench.powDouble | 0 | thrpt | 5 | 222.220 | +/- 3.854 | ops/ms | > | MathBench.sinDouble | 0 | thrpt | 5 | 112.715 | +/- 9.088 | ops/ms | > | MathBench.sqrtDouble | 0 | thrpt | 5 | 119.341 | +/- 76.528 | ops/ms | > | MathBench.tanDouble | 0 | thrpt | 5 | 105.224 | +/- 30.477 | ops/ms | > > __soft-float__ `-Xint -XX:-InlineIntrinsics` > > | Benchmark | (seed) | Mode | Cnt | Score | Error | Units | > | :---------------------------- | -----: | ----: | --: | -------: | ----------: | -----: | > | MathBench.absDouble | 0 | thrpt | 5 | 173.150 | +/- 36.279 | ops/ms | > | MathBench.cosDouble | 0 | thrpt | 5 | 129.774 | +/- 8.795 | ops/ms | > | MathBench.expDouble | 0 | thrpt | 5 | 53.524 | +/- 1.679 | ops/ms | > | MathBench.log10Double | 0 | thrpt | 5 | 132.503 | +/- 4.274 | ops/ms | > | MathBench.logDouble | 0 | thrpt | 5 | 135.483 | +/- 1.150 | ops/ms | > | MathBench.powDouble | 0 | thrpt | 5 | 54.266 | +/- 0.699 | ops/ms | > | MathBench.sinDouble | 0 | thrpt | 5 | 105.636 | +/- 4.647 | ops/ms | > | MathBench.sqrtDouble | 0 | thrpt | 5 | 204.550 | +/- 7.206 | ops/ms | > | MathBench.tanDouble | 0 | thrpt | 5 | 101.072 | +/- 3.701 | ops/ms | Sorry, I forgot to mention this. I tested the java.lang.Math methods for which the new intrinsics are implemented manually, by comparing the results of the intrinsics with the results of the corresponding java.lang.StrictMath method. Since both, StrictMath and the intrinsics use the same algorithm on 32-bit ARM, it is possible to do that. But I agree, doing some more testing doesn't hurt. I will start jdk tier1 as well and will report back as soon as they are done, will definitely take some time though. ------------- PR: https://git.openjdk.java.net/jdk/pull/4927 From dcubed at openjdk.java.net Thu Jul 29 19:50:00 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 29 Jul 2021 19:50:00 GMT Subject: RFR: 8249004: Reduce ThreadListHandle overhead in relation to direct handshakes [v2] In-Reply-To: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: > A trivial fix to reduce ThreadListHandle overhead in relation to handshakes. > > This refactoring was tested with Mach5 Tier[1-3]. Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into JDK-8249004 - 8249004: Reduce ThreadListHandle overhead in relation to direct handshakes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4677/files - new: https://git.openjdk.java.net/jdk/pull/4677/files/8162b22f..bc82cfa6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=00-01 Stats: 38422 lines in 1014 files changed: 17121 ins; 15900 del; 5401 mod Patch: https://git.openjdk.java.net/jdk/pull/4677.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4677/head:pull/4677 PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Thu Jul 29 19:50:09 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 29 Jul 2021 19:50:09 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v3] In-Reply-To: References: Message-ID: <2ppfp1xwNDM6FMqH0iZLYbixIhiHSH0EmxvAXQTbVLo=.8cac62e7-84f5-459d-9ea3-3d28cffc985a@github.com> > This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." > Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this > piece of history that I'm finally getting around to cleaning up. While this macro has > been with us for a long time, its time has passed... > > Tested with Mach5 Tier[1-3]. Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8193559 - kbarrett CR - delete unused _list member. - 8193559.cr0 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4671/files - new: https://git.openjdk.java.net/jdk/pull/4671/files/5ee49914..a133ca42 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4671&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4671&range=01-02 Stats: 39768 lines in 1046 files changed: 18045 ins; 16146 del; 5577 mod Patch: https://git.openjdk.java.net/jdk/pull/4671.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4671/head:pull/4671 PR: https://git.openjdk.java.net/jdk/pull/4671 From dcubed at openjdk.java.net Thu Jul 29 20:35:45 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 29 Jul 2021 20:35:45 GMT Subject: RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes Message-ID: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> A trivial follow-up to: JDK-8271251 JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" that adds a stronger sanity check of thread state when polling for safepoint/handshakes. This fix was used to test @pchilano's fix for JDK-8271251 in my JDK17 Mach5 Tier[1-8] runs for JDK-8271251. It has also been tested with Mach5 Tier[1-3] for jdk/jdk (JDK18). ------------- Commit messages: - 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes Changes: https://git.openjdk.java.net/jdk/pull/4936/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4936&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271348 Stats: 48 lines in 3 files changed: 20 ins; 16 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/4936.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4936/head:pull/4936 PR: https://git.openjdk.java.net/jdk/pull/4936 From dcubed at openjdk.java.net Thu Jul 29 20:46:30 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 29 Jul 2021 20:46:30 GMT Subject: RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes In-Reply-To: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> References: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> Message-ID: On Thu, 29 Jul 2021 20:29:27 GMT, Daniel D. Daugherty wrote: > A trivial follow-up to: > > JDK-8271251 JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" > > that adds a stronger sanity check of thread state when polling for safepoint/handshakes. > > This fix was used to test @pchilano's fix for JDK-8271251 in my JDK17 Mach5 > Tier[1-8] runs for JDK-8271251. It has also been tested with Mach5 Tier[1-3] > for jdk/jdk (JDK18). Just to be clear: While I tested this fix with JDK17 bits, this fix is targeted to jdk/jdk (JDK18). ------------- PR: https://git.openjdk.java.net/jdk/pull/4936 From dholmes at openjdk.java.net Thu Jul 29 22:21:31 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 29 Jul 2021 22:21:31 GMT Subject: RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes In-Reply-To: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> References: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> Message-ID: On Thu, 29 Jul 2021 20:29:27 GMT, Daniel D. Daugherty wrote: > A trivial follow-up to: > > JDK-8271251 JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" > > that adds a stronger sanity check of thread state when polling for safepoint/handshakes. > > This fix was used to test @pchilano's fix for JDK-8271251 in my JDK17 Mach5 > Tier[1-8] runs for JDK-8271251. It has also been tested with Mach5 Tier[1-3] > for jdk/jdk (JDK18). Hi Dan, Not sure about part of this - see below. Thanks, David src/hotspot/share/runtime/safepoint.cpp line 708: > 706: > 707: JavaThreadState state = thread->thread_state(); > 708: assert(SafepointSynchronize::is_a_block_safe_state(state), "Illegal threadstate encountered: %d", state); Nit: you shouldn't need to say SafepointSynchronize:: here. src/hotspot/share/runtime/safepoint.cpp line 716: > 714: // So we can miss this poll, but stop at next. > 715: > 716: // Load dependent store, it must not pass loading of safepoint_id. Existing: I struggle to understand what this comment means - we are storing the value of safepoint_id so I don't see how the loading of safepoint_id can be reordered. ??? src/hotspot/share/runtime/safepointMechanism.cpp line 122: > 120: do { > 121: JavaThreadState state = thread->thread_state(); > 122: guarantee(SafepointSynchronize::is_a_block_safe_state(state), "Illegal threadstate encountered: %d", state); Shouldn't this be outside the loop? Though we are doubling up given the assert in block(). Do we really want guarantee rather than assert? Doesn't a failure here indicate an internal programming error? ------------- PR: https://git.openjdk.java.net/jdk/pull/4936 From dcubed at openjdk.java.net Thu Jul 29 23:56:30 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 29 Jul 2021 23:56:30 GMT Subject: RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes In-Reply-To: References: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> Message-ID: On Thu, 29 Jul 2021 22:04:56 GMT, David Holmes wrote: >> A trivial follow-up to: >> >> JDK-8271251 JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" >> >> that adds a stronger sanity check of thread state when polling for safepoint/handshakes. >> >> This fix was used to test @pchilano's fix for JDK-8271251 in my JDK17 Mach5 >> Tier[1-8] runs for JDK-8271251. It has also been tested with Mach5 Tier[1-3] >> for jdk/jdk (JDK18). > > src/hotspot/share/runtime/safepoint.cpp line 708: > >> 706: >> 707: JavaThreadState state = thread->thread_state(); >> 708: assert(SafepointSynchronize::is_a_block_safe_state(state), "Illegal threadstate encountered: %d", state); > > Nit: you shouldn't need to say SafepointSynchronize:: here. Agreed. Will fix it. > src/hotspot/share/runtime/safepoint.cpp line 716: > >> 714: // So we can miss this poll, but stop at next. >> 715: >> 716: // Load dependent store, it must not pass loading of safepoint_id. > > Existing: I struggle to understand what this comment means - we are storing the value of safepoint_id so I don't see how the loading of safepoint_id can be reordered. ??? I'll have to check to see who added that comment. > src/hotspot/share/runtime/safepointMechanism.cpp line 122: > >> 120: do { >> 121: JavaThreadState state = thread->thread_state(); >> 122: guarantee(SafepointSynchronize::is_a_block_safe_state(state), "Illegal threadstate encountered: %d", state); > > Shouldn't this be outside the loop? Though we are doubling up given the assert in block(). > Do we really want guarantee rather than assert? Doesn't a failure here indicate an internal programming error? I think the thread's state can change during this loop so having the check in the loop will catch if it changes to something bad. The assert() in `block()` is to catch any future new callers to `block()` that aren't calling from the right thread_state. Yes, I specifically wanted a `guarantee()` here to catch this condition in 'release' bits. The original internal programming bug was racy and I want to make sure we have the best chance to catch any future racy uses. ------------- PR: https://git.openjdk.java.net/jdk/pull/4936 From dcubed at openjdk.java.net Fri Jul 30 00:00:57 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Jul 2021 00:00:57 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2] In-Reply-To: <0yNOkRrweFvaVauhMHJz8RVSKurahOukCJ9VKQReuZw=.4309a359-d1de-4979-88d2-f49a4075a03c@github.com> References: <0yNOkRrweFvaVauhMHJz8RVSKurahOukCJ9VKQReuZw=.4309a359-d1de-4979-88d2-f49a4075a03c@github.com> Message-ID: On Sun, 4 Jul 2021 22:29:42 GMT, Kim Barrett wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> kbarrett CR - delete unused _list member. > > Changes requested by kbarrett (Reviewer). I've updated the fix with @kimbarrett's rewrite that uses newer C++ features. I've tested this version with Mach5 Tier[1-3]. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From dcubed at openjdk.java.net Fri Jul 30 00:00:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Jul 2021 00:00:56 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4] In-Reply-To: References: Message-ID: > This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." > Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this > piece of history that I'm finally getting around to cleaning up. While this macro has > been with us for a long time, its time has passed... > > Tested with Mach5 Tier[1-3]. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: 8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4671/files - new: https://git.openjdk.java.net/jdk/pull/4671/files/a133ca42..3be5dc72 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4671&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4671&range=02-03 Stats: 142 lines in 4 files changed: 109 ins; 30 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4671.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4671/head:pull/4671 PR: https://git.openjdk.java.net/jdk/pull/4671 From dcubed at openjdk.java.net Fri Jul 30 00:08:55 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Jul 2021 00:08:55 GMT Subject: RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes [v2] In-Reply-To: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> References: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> Message-ID: > A trivial follow-up to: > > JDK-8271251 JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" > > that adds a stronger sanity check of thread state when polling for safepoint/handshakes. > > This fix was used to test @pchilano's fix for JDK-8271251 in my JDK17 Mach5 > Tier[1-8] runs for JDK-8271251. It has also been tested with Mach5 Tier[1-3] > for jdk/jdk (JDK18). Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: dholmes CR ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4936/files - new: https://git.openjdk.java.net/jdk/pull/4936/files/15167b4f..2e748859 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4936&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4936&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4936.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4936/head:pull/4936 PR: https://git.openjdk.java.net/jdk/pull/4936 From dcubed at openjdk.java.net Fri Jul 30 00:08:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Jul 2021 00:08:56 GMT Subject: RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes [v2] In-Reply-To: References: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> Message-ID: On Thu, 29 Jul 2021 23:42:33 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/safepoint.cpp line 716: >> >>> 714: // So we can miss this poll, but stop at next. >>> 715: >>> 716: // Load dependent store, it must not pass loading of safepoint_id. >> >> Existing: I struggle to understand what this comment means - we are storing the value of safepoint_id so I don't see how the loading of safepoint_id can be reordered. ??? > > I'll have to check to see who added that comment. It was added here: commit bec8431683a36ad552a15cd7c4d5ca48058249a7 Author: Robbin Ehn Date: Fri Feb 15 14:15:10 2019 +0100 8203469: Faster safepoints Reviewed-by: dcubed, pchilanomate, dholmes, acorn, coleenp, eosterlund ------------- PR: https://git.openjdk.java.net/jdk/pull/4936 From dcubed at openjdk.java.net Fri Jul 30 00:08:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Jul 2021 00:08:56 GMT Subject: RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes [v2] In-Reply-To: References: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> Message-ID: On Fri, 30 Jul 2021 00:02:30 GMT, Daniel D. Daugherty wrote: >> I'll have to check to see who added that comment. > > It was added here: > > commit bec8431683a36ad552a15cd7c4d5ca48058249a7 > Author: Robbin Ehn > Date: Fri Feb 15 14:15:10 2019 +0100 > > 8203469: Faster safepoints > > Reviewed-by: dcubed, pchilanomate, dholmes, acorn, coleenp, eosterlund Here's the code block: uint64_t safepoint_id = SafepointSynchronize::safepoint_counter(); // Check that we have a valid thread_state at this point switch(state) { case _thread_in_vm_trans: case _thread_in_Java: // From compiled code case _thread_in_native_trans: case _thread_blocked_trans: case _thread_new_trans: // We have no idea where the VMThread is, it might even be at next safepoint. // So we can miss this poll, but stop at next. // Load dependent store, it must not pass loading of safepoint_id. thread->safepoint_state()->set_safepoint_id(safepoint_id); // Release store ------------- PR: https://git.openjdk.java.net/jdk/pull/4936 From dcubed at openjdk.java.net Fri Jul 30 00:15:31 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Jul 2021 00:15:31 GMT Subject: RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes [v2] In-Reply-To: References: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> Message-ID: <7wCYh5zLT0e5XgEx9cKnyVsMps1rwuqiJn_k1kp5Bw0=.41beacdf-037f-4719-a6bd-d53e7b8d1cf0@github.com> On Fri, 30 Jul 2021 00:02:46 GMT, Daniel D. Daugherty wrote: >> It was added here: >> >> commit bec8431683a36ad552a15cd7c4d5ca48058249a7 >> Author: Robbin Ehn >> Date: Fri Feb 15 14:15:10 2019 +0100 >> >> 8203469: Faster safepoints >> >> Reviewed-by: dcubed, pchilanomate, dholmes, acorn, coleenp, eosterlund > > Here's the code block: > > uint64_t safepoint_id = SafepointSynchronize::safepoint_counter(); > // Check that we have a valid thread_state at this point > switch(state) { > case _thread_in_vm_trans: > case _thread_in_Java: // From compiled code > case _thread_in_native_trans: > case _thread_blocked_trans: > case _thread_new_trans: > > // We have no idea where the VMThread is, it might even be at next safepoint. > // So we can miss this poll, but stop at next. > > // Load dependent store, it must not pass loading of safepoint_id. > thread->safepoint_state()->set_safepoint_id(safepoint_id); // Release store So I think @robehn was trying to separate these two lines of code: `uint64_t safepoint_id = SafepointSynchronize::safepoint_counter();` and `thread->safepoint_state()->set_safepoint_id(safepoint_id);` I think the same situation applies in the updated code, but it is harder to see in this GitHub view. Especially now that I've added all these comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/4936 From dholmes at openjdk.java.net Fri Jul 30 01:16:29 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Jul 2021 01:16:29 GMT Subject: RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes [v2] In-Reply-To: References: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> Message-ID: On Thu, 29 Jul 2021 23:52:50 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/safepointMechanism.cpp line 122: >> >>> 120: do { >>> 121: JavaThreadState state = thread->thread_state(); >>> 122: guarantee(SafepointSynchronize::is_a_block_safe_state(state), "Illegal threadstate encountered: %d", state); >> >> Shouldn't this be outside the loop? Though we are doubling up given the assert in block(). >> Do we really want guarantee rather than assert? Doesn't a failure here indicate an internal programming error? > > I think the thread's state can change during this loop so having the check in the > loop will catch if it changes to something bad. > > The assert() in `block()` is to catch any future new callers to `block()` that aren't > calling from the right thread_state. > > Yes, I specifically wanted a `guarantee()` here to catch this condition in 'release' bits. > The original internal programming bug was racy and I want to make sure we have the > best chance to catch any future racy uses. I would expect any state change to restore the original state before we get back into this loop. So this seems a little paranoid, but okay I guess. ------------- PR: https://git.openjdk.java.net/jdk/pull/4936 From dholmes at openjdk.java.net Fri Jul 30 01:16:28 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Jul 2021 01:16:28 GMT Subject: RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes [v2] In-Reply-To: <7wCYh5zLT0e5XgEx9cKnyVsMps1rwuqiJn_k1kp5Bw0=.41beacdf-037f-4719-a6bd-d53e7b8d1cf0@github.com> References: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> <7wCYh5zLT0e5XgEx9cKnyVsMps1rwuqiJn_k1kp5Bw0=.41beacdf-037f-4719-a6bd-d53e7b8d1cf0@github.com> Message-ID: On Fri, 30 Jul 2021 00:12:40 GMT, Daniel D. Daugherty wrote: >> Here's the code block: >> >> uint64_t safepoint_id = SafepointSynchronize::safepoint_counter(); >> // Check that we have a valid thread_state at this point >> switch(state) { >> case _thread_in_vm_trans: >> case _thread_in_Java: // From compiled code >> case _thread_in_native_trans: >> case _thread_blocked_trans: >> case _thread_new_trans: >> >> // We have no idea where the VMThread is, it might even be at next safepoint. >> // So we can miss this poll, but stop at next. >> >> // Load dependent store, it must not pass loading of safepoint_id. >> thread->safepoint_state()->set_safepoint_id(safepoint_id); // Release store > > So I think @robehn was trying to separate these two lines of code: > > `uint64_t safepoint_id = SafepointSynchronize::safepoint_counter();` > > and > > `thread->safepoint_state()->set_safepoint_id(safepoint_id);` > > I think the same situation applies in the updated code, but it is harder > to see in this GitHub view. Especially now that I've added all these > comments. Thanks and apologies for the digression. I'm assuming the intended required order is: - load safepoint counter into safepoint_id - load thread safepoint state - store safepoint_id into safepoint_state But the store is a release_store, so it is effectively preceded by a LoadStore|SoreStore barrier. So both loads must come before the store. The loads themselves could be reordered AFAICS but with no affect on correctness. So I remain unclear about the "load dependent store" comment actually relates to. Oh well, not a problem for this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4936 From dholmes at openjdk.java.net Fri Jul 30 01:26:30 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Jul 2021 01:26:30 GMT Subject: RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes [v2] In-Reply-To: References: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> Message-ID: On Fri, 30 Jul 2021 01:13:13 GMT, David Holmes wrote: >> I think the thread's state can change during this loop so having the check in the >> loop will catch if it changes to something bad. >> >> The assert() in `block()` is to catch any future new callers to `block()` that aren't >> calling from the right thread_state. >> >> Yes, I specifically wanted a `guarantee()` here to catch this condition in 'release' bits. >> The original internal programming bug was racy and I want to make sure we have the >> best chance to catch any future racy uses. > > I would expect any state change to restore the original state before we get back into this loop. So this seems a little paranoid, but okay I guess. No on further thought I'm not sure about this. If we take the path to SS::block() then this guarantee must hold. But what if we don't take that path? What if this is called due to a local poll and the thread is executing code that precludes the possibility of a global poll (e.g. holds Threads_lock) - what are the potential valid states in that case? ------------- PR: https://git.openjdk.java.net/jdk/pull/4936 From dholmes at openjdk.java.net Fri Jul 30 02:33:33 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Jul 2021 02:33:33 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4] In-Reply-To: References: Message-ID: <33PFDNQLa3IJPKDV3wX1en98eT72-ecZmnoqsKX7JsQ=.e96fb85e-9edf-4560-ab7f-0107b3a68a9d@github.com> On Fri, 30 Jul 2021 00:00:56 GMT, Daniel D. Daugherty wrote: >> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." >> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this >> piece of history that I'm finally getting around to cleaning up. While this macro has >> been with us for a long time, its time has passed... >> >> Tested with Mach5 Tier[1-3]. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > 8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features. Hi Dan, I can't comment on all the details of C++ Iterator definitions etc but these new foreach loops are definitely not ugly. :) Looks good! Thanks, David src/hotspot/share/runtime/threadSMR.cpp line 638: > 636: > 637: uint ThreadsList::Iterator::check_index(ThreadsList* list, uint i) { > 638: assert(i <= list->length(), "invalid index %u", i); Shouldn't that just be a '<' check? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4671 From dholmes at openjdk.java.net Fri Jul 30 03:50:38 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Jul 2021 03:50:38 GMT Subject: Withdrawn: 8267585: JavaThread::set_thread_state generally needs release semantics In-Reply-To: References: Message-ID: On Mon, 19 Jul 2021 11:57:43 GMT, David Holmes wrote: > Please review this small change to try and tidy up some of the memory ordering issues around the use of `JavaThread::set_thread_state()` and `JavaThread::thread_state()`. > > - Added: `release_set_thread_state()` and `thread_state_acquire()` > - Replaced use of storestore barrier before `set_thread_state()` with `release_set_thread_state()` > - Added missing release semantics in ` vm_perform_shutdown_actions()` > - Changed uses of `thread_state()` prior to checking `walkable()` to use acquire semantics, to match the release semantics used after `make_walkable()` > - Use Atomic load/store instead of plain accesses on `_thread_state` > - Removed unnecessary casts in the use of the Atomic and OrderAccess API's. > > This makes some of the semantics clearer and removes redundant barriers on PPC64 and Aarch64 in some cases. > > I question whether acquire/release semantics are needed by default on PPC64/Aarch64. I couldn't find any discussion related to that decision. But I can see that reasoning about when they are, and are not needed is quite difficult. So I didn't try to change that. > > Testing: > - tiers 1-4 builds (as sanity check for cast removal etc) > - GHA (in progress) > > Thanks, > David This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4825 From dholmes at openjdk.java.net Fri Jul 30 03:50:37 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Jul 2021 03:50:37 GMT Subject: RFR: 8267585: JavaThread::set_thread_state generally needs release semantics In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 09:17:11 GMT, Martin Doerr wrote: >> I don't agree with the assertion we didn't have clean platform independent code when PPC64 was introduced as justification here. We already had closed ports of ARM and PPC at that time and we had done a lot (ever since IA64 work years earlier) to make the shared code platform (and TSO) agnostic. Sure it wasn't/isn't perfect but I don't think you can use that as a justification here. I couldn't find anything that explained why PPC64 took the path it did (nor the discussion that forced the acquire/release to be restricted to PPC64 due to performance concerns on other platforms). The Aarch64 port at least tries to justify it, but I'd argue always using acquire/release semantics with thread-state was a sledgehammer approach to avoid actually identifying which interactions actually need what kind of memory barriers. > > I'm not happy with the sledgehammer, either, but better using a sledgehammer than having possibly incorrect code or an unstable VM IMHO. > No problems reported on some platforms doesn't mean that the code is correct. Do we know that not using release/acquire is correct for any platform? The aarch64 issue doesn't sound like that. > IA64 is not affected because volatile accesses always use release/acquire semantics. I believe that arm32 uses that, too. So, we already rely on release/acquire semantics. Shouldn't that better be explicit? The need for acquire/release semantics needs to be established for pairs of accesses. Simply using them "just in case" is not something I support and I certainly discourage it because it says "we don't understand our code so we're just throwing barriers in just in case". That said there seems no interest in this change so I will just close it out. Cheers, David ------------- PR: https://git.openjdk.java.net/jdk/pull/4825 From dholmes at openjdk.java.net Fri Jul 30 04:05:37 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Jul 2021 04:05:37 GMT Subject: RFR: 8269523: runtime/Safepoint/TestAbortOnVMOperationTimeout.java failed when expecting 'VM operation took too long' [v3] In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 07:12:52 GMT, David Holmes wrote: >> Please review this simple test adjustment: >> - dropped 5ms timeout as we have seen execution as low as 2ms >> - enabled GC logging >> - report output in all cases to allow ease of analysis >> >> Testing: ran 10x on macos/linux/Windows x64 and macos Aarch64 to check execution times and adjusted test accordingly >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fixed array initialization There are issues with this test given the granularity of the periodic task mechanism is 10ms - see JBS issue for discussion. But the fix as it stands seems sufficient to make the test more reliable for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/4901 From dholmes at openjdk.java.net Fri Jul 30 04:05:38 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Jul 2021 04:05:38 GMT Subject: Integrated: 8269523: runtime/Safepoint/TestAbortOnVMOperationTimeout.java failed when expecting 'VM operation took too long' In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 00:23:43 GMT, David Holmes wrote: > Please review this simple test adjustment: > - dropped 5ms timeout as we have seen execution as low as 2ms > - enabled GC logging > - report output in all cases to allow ease of analysis > > Testing: ran 10x on macos/linux/Windows x64 and macos Aarch64 to check execution times and adjusted test accordingly > > Thanks, > David This pull request has now been integrated. Changeset: 4f42eb66 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/4f42eb6601c3b6011d3c2b30af6b2be264ff7c0e Stats: 13 lines in 1 file changed: 7 ins; 1 del; 5 mod 8269523: runtime/Safepoint/TestAbortOnVMOperationTimeout.java failed when expecting 'VM operation took too long' Reviewed-by: shade, mseledtsov ------------- PR: https://git.openjdk.java.net/jdk/pull/4901 From kbarrett at openjdk.java.net Fri Jul 30 04:18:29 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 30 Jul 2021 04:18:29 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4] In-Reply-To: <33PFDNQLa3IJPKDV3wX1en98eT72-ecZmnoqsKX7JsQ=.e96fb85e-9edf-4560-ab7f-0107b3a68a9d@github.com> References: <33PFDNQLa3IJPKDV3wX1en98eT72-ecZmnoqsKX7JsQ=.e96fb85e-9edf-4560-ab7f-0107b3a68a9d@github.com> Message-ID: On Fri, 30 Jul 2021 01:54:54 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> 8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features. > > src/hotspot/share/runtime/threadSMR.cpp line 638: > >> 636: >> 637: uint ThreadsList::Iterator::check_index(ThreadsList* list, uint i) { >> 638: assert(i <= list->length(), "invalid index %u", i); > > Shouldn't that just be a '<' check? No, less-eq is correct. The index being checked here can be 1-past-the-last-element, for an end-iterator. Including 0 for an empty sequence. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From kbarrett at openjdk.java.net Fri Jul 30 04:28:28 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 30 Jul 2021 04:28:28 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4] In-Reply-To: References: Message-ID: On Fri, 30 Jul 2021 00:00:56 GMT, Daniel D. Daugherty wrote: >> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." >> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this >> piece of history that I'm finally getting around to cleaning up. While this macro has >> been with us for a long time, its time has passed... >> >> Tested with Mach5 Tier[1-3]. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > 8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features. src/hotspot/share/runtime/threadSMR.inline.hpp line 59: > 57: assert_not_singular(); > 58: assert_dereferenceable(); > 59: Prefetch::read(const_cast(_thread_ptr), PrefetchScanIntervalInBytes); This prefetch is included because the old code had it. But I'm dubious about it. This is just linear iteration through an array, which seems like the canonical best case for leaving it to the hardware, rather than doing cachelinesize/ptrsize software prefetches per cache line. I'm hoping the original authors can comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From kbarrett at openjdk.java.net Fri Jul 30 04:36:30 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 30 Jul 2021 04:36:30 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4] In-Reply-To: References: Message-ID: On Fri, 30 Jul 2021 00:00:56 GMT, Daniel D. Daugherty wrote: >> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." >> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this >> piece of history that I'm finally getting around to cleaning up. While this macro has >> been with us for a long time, its time has passed... >> >> Tested with Mach5 Tier[1-3]. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > 8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features. src/hotspot/share/runtime/threadSMR.inline.hpp line 53: > 51: assert_not_singular(); > 52: assert_same_list(i); > 53: return _thread_ptr != i._thread_ptr; Better might be to have the entire body consist of `return operator==(i);`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From dholmes at openjdk.java.net Fri Jul 30 05:52:29 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Jul 2021 05:52:29 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4] In-Reply-To: References: <33PFDNQLa3IJPKDV3wX1en98eT72-ecZmnoqsKX7JsQ=.e96fb85e-9edf-4560-ab7f-0107b3a68a9d@github.com> Message-ID: <4T0vmegiB5unIGg-ZfJVD_x64kXEMc7ZV4IIBqmLEw0=.82b46b5a-8dcc-4991-8931-dfdd4ac137be@github.com> On Fri, 30 Jul 2021 04:15:58 GMT, Kim Barrett wrote: >> src/hotspot/share/runtime/threadSMR.cpp line 638: >> >>> 636: >>> 637: uint ThreadsList::Iterator::check_index(ThreadsList* list, uint i) { >>> 638: assert(i <= list->length(), "invalid index %u", i); >> >> Shouldn't that just be a '<' check? > > No, less-eq is correct. The index being checked here can be 1-past-the-last-element, for an end-iterator. Including 0 for an empty sequence. Okay - thanks for explaining. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From mdoerr at openjdk.java.net Fri Jul 30 13:01:32 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 30 Jul 2021 13:01:32 GMT Subject: RFR: 8267585: JavaThread::set_thread_state generally needs release semantics In-Reply-To: References: Message-ID: On Mon, 19 Jul 2021 11:57:43 GMT, David Holmes wrote: > Please review this small change to try and tidy up some of the memory ordering issues around the use of `JavaThread::set_thread_state()` and `JavaThread::thread_state()`. > > - Added: `release_set_thread_state()` and `thread_state_acquire()` > - Replaced use of storestore barrier before `set_thread_state()` with `release_set_thread_state()` > - Added missing release semantics in ` vm_perform_shutdown_actions()` > - Changed uses of `thread_state()` prior to checking `walkable()` to use acquire semantics, to match the release semantics used after `make_walkable()` > - Use Atomic load/store instead of plain accesses on `_thread_state` > - Removed unnecessary casts in the use of the Atomic and OrderAccess API's. > > This makes some of the semantics clearer and removes redundant barriers on PPC64 and Aarch64 in some cases. > > I question whether acquire/release semantics are needed by default on PPC64/Aarch64. I couldn't find any discussion related to that decision. But I can see that reasoning about when they are, and are not needed is quite difficult. So I didn't try to change that. > > Testing: > - tiers 1-4 builds (as sanity check for cast removal etc) > - GHA (in progress) > > Thanks, > David Hi David, the proposed change was not bad. It would just be even better if we could get rid of the nasty platform difference IMHO. The release/acquire semantics are not there "just in case". There were real problems on PPC64 and aarch64. I still think that what we currently have is worse: If PPC64 or aarch64: use explicit release/acquire semantics for some not closer identified usages Other platforms: rely on implicit release/acquire semantics which are ensured by CPU or ABI convention ------------- PR: https://git.openjdk.java.net/jdk/pull/4825 From minqi at openjdk.java.net Fri Jul 30 15:39:51 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 30 Jul 2021 15:39:51 GMT Subject: RFR: 8271419: Refactor test code for modifying CDS archive contents Message-ID: The code for modifying CDS archive content could be used by other tests so the common code is refactored into a util class CDSArchiveUtils. Tests: tier1,tier4 Thanks Yumin ------------- Commit messages: - 8271419: Refactor test code for modifying CDS archive contents Changes: https://git.openjdk.java.net/jdk/pull/4945/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4945&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271419 Stats: 452 lines in 2 files changed: 229 ins; 174 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/4945.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4945/head:pull/4945 PR: https://git.openjdk.java.net/jdk/pull/4945 From dcubed at openjdk.java.net Fri Jul 30 16:11:32 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Jul 2021 16:11:32 GMT Subject: RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes [v2] In-Reply-To: References: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> <7wCYh5zLT0e5XgEx9cKnyVsMps1rwuqiJn_k1kp5Bw0=.41beacdf-037f-4719-a6bd-d53e7b8d1cf0@github.com> Message-ID: On Fri, 30 Jul 2021 01:10:03 GMT, David Holmes wrote: >> So I think @robehn was trying to separate these two lines of code: >> >> `uint64_t safepoint_id = SafepointSynchronize::safepoint_counter();` >> >> and >> >> `thread->safepoint_state()->set_safepoint_id(safepoint_id);` >> >> I think the same situation applies in the updated code, but it is harder >> to see in this GitHub view. Especially now that I've added all these >> comments. > > Thanks and apologies for the digression. I'm assuming the intended required order is: > - load safepoint counter into safepoint_id > - load thread safepoint state > - store safepoint_id into safepoint_state > > But the store is a release_store, so it is effectively preceded by a LoadStore|SoreStore barrier. So both loads must come before the store. The loads themselves could be reordered AFAICS but with no affect on correctness. So I remain unclear about the "load dependent store" comment actually relates to. > Oh well, not a problem for this PR. Okay so we're done with this one for this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4936 From dcubed at openjdk.java.net Fri Jul 30 16:14:29 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Jul 2021 16:14:29 GMT Subject: RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes [v2] In-Reply-To: References: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> Message-ID: On Fri, 30 Jul 2021 01:23:24 GMT, David Holmes wrote: >> I would expect any state change to restore the original state before we get back into this loop. So this seems a little paranoid, but okay I guess. > > No on further thought I'm not sure about this. If we take the path to SS::block() then this guarantee must hold. But what if we don't take that path? What if this is called due to a local poll and the thread is executing code that precludes the possibility of a global poll (e.g. holds Threads_lock) - what are the potential valid states in that case? Your last comment is exactly why I want this `guarantee()` here. If we run into that set of conditions I want us to crash and investigate what the heck is going on here. It's also the reason why @pchilano and I agreed that this change should be targeted to jdk/jdk (JDK18) instead of JDK17. We want time for this change to percolate in the system. While I've done a lot of Mach5 test runs for this change (plus the fix for JDK-8271251), there is no substitute for letting this change bake for a couple of months... ------------- PR: https://git.openjdk.java.net/jdk/pull/4936 From dcubed at openjdk.java.net Fri Jul 30 16:17:29 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Jul 2021 16:17:29 GMT Subject: RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes [v2] In-Reply-To: References: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> Message-ID: On Fri, 30 Jul 2021 00:08:55 GMT, Daniel D. Daugherty wrote: >> A trivial follow-up to: >> >> JDK-8271251 JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" >> >> that adds a stronger sanity check of thread state when polling for safepoint/handshakes. >> >> This fix was used to test @pchilano's fix for JDK-8271251 in my JDK17 Mach5 >> Tier[1-8] runs for JDK-8271251. It has also been tested with Mach5 Tier[1-3] >> for jdk/jdk (JDK18). > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > dholmes CR @pchilano - Since this is your version of the fix with one small change from me, it would be good if you could review here to make sure that I have the changes all correct in the jdk/jdk (JDK18) context. ------------- PR: https://git.openjdk.java.net/jdk/pull/4936 From dcubed at openjdk.java.net Fri Jul 30 16:23:31 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Jul 2021 16:23:31 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4] In-Reply-To: <33PFDNQLa3IJPKDV3wX1en98eT72-ecZmnoqsKX7JsQ=.e96fb85e-9edf-4560-ab7f-0107b3a68a9d@github.com> References: <33PFDNQLa3IJPKDV3wX1en98eT72-ecZmnoqsKX7JsQ=.e96fb85e-9edf-4560-ab7f-0107b3a68a9d@github.com> Message-ID: On Fri, 30 Jul 2021 02:30:50 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> 8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features. > > Hi Dan, > > I can't comment on all the details of C++ Iterator definitions etc but these new foreach loops are definitely not ugly. :) > > Looks good! > > Thanks, > David @dholmes-ora - Thanks for the re-review. @kimbarrett - Thanks for answering @dholmes-ora's query. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From dcubed at openjdk.java.net Fri Jul 30 16:29:34 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Jul 2021 16:29:34 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4] In-Reply-To: References: Message-ID: <7XZU2gwQFrzk4sl665oruDmYt_VuyJo8-yvacq3NOuw=.198345bb-ead7-499f-a01a-bb7f75675a38@github.com> On Fri, 30 Jul 2021 04:33:28 GMT, Kim Barrett wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> 8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features. > > src/hotspot/share/runtime/threadSMR.inline.hpp line 53: > >> 51: assert_not_singular(); >> 52: assert_same_list(i); >> 53: return _thread_ptr != i._thread_ptr; > > Better might be to have the entire body consist of `return operator==(i);`. I think what's there is more clear. If we switch to `return operator==(i)`, then I think that will lead to some head scratching. Especially since it's making me wonder right now... > src/hotspot/share/runtime/threadSMR.inline.hpp line 59: > >> 57: assert_not_singular(); >> 58: assert_dereferenceable(); >> 59: Prefetch::read(const_cast(_thread_ptr), PrefetchScanIntervalInBytes); > > This prefetch is included because the old code had it. But I'm dubious about it. This is just linear iteration through an array, which seems like the canonical best case for leaving it to the hardware, rather than doing cachelinesize/ptrsize software prefetches per cache line. I'm hoping the original authors can comment. The original author that added the prefetch is @fisk. He's reviewed an earlier version of this fix and I'm hoping he's around to review this version. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From pchilanomate at openjdk.java.net Fri Jul 30 16:49:31 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 30 Jul 2021 16:49:31 GMT Subject: RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes [v2] In-Reply-To: References: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> Message-ID: On Fri, 30 Jul 2021 00:08:55 GMT, Daniel D. Daugherty wrote: >> A trivial follow-up to: >> >> JDK-8271251 JavaThread::java_suspend() fails with "fatal error: Illegal threadstate encountered: 6" >> >> that adds a stronger sanity check of thread state when polling for safepoint/handshakes. >> >> This fix was used to test @pchilano's fix for JDK-8271251 in my JDK17 Mach5 >> Tier[1-8] runs for JDK-8271251. It has also been tested with Mach5 Tier[1-3] >> for jdk/jdk (JDK18). > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > dholmes CR LGTM! Thanks, Patricio ------------- Marked as reviewed by pchilanomate (Committer). PR: https://git.openjdk.java.net/jdk/pull/4936 From dcubed at openjdk.java.net Fri Jul 30 17:21:31 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Jul 2021 17:21:31 GMT Subject: RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes [v2] In-Reply-To: References: <58MmgAWA8DFg43Ky4AbuKHpMNgdztBnvoIy2Dop1OrU=.1a0c133d-bcae-42d8-9522-d23744c18256@github.com> Message-ID: <9wu-N-BqF3YmXwSbDOTDt0nghy8P_kJLFZq1iALhUGE=.31cb0399-7b39-4eff-98c7-d8d2389ac3db@github.com> On Fri, 30 Jul 2021 16:46:06 GMT, Patricio Chilano Mateo wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> dholmes CR > > LGTM! > > Thanks, > Patricio @pchilano - Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4936 From iklam at openjdk.java.net Fri Jul 30 18:57:07 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 30 Jul 2021 18:57:07 GMT Subject: RFR: 8271419: Refactor test code for modifying CDS archive contents In-Reply-To: References: Message-ID: On Fri, 30 Jul 2021 15:33:14 GMT, Yumin Qi wrote: > The code for modifying CDS archive content could be used by other tests so the common code is refactored into a util class CDSArchiveUtils. > > Tests: tier1,tier4 > > Thanks > Yumin Changes requested by iklam (Reviewer). test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java line 152: > 150: > 151: public static void modifyJvmIdent(File jsaFile) throws Exception { > 152: System.out.println(" offset_jvm_ident " + CDSArchiveUtils.offsetJvmIdent); I think the modifyXXX functions should also be moved to CDSArchiveUtils so that they can be called by other test cases. test/lib/jdk/test/lib/cds/CDSArchiveUtils.java line 85: > 83: // fileHeaderSize may not be available > 84: // fileHeaderSize = (int)alignUpWithPageSize(wb.getOffsetForName("file_header_size")); > 85: } This should always be available. `file_header_size` is a constant value (`sizeof(FileMapHeader)`) stored inside cdsoffsets.cpp. It doesn't depend on the contents of the archive file. ------------- PR: https://git.openjdk.java.net/jdk/pull/4945 From kbarrett at openjdk.java.net Fri Jul 30 19:12:31 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 30 Jul 2021 19:12:31 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4] In-Reply-To: <7XZU2gwQFrzk4sl665oruDmYt_VuyJo8-yvacq3NOuw=.198345bb-ead7-499f-a01a-bb7f75675a38@github.com> References: <7XZU2gwQFrzk4sl665oruDmYt_VuyJo8-yvacq3NOuw=.198345bb-ead7-499f-a01a-bb7f75675a38@github.com> Message-ID: On Fri, 30 Jul 2021 16:24:33 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/threadSMR.inline.hpp line 53: >> >>> 51: assert_not_singular(); >>> 52: assert_same_list(i); >>> 53: return _thread_ptr != i._thread_ptr; >> >> Better might be to have the entire body consist of `return operator==(i);`. > > I think what's there is more clear. If we switch to `return operator==(i)`, > then I think that will lead to some head scratching. Especially since it's > making me wonder right now... And _obviously_ I meant `return !operator==(i)`. Need to keep that all-important one-character difference... ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From dcubed at openjdk.java.net Fri Jul 30 19:29:29 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Jul 2021 19:29:29 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4] In-Reply-To: References: <7XZU2gwQFrzk4sl665oruDmYt_VuyJo8-yvacq3NOuw=.198345bb-ead7-499f-a01a-bb7f75675a38@github.com> Message-ID: On Fri, 30 Jul 2021 19:09:02 GMT, Kim Barrett wrote: >> I think what's there is more clear. If we switch to `return operator==(i)`, >> then I think that will lead to some head scratching. Especially since it's >> making me wonder right now... > > And _obviously_ I meant `return !operator==(i)`. Need to keep that all-important one-character difference... Thanks for the clarification. Now you see why I was scratching my head and wondering what C++ voodoo you were doing now... :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From ccheung at openjdk.java.net Fri Jul 30 19:41:00 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 30 Jul 2021 19:41:00 GMT Subject: RFR: 8271003: hs_err improvement: handle CLASSPATH env setting longer than O_BUFLEN Message-ID: Please review this small enhancement for addressing the problem of the CLASSPATH env variable setting being truncated in a hs err log. For printing a char string, it doesn't need to go through `do_vsnprintf()` which does the truncation based on the input buffer length. The change is local to the code path pertaining to hs err log. Testing: - [x] tiers 1, 2 (including the new test) ------------- Commit messages: - fix whitespace error - 8271003: hs_err improvement: handle CLASSPATH env setting longer than O_BUFLEN Changes: https://git.openjdk.java.net/jdk/pull/4947/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4947&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271003 Stats: 144 lines in 3 files changed: 143 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4947.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4947/head:pull/4947 PR: https://git.openjdk.java.net/jdk/pull/4947 From dcubed at openjdk.java.net Fri Jul 30 20:53:53 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Jul 2021 20:53:53 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2] In-Reply-To: <0yNOkRrweFvaVauhMHJz8RVSKurahOukCJ9VKQReuZw=.4309a359-d1de-4979-88d2-f49a4075a03c@github.com> References: <0yNOkRrweFvaVauhMHJz8RVSKurahOukCJ9VKQReuZw=.4309a359-d1de-4979-88d2-f49a4075a03c@github.com> Message-ID: On Sun, 4 Jul 2021 22:29:42 GMT, Kim Barrett wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> kbarrett CR - delete unused _list member. > > Changes requested by kbarrett (Reviewer). Added @kimbarrett's simplification of 'ThreadsList::Iterator::operator!=(Iterator i)'. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From dcubed at openjdk.java.net Fri Jul 30 20:53:53 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Jul 2021 20:53:53 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v5] In-Reply-To: References: Message-ID: > This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." > Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this > piece of history that I'm finally getting around to cleaning up. While this macro has > been with us for a long time, its time has passed... > > Tested with Mach5 Tier[1-3]. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: kbarrett CR - simplify 'ThreadsList::Iterator::operator!=(Iterator i)' ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4671/files - new: https://git.openjdk.java.net/jdk/pull/4671/files/3be5dc72..a8865b8e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4671&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4671&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4671.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4671/head:pull/4671 PR: https://git.openjdk.java.net/jdk/pull/4671 From ccheung at openjdk.java.net Fri Jul 30 21:07:33 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 30 Jul 2021 21:07:33 GMT Subject: RFR: 8271419: Refactor test code for modifying CDS archive contents In-Reply-To: References: Message-ID: On Fri, 30 Jul 2021 15:33:14 GMT, Yumin Qi wrote: > The code for modifying CDS archive content could be used by other tests so the common code is refactored into a util class CDSArchiveUtils. > > Tests: tier1,tier4 > > Thanks > Yumin I have 2 comments. test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java line 159: > 157: public static void modifyHeaderIntField(File jsaFile, long offset, int value) throws Exception { > 158: System.out.println(" offset " + offset); > 159: byte[] buf = { (byte)(value >> 24), (byte)(value >> 16), (byte)(value >> 8), (byte)(value)}; Isn't this the same as the original code which does a `ByteBuffer.wrap()`? If so, why changing it. test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java line 214: > 212: shareAuto = args[0].equals("auto"); > 213: WhiteBox box = WhiteBox.getWhiteBox(); > 214: CDSArchiveUtils.initialize(box); // all offsets available After this refactoring, I don't think WhiteBox is required in this file. So I think CDSArchiveUtils could create a WhiteBox instance instead of requiring the caller to supply one. ------------- PR: https://git.openjdk.java.net/jdk/pull/4945 From dcubed at openjdk.java.net Fri Jul 30 21:39:48 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Jul 2021 21:39:48 GMT Subject: RFR: 8271513: support JavaThreadIteratorWithHandle replacement by new ThreadsList::Iterator Message-ID: <1Z4Ir14GHhlNY2yPFGMl3GXLlB6G2cqCHJReppkJ41E=.0943e1b9-6154-4083-a36f-5a12dda17655@github.com> A trivial fix to support JavaThreadIteratorWithHandle replacement by new ThreadsList::Iterator. ------------- Depends on: https://git.openjdk.java.net/jdk/pull/4671 Commit messages: - Merge branch 'pull/4671' into JDK-8271513 - 8271513: support JavaThreadIteratorWithHandle replacement by new ThreadsList::Iterator Changes: https://git.openjdk.java.net/jdk/pull/4948/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4948&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271513 Stats: 9 lines in 3 files changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4948.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4948/head:pull/4948 PR: https://git.openjdk.java.net/jdk/pull/4948 From minqi at openjdk.java.net Fri Jul 30 22:13:29 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 30 Jul 2021 22:13:29 GMT Subject: RFR: 8271419: Refactor test code for modifying CDS archive contents In-Reply-To: References: Message-ID: <2wZdTIitWGkMFK3RhVKLI9eV-dP6q3r1-G7WiSFz3yA=.1758b982-8601-4b43-ac78-8024dc5331e0@github.com> On Fri, 30 Jul 2021 21:02:24 GMT, Calvin Cheung wrote: >> The code for modifying CDS archive content could be used by other tests so the common code is refactored into a util class CDSArchiveUtils. >> >> Tests: tier1,tier4 >> >> Thanks >> Yumin > > test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java line 214: > >> 212: shareAuto = args[0].equals("auto"); >> 213: WhiteBox box = WhiteBox.getWhiteBox(); >> 214: CDSArchiveUtils.initialize(box); // all offsets available > > After this refactoring, I don't think WhiteBox is required in this file. > So I think CDSArchiveUtils could create a WhiteBox instance instead of requiring the caller to supply one. The util class is just a utility class, I have no idea if we can do this, let me try --- it might work. ------------- PR: https://git.openjdk.java.net/jdk/pull/4945 From minqi at openjdk.java.net Fri Jul 30 22:24:29 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 30 Jul 2021 22:24:29 GMT Subject: RFR: 8271419: Refactor test code for modifying CDS archive contents In-Reply-To: References: Message-ID: On Fri, 30 Jul 2021 21:02:17 GMT, Calvin Cheung wrote: >> The code for modifying CDS archive content could be used by other tests so the common code is refactored into a util class CDSArchiveUtils. >> >> Tests: tier1,tier4 >> >> Thanks >> Yumin > > test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java line 159: > >> 157: public static void modifyHeaderIntField(File jsaFile, long offset, int value) throws Exception { >> 158: System.out.println(" offset " + offset); >> 159: byte[] buf = { (byte)(value >> 24), (byte)(value >> 16), (byte)(value >> 8), (byte)(value)}; > > Isn't this the same as the original code which does a `ByteBuffer.wrap()`? > If so, why changing it. I make CDSARchiveUtils take byte[] as input, not ByteBuffer. Here just simply convert int to byte[]. ------------- PR: https://git.openjdk.java.net/jdk/pull/4945 From minqi at openjdk.java.net Fri Jul 30 22:24:28 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 30 Jul 2021 22:24:28 GMT Subject: RFR: 8271419: Refactor test code for modifying CDS archive contents In-Reply-To: References: Message-ID: On Fri, 30 Jul 2021 18:47:33 GMT, Ioi Lam wrote: >> The code for modifying CDS archive content could be used by other tests so the common code is refactored into a util class CDSArchiveUtils. >> >> Tests: tier1,tier4 >> >> Thanks >> Yumin > > test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java line 152: > >> 150: >> 151: public static void modifyJvmIdent(File jsaFile) throws Exception { >> 152: System.out.println(" offset_jvm_ident " + CDSArchiveUtils.offsetJvmIdent); > > I think the modifyXXX functions should also be moved to CDSArchiveUtils so that they can be called by other test cases. Let me double check this part. > test/lib/jdk/test/lib/cds/CDSArchiveUtils.java line 85: > >> 83: // fileHeaderSize may not be available >> 84: // fileHeaderSize = (int)alignUpWithPageSize(wb.getOffsetForName("file_header_size")); >> 85: } > > This should always be available. `file_header_size` is a constant value (`sizeof(FileMapHeader)`) stored inside cdsoffsets.cpp. It doesn't depend on the contents of the archive file. This is same as original code, I will investigate more of this part. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4945 From kbarrett at openjdk.java.net Sat Jul 31 04:37:31 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 31 Jul 2021 04:37:31 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v5] In-Reply-To: References: Message-ID: On Fri, 30 Jul 2021 20:53:53 GMT, Daniel D. Daugherty wrote: >> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." >> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this >> piece of history that I'm finally getting around to cleaning up. While this macro has >> been with us for a long time, its time has passed... >> >> Tested with Mach5 Tier[1-3]. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > kbarrett CR - simplify 'ThreadsList::Iterator::operator!=(Iterator i)' This looks good to me (unsurprisingly), except for the prefetch question. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From kbarrett at openjdk.java.net Sat Jul 31 04:43:26 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 31 Jul 2021 04:43:26 GMT Subject: RFR: 8271513: support JavaThreadIteratorWithHandle replacement by new ThreadsList::Iterator In-Reply-To: <1Z4Ir14GHhlNY2yPFGMl3GXLlB6G2cqCHJReppkJ41E=.0943e1b9-6154-4083-a36f-5a12dda17655@github.com> References: <1Z4Ir14GHhlNY2yPFGMl3GXLlB6G2cqCHJReppkJ41E=.0943e1b9-6154-4083-a36f-5a12dda17655@github.com> Message-ID: On Fri, 30 Jul 2021 19:19:49 GMT, Daniel D. Daugherty wrote: > A trivial fix to support JavaThreadIteratorWithHandle replacement by new ThreadsList::Iterator. > > This fix was tested with Mach5 Tier[1-3]. Looks good, and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4948 From eosterlund at openjdk.java.net Sat Jul 31 08:14:31 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Sat, 31 Jul 2021 08:14:31 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4] In-Reply-To: <7XZU2gwQFrzk4sl665oruDmYt_VuyJo8-yvacq3NOuw=.198345bb-ead7-499f-a01a-bb7f75675a38@github.com> References: <7XZU2gwQFrzk4sl665oruDmYt_VuyJo8-yvacq3NOuw=.198345bb-ead7-499f-a01a-bb7f75675a38@github.com> Message-ID: On Fri, 30 Jul 2021 16:26:35 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/threadSMR.inline.hpp line 59: >> >>> 57: assert_not_singular(); >>> 58: assert_dereferenceable(); >>> 59: Prefetch::read(const_cast(_thread_ptr), PrefetchScanIntervalInBytes); >> >> This prefetch is included because the old code had it. But I'm dubious about it. This is just linear iteration through an array, which seems like the canonical best case for leaving it to the hardware, rather than doing cachelinesize/ptrsize software prefetches per cache line. I'm hoping the original authors can comment. > > The original author that added the prefetch is @fisk. He's reviewed an earlier > version of this fix and I'm hoping he's around to review this version. I agree that it should be okay without prefetch. I added it when I was running on a 4096 strand SPARC machine running over 8000 threads, and walking the list would approach 1 ms. While intuitively linear scan should be good enough, I did actually measure slight improvements with explicit prefetching, and the slight improvements did seem worth it at the time as the amount of time spent in there was non-trivial. Now we don't support that kind of hardware any longer, so I don't think this trick would necessarily spark as much joy any longer. I don't mind if we do or do not perform the prefetching. I'm okay either way. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From dcubed at openjdk.java.net Sat Jul 31 14:24:30 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 31 Jul 2021 14:24:30 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v5] In-Reply-To: References: Message-ID: On Sat, 31 Jul 2021 04:34:18 GMT, Kim Barrett wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> kbarrett CR - simplify 'ThreadsList::Iterator::operator!=(Iterator i)' > > This looks good to me (unsurprisingly), except for the prefetch question. @kimbarrett - Thanks for the re-review. I'm going to leave resolution of the prefetch question to a follow-up bug. I think that discussion deserves a separate issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From dcubed at openjdk.java.net Sat Jul 31 14:25:30 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 31 Jul 2021 14:25:30 GMT Subject: RFR: 8271513: support JavaThreadIteratorWithHandle replacement by new ThreadsList::Iterator In-Reply-To: References: <1Z4Ir14GHhlNY2yPFGMl3GXLlB6G2cqCHJReppkJ41E=.0943e1b9-6154-4083-a36f-5a12dda17655@github.com> Message-ID: On Sat, 31 Jul 2021 04:40:24 GMT, Kim Barrett wrote: >> A trivial fix to support JavaThreadIteratorWithHandle replacement by new ThreadsList::Iterator. >> >> This fix was tested with Mach5 Tier[1-3]. > > Looks good, and trivial. @kimbarrett - Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4948 From dcubed at openjdk.java.net Sat Jul 31 14:30:46 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 31 Jul 2021 14:30:46 GMT Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator Message-ID: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> A trivial fix to support JFR use of new ThreadsList::Iterator. This fix was tested with Mach5 Tier[1-3]. ------------- Depends on: https://git.openjdk.java.net/jdk/pull/4948 Commit messages: - Merge branch 'pull/4948' into JDK-8271514 - 8271514: support JFR use of new ThreadsList::Iterator Changes: https://git.openjdk.java.net/jdk/pull/4949/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4949&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271514 Stats: 39 lines in 2 files changed: 20 ins; 11 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4949.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4949/head:pull/4949 PR: https://git.openjdk.java.net/jdk/pull/4949 From dcubed at openjdk.java.net Sat Jul 31 14:41:36 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 31 Jul 2021 14:41:36 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4] In-Reply-To: References: <7XZU2gwQFrzk4sl665oruDmYt_VuyJo8-yvacq3NOuw=.198345bb-ead7-499f-a01a-bb7f75675a38@github.com> Message-ID: On Sat, 31 Jul 2021 08:11:05 GMT, Erik ?sterlund wrote: >> The original author that added the prefetch is @fisk. He's reviewed an earlier >> version of this fix and I'm hoping he's around to review this version. > > I agree that it should be okay without prefetch. I added it when I was running on a 4096 strand SPARC machine running over 8000 threads, and walking the list would approach 1 ms. While intuitively linear scan should be good enough, I did actually measure slight improvements with explicit prefetching, and the slight improvements did seem worth it at the time as the amount of time spent in there was non-trivial. > Now we don't support that kind of hardware any longer, so I don't think this trick would necessarily spark as much joy any longer. > I don't mind if we do or do not perform the prefetching. I'm okay either way. I'm going to leave resolution of the prefetch question to a follow-up bug. I think that discussion deserves a separate issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From kbarrett at openjdk.java.net Sat Jul 31 17:40:37 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 31 Jul 2021 17:40:37 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4] In-Reply-To: References: <7XZU2gwQFrzk4sl665oruDmYt_VuyJo8-yvacq3NOuw=.198345bb-ead7-499f-a01a-bb7f75675a38@github.com> Message-ID: On Sat, 31 Jul 2021 14:37:29 GMT, Daniel D. Daugherty wrote: >> I agree that it should be okay without prefetch. I added it when I was running on a 4096 strand SPARC machine running over 8000 threads, and walking the list would approach 1 ms. While intuitively linear scan should be good enough, I did actually measure slight improvements with explicit prefetching, and the slight improvements did seem worth it at the time as the amount of time spent in there was non-trivial. >> Now we don't support that kind of hardware any longer, so I don't think this trick would necessarily spark as much joy any longer. >> I don't mind if we do or do not perform the prefetching. I'm okay either way. > > I'm going to leave resolution of the prefetch question to a follow-up bug. > I think that discussion deserves a separate issue. OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/4671 From kbarrett at openjdk.java.net Sat Jul 31 17:40:36 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 31 Jul 2021 17:40:36 GMT Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v5] In-Reply-To: References: Message-ID: <_ZO1aky7oyRjpY6NTFG_fjGhd9sr0ucpgQ8wO7VXTH8=.8491610a-5043-42f5-a8cc-1e6a906066aa@github.com> On Fri, 30 Jul 2021 20:53:53 GMT, Daniel D. Daugherty wrote: >> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen." >> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this >> piece of history that I'm finally getting around to cleaning up. While this macro has >> been with us for a long time, its time has passed... >> >> Tested with Mach5 Tier[1-3]. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > kbarrett CR - simplify 'ThreadsList::Iterator::operator!=(Iterator i)' Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4671 From minqi at openjdk.java.net Sat Jul 31 20:42:57 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Sat, 31 Jul 2021 20:42:57 GMT Subject: RFR: 8271419: Refactor test code for modifying CDS archive contents [v2] In-Reply-To: References: Message-ID: > The code for modifying CDS archive content could be used by other tests so the common code is refactored into a util class CDSArchiveUtils. > > Tests: tier1,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Move more function to CDSArchiveUtils, fixed review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4945/files - new: https://git.openjdk.java.net/jdk/pull/4945/files/d95f25fa..10104904 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4945&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4945&range=00-01 Stats: 304 lines in 2 files changed: 134 ins; 139 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/4945.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4945/head:pull/4945 PR: https://git.openjdk.java.net/jdk/pull/4945