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: <K8MDn-C4DC39Od5dXdNnq7w1M6FCSFY2OyomoUD6CpE=.9706b47b-bf21-4c0e-864e-46cfbe3d1818@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
 <LxYLS_7x1UhlB9CvfyHqmU7mtBf81L9nJ1CUIGMFKt4=.c12ff5c3-561e-44de-8578-79b4096d1800@github.com>
 <K8MDn-C4DC39Od5dXdNnq7w1M6FCSFY2OyomoUD6CpE=.9706b47b-bf21-4c0e-864e-46cfbe3d1818@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 <coleenp at openjdk.org> 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: <fGk8kHg2GTT2NnXUy6GMD87cET1gIWm3yXZyYXNicoM=.55d3a904-086a-43fb-901d-32b58679b55d@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
 <fGk8kHg2GTT2NnXUy6GMD87cET1gIWm3yXZyYXNicoM=.55d3a904-086a-43fb-901d-32b58679b55d@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 <dholmes at openjdk.org> 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>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
 <LxYLS_7x1UhlB9CvfyHqmU7mtBf81L9nJ1CUIGMFKt4=.c12ff5c3-561e-44de-8578-79b4096d1800@github.com>
 <K8MDn-C4DC39Od5dXdNnq7w1M6FCSFY2OyomoUD6CpE=.9706b47b-bf21-4c0e-864e-46cfbe3d1818@github.com>
 <4a866a63-e9b9-7cf3-9f54-91b11839f69c@oracle.com>
Message-ID: <c3e5d214-23ed-687f-da8e-9ffed9437775@oracle.com>

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 
>> <coleenp at openjdk.org> 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: <LxYLS_7x1UhlB9CvfyHqmU7mtBf81L9nJ1CUIGMFKt4=.c12ff5c3-561e-44de-8578-79b4096d1800@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
 <LxYLS_7x1UhlB9CvfyHqmU7mtBf81L9nJ1CUIGMFKt4=.c12ff5c3-561e-44de-8578-79b4096d1800@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 <dholmes at openjdk.org> 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: <Uo9S3GGZUFzI6oA3Ku8RClqgFrPqS4sqGpJepe1DV8M=.d3cefea1-6e27-428f-9bdc-9bc39e2c445e@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
 <Uo9S3GGZUFzI6oA3Ku8RClqgFrPqS4sqGpJepe1DV8M=.d3cefea1-6e27-428f-9bdc-9bc39e2c445e@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 <dholmes at openjdk.org> 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(&notification_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 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 github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  1 10:38:24 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 1 Jul 2021 10:38:24 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v3]
In-Reply-To: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
Message-ID: <ebvBjXWBYHat1Sel4UzveO8VLsyKMKdbbJ4BaMjcnJk=.4ed164b0-43d8-4668-b0f5-d90209d79fb7@github.com>

> In some JDK classes there's still the following hashCode() implementation:
> 
> long objNum;
> 
> public int hashCode() {
>     return (int) objNum;
> }
> 
> This outdated expression should be replaced with Long.hashCode(long) as it
> 
> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
> 
> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
> 
> See https://stackoverflow.com/a/4045083
> 
> This is related to https://github.com/openjdk/jdk/pull/4309

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

  8268764: Update copy-right year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4491/files
  - new: https://git.openjdk.java.net/jdk/pull/4491/files/12a1d3ac..932c26ad

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

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  1 10:38:28 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 1 Jul 2021 10:38:28 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v2]
In-Reply-To: <ZVcup6_4t_d6djkaIRuX8kk7qs7iUSBdvfTS2CwJR3Y=.fa4ac0b9-41df-4ade-8c38-7f262e5145f3@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
 <ZVcup6_4t_d6djkaIRuX8kk7qs7iUSBdvfTS2CwJR3Y=.fa4ac0b9-41df-4ade-8c38-7f262e5145f3@github.com>
Message-ID: <HB1z1cJI9L5pqd_WmVvj9vi018gqtImK_DEuX-sUtP8=.9ae2c48b-797f-4cd6-99ae-700daa4d8e55@github.com>

On Wed, 30 Jun 2021 11:49:51 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>>     return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> ?????? ??????? has updated the pull request 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 8268764
>  - 8268764: Use Long.hashCode() instead of int-cast where applicable

Hi Kevin, thanks for review! I've updated copy-right year

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

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

From kevinw at openjdk.java.net  Thu Jul  1 11:39:00 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 1 Jul 2021 11:39:00 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v3]
In-Reply-To: <ebvBjXWBYHat1Sel4UzveO8VLsyKMKdbbJ4BaMjcnJk=.4ed164b0-43d8-4668-b0f5-d90209d79fb7@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
 <ebvBjXWBYHat1Sel4UzveO8VLsyKMKdbbJ4BaMjcnJk=.4ed164b0-43d8-4668-b0f5-d90209d79fb7@github.com>
Message-ID: <RNAM2x8XAZGcoB3x5XrGJrXRre7sU01v9IL1OyljLhA=.98fc305e-6ec4-470b-8f8b-3942e87ffced@github.com>

On Thu, 1 Jul 2021 10:38:24 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>>     return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8268764: Update copy-right year

Marked as reviewed by kevinw (Committer).

OK, one more (C) in src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java and done. 8-)
Needs a second Review before integrating, thanks.

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

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

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: <HymICnwa-gBp4HWgbWWAB8B8qJ0Yc-iFPeJy_qUePp0=.35123238-b982-4cdc-96a2-c67c3ee54a8d@github.com>

On Thu, 1 Jul 2021 04:18:28 GMT, David Holmes <dholmes at openjdk.org> 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: <LxYLS_7x1UhlB9CvfyHqmU7mtBf81L9nJ1CUIGMFKt4=.c12ff5c3-561e-44de-8578-79b4096d1800@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
 <LxYLS_7x1UhlB9CvfyHqmU7mtBf81L9nJ1CUIGMFKt4=.c12ff5c3-561e-44de-8578-79b4096d1800@github.com>
Message-ID: <7xYz2Qtk8SqjnFyX0BLqqxyqJoslGqezRk4BfCiigo8=.54517e36-285e-4198-b5b1-223a7c96ebd4@github.com>

On Wed, 30 Jun 2021 18:37:40 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <wgCSkszDxANZt9ApdiCWVp_k7Hw4yHRzMqQJd4CEwws=.30493501-13a7-4dd1-bfaa-1aa7ffbe560b@github.com>

On Thu, 1 Jul 2021 04:18:28 GMT, David Holmes <dholmes at openjdk.org> 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 github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  1 12:19:53 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 1 Jul 2021 12:19:53 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v4]
In-Reply-To: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
Message-ID: <eciHLB1bKgy02_eV0d-Y-RiECZshzMxHakK2ZaUhFk0=.298fe17f-0913-4f1e-8eba-4587c28b05b1@github.com>

> In some JDK classes there's still the following hashCode() implementation:
> 
> long objNum;
> 
> public int hashCode() {
>     return (int) objNum;
> }
> 
> This outdated expression should be replaced with Long.hashCode(long) as it
> 
> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
> 
> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
> 
> See https://stackoverflow.com/a/4045083
> 
> This is related to https://github.com/openjdk/jdk/pull/4309

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

  8268764: Update copy-right year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4491/files
  - new: https://git.openjdk.java.net/jdk/pull/4491/files/932c26ad..20ad76be

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

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  1 12:19:55 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 1 Jul 2021 12:19:55 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v3]
In-Reply-To: <ebvBjXWBYHat1Sel4UzveO8VLsyKMKdbbJ4BaMjcnJk=.4ed164b0-43d8-4668-b0f5-d90209d79fb7@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
 <ebvBjXWBYHat1Sel4UzveO8VLsyKMKdbbJ4BaMjcnJk=.4ed164b0-43d8-4668-b0f5-d90209d79fb7@github.com>
Message-ID: <KfVPBIhy44IKY4Nq3-UmI69sQPfr0Fb2oz_0jgykjfQ=.2edc1651-5efb-43d7-8ac6-5ca82e87713d@github.com>

On Thu, 1 Jul 2021 10:38:24 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>>     return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8268764: Update copy-right year

Right, done!

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

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

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: <NmDg4MtR7kW5aCAu14CDaOGXtQ7z5mcozymZzuaxwPo=.25c0eef0-176d-46fd-9ba8-c47279893b0c@github.com>

On Thu, 1 Jul 2021 04:18:28 GMT, David Holmes <dholmes at openjdk.org> 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: <sUXdcIDOsuFXIPBEEG16xKPA-4r0ax9ZxrR4DmakQL4=.91b07e3e-8ccb-4e63-a433-29c328fedff2@github.com>

On Thu, 1 Jul 2021 04:18:28 GMT, David Holmes <dholmes at openjdk.org> 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: <QshGAbhdFRpS4tk4cL8qfwORjZ15ubUxhtXo3DoEu_E=.c573921e-436f-413a-b15e-fe31ef1d2886@github.com>

On Thu, 1 Jul 2021 04:18:28 GMT, David Holmes <dholmes at openjdk.org> 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 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: <sUXdcIDOsuFXIPBEEG16xKPA-4r0ax9ZxrR4DmakQL4=.91b07e3e-8ccb-4e63-a433-29c328fedff2@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>
 <sUXdcIDOsuFXIPBEEG16xKPA-4r0ax9ZxrR4DmakQL4=.91b07e3e-8ccb-4e63-a433-29c328fedff2@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 <kvn at openjdk.org> 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>
 <sUXdcIDOsuFXIPBEEG16xKPA-4r0ax9ZxrR4DmakQL4=.91b07e3e-8ccb-4e63-a433-29c328fedff2@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 <kvn at openjdk.org> 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: <sUXdcIDOsuFXIPBEEG16xKPA-4r0ax9ZxrR4DmakQL4=.91b07e3e-8ccb-4e63-a433-29c328fedff2@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>
 <sUXdcIDOsuFXIPBEEG16xKPA-4r0ax9ZxrR4DmakQL4=.91b07e3e-8ccb-4e63-a433-29c328fedff2@github.com>
Message-ID: <x9I9OfkIcHwiBR08mKfzpc1PDWpnSvu0hsJyZ9UcPa4=.ecd937e2-e259-4feb-bdd9-77d20c1d4ee9@github.com>

On Thu, 1 Jul 2021 16:18:50 GMT, Vladimir Kozlov <kvn at openjdk.org> 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>
 <sUXdcIDOsuFXIPBEEG16xKPA-4r0ax9ZxrR4DmakQL4=.91b07e3e-8ccb-4e63-a433-29c328fedff2@github.com>
 <1ywsxUI_B9ZGVP_Us0O5lecBx4qtglIzGSI6hVXz6gM=.ad566e05-2bdd-4bb9-a5f5-bdb38c768a3a@github.com>
Message-ID: <u_eio3px2YC5U1oIUSBtqUNZD3Ag-U-k2FUFBKtTgJE=.210cb113-e69a-4a75-91ad-a0f3d71496a7@github.com>

On Thu, 1 Jul 2021 17:33:02 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <HymICnwa-gBp4HWgbWWAB8B8qJ0Yc-iFPeJy_qUePp0=.35123238-b982-4cdc-96a2-c67c3ee54a8d@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>
 <HymICnwa-gBp4HWgbWWAB8B8qJ0Yc-iFPeJy_qUePp0=.35123238-b982-4cdc-96a2-c67c3ee54a8d@github.com>
Message-ID: <mUJplDDhcmTdACbrB13To6DNHZWLIMsllQkg8i-BUlw=.7baeb238-7127-4f49-8325-a781dfcf87e5@github.com>

On Thu, 1 Jul 2021 12:07:10 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <OY7wGWVOEUyBO5FZIAbeDyGs8KgW33L7JWHK6IReAVk=.bc8fca74-4baa-4578-9539-0edea7b78496@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 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: <QshGAbhdFRpS4tk4cL8qfwORjZ15ubUxhtXo3DoEu_E=.c573921e-436f-413a-b15e-fe31ef1d2886@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>
 <QshGAbhdFRpS4tk4cL8qfwORjZ15ubUxhtXo3DoEu_E=.c573921e-436f-413a-b15e-fe31ef1d2886@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 <dholmes at openjdk.org> 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: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: <x9I9OfkIcHwiBR08mKfzpc1PDWpnSvu0hsJyZ9UcPa4=.ecd937e2-e259-4feb-bdd9-77d20c1d4ee9@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>
 <sUXdcIDOsuFXIPBEEG16xKPA-4r0ax9ZxrR4DmakQL4=.91b07e3e-8ccb-4e63-a433-29c328fedff2@github.com>
 <x9I9OfkIcHwiBR08mKfzpc1PDWpnSvu0hsJyZ9UcPa4=.ecd937e2-e259-4feb-bdd9-77d20c1d4ee9@github.com>
Message-ID: <RjhaB6-T7iBBAsoxVKhqL4KwRVUwCByWwgQdxqXelOY=.fbca8676-e7c6-4603-8eb1-bdfc931df757@github.com>

On Thu, 1 Jul 2021 22:02:40 GMT, David Holmes <dholmes at openjdk.org> 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 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: <OY7wGWVOEUyBO5FZIAbeDyGs8KgW33L7JWHK6IReAVk=.bc8fca74-4baa-4578-9539-0edea7b78496@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <OY7wGWVOEUyBO5FZIAbeDyGs8KgW33L7JWHK6IReAVk=.bc8fca74-4baa-4578-9539-0edea7b78496@github.com>
Message-ID: <hU0EpYFo0IgxW53nZ40Cid68GmnlDf6uIldeEpf7Qko=.16fd60a5-4831-4d93-b435-170eaa46339e@github.com>

On Thu, 1 Jul 2021 22:17:27 GMT, David Holmes <dholmes at openjdk.org> 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 amenkov at openjdk.java.net  Thu Jul  1 23:28:16 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 1 Jul 2021 23:28:16 GMT
Subject: RFR: 8269770: nsk tests should start IOPipe channel before launch
 debuggee - Debugee.prepareDebugee
Message-ID: <Ul6inNVMRVB_OAtRF6ONX1HfJ1xLxZ-olKE95X_FiF4=.9b6cad69-0927-4750-b28d-e3099ea4f636@github.com>

The change fixes several hundreds tests which launch debugee by using uses Debugee.prepareDebugee() method or use 
debugee = Binder.bindToDebugee(...);
IOPipe pipe = debugee.createIOPipe();
logic.
Debugee.prepareDebugee() and Binder.bindToDebugee() launch debuggee by using CommandLineLaunch JDI connector with suspend=="true" argument, so they return debuggee suspended before the main class is loaded.
The fix starts IOPipe listening before debuggee VM is resumed.

Simplified isPackagePrivate/accipp001.java test to use Debugee.prepareDebugee() - it does exactly the same as Debugee.prepareDebugee() does (the only difference is using deprecated IOPipe ctor instead of Debugee.createIOPipe())

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

Commit messages:
 - DebugeeProcess.createIOPipe starts listening

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

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

From ddong at openjdk.java.net  Fri Jul  2 03:23:00 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 2 Jul 2021 03:23:00 GMT
Subject: RFR: 8269470: Add truncation and compression information to
 EventHeapDump [v2]
In-Reply-To: <arcifDTQoKL6qDJ7mg0ml94-1evr0nAAUmqA9wlcgy8=.0057fdf3-d930-4cef-8161-20ec3ee55235@github.com>
References: <6aIKhIzZuN1t1DZhSzfV9HLQrKnau9zB77VggMdg1sQ=.a8128116-723d-4384-a1b4-36ba3e7fc46c@github.com>
 <arcifDTQoKL6qDJ7mg0ml94-1evr0nAAUmqA9wlcgy8=.0057fdf3-d930-4cef-8161-20ec3ee55235@github.com>
Message-ID: <k4aanAzldKsOOPM6QCyGIIkVJlV_0gtPxBIz0dbQ9ic=.1cec42ea-2bdd-46da-9f9a-2af6c01e4c36@github.com>

On Mon, 28 Jun 2021 07:39:40 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Could I have a review of this change that adds the truncation and compression information to EventHeapDump?
>> 
>> We occasionally receive feedback from users that the heap size parsed from the heap dump does not match the GC log. We think this may be caused by the truncation of the heap dump.
>> 
>> It would be nice to add truncation info to the EventHeapDump.
>> 
>> Also, this patch adds the compression info which is trivial to add.
>> 
>> Regards,
>> Denghui
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wrong return type

Forward to serviceability

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

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

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: <fGk8kHg2GTT2NnXUy6GMD87cET1gIWm3yXZyYXNicoM=.55d3a904-086a-43fb-901d-32b58679b55d@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
 <fGk8kHg2GTT2NnXUy6GMD87cET1gIWm3yXZyYXNicoM=.55d3a904-086a-43fb-901d-32b58679b55d@github.com>
Message-ID: <ZsrWwJ-2mjjTYHBvxTJCLih1Gn_WfqfXpQaKTiUENcM=.00efc4ad-0120-495d-ae91-ea1db2b68e99@github.com>

On Wed, 30 Jun 2021 15:54:12 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> 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: <z2l_ieJsfj4NTPvmOpW7Ly_DQ2kgAFmpRNJYLOhF4A4=.540f3acd-f9cc-4926-a051-7d7c8b828da2@github.com>

On Tue, 29 Jun 2021 21:55:04 GMT, David Holmes <dholmes at openjdk.org> 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 <dholmes at openjdk.org>
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 sspitsyn at openjdk.java.net  Fri Jul  2 06:22:05 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 2 Jul 2021 06:22:05 GMT
Subject: RFR: 8269770: nsk tests should start IOPipe channel before launch
 debuggee - Debugee.prepareDebugee
In-Reply-To: <Ul6inNVMRVB_OAtRF6ONX1HfJ1xLxZ-olKE95X_FiF4=.9b6cad69-0927-4750-b28d-e3099ea4f636@github.com>
References: <Ul6inNVMRVB_OAtRF6ONX1HfJ1xLxZ-olKE95X_FiF4=.9b6cad69-0927-4750-b28d-e3099ea4f636@github.com>
Message-ID: <R6Jkwhwu0vTK7tooQF-7NgKj1MZ17SVDOQPm7eVkkng=.fbb4b3fb-0f25-4ac9-9319-2a6dc1b0c872@github.com>

On Thu, 1 Jul 2021 23:21:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes several hundreds tests which launch debugee by using uses Debugee.prepareDebugee() method or use 
> debugee = Binder.bindToDebugee(...);
> IOPipe pipe = debugee.createIOPipe();
> logic.
> Debugee.prepareDebugee() and Binder.bindToDebugee() launch debuggee by using CommandLineLaunch JDI connector with suspend=="true" argument, so they return debuggee suspended before the main class is loaded.
> The fix starts IOPipe listening before debuggee VM is resumed.
> 
> Simplified isPackagePrivate/accipp001.java test to use Debugee.prepareDebugee() - it does exactly the same as Debugee.prepareDebugee() does (the only difference is using deprecated IOPipe ctor instead of Debugee.createIOPipe())
> 
> Tested all affected tests:
> test/hotspot/jtreg/vmTestbase/nsk/jdi
> test/hotspot/jtreg/vmTestbase/nsk/jdwp
> test/hotspot/jtreg/serviceability/dcmd

Marked as reviewed by sspitsyn (Reviewer).

test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java line 111:

> 109:     // --------------------------------------------------- //
> 110: 
> 111:     /** Created and return new IOPipe channel to the debuggee VM.

Not your typo but would be nice to fix this in the comment:  "Created" => "Create"

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

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

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 lzang at openjdk.java.net  Fri Jul  2 12:12:16 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 2 Jul 2021 12:12:16 GMT
Subject: RFR: 8269685: Optimize HeapHprofBinWriter implementation
Message-ID: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>

This PR rewrite the implementation of the HeapHprofBinWriter, which could simplify the logic of current implementation.
please see detail description at https://bugs.openjdk.java.net/browse/JDK-8269685.

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

Commit messages:
 - 8269685: Optimize HeapHprofBinWriter implementation

Changes: https://git.openjdk.java.net/jdk/pull/4666/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4666&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269685
  Stats: 468 lines in 3 files changed: 209 ins; 246 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4666.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4666/head:pull/4666

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

From lzang at openjdk.java.net  Fri Jul  2 12:16:18 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 2 Jul 2021 12:16:18 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v14]
In-Reply-To: <pew__FWJ2yL8cHc4dBGF8RBNk8AQbIHpnjOi7z4Ishk=.750d707c-3109-4ab9-be73-8889066b2a05@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <pew__FWJ2yL8cHc4dBGF8RBNk8AQbIHpnjOi7z4Ishk=.750d707c-3109-4ab9-be73-8889066b2a05@github.com>
Message-ID: <wEcA6iHnfyLx4dxmxuV8Bzfcqs2XA3lp5CzzUbRay-U=.fdb821b9-19ca-4908-81ca-7218cda15927@github.com>

On Mon, 7 Jun 2021 08:01:54 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
>
> 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 18 additional commits since the last revision:
> 
>  - Merge branch 'master' into sadump-fix
>  - Merge branch 'master' into sadump-fix
>  - Merge branch 'master' into s-fix
>  - add comment for the timestamp value
>  - Merge branch 'master' into s-fix
>  - Fix typo and add comment
>  - Merge branch 'master' into s-fix
>  - fix typo in comments
>  - Merge branch 'master' into s-fix
>  - Merge branch 'master'
>  - ... and 8 more: https://git.openjdk.java.net/jdk/compare/f53ba509...a87793c3

Dear All,
     Please note that the issue could also be fixed by a new PR #4666.  IMHO, this one could be closed when the #4666 is ready for pushing. 
     Thanks!

Lin

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

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

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 <dholmes at openjdk.org> 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 amenkov at openjdk.java.net  Fri Jul  2 19:30:11 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 2 Jul 2021 19:30:11 GMT
Subject: RFR: 8269770: nsk tests should start IOPipe channel before launch
 debuggee - Debugee.prepareDebugee [v2]
In-Reply-To: <Ul6inNVMRVB_OAtRF6ONX1HfJ1xLxZ-olKE95X_FiF4=.9b6cad69-0927-4750-b28d-e3099ea4f636@github.com>
References: <Ul6inNVMRVB_OAtRF6ONX1HfJ1xLxZ-olKE95X_FiF4=.9b6cad69-0927-4750-b28d-e3099ea4f636@github.com>
Message-ID: <NN8U4ddBK-4rcoVri_yEo8o13MAOajtLl4smgln4PJ0=.347bd198-8e2e-4b8b-99bf-ef808f5c894f@github.com>

> The change fixes several hundreds tests which launch debugee by using uses Debugee.prepareDebugee() method or use 
> debugee = Binder.bindToDebugee(...);
> IOPipe pipe = debugee.createIOPipe();
> logic.
> Debugee.prepareDebugee() and Binder.bindToDebugee() launch debuggee by using CommandLineLaunch JDI connector with suspend=="true" argument, so they return debuggee suspended before the main class is loaded.
> The fix starts IOPipe listening before debuggee VM is resumed.
> 
> Simplified isPackagePrivate/accipp001.java test to use Debugee.prepareDebugee() - it does exactly the same as Debugee.prepareDebugee() does (the only difference is using deprecated IOPipe ctor instead of Debugee.createIOPipe())
> 
> Tested all affected tests:
> test/hotspot/jtreg/vmTestbase/nsk/jdi
> test/hotspot/jtreg/vmTestbase/nsk/jdwp
> test/hotspot/jtreg/serviceability/dcmd

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  Fixed comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4659/files
  - new: https://git.openjdk.java.net/jdk/pull/4659/files/8c46ee02..854df1c9

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

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

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

From amenkov at openjdk.java.net  Fri Jul  2 21:32:01 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 2 Jul 2021 21:32:01 GMT
Subject: RFR: 8269616: serviceability/dcmd/framework/VMVersionTest.java fails
 with Address already in use error
Message-ID: <cGHTffmXV_fPcR2uzsbb0Xyj7QUqg0Sm1ZkUCkwhXUg=.b4f9adb3-a430-42f0-a95d-e5a906c9e30d@github.com>

SocketIOPipe/IOPipe classes can select listening port by 2 ways:
1. caller specifies "-transport.address=dynamic" argument creating ArgumentHandler,
and calls Binder.prepareForPipeConnection (actually see nsk.share.jpda.DebugeeBinder.prepareForPipeConnection()) before start listening.
In the case prepareForPipeConnection creates socket and this socket later is used by IOPipe.
2. just start IOPipe listening.
Then port is selected by calling nsk.share.jpda.DebugeeArgumentHandler.getTransportPort() which use findFreePort() method:

    ServerSocket ss;
    try {
        ss = new ServerSocket(0);
        return String.valueOf(ss.getLocalPort());
    }finally {
        ss.close();
    }

This method is known to be error prone (sometimes causes "address in use" error).

The fix adds "-transport.address=dynamic" argument so IOPipe use 1st method.

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

Commit messages:
 - Fixed "address in use" error

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

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

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: <JfOeeO4t1fkm7ujpHQWm7OWKHrX9EK8mejD1i5Dutw0=.fae54913-1a81-464d-a5b5-f1e41c7d083f@github.com>

On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes <dholmes at openjdk.org> 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 cjplummer at openjdk.java.net  Fri Jul  2 22:05:15 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 2 Jul 2021 22:05:15 GMT
Subject: [jdk17] RFR: 8269830: SA's vm object vtable matching code sometimes
 matches on incorrect type
Message-ID: <k9MpheHb72YinJMy-nEXdNMMasleSwZ-3QpRjU-n-zI=.0485265c-ec3c-41b7-b0b4-4099d380b292@github.com>

See the CR for details. This issue is causing a lot of failures related to some threads occasionally not being included in the jstack output, such as SteadyStateThread, Common-Cleaner, and "Signal Dispatcher". The bug caused SA to sometimes think a JavaThread object is actually an instance of the CompilerThread subclass, even though it is not. This results in jstack not including the thread in the output since it purposefully omits CompilerThreads.

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

Commit messages:
 - Get rid of solaris support addressTypeIsEqualToType that was causing issues on other platforms

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

PR: https://git.openjdk.java.net/jdk17/pull/206

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 <dholmes at openjdk.org> 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: <JfOeeO4t1fkm7ujpHQWm7OWKHrX9EK8mejD1i5Dutw0=.fae54913-1a81-464d-a5b5-f1e41c7d083f@github.com>
References: <1xlkxAdEDe5AYusaPTY00esOKsUauSzADqpybjg2l60=.8322ca9d-b460-4e27-a8ea-30795ceef90d@github.com>
 <JfOeeO4t1fkm7ujpHQWm7OWKHrX9EK8mejD1i5Dutw0=.fae54913-1a81-464d-a5b5-f1e41c7d083f@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 <dholmes at openjdk.org> 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 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 <dholmes at openjdk.org> 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 <dholmes at openjdk.org> 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 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 <dholmes at openjdk.org> 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: <b77c9f8f-d3ac-928c-a531-ffe1736dabe3@oracle.com>

On 3/07/2021 10:40 am, Vladimir Kozlov wrote:
> On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes <dholmes at openjdk.org> 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 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: <NX0_18_syB0D2X_yNluL3C-tcfnEkjPXu4_yF51jA8o=.074492c2-990a-4de1-aeb6-876b705a42e1@github.com>

On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes <dholmes at openjdk.org> 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 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: <uabK40D-krpkquIQFn446BzMbvKf03bBF11Krb0QmYg=.4e7c6660-aa89-430b-9a96-74b30d63cb08@github.com>

On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes <dholmes at openjdk.org> 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 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: <PTKZxlI93v0JUj-dvByukFvCpG7_tzXyITmF_mWqjMs=.d6778124-d987-4404-af15-342636e313c1@github.com>

On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes <dholmes at openjdk.org> 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 <dholmes at openjdk.org>
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 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: <IaBR4pKZ5_lc-2DkcO22uchOPH1nFHQV7j6jIxgjr7c=.74a34075-57ca-44df-b6bc-68daa0b8ede9@github.com>

On Sat, 3 Jul 2021 14:15:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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 yyang at openjdk.java.net  Mon Jul  5 06:04:50 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 5 Jul 2021 06:04:50 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible
In-Reply-To: <wnnvM-AabtvXj6GyY15k2WngzWJhz6OXWfs_PygCaWU=.17e6e99b-e808-4c9e-89cc-4af2213e301e@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <wnnvM-AabtvXj6GyY15k2WngzWJhz6OXWfs_PygCaWU=.17e6e99b-e808-4c9e-89cc-4af2213e301e@github.com>
Message-ID: <u2TRSykc6zsKvQKGF74xka3w2odK2m0dx0HmEP0BwZc=.c8dfba1f-55b4-4e8e-a2ad-5286097ea203@github.com>

On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Class loading order is different to class initialization order.
> 
> There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them.  If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing.
> 
> Thanks,
> David

@dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest version? Thanks.

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

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

From dholmes at openjdk.java.net  Mon Jul  5 06:32:54 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 5 Jul 2021 06:32:54 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible
In-Reply-To: <u2TRSykc6zsKvQKGF74xka3w2odK2m0dx0HmEP0BwZc=.c8dfba1f-55b4-4e8e-a2ad-5286097ea203@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <wnnvM-AabtvXj6GyY15k2WngzWJhz6OXWfs_PygCaWU=.17e6e99b-e808-4c9e-89cc-4af2213e301e@github.com>
 <u2TRSykc6zsKvQKGF74xka3w2odK2m0dx0HmEP0BwZc=.c8dfba1f-55b4-4e8e-a2ad-5286097ea203@github.com>
Message-ID: <rKyGMmub9-W1VGCGX86Wkh9f-GdRcUtEupSXLY1Jarw=.67f42692-0937-4a4a-9331-4c5a641dc2ea@github.com>

On Mon, 5 Jul 2021 06:01:23 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Class loading order is different to class initialization order.
>> 
>> There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them.  If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing.
>> 
>> Thanks,
>> David
>
> @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest version? Thanks.

@kelthuzadx  I did not see any response to my query about the change in initialization (not load) order. I also remain concerned about introducing cross dependencies between core classes (e.g. String now uses Precondition, so does that impact Precondition using String?) But these are things for the core-libs folk to be concerned about, or not.

Cheers,
David

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

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

From yyang at openjdk.java.net  Mon Jul  5 08:06:54 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 5 Jul 2021 08:06:54 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible
In-Reply-To: <u2TRSykc6zsKvQKGF74xka3w2odK2m0dx0HmEP0BwZc=.c8dfba1f-55b4-4e8e-a2ad-5286097ea203@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <wnnvM-AabtvXj6GyY15k2WngzWJhz6OXWfs_PygCaWU=.17e6e99b-e808-4c9e-89cc-4af2213e301e@github.com>
 <u2TRSykc6zsKvQKGF74xka3w2odK2m0dx0HmEP0BwZc=.c8dfba1f-55b4-4e8e-a2ad-5286097ea203@github.com>
Message-ID: <MGaJGRNH13DuTwOv-AhcTnmRWHnXIDT8Lh3gNYzRu6E=.9ce30156-e8cc-4d30-8959-7a77f0f840eb@github.com>

On Mon, 5 Jul 2021 06:01:23 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Class loading order is different to class initialization order.
>> 
>> There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them.  If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing.
>> 
>> Thanks,
>> David
>
> @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest version? Thanks.

> @kelthuzadx I did not see any response to my query about the change in initialization (not load) order. I also remain concerned about introducing cross dependencies between core classes (e.g. String now uses Precondition, so does that impact Precondition using String?) But these are things for the core-libs folk to be concerned about, or not.
> 
> Cheers,
> David

Hi David, the following are initialization orders:

$./java -Xlog:class+init -version
[0.255s][info][class,init] 0 Initializing 'java/lang/Object'(no method) (0x0000000800000e18)
[0.255s][info][class,init] 1 Initializing 'java/lang/CharSequence'(no method) (0x000000080006ba68)
[0.255s][info][class,init] 2 Initializing 'java/lang/String' (0x000000080000e978)
[0.255s][info][class,init] 3 Initializing 'java/util/Comparator'(no method) (0x00000008000fd760)
[0.255s][info][class,init] 4 Initializing 'java/lang/String$CaseInsensitiveComparator'(no method) (0x0000000800130988)
[0.255s][info][class,init] 5 Initializing 'java/lang/System' (0x0000000800008c68)
[0.256s][info][class,init] 6 Initializing 'java/lang/reflect/AnnotatedElement'(no method) (0x0000000800001f88)
[0.256s][info][class,init] 7 Initializing 'java/lang/reflect/Type'(no method) (0x0000000800002930)
[0.256s][info][class,init] 8 Initializing 'java/lang/Class' (0x0000000800001830)
[0.256s][info][class,init] 9 Initializing 'java/lang/ThreadGroup'(no method) (0x000000080001d348)
[0.257s][info][class,init] 10 Initializing 'java/lang/Thread' (0x000000080001c470)
[0.258s][info][class,init] 11 Initializing 'java/security/AccessController' (0x0000000800009a80)
[0.258s][info][class,init] 12 Initializing 'java/security/AccessControlContext' (0x00000008000743c8)
[0.258s][info][class,init] 13 Initializing 'java/lang/Module' (0x000000080000bab0)
[0.259s][info][class,init] 14 Initializing 'java/lang/Module$ArchivedData' (0x00000008001a05a8)
[0.259s][info][class,init] 15 Initializing 'jdk/internal/misc/CDS' (0x0000000800018bf8)
[0.259s][info][class,init] 16 Initializing 'java/lang/Iterable'(no method) (0x000000080008be28)
[0.259s][info][class,init] 17 Initializing 'java/util/Collection'(no method) (0x000000080008c028)
[0.260s][info][class,init] 18 Initializing 'java/util/AbstractCollection'(no method) (0x00000008000381e0)
[0.260s][info][class,init] 19 Initializing 'java/util/ImmutableCollections$AbstractImmutableCollection'(no method) (0x000000080008c2f8)
[0.260s][info][class,init] 20 Initializing 'java/util/Set'(no method) (0x00000008000189f8)
[0.260s][info][class,init] 21 Initializing 'java/util/ImmutableCollections$AbstractImmutableSet'(no method) (0x000000080008d018)
[0.260s][info][class,init] 22 Initializing 'java/util/ImmutableCollections$Set12'(no method) (0x000000080008ba18)
[0.369s][info][class,init] 23 Initializing 'jdk/internal/misc/UnsafeConstants' (0x00000008000b4ea0)
[0.369s][info][class,init] 24 Initializing 'java/lang/reflect/AccessibleObject' (0x000000080005b4d8)
[0.370s][info][class,init] 25 Initializing 'java/lang/reflect/ReflectAccess'(no method) (0x0000000800013610)
[0.370s][info][class,init] 26 Initializing 'jdk/internal/access/SharedSecrets' (0x0000000800013408)
[0.370s][info][class,init] 27 Initializing 'java/lang/invoke/MethodHandles' (0x0000000800131720)
[0.371s][info][class,init] 28 Initializing 'java/lang/invoke/MemberName' (0x00000008000de230)
[0.371s][info][class,init] 29 Initializing 'java/lang/invoke/MemberName$Factory' (0x0000000800023468)
[0.372s][info][class,init] 30 Initializing 'java/security/Permission'(no method) (0x0000000800023020)
[0.372s][info][class,init] 31 Initializing 'java/security/BasicPermission'(no method) (0x0000000800025de8)
[0.372s][info][class,init] 32 Initializing 'java/lang/reflect/ReflectPermission'(no method) (0x0000000800025b98)
[0.372s][info][class,init] 33 Initializing 'java/lang/StringLatin1' (0x0000000800022e18)
[0.373s][info][class,init] 34 Initializing 'java/lang/invoke/MethodHandles$Lookup' (0x00000008000e3708)
[0.373s][info][class,init] 35 Initializing 'java/util/Objects'(no method) (0x000000080008b810)
[0.374s][info][class,init] 36 Initializing 'jdk/internal/reflect/Reflection' (0x000000080000fb28)
[0.374s][info][class,init] 37 Initializing 'java/util/ImmutableCollections' (0x000000080008d420)
[0.374s][info][class,init] 38 Initializing 'java/util/List'(no method) (0x000000080008e460)
[0.374s][info][class,init] 39 Initializing 'java/util/ImmutableCollections$AbstractImmutableList'(no method) (0x000000080008c670)
[0.374s][info][class,init] 40 Initializing 'java/util/ImmutableCollections$ListN'(no method) (0x00000008001d2ad0)
[0.374s][info][class,init] 41 Initializing 'java/util/ImmutableCollections$SetN'(no method) (0x000000080018fd58)
[0.375s][info][class,init] 42 Initializing 'java/util/Map'(no method) (0x0000000800018368)
[0.375s][info][class,init] 43 Initializing 'java/util/AbstractMap'(no method) (0x0000000800057d08)
[0.375s][info][class,init] 44 Initializing 'java/util/ImmutableCollections$AbstractImmutableMap'(no method) (0x000000080011aef8)
[0.375s][info][class,init] 45 Initializing 'java/util/ImmutableCollections$MapN'(no method) (0x000000080018a888)
[0.487s][info][class,init] 46 Initializing 'java/lang/Math' (0x0000000800027918)
[0.488s][info][class,init] 47 Initializing 'java/lang/Number'(no method) (0x000000080003fd18)
[0.488s][info][class,init] 48 Initializing 'java/lang/Float' (0x0000000800048978)
[0.488s][info][class,init] 49 Initializing 'java/lang/Double' (0x000000080004a478)
[0.488s][info][class,init] 50 Initializing 'java/util/HashMap'(no method) (0x000000080011a6a0)
[0.489s][info][class,init] 51 Initializing 'java/lang/Integer' (0x000000080004bb58)
[0.489s][info][class,init] 52 Initializing 'java/util/AbstractSet'(no method) (0x000000080011ced8)
[0.489s][info][class,init] 53 Initializing 'java/util/ImmutableCollections$MapN$1'(no method) (0x00000008001e0f10)
[0.489s][info][class,init] 54 Initializing 'java/util/Iterator'(no method) (0x00000008000047d8)
[0.489s][info][class,init] 55 Initializing 'java/util/ImmutableCollections$MapN$MapNIterator'(no method) (0x00000008000192c0)
[0.490s][info][class,init] 56 Initializing 'java/util/KeyValueHolder'(no method) (0x000000080016d540)
[0.490s][info][class,init] 57 Initializing 'java/util/HashMap$Node'(no method) (0x000000080016c8f8)
[0.491s][info][class,init] 58 Initializing 'java/util/concurrent/ConcurrentMap'(no method) (0x00000008001872d8)
[0.491s][info][class,init] 59 Initializing 'java/util/concurrent/ConcurrentHashMap' (0x000000080000e3d0)
[0.491s][info][class,init] 60 Initializing 'java/lang/Runtime' (0x000000080016c650)
[0.491s][info][class,init] 61 Initializing 'java/io/ObjectStreamField'(no method) (0x00000008000fd960)
[0.492s][info][class,init] 62 Initializing 'jdk/internal/misc/Unsafe' (0x0000000800010140)
[0.493s][info][class,init] 63 Initializing 'jdk/internal/reflect/ReflectionFactory$GetReflectionFactoryAction'(no method) (0x0000000800146b08)
[0.494s][info][class,init] 64 Initializing 'jdk/internal/reflect/ReflectionFactory' (0x000000080005a630)
[0.494s][info][class,init] 65 Initializing 'java/lang/ref/Reference' (0x00000008000533f8)
[0.494s][info][class,init] 66 Initializing 'java/lang/ref/Reference$ReferenceHandler' (0x0000000800054af8)
[0.495s][info][class,init] 67 Initializing 'java/lang/ref/PhantomReference'(no method) (0x0000000800053640)
[0.495s][info][class,init] 68 Initializing 'jdk/internal/ref/Cleaner' (0x00000008000548a0)
[0.495s][info][class,init] 69 Initializing 'java/lang/ref/ReferenceQueue' (0x000000080005a1a8)
[0.495s][info][class,init] 70 Initializing 'java/lang/ref/ReferenceQueue$Null'(no method) (0x000000080005a3e8)
[0.495s][info][class,init] 71 Initializing 'java/lang/ref/ReferenceQueue$Lock'(no method) (0x00000008001f3cd8)
[0.496s][info][class,init] 72 Initializing 'java/lang/ref/Reference$1'(no method) (0x000000080005aab0)
[0.496s][info][class,init] 73 Initializing 'java/lang/reflect/Executable'(no method) (0x000000080005b798)
[0.496s][info][class,init] 74 Initializing 'java/lang/reflect/Method'(no method) (0x000000080005c430)
[0.496s][info][class,init] 75 Initializing 'java/lang/ref/FinalReference'(no method) (0x00000008000553d8)
[0.496s][info][class,init] 76 Initializing 'java/lang/ref/Finalizer' (0x0000000800055620)
[0.496s][info][class,init] 77 Initializing 'java/lang/ref/Finalizer$FinalizerThread'(no method) (0x000000080017e790)
[0.497s][info][class,init] 78 Initializing 'java/lang/System$2'(no method) (0x0000000800015b68)
[0.498s][info][class,init] 79 Initializing 'jdk/internal/util/SystemProps' (0x0000000800015960)
[0.498s][info][class,init] 80 Initializing 'jdk/internal/util/SystemProps$Raw'(no method) (0x000000080009e300)
[0.499s][info][class,init] 81 Initializing 'jdk/internal/misc/VM' (0x000000080000fd30)
[0.500s][info][class,init] 82 Initializing 'java/lang/StringConcatHelper' (0x0000000800016308)
[0.500s][info][class,init] 83 Initializing 'java/lang/Byte' (0x0000000800040330)
[0.500s][info][class,init] 84 Initializing 'java/lang/VersionProps' (0x0000000800016100)
[0.502s][info][class,init] 85 Initializing 'java/util/Arrays' (0x0000000800027b20)
[0.502s][info][class,init] 86 Initializing 'java/lang/Character' (0x000000080003e1c8)
[0.502s][info][class,init] 87 Initializing 'java/lang/CharacterData'(no method) (0x00000008000449a8)
[0.503s][info][class,init] 88 Initializing 'java/lang/CharacterDataLatin1' (0x0000000800044638)
[0.503s][info][class,init] 89 Initializing 'java/lang/Integer$IntegerCache' (0x000000080003fb10)
[0.624s][info][class,init] 90 Initializing 'java/util/Dictionary'(no method) (0x0000000800016970)
[0.624s][info][class,init] 91 Initializing 'java/util/Hashtable'(no method) (0x0000000800016bb0)
[0.624s][info][class,init] 92 Initializing 'java/util/Properties' (0x0000000800016510)
[0.624s][info][class,init] 93 Initializing 'java/util/HashMap$EntrySet'(no method) (0x00000008001f0b48)
[0.624s][info][class,init] 94 Initializing 'java/util/HashMap$HashIterator'(no method) (0x00000008000199f0)
[0.624s][info][class,init] 95 Initializing 'java/util/HashMap$EntryIterator'(no method) (0x0000000800019c00)
[0.625s][info][class,init] 96 Initializing 'java/util/concurrent/ConcurrentHashMap$Node'(no method) (0x00000008001be7b8)
[0.626s][info][class,init] 97 Initializing 'jdk/internal/util/StaticProperty' (0x00000008000197e8)
[0.626s][info][class,init] 98 Initializing 'java/io/InputStream'(no method) (0x000000080001a100)
[0.626s][info][class,init] 99 Initializing 'java/io/FileInputStream' (0x0000000800019e48)
[0.627s][info][class,init] 100 Initializing 'java/io/FileDescriptor' (0x000000080001ac70)
[0.627s][info][class,init] 101 Initializing 'java/io/FileDescriptor$1'(no method) (0x00000008001fe1d8)
[0.627s][info][class,init] 102 Initializing 'java/io/OutputStream'(no method) (0x0000000800013cf8)
[0.628s][info][class,init] 103 Initializing 'java/io/FileOutputStream' (0x000000080001ae80)
[0.628s][info][class,init] 104 Initializing 'java/io/FilterInputStream'(no method) (0x000000080001b630)
[0.628s][info][class,init] 105 Initializing 'java/io/BufferedInputStream' (0x000000080001b378)
[0.628s][info][class,init] 106 Initializing 'java/io/FilterOutputStream'(no method) (0x0000000800013f70)
[0.629s][info][class,init] 107 Initializing 'java/io/PrintStream'(no method) (0x0000000800013948)
[0.629s][info][class,init] 108 Initializing 'java/io/BufferedOutputStream'(no method) (0x0000000800018568)
[0.629s][info][class,init] 109 Initializing 'java/nio/charset/Charset' (0x000000080009e0a0)
[0.629s][info][class,init] 110 Initializing 'java/nio/charset/spi/CharsetProvider'(no method) (0x00000008001f45c8)
[0.629s][info][class,init] 111 Initializing 'sun/nio/cs/StandardCharsets' (0x00000008001f47e0)
[0.629s][info][class,init] 112 Initializing 'java/lang/ThreadLocal' (0x0000000800027d28)
[0.630s][info][class,init] 113 Initializing 'java/util/concurrent/atomic/AtomicInteger' (0x0000000800027f70)
[0.630s][info][class,init] 114 Initializing 'sun/nio/cs/Unicode'(no method) (0x000000080009eba8)
[0.630s][info][class,init] 115 Initializing 'sun/nio/cs/UTF_8' (0x000000080009ee28)
[0.631s][info][class,init] 116 Initializing 'java/io/Writer'(no method) (0x00000008000fa5e0)
[0.631s][info][class,init] 117 Initializing 'java/io/OutputStreamWriter'(no method) (0x00000008000fb258)
[0.631s][info][class,init] 118 Initializing 'sun/nio/cs/StreamEncoder' (0x00000008000fc1e0)
[0.632s][info][class,init] 119 Initializing 'java/nio/charset/CharsetEncoder' (0x00000008000f98c0)
[0.632s][info][class,init] 120 Initializing 'sun/nio/cs/UTF_8$Encoder'(no method) (0x00000008010403e0)
[0.632s][info][class,init] 121 Initializing 'java/nio/charset/CodingErrorAction' (0x00000008000b6120)
[0.633s][info][class,init] 122 Initializing 'java/nio/Buffer' (0x000000080007e418)
[0.635s][info][class,init] 123 Initializing 'jdk/internal/misc/ScopedMemoryAccess' (0x00000008000b52a8)
[0.636s][info][class,init] 124 Initializing 'java/nio/Buffer$1'(no method) (0x00000008001d5338)
[0.636s][info][class,init] 125 Initializing 'java/nio/ByteBuffer' (0x0000000800084418)
[0.637s][info][class,init] 126 Initializing 'java/nio/HeapByteBuffer' (0x0000000800207160)
[0.637s][info][class,init] 127 Initializing 'java/nio/ByteOrder' (0x000000080001bf60)
[0.638s][info][class,init] 128 Initializing 'java/io/BufferedWriter' (0x000000080001c170)
[0.638s][info][class,init] 129 Initializing 'java/lang/Terminator' (0x000000080001bd58)
[0.638s][info][class,init] 130 Initializing 'java/lang/Terminator$1'(no method) (0x0000000800091328)
[0.638s][info][class,init] 131 Initializing 'jdk/internal/misc/Signal' (0x0000000800091118)
[0.639s][info][class,init] 132 Initializing 'java/util/Hashtable$Entry'(no method) (0x0000000800188278)
[0.639s][info][class,init] 133 Initializing 'jdk/internal/misc/Signal$Handler' (0x0000000800091550)
[0.639s][info][class,init] 134 Initializing 'jdk/internal/misc/Signal$NativeHandler'(no method) (0x000000080020dd80)
[0.639s][info][class,init] 135 Initializing 'jdk/internal/misc/OSEnvironment'(no method) (0x0000000800037dc8)
[0.640s][info][class,init] 136 Initializing 'java/lang/Throwable' (0x00000008000339d8)
[0.640s][info][class,init] 137 Initializing 'java/util/Collections' (0x0000000800037bc0)
[0.640s][info][class,init] 138 Initializing 'java/util/Collections$EmptySet'(no method) (0x000000080011d2e0)
[0.640s][info][class,init] 139 Initializing 'java/util/AbstractList'(no method) (0x000000080008e660)
[0.640s][info][class,init] 140 Initializing 'java/util/Collections$EmptyList'(no method) (0x00000008001c97d0)
[0.641s][info][class,init] 141 Initializing 'java/util/Collections$EmptyMap'(no method) (0x0000000800058498)
[0.641s][info][class,init] 142 Initializing 'java/lang/Error'(no method) (0x0000000800035558)
[0.641s][info][class,init] 143 Initializing 'java/lang/VirtualMachineError'(no method) (0x00000008000357b8)
[0.641s][info][class,init] 144 Initializing 'java/lang/OutOfMemoryError'(no method) (0x0000000800099da8)
[0.641s][info][class,init] 145 Initializing 'java/lang/Exception'(no method) (0x0000000800033c38)
[0.641s][info][class,init] 146 Initializing 'java/lang/RuntimeException'(no method) (0x0000000800034e08)
[0.641s][info][class,init] 147 Initializing 'java/lang/NullPointerException'(no method) (0x0000000800099950)
[0.641s][info][class,init] 148 Initializing 'java/lang/ClassCastException'(no method) (0x000000080009a5f8)
[0.641s][info][class,init] 149 Initializing 'java/lang/ArrayStoreException'(no method) (0x0000000800035ed8)
[0.641s][info][class,init] 150 Initializing 'java/lang/ArithmeticException'(no method) (0x00000008000996f0)
[0.641s][info][class,init] 151 Initializing 'java/lang/StackOverflowError'(no method) (0x0000000800035a18)
[0.641s][info][class,init] 152 Initializing 'java/lang/IllegalMonitorStateException'(no method) (0x00000008000570e0)
[0.641s][info][class,init] 153 Initializing 'java/lang/IllegalArgumentException'(no method) (0x0000000800035068)
[0.643s][info][class,init] 154 Initializing 'java/lang/invoke/MethodHandle' (0x00000008000c8200)
[0.644s][info][class,init] 155 Initializing 'java/lang/invoke/MethodHandleStatics' (0x000000080001e260)
[0.644s][info][class,init] 156 Initializing 'sun/security/action/GetPropertyAction'(no method) (0x00000008000fa3a8)
[0.644s][info][class,init] 157 Initializing 'java/lang/Boolean' (0x0000000800038f10)
[0.645s][info][class,init] 158 Initializing 'java/lang/invoke/ResolvedMethodName'(no method) (0x00000008000e1fc0)
[0.645s][info][class,init] 159 Initializing 'java/lang/invoke/MethodHandleNatives' (0x00000008000e22b0)
[0.645s][info][class,init] 160 Initializing 'jdk/internal/module/ModuleBootstrap' (0x000000080001e058)
[0.646s][info][class,init] 161 Initializing 'sun/invoke/util/VerifyAccess' (0x000000080007a938)
[0.646s][info][class,init] 162 Initializing 'java/lang/reflect/Modifier'(no method) (0x000000080007a730)
[0.647s][info][class,init] 163 Initializing 'java/lang/module/ModuleDescriptor' (0x000000080013a608)
[0.647s][info][class,init] 164 Initializing 'java/lang/module/ModuleDescriptor$1'(no method) (0x000000080007a258)
[0.647s][info][class,init] 165 Initializing 'java/io/File' (0x0000000800079ec0)
[0.648s][info][class,init] 166 Initializing 'java/io/DefaultFileSystem'(no method) (0x00000008000afa80)
[0.648s][info][class,init] 167 Initializing 'java/io/FileSystem' (0x00000008000adb08)
[0.648s][info][class,init] 168 Initializing 'java/io/UnixFileSystem' (0x00000008000addf0)
[0.649s][info][class,init] 169 Initializing 'java/lang/AbstractStringBuilder' (0x000000080006c268)
[0.649s][info][class,init] 170 Initializing 'java/lang/StringBuilder'(no method) (0x000000080000f478)
[0.650s][info][class,init] 171 Initializing 'jdk/internal/util/ArraysSupport' (0x00000008000ad900)
[0.650s][info][class,init] 172 Initializing 'jdk/internal/module/ModulePatcher' (0x00000008001945b0)
[0.651s][info][class,init] 173 Initializing 'jdk/internal/module/ModuleBootstrap$Counters' (0x0000000800192aa8)
[0.651s][info][class,init] 174 Initializing 'jdk/internal/module/ArchivedBootLayer' (0x0000000800192890)
[0.651s][info][class,init] 175 Initializing 'java/lang/ModuleLayer' (0x0000000800175c40)
[0.651s][info][class,init] 176 Initializing 'java/lang/module/Configuration' (0x000000080018e820)
[0.918s][info][class,init] 177 Initializing 'jdk/internal/loader/AbstractClassLoaderValue' (0x000000080018eeb0)
[0.918s][info][class,init] 178 Initializing 'jdk/internal/loader/ClassLoaderValue'(no method) (0x000000080018f0f8)
[0.918s][info][class,init] 179 Initializing 'java/util/ImmutableCollections$List12'(no method) (0x000000080008cb40)
[0.918s][info][class,init] 180 Initializing 'java/lang/module/ResolvedModule'(no method) (0x00000008001917c8)
[0.918s][info][class,init] 181 Initializing 'java/lang/module/ModuleReference'(no method) (0x00000008000d1f40)
[0.918s][info][class,init] 182 Initializing 'jdk/internal/module/ModuleReferenceImpl'(no method) (0x000000080018bf00)
[0.918s][info][class,init] 183 Initializing 'java/lang/module/ModuleDescriptor$Version'(no method) (0x000000080018ceb8)
[0.918s][info][class,init] 184 Initializing 'java/util/ArrayList' (0x000000080000dea8)
[0.919s][info][class,init] 185 Initializing 'java/lang/module/ModuleDescriptor$Requires' (0x0000000800178b80)
[0.919s][info][class,init] 186 Initializing 'java/lang/Enum'(no method) (0x0000000800007880)
[0.919s][info][class,init] 187 Initializing 'java/lang/module/ModuleDescriptor$Requires$Modifier' (0x0000000800094980)
[0.919s][info][class,init] 188 Initializing 'java/lang/module/ModuleDescriptor$Exports'(no method) (0x0000000800178958)
[0.919s][info][class,init] 189 Initializing 'java/lang/module/ModuleDescriptor$Provides'(no method) (0x000000080018d0e0)
[0.919s][info][class,init] 190 Initializing 'java/net/URI' (0x0000000800192228)
[0.920s][info][class,init] 191 Initializing 'java/net/URI$1'(no method) (0x000000080022bb10)
[0.920s][info][class,init] 192 Initializing 'jdk/internal/module/SystemModuleFinders$2'(no method) (0x000000080018bcc8)
[0.920s][info][class,init] 193 Initializing 'jdk/internal/module/SystemModuleFinders$3'(no method) (0x00000008001947c0)
[0.920s][info][class,init] 194 Initializing 'jdk/internal/module/ModuleTarget'(no method) (0x0000000800225ca0)
[0.920s][info][class,init] 195 Initializing 'jdk/internal/module/ModuleHashes'(no method) (0x00000008001941a0)
[0.920s][info][class,init] 196 Initializing 'java/util/Collections$UnmodifiableMap'(no method) (0x0000000800213c70)
[0.920s][info][class,init] 197 Initializing 'java/lang/module/ModuleDescriptor$Opens'(no method) (0x0000000800178730)
[0.920s][info][class,init] 198 Initializing 'java/util/HashSet' (0x000000080011cac8)
[0.920s][info][class,init] 199 Initializing 'java/lang/ClassLoader' (0x0000000800008e70)
[0.921s][info][class,init] 200 Initializing 'java/security/SecureClassLoader' (0x0000000800009450)
[0.921s][info][class,init] 201 Initializing 'java/lang/ClassLoader$ParallelLoaders' (0x000000080000f270)
[0.921s][info][class,init] 202 Initializing 'java/util/WeakHashMap' (0x0000000800057948)
[0.922s][info][class,init] 203 Initializing 'java/util/Collections$SetFromMap'(no method) (0x000000080021a8c8)
[0.922s][info][class,init] 204 Initializing 'java/util/WeakHashMap$KeySet'(no method) (0x000000080017b698)
[0.922s][info][class,init] 205 Initializing 'java/lang/ref/WeakReference'(no method) (0x0000000800055a20)
[0.922s][info][class,init] 206 Initializing 'java/util/WeakHashMap$Entry'(no method) (0x00000008000576a8)
[0.923s][info][class,init] 207 Initializing 'jdk/internal/loader/BuiltinClassLoader' (0x0000000800009748)
[0.923s][info][class,init] 208 Initializing 'jdk/internal/loader/ArchivedClassLoaders' (0x00000008001bda48)
[0.923s][info][class,init] 209 Initializing 'jdk/internal/loader/ClassLoaders$BootClassLoader'(no method) (0x00000008001be2c8)
[0.923s][info][class,init] 210 Initializing 'java/security/ProtectionDomain' (0x000000080000ec18)
[0.923s][info][class,init] 211 Initializing 'java/security/ProtectionDomain$JavaSecurityAccessImpl'(no method) (0x000000080017b240)
[0.923s][info][class,init] 212 Initializing 'java/security/CodeSource'(no method) (0x000000080000ee38)
[0.923s][info][class,init] 213 Initializing 'java/security/Principal'(no method) (0x000000080017be08)
[0.923s][info][class,init] 214 Initializing 'java/security/ProtectionDomain$Key'(no method) (0x000000080017b038)
[0.923s][info][class,init] 215 Initializing 'jdk/internal/loader/NativeLibraries' (0x000000080000f060)
[0.924s][info][class,init] 216 Initializing 'java/util/ArrayDeque'(no method) (0x0000000800169620)
[0.924s][info][class,init] 217 Initializing 'jdk/internal/module/ServicesCatalog' (0x000000080013cb28)
[0.924s][info][class,init] 218 Initializing 'java/util/concurrent/CopyOnWriteArrayList'(no method) (0x0000000800231220)
[0.924s][info][class,init] 219 Initializing 'jdk/internal/module/ServicesCatalog$ServiceProvider'(no method) (0x0000000800231730)
[0.924s][info][class,init] 220 Initializing 'jdk/internal/loader/ClassLoaders$PlatformClassLoader' (0x00000008000990b8)
[0.924s][info][class,init] 221 Initializing 'jdk/internal/loader/BuiltinClassLoader$LoadedModule'(no method) (0x000000080018ec80)
[1.051s][info][class,init] 222 Initializing 'jdk/internal/loader/ClassLoaders$AppClassLoader' (0x0000000800096cc0)
[1.176s][info][class,init] 223 Initializing 'jdk/internal/loader/BootLoader' (0x000000080013c1d8)
[1.176s][info][class,init] 224 Initializing 'jdk/internal/loader/ClassLoaders' (0x000000080000ff38)
[1.177s][info][class,init] 225 Initializing 'jdk/internal/loader/URLClassPath' (0x00000008001b60c8)
[1.178s][info][class,init] 226 Initializing 'java/net/URL' (0x0000000800075b88)
[1.178s][info][class,init] 227 Initializing 'java/net/URL$DefaultFactory' (0x0000000800094250)
[1.178s][info][class,init] 228 Initializing 'java/net/URL$3'(no method) (0x0000000800093e28)
[1.179s][info][class,init] 229 Initializing 'java/io/File$PathStatus' (0x0000000800094738)
[1.180s][info][class,init] 230 Initializing 'sun/net/www/ParseUtil' (0x0000000800093c20)
[1.180s][info][class,init] 231 Initializing 'java/util/HexFormat' (0x0000000800096088)
[1.181s][info][class,init] 232 Initializing 'java/net/URLStreamHandler'(no method) (0x00000008001b3148)
[1.181s][info][class,init] 233 Initializing 'sun/net/www/protocol/file/Handler'(no method) (0x00000008001b38f8)
[1.182s][info][class,init] 234 Initializing 'sun/net/util/IPAddressUtil' (0x0000000800090688)
[1.183s][info][class,init] 235 Initializing 'jdk/internal/util/Preconditions'(no method) (0x0000000800090480)
[1.184s][info][class,init] 236 Initializing 'java/lang/invoke/StringConcatFactory' (0x000000080001e468)
[1.185s][info][class,init] 237 Initializing 'java/util/function/Function'(no method) (0x00000008001151e8)
[1.185s][info][class,init] 238 Initializing 'java/lang/invoke/StringConcatFactory$1'(no method) (0x0000000800235200)
[1.185s][info][class,init] 239 Initializing 'java/lang/invoke/StringConcatFactory$2'(no method) (0x0000000800235770)
[1.185s][info][class,init] 240 Initializing 'java/lang/invoke/StringConcatFactory$3'(no method) (0x0000000800043b98)
[1.187s][info][class,init] 241 Initializing 'java/nio/CharBuffer' (0x0000000800081918)
[1.187s][info][class,init] 242 Initializing 'java/nio/HeapCharBuffer' (0x0000000800081f90)
[1.188s][info][class,init] 243 Initializing 'java/nio/charset/CoderResult' (0x00000008000b5a90)
openjdk version "18-internal" 2022-03-15
OpenJDK Runtime Environment (slowdebug build 18-internal+0-adhoc.qingfengyy.jdktip)
OpenJDK 64-Bit Server VM (slowdebug build 18-internal+0-adhoc.qingfengyy.jdktip, mixed mode, sharing)
[1.192s][info][class,init] 244 Initializing 'java/lang/Shutdown' (0x0000000800050c98)
[1.192s][info][class,init] 245 Initializing 'java/lang/Shutdown$Lock'(no method) (0x00000008000264d8)

$./java -Xlog:class+init -version
[0.020s][info][class,init] 0 Initializing java/lang/Object'java/lang/Object'(no method) (0x0000000800000d68)
[0.020s][info][class,init] 1 Initializing java/lang/CharSequence'java/lang/CharSequence'(no method) (0x0000000800065478)
[0.020s][info][class,init] 2 Initializing java/lang/String'java/lang/String' (0x000000080000e4a0)
[0.020s][info][class,init] 3 Initializing java/util/Comparator'java/util/Comparator'(no method) (0x00000008000ea748)
[0.020s][info][class,init] 4 Initializing java/lang/String$CaseInsensitiveComparator'java/lang/String$CaseInsensitiveComparator'(no method) (0x000000080011ba70)
[0.020s][info][class,init] 5 Initializing java/lang/System'java/lang/System' (0x00000008000088f8)
[0.020s][info][class,init] 6 Initializing java/lang/reflect/AnnotatedElement'java/lang/reflect/AnnotatedElement'(no method) (0x0000000800001eb0)
[0.020s][info][class,init] 7 Initializing java/lang/reflect/Type'java/lang/reflect/Type'(no method) (0x00000008000027e0)
[0.020s][info][class,init] 8 Initializing java/lang/Class'java/lang/Class' (0x0000000800001750)
[0.020s][info][class,init] 9 Initializing java/lang/ThreadGroup'java/lang/ThreadGroup'(no method) (0x000000080001c1e8)
[0.020s][info][class,init] 10 Initializing java/lang/Thread'java/lang/Thread' (0x000000080001b3d0)
[0.020s][info][class,init] 11 Initializing java/security/AccessController'java/security/AccessController' (0x0000000800009738)
[0.020s][info][class,init] 12 Initializing java/security/AccessControlContext'java/security/AccessControlContext' (0x000000080006d2c8)
[0.020s][info][class,init] 13 Initializing java/lang/Module'java/lang/Module' (0x000000080000b5c0)
[0.021s][info][class,init] 14 Initializing java/lang/Module$ArchivedData'java/lang/Module$ArchivedData' (0x0000000800186270)
[0.021s][info][class,init] 15 Initializing jdk/internal/misc/CDS'jdk/internal/misc/CDS' (0x0000000800017d08)
[0.021s][info][class,init] 16 Initializing java/lang/Iterable'java/lang/Iterable'(no method) (0x0000000800082f10)
[0.021s][info][class,init] 17 Initializing java/util/Collection'java/util/Collection'(no method) (0x0000000800083118)
[0.021s][info][class,init] 18 Initializing java/util/AbstractCollection'java/util/AbstractCollection'(no method) (0x00000008000357c8)
[0.021s][info][class,init] 19 Initializing java/util/ImmutableCollections$AbstractImmutableCollection'java/util/ImmutableCollections$AbstractImmutableCollection'(no method) (0x00000008000833d0)
[0.021s][info][class,init] 20 Initializing java/util/Set'java/util/Set'(no method) (0x0000000800017b00)
[0.021s][info][class,init] 21 Initializing java/util/ImmutableCollections$AbstractImmutableSet'java/util/ImmutableCollections$AbstractImmutableSet'(no method) (0x0000000800084108)
[0.021s][info][class,init] 22 Initializing java/util/ImmutableCollections$Set12'java/util/ImmutableCollections$Set12'(no method) (0x0000000800082af8)
[0.021s][info][class,init] 23 Initializing jdk/internal/misc/UnsafeConstants'jdk/internal/misc/UnsafeConstants' (0x00000008000a7ff0)
[0.021s][info][class,init] 24 Initializing java/lang/reflect/AccessibleObject'java/lang/reflect/AccessibleObject' (0x0000000800056450)
[0.021s][info][class,init] 25 Initializing java/lang/reflect/ReflectAccess'java/lang/reflect/ReflectAccess'(no method) (0x0000000800012c50)
[0.021s][info][class,init] 26 Initializing jdk/internal/access/SharedSecrets'jdk/internal/access/SharedSecrets' (0x0000000800012a40)
[0.021s][info][class,init] 27 Initializing java/lang/invoke/MethodHandles'java/lang/invoke/MethodHandles' (0x000000080011c780)
[0.021s][info][class,init] 28 Initializing java/lang/invoke/MemberName'java/lang/invoke/MemberName' (0x00000008000cdbb8)
[0.021s][info][class,init] 29 Initializing java/lang/invoke/MemberName$Factory'java/lang/invoke/MemberName$Factory' (0x0000000800021bb0)
[0.021s][info][class,init] 30 Initializing java/security/Permission'java/security/Permission'(no method) (0x0000000800021758)
[0.021s][info][class,init] 31 Initializing java/security/BasicPermission'java/security/BasicPermission'(no method) (0x0000000800024338)
[0.021s][info][class,init] 32 Initializing java/lang/reflect/ReflectPermission'java/lang/reflect/ReflectPermission'(no method) (0x00000008000240e0)
[0.021s][info][class,init] 33 Initializing java/lang/StringLatin1'java/lang/StringLatin1' (0x0000000800021548)
[0.022s][info][class,init] 34 Initializing java/lang/invoke/MethodHandles$Lookup'java/lang/invoke/MethodHandles$Lookup' (0x00000008000d2af8)
[0.022s][info][class,init] 35 Initializing java/util/Objects'java/util/Objects'(no method) (0x00000008000828e8)
[0.022s][info][class,init] 36 Initializing jdk/internal/reflect/Reflection'jdk/internal/reflect/Reflection' (0x000000080000f688)
[0.022s][info][class,init] 37 Initializing java/util/ImmutableCollections'java/util/ImmutableCollections' (0x0000000800084518)
[0.022s][info][class,init] 38 Initializing java/util/List'java/util/List'(no method) (0x0000000800085330)
[0.022s][info][class,init] 39 Initializing java/util/ImmutableCollections$AbstractImmutableList'java/util/ImmutableCollections$AbstractImmutableList'(no method) (0x0000000800083750)
[0.022s][info][class,init] 40 Initializing java/util/ImmutableCollections$ListN'java/util/ImmutableCollections$ListN'(no method) (0x0000000800170ea0)
[0.022s][info][class,init] 41 Initializing java/util/ImmutableCollections$SetN'java/util/ImmutableCollections$SetN'(no method) (0x0000000800170a88)
[0.022s][info][class,init] 42 Initializing java/util/Map'java/util/Map'(no method) (0x00000008000174b0)
[0.022s][info][class,init] 43 Initializing java/util/AbstractMap'java/util/AbstractMap'(no method) (0x0000000800052fb8)
[0.022s][info][class,init] 44 Initializing java/util/ImmutableCollections$AbstractImmutableMap'java/util/ImmutableCollections$AbstractImmutableMap'(no method) (0x00000008001706e0)
[0.022s][info][class,init] 45 Initializing java/util/ImmutableCollections$MapN'java/util/ImmutableCollections$MapN'(no method) (0x0000000800172340)
[0.022s][info][class,init] 46 Initializing java/lang/Math'java/lang/Math' (0x0000000800025dc8)
[0.022s][info][class,init] 47 Initializing java/lang/Number'java/lang/Number'(no method) (0x000000080003cc38)
[0.022s][info][class,init] 48 Initializing java/lang/Float'java/lang/Float' (0x0000000800044c98)
[0.022s][info][class,init] 49 Initializing java/lang/Double'java/lang/Double' (0x0000000800046560)
[0.022s][info][class,init] 50 Initializing java/util/HashMap'java/util/HashMap'(no method) (0x00000008000efe78)
[0.022s][info][class,init] 51 Initializing java/lang/Integer'java/lang/Integer' (0x0000000800047a18)
[0.022s][info][class,init] 52 Initializing java/util/AbstractSet'java/util/AbstractSet'(no method) (0x0000000800109688)
[0.022s][info][class,init] 53 Initializing java/util/ImmutableCollections$MapN$1'java/util/ImmutableCollections$MapN$1'(no method) (0x00000008001c28d8)
[0.022s][info][class,init] 54 Initializing java/util/Iterator'java/util/Iterator'(no method) (0x0000000800004680)
[0.022s][info][class,init] 55 Initializing java/util/ImmutableCollections$MapN$MapNIterator'java/util/ImmutableCollections$MapN$MapNIterator'(no method) (0x00000008000183c8)
[0.022s][info][class,init] 56 Initializing java/util/KeyValueHolder'java/util/KeyValueHolder'(no method) (0x0000000800155370)
[0.022s][info][class,init] 57 Initializing java/util/HashMap$Node'java/util/HashMap$Node'(no method) (0x0000000800154778)
[0.023s][info][class,init] 58 Initializing java/util/concurrent/ConcurrentMap'java/util/concurrent/ConcurrentMap'(no method) (0x000000080016d3b0)
[0.023s][info][class,init] 59 Initializing java/util/concurrent/ConcurrentHashMap'java/util/concurrent/ConcurrentHashMap' (0x000000080000def0)
[0.023s][info][class,init] 60 Initializing java/lang/Runtime'java/lang/Runtime' (0x00000008001544c8)
[0.023s][info][class,init] 61 Initializing java/io/ObjectStreamField'java/io/ObjectStreamField'(no method) (0x00000008000ea950)
[0.023s][info][class,init] 62 Initializing jdk/internal/misc/Unsafe'jdk/internal/misc/Unsafe' (0x000000080000fcb8)
[0.023s][info][class,init] 63 Initializing jdk/internal/reflect/ReflectionFactory$GetReflectionFactoryAction'jdk/internal/reflect/ReflectionFactory$GetReflectionFactoryAction'(no method) (0x00000008001308b8)
[0.023s][info][class,init] 64 Initializing jdk/internal/reflect/ReflectionFactory'jdk/internal/reflect/ReflectionFactory' (0x00000008000556c0)
[0.023s][info][class,init] 65 Initializing java/lang/ref/Reference'java/lang/ref/Reference' (0x000000080004e880)
[0.023s][info][class,init] 66 Initializing java/lang/ref/Reference$ReferenceHandler'java/lang/ref/Reference$ReferenceHandler' (0x000000080004ff10)
[0.023s][info][class,init] 67 Initializing java/lang/ref/PhantomReference'java/lang/ref/PhantomReference'(no method) (0x000000080004ead0)
[0.023s][info][class,init] 68 Initializing jdk/internal/ref/Cleaner'jdk/internal/ref/Cleaner' (0x000000080004fcb0)
[0.023s][info][class,init] 69 Initializing java/lang/ref/ReferenceQueue'java/lang/ref/ReferenceQueue' (0x0000000800055228)
[0.023s][info][class,init] 70 Initializing java/lang/ref/ReferenceQueue$Null'java/lang/ref/ReferenceQueue$Null'(no method) (0x0000000800055470)
[0.023s][info][class,init] 71 Initializing java/lang/ref/ReferenceQueue$Lock'java/lang/ref/ReferenceQueue$Lock'(no method) (0x00000008001d49d8)
[0.023s][info][class,init] 72 Initializing java/lang/ref/Reference$1'java/lang/ref/Reference$1'(no method) (0x0000000800055af8)
[0.023s][info][class,init] 73 Initializing java/lang/reflect/Executable'java/lang/reflect/Executable'(no method) (0x0000000800056718)
[0.023s][info][class,init] 74 Initializing java/lang/reflect/Method'java/lang/reflect/Method'(no method) (0x00000008000573d0)
[0.023s][info][class,init] 75 Initializing java/lang/ref/FinalReference'java/lang/ref/FinalReference'(no method) (0x0000000800050768)
[0.023s][info][class,init] 76 Initializing java/lang/ref/Finalizer'java/lang/ref/Finalizer' (0x00000008000509b8)
[0.023s][info][class,init] 77 Initializing java/lang/ref/Finalizer$FinalizerThread'java/lang/ref/Finalizer$FinalizerThread'(no method) (0x00000008000d2f70)
[0.024s][info][class,init] 78 Initializing java/lang/System$2'java/lang/System$2'(no method) (0x0000000800014f90)
[0.024s][info][class,init] 79 Initializing jdk/internal/util/SystemProps'jdk/internal/util/SystemProps' (0x0000000800014d80)
[0.024s][info][class,init] 80 Initializing jdk/internal/misc/VM'jdk/internal/misc/VM' (0x000000080000f898)
[0.024s][info][class,init] 81 Initializing jdk/internal/util/SystemProps$Raw'jdk/internal/util/SystemProps$Raw'(no method) (0x0000000800094718)
[0.024s][info][class,init] 82 Initializing java/lang/StringConcatHelper'java/lang/StringConcatHelper' (0x0000000800015740)
[0.024s][info][class,init] 83 Initializing java/lang/Byte'java/lang/Byte' (0x000000080003d268)
[0.024s][info][class,init] 84 Initializing java/lang/VersionProps'java/lang/VersionProps' (0x0000000800015530)
[0.024s][info][class,init] 85 Initializing java/util/Arrays'java/util/Arrays' (0x0000000800025fd8)
[0.025s][info][class,init] 86 Initializing java/lang/Character'java/lang/Character' (0x000000080003b0f0)
[0.025s][info][class,init] 87 Initializing java/lang/CharacterData'java/lang/CharacterData'(no method) (0x0000000800041218)
[0.025s][info][class,init] 88 Initializing java/lang/CharacterDataLatin1'java/lang/CharacterDataLatin1' (0x0000000800040ea0)
[0.025s][info][class,init] 89 Initializing java/lang/Integer$IntegerCache'java/lang/Integer$IntegerCache' (0x000000080003ca28)
[0.025s][info][class,init] 90 Initializing java/util/Dictionary'java/util/Dictionary'(no method) (0x0000000800015db8)
[0.025s][info][class,init] 91 Initializing java/util/Hashtable'java/util/Hashtable'(no method) (0x0000000800016000)
[0.025s][info][class,init] 92 Initializing java/util/Properties'java/util/Properties' (0x0000000800015950)
[0.025s][info][class,init] 93 Initializing java/util/HashMap$EntrySet'java/util/HashMap$EntrySet'(no method) (0x00000008001d1a30)
[0.025s][info][class,init] 94 Initializing java/util/HashMap$HashIterator'java/util/HashMap$HashIterator'(no method) (0x0000000800018af0)
[0.025s][info][class,init] 95 Initializing java/util/HashMap$EntryIterator'java/util/HashMap$EntryIterator'(no method) (0x0000000800018d08)
[0.025s][info][class,init] 96 Initializing java/util/concurrent/ConcurrentHashMap$Node'java/util/concurrent/ConcurrentHashMap$Node'(no method) (0x00000008001a2628)
[0.025s][info][class,init] 97 Initializing jdk/internal/util/StaticProperty'jdk/internal/util/StaticProperty' (0x00000008000188e0)
[0.025s][info][class,init] 98 Initializing java/io/InputStream'java/io/InputStream'(no method) (0x0000000800019218)
[0.025s][info][class,init] 99 Initializing java/io/FileInputStream'java/io/FileInputStream' (0x0000000800018f58)
[0.025s][info][class,init] 100 Initializing java/io/FileDescriptor'java/io/FileDescriptor' (0x0000000800019ca8)
[0.025s][info][class,init] 101 Initializing java/io/FileDescriptor$1'java/io/FileDescriptor$1'(no method) (0x00000008001ddf68)
[0.025s][info][class,init] 102 Initializing java/io/OutputStream'java/io/OutputStream'(no method) (0x0000000800013348)
[0.025s][info][class,init] 103 Initializing java/io/FileOutputStream'java/io/FileOutputStream' (0x0000000800019ec0)
[0.025s][info][class,init] 104 Initializing java/io/FilterInputStream'java/io/FilterInputStream'(no method) (0x000000080001a620)
[0.025s][info][class,init] 105 Initializing java/io/BufferedInputStream'java/io/BufferedInputStream' (0x000000080001a360)
[0.025s][info][class,init] 106 Initializing java/io/FilterOutputStream'java/io/FilterOutputStream'(no method) (0x00000008000135c8)
[0.025s][info][class,init] 107 Initializing java/io/PrintStream'java/io/PrintStream'(no method) (0x0000000800012f90)
[0.025s][info][class,init] 108 Initializing java/io/BufferedOutputStream'java/io/BufferedOutputStream'(no method) (0x00000008000176b8)
[0.026s][info][class,init] 109 Initializing java/nio/charset/Charset'java/nio/charset/Charset' (0x00000008000944b0)
[0.026s][info][class,init] 110 Initializing java/nio/charset/spi/CharsetProvider'java/nio/charset/spi/CharsetProvider'(no method) (0x00000008001d5290)
[0.026s][info][class,init] 111 Initializing sun/nio/cs/StandardCharsets'sun/nio/cs/StandardCharsets' (0x00000008001d54b0)
[0.026s][info][class,init] 112 Initializing java/lang/ThreadLocal'java/lang/ThreadLocal' (0x00000008000261e8)
[0.026s][info][class,init] 113 Initializing java/util/concurrent/atomic/AtomicInteger'java/util/concurrent/atomic/AtomicInteger' (0x0000000800026438)
[0.026s][info][class,init] 114 Initializing sun/nio/cs/Unicode'sun/nio/cs/Unicode'(no method) (0x0000000800094f30)
[0.026s][info][class,init] 115 Initializing sun/nio/cs/UTF_8'sun/nio/cs/UTF_8' (0x00000008000951b8)
[0.026s][info][class,init] 116 Initializing java/io/Writer'java/io/Writer'(no method) (0x00000008000e7ae0)
[0.026s][info][class,init] 117 Initializing java/io/OutputStreamWriter'java/io/OutputStreamWriter'(no method) (0x00000008000e8660)
[0.026s][info][class,init] 118 Initializing sun/nio/cs/StreamEncoder'sun/nio/cs/StreamEncoder' (0x00000008000e9490)
[0.026s][info][class,init] 119 Initializing java/nio/charset/CharsetEncoder'java/nio/charset/CharsetEncoder' (0x00000008000e6e98)
[0.026s][info][class,init] 120 Initializing sun/nio/cs/UTF_8$Encoder'sun/nio/cs/UTF_8$Encoder'(no method) (0x0000000800c403f0)
[0.026s][info][class,init] 121 Initializing java/nio/charset/CodingErrorAction'java/nio/charset/CodingErrorAction' (0x00000008000a9278)
[0.026s][info][class,init] 122 Initializing java/nio/Buffer'java/nio/Buffer' (0x00000008000767a8)
[0.027s][info][class,init] 123 Initializing jdk/internal/misc/ScopedMemoryAccess'jdk/internal/misc/ScopedMemoryAccess' (0x00000008000a83e0)
[0.027s][info][class,init] 124 Initializing java/nio/Buffer$1'java/nio/Buffer$1'(no method) (0x00000008001b7460)
[0.027s][info][class,init] 125 Initializing java/nio/ByteBuffer'java/nio/ByteBuffer' (0x000000080007c050)
[0.027s][info][class,init] 126 Initializing java/nio/HeapByteBuffer'java/nio/HeapByteBuffer' (0x00000008001e5660)
[0.027s][info][class,init] 127 Initializing java/nio/ByteOrder'java/nio/ByteOrder' (0x000000080001aeb0)
[0.027s][info][class,init] 128 Initializing java/io/BufferedWriter'java/io/BufferedWriter' (0x000000080001b0c8)
[0.027s][info][class,init] 129 Initializing java/lang/Terminator'java/lang/Terminator' (0x000000080001aca0)
[0.027s][info][class,init] 130 Initializing java/lang/Terminator$1'java/lang/Terminator$1'(no method) (0x0000000800087e58)
[0.027s][info][class,init] 131 Initializing jdk/internal/misc/Signal'jdk/internal/misc/Signal' (0x0000000800087c40)
[0.027s][info][class,init] 132 Initializing java/util/Hashtable$Entry'java/util/Hashtable$Entry'(no method) (0x000000080016e1d8)
[0.027s][info][class,init] 133 Initializing jdk/internal/misc/Signal$Handler'jdk/internal/misc/Signal$Handler' (0x0000000800088088)
[0.027s][info][class,init] 134 Initializing jdk/internal/misc/Signal$NativeHandler'jdk/internal/misc/Signal$NativeHandler'(no method) (0x00000008001eb878)
[0.027s][info][class,init] 135 Initializing jdk/internal/misc/OSEnvironment'jdk/internal/misc/OSEnvironment'(no method) (0x00000008000353a0)
[0.027s][info][class,init] 136 Initializing java/lang/Throwable'java/lang/Throwable' (0x00000008000310c0)
[0.027s][info][class,init] 137 Initializing java/util/Collections'java/util/Collections' (0x0000000800035190)
[0.027s][info][class,init] 138 Initializing java/util/Collections$EmptySet'java/util/Collections$EmptySet'(no method) (0x0000000800109a98)
[0.027s][info][class,init] 139 Initializing java/util/AbstractList'java/util/AbstractList'(no method) (0x0000000800085538)
[0.027s][info][class,init] 140 Initializing java/util/Collections$EmptyList'java/util/Collections$EmptyList'(no method) (0x00000008001acf38)
[0.027s][info][class,init] 141 Initializing java/util/Collections$EmptyMap'java/util/Collections$EmptyMap'(no method) (0x0000000800053758)
[0.027s][info][class,init] 142 Initializing java/lang/Error'java/lang/Error'(no method) (0x0000000800032b90)
[0.027s][info][class,init] 143 Initializing java/lang/VirtualMachineError'java/lang/VirtualMachineError'(no method) (0x0000000800032df8)
[0.027s][info][class,init] 144 Initializing java/lang/OutOfMemoryError'java/lang/OutOfMemoryError'(no method) (0x0000000800090428)
[0.027s][info][class,init] 145 Initializing java/lang/Exception'java/lang/Exception'(no method) (0x0000000800031328)
[0.027s][info][class,init] 146 Initializing java/lang/RuntimeException'java/lang/RuntimeException'(no method) (0x0000000800032470)
[0.027s][info][class,init] 147 Initializing java/lang/NullPointerException'java/lang/NullPointerException'(no method) (0x000000080008ffc0)
[0.027s][info][class,init] 148 Initializing java/lang/ClassCastException'java/lang/ClassCastException'(no method) (0x0000000800090c18)
[0.027s][info][class,init] 149 Initializing java/lang/ArrayStoreException'java/lang/ArrayStoreException'(no method) (0x0000000800033530)
[0.027s][info][class,init] 150 Initializing java/lang/ArithmeticException'java/lang/ArithmeticException'(no method) (0x000000080008fd58)
[0.027s][info][class,init] 151 Initializing java/lang/StackOverflowError'java/lang/StackOverflowError'(no method) (0x0000000800033060)
[0.027s][info][class,init] 152 Initializing java/lang/IllegalMonitorStateException'java/lang/IllegalMonitorStateException'(no method) (0x0000000800052390)
[0.027s][info][class,init] 153 Initializing java/lang/IllegalArgumentException'java/lang/IllegalArgumentException'(no method) (0x00000008000326d8)
[0.028s][info][class,init] 154 Initializing java/lang/invoke/MethodHandle'java/lang/invoke/MethodHandle' (0x00000008000b93d0)
[0.028s][info][class,init] 155 Initializing java/lang/invoke/MethodHandleStatics'java/lang/invoke/MethodHandleStatics' (0x000000080001d020)
[0.028s][info][class,init] 156 Initializing sun/security/action/GetPropertyAction'sun/security/action/GetPropertyAction'(no method) (0x00000008000e78a0)
[0.028s][info][class,init] 157 Initializing java/lang/Boolean'java/lang/Boolean' (0x00000008000363d8)
[0.028s][info][class,init] 158 Initializing java/lang/invoke/ResolvedMethodName'java/lang/invoke/ResolvedMethodName'(no method) (0x00000008000d13b0)
[0.028s][info][class,init] 159 Initializing java/lang/invoke/MethodHandleNatives'java/lang/invoke/MethodHandleNatives' (0x00000008000d1698)
[0.028s][info][class,init] 160 Initializing jdk/internal/module/ModuleBootstrap'jdk/internal/module/ModuleBootstrap' (0x000000080001ce10)
[0.029s][info][class,init] 161 Initializing sun/invoke/util/VerifyAccess'sun/invoke/util/VerifyAccess' (0x0000000800073250)
[0.029s][info][class,init] 162 Initializing java/lang/reflect/Modifier'java/lang/reflect/Modifier'(no method) (0x0000000800073040)
[0.029s][info][class,init] 163 Initializing java/lang/module/ModuleDescriptor'java/lang/module/ModuleDescriptor' (0x0000000800124e20)
[0.029s][info][class,init] 164 Initializing java/lang/module/ModuleDescriptor$1'java/lang/module/ModuleDescriptor$1'(no method) (0x0000000800072b58)
[0.029s][info][class,init] 165 Initializing java/io/File'java/io/File' (0x00000008000727b8)
[0.029s][info][class,init] 166 Initializing java/io/DefaultFileSystem'java/io/DefaultFileSystem'(no method) (0x00000008000a4818)
[0.029s][info][class,init] 167 Initializing java/io/FileSystem'java/io/FileSystem' (0x00000008000a2b00)
[0.029s][info][class,init] 168 Initializing java/io/UnixFileSystem'java/io/UnixFileSystem' (0x00000008000a2df0)
[0.029s][info][class,init] 169 Initializing java/lang/AbstractStringBuilder'java/lang/AbstractStringBuilder' (0x0000000800065f28)
[0.029s][info][class,init] 170 Initializing java/lang/StringBuilder'java/lang/StringBuilder'(no method) (0x000000080000efc8)
[0.029s][info][class,init] 171 Initializing jdk/internal/util/ArraysSupport'jdk/internal/util/ArraysSupport' (0x00000008000a28f0)
[0.029s][info][class,init] 172 Initializing jdk/internal/module/ModulePatcher'jdk/internal/module/ModulePatcher' (0x000000080017b118)
[0.029s][info][class,init] 173 Initializing jdk/internal/module/ModuleBootstrap$Counters'jdk/internal/module/ModuleBootstrap$Counters' (0x0000000800179690)
[0.029s][info][class,init] 174 Initializing jdk/internal/module/ArchivedBootLayer'jdk/internal/module/ArchivedBootLayer' (0x0000000800179470)
[0.029s][info][class,init] 175 Initializing java/lang/ModuleLayer'java/lang/ModuleLayer' (0x000000080015d020)
[0.029s][info][class,init] 176 Initializing java/lang/module/Configuration'java/lang/module/Configuration' (0x0000000800175a90)
[0.029s][info][class,init] 177 Initializing jdk/internal/loader/AbstractClassLoaderValue'jdk/internal/loader/AbstractClassLoaderValue' (0x0000000800176138)
[0.029s][info][class,init] 178 Initializing jdk/internal/loader/ClassLoaderValue'jdk/internal/loader/ClassLoaderValue'(no method) (0x0000000800176388)
[0.029s][info][class,init] 179 Initializing java/util/ImmutableCollections$List12'java/util/ImmutableCollections$List12'(no method) (0x0000000800083c28)
[0.029s][info][class,init] 180 Initializing java/lang/module/ResolvedModule'java/lang/module/ResolvedModule'(no method) (0x0000000800178410)
[0.029s][info][class,init] 181 Initializing java/lang/module/ModuleReference'java/lang/module/ModuleReference'(no method) (0x00000008000c26a0)
[0.029s][info][class,init] 182 Initializing jdk/internal/module/ModuleReferenceImpl'jdk/internal/module/ModuleReferenceImpl'(no method) (0x0000000800173380)
[0.030s][info][class,init] 183 Initializing java/lang/module/ModuleDescriptor$Version'java/lang/module/ModuleDescriptor$Version'(no method) (0x0000000800174260)
[0.030s][info][class,init] 184 Initializing java/util/ArrayList'java/util/ArrayList' (0x000000080000d9c0)
[0.030s][info][class,init] 185 Initializing java/lang/module/ModuleDescriptor$Requires'java/lang/module/ModuleDescriptor$Requires' (0x000000080015fd68)
[0.030s][info][class,init] 186 Initializing java/lang/Enum'java/lang/Enum'(no method) (0x0000000800007540)
[0.030s][info][class,init] 187 Initializing java/lang/module/ModuleDescriptor$Requires$Modifier'java/lang/module/ModuleDescriptor$Requires$Modifier' (0x000000080008b318)
[0.030s][info][class,init] 188 Initializing java/lang/module/ModuleDescriptor$Provides'java/lang/module/ModuleDescriptor$Provides'(no method) (0x0000000800174490)
[0.030s][info][class,init] 189 Initializing java/net/URI'java/net/URI' (0x0000000800178df0)
[0.030s][info][class,init] 190 Initializing java/net/URI$1'java/net/URI$1'(no method) (0x00000008002076e8)
[0.030s][info][class,init] 191 Initializing jdk/internal/module/SystemModuleFinders$2'jdk/internal/module/SystemModuleFinders$2'(no method) (0x0000000800173140)
[0.030s][info][class,init] 192 Initializing jdk/internal/module/SystemModuleFinders$3'jdk/internal/module/SystemModuleFinders$3'(no method) (0x000000080017b330)
[0.030s][info][class,init] 193 Initializing java/lang/module/ModuleDescriptor$Exports'java/lang/module/ModuleDescriptor$Exports'(no method) (0x000000080015fb38)
[0.030s][info][class,init] 194 Initializing jdk/internal/module/ModuleTarget'jdk/internal/module/ModuleTarget'(no method) (0x0000000800201e38)
[0.030s][info][class,init] 195 Initializing jdk/internal/module/ModuleHashes'jdk/internal/module/ModuleHashes'(no method) (0x000000080017acf8)
[0.030s][info][class,init] 196 Initializing java/util/Collections$UnmodifiableMap'java/util/Collections$UnmodifiableMap'(no method) (0x00000008001f1118)
[0.030s][info][class,init] 197 Initializing java/lang/module/ModuleDescriptor$Opens'java/lang/module/ModuleDescriptor$Opens'(no method) (0x000000080015f908)
[0.030s][info][class,init] 198 Initializing java/util/HashSet'java/util/HashSet' (0x0000000800109270)
[0.030s][info][class,init] 199 Initializing java/lang/ClassLoader'java/lang/ClassLoader' (0x0000000800008b08)
[0.030s][info][class,init] 200 Initializing java/security/SecureClassLoader'java/security/SecureClassLoader' (0x00000008000090f8)
[0.030s][info][class,init] 201 Initializing java/lang/ClassLoader$ParallelLoaders'java/lang/ClassLoader$ParallelLoaders' (0x000000080000edb8)
[0.030s][info][class,init] 202 Initializing java/util/WeakHashMap'java/util/WeakHashMap' (0x0000000800052bf0)
[0.030s][info][class,init] 203 Initializing java/util/Collections$SetFromMap'java/util/Collections$SetFromMap'(no method) (0x00000008001f7808)
[0.030s][info][class,init] 204 Initializing java/util/WeakHashMap$KeySet'java/util/WeakHashMap$KeySet'(no method) (0x00000008001626b0)
[0.030s][info][class,init] 205 Initializing java/lang/ref/WeakReference'java/lang/ref/WeakReference'(no method) (0x0000000800050d80)
[0.030s][info][class,init] 206 Initializing java/util/WeakHashMap$Entry'java/util/WeakHashMap$Entry'(no method) (0x0000000800052948)
[0.030s][info][class,init] 207 Initializing jdk/internal/loader/BuiltinClassLoader'jdk/internal/loader/BuiltinClassLoader' (0x00000008000093f8)
[0.030s][info][class,init] 208 Initializing jdk/internal/loader/ArchivedClassLoaders'jdk/internal/loader/ArchivedClassLoaders' (0x00000008001a1958)
[0.030s][info][class,init] 209 Initializing jdk/internal/loader/ClassLoaders$BootClassLoader'jdk/internal/loader/ClassLoaders$BootClassLoader'(no method) (0x00000008001a2150)
[0.030s][info][class,init] 210 Initializing java/security/ProtectionDomain'java/security/ProtectionDomain' (0x000000080000e748)
[0.030s][info][class,init] 211 Initializing java/security/ProtectionDomain$JavaSecurityAccessImpl'java/security/ProtectionDomain$JavaSecurityAccessImpl'(no method) (0x0000000800162248)
[0.030s][info][class,init] 212 Initializing java/security/CodeSource'java/security/CodeSource'(no method) (0x000000080000e970)
[0.030s][info][class,init] 213 Initializing java/security/Principal'java/security/Principal'(no method) (0x0000000800162db8)
[0.030s][info][class,init] 214 Initializing java/security/ProtectionDomain$Key'java/security/ProtectionDomain$Key'(no method) (0x0000000800162038)
[0.030s][info][class,init] 215 Initializing jdk/internal/loader/NativeLibraries'jdk/internal/loader/NativeLibraries' (0x000000080000eba0)
[0.030s][info][class,init] 216 Initializing java/util/ArrayDeque'java/util/ArrayDeque'(no method) (0x00000008001518f0)
[0.030s][info][class,init] 217 Initializing jdk/internal/module/ServicesCatalog'jdk/internal/module/ServicesCatalog' (0x0000000800127108)
[0.031s][info][class,init] 218 Initializing java/util/concurrent/CopyOnWriteArrayList'java/util/concurrent/CopyOnWriteArrayList'(no method) (0x000000080020c928)
[0.031s][info][class,init] 219 Initializing jdk/internal/module/ServicesCatalog$ServiceProvider'jdk/internal/module/ServicesCatalog$ServiceProvider'(no method) (0x000000080020ce40)
[0.031s][info][class,init] 220 Initializing jdk/internal/loader/ClassLoaders$PlatformClassLoader'jdk/internal/loader/ClassLoaders$PlatformClassLoader' (0x000000080008f768)
[0.031s][info][class,init] 221 Initializing jdk/internal/loader/BuiltinClassLoader$LoadedModule'jdk/internal/loader/BuiltinClassLoader$LoadedModule'(no method) (0x0000000800175f00)
[0.031s][info][class,init] 222 Initializing jdk/internal/loader/ClassLoaders$AppClassLoader'jdk/internal/loader/ClassLoaders$AppClassLoader' (0x000000080008d498)
[0.031s][info][class,init] 223 Initializing jdk/internal/loader/BootLoader'jdk/internal/loader/BootLoader' (0x00000008001267b0)
[0.031s][info][class,init] 224 Initializing jdk/internal/loader/ClassLoaders'jdk/internal/loader/ClassLoaders' (0x000000080000faa8)
[0.031s][info][class,init] 225 Initializing jdk/internal/loader/URLClassPath'jdk/internal/loader/URLClassPath' (0x000000080019a988)
[0.031s][info][class,init] 226 Initializing java/net/URL'java/net/URL' (0x000000080006e8e0)
[0.031s][info][class,init] 227 Initializing java/net/URL$DefaultFactory'java/net/URL$DefaultFactory' (0x000000080008abf0)
[0.031s][info][class,init] 228 Initializing java/net/URL$3'java/net/URL$3'(no method) (0x000000080008a7b8)
[0.031s][info][class,init] 229 Initializing java/io/File$PathStatus'java/io/File$PathStatus' (0x000000080008b0c8)
[0.031s][info][class,init] 230 Initializing sun/net/www/ParseUtil'sun/net/www/ParseUtil' (0x000000080008a5a8)
[0.031s][info][class,init] 231 Initializing java/util/HexFormat'java/util/HexFormat' (0x000000080008c9e8)
[0.031s][info][class,init] 232 Initializing java/net/URLStreamHandler'java/net/URLStreamHandler'(no method) (0x0000000800197d98)
[0.031s][info][class,init] 233 Initializing sun/net/www/protocol/file/Handler'sun/net/www/protocol/file/Handler'(no method) (0x0000000800198480)
[0.031s][info][class,init] 234 Initializing sun/net/util/IPAddressUtil'sun/net/util/IPAddressUtil' (0x00000008000872f8)
[0.032s][info][class,init] 235 Initializing jdk/internal/util/Preconditions'jdk/internal/util/Preconditions'(no method) (0x00000008000870e8)
[0.032s][info][class,init] 236 Initializing java/lang/invoke/StringConcatFactory'java/lang/invoke/StringConcatFactory' (0x000000080001d230)
[0.032s][info][class,init] 237 Initializing java/util/function/Function'java/util/function/Function'(no method) (0x00000008001034f8)
[0.032s][info][class,init] 238 Initializing java/lang/invoke/StringConcatFactory$1'java/lang/invoke/StringConcatFactory$1'(no method) (0x0000000800210430)
[0.032s][info][class,init] 239 Initializing java/lang/invoke/StringConcatFactory$2'java/lang/invoke/StringConcatFactory$2'(no method) (0x0000000800210978)
[0.032s][info][class,init] 240 Initializing java/lang/invoke/StringConcatFactory$3'java/lang/invoke/StringConcatFactory$3'(no method) (0x0000000800040450)
[0.032s][info][class,init] 241 Initializing java/nio/CharBuffer'java/nio/CharBuffer' (0x00000008000798f8)
[0.032s][info][class,init] 242 Initializing java/nio/HeapCharBuffer'java/nio/HeapCharBuffer' (0x0000000800079f80)
[0.032s][info][class,init] 243 Initializing java/nio/charset/CoderResult'java/nio/charset/CoderResult' (0x00000008000a8bd0)
openjdk version "18-internal" 2022-03-15
OpenJDK Runtime Environment (build 18-internal+0-adhoc.qingfengyy.jdktip)
OpenJDK 64-Bit Server VM (build 18-internal+0-adhoc.qingfengyy.jdktip, mixed mode, sharing)
[0.033s][info][class,init] 244 Initializing java/lang/Shutdown'java/lang/Shutdown' (0x000000080004c3a0)
[0.033s][info][class,init] 245 Initializing java/lang/Shutdown$Lock'java/lang/Shutdown$Lock'(no method) (0x0000000800024a40)

It looks this patch will not affect the initialization order.

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

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

From lzang at openjdk.java.net  Mon Jul  5 09:34:03 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 5 Jul 2021 09:34:03 GMT
Subject: RFR: 8269685: Optimize HeapHprofBinWriter implementation [v2]
In-Reply-To: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
Message-ID: <-2ODd7Z0XBowrP2n-6--JsvvvQnVOO24HfB9Db7rAaU=.43308cfb-651f-4663-93d3-c6dccab1c464@github.com>

> This PR rewrite the implementation of the HeapHprofBinWriter, which could simplify the logic of current implementation.
> please see detail description at https://bugs.openjdk.java.net/browse/JDK-8269685.

Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into hprof
 - 8269685: Optimize HeapHprofBinWriter implementation

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

Changes: https://git.openjdk.java.net/jdk/pull/4666/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4666&range=01
  Stats: 467 lines in 3 files changed: 208 ins; 246 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4666.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4666/head:pull/4666

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

From lzang at openjdk.java.net  Mon Jul  5 12:04:17 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 5 Jul 2021 12:04:17 GMT
Subject: RFR: 8269685: Optimize HeapHprofBinWriter implementation [v3]
In-Reply-To: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
Message-ID: <DyIwynoIm6DSvzRJoyxB8m65aYMyBuHagz5lwTClc9g=.4af54310-c091-4d5f-a648-27c8bf75d1c7@github.com>

> This PR rewrite the implementation of the HeapHprofBinWriter, which could simplify the logic of current implementation.
> please see detail description at https://bugs.openjdk.java.net/browse/JDK-8269685.

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  fix write size issue

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4666/files
  - new: https://git.openjdk.java.net/jdk/pull/4666/files/e5ef8bd3..59691b54

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

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

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

From cgo at openjdk.java.net  Mon Jul  5 12:24:01 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Mon, 5 Jul 2021 12:24:01 GMT
Subject: [jdk17] RFR: 8269873: serviceability/sa/Clhsdb tests are using a C2
 specific VMStruct field
Message-ID: <nCO1-ZPuidcsbdej4s10GOx6QFaVszDWdmKq-32Witk=.34a45d04-2f08-4743-bbb2-81cf2e1eaf9b@github.com>

Hi,

please review this small change for two Clhsdb test cases, which are using C2 specific fields during testing. This makes the tests fail, if C2 is not available during testing.

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

Commit messages:
 - 8269873: serviceability/sa/Clhsdb tests are using a C2 specific VMStruct field

Changes: https://git.openjdk.java.net/jdk17/pull/213/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=213&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269873
  Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/213.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/213/head:pull/213

PR: https://git.openjdk.java.net/jdk17/pull/213

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: <N9wrxWLSAR641XaAwfdNO2OiT76zhTbC7DcjbmJG6zo=.e96e776e-d3a1-4d60-818c-1cb3ef03a57e@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <N9wrxWLSAR641XaAwfdNO2OiT76zhTbC7DcjbmJG6zo=.e96e776e-d3a1-4d60-818c-1cb3ef03a57e@github.com>
Message-ID: <vXJQa9YGKu-5Jou_h6OWh_sxgFu5o1HjXibGdl8-RkU=.d1263040-4e96-4956-8b55-a39fd245d821@github.com>

On Wed, 30 Jun 2021 06:38:30 GMT, Yi Yang <yyang at openjdk.org> 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 <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: <N9wrxWLSAR641XaAwfdNO2OiT76zhTbC7DcjbmJG6zo=.e96e776e-d3a1-4d60-818c-1cb3ef03a57e@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <N9wrxWLSAR641XaAwfdNO2OiT76zhTbC7DcjbmJG6zo=.e96e776e-d3a1-4d60-818c-1cb3ef03a57e@github.com>
Message-ID: <Q67aBGldQlbcc8bEp42KYzp4uyO-Ym7jPY6iQZXXCO0=.ed677e81-1861-492e-9061-9f4c1b067bed@github.com>

On Wed, 30 Jun 2021 06:38:30 GMT, Yi Yang <yyang at openjdk.org> 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 <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: <ug7xjtcP4EADoibDKJ1533wqQDpLgXIR3N-XHIBUkxg=.a29c5812-bc6f-4f7b-b079-12262c9646da@github.com>

On Tue, 6 Jul 2021 02:55:37 GMT, Lin Zang <lzang at openjdk.org> 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: <Q67aBGldQlbcc8bEp42KYzp4uyO-Ym7jPY6iQZXXCO0=.ed677e81-1861-492e-9061-9f4c1b067bed@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <N9wrxWLSAR641XaAwfdNO2OiT76zhTbC7DcjbmJG6zo=.e96e776e-d3a1-4d60-818c-1cb3ef03a57e@github.com>
 <Q67aBGldQlbcc8bEp42KYzp4uyO-Ym7jPY6iQZXXCO0=.ed677e81-1861-492e-9061-9f4c1b067bed@github.com>
Message-ID: <CM1jaMoAH5PZetjuAiu8mthhyrXTU9qQK_gVcgbKoKo=.8915e9ba-7e1e-47eb-8acb-4f4b804fa7bf@github.com>

On Tue, 6 Jul 2021 03:08:42 GMT, David Holmes <dholmes at openjdk.org> 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: <CM1jaMoAH5PZetjuAiu8mthhyrXTU9qQK_gVcgbKoKo=.8915e9ba-7e1e-47eb-8acb-4f4b804fa7bf@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <N9wrxWLSAR641XaAwfdNO2OiT76zhTbC7DcjbmJG6zo=.e96e776e-d3a1-4d60-818c-1cb3ef03a57e@github.com>
 <Q67aBGldQlbcc8bEp42KYzp4uyO-Ym7jPY6iQZXXCO0=.ed677e81-1861-492e-9061-9f4c1b067bed@github.com>
 <CM1jaMoAH5PZetjuAiu8mthhyrXTU9qQK_gVcgbKoKo=.8915e9ba-7e1e-47eb-8acb-4f4b804fa7bf@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 <dholmes at openjdk.org> 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: <lwkhqDopE3X6CcnjxWM8MMqrI0G6FkV5miaTsQ2I9xI=.b6e8bb6d-ea69-4bd3-be1c-8138e04433c0@github.com>

On Tue, 6 Jul 2021 02:55:37 GMT, Lin Zang <lzang at openjdk.org> 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: <lwkhqDopE3X6CcnjxWM8MMqrI0G6FkV5miaTsQ2I9xI=.b6e8bb6d-ea69-4bd3-be1c-8138e04433c0@github.com>
References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com>
 <lwkhqDopE3X6CcnjxWM8MMqrI0G6FkV5miaTsQ2I9xI=.b6e8bb6d-ea69-4bd3-be1c-8138e04433c0@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 <lzang at openjdk.org> 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: <ug7xjtcP4EADoibDKJ1533wqQDpLgXIR3N-XHIBUkxg=.a29c5812-bc6f-4f7b-b079-12262c9646da@github.com>
References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com>
 <ug7xjtcP4EADoibDKJ1533wqQDpLgXIR3N-XHIBUkxg=.a29c5812-bc6f-4f7b-b079-12262c9646da@github.com>
Message-ID: <OmX1XrOWEVd071ah7vIGYK02Q5dUI725fLjSQDdRpOk=.1a7ee0ea-b9ea-4403-bd79-774551d9a8be@github.com>

On Tue, 6 Jul 2021 03:14:15 GMT, David Holmes <dholmes at openjdk.org> 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 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: <tAei8i_f39Kbqx9tkC7DLDhsnWC1MrV4fqJ5dpkVy6Q=.a455d326-e759-4926-8cd8-a65ed6279ddf@github.com>

On Tue, 6 Jul 2021 06:32:12 GMT, Lin Zang <lzang at openjdk.org> 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: <heBSJJ3TH5wkmWGhNeHXGAkN1XNhyreEMFJWWghXuRY=.ee285f3e-409b-49cf-8077-15542d66aeaa@github.com>

On Tue, 6 Jul 2021 06:32:12 GMT, Lin Zang <lzang at openjdk.org> 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 kevinw at openjdk.java.net  Tue Jul  6 08:02:51 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 6 Jul 2021 08:02:51 GMT
Subject: [jdk17] RFR: 8269830: SA's vm object vtable matching code
 sometimes matches on incorrect type
In-Reply-To: <k9MpheHb72YinJMy-nEXdNMMasleSwZ-3QpRjU-n-zI=.0485265c-ec3c-41b7-b0b4-4099d380b292@github.com>
References: <k9MpheHb72YinJMy-nEXdNMMasleSwZ-3QpRjU-n-zI=.0485265c-ec3c-41b7-b0b4-4099d380b292@github.com>
Message-ID: <LVZeNoyVCCXKCIsIHvDuy3cHim4oQHG4PxZVHYfNh2Q=.dfe75ff8-617b-438a-b0f5-f9eefa31686d@github.com>

On Fri, 2 Jul 2021 21:57:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See the CR for details. This issue is causing a lot of failures related to some threads occasionally not being included in the jstack output, such as SteadyStateThread, Common-Cleaner, and "Signal Dispatcher". The bug caused SA to sometimes think a JavaThread object is actually an instance of the CompilerThread subclass, even though it is not. This results in jstack not including the thread in the output since it purposefully omits CompilerThreads.

Much simpler!

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

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.java.net/jdk17/pull/206

From pconcannon at openjdk.java.net  Tue Jul  6 10:24:29 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 6 Jul 2021 10:24:29 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v6]
In-Reply-To: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
Message-ID: <xBVt4ToIsZo0iLBheZlh6ilATN_PcdmiMcl5KDZ5Ru4=.e5784c9d-7817-4316-b546-bafaaa53e1a8@github.com>

> Hi,
> 
> Could someone please review my changes for the removal of the legacy `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
> 
> In JDK 13, JEP 353 provided a drop in replacement for the legacy `PlainSocketImpl` implementation. Since JDK 13, the `PlainSocketImpl` implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property `jdk.net.usePlainSocketImpl` allowing to switch back to the old implementation. 
> Similarly, in JDK 15, JEP 373 provided a new implementation for `DatagramSocket` and `MulticastSocket`, with a JDK-specific property `jdk.net.usePlainDatagramSocketImpl` also allowing the user to switch back to the old implementation in case of compatibility issue.
> 
> As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8253119
 - 8253119: Fixed typo
 - 8253119: Added message to null check in java/net/DatagramSocket
 - Merge remote-tracking branch 'origin/master' into JDK-8253119
 - 8253119: Removed redundant comments and USE_PLAINDATAGRAMSOCKET from java/net/DatagramSocket
 - Merge remote-tracking branch 'origin/master' into JDK-8253119
 - 8253119: Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4574/files
  - new: https://git.openjdk.java.net/jdk/pull/4574/files/686b4369..538b145e

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

  Stats: 12821 lines in 436 files changed: 7154 ins; 3504 del; 2163 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4574.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4574/head:pull/4574

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

From pconcannon at openjdk.java.net  Tue Jul  6 13:50:53 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 6 Jul 2021 13:50:53 GMT
Subject: Integrated: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation
In-Reply-To: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
Message-ID: <Zk8-H_v4_lAPs7eLhDTQ_0NSTYUZDuBwXWjErPR6pnQ=.a85bb9cb-db9b-4b6b-ade3-3d2fafe5abfe@github.com>

On Wed, 23 Jun 2021 12:06:41 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my changes for the removal of the legacy `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
> 
> In JDK 13, JEP 353 provided a drop in replacement for the legacy `PlainSocketImpl` implementation. Since JDK 13, the `PlainSocketImpl` implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property `jdk.net.usePlainSocketImpl` allowing to switch back to the old implementation. 
> Similarly, in JDK 15, JEP 373 provided a new implementation for `DatagramSocket` and `MulticastSocket`, with a JDK-specific property `jdk.net.usePlainDatagramSocketImpl` also allowing the user to switch back to the old implementation in case of compatibility issue.
> 
> As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.
> 
> Kind regards,
> Patrick

This pull request has now been integrated.

Changeset: 326b2e13
Author:    Patrick Concannon <pconcannon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/326b2e13447d734f84271942cc8154e30486fa7d
Stats:     11059 lines in 78 files changed: 136 ins; 10853 del; 70 mod

8253119: Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation

Reviewed-by: alanb, dfuchs, chegar

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

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

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: <sdYRAoHt318_btf1wW4rP0eMUIIUba9nqDXIa-qQH34=.63c0837e-239f-457c-a44e-b4213c34ccc7@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
 <sdYRAoHt318_btf1wW4rP0eMUIIUba9nqDXIa-qQH34=.63c0837e-239f-457c-a44e-b4213c34ccc7@github.com>
Message-ID: <J-JcGF6UxpnIVsouNnPCJSarTUXbxk7poOZHh0zG_Wg=.a989186a-1404-4a24-8b5f-56d19cf63647@github.com>

On Sun, 6 Jun 2021 08:50:22 GMT, Anton Kozlov <akozlov at openjdk.org> 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 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: <gCKaeo-_5Zme0-fM1F4lK6aXLzY5CDWA0pwaDy5TIxU=.93abf66b-ca09-4361-965e-ba2ac0aff93d@github.com>

On Tue, 6 Jul 2021 06:32:12 GMT, Lin Zang <lzang at openjdk.org> 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:07:52 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 6 Jul 2021 18:07:52 GMT
Subject: [jdk17] RFR: 8269873: serviceability/sa/Clhsdb tests are using a
 C2 specific VMStruct field
In-Reply-To: <nCO1-ZPuidcsbdej4s10GOx6QFaVszDWdmKq-32Witk=.34a45d04-2f08-4743-bbb2-81cf2e1eaf9b@github.com>
References: <nCO1-ZPuidcsbdej4s10GOx6QFaVszDWdmKq-32Witk=.34a45d04-2f08-4743-bbb2-81cf2e1eaf9b@github.com>
Message-ID: <LRIcT5yY0s_qxztepVV58EXzo3EhKRdHXUYnipVtGvY=.c8ac4b6f-cf0a-46a0-a29c-c60e29b9208e@github.com>

On Mon, 5 Jul 2021 12:16:22 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Hi,
> 
> please review this small change for two Clhsdb test cases, which are using C2 specific fields during testing. This makes the tests fail, if C2 is not available during testing.

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/213

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 <lzang at openjdk.org> 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 cjplummer at openjdk.java.net  Tue Jul  6 18:32:59 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 6 Jul 2021 18:32:59 GMT
Subject: [jdk17] RFR: 8269830: SA's vm object vtable matching code
 sometimes matches on incorrect type
In-Reply-To: <LVZeNoyVCCXKCIsIHvDuy3cHim4oQHG4PxZVHYfNh2Q=.dfe75ff8-617b-438a-b0f5-f9eefa31686d@github.com>
References: <k9MpheHb72YinJMy-nEXdNMMasleSwZ-3QpRjU-n-zI=.0485265c-ec3c-41b7-b0b4-4099d380b292@github.com>
 <LVZeNoyVCCXKCIsIHvDuy3cHim4oQHG4PxZVHYfNh2Q=.dfe75ff8-617b-438a-b0f5-f9eefa31686d@github.com>
Message-ID: <JGGw8sxwEgqnXuIt36M-e648mqSQFo6HI9mxOpkeXeY=.ac5bc418-563b-4c0d-b56a-1387cc27120a@github.com>

On Tue, 6 Jul 2021 07:59:25 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Much simpler!

Thank you Kevin!

Can I get one more review please?

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

PR: https://git.openjdk.java.net/jdk17/pull/206

From mchung at openjdk.java.net  Tue Jul  6 19:20:54 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 6 Jul 2021 19:20:54 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible
In-Reply-To: <rKyGMmub9-W1VGCGX86Wkh9f-GdRcUtEupSXLY1Jarw=.67f42692-0937-4a4a-9331-4c5a641dc2ea@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <wnnvM-AabtvXj6GyY15k2WngzWJhz6OXWfs_PygCaWU=.17e6e99b-e808-4c9e-89cc-4af2213e301e@github.com>
 <u2TRSykc6zsKvQKGF74xka3w2odK2m0dx0HmEP0BwZc=.c8dfba1f-55b4-4e8e-a2ad-5286097ea203@github.com>
 <rKyGMmub9-W1VGCGX86Wkh9f-GdRcUtEupSXLY1Jarw=.67f42692-0937-4a4a-9331-4c5a641dc2ea@github.com>
Message-ID: <T47LfOAok-UF2NOA0biHXQjDRKbuyDc1HBXfw6LEPkM=.7cde602e-98f5-4906-9968-048ccedbc692@github.com>

On Mon, 5 Jul 2021 06:29:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest version? Thanks.
>
> @kelthuzadx  I did not see any response to my query about the change in initialization (not load) order. I also remain concerned about introducing cross dependencies between core classes (e.g. String now uses Precondition, so does that impact Precondition using String?) But these are things for the core-libs folk to be concerned about, or not.
> 
> Cheers,
> David

> @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest version? Thanks.

Alan and Paul are currently on vacation.  I'm reviewing it.

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

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

From mchung at openjdk.java.net  Tue Jul  6 19:20:53 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 6 Jul 2021 19:20:53 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v8]
In-Reply-To: <imrXHsfJUsxhjLQpbPTeYPTKUff42FGED1cdeB76ST8=.d7c474cb-ebad-4f63-8f88-13494086e0e6@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <imrXHsfJUsxhjLQpbPTeYPTKUff42FGED1cdeB76ST8=.d7c474cb-ebad-4f63-8f88-13494086e0e6@github.com>
Message-ID: <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com>

On Wed, 23 Jun 2021 03:54:55 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tests rely on IOOBE exception message

I suggest to separate the client changes (both src and test) in a separate PR for the client review.

I review the rest of the files, which looks okay to me.   I will take another pass carefully.

src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java needs to be updated in JSR 166 upstream repo.    Better to file a separate issue for this change to ensure that gets fixed in the upstream project.

test/jdk/java/lang/StringBuffer/Exceptions.java line 73:

> 71:                 new StringBuffer();
> 72:             }
> 73:         });

Nit: The above formatting (line 70-97) is inconsistent with the formatting in line 110-124.   It'd be good to use the same formatting.

test/jdk/java/lang/StringBuilder/Exceptions.java line 73:

> 71:                 new StringBuilder();
> 72:             }
> 73:         });

Nit: it'd be good to make the formatting of all calls to tryCatch method consistent.

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

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

From sspitsyn at openjdk.java.net  Tue Jul  6 19:27:50 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 6 Jul 2021 19:27:50 GMT
Subject: RFR: 8269770: nsk tests should start IOPipe channel before launch
 debuggee - Debugee.prepareDebugee [v2]
In-Reply-To: <NN8U4ddBK-4rcoVri_yEo8o13MAOajtLl4smgln4PJ0=.347bd198-8e2e-4b8b-99bf-ef808f5c894f@github.com>
References: <Ul6inNVMRVB_OAtRF6ONX1HfJ1xLxZ-olKE95X_FiF4=.9b6cad69-0927-4750-b28d-e3099ea4f636@github.com>
 <NN8U4ddBK-4rcoVri_yEo8o13MAOajtLl4smgln4PJ0=.347bd198-8e2e-4b8b-99bf-ef808f5c894f@github.com>
Message-ID: <EC-u2SPaNAm9ZYVotpc8OX_GsD8AnkRq1ArOT60Yybk=.7eee1fa3-3d18-402e-aa8a-8c32cad65fd3@github.com>

On Fri, 2 Jul 2021 19:30:11 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The change fixes several hundreds tests which launch debugee by using uses Debugee.prepareDebugee() method or use 
>> debugee = Binder.bindToDebugee(...);
>> IOPipe pipe = debugee.createIOPipe();
>> logic.
>> Debugee.prepareDebugee() and Binder.bindToDebugee() launch debuggee by using CommandLineLaunch JDI connector with suspend=="true" argument, so they return debuggee suspended before the main class is loaded.
>> The fix starts IOPipe listening before debuggee VM is resumed.
>> 
>> Simplified isPackagePrivate/accipp001.java test to use Debugee.prepareDebugee() - it does exactly the same as Debugee.prepareDebugee() does (the only difference is using deprecated IOPipe ctor instead of Debugee.createIOPipe())
>> 
>> Tested all affected tests:
>> test/hotspot/jtreg/vmTestbase/nsk/jdi
>> test/hotspot/jtreg/vmTestbase/nsk/jdwp
>> test/hotspot/jtreg/serviceability/dcmd
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed comment

Marked as reviewed by sspitsyn (Reviewer).

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

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

From sspitsyn at openjdk.java.net  Tue Jul  6 19:29:51 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 6 Jul 2021 19:29:51 GMT
Subject: RFR: 8269616: serviceability/dcmd/framework/VMVersionTest.java
 fails with Address already in use error
In-Reply-To: <cGHTffmXV_fPcR2uzsbb0Xyj7QUqg0Sm1ZkUCkwhXUg=.b4f9adb3-a430-42f0-a95d-e5a906c9e30d@github.com>
References: <cGHTffmXV_fPcR2uzsbb0Xyj7QUqg0Sm1ZkUCkwhXUg=.b4f9adb3-a430-42f0-a95d-e5a906c9e30d@github.com>
Message-ID: <eeawdQy1RTqCF4dNWpqTA_N25RPHHU1141ckBfOclYY=.fac3280c-4134-45bd-8b29-a7cace69c8a8@github.com>

On Fri, 2 Jul 2021 21:23:39 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> SocketIOPipe/IOPipe classes can select listening port by 2 ways:
> 1. caller specifies "-transport.address=dynamic" argument creating ArgumentHandler,
> and calls Binder.prepareForPipeConnection (actually see nsk.share.jpda.DebugeeBinder.prepareForPipeConnection()) before start listening.
> In the case prepareForPipeConnection creates socket and this socket later is used by IOPipe.
> 2. just start IOPipe listening.
> Then port is selected by calling nsk.share.jpda.DebugeeArgumentHandler.getTransportPort() which use findFreePort() method:
> 
>     ServerSocket ss;
>     try {
>         ss = new ServerSocket(0);
>         return String.valueOf(ss.getLocalPort());
>     }finally {
>         ss.close();
>     }
> 
> This method is known to be error prone (sometimes causes "address in use" error).
> 
> The fix adds "-transport.address=dynamic" argument so IOPipe use 1st method.

LGTM.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.java.net  Tue Jul  6 20:03:47 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 6 Jul 2021 20:03:47 GMT
Subject: [jdk17] RFR: 8269830: SA's vm object vtable matching code
 sometimes matches on incorrect type
In-Reply-To: <k9MpheHb72YinJMy-nEXdNMMasleSwZ-3QpRjU-n-zI=.0485265c-ec3c-41b7-b0b4-4099d380b292@github.com>
References: <k9MpheHb72YinJMy-nEXdNMMasleSwZ-3QpRjU-n-zI=.0485265c-ec3c-41b7-b0b4-4099d380b292@github.com>
Message-ID: <m5demCgMct-bL2vL8_OMTw-j7UKdOnnJtP4XFIyRIUA=.52c7c5e7-1ac1-464d-9ab5-8d757f19ee53@github.com>

On Fri, 2 Jul 2021 21:57:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See the CR for details. This issue is causing a lot of failures related to some threads occasionally not being included in the jstack output, such as SteadyStateThread, Common-Cleaner, and "Signal Dispatcher". The bug caused SA to sometimes think a JavaThread object is actually an instance of the CompilerThread subclass, even though it is not. This results in jstack not including the thread in the output since it purposefully omits CompilerThreads.

Nice cleanup.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/206

From cjplummer at openjdk.java.net  Tue Jul  6 21:15:50 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 6 Jul 2021 21:15:50 GMT
Subject: [jdk17] RFR: 8269830: SA's vm object vtable matching code
 sometimes matches on incorrect type
In-Reply-To: <k9MpheHb72YinJMy-nEXdNMMasleSwZ-3QpRjU-n-zI=.0485265c-ec3c-41b7-b0b4-4099d380b292@github.com>
References: <k9MpheHb72YinJMy-nEXdNMMasleSwZ-3QpRjU-n-zI=.0485265c-ec3c-41b7-b0b4-4099d380b292@github.com>
Message-ID: <wVPIrCsbUjB2Bop-jGqTT3vnnOaV2Qnc7BGoOkiG6os=.4c69201e-db58-4470-8ddc-c0e57028f8e8@github.com>

On Fri, 2 Jul 2021 21:57:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See the CR for details. This issue is causing a lot of failures related to some threads occasionally not being included in the jstack output, such as SteadyStateThread, Common-Cleaner, and "Signal Dispatcher". The bug caused SA to sometimes think a JavaThread object is actually an instance of the CompilerThread subclass, even though it is not. This results in jstack not including the thread in the output since it purposefully omits CompilerThreads.

Thanks Serguei!

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

PR: https://git.openjdk.java.net/jdk17/pull/206

From dholmes at openjdk.java.net  Tue Jul  6 21:48:51 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 6 Jul 2021 21:48:51 GMT
Subject: [jdk17] RFR: 8269873: serviceability/sa/Clhsdb tests are using a
 C2 specific VMStruct field
In-Reply-To: <nCO1-ZPuidcsbdej4s10GOx6QFaVszDWdmKq-32Witk=.34a45d04-2f08-4743-bbb2-81cf2e1eaf9b@github.com>
References: <nCO1-ZPuidcsbdej4s10GOx6QFaVszDWdmKq-32Witk=.34a45d04-2f08-4743-bbb2-81cf2e1eaf9b@github.com>
Message-ID: <tenAi74LGA9RMvsnbUNt81qt45NyU_tLVIKjxoS4PEM=.6f9c60e3-3d85-4a7b-b04a-2d92091fd7ac@github.com>

On Mon, 5 Jul 2021 12:16:22 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Hi,
> 
> please review this small change for two Clhsdb test cases, which are using C2 specific fields during testing. This makes the tests fail, if C2 is not available during testing.

Looks good.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/213

From sspitsyn at openjdk.java.net  Tue Jul  6 22:03:48 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 6 Jul 2021 22:03:48 GMT
Subject: [jdk17] RFR: 8269873: serviceability/sa/Clhsdb tests are using a
 C2 specific VMStruct field
In-Reply-To: <nCO1-ZPuidcsbdej4s10GOx6QFaVszDWdmKq-32Witk=.34a45d04-2f08-4743-bbb2-81cf2e1eaf9b@github.com>
References: <nCO1-ZPuidcsbdej4s10GOx6QFaVszDWdmKq-32Witk=.34a45d04-2f08-4743-bbb2-81cf2e1eaf9b@github.com>
Message-ID: <zuZ5o2-GWL6Wp3Zh5RFH2SRM-JQiFgLWxZs8Q2x38KI=.56f11584-df49-400b-a36a-84b685b6b29d@github.com>

On Mon, 5 Jul 2021 12:16:22 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Hi,
> 
> please review this small change for two Clhsdb test cases, which are using C2 specific fields during testing. This makes the tests fail, if C2 is not available during testing.

Marked as reviewed by sspitsyn (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/213

From cgo at openjdk.java.net  Tue Jul  6 22:34:52 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Tue, 6 Jul 2021 22:34:52 GMT
Subject: [jdk17] RFR: 8269873: serviceability/sa/Clhsdb tests are using a
 C2 specific VMStruct field
In-Reply-To: <nCO1-ZPuidcsbdej4s10GOx6QFaVszDWdmKq-32Witk=.34a45d04-2f08-4743-bbb2-81cf2e1eaf9b@github.com>
References: <nCO1-ZPuidcsbdej4s10GOx6QFaVszDWdmKq-32Witk=.34a45d04-2f08-4743-bbb2-81cf2e1eaf9b@github.com>
Message-ID: <bEX_HQ4srZEN2mi5YcMtMnr2PRUUNjiPMcyLf4pZ4PY=.3290772e-9078-429f-9924-ec6bc65c7124@github.com>

On Mon, 5 Jul 2021 12:16:22 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Hi,
> 
> please review this small change for two Clhsdb test cases, which are using C2 specific fields during testing. This makes the tests fail, if C2 is not available during testing.

Thanks for the reviews.

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

PR: https://git.openjdk.java.net/jdk17/pull/213

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: <DNRLYYNjMOtf4JmQEhAFE1Ro-jdXMSUC3LfSC5z2AJ0=.a2fad234-430b-4f61-b300-fad5381ec95a@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 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: <tlyGik9FJY8RIvEoAd45XZWhnPKRJHQrCfRlUjEbsSU=.5b60acca-9dda-4c75-a929-f05e9e42844d@github.com>

On Tue, 6 Jul 2021 18:12:09 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <DNRLYYNjMOtf4JmQEhAFE1Ro-jdXMSUC3LfSC5z2AJ0=.a2fad234-430b-4f61-b300-fad5381ec95a@github.com>
References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com>
 <DNRLYYNjMOtf4JmQEhAFE1Ro-jdXMSUC3LfSC5z2AJ0=.a2fad234-430b-4f61-b300-fad5381ec95a@github.com>
Message-ID: <uAxXAG6vSwLde7Sv-ojd_yQH4vLlR3vpQevQ9eRlWPo=.72ccfbf7-09fa-416b-87d9-55b7fc78cc08@github.com>

On Wed, 7 Jul 2021 00:44:11 GMT, Lin Zang <lzang at openjdk.org> 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 github.com+7837910+xpbob at openjdk.java.net  Wed Jul  7 01:21:11 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Wed, 7 Jul 2021 01:21:11 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports Process
 CPU usage
Message-ID: <i3eX0EiRKS8MFmlet1ikGxgMlW2_8Dspw-mgJpObBXo=.9e1059ec-4558-4e9f-9d74-0365922fd7dc@github.com>

?ocess cpu usage inside a container

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

Commit messages:
 - 8269851: OperatingSystemMXBean getProcessCpuLoad reports incorrect process cpu usage inside a container

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

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

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: <SNXLLBxzqlSz0jOndn0CJ57ghU9W06_wv2NVQRRGEYY=.e68d39e8-451c-4720-be72-f0389eb2d19f@github.com>

On Thu, 10 Jun 2021 02:07:36 GMT, Yi Yang <yyang at openjdk.org> 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 <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 <yyang at openjdk.org>
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 github.com+7837910+xpbob at openjdk.java.net  Wed Jul  7 01:48:49 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Wed, 7 Jul 2021 01:48:49 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 Process CPU usage
In-Reply-To: <i3eX0EiRKS8MFmlet1ikGxgMlW2_8Dspw-mgJpObBXo=.9e1059ec-4558-4e9f-9d74-0365922fd7dc@github.com>
References: <i3eX0EiRKS8MFmlet1ikGxgMlW2_8Dspw-mgJpObBXo=.9e1059ec-4558-4e9f-9d74-0365922fd7dc@github.com>
Message-ID: <Uw9zGeDLCiuQwBzQzhuEnnCZRdF1S56X-QNzhksMzpE=.411c4a17-e66a-4fcb-891f-9fc02762e159@github.com>

On Wed, 7 Jul 2021 01:11:00 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

> ?ocess cpu usage inside a container

getProcessCpuLoad return jvm cpu load?
8 core in machine, set 1 core for container?
Run same program, the getProcessCpuLoad return the same value?

expected 
same program run in machine,value 0.12
run in  1 core container,value 0.99

ProcessCpuLoad  is associative container setting

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

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

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: <ug7xjtcP4EADoibDKJ1533wqQDpLgXIR3N-XHIBUkxg=.a29c5812-bc6f-4f7b-b079-12262c9646da@github.com>
References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com>
 <ug7xjtcP4EADoibDKJ1533wqQDpLgXIR3N-XHIBUkxg=.a29c5812-bc6f-4f7b-b079-12262c9646da@github.com>
Message-ID: <NPM2_ohk3e-3FnBi_YerrKb3j-J1RDOO4ertFSre5Cs=.213f24f2-b7bb-4ec8-8e51-af82bf786ca9@github.com>

On Tue, 6 Jul 2021 03:14:15 GMT, David Holmes <dholmes at openjdk.org> 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 yyang at openjdk.java.net  Wed Jul  7 02:18:13 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 7 Jul 2021 02:18:13 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v8]
In-Reply-To: <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <imrXHsfJUsxhjLQpbPTeYPTKUff42FGED1cdeB76ST8=.d7c474cb-ebad-4f63-8f88-13494086e0e6@github.com>
 <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com>
Message-ID: <7AYfiggiXSOnvK9Vi3mIUmJMT54MQqBQRygezjGvXPU=.33f0f6bb-0fa9-4f03-9151-c7c68afadbc1@github.com>

On Tue, 6 Jul 2021 19:06:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   tests rely on IOOBE exception message
>
> test/jdk/java/lang/StringBuffer/Exceptions.java line 73:
> 
>> 71:                 new StringBuffer();
>> 72:             }
>> 73:         });
> 
> Nit: The above formatting (line 70-97) is inconsistent with the formatting in line 110-124.   It'd be good to use the same formatting.

Hi Mandy, thanks for reviewing this. 

> I suggest to separate the client changes (both src and test) in a separate PR for the client review.

Does "client changes" means changes involving src/java.desktop and test/java/awt?

> src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java needs to be updated in JSR 166 upstream repo. Better to file a separate issue for this change to ensure that gets fixed in the upstream project.

Can you please paste a link for that? I'm not sure where I can find JSR 166 upstream repo..

> Nit: The above formatting (line 70-97) is inconsistent with the formatting in line 110-124. It'd be good to use the same formatting.

Restored.

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

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

From yyang at openjdk.java.net  Wed Jul  7 02:18:12 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 7 Jul 2021 02:18:12 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v9]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <Ya5eZhM6WCzGfHV2UzYNXEQVV8obE5xRhfzJg9JuNyQ=.4e951e8c-ccc6-4573-9db8-091f230d6742@github.com>

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with four additional commits since the last revision:

 - restore code format
 - restore code format
 - restore code format
 - restore code format

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/ab1b509d..f43ffc3a

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

  Stats: 58 lines in 2 files changed: 0 ins; 10 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

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

From dholmes at openjdk.java.net  Wed Jul  7 02:24:47 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 7 Jul 2021 02:24:47 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 Process CPU usage
In-Reply-To: <i3eX0EiRKS8MFmlet1ikGxgMlW2_8Dspw-mgJpObBXo=.9e1059ec-4558-4e9f-9d74-0365922fd7dc@github.com>
References: <i3eX0EiRKS8MFmlet1ikGxgMlW2_8Dspw-mgJpObBXo=.9e1059ec-4558-4e9f-9d74-0365922fd7dc@github.com>
Message-ID: <XWV25aATg42B0mlXWJzDjPN1pcBy7id1BMTA5LHE5ew=.22e3f064-4531-43b7-8ff8-e4a6f899ac15@github.com>

On Wed, 7 Jul 2021 01:11:00 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

> ?ocess cpu usage inside a container

@YaSuenag and @jerboaa could you please take a look at this one.

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

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

From yyang at openjdk.java.net  Wed Jul  7 02:23:19 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 7 Jul 2021 02:23:19 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v10]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <B94vxaOc5uZ44iZ_uwLPB9dJ9nuXp7gSazGq_Qwfkvo=.12ae4ddc-f30d-4437-9ade-78fe579b6162@github.com>

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with two additional commits since the last revision:

 - restore code format
 - restore code format

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/f43ffc3a..903f0305

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=08-09

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

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

From cjplummer at openjdk.java.net  Wed Jul  7 02:35:53 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 7 Jul 2021 02:35:53 GMT
Subject: [jdk17] Integrated: 8269830: SA's vm object vtable matching code
 sometimes matches on incorrect type
In-Reply-To: <k9MpheHb72YinJMy-nEXdNMMasleSwZ-3QpRjU-n-zI=.0485265c-ec3c-41b7-b0b4-4099d380b292@github.com>
References: <k9MpheHb72YinJMy-nEXdNMMasleSwZ-3QpRjU-n-zI=.0485265c-ec3c-41b7-b0b4-4099d380b292@github.com>
Message-ID: <1qHohG5irm3VBsO42koj_O_t6QXbMnUjqnwg78vepGQ=.1cd0612f-00fb-45d1-80a3-9f7fc6dfcacf@github.com>

On Fri, 2 Jul 2021 21:57:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See the CR for details. This issue is causing a lot of failures related to some threads occasionally not being included in the jstack output, such as SteadyStateThread, Common-Cleaner, and "Signal Dispatcher". The bug caused SA to sometimes think a JavaThread object is actually an instance of the CompilerThread subclass, even though it is not. This results in jstack not including the thread in the output since it purposefully omits CompilerThreads.

This pull request has now been integrated.

Changeset: 2daf39a5
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/2daf39a59b2d51f25b03bb78edd677a1bab4433c
Stats:     69 lines in 1 file changed: 0 ins; 56 del; 13 mod

8269830: SA's vm object vtable matching code sometimes matches on incorrect type

Reviewed-by: kevinw, sspitsyn

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

PR: https://git.openjdk.java.net/jdk17/pull/206

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: <cmczNJDphMQdTgMKPezycvV7vxNu0ZU3WvOZqn0acDk=.5b42524f-359e-4bed-9b3e-934e08d9e116@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:

  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: <cmczNJDphMQdTgMKPezycvV7vxNu0ZU3WvOZqn0acDk=.5b42524f-359e-4bed-9b3e-934e08d9e116@github.com>
References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com>
 <cmczNJDphMQdTgMKPezycvV7vxNu0ZU3WvOZqn0acDk=.5b42524f-359e-4bed-9b3e-934e08d9e116@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 <lzang at openjdk.org> 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 github.com+7837910+xpbob at openjdk.java.net  Wed Jul  7 03:25:49 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Wed, 7 Jul 2021 03:25:49 GMT
Subject: Withdrawn: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers
In-Reply-To: <i3eX0EiRKS8MFmlet1ikGxgMlW2_8Dspw-mgJpObBXo=.9e1059ec-4558-4e9f-9d74-0365922fd7dc@github.com>
References: <i3eX0EiRKS8MFmlet1ikGxgMlW2_8Dspw-mgJpObBXo=.9e1059ec-4558-4e9f-9d74-0365922fd7dc@github.com>
Message-ID: <hBnrv9fupsPhQ7MLegGQ7vu--UbLeyViplwNd-rNBfM=.50b011e2-23ca-49d4-9867-8b16b1b5eeee@github.com>

On Wed, 7 Jul 2021 01:11:00 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

> ?ocess cpu usage inside a container

This pull request has been closed without being integrated.

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

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

From github.com+7837910+xpbob at openjdk.java.net  Wed Jul  7 04:12:03 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Wed, 7 Jul 2021 04:12:03 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers
Message-ID: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>

?ocess cpu usage in containers

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

Commit messages:
 - 8269851: OperatingSystemMXBean getProcessCpuLoad reports incorrect process cpu usage in containers

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

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

From github.com+7837910+xpbob at openjdk.java.net  Wed Jul  7 04:12:03 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Wed, 7 Jul 2021 04:12:03 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers
In-Reply-To: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
Message-ID: <2SgpJanKLDfP5FQA0GAHrsc8SGOJKCfwj47wqIB6T08=.964a9b22-c6cd-4d52-9e51-e050098c67b5@github.com>

On Wed, 7 Jul 2021 04:03:27 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

> ?ocess cpu usage in containers

getProcessCpuLoad return jvm cpu load?
8 core in machine, set 1 core for container?
Run same program, the getProcessCpuLoad return the same value?

expected
same program run in machine,value 0.12
run in 1 core container,value 0.99
ProcessCpuLoad is associative container setting

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

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

From dholmes at openjdk.java.net  Wed Jul  7 04:31:51 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 7 Jul 2021 04:31:51 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers
In-Reply-To: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
Message-ID: <TMQT6hNemMVFFeyTDoACN00jGYZBoNdUM5eRdDE0Q00=.e980b97b-eff0-4165-aeff-3d803a26e408@github.com>

On Wed, 7 Jul 2021 04:03:27 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

> ?ocess cpu usage in containers

Why did you create a new PR ??

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

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

From dholmes at openjdk.java.net  Wed Jul  7 04:32:53 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 7 Jul 2021 04:32:53 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers
In-Reply-To: <i3eX0EiRKS8MFmlet1ikGxgMlW2_8Dspw-mgJpObBXo=.9e1059ec-4558-4e9f-9d74-0365922fd7dc@github.com>
References: <i3eX0EiRKS8MFmlet1ikGxgMlW2_8Dspw-mgJpObBXo=.9e1059ec-4558-4e9f-9d74-0365922fd7dc@github.com>
Message-ID: <NYA559jM-Uk-CJGbqh7uGeeQY7VwdVpMB8-9ZLIZNAs=.f187d134-4ba9-4c8b-aaae-bdfa9f4fc4e2@github.com>

On Wed, 7 Jul 2021 01:11:00 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

> ?ocess cpu usage inside a container

This has moved to https://github.com/openjdk/jdk/pull/4702

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

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

From github.com+7837910+xpbob at openjdk.java.net  Wed Jul  7 04:37:51 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Wed, 7 Jul 2021 04:37:51 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers
In-Reply-To: <TMQT6hNemMVFFeyTDoACN00jGYZBoNdUM5eRdDE0Q00=.e980b97b-eff0-4165-aeff-3d803a26e408@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
 <TMQT6hNemMVFFeyTDoACN00jGYZBoNdUM5eRdDE0Q00=.e980b97b-eff0-4165-aeff-3d803a26e408@github.com>
Message-ID: <Oztz1S6KBFo5AqoFlHzl3_JhIjeLT-3XoFpYqwuqyzE=.945144cf-9244-4655-884a-d9a2ea299791@github.com>

On Wed, 7 Jul 2021 04:29:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Why did you create a new PR ??

bug description changed?
update the commit info.

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

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

From lzang at openjdk.java.net  Wed Jul  7 06:34:49 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 7 Jul 2021 06:34:49 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers
In-Reply-To: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
Message-ID: <0Yg5MhNiOXFEkhH8_dYEtH9-zQK-qaHGNRafzFGXcJc=.d6ea8e9d-cc24-4165-bd5a-ba375db3fd3f@github.com>

On Wed, 7 Jul 2021 04:03:27 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

> ?ocess cpu usage in containers

Hi Bob,
     I am not a reviewer, just a tiny comments that you may need to remove the unnecessary empty line. Thanks.
-Lin

src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 49:

> 47:     private long processUsageTicks = 0; // used for process cpu load calculation
> 48:     private long processTotalTicks = 0; // used for process cpu load calculation
> 49: 

I think this empty line could be removed

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

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

From david.holmes at oracle.com  Wed Jul  7 06:48:34 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 7 Jul 2021 16:48:34 +1000
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers
In-Reply-To: <Oztz1S6KBFo5AqoFlHzl3_JhIjeLT-3XoFpYqwuqyzE=.945144cf-9244-4655-884a-d9a2ea299791@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
 <TMQT6hNemMVFFeyTDoACN00jGYZBoNdUM5eRdDE0Q00=.e980b97b-eff0-4165-aeff-3d803a26e408@github.com>
 <Oztz1S6KBFo5AqoFlHzl3_JhIjeLT-3XoFpYqwuqyzE=.945144cf-9244-4655-884a-d9a2ea299791@github.com>
Message-ID: <dfa04925-ded0-b3e5-9e41-636a08be72bf@oracle.com>

On 7/07/2021 2:37 pm, xpbob wrote:
> On Wed, 7 Jul 2021 04:29:01 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Why did you create a new PR ??
> 
> bug description changed?
> update the commit info.

There was no reason to create a new PR.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4702
> 

From ysuenaga at openjdk.java.net  Wed Jul  7 07:55:11 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 7 Jul 2021 07:55:11 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v2]
In-Reply-To: <Es2CE3klhEM7pEm81t_hQ9lmjPHKcAXcTe2shLO4qjo=.b0b0b1d1-f97f-4abe-8753-bed56ed48843@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
 <Es2CE3klhEM7pEm81t_hQ9lmjPHKcAXcTe2shLO4qjo=.b0b0b1d1-f97f-4abe-8753-bed56ed48843@github.com>
Message-ID: <ilAarCAwV6rkufRpaKKJVDtLwpnKXcDY2O3B-LXyAII=.47d95741-8d61-4f96-8f30-1cf72ffb6612@github.com>

On Wed, 7 Jul 2021 07:51:49 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

>> ?ocess cpu usage in containers
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove empty line

In HotSpot, CPU usage for JVM would be calculated at `get_jvm_tickes()` in os_perf_linux.cpp . It refers `/proc/self/stat` - should we refer it in same way?

I discussed about similar issue in #4299 , then we came to an agreement that we should refactor that HotSpot and JMX should share the code. Of course you can fix JMX only in this PR, but it still uses different implementation from HotSpot. I prefer to fix it in code consolidation between HotSpot and JMX.

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

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

From github.com+7837910+xpbob at openjdk.java.net  Wed Jul  7 07:55:10 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Wed, 7 Jul 2021 07:55:10 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v2]
In-Reply-To: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
Message-ID: <Es2CE3klhEM7pEm81t_hQ9lmjPHKcAXcTe2shLO4qjo=.b0b0b1d1-f97f-4abe-8753-bed56ed48843@github.com>

> ?ocess cpu usage in containers

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

  remove empty line

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4702/files
  - new: https://git.openjdk.java.net/jdk/pull/4702/files/91aa779d..3693793e

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

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

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

From sgehwolf at openjdk.java.net  Wed Jul  7 08:34:47 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 7 Jul 2021 08:34:47 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v2]
In-Reply-To: <Es2CE3klhEM7pEm81t_hQ9lmjPHKcAXcTe2shLO4qjo=.b0b0b1d1-f97f-4abe-8753-bed56ed48843@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
 <Es2CE3klhEM7pEm81t_hQ9lmjPHKcAXcTe2shLO4qjo=.b0b0b1d1-f97f-4abe-8753-bed56ed48843@github.com>
Message-ID: <I28CzdcrjBIQdFSmclJ4vXBtqr_k72vRpJNLlFFpwUY=.b43717e3-0584-4e4a-b18f-fb8d457bbb87@github.com>

On Wed, 7 Jul 2021 07:55:10 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

>> ?ocess cpu usage in containers
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove empty line

This patch seems fine in principle, but I don't like the duplication. Right now, `getProcessUsageDividesTotal()` and `getUsageDividesTotal()` look almost the same, but use different fields to set. Perhaps pass a parameter whether or not it's a system/process load request and use the different setters accordingly. Same duplication between `getCpuLoad()` and `getProcessCpuLoad()`. The main difference seems to be how `usageNanos` are being retrieved.

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

Changes requested by sgehwolf (Reviewer).

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

From sgehwolf at openjdk.java.net  Wed Jul  7 10:34:51 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 7 Jul 2021 10:34:51 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v2]
In-Reply-To: <ilAarCAwV6rkufRpaKKJVDtLwpnKXcDY2O3B-LXyAII=.47d95741-8d61-4f96-8f30-1cf72ffb6612@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
 <Es2CE3klhEM7pEm81t_hQ9lmjPHKcAXcTe2shLO4qjo=.b0b0b1d1-f97f-4abe-8753-bed56ed48843@github.com>
 <ilAarCAwV6rkufRpaKKJVDtLwpnKXcDY2O3B-LXyAII=.47d95741-8d61-4f96-8f30-1cf72ffb6612@github.com>
Message-ID: <lsKHazLYPl_l3Y1LTzobf3Xk4KC1zq8A8wHeyhbkWCQ=.94a90550-ba13-4da5-a64f-74f2f3f9fb9d@github.com>

On Wed, 7 Jul 2021 07:50:51 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> In HotSpot, CPU usage for JVM would be calculated at `get_jvm_tickes()` in os_perf_linux.cpp . It refers `/proc/self/stat` - should we refer it in same way?
> 
> I discussed about similar issue in #4299 , then we came to an agreement that we should refactor that HotSpot and JMX should share the code. Of course you can fix JMX only in this PR, but it still uses different implementation from HotSpot. I prefer to fix it in code consolidation between HotSpot and JMX.

Yes, we need a bug to track this work (or at least decide on a plan of action - if any). I wouldn't conflate this into this bug, though as it's not clear whether or not JFR/thread dumps should report container values. I'll try to create a bug for this consolidation effort today.

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

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

From sgehwolf at openjdk.java.net  Wed Jul  7 10:37:51 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 7 Jul 2021 10:37:51 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v2]
In-Reply-To: <I28CzdcrjBIQdFSmclJ4vXBtqr_k72vRpJNLlFFpwUY=.b43717e3-0584-4e4a-b18f-fb8d457bbb87@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
 <Es2CE3klhEM7pEm81t_hQ9lmjPHKcAXcTe2shLO4qjo=.b0b0b1d1-f97f-4abe-8753-bed56ed48843@github.com>
 <I28CzdcrjBIQdFSmclJ4vXBtqr_k72vRpJNLlFFpwUY=.b43717e3-0584-4e4a-b18f-fb8d457bbb87@github.com>
Message-ID: <Jfhd1bpuOhmg0VOp9okSI6WaUJa2UZC6r_iYbn-8lyU=.9bd7ee2d-3a2e-422a-a499-6dc28fc658f4@github.com>

On Wed, 7 Jul 2021 08:31:22 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This patch seems fine in principle [...]

Let me revise this. It looks like imposing CPU limits via cpuset-cpus would go down a path which won't have this fixed with the current patch.

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

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

From coleenp at openjdk.java.net  Wed Jul  7 13:35:10 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 7 Jul 2021 13:35:10 GMT
Subject: RFR: 8269962: SA has unused Hashtable, Dictionary classes
In-Reply-To: <wnSTQEsZJsfjVweS27jWwU55kQyN3U5KLewT1upUX5E=.a3f634b4-eba1-4754-b406-e662095d6443@github.com>
References: <wnSTQEsZJsfjVweS27jWwU55kQyN3U5KLewT1upUX5E=.a3f634b4-eba1-4754-b406-e662095d6443@github.com>
Message-ID: <17Vyll0T_s8sQGC8070vcu9ZeLxX-Nf5Re0skIdi2k8=.99923ba2-abdc-4eb3-b48c-30f1d0783384@github.com>

On Wed, 7 Jul 2021 13:27:49 GMT, Coleen Phillimore <coleenp at openjdk.org> 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.

I also removed BinaryTreeDictionary left over from Metaspace and CMS.

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

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

From coleenp at openjdk.java.net  Wed Jul  7 13:35:10 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 7 Jul 2021 13:35:10 GMT
Subject: RFR: 8269962: SA has unused Hashtable, Dictionary classes
Message-ID: <wnSTQEsZJsfjVweS27jWwU55kQyN3U5KLewT1upUX5E=.a3f634b4-eba1-4754-b406-e662095d6443@github.com>

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.

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

Commit messages:
 - 8269962: SA has unused Hashtable, Dictionary classes

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

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

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: <wYhsBscH6ecnc22xvAhyt8Ib0r-Yz1UMcv_DgC_vTt4=.c23bfdfd-ac18-4e2c-badb-67b60351981c@github.com>
References: <wYhsBscH6ecnc22xvAhyt8Ib0r-Yz1UMcv_DgC_vTt4=.c23bfdfd-ac18-4e2c-badb-67b60351981c@github.com>
Message-ID: <L9SBBSQVENYmMi4luuFkBxXyD2do6JjG6Wsw7iSters=.3509c055-08b8-4da3-8752-cac48b4383e6@github.com>

On Wed, 7 Jul 2021 13:58:59 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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: <L9SBBSQVENYmMi4luuFkBxXyD2do6JjG6Wsw7iSters=.3509c055-08b8-4da3-8752-cac48b4383e6@github.com>
References: <wYhsBscH6ecnc22xvAhyt8Ib0r-Yz1UMcv_DgC_vTt4=.c23bfdfd-ac18-4e2c-badb-67b60351981c@github.com>
 <L9SBBSQVENYmMi4luuFkBxXyD2do6JjG6Wsw7iSters=.3509c055-08b8-4da3-8752-cac48b4383e6@github.com>
Message-ID: <oV6Fafm0aXj32dkLIUiYoRCRoxCjgbToGdnUXWpKRfw=.ecb31d64-e86f-4653-91ca-c809fd87632c@github.com>

On Wed, 7 Jul 2021 14:02:45 GMT, Markus Gr?nlund <mgronlun at openjdk.org> 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: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: <wYhsBscH6ecnc22xvAhyt8Ib0r-Yz1UMcv_DgC_vTt4=.c23bfdfd-ac18-4e2c-badb-67b60351981c@github.com>
References: <wYhsBscH6ecnc22xvAhyt8Ib0r-Yz1UMcv_DgC_vTt4=.c23bfdfd-ac18-4e2c-badb-67b60351981c@github.com>
Message-ID: <eMyrI2MsTtEyEKHnNWCvC6Q1bWfds47pgPg9RCUSKGk=.d533e4cd-ae01-452c-8433-f218cdebde57@github.com>

On Wed, 7 Jul 2021 13:58:59 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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 <dcubed at openjdk.org>
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 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: <wYhsBscH6ecnc22xvAhyt8Ib0r-Yz1UMcv_DgC_vTt4=.c23bfdfd-ac18-4e2c-badb-67b60351981c@github.com>

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 mchung at openjdk.java.net  Wed Jul  7 16:25:49 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 7 Jul 2021 16:25:49 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v8]
In-Reply-To: <7AYfiggiXSOnvK9Vi3mIUmJMT54MQqBQRygezjGvXPU=.33f0f6bb-0fa9-4f03-9151-c7c68afadbc1@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <imrXHsfJUsxhjLQpbPTeYPTKUff42FGED1cdeB76ST8=.d7c474cb-ebad-4f63-8f88-13494086e0e6@github.com>
 <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com>
 <7AYfiggiXSOnvK9Vi3mIUmJMT54MQqBQRygezjGvXPU=.33f0f6bb-0fa9-4f03-9151-c7c68afadbc1@github.com>
Message-ID: <TD8q3evwKPIVqbq6hTb4A7Oek3YuVLlb0qpvrvxkDus=.356e7fab-68e4-45d3-97f4-f8641eb57997@github.com>

On Wed, 7 Jul 2021 02:10:10 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Does "client changes" means changes involving src/java.desktop and test/java/awt?

src/java.desktop, test/java/awt, and test/javax/imageio

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

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

From mchung at openjdk.java.net  Wed Jul  7 17:10:56 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 7 Jul 2021 17:10:56 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v8]
In-Reply-To: <TD8q3evwKPIVqbq6hTb4A7Oek3YuVLlb0qpvrvxkDus=.356e7fab-68e4-45d3-97f4-f8641eb57997@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <imrXHsfJUsxhjLQpbPTeYPTKUff42FGED1cdeB76ST8=.d7c474cb-ebad-4f63-8f88-13494086e0e6@github.com>
 <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com>
 <7AYfiggiXSOnvK9Vi3mIUmJMT54MQqBQRygezjGvXPU=.33f0f6bb-0fa9-4f03-9151-c7c68afadbc1@github.com>
 <TD8q3evwKPIVqbq6hTb4A7Oek3YuVLlb0qpvrvxkDus=.356e7fab-68e4-45d3-97f4-f8641eb57997@github.com>
Message-ID: <5oJGpGnTSIbs8geLeAbp7aU6KWKkrDIgg4lpw-uJh10=.0ea96922-78ed-429c-9db1-ba92dd613549@github.com>

On Wed, 7 Jul 2021 16:22:25 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Hi Mandy, thanks for reviewing this. 
>> 
>>> I suggest to separate the client changes (both src and test) in a separate PR for the client review.
>> 
>> Does "client changes" means changes involving src/java.desktop and test/java/awt?
>> 
>>> src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java needs to be updated in JSR 166 upstream repo. Better to file a separate issue for this change to ensure that gets fixed in the upstream project.
>> 
>> Can you please paste a link for that? I'm not sure where I can find JSR 166 upstream repo..
>> 
>>> Nit: The above formatting (line 70-97) is inconsistent with the formatting in line 110-124. It'd be good to use the same formatting.
>> 
>> Restored.
>
>> Does "client changes" means changes involving src/java.desktop and test/java/awt?
> 
> src/java.desktop, test/java/awt, and test/javax/imageio

> > src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java needs to be updated in JSR 166 upstream repo. Better to file a separate issue for this change to ensure that gets fixed in the upstream project.
> 
> Can you please paste a link for that? I'm not sure where I can find JSR 166 upstream repo..

What I meant is to file a JBS issue for this change and revert the change in this patch.   That can be fixed when the next JSR 166 changes are imported to JDK. 

I wasn't sure if this is the right repo:  http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/

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

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

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: <cmczNJDphMQdTgMKPezycvV7vxNu0ZU3WvOZqn0acDk=.5b42524f-359e-4bed-9b3e-934e08d9e116@github.com>
References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com>
 <cmczNJDphMQdTgMKPezycvV7vxNu0ZU3WvOZqn0acDk=.5b42524f-359e-4bed-9b3e-934e08d9e116@github.com>
Message-ID: <G9xgKs9jf_WlMI5xbr-_2VbVD-WyhqfkhUNdrRwOtgo=.42d8927e-861f-4e34-815b-16203c8e8735@github.com>

On Wed, 7 Jul 2021 02:39:10 GMT, Lin Zang <lzang at openjdk.org> 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 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: <wnSTQEsZJsfjVweS27jWwU55kQyN3U5KLewT1upUX5E=.a3f634b4-eba1-4754-b406-e662095d6443@github.com>
References: <wnSTQEsZJsfjVweS27jWwU55kQyN3U5KLewT1upUX5E=.a3f634b4-eba1-4754-b406-e662095d6443@github.com>
Message-ID: <xz6Zsp1oLMwvctTFpFlL4BoxJIbc3K3olA1R6wYfICY=.139f17cd-64a3-4e73-8f39-a617e2ccb0f2@github.com>

On Wed, 7 Jul 2021 13:27:49 GMT, Coleen Phillimore <coleenp at openjdk.org> 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 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: <G9xgKs9jf_WlMI5xbr-_2VbVD-WyhqfkhUNdrRwOtgo=.42d8927e-861f-4e34-815b-16203c8e8735@github.com>
References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com>
 <cmczNJDphMQdTgMKPezycvV7vxNu0ZU3WvOZqn0acDk=.5b42524f-359e-4bed-9b3e-934e08d9e116@github.com>
 <G9xgKs9jf_WlMI5xbr-_2VbVD-WyhqfkhUNdrRwOtgo=.42d8927e-861f-4e34-815b-16203c8e8735@github.com>
Message-ID: <ECLnM1ooqgViyIAY1r9foS78_qMJuSiK2WFg12cB5U4=.3f250d5e-acff-4b15-a8af-53cdcb8a02a2@github.com>

On Wed, 7 Jul 2021 17:45:10 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <wnSTQEsZJsfjVweS27jWwU55kQyN3U5KLewT1upUX5E=.a3f634b4-eba1-4754-b406-e662095d6443@github.com>
References: <wnSTQEsZJsfjVweS27jWwU55kQyN3U5KLewT1upUX5E=.a3f634b4-eba1-4754-b406-e662095d6443@github.com>
Message-ID: <BadzjSaitGE6Zd4Ug8RYSpCUJ7WdEpn2L85HhAK8_6c=.e9cce7a1-a251-4411-aa91-ac04b2d0ce64@github.com>

On Wed, 7 Jul 2021 13:27:49 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <G9xgKs9jf_WlMI5xbr-_2VbVD-WyhqfkhUNdrRwOtgo=.42d8927e-861f-4e34-815b-16203c8e8735@github.com>
References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com>
 <cmczNJDphMQdTgMKPezycvV7vxNu0ZU3WvOZqn0acDk=.5b42524f-359e-4bed-9b3e-934e08d9e116@github.com>
 <G9xgKs9jf_WlMI5xbr-_2VbVD-WyhqfkhUNdrRwOtgo=.42d8927e-861f-4e34-815b-16203c8e8735@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 <cjplummer at openjdk.org> 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 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: <wnSTQEsZJsfjVweS27jWwU55kQyN3U5KLewT1upUX5E=.a3f634b4-eba1-4754-b406-e662095d6443@github.com>
References: <wnSTQEsZJsfjVweS27jWwU55kQyN3U5KLewT1upUX5E=.a3f634b4-eba1-4754-b406-e662095d6443@github.com>
Message-ID: <yXdxV9DD7mb2AUrqebkmACO2VWFk2zhJdncFxQRqbQM=.73832012-6cc0-4054-b9eb-6863cf254bdf@github.com>

On Wed, 7 Jul 2021 13:27:49 GMT, Coleen Phillimore <coleenp at openjdk.org> 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 jwilhelm at openjdk.java.net  Thu Jul  8 00:09:13 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 8 Jul 2021 00:09:13 GMT
Subject: RFR: Merge jdk17
Message-ID: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8269929: (test) Add diagnostic info to ProceessBuilder/Basic.java for unexpected output
 - 8269185: Directories in /opt/runtimepackagetest and /path/to/jdk-17 are different
 - 8269879: [PPC64] C2: Math.rint intrinsic uses wrong rounding mode
 - 8266036: class file for sun.misc.Contended not found
 - 8269772: [macos-aarch64] test compilation failed with "SocketException: No buffer space available"
 - 8268859: jshell throws exception while parsing illegal "case true"
 - 8269802: javac fails to compile nested pattern matching switches
 - 8269830: SA's vm object vtable matching code sometimes matches on incorrect type
 - 8268778: CDS check_excluded_classes needs DumpTimeTable_lock

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4713&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4713&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4713/files
  Stats: 1083 lines in 36 files changed: 629 ins; 278 del; 176 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4713.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4713/head:pull/4713

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

From jwilhelm at openjdk.java.net  Thu Jul  8 01:01:08 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 8 Jul 2021 01:01:08 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com>
References: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com>
Message-ID: <aR7I10NllN3IUYv2fFGqbNJiqNGHWOCGJbu1oPfkHnE=.3023ca05-f5a5-4053-a9aa-0a299da41680@github.com>

On Thu, 8 Jul 2021 00:01:43 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 270fbcb3
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/270fbcb3f5755baf045fa6dec3fba459d32c32e1
Stats:     1083 lines in 36 files changed: 629 ins; 278 del; 176 mod

Merge

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

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

From jwilhelm at openjdk.java.net  Thu Jul  8 01:01:07 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 8 Jul 2021 01:01:07 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com>
References: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com>
Message-ID: <T8ZKUYz_moDDFWXemuiH6AHfTv2rC1ysSDBJskzCknY=.3b17f7a7-8c39-4728-b06d-0a5cd4710a1a@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 180 commits:

 - Merge
 - 8264735: Make dynamic dump repeatable
   
   Reviewed-by: ccheung, iklam
 - 8269481: SctpMultiChannel never releases own file descriptor
   
   Reviewed-by: alanb, chegar
 - 8270027: ProblemList jdk/jfr/event/oldobject/TestObjectSize.java on macOS-x64
   
   Reviewed-by: mgronlun
 - 8267303: Replace MinObjectAlignmentSize usages for non-Java heap objects
   
   Reviewed-by: kbarrett, tschatzl, minqi
 - 8268635: Corrupt oop in ClassLoaderData
   
   Reviewed-by: iklam, dholmes
 - 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
 - 8269761: idea.sh missing .exe suffix when invoking javac on WSL
   
   Reviewed-by: mcimadamore, erikj
 - 8269294: Verify_before/after_young_collection should execute all verification
   
   Reviewed-by: iwalulya, kbarrett
 - 8269908: Move MemoryService::track_memory_usage call into G1MonitoringScope
   
   Reviewed-by: ayang, kbarrett
 - ... and 170 more: https://git.openjdk.java.net/jdk/compare/c812bbbe...e5695159

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

Changes: https://git.openjdk.java.net/jdk/pull/4713/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4713&range=01
  Stats: 46991 lines in 850 files changed: 21189 ins; 22881 del; 2921 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4713.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4713/head:pull/4713

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

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: <wnSTQEsZJsfjVweS27jWwU55kQyN3U5KLewT1upUX5E=.a3f634b4-eba1-4754-b406-e662095d6443@github.com>
References: <wnSTQEsZJsfjVweS27jWwU55kQyN3U5KLewT1upUX5E=.a3f634b4-eba1-4754-b406-e662095d6443@github.com>
Message-ID: <d7xdFA_kmifNW-StHo1jTZ-wuh8ki0t0JXhUUNM0ThE=.4bc83100-62f0-4787-beb6-230e479a80b0@github.com>

On Wed, 7 Jul 2021 13:27:49 GMT, Coleen Phillimore <coleenp at openjdk.org> 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 github.com+7837910+xpbob at openjdk.java.net  Thu Jul  8 02:48:09 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Thu, 8 Jul 2021 02:48:09 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v3]
In-Reply-To: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
Message-ID: <TpKLBrp1k1yX_HSkddmRtcchrhGvSz7w8Yi261e37q0=.c96a872c-b80e-4262-88ea-1501a107133c@github.com>

> ?ocess cpu usage in containers

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

  add cpuset-cpus support

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4702/files
  - new: https://git.openjdk.java.net/jdk/pull/4702/files/3693793e..f9dadf7f

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

  Stats: 52 lines in 1 file changed: 18 ins; 20 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4702.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4702/head:pull/4702

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

From github.com+7837910+xpbob at openjdk.java.net  Thu Jul  8 02:51:09 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Thu, 8 Jul 2021 02:51:09 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v4]
In-Reply-To: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
Message-ID: <oiZj95VoY09LAdXODZ_4qZOAj8Rhiuuxo6YnaRX4jBg=.ea045cef-8471-45d6-8264-45c59f2a4e74@github.com>

> ?ocess cpu usage in containers

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

  remove whitespace

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4702/files
  - new: https://git.openjdk.java.net/jdk/pull/4702/files/f9dadf7f..f5ccb86c

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

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

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

From yyang at openjdk.java.net  Thu Jul  8 03:12:26 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 8 Jul 2021 03:12:26 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.base [v8]
In-Reply-To: <5oJGpGnTSIbs8geLeAbp7aU6KWKkrDIgg4lpw-uJh10=.0ea96922-78ed-429c-9db1-ba92dd613549@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <imrXHsfJUsxhjLQpbPTeYPTKUff42FGED1cdeB76ST8=.d7c474cb-ebad-4f63-8f88-13494086e0e6@github.com>
 <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com>
 <7AYfiggiXSOnvK9Vi3mIUmJMT54MQqBQRygezjGvXPU=.33f0f6bb-0fa9-4f03-9151-c7c68afadbc1@github.com>
 <TD8q3evwKPIVqbq6hTb4A7Oek3YuVLlb0qpvrvxkDus=.356e7fab-68e4-45d3-97f4-f8641eb57997@github.com>
 <5oJGpGnTSIbs8geLeAbp7aU6KWKkrDIgg4lpw-uJh10=.0ea96922-78ed-429c-9db1-ba92dd613549@github.com>
Message-ID: <zuVoAYcrfUuDsT-IGeI7p8ui3aDwbUe48fdQJVqF20A=.e0854d3d-47b2-4e31-96ee-ebf150e8f1dd@github.com>

On Wed, 7 Jul 2021 17:08:19 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> Does "client changes" means changes involving src/java.desktop and test/java/awt?
>> 
>> src/java.desktop, test/java/awt, and test/javax/imageio
>
>> > src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java needs to be updated in JSR 166 upstream repo. Better to file a separate issue for this change to ensure that gets fixed in the upstream project.
>> 
>> Can you please paste a link for that? I'm not sure where I can find JSR 166 upstream repo..
> 
> What I meant is to file a JBS issue for this change and revert the change in this patch.   That can be fixed when the next JSR 166 changes are imported to JDK. 
> 
> I wasn't sure if this is the right repo:  http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/

Okay. I've filed https://bugs.openjdk.java.net/browse/JDK-8270057 and https://bugs.openjdk.java.net/browse/JDK-8270058 for JSR 166 and client code respectively. These codes have been restored.

(Sorry for force-pushing, my mistake..)

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

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

From yyang at openjdk.java.net  Thu Jul  8 03:12:24 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 8 Jul 2021 03:12:24 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.base [v11]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  restore JSR166; restore java.desktop

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/903f0305..a9e7dbc8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=09-10

  Stats: 49 lines in 7 files changed: 24 ins; 7 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

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

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: <nmyOEwWa92oMDE2n6Se9aXOUvZbtW-qejOE4cZyHw84=.13389991-f859-4d78-904f-8b3a25ed50f0@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:

  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: <nmyOEwWa92oMDE2n6Se9aXOUvZbtW-qejOE4cZyHw84=.13389991-f859-4d78-904f-8b3a25ed50f0@github.com>
References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com>
 <nmyOEwWa92oMDE2n6Se9aXOUvZbtW-qejOE4cZyHw84=.13389991-f859-4d78-904f-8b3a25ed50f0@github.com>
Message-ID: <G3nMZWrkV_CeA6Pdv4zZuMvJ26Z6LBs5Fcyr4u-5tHw=.a734da63-545c-4586-92bc-9ae77d316747@github.com>

On Thu, 8 Jul 2021 03:28:10 GMT, Lin Zang <lzang at openjdk.org> 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: <HqAmVf6bYSSZBgTzS4DPW9r4Gkw0Pjv242ENUs_Qp3k=.e03e69a2-3371-4f62-9b5e-82f6d2adc0f5@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:

  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 github.com+7837910+xpbob at openjdk.java.net  Thu Jul  8 03:50:51 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Thu, 8 Jul 2021 03:50:51 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v2]
In-Reply-To: <Jfhd1bpuOhmg0VOp9okSI6WaUJa2UZC6r_iYbn-8lyU=.9bd7ee2d-3a2e-422a-a499-6dc28fc658f4@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
 <Es2CE3klhEM7pEm81t_hQ9lmjPHKcAXcTe2shLO4qjo=.b0b0b1d1-f97f-4abe-8753-bed56ed48843@github.com>
 <I28CzdcrjBIQdFSmclJ4vXBtqr_k72vRpJNLlFFpwUY=.b43717e3-0584-4e4a-b18f-fb8d457bbb87@github.com>
 <Jfhd1bpuOhmg0VOp9okSI6WaUJa2UZC6r_iYbn-8lyU=.9bd7ee2d-3a2e-422a-a499-6dc28fc658f4@github.com>
Message-ID: <8bhPcHa3Opgk3zDJwZ3i0ahdnflKyy5A5G-0DgRU58k=.357d0227-6280-46c0-b8bb-60c5e1841755@github.com>

On Wed, 7 Jul 2021 10:34:51 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > This patch seems fine in principle [...]
> 
> Let me revise this. It looks like imposing CPU limits via cpuset-cpus would go down a path which won't have this fixed with the current patch.

use (getProcessCpuLoad0() * totalCPUs / containerCPUs) for CPU limits via cpuset-cpus

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

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

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: <HqAmVf6bYSSZBgTzS4DPW9r4Gkw0Pjv242ENUs_Qp3k=.e03e69a2-3371-4f62-9b5e-82f6d2adc0f5@github.com>
References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com>
 <HqAmVf6bYSSZBgTzS4DPW9r4Gkw0Pjv242ENUs_Qp3k=.e03e69a2-3371-4f62-9b5e-82f6d2adc0f5@github.com>
Message-ID: <zlG8_yQnwBEYnTFH3HS77jr58Nyhlt8adgYxmd3mG_o=.8d242def-50d6-4f45-9e31-54676eaa639d@github.com>

On Thu, 8 Jul 2021 03:47:09 GMT, Lin Zang <lzang at openjdk.org> 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 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: <HqAmVf6bYSSZBgTzS4DPW9r4Gkw0Pjv242ENUs_Qp3k=.e03e69a2-3371-4f62-9b5e-82f6d2adc0f5@github.com>
References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com>
 <HqAmVf6bYSSZBgTzS4DPW9r4Gkw0Pjv242ENUs_Qp3k=.e03e69a2-3371-4f62-9b5e-82f6d2adc0f5@github.com>
Message-ID: <Vp_UoJJWnnX43Jwq7B1JnZ7cAIi8Vl51WN-akLDpj9s=.73711b64-d99b-442a-b47c-7f7e1d52eb95@github.com>

On Thu, 8 Jul 2021 03:47:09 GMT, Lin Zang <lzang at openjdk.org> 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 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: <HqAmVf6bYSSZBgTzS4DPW9r4Gkw0Pjv242ENUs_Qp3k=.e03e69a2-3371-4f62-9b5e-82f6d2adc0f5@github.com>
References: <8OEuY2xdWGM14oUoudFKw4BSYFXGMomxuXgyp_XKPD0=.0dcc7a1f-87d7-49d7-bea0-2cedc3b64d75@github.com>
 <HqAmVf6bYSSZBgTzS4DPW9r4Gkw0Pjv242ENUs_Qp3k=.e03e69a2-3371-4f62-9b5e-82f6d2adc0f5@github.com>
Message-ID: <M4MzCUs6-L17_Qz4ibkKhJHKmkxqfsLGqIBtMWemCtI=.17a412a5-e4dd-46a4-9286-cd1b7e8a41c3@github.com>

On Thu, 8 Jul 2021 03:47:09 GMT, Lin Zang <lzang at openjdk.org> 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: <W-GBxcdgO11GBqRnwa9beLsFafk-JPQrBGndQS9pKx4=.84a76815-033c-4416-b4d8-0358640103ae@github.com>

On Tue, 6 Jul 2021 02:55:37 GMT, Lin Zang <lzang at openjdk.org> 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 <lzang at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
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 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: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>

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 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: <wnSTQEsZJsfjVweS27jWwU55kQyN3U5KLewT1upUX5E=.a3f634b4-eba1-4754-b406-e662095d6443@github.com>
References: <wnSTQEsZJsfjVweS27jWwU55kQyN3U5KLewT1upUX5E=.a3f634b4-eba1-4754-b406-e662095d6443@github.com>
Message-ID: <tneiDP6dlA2CtiyJjmTiNeQN-4VwCS4Gl-Fn5V8HQQ4=.b2c0eb52-2c8f-4e2f-8a26-be36bc572ac0@github.com>

On Wed, 7 Jul 2021 13:27:49 GMT, Coleen Phillimore <coleenp at openjdk.org> 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 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: <wnSTQEsZJsfjVweS27jWwU55kQyN3U5KLewT1upUX5E=.a3f634b4-eba1-4754-b406-e662095d6443@github.com>
References: <wnSTQEsZJsfjVweS27jWwU55kQyN3U5KLewT1upUX5E=.a3f634b4-eba1-4754-b406-e662095d6443@github.com>
Message-ID: <qdYCADgPvKeWolXHUze__zgQHmhq6jU1cPtUHqXbhNs=.61a2fc97-ac5c-4ae7-8aa4-d48901fa7ad6@github.com>

On Wed, 7 Jul 2021 13:27:49 GMT, Coleen Phillimore <coleenp at openjdk.org> 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 <coleenp at openjdk.org>
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 sspitsyn at openjdk.java.net  Thu Jul  8 19:18:04 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 8 Jul 2021 19:18:04 GMT
Subject: [jdk17] RFR: 8269558: fix of JDK-8252657 missed to update history at
 the end of JVM TI spec
Message-ID: <xOZkzqOcWzsi3KMyPz_2MLnmsjLweaUc-aoCuLUE3FU=.651582cd-6fc0-4723-bda2-949b306854f1@github.com>

The fix of:
   8252657 JVMTI agent is not unloaded when Agent_OnAttach is failed
did not update the JVM TI spec history at the end of document. 
This PR adds missed item to the JVM TI spec history.

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

Commit messages:
 - 8269558: fix of JDK-8252657 missed to update history at the end of JVM TI spec

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

PR: https://git.openjdk.java.net/jdk17/pull/233

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: <WtlSeQbHe3pa1lg5SqWHMZvtA98kINNl-xO4xOI9fRo=.f9c584d3-0c5d-4646-8622-ee4a54c707c6@github.com>
References: <WtlSeQbHe3pa1lg5SqWHMZvtA98kINNl-xO4xOI9fRo=.f9c584d3-0c5d-4646-8622-ee4a54c707c6@github.com>
Message-ID: <-tiyR4al6BXPZEmk5ZggZ-tAcB9dUfRlymp18RAIP-E=.c413592d-caa6-4e6d-9038-3a87b6951e32@github.com>

On Thu, 8 Jul 2021 19:17:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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
Message-ID: <WtlSeQbHe3pa1lg5SqWHMZvtA98kINNl-xO4xOI9fRo=.f9c584d3-0c5d-4646-8622-ee4a54c707c6@github.com>

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 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: <WtlSeQbHe3pa1lg5SqWHMZvtA98kINNl-xO4xOI9fRo=.f9c584d3-0c5d-4646-8622-ee4a54c707c6@github.com>
 <-tiyR4al6BXPZEmk5ZggZ-tAcB9dUfRlymp18RAIP-E=.c413592d-caa6-4e6d-9038-3a87b6951e32@github.com>
Message-ID: <IWKx3TOYxjDKCkbsNY5GhKbnjvTEdL74rk64cFravhc=.b36ffb3e-05ef-4ff3-b47e-c0b161b93811@github.com>

On Thu, 8 Jul 2021 19:21:20 GMT, Mikael Vidstedt <mikael at openjdk.org> 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: <WtlSeQbHe3pa1lg5SqWHMZvtA98kINNl-xO4xOI9fRo=.f9c584d3-0c5d-4646-8622-ee4a54c707c6@github.com>
References: <WtlSeQbHe3pa1lg5SqWHMZvtA98kINNl-xO4xOI9fRo=.f9c584d3-0c5d-4646-8622-ee4a54c707c6@github.com>
Message-ID: <-Fsi2b-BSGPy8rZYTYufdzrV4bFHbIxGMnxuT3kXE80=.f340fb80-8162-415e-a7f7-9f55eedb1e4f@github.com>

On Thu, 8 Jul 2021 19:17:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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 <dcubed at openjdk.org>
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 dcubed at openjdk.java.net  Thu Jul  8 19:33:57 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 8 Jul 2021 19:33:57 GMT
Subject: [jdk17] RFR: 8269558: fix of JDK-8252657 missed to update history
 at the end of JVM TI spec
In-Reply-To: <xOZkzqOcWzsi3KMyPz_2MLnmsjLweaUc-aoCuLUE3FU=.651582cd-6fc0-4723-bda2-949b306854f1@github.com>
References: <xOZkzqOcWzsi3KMyPz_2MLnmsjLweaUc-aoCuLUE3FU=.651582cd-6fc0-4723-bda2-949b306854f1@github.com>
Message-ID: <kRfk9gVPafNZDGC62J63FhveCGcC3UAdK6mU4D3weBo=.c2186278-06e9-4930-ad38-837c741612d7@github.com>

On Thu, 8 Jul 2021 19:11:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The fix of:
>    8252657 JVMTI agent is not unloaded when Agent_OnAttach is failed
> did not update the JVM TI spec history at the end of document. 
> This PR adds missed item to the JVM TI spec history.

Thumbs up. This looks like a trivial fix to me.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/233

From cjplummer at openjdk.java.net  Thu Jul  8 19:48:54 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 8 Jul 2021 19:48:54 GMT
Subject: [jdk17] RFR: 8269558: fix of JDK-8252657 missed to update history
 at the end of JVM TI spec
In-Reply-To: <xOZkzqOcWzsi3KMyPz_2MLnmsjLweaUc-aoCuLUE3FU=.651582cd-6fc0-4723-bda2-949b306854f1@github.com>
References: <xOZkzqOcWzsi3KMyPz_2MLnmsjLweaUc-aoCuLUE3FU=.651582cd-6fc0-4723-bda2-949b306854f1@github.com>
Message-ID: <ybfKDHjhTidLvKgqIsLshnJXeNhN-3XRbWsxoRIraFY=.446d4c89-2f21-4f2b-bfb3-f28af787003b@github.com>

On Thu, 8 Jul 2021 19:11:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The fix of:
>    8252657 JVMTI agent is not unloaded when Agent_OnAttach is failed
> did not update the JVM TI spec history at the end of document. 
> This PR adds missed item to the JVM TI spec history.

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/233

From mchung at openjdk.java.net  Thu Jul  8 19:49:59 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 8 Jul 2021 19:49:59 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.base [v11]
In-Reply-To: <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
Message-ID: <rO7C7Dyhzdh1fAomVfcSvFQ0DiLPoVMobB64YN17FKE=.aa256d50-5264-4060-b43e-4258751aa809@github.com>

On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   restore JSR166; restore java.desktop

Looks good.  Thanks for separating the other files from this patch.   I also did a test run on tier1-3 that looks clean.

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

Marked as reviewed by mchung (Reviewer).

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

From sspitsyn at openjdk.java.net  Thu Jul  8 21:52:54 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 8 Jul 2021 21:52:54 GMT
Subject: [jdk17] RFR: 8269558: fix of JDK-8252657 missed to update history
 at the end of JVM TI spec
In-Reply-To: <xOZkzqOcWzsi3KMyPz_2MLnmsjLweaUc-aoCuLUE3FU=.651582cd-6fc0-4723-bda2-949b306854f1@github.com>
References: <xOZkzqOcWzsi3KMyPz_2MLnmsjLweaUc-aoCuLUE3FU=.651582cd-6fc0-4723-bda2-949b306854f1@github.com>
Message-ID: <mNngDPEMvdax-vidsBsvyq2_5ZmXxu7UX0eerYnkpBg=.8ad7c884-abd4-4920-92b5-87c86e7113b3@github.com>

On Thu, 8 Jul 2021 19:11:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The fix of:
>    8252657 JVMTI agent is not unloaded when Agent_OnAttach is failed
> did not update the JVM TI spec history at the end of document. 
> This PR adds missed item to the JVM TI spec history.

Dan and Chris, thank you for quick review!

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

PR: https://git.openjdk.java.net/jdk17/pull/233

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: <NDjsBIfcu8h-e21OTEioLI1pMeNgVzQmywL_1sD_JHk=.1daadc62-0a09-45b1-805a-0da9849ffc65@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <NDjsBIfcu8h-e21OTEioLI1pMeNgVzQmywL_1sD_JHk=.1daadc62-0a09-45b1-805a-0da9849ffc65@github.com>
Message-ID: <kksf6G3ES3dDnVTUgQCO-KtPaN33UVJuKPDku1L1iaI=.dcf28313-0a10-4a71-a76c-6c6649de81f5@github.com>

On Fri, 25 Jun 2021 06:22:37 GMT, Thomas Stuefe <stuefe at openjdk.org> 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: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
Message-ID: <mA1NM8SyYPXtJpGWTEEpHhM6d-Cm6Zbqd-bpFhGHeXU=.a9a70458-faaf-4d49-89e3-47abd3585c5e@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 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: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
Message-ID: <xcpJiUFEX5VMzuDgXJYuX8M_G4wcWrFqDkv8vLvXfjk=.474ed7a5-bf44-4734-aaaa-c6108f85b1c4@github.com>

> 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 ngasson at openjdk.java.net  Fri Jul  9 08:43:10 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 9 Jul 2021 08:43:10 GMT
Subject: RFR: 8270067: AArch64: several clhsdb tests fail with -Xcomp
Message-ID: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>

Running the jtreg test serviceability/sa/ClhsdbWhere.java with -Xcomp
-XX:-TieredCompilation fails with the following exception:

  Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
  java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
          at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.createStackValue(CompiledVFrame.java:270)
          at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getLocals(CompiledVFrame.java:107)
          at jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTMLForJavaStackTrace(HTMLGenerator.java:1937)
          at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$43.doit(CommandProcessor.java:1573)
          at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2090)
          at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2060)

The oop map for the frame being inspected is:

   ScopeDesc(pc=0x0000ffff8957e000 offset=140):
   jdk.test.lib.apps.LingeredApp::steadyState at 7 (line 536)
   Locals
    - l0: empty
    - l1: reg rfp [58],oop
    - l2: empty
   Monitor stack
    - @0: monitor{reg rfp [58],oop,stack[16]}

But RegisterMap::getLocation() returns a null Address for register
58 (=RFP).

This patch fixes two problems: the fp VMReg value used in
AARCH64Frame::updateMapWithSavedLink should be 29<<1 not 29 because a
VMReg has two slots in a 64-bit VM.  The other bug is that
RegisterMap::setLocation and getLocation calculate the long
locationValid mask using (1 << (i % locationValidTypeSize)) where i and
locationValidTypeSize are both int.  We need to do this calculation as a
long if i % locationValidTypeSize can be > 32.  There's no failure on
x86_64 because that only has 16 integer registers.

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

Commit messages:
 - 8270067: AArch64: several clhsdb tests fail with -Xcomp

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

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

From sgehwolf at openjdk.java.net  Fri Jul  9 14:22:54 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 9 Jul 2021 14:22:54 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v4]
In-Reply-To: <oiZj95VoY09LAdXODZ_4qZOAj8Rhiuuxo6YnaRX4jBg=.ea045cef-8471-45d6-8264-45c59f2a4e74@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
 <oiZj95VoY09LAdXODZ_4qZOAj8Rhiuuxo6YnaRX4jBg=.ea045cef-8471-45d6-8264-45c59f2a4e74@github.com>
Message-ID: <Js4dpsvqTBJrTjtsFSDwOqUph68m-cHhdzejq-TpnA0=.85787a87-3ff0-4978-897c-b0dd652f83db@github.com>

On Thu, 8 Jul 2021 02:51:09 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

>> ?ocess cpu usage in containers
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove whitespace

Thanks for the update. `getProcessCpuLoad()` and `getCpuLoad()` looks way too similar to me. Is there a way to make them more generic and do the process vs. system paths as needed? I think there is.

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

Changes requested by sgehwolf (Reviewer).

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

From sspitsyn at openjdk.java.net  Sun Jul 11 08:13:30 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sun, 11 Jul 2021 08:13:30 GMT
Subject: [jdk17] RFR: 8269558: fix of JDK-8252657 missed to update history
 at the end of JVM TI spec [v2]
In-Reply-To: <xOZkzqOcWzsi3KMyPz_2MLnmsjLweaUc-aoCuLUE3FU=.651582cd-6fc0-4723-bda2-949b306854f1@github.com>
References: <xOZkzqOcWzsi3KMyPz_2MLnmsjLweaUc-aoCuLUE3FU=.651582cd-6fc0-4723-bda2-949b306854f1@github.com>
Message-ID: <xGbk1BaTsjqTOUXln2DJfyiysDthwwN7QrydKGj08ew=.dc1fd13c-393d-472e-86b1-3c7653fe6749@github.com>

> The fix of:
>    8252657 JVMTI agent is not unloaded when Agent_OnAttach is failed
> did not update the JVM TI spec history at the end of document. 
> This PR adds missed item to the JVM TI spec history.

Serguei Spitsyn 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
 - 8269558: fix of JDK-8252657 missed to update history at the end of JVM TI spec

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/233/files
  - new: https://git.openjdk.java.net/jdk17/pull/233/files/7a5b9b3b..82f97000

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

  Stats: 828 lines in 37 files changed: 668 ins; 67 del; 93 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/233.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/233/head:pull/233

PR: https://git.openjdk.java.net/jdk17/pull/233

From sspitsyn at openjdk.java.net  Sun Jul 11 11:07:01 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sun, 11 Jul 2021 11:07:01 GMT
Subject: [jdk17] Integrated: 8269558: fix of JDK-8252657 missed to update
 history at the end of JVM TI spec
In-Reply-To: <xOZkzqOcWzsi3KMyPz_2MLnmsjLweaUc-aoCuLUE3FU=.651582cd-6fc0-4723-bda2-949b306854f1@github.com>
References: <xOZkzqOcWzsi3KMyPz_2MLnmsjLweaUc-aoCuLUE3FU=.651582cd-6fc0-4723-bda2-949b306854f1@github.com>
Message-ID: <WpD0bcSmsj_herzrpSqcEJmWHEdEnslGsSGB20ezcj8=.d13204b8-23de-4d7e-8aab-db3f4836d6e6@github.com>

On Thu, 8 Jul 2021 19:11:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The fix of:
>    8252657 JVMTI agent is not unloaded when Agent_OnAttach is failed
> did not update the JVM TI spec history at the end of document. 
> This PR adds missed item to the JVM TI spec history.

This pull request has now been integrated.

Changeset: 3d82b0e6
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/3d82b0e634583f4bc01ceece9dd82fc00fd6f9c3
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8269558: fix of JDK-8252657 missed to update history at the end of JVM TI spec

Reviewed-by: dcubed, cjplummer

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

PR: https://git.openjdk.java.net/jdk17/pull/233

From apangin at openjdk.java.net  Sun Jul 11 22:24:58 2021
From: apangin at openjdk.java.net (Andrei Pangin)
Date: Sun, 11 Jul 2021 22:24:58 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v3]
In-Reply-To: <jfohRNi3z8LnjHcxEzmJNhuO7nKKEtBY5bhR-8uycVI=.b410939d-7166-4ea7-a046-c8ca8f2dcc93@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <jfohRNi3z8LnjHcxEzmJNhuO7nKKEtBY5bhR-8uycVI=.b410939d-7166-4ea7-a046-c8ca8f2dcc93@github.com>
Message-ID: <zEfeAKmEcH3klTLjoOc4ww7yMMlaQmasB0LGXYFREDM=.911f044b-665a-4ca1-a604-66e1270ef191@github.com>

On Fri, 18 Jun 2021 08:56:32 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime stub (like arraycopy), a vtable stub, or the prolog of a compiled method,  it wouldn't be able to detect the sender (caller) frame for multiple reasons. This patch fixes these cases through adding CodeBlob-specific frame parser which are in the best position to know how a frame is setup.
>> 
>> The following examples have been profiled with honest-profiler which uses `AsyncGetCallTrace`.
>> 
>> # `Prof1`
>> 
>> public class Prof1 {
>> 
>>     public static void main(String[] args) {
>>         StringBuilder sb = new StringBuilder();
>>         for (int i = 0; i < 1000000; i++) {
>>             sb.append("ab");
>>             sb.delete(0, 1);
>>         }
>>         System.out.println(sb.length());
>>     }
>> }
>> 
>> 
>> - Baseline:
>> 
>> Flat Profile (by method):
>>         (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>>         (t  0.5,s  0.2) Prof1::main
>>         (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>>         (t  0.0,s  0.0) java.lang.String::getBytes
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>>         (t  0.0,s  0.0) java.lang.StringBuilder::delete
>>         (t  0.2,s  0.0) java.lang.StringBuilder::append
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>> 
>> - With `StubRoutinesBlob::FrameParser`:
>> 
>> Flat Profile (by method):
>>         (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>         (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>>         (t 99.8,s  0.2) Prof1::main
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>>         (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>>         (t 98.8,s  0.0) java.lang.StringBuilder::append
>>         (t  0.9,s  0.0) java.lang.StringBuilder::delete
>> 
>> 
>> # `Prof2`
>> 
>> import java.util.function.Supplier;
>> 
>> public class Prof2 {
>> 
>>     public static void main(String[] args) {
>>         var rand = new java.util.Random(0);
>>         Supplier[] suppliers = {
>>                 () -> 0,
>>                 () -> 1,
>>                 () -> 2,
>>                 () -> 3,
>>         };
>> 
>>         long sum = 0;
>>         for (int i = 0; i >= 0; i++) {
>>             sum += (int)suppliers[i % suppliers.length].get();
>>         }
>>     }
>> }
>> 
>> 
>> - Baseline:
>> 
>> Flat Profile (by method):
>>         (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>>         (t 39.2,s 35.2) Prof2::main
>>         (t  1.4,s  1.4) Prof2::lambda$main$3
>>         (t  1.0,s  1.0) Prof2::lambda$main$2
>>         (t  0.9,s  0.9) Prof2::lambda$main$1
>>         (t  0.7,s  0.7) Prof2::lambda$main$0
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) java.lang.Thread::exit
>>         (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>>         (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>>         (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>>         (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
>> 
>> 
>> - With `VtableBlob::FrameParser` and `nmethod::FrameParser`:
>> 
>> Flat Profile (by method):
>>         (t 74.1,s 70.3) Prof2::main
>>         (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>>         (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>>         (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>>         (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>>         (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>>         (t  1.2,s  1.2) Prof2::lambda$main$2
>>         (t  0.9,s  0.9) Prof2::lambda$main$3
>>         (t  0.9,s  0.9) Prof2::lambda$main$1
>>         (t  0.7,s  0.7) Prof2::lambda$main$0
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>
> Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

Hi Ludovic,

Thank you for working on this long-standing bug.
I like the idea of the proposed solution, but unfortunately it cannot be applied as is. Since the stack walking code runs inside a signal handler, it is very limited in things it can do. In particular, it must not allocate, acquire locks, etc. In your implementation, FrameParser does allocate though.

The issue is not just theoretical: when I ran JDK with this patch with async-profiler, I immediately got the following deadlock:


(gdb) bt
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007fa2363ca025 in __GI___pthread_mutex_lock (mutex=0x7fa235da5440 <tc_mutex>)
    at ../nptl/pthread_mutex_lock.c:80
#2  0x00007fa235696cb6 in ThreadCritical::ThreadCritical() () from /usr/java/jdk-18/lib/server/libjvm.so
#3  0x00007fa234b6fe53 in Chunk::next_chop() () from /usr/java/jdk-18/lib/server/libjvm.so
#4  0x00007fa234e88523 in frame::safe_for_sender(JavaThread*) () from /usr/java/jdk-18/lib/server/libjvm.so
#5  0x00007fa234e838f2 in vframeStreamForte::forte_next() () from /usr/java/jdk-18/lib/server/libjvm.so
#6  0x00007fa2349fbb9b in forte_fill_call_trace_given_top(JavaThread*, ASGCT_CallTrace*, int, frame) [clone .isra.20]
    () from /usr/java/jdk-18/lib/server/libjvm.so
#7  0x00007fa234e8426e in AsyncGetCallTrace () from /usr/java/jdk-18/lib/server/libjvm.so
#8  0x00007fa228519312 in Profiler::getJavaTraceAsync(void*, ASGCT_CallFrame*, int) ()
   from /mnt/c/Users/Andrei/java/async-profiler/build/libasyncProfiler.so
#9  0x00007fa228519c72 in Profiler::recordSample(void*, unsigned long long, int, Event*) ()
   from /mnt/c/Users/Andrei/java/async-profiler/build/libasyncProfiler.so
#10 0x00007fa2285164f8 in WallClock::signalHandler(int, siginfo_t*, void*) ()
   from /mnt/c/Users/Andrei/java/async-profiler/build/libasyncProfiler.so
#11 <signal handler called>
#12 __pthread_mutex_unlock_usercnt (decr=1, mutex=0x7fa235da5440 <tc_mutex>) at pthread_mutex_unlock.c:41
#13 __GI___pthread_mutex_unlock (mutex=0x7fa235da5440 <tc_mutex>) at pthread_mutex_unlock.c:356
#14 0x00007fa235696d3b in ThreadCritical::~ThreadCritical() () from /usr/java/jdk-18/lib/server/libjvm.so
#15 0x00007fa234b6fe71 in Chunk::next_chop() () from /usr/java/jdk-18/lib/server/libjvm.so
#16 0x00007fa234d1ca62 in ClassFileParser::parse_method(ClassFileStream const*, bool, ConstantPool const*, AccessFlags*, JavaThread*) () from /usr/java/jdk-18/lib/server/libjvm.so
#17 0x00007fa234d1e338 in ClassFileParser::parse_methods(ClassFileStream const*, bool, AccessFlags*, bool*, bool*, JavaThread*) () from /usr/java/jdk-18/lib/server/libjvm.so
#18 0x00007fa234d22459 in ClassFileParser::parse_stream(ClassFileStream const*, JavaThread*) ()
   from /usr/java/jdk-18/lib/server/libjvm.so
#19 0x00007fa234d2291c in ClassFileParser::ClassFileParser(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const*, ClassFileParser::Publicity, JavaThread*) () from /usr/java/jdk-18/lib/server/libjvm.so
#20 0x00007fa2351febb6 in KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const&, JavaThread*) ()
   from /usr/java/jdk-18/lib/server/libjvm.so
#21 0x00007fa235645b40 in SystemDictionary::resolve_class_from_stream(ClassFileStream*, Symbol*, Handle, ClassLoadInfo const&, JavaThread*) ()
   from /usr/java/jdk-18/lib/server/libjvm.so
#22 0x00007fa2350bad0a in jvm_define_class_common(char const*, _jobject*, signed char const*, int, _jobject*, char const*, JavaThread*) [clone .constprop.299] ()
   from /usr/java/jdk-18/lib/server/libjvm.so
#23 0x00007fa2350bae6d in JVM_DefineClassWithSource () from /usr/java/jdk-18/lib/server/libjvm.so
#24 0x00007fa236a0ee12 in Java_java_lang_ClassLoader_defineClass1 () from /usr/java/jdk-18/lib/libjava.so

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

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

From github.com+7837910+xpbob at openjdk.java.net  Mon Jul 12 03:24:12 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Mon, 12 Jul 2021 03:24:12 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v5]
In-Reply-To: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
Message-ID: <dd0JBHdp_R8n2fwlKj0uhp-u29Ce3EdY5uJeZe49cmk=.29183f20-58fe-475c-91d8-6245417b758d@github.com>

> ?ocess cpu usage in containers

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

  use same path for cpuload

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4702/files
  - new: https://git.openjdk.java.net/jdk/pull/4702/files/f5ccb86c..90aa3c6b

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

  Stats: 118 lines in 1 file changed: 44 ins; 51 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4702.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4702/head:pull/4702

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

From github.com+7837910+xpbob at openjdk.java.net  Mon Jul 12 03:49:50 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Mon, 12 Jul 2021 03:49:50 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v4]
In-Reply-To: <Js4dpsvqTBJrTjtsFSDwOqUph68m-cHhdzejq-TpnA0=.85787a87-3ff0-4978-897c-b0dd652f83db@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
 <oiZj95VoY09LAdXODZ_4qZOAj8Rhiuuxo6YnaRX4jBg=.ea045cef-8471-45d6-8264-45c59f2a4e74@github.com>
 <Js4dpsvqTBJrTjtsFSDwOqUph68m-cHhdzejq-TpnA0=.85787a87-3ff0-4978-897c-b0dd652f83db@github.com>
Message-ID: <aGMuUvLk_G36uAhAchJqmy_MTp320Q91KCIuL7Yc7IM=.600fb5e1-443d-45c7-955e-99e640736ac7@github.com>

On Fri, 9 Jul 2021 14:19:42 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Thanks for the update. `getProcessCpuLoad()` and `getCpuLoad()` looks way too similar to me. Is there a way to make them more generic and do the process vs. system paths as needed? I think there is.

use getCpuLoadWithTarget for process and system

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

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

From yyang at openjdk.java.net  Mon Jul 12 05:24:57 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 12 Jul 2021 05:24:57 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.base [v11]
In-Reply-To: <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
Message-ID: <fAce1CcdIOiW48sazVB_56DhApB92Lr0gXN6zqOCAYo=.ee084537-89c5-473a-9bab-18dd1edd833b@github.com>

On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

I'm not familiar with the review process of core-lib group. Is it sufficient for merging with one approval? Should I have more reviews for this? ??

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

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

From cgo at openjdk.java.net  Mon Jul 12 09:37:54 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Mon, 12 Jul 2021 09:37:54 GMT
Subject: [jdk17] RFR: 8269873: serviceability/sa/Clhsdb tests are using a
 C2 specific VMStruct field
In-Reply-To: <nCO1-ZPuidcsbdej4s10GOx6QFaVszDWdmKq-32Witk=.34a45d04-2f08-4743-bbb2-81cf2e1eaf9b@github.com>
References: <nCO1-ZPuidcsbdej4s10GOx6QFaVszDWdmKq-32Witk=.34a45d04-2f08-4743-bbb2-81cf2e1eaf9b@github.com>
Message-ID: <UWE0STLGwcWedoHyZV9Se1RtyHxNuRJdYO5EwgLlmns=.c5468633-4c97-478d-bea2-626f579bdd20@github.com>

On Mon, 5 Jul 2021 12:16:22 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Hi,
> 
> please review this small change for two Clhsdb test cases, which are using C2 specific fields during testing. This makes the tests fail, if C2 is not available during testing.

Could someone please sponsor this change for me?

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

PR: https://git.openjdk.java.net/jdk17/pull/213

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: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
Message-ID: <XngdH6IzPH3ljUiyRE35HsKluFgYqIbcecIqqPaWybo=.87358259-1cfa-4f56-860c-edf3fd2b3915@github.com>

On Tue, 25 May 2021 11:23:33 GMT, Anton Kozlov <akozlov at openjdk.org> 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 <akozlov at openjdk.org>
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 cgo at openjdk.java.net  Mon Jul 12 11:26:53 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Mon, 12 Jul 2021 11:26:53 GMT
Subject: [jdk17] Integrated: 8269873: serviceability/sa/Clhsdb tests are using
 a C2 specific VMStruct field
In-Reply-To: <nCO1-ZPuidcsbdej4s10GOx6QFaVszDWdmKq-32Witk=.34a45d04-2f08-4743-bbb2-81cf2e1eaf9b@github.com>
References: <nCO1-ZPuidcsbdej4s10GOx6QFaVszDWdmKq-32Witk=.34a45d04-2f08-4743-bbb2-81cf2e1eaf9b@github.com>
Message-ID: <W8cG0UXoNN4zgr_N5zk5XwD3FfVm_RWgxvxdBSB4R60=.ee1b7e26-98a1-4aba-a178-c4c53fbc9aec@github.com>

On Mon, 5 Jul 2021 12:16:22 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Hi,
> 
> please review this small change for two Clhsdb test cases, which are using C2 specific fields during testing. This makes the tests fail, if C2 is not available during testing.

This pull request has now been integrated.

Changeset: 999ced03
Author:    Christoph G?ttschkes <cgo at openjdk.org>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/999ced03ccd58b216adf9a7bfb2646e511219e6c
Stats:     4 lines in 2 files changed: 0 ins; 2 del; 2 mod

8269873: serviceability/sa/Clhsdb tests are using a C2 specific VMStruct field

Reviewed-by: cjplummer, dholmes, sspitsyn

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

PR: https://git.openjdk.java.net/jdk17/pull/213

From sgehwolf at openjdk.java.net  Mon Jul 12 13:22:59 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 12 Jul 2021 13:22:59 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v4]
In-Reply-To: <aGMuUvLk_G36uAhAchJqmy_MTp320Q91KCIuL7Yc7IM=.600fb5e1-443d-45c7-955e-99e640736ac7@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
 <oiZj95VoY09LAdXODZ_4qZOAj8Rhiuuxo6YnaRX4jBg=.ea045cef-8471-45d6-8264-45c59f2a4e74@github.com>
 <Js4dpsvqTBJrTjtsFSDwOqUph68m-cHhdzejq-TpnA0=.85787a87-3ff0-4978-897c-b0dd652f83db@github.com>
 <aGMuUvLk_G36uAhAchJqmy_MTp320Q91KCIuL7Yc7IM=.600fb5e1-443d-45c7-955e-99e640736ac7@github.com>
Message-ID: <IvIhnszQD6R7OpoxBfcbqgaOzUGkP_ZFHFT8j4JoGlk=.ef71d2b9-e8b6-4874-a7e8-a9aa5b664b53@github.com>

On Mon, 12 Jul 2021 03:46:23 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

> > Thanks for the update. `getProcessCpuLoad()` and `getCpuLoad()` looks way too similar to me. Is there a way to make them more generic and do the process vs. system paths as needed? I think there is.
> 
> use getCpuLoadWithTarget for process and system

Thanks. We are getting there. I've proposed a PR to your branch which makes this a bit easier to read:
https://github.com/xpbob/jdk/pull/1

If you merge that it'll show up in this PR.

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

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

From mchung at openjdk.java.net  Mon Jul 12 16:56:58 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 12 Jul 2021 16:56:58 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.base [v11]
In-Reply-To: <fAce1CcdIOiW48sazVB_56DhApB92Lr0gXN6zqOCAYo=.ee084537-89c5-473a-9bab-18dd1edd833b@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
 <fAce1CcdIOiW48sazVB_56DhApB92Lr0gXN6zqOCAYo=.ee084537-89c5-473a-9bab-18dd1edd833b@github.com>
Message-ID: <J0v7qsbP9BgGowSx1KSS-mH8ZJBJe3ATtgCmdXRe4R8=.e919d281-1c8e-43b0-84c0-8dca1f3d6740@github.com>

On Mon, 12 Jul 2021 05:21:34 GMT, Yi Yang <yyang at openjdk.org> wrote:

> I'm not familiar with the review process of core-lib group. Is it sufficient for merging with one approval? Should I have more reviews for this? ??

It depends on the change.

For this patch, it's good to get another reviewer to look through it.

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

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

From rriggs at openjdk.java.net  Mon Jul 12 19:49:53 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 12 Jul 2021 19:49:53 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.base [v11]
In-Reply-To: <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
Message-ID: <sgRG6_cJ5_--BLqBtV9jmmNxbq0kmbEFC0oDRFekDwY=.3353ef2b-9f25-4552-a64a-d07027c4b21b@github.com>

On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   restore JSR166; restore java.desktop

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

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

From akozlov at openjdk.java.net  Mon Jul 12 20:30:18 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 12 Jul 2021 20:30:18 GMT
Subject: [jdk17] RFR: 8266889: [macosx-aarch64] Crash with SIGBUS in
 MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002
 test run
Message-ID: <yicyL1ISRPV-D0a-lgo_jJu_7guVM2tk06J2bVrzPH4=.c13e4b9e-dc91-497d-b510-122d4e59a8f1@github.com>

The change adds W^X transition in RawMonitor family of functions, fixing the crash. RawMonitor functions are treated specially, so W^X transition is not inserted automatically. A better fix would be in .xml description for entries generation, but for now it is too risky. I hope to get this fixed in 17 in the simplest way and do re-work in the 18. This change is still 100% correct for the reported bug.

Verified by: 

jtreg -vmoption:-XX:+AssertWXAtThreadSync test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002

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

Commit messages:
 - 8266889: Switch W^X in JVMTI RawMonitor functions

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

PR: https://git.openjdk.java.net/jdk17/pull/244

From cjplummer at openjdk.java.net  Mon Jul 12 22:04:54 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 12 Jul 2021 22:04:54 GMT
Subject: RFR: 8270067: AArch64: several clhsdb tests fail with -Xcomp
In-Reply-To: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
References: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
Message-ID: <e-3mYcBgotvopTf1tW9QVzxhtl9tZp9WcJKh8qJ5Ybo=.14777947-fed8-4bd8-a9db-5be714a44d6a@github.com>

On Fri, 9 Jul 2021 08:37:00 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Running the jtreg test serviceability/sa/ClhsdbWhere.java with -Xcomp
> -XX:-TieredCompilation fails with the following exception:
> 
>   Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
>   java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
>           at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.createStackValue(CompiledVFrame.java:270)
>           at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getLocals(CompiledVFrame.java:107)
>           at jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTMLForJavaStackTrace(HTMLGenerator.java:1937)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$43.doit(CommandProcessor.java:1573)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2090)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2060)
> 
> The oop map for the frame being inspected is:
> 
>    ScopeDesc(pc=0x0000ffff8957e000 offset=140):
>    jdk.test.lib.apps.LingeredApp::steadyState at 7 (line 536)
>    Locals
>     - l0: empty
>     - l1: reg rfp [58],oop
>     - l2: empty
>    Monitor stack
>     - @0: monitor{reg rfp [58],oop,stack[16]}
> 
> But RegisterMap::getLocation() returns a null Address for register
> 58 (=RFP).
> 
> This patch fixes two problems: the fp VMReg value used in
> AARCH64Frame::updateMapWithSavedLink should be 29<<1 not 29 because a
> VMReg has two slots in a 64-bit VM.  The other bug is that
> RegisterMap::setLocation and getLocation calculate the long
> locationValid mask using (1 << (i % locationValidTypeSize)) where i and
> locationValidTypeSize are both int.  We need to do this calculation as a
> long if i % locationValidTypeSize can be > 32.  There's no failure on
> x86_64 because that only has 16 integer registers.

How did you even get the test to run without running into [JDK-8270199](https://bugs.openjdk.java.net/browse/JDK-8270199)

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

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

From jwilhelm at openjdk.java.net  Mon Jul 12 23:21:35 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 12 Jul 2021 23:21:35 GMT
Subject: RFR: Merge jdk17
Message-ID: <7zQieFkCIJDip3Y4qUzNkzmvs5CWEaF2L09fXDMbLkc=.2b0d08b5-5ed6-4d63-bc76-fccad123bdb6@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8266345: (fs) Custom DefaultFileSystemProvider security related loops
 - 8269873: serviceability/sa/Clhsdb tests are using a C2 specific VMStruct field
 - 8268965: TCP Connection Reset when connecting simple socket to SSL server
 - 8269558: fix of JDK-8252657 missed to update history at the end of JVM TI spec
 - 8270216: [macOS] Update named used for Java run loop mode

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4760&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4760&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4760/files
  Stats: 39 lines in 7 files changed: 33 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4760.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4760/head:pull/4760

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

From sspitsyn at openjdk.java.net  Mon Jul 12 23:49:53 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 12 Jul 2021 23:49:53 GMT
Subject: [jdk17] RFR: 8266889: [macosx-aarch64] Crash with SIGBUS in
 MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002
 test run
In-Reply-To: <yicyL1ISRPV-D0a-lgo_jJu_7guVM2tk06J2bVrzPH4=.c13e4b9e-dc91-497d-b510-122d4e59a8f1@github.com>
References: <yicyL1ISRPV-D0a-lgo_jJu_7guVM2tk06J2bVrzPH4=.c13e4b9e-dc91-497d-b510-122d4e59a8f1@github.com>
Message-ID: <UEc-7XooX5Zsi-pgZk7A7GxTsvKeU2OfXJrQ4bS0agM=.f213a002-e432-4b46-b4e7-a620fccf8e13@github.com>

On Mon, 12 Jul 2021 20:22:25 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> The change adds W^X transition in RawMonitor family of functions, fixing the crash. RawMonitor functions are treated specially, so W^X transition is not inserted automatically. A better fix would be in .xml description for entries generation, but for now it is too risky. I hope to get this fixed in 17 in the simplest way and do re-work in the 18. This change is still 100% correct for the reported bug.
> 
> Verified by: 
> 
> jtreg -vmoption:-XX:+AssertWXAtThreadSync test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002

Hi Anton,
At least, some comments would be nice to have explaining why the switches are needed there.
Thanks,
Serguei

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

PR: https://git.openjdk.java.net/jdk17/pull/244

From dholmes at openjdk.java.net  Tue Jul 13 01:28:51 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 13 Jul 2021 01:28:51 GMT
Subject: [jdk17] RFR: 8266889: [macosx-aarch64] Crash with SIGBUS in
 MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002
 test run
In-Reply-To: <yicyL1ISRPV-D0a-lgo_jJu_7guVM2tk06J2bVrzPH4=.c13e4b9e-dc91-497d-b510-122d4e59a8f1@github.com>
References: <yicyL1ISRPV-D0a-lgo_jJu_7guVM2tk06J2bVrzPH4=.c13e4b9e-dc91-497d-b510-122d4e59a8f1@github.com>
Message-ID: <S0P5hw5Y3ql7a3fWYchY5bU6Dg3fldLAbDK7QbuSCVw=.c9ef286d-4fe7-4379-933d-1c15d92ddc3c@github.com>

On Mon, 12 Jul 2021 20:22:25 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> The change adds W^X transition in RawMonitor family of functions, fixing the crash. RawMonitor functions are treated specially, so W^X transition is not inserted automatically. A better fix would be in .xml description for entries generation, but for now it is too risky. I hope to get this fixed in 17 in the simplest way and do re-work in the 18. This change is still 100% correct for the reported bug.
> 
> Verified by: 
> 
> jtreg -vmoption:-XX:+AssertWXAtThreadSync test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002

I can understand that raw_enter and raw_wait need this fix because they have the ThreadBlockInVM transition; but why do we need it for raw_exit and raw_notify when they do not change the thread state ??

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

PR: https://git.openjdk.java.net/jdk17/pull/244

From ngasson at openjdk.java.net  Tue Jul 13 01:43:54 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 13 Jul 2021 01:43:54 GMT
Subject: RFR: 8270067: AArch64: several clhsdb tests fail with -Xcomp
In-Reply-To: <e-3mYcBgotvopTf1tW9QVzxhtl9tZp9WcJKh8qJ5Ybo=.14777947-fed8-4bd8-a9db-5be714a44d6a@github.com>
References: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
 <e-3mYcBgotvopTf1tW9QVzxhtl9tZp9WcJKh8qJ5Ybo=.14777947-fed8-4bd8-a9db-5be714a44d6a@github.com>
Message-ID: <Smk1xiOakHBiIB0W2Hr0IUj_uVMqKLb4hbrIcFvJNm0=.daf31fea-0c26-48a8-bacb-8dc1e345c087@github.com>

On Mon, 12 Jul 2021 22:01:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> How did you even get the test to run without running into [JDK-8270199](https://bugs.openjdk.java.net/browse/JDK-8270199)

Linux not macOS.

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

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

From yyang at openjdk.java.net  Tue Jul 13 02:38:00 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 13 Jul 2021 02:38:00 GMT
Subject: Integrated: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.base
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <4Gub7lCLaidzVMPjzkZNJD2kC9X_F7RMtYuNY0c80S4=.5f60cd93-799c-4cd2-8ad9-eb549b0bf281@github.com>

On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang <yyang at openjdk.org> wrote:

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

This pull request has now been integrated.

Changeset: afe957cd
Author:    Yi Yang <yyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/afe957cd9741810a113ea165a635a117c0ea556f
Stats:     357 lines in 40 files changed: 73 ins; 171 del; 113 mod

8268698: Use Objects.check{Index,FromToIndex,FromIndexSize} for java.base

Reviewed-by: mchung, rriggs

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

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

From yyang at openjdk.java.net  Tue Jul 13 02:37:59 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 13 Jul 2021 02:37:59 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.base [v11]
In-Reply-To: <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
Message-ID: <Wv9f3s9E44AxjCG_1izKI9RFdCCta08e2bsJ82JwaH8=.d33f7caa-1904-4f23-9ad0-d27cdd5152db@github.com>

On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Thanks Mandy and Roger for reviews!

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

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

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: <xcpJiUFEX5VMzuDgXJYuX8M_G4wcWrFqDkv8vLvXfjk=.474ed7a5-bf44-4734-aaaa-c6108f85b1c4@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
 <xcpJiUFEX5VMzuDgXJYuX8M_G4wcWrFqDkv8vLvXfjk=.474ed7a5-bf44-4734-aaaa-c6108f85b1c4@github.com>
Message-ID: <m_ebRm1RrN-3C_PG8OHxU9y5yVuY9y26qk63PkwB9lI=.2ee467d2-3a88-4458-a651-e792f18f1684@github.com>

On Fri, 9 Jul 2021 08:21:21 GMT, Lin Zang <lzang at openjdk.org> 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 github.com+7837910+xpbob at openjdk.java.net  Tue Jul 13 03:49:21 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Tue, 13 Jul 2021 03:49:21 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v6]
In-Reply-To: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
Message-ID: <jBFyEFi-tADgD5Gr0yQdbVfaakUX6EX7b_tcuH8LJEg=.d5bc50be-7a36-4fda-b39c-2fb89a26b301@github.com>

> ?ocess cpu usage in containers

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

  Refactor process/system cpu load calculation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4702/files
  - new: https://git.openjdk.java.net/jdk/pull/4702/files/90aa3c6b..e6849957

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

  Stats: 226 lines in 1 file changed: 120 ins; 99 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4702.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4702/head:pull/4702

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

From ddong at openjdk.java.net  Tue Jul 13 04:58:54 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 13 Jul 2021 04:58:54 GMT
Subject: RFR: 8269470: Add truncation and compression information to
 EventHeapDump [v2]
In-Reply-To: <arcifDTQoKL6qDJ7mg0ml94-1evr0nAAUmqA9wlcgy8=.0057fdf3-d930-4cef-8161-20ec3ee55235@github.com>
References: <6aIKhIzZuN1t1DZhSzfV9HLQrKnau9zB77VggMdg1sQ=.a8128116-723d-4384-a1b4-36ba3e7fc46c@github.com>
 <arcifDTQoKL6qDJ7mg0ml94-1evr0nAAUmqA9wlcgy8=.0057fdf3-d930-4cef-8161-20ec3ee55235@github.com>
Message-ID: <SUPoYj6uYggpOAUH6Tpkt2mSKgsDu-SmCp_O-58ZezE=.dab818ab-f5dc-4f94-a3e0-8e6f44875d0f@github.com>

On Mon, 28 Jun 2021 07:39:40 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Could I have a review of this change that adds the truncation and compression information to EventHeapDump?
>> 
>> We occasionally receive feedback from users that the heap size parsed from the heap dump does not match the GC log. We think this may be caused by the truncation of the heap dump.
>> 
>> It would be nice to add truncation info to the EventHeapDump.
>> 
>> Also, this patch adds the compression info which is trivial to add.
>> 
>> Regards,
>> Denghui
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wrong return type

gentle ping:)

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

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

From github.com+7837910+xpbob at openjdk.java.net  Tue Jul 13 05:19:25 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Tue, 13 Jul 2021 05:19:25 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v7]
In-Reply-To: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
Message-ID: <gpjCsgFbuodheiTL3QFyXSLKzB3s2S407F01phZKmRc=.e304ec33-ad9c-496a-9a56-fa85ca1349c2@github.com>

> ?ocess cpu usage in containers

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

  Set 1.0 for cpu set max

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4702/files
  - new: https://git.openjdk.java.net/jdk/pull/4702/files/e6849957..fdd17d50

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

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

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

From github.com+7837910+xpbob at openjdk.java.net  Tue Jul 13 06:03:53 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Tue, 13 Jul 2021 06:03:53 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v7]
In-Reply-To: <gpjCsgFbuodheiTL3QFyXSLKzB3s2S407F01phZKmRc=.e304ec33-ad9c-496a-9a56-fa85ca1349c2@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
 <gpjCsgFbuodheiTL3QFyXSLKzB3s2S407F01phZKmRc=.e304ec33-ad9c-496a-9a56-fa85ca1349c2@github.com>
Message-ID: <dTBcnqQZfO-PuGcGK0VSGnLysIt2xSQJUg0gYrc4SLE=.765a4ed5-b2e2-446b-ac54-1d17bd790383@github.com>

On Tue, 13 Jul 2021 05:19:25 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

>> ?ocess cpu usage in containers
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set 1.0 for cpu set max

> > > Thanks for the update. `getProcessCpuLoad()` and `getCpuLoad()` looks way too similar to me. Is there a way to make them more generic and do the process vs. system paths as needed? I think there is.
> > 
> > 
> > use getCpuLoadWithTarget for process and system
> 
> Thanks. We are getting there. I've proposed a PR to your branch which makes this a bit easier to read:
> [xpbob#1](https://github.com/xpbob/jdk/pull/1)
> 
> If you merge that it'll show up in this PR.

Thank you so much @jerboaa .

Code has been merged.
I tested the following cgroup scenario on Linux/x64 and all passed.

  cpu-quota=50000 cpu-period=50000 
  cpuset-cpus=0-2
  cpu.shares=2048
  cpuset-cpus=3

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

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

From akozlov at openjdk.java.net  Tue Jul 13 10:13:57 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 13 Jul 2021 10:13:57 GMT
Subject: [jdk17] RFR: 8266889: [macosx-aarch64] Crash with SIGBUS in
 MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002
 test run [v2]
In-Reply-To: <S0P5hw5Y3ql7a3fWYchY5bU6Dg3fldLAbDK7QbuSCVw=.c9ef286d-4fe7-4379-933d-1c15d92ddc3c@github.com>
References: <yicyL1ISRPV-D0a-lgo_jJu_7guVM2tk06J2bVrzPH4=.c13e4b9e-dc91-497d-b510-122d4e59a8f1@github.com>
 <S0P5hw5Y3ql7a3fWYchY5bU6Dg3fldLAbDK7QbuSCVw=.c9ef286d-4fe7-4379-933d-1c15d92ddc3c@github.com>
Message-ID: <WF46hKJVTw1u9d6en-Ne6a1EPevD6zQGAPZkCa_ppok=.3b648b4a-76b4-4c93-a621-04f7487b1f07@github.com>

On Tue, 13 Jul 2021 01:25:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Subset of RawMonitor; comments added
>
> I can understand that raw_enter and raw_wait need this fix because they have the ThreadBlockInVM transition; but why do we need it for raw_exit and raw_notify when they do not change the thread state ??

@dholmes-ora I added the W^X into all RawMonitor functions since they clearly slipped from the common JVMTI entry with W^X management. It was just precaution. But I don't see any problem with handling only raw_enter and raw_wait, updated the patch.

Handling only subset of functions also simplifies the comment suggested by @sspitsyn. 

Thanks for the comments!

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

PR: https://git.openjdk.java.net/jdk17/pull/244

From akozlov at openjdk.java.net  Tue Jul 13 10:13:39 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 13 Jul 2021 10:13:39 GMT
Subject: [jdk17] RFR: 8266889: [macosx-aarch64] Crash with SIGBUS in
 MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002
 test run [v2]
In-Reply-To: <yicyL1ISRPV-D0a-lgo_jJu_7guVM2tk06J2bVrzPH4=.c13e4b9e-dc91-497d-b510-122d4e59a8f1@github.com>
References: <yicyL1ISRPV-D0a-lgo_jJu_7guVM2tk06J2bVrzPH4=.c13e4b9e-dc91-497d-b510-122d4e59a8f1@github.com>
Message-ID: <8qJPTLrfnYRnzcv9csluIhKDZW9SxNwoFsnMEAYPnW8=.5b36c87f-09af-4935-88e5-1538f4377c2c@github.com>

> The change adds W^X transition in RawMonitor family of functions, fixing the crash. RawMonitor functions are treated specially, so W^X transition is not inserted automatically. A better fix would be in .xml description for entries generation, but for now it is too risky. I hope to get this fixed in 17 in the simplest way and do re-work in the 18. This change is still 100% correct for the reported bug.
> 
> Verified by: 
> 
> jtreg -vmoption:-XX:+AssertWXAtThreadSync test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002

Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Subset of RawMonitor; comments added

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/244/files
  - new: https://git.openjdk.java.net/jdk17/pull/244/files/4598ddb8..0088479c

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

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

PR: https://git.openjdk.java.net/jdk17/pull/244

From aph at openjdk.java.net  Tue Jul 13 10:34:03 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 13 Jul 2021 10:34:03 GMT
Subject: [jdk17] RFR: 8266889: [macosx-aarch64] Crash with SIGBUS in
 MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002
 test run [v2]
In-Reply-To: <8qJPTLrfnYRnzcv9csluIhKDZW9SxNwoFsnMEAYPnW8=.5b36c87f-09af-4935-88e5-1538f4377c2c@github.com>
References: <yicyL1ISRPV-D0a-lgo_jJu_7guVM2tk06J2bVrzPH4=.c13e4b9e-dc91-497d-b510-122d4e59a8f1@github.com>
 <8qJPTLrfnYRnzcv9csluIhKDZW9SxNwoFsnMEAYPnW8=.5b36c87f-09af-4935-88e5-1538f4377c2c@github.com>
Message-ID: <5RGCSuMnuhEB_pV7UDdCJaks7Liz_nJovKKldsufGoc=.24afb9c2-fb75-4d8c-aedb-0818cb152546@github.com>

On Tue, 13 Jul 2021 10:13:39 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> The change adds W^X transition in RawMonitor family of functions, fixing the crash. RawMonitor functions are treated specially, so W^X transition is not inserted automatically. A better fix would be in .xml description for entries generation, but for now it is too risky. I hope to get this fixed in 17 in the simplest way and do re-work in the 18. This change is still 100% correct for the reported bug.
>> 
>> Verified by: 
>> 
>> jtreg -vmoption:-XX:+AssertWXAtThreadSync test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Subset of RawMonitor; comments added

OK. We really need to have a think about how W^X should be handled: this temporal coupling is a code smell, and will be be a reliability problem until we do something better.

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

Marked as reviewed by aph (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/244

From jwilhelm at openjdk.java.net  Tue Jul 13 10:54:07 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 13 Jul 2021 10:54:07 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <7zQieFkCIJDip3Y4qUzNkzmvs5CWEaF2L09fXDMbLkc=.2b0d08b5-5ed6-4d63-bc76-fccad123bdb6@github.com>
References: <7zQieFkCIJDip3Y4qUzNkzmvs5CWEaF2L09fXDMbLkc=.2b0d08b5-5ed6-4d63-bc76-fccad123bdb6@github.com>
Message-ID: <XC7_NxNXzknqIq8paB3h30KQkYqOppf0NgK02-xgEhU=.15d63b64-b013-400c-b722-27be4f11e5df@github.com>

On Mon, 12 Jul 2021 23:12:29 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 6b123b05
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6b123b059136b0c1efa62a23824b9aa253e6a519
Stats:     39 lines in 7 files changed: 33 ins; 2 del; 4 mod

Merge

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

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

From sgehwolf at openjdk.java.net  Tue Jul 13 13:09:55 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 13 Jul 2021 13:09:55 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v7]
In-Reply-To: <gpjCsgFbuodheiTL3QFyXSLKzB3s2S407F01phZKmRc=.e304ec33-ad9c-496a-9a56-fa85ca1349c2@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
 <gpjCsgFbuodheiTL3QFyXSLKzB3s2S407F01phZKmRc=.e304ec33-ad9c-496a-9a56-fa85ca1349c2@github.com>
Message-ID: <kdy1CkZDSVTPz38SzwG-hrj507y__ck8aY3MLXGeHcI=.1668ba4d-e354-4fd6-84cf-62f193b5f5ff@github.com>

On Tue, 13 Jul 2021 05:19:25 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

>> ?ocess cpu usage in containers
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set 1.0 for cpu set max

https://github.com/jerboaa/jdk/actions/runs/1026610314 is a pre-integration run of this.

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

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

From sgehwolf at openjdk.java.net  Tue Jul 13 15:12:59 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 13 Jul 2021 15:12:59 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v7]
In-Reply-To: <gpjCsgFbuodheiTL3QFyXSLKzB3s2S407F01phZKmRc=.e304ec33-ad9c-496a-9a56-fa85ca1349c2@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
 <gpjCsgFbuodheiTL3QFyXSLKzB3s2S407F01phZKmRc=.e304ec33-ad9c-496a-9a56-fa85ca1349c2@github.com>
Message-ID: <u1t-n_2J5fvyNjAOU0ISLjR2IfgSOU9VEDSDWDaiunE=.a16994b0-7363-42b2-9e3a-067b9fffca76@github.com>

On Tue, 13 Jul 2021 05:19:25 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

>> ?ocess cpu usage in containers
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set 1.0 for cpu set max

Except for the missing comments in the new code blocks this looks good to me.

src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 98:

> 96:                 hostTicks = hostTicks * containerCPUs / totalCPUs;
> 97:                 return getUsageDividesTotal(cpuUsageSupplier().getAsLong(), hostTicks);
> 98:             } else {

The old code had these comments here. We should add them as they're still relevant:


                // If CPU quotas and shares are not active then find the average system load for
                // all online CPUs that are allowed to run this container.

                // If the cpuset is the same as the host's one there is no need to iterate over each CPU

src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 106:

> 104:                         cpuSet = containerMetrics.getCpuSetCpus();
> 105:                     }
> 106:                     if (cpuSet == null) {

Please add the comment as it was in the original code:


                        // cgroups is mounted, but CPU resource is not limited.
                        // We can assume the VM is run on the host CPUs.

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

Marked as reviewed by sgehwolf (Reviewer).

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

From sspitsyn at openjdk.java.net  Tue Jul 13 16:15:54 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 13 Jul 2021 16:15:54 GMT
Subject: [jdk17] RFR: 8266889: [macosx-aarch64] Crash with SIGBUS in
 MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002
 test run [v2]
In-Reply-To: <8qJPTLrfnYRnzcv9csluIhKDZW9SxNwoFsnMEAYPnW8=.5b36c87f-09af-4935-88e5-1538f4377c2c@github.com>
References: <yicyL1ISRPV-D0a-lgo_jJu_7guVM2tk06J2bVrzPH4=.c13e4b9e-dc91-497d-b510-122d4e59a8f1@github.com>
 <8qJPTLrfnYRnzcv9csluIhKDZW9SxNwoFsnMEAYPnW8=.5b36c87f-09af-4935-88e5-1538f4377c2c@github.com>
Message-ID: <5ylMEuqR6Wu5I7mqoDAZH94mKivSnnefC0SMJmDRP0w=.569f3410-1354-454c-8864-cf7b65cf8aa7@github.com>

On Tue, 13 Jul 2021 10:13:39 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> The change adds W^X transition in RawMonitor family of functions, fixing the crash. RawMonitor functions are treated specially, so W^X transition is not inserted automatically. A better fix would be in .xml description for entries generation, but for now it is too risky. I hope to get this fixed in 17 in the simplest way and do re-work in the 18. This change is still 100% correct for the reported bug.
>> 
>> Verified by: 
>> 
>> jtreg -vmoption:-XX:+AssertWXAtThreadSync test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Subset of RawMonitor; comments added

Marked as reviewed by sspitsyn (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/244

From cjplummer at openjdk.java.net  Tue Jul 13 17:40:15 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 13 Jul 2021 17:40:15 GMT
Subject: RFR: 8270067: AArch64: several clhsdb tests fail with -Xcomp
In-Reply-To: <Smk1xiOakHBiIB0W2Hr0IUj_uVMqKLb4hbrIcFvJNm0=.daf31fea-0c26-48a8-bacb-8dc1e345c087@github.com>
References: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
 <e-3mYcBgotvopTf1tW9QVzxhtl9tZp9WcJKh8qJ5Ybo=.14777947-fed8-4bd8-a9db-5be714a44d6a@github.com>
 <Smk1xiOakHBiIB0W2Hr0IUj_uVMqKLb4hbrIcFvJNm0=.daf31fea-0c26-48a8-bacb-8dc1e345c087@github.com>
Message-ID: <WTTvzMJyxhfGeDOXTWWrS-Ti73Kj-kRtmhJvHSBMCYw=.80c9860e-df2e-4e50-bbbb-c7bd3362dfe6@github.com>

On Tue, 13 Jul 2021 01:41:03 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> > How did you even get the test to run without running into [JDK-8270199](https://bugs.openjdk.java.net/browse/JDK-8270199)
> 
> Linux not macOS.

Ah. OK.

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

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

From cjplummer at openjdk.java.net  Tue Jul 13 17:52:17 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 13 Jul 2021 17:52:17 GMT
Subject: RFR: 8270067: AArch64: several clhsdb tests fail with -Xcomp
In-Reply-To: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
References: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
Message-ID: <O7zehOu9BNAKD_4PHAtBMtgmfIQE2FXjY3Ih5NE96-Q=.42a0b554-dbf3-4b00-a2f7-4cfd28775f34@github.com>

On Fri, 9 Jul 2021 08:37:00 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Running the jtreg test serviceability/sa/ClhsdbWhere.java with -Xcomp
> -XX:-TieredCompilation fails with the following exception:
> 
>   Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
>   java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
>           at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.createStackValue(CompiledVFrame.java:270)
>           at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getLocals(CompiledVFrame.java:107)
>           at jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTMLForJavaStackTrace(HTMLGenerator.java:1937)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$43.doit(CommandProcessor.java:1573)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2090)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2060)
> 
> The oop map for the frame being inspected is:
> 
>    ScopeDesc(pc=0x0000ffff8957e000 offset=140):
>    jdk.test.lib.apps.LingeredApp::steadyState at 7 (line 536)
>    Locals
>     - l0: empty
>     - l1: reg rfp [58],oop
>     - l2: empty
>    Monitor stack
>     - @0: monitor{reg rfp [58],oop,stack[16]}
> 
> But RegisterMap::getLocation() returns a null Address for register
> 58 (=RFP).
> 
> This patch fixes two problems: the fp VMReg value used in
> AARCH64Frame::updateMapWithSavedLink should be 29<<1 not 29 because a
> VMReg has two slots in a 64-bit VM.  The other bug is that
> RegisterMap::setLocation and getLocation calculate the long
> locationValid mask using (1 << (i % locationValidTypeSize)) where i and
> locationValidTypeSize are both int.  We need to do this calculation as a
> long if i % locationValidTypeSize can be > 32.  There's no failure on
> x86_64 because that only has 16 integer registers.

This looks like a dup of [https://bugs.openjdk.java.net/browse/JDK-8247351](JDK-8247351). If so, please close this CR out as a dup and target this PR to JDK-8247351.

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

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

From dholmes at openjdk.java.net  Wed Jul 14 00:11:16 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 14 Jul 2021 00:11:16 GMT
Subject: [jdk17] RFR: 8266889: [macosx-aarch64] Crash with SIGBUS in
 MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002
 test run [v2]
In-Reply-To: <8qJPTLrfnYRnzcv9csluIhKDZW9SxNwoFsnMEAYPnW8=.5b36c87f-09af-4935-88e5-1538f4377c2c@github.com>
References: <yicyL1ISRPV-D0a-lgo_jJu_7guVM2tk06J2bVrzPH4=.c13e4b9e-dc91-497d-b510-122d4e59a8f1@github.com>
 <8qJPTLrfnYRnzcv9csluIhKDZW9SxNwoFsnMEAYPnW8=.5b36c87f-09af-4935-88e5-1538f4377c2c@github.com>
Message-ID: <3haZTu2ZwYp0-RQ82bjglrUG_dKH0ookReMroI5-KDc=.08bf0e7e-7853-462f-943b-24629684d2f1@github.com>

On Tue, 13 Jul 2021 10:13:39 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> The change adds W^X transition in RawMonitor family of functions, fixing the crash. RawMonitor functions are treated specially, so W^X transition is not inserted automatically. A better fix would be in .xml description for entries generation, but for now it is too risky. I hope to get this fixed in 17 in the simplest way and do re-work in the 18. This change is still 100% correct for the reported bug.
>> 
>> Verified by: 
>> 
>> jtreg -vmoption:-XX:+AssertWXAtThreadSync test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Subset of RawMonitor; comments added

Seems fine to address current problem, but we need a much clearer, more systematic approach to handling this (and enabling others to easily understand when and why it is needed).

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/244

From ngasson at openjdk.java.net  Wed Jul 14 02:03:14 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 14 Jul 2021 02:03:14 GMT
Subject: RFR: 8247351: [aarch64] NullPointerException during stack walking
 (clhsdb "where -a")
In-Reply-To: <O7zehOu9BNAKD_4PHAtBMtgmfIQE2FXjY3Ih5NE96-Q=.42a0b554-dbf3-4b00-a2f7-4cfd28775f34@github.com>
References: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
 <O7zehOu9BNAKD_4PHAtBMtgmfIQE2FXjY3Ih5NE96-Q=.42a0b554-dbf3-4b00-a2f7-4cfd28775f34@github.com>
Message-ID: <S2AxUQrfW7yK1QRwA0D8VCRl1LwzY83k8Pby-12aXqU=.fa398865-69e6-4c88-b51b-438aecb8bf85@github.com>

On Tue, 13 Jul 2021 17:49:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This looks like a dup of [https://bugs.openjdk.java.net/browse/JDK-8247351](JDK-8247351). If so, please close this CR out as a dup and target this PR to JDK-8247351.

Yes, I missed that one. Thanks.

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

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

From cjplummer at openjdk.java.net  Wed Jul 14 02:27:10 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 14 Jul 2021 02:27:10 GMT
Subject: RFR: 8247351: [aarch64] NullPointerException during stack walking
 (clhsdb "where -a")
In-Reply-To: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
References: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
Message-ID: <FAQhSpo-YyTJ_OGzYGvL9PWTLfVQu-deJ7N3ZAPKXRs=.1c813d66-d9d7-432d-94ec-9ef712013b93@github.com>

On Fri, 9 Jul 2021 08:37:00 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Running the jtreg test serviceability/sa/ClhsdbWhere.java with -Xcomp
> -XX:-TieredCompilation fails with the following exception:
> 
>   Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
>   java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
>           at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.createStackValue(CompiledVFrame.java:270)
>           at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getLocals(CompiledVFrame.java:107)
>           at jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTMLForJavaStackTrace(HTMLGenerator.java:1937)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$43.doit(CommandProcessor.java:1573)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2090)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2060)
> 
> The oop map for the frame being inspected is:
> 
>    ScopeDesc(pc=0x0000ffff8957e000 offset=140):
>    jdk.test.lib.apps.LingeredApp::steadyState at 7 (line 536)
>    Locals
>     - l0: empty
>     - l1: reg rfp [58],oop
>     - l2: empty
>    Monitor stack
>     - @0: monitor{reg rfp [58],oop,stack[16]}
> 
> But RegisterMap::getLocation() returns a null Address for register
> 58 (=RFP).
> 
> This patch fixes two problems: the fp VMReg value used in
> AARCH64Frame::updateMapWithSavedLink should be 29<<1 not 29 because a
> VMReg has two slots in a 64-bit VM.  The other bug is that
> RegisterMap::setLocation and getLocation calculate the long
> locationValid mask using (1 << (i % locationValidTypeSize)) where i and
> locationValidTypeSize are both int.  We need to do this calculation as a
> long if i % locationValidTypeSize can be > 32.  There's no failure on
> x86_64 because that only has 16 integer registers.

The changes look good.

I assume this bug also existed on PPC, although I don't see any bugs filed for it.

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

Marked as reviewed by cjplummer (Reviewer).

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

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: <xcpJiUFEX5VMzuDgXJYuX8M_G4wcWrFqDkv8vLvXfjk=.474ed7a5-bf44-4734-aaaa-c6108f85b1c4@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
 <xcpJiUFEX5VMzuDgXJYuX8M_G4wcWrFqDkv8vLvXfjk=.474ed7a5-bf44-4734-aaaa-c6108f85b1c4@github.com>
Message-ID: <oTdhruJdPSUEPS15V8lbECHbqtnwEyoz4R4azLknGqM=.e6725634-04d0-44d2-9f7f-26dd66e5ceef@github.com>

On Fri, 9 Jul 2021 08:21:21 GMT, Lin Zang <lzang at openjdk.org> 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 ngasson at openjdk.java.net  Wed Jul 14 02:35:17 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 14 Jul 2021 02:35:17 GMT
Subject: RFR: 8247351: [aarch64] NullPointerException during stack walking
 (clhsdb "where -a")
In-Reply-To: <O7zehOu9BNAKD_4PHAtBMtgmfIQE2FXjY3Ih5NE96-Q=.42a0b554-dbf3-4b00-a2f7-4cfd28775f34@github.com>
References: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
 <O7zehOu9BNAKD_4PHAtBMtgmfIQE2FXjY3Ih5NE96-Q=.42a0b554-dbf3-4b00-a2f7-4cfd28775f34@github.com>
Message-ID: <TUN6TW9ze77r5PvaVUaYqtB0G7Wk2LmMSLpdwZzAvx0=.59aeea00-e329-4fac-a7af-7948eada7a98@github.com>

On Tue, 13 Jul 2021 17:49:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Running the jtreg test serviceability/sa/ClhsdbWhere.java with -Xcomp
>> -XX:-TieredCompilation fails with the following exception:
>> 
>>   Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
>>   java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
>>           at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.createStackValue(CompiledVFrame.java:270)
>>           at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getLocals(CompiledVFrame.java:107)
>>           at jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTMLForJavaStackTrace(HTMLGenerator.java:1937)
>>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$43.doit(CommandProcessor.java:1573)
>>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2090)
>>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2060)
>> 
>> The oop map for the frame being inspected is:
>> 
>>    ScopeDesc(pc=0x0000ffff8957e000 offset=140):
>>    jdk.test.lib.apps.LingeredApp::steadyState at 7 (line 536)
>>    Locals
>>     - l0: empty
>>     - l1: reg rfp [58],oop
>>     - l2: empty
>>    Monitor stack
>>     - @0: monitor{reg rfp [58],oop,stack[16]}
>> 
>> But RegisterMap::getLocation() returns a null Address for register
>> 58 (=RFP).
>> 
>> This patch fixes two problems: the fp VMReg value used in
>> AARCH64Frame::updateMapWithSavedLink should be 29<<1 not 29 because a
>> VMReg has two slots in a 64-bit VM.  The other bug is that
>> RegisterMap::setLocation and getLocation calculate the long
>> locationValid mask using (1 << (i % locationValidTypeSize)) where i and
>> locationValidTypeSize are both int.  We need to do this calculation as a
>> long if i % locationValidTypeSize can be > 32.  There's no failure on
>> x86_64 because that only has 16 integer registers.
>
> This looks like a dup of [https://bugs.openjdk.java.net/browse/JDK-8247351](JDK-8247351). If so, please close this CR out as a dup and target this PR to JDK-8247351.

Thanks @plummercj . I think I did something wrong with the /issue commands and now I ended up with the JBS line in the commit message duplicated. Not sure how to fix that...

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

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

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: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
Message-ID: <RKXkjsvmdwzbw7B7PhFtTVz3oYEstu55WAfL6rHNJMA=.653dd355-066c-434b-ae43-5cdcad7216d2@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:

  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 cjplummer at openjdk.java.net  Wed Jul 14 03:47:13 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 14 Jul 2021 03:47:13 GMT
Subject: RFR: 8247351: [aarch64] NullPointerException during stack walking
 (clhsdb "where -a")
In-Reply-To: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
References: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
Message-ID: <PfunCs40nVQdwuIJN478AZjiL2BH_iFaDOJ0lkkEosQ=.a8bcb161-a76d-49f4-bbf2-6444091f8234@github.com>

On Fri, 9 Jul 2021 08:37:00 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Running the jtreg test serviceability/sa/ClhsdbWhere.java with -Xcomp
> -XX:-TieredCompilation fails with the following exception:
> 
>   Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
>   java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
>           at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.createStackValue(CompiledVFrame.java:270)
>           at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getLocals(CompiledVFrame.java:107)
>           at jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTMLForJavaStackTrace(HTMLGenerator.java:1937)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$43.doit(CommandProcessor.java:1573)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2090)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2060)
> 
> The oop map for the frame being inspected is:
> 
>    ScopeDesc(pc=0x0000ffff8957e000 offset=140):
>    jdk.test.lib.apps.LingeredApp::steadyState at 7 (line 536)
>    Locals
>     - l0: empty
>     - l1: reg rfp [58],oop
>     - l2: empty
>    Monitor stack
>     - @0: monitor{reg rfp [58],oop,stack[16]}
> 
> But RegisterMap::getLocation() returns a null Address for register
> 58 (=RFP).
> 
> This patch fixes two problems: the fp VMReg value used in
> AARCH64Frame::updateMapWithSavedLink should be 29<<1 not 29 because a
> VMReg has two slots in a 64-bit VM.  The other bug is that
> RegisterMap::setLocation and getLocation calculate the long
> locationValid mask using (1 << (i % locationValidTypeSize)) where i and
> locationValidTypeSize are both int.  We need to do this calculation as a
> long if i % locationValidTypeSize can be > 32.  There's no failure on
> x86_64 because that only has 16 integer registers.

Looks like it is ok now.

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

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

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: <RKXkjsvmdwzbw7B7PhFtTVz3oYEstu55WAfL6rHNJMA=.653dd355-066c-434b-ae43-5cdcad7216d2@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
 <RKXkjsvmdwzbw7B7PhFtTVz3oYEstu55WAfL6rHNJMA=.653dd355-066c-434b-ae43-5cdcad7216d2@github.com>
Message-ID: <G8Crh3KA_FWWju_nSZzAdcsdXD2WJ72DK30JuK13JKI=.f444f7f7-106f-4c01-906f-a5ae717f4b74@github.com>

On Wed, 14 Jul 2021 02:38:38 GMT, Lin Zang <lzang at openjdk.org> 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 github.com+7837910+xpbob at openjdk.java.net  Wed Jul 14 04:00:39 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Wed, 14 Jul 2021 04:00:39 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v8]
In-Reply-To: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
Message-ID: <j2nvg27bB4wt11pUAQW175-do1q44HFycxM-TzX1tNg=.bb7aca28-a9de-4a5b-bf03-c4ac8bf73207@github.com>

> ?ocess cpu usage in containers

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

  Add  comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4702/files
  - new: https://git.openjdk.java.net/jdk/pull/4702/files/fdd17d50..0f43d5dc

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

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

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

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: <RKXkjsvmdwzbw7B7PhFtTVz3oYEstu55WAfL6rHNJMA=.653dd355-066c-434b-ae43-5cdcad7216d2@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
 <RKXkjsvmdwzbw7B7PhFtTVz3oYEstu55WAfL6rHNJMA=.653dd355-066c-434b-ae43-5cdcad7216d2@github.com>
Message-ID: <BlOBepxDBLG6-W1HcAS8nw7k_9m2cnGCTKk2dWz0ef4=.b0f7994a-9db2-4434-b106-29198f881910@github.com>

On Wed, 14 Jul 2021 02:38:38 GMT, Lin Zang <lzang at openjdk.org> 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: <mA1NM8SyYPXtJpGWTEEpHhM6d-Cm6Zbqd-bpFhGHeXU=.a9a70458-faaf-4d49-89e3-47abd3585c5e@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <mA1NM8SyYPXtJpGWTEEpHhM6d-Cm6Zbqd-bpFhGHeXU=.a9a70458-faaf-4d49-89e3-47abd3585c5e@github.com>
Message-ID: <cpbXWSscUL95XBennGz2JBYQiXgWdDunR4dJ6DAiOxk=.ba4bcd22-6a5a-4556-a693-9a0ebfec282d@github.com>

On Fri, 9 Jul 2021 04:57:27 GMT, Thomas Stuefe <stuefe at openjdk.org> 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: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: <BlOBepxDBLG6-W1HcAS8nw7k_9m2cnGCTKk2dWz0ef4=.b0f7994a-9db2-4434-b106-29198f881910@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
 <RKXkjsvmdwzbw7B7PhFtTVz3oYEstu55WAfL6rHNJMA=.653dd355-066c-434b-ae43-5cdcad7216d2@github.com>
 <BlOBepxDBLG6-W1HcAS8nw7k_9m2cnGCTKk2dWz0ef4=.b0f7994a-9db2-4434-b106-29198f881910@github.com>
Message-ID: <3iQxjLw4JuH6GonjG1TRTrXCJFQpuKPE3AR5wnRsjCU=.b0ffc58c-c7e8-42b0-8327-17ebb8102c0b@github.com>

On Wed, 14 Jul 2021 04:19:56 GMT, David Holmes <dholmes at openjdk.org> 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 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: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
Message-ID: <oYpfsJXyV1KVHyGzEKi-9u7ibyTSnlKuFSApw_7QwFI=.ac80fa39-e780-459f-894b-8c46e37898ff@github.com>

> 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 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: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
 <RKXkjsvmdwzbw7B7PhFtTVz3oYEstu55WAfL6rHNJMA=.653dd355-066c-434b-ae43-5cdcad7216d2@github.com>
 <BlOBepxDBLG6-W1HcAS8nw7k_9m2cnGCTKk2dWz0ef4=.b0f7994a-9db2-4434-b106-29198f881910@github.com>
 <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 <dholmes at openjdk.org> 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: <mA1NM8SyYPXtJpGWTEEpHhM6d-Cm6Zbqd-bpFhGHeXU=.a9a70458-faaf-4d49-89e3-47abd3585c5e@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <mA1NM8SyYPXtJpGWTEEpHhM6d-Cm6Zbqd-bpFhGHeXU=.a9a70458-faaf-4d49-89e3-47abd3585c5e@github.com>
Message-ID: <7XKHDRZiy9DSZzDPUQ4Zde87tnclj7U4bS69Y38TPGI=.f516576d-a7b3-4475-a44b-69f084271166@github.com>

On Fri, 9 Jul 2021 04:57:27 GMT, Thomas Stuefe <stuefe at openjdk.org> 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: <oYpfsJXyV1KVHyGzEKi-9u7ibyTSnlKuFSApw_7QwFI=.ac80fa39-e780-459f-894b-8c46e37898ff@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
 <oYpfsJXyV1KVHyGzEKi-9u7ibyTSnlKuFSApw_7QwFI=.ac80fa39-e780-459f-894b-8c46e37898ff@github.com>
Message-ID: <B5yhNUrAI9UbfoaiCcd0plO6RLP_wrROyl-QtZydY3o=.d57e1426-cd9e-4db6-b931-ed825ff411c8@github.com>

On Wed, 14 Jul 2021 04:48:41 GMT, Lin Zang <lzang at openjdk.org> 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 sgehwolf at openjdk.java.net  Wed Jul 14 07:41:15 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 14 Jul 2021 07:41:15 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v8]
In-Reply-To: <j2nvg27bB4wt11pUAQW175-do1q44HFycxM-TzX1tNg=.bb7aca28-a9de-4a5b-bf03-c4ac8bf73207@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
 <j2nvg27bB4wt11pUAQW175-do1q44HFycxM-TzX1tNg=.bb7aca28-a9de-4a5b-bf03-c4ac8bf73207@github.com>
Message-ID: <HuJ1D9C1RDrtRIIYLSpOfqf4vlQew2-8vHENi_KMpzY=.81c64c0e-e642-4cf0-b4b0-71b7734d39b1@github.com>

On Wed, 14 Jul 2021 04:00:39 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

>> ?ocess cpu usage in containers
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add  comments

Still looks good.

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

Marked as reviewed by sgehwolf (Reviewer).

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

From ngasson at openjdk.java.net  Wed Jul 14 09:06:18 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 14 Jul 2021 09:06:18 GMT
Subject: Integrated: 8247351: [aarch64] NullPointerException during stack
 walking (clhsdb "where -a")
In-Reply-To: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
References: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
Message-ID: <qUJhTF-8LEjpYPUhOi1QMZlepkujhHITaT43cWKSVtw=.7643ca90-0c1f-455a-8bc8-bfae7e72697b@github.com>

On Fri, 9 Jul 2021 08:37:00 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Running the jtreg test serviceability/sa/ClhsdbWhere.java with -Xcomp
> -XX:-TieredCompilation fails with the following exception:
> 
>   Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
>   java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
>           at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.createStackValue(CompiledVFrame.java:270)
>           at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getLocals(CompiledVFrame.java:107)
>           at jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTMLForJavaStackTrace(HTMLGenerator.java:1937)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$43.doit(CommandProcessor.java:1573)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2090)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2060)
> 
> The oop map for the frame being inspected is:
> 
>    ScopeDesc(pc=0x0000ffff8957e000 offset=140):
>    jdk.test.lib.apps.LingeredApp::steadyState at 7 (line 536)
>    Locals
>     - l0: empty
>     - l1: reg rfp [58],oop
>     - l2: empty
>    Monitor stack
>     - @0: monitor{reg rfp [58],oop,stack[16]}
> 
> But RegisterMap::getLocation() returns a null Address for register
> 58 (=RFP).
> 
> This patch fixes two problems: the fp VMReg value used in
> AARCH64Frame::updateMapWithSavedLink should be 29<<1 not 29 because a
> VMReg has two slots in a 64-bit VM.  The other bug is that
> RegisterMap::setLocation and getLocation calculate the long
> locationValid mask using (1 << (i % locationValidTypeSize)) where i and
> locationValidTypeSize are both int.  We need to do this calculation as a
> long if i % locationValidTypeSize can be > 32.  There's no failure on
> x86_64 because that only has 16 integer registers.

This pull request has now been integrated.

Changeset: 357fe09f
Author:    Nick Gasson <ngasson at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/357fe09f2e46efa3343f6c8a57b8693dcd5dd43c
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8247351: [aarch64] NullPointerException during stack walking (clhsdb "where -a")

Reviewed-by: cjplummer

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

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

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: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <mA1NM8SyYPXtJpGWTEEpHhM6d-Cm6Zbqd-bpFhGHeXU=.a9a70458-faaf-4d49-89e3-47abd3585c5e@github.com>
 <7XKHDRZiy9DSZzDPUQ4Zde87tnclj7U4bS69Y38TPGI=.f516576d-a7b3-4475-a44b-69f084271166@github.com>
Message-ID: <BojFC9SiQFDYfpflGZPlexOcowWkqBxqNAmcvaQxbds=.97e6da24-4ad4-4d55-b78f-f614af5a71d7@github.com>

On Wed, 14 Jul 2021 05:01:49 GMT, David Holmes <dholmes at openjdk.org> 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: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
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 akozlov at openjdk.java.net  Wed Jul 14 10:39:11 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 14 Jul 2021 10:39:11 GMT
Subject: [jdk17] Integrated: 8266889: [macosx-aarch64] Crash with SIGBUS in
 MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002
 test run
In-Reply-To: <yicyL1ISRPV-D0a-lgo_jJu_7guVM2tk06J2bVrzPH4=.c13e4b9e-dc91-497d-b510-122d4e59a8f1@github.com>
References: <yicyL1ISRPV-D0a-lgo_jJu_7guVM2tk06J2bVrzPH4=.c13e4b9e-dc91-497d-b510-122d4e59a8f1@github.com>
Message-ID: <aHoUcC3pEymx1XdO5FDcFSmVuYr5vQeBGSsY_CTNVPw=.194f9365-0ed4-4725-8248-907bc2b391c4@github.com>

On Mon, 12 Jul 2021 20:22:25 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> The change adds W^X transition in RawMonitor family of functions, fixing the crash. RawMonitor functions are treated specially, so W^X transition is not inserted automatically. A better fix would be in .xml description for entries generation, but for now it is too risky. I hope to get this fixed in 17 in the simplest way and do re-work in the 18. This change is still 100% correct for the reported bug.
> 
> Verified by: 
> 
> jtreg -vmoption:-XX:+AssertWXAtThreadSync test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002

This pull request has now been integrated.

Changeset: 381bd621
Author:    Anton Kozlov <akozlov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/381bd621074a13cc2f260c18371c956bc48abd4d
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8266889: [macosx-aarch64] Crash with SIGBUS in MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002 test run

Reviewed-by: dholmes, aph, sspitsyn

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

PR: https://git.openjdk.java.net/jdk17/pull/244

From akozlov at openjdk.java.net  Wed Jul 14 10:39:10 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 14 Jul 2021 10:39:10 GMT
Subject: [jdk17] RFR: 8266889: [macosx-aarch64] Crash with SIGBUS in
 MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002
 test run [v2]
In-Reply-To: <8qJPTLrfnYRnzcv9csluIhKDZW9SxNwoFsnMEAYPnW8=.5b36c87f-09af-4935-88e5-1538f4377c2c@github.com>
References: <yicyL1ISRPV-D0a-lgo_jJu_7guVM2tk06J2bVrzPH4=.c13e4b9e-dc91-497d-b510-122d4e59a8f1@github.com>
 <8qJPTLrfnYRnzcv9csluIhKDZW9SxNwoFsnMEAYPnW8=.5b36c87f-09af-4935-88e5-1538f4377c2c@github.com>
Message-ID: <CUTCpVHzVFbGSeE7o90xQT7jcFalxgCgmqLD22wyae8=.762f41aa-da6e-422e-8de2-67c96e6d55b6@github.com>

On Tue, 13 Jul 2021 10:13:39 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> The change adds W^X transition in RawMonitor family of functions, fixing the crash. RawMonitor functions are treated specially, so W^X transition is not inserted automatically. A better fix would be in .xml description for entries generation, but for now it is too risky. I hope to get this fixed in 17 in the simplest way and do re-work in the 18. This change is still 100% correct for the reported bug.
>> 
>> Verified by: 
>> 
>> jtreg -vmoption:-XX:+AssertWXAtThreadSync test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Subset of RawMonitor; comments added

Thanks for the reviews.

It's my fault I have not explained how W^X is supposed to work. I still does not consider this as the smell, but since someone thinks so, it's my bad. I'm going to create a page on cr.openjdk.java.net that will be a memo of the current state.

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

PR: https://git.openjdk.java.net/jdk17/pull/244

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: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <8POs-ek7fxeLPey8_s8PwkBPEQBAgJj4ci5JgPY0ChM=.2ec38ba5-e2ef-4324-b4ae-59dfa56a5fc7@github.com>
Message-ID: <kUdvEdZ9A0r5s7Fy2j-y_ZR1UV_xBzJZJ3Q2lUllJTo=.95ee132b-2dd4-4d3f-bff4-3942b7354567@github.com>

On Wed, 14 Jul 2021 09:55:48 GMT, Thomas Stuefe <stuefe at openjdk.org> 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 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: <kUdvEdZ9A0r5s7Fy2j-y_ZR1UV_xBzJZJ3Q2lUllJTo=.95ee132b-2dd4-4d3f-bff4-3942b7354567@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <8POs-ek7fxeLPey8_s8PwkBPEQBAgJj4ci5JgPY0ChM=.2ec38ba5-e2ef-4324-b4ae-59dfa56a5fc7@github.com>
 <kUdvEdZ9A0r5s7Fy2j-y_ZR1UV_xBzJZJ3Q2lUllJTo=.95ee132b-2dd4-4d3f-bff4-3942b7354567@github.com>
Message-ID: <LV6nQYZGbk-og_wVd5Zs1H_g2ahJEnnKq0jS7AkeD98=.2ed3770b-34c0-4204-9bed-7c85246ca82a@github.com>

On Wed, 14 Jul 2021 13:49:52 GMT, Severin Gehwolf <sgehwolf at openjdk.org> 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 cjplummer at openjdk.java.net  Wed Jul 14 16:43:15 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 14 Jul 2021 16:43:15 GMT
Subject: RFR: 8247351: [aarch64] NullPointerException during stack walking
 (clhsdb "where -a")
In-Reply-To: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
References: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
Message-ID: <9YbGBaIE8vG_hmvFs_ZuxuVGpz5c_n2gtueipQwHdJY=.a3d58d05-9d5c-4977-a857-278bbe2b2518@github.com>

On Fri, 9 Jul 2021 08:37:00 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Running the jtreg test serviceability/sa/ClhsdbWhere.java with -Xcomp
> -XX:-TieredCompilation fails with the following exception:
> 
>   Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
>   java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
>           at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.createStackValue(CompiledVFrame.java:270)
>           at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getLocals(CompiledVFrame.java:107)
>           at jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTMLForJavaStackTrace(HTMLGenerator.java:1937)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$43.doit(CommandProcessor.java:1573)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2090)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2060)
> 
> The oop map for the frame being inspected is:
> 
>    ScopeDesc(pc=0x0000ffff8957e000 offset=140):
>    jdk.test.lib.apps.LingeredApp::steadyState at 7 (line 536)
>    Locals
>     - l0: empty
>     - l1: reg rfp [58],oop
>     - l2: empty
>    Monitor stack
>     - @0: monitor{reg rfp [58],oop,stack[16]}
> 
> But RegisterMap::getLocation() returns a null Address for register
> 58 (=RFP).
> 
> This patch fixes two problems: the fp VMReg value used in
> AARCH64Frame::updateMapWithSavedLink should be 29<<1 not 29 because a
> VMReg has two slots in a 64-bit VM.  The other bug is that
> RegisterMap::setLocation and getLocation calculate the long
> locationValid mask using (1 << (i % locationValidTypeSize)) where i and
> locationValidTypeSize are both int.  We need to do this calculation as a
> long if i % locationValidTypeSize can be > 32.  There's no failure on
> x86_64 because that only has 16 integer registers.

FYI, 2 reviews are required for hotspot changes, and SA is considered to be part of hotspot.

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

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

From jwilhelm at openjdk.java.net  Wed Jul 14 21:43:43 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 14 Jul 2021 21:43:43 GMT
Subject: RFR: Merge jdk17
Message-ID: <mGFja6UZbJ_96gghTVJxjyMQfLBeFCWO27006sRTdKo=.a280d3bc-fc00-4333-ae62-75e6a9c978d5@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8270422: Test build/AbsPathsInImage.java fails after JDK-8259848
 - 8266313: (JEP-356) - RandomGenerator spec implementation requirements tightly coupled to JDK internal classes
 - 8270075: SplittableRandom extends AbstractSplittableGenerator
 - 8266889: [macosx-aarch64] Crash with SIGBUS in MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002 test run
 - 8259499: Handling type arguments from outer classes for inner class in javadoc
 - 8268620: InfiniteLoopException test may fail on x86 platforms
 - 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX
 - 8270056: Generated lambda class can not access protected static method of target class

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4786&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4786&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4786/files
  Stats: 328 lines in 19 files changed: 240 ins; 14 del; 74 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4786.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4786/head:pull/4786

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

From jwilhelm at openjdk.java.net  Wed Jul 14 22:41:17 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 14 Jul 2021 22:41:17 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <mGFja6UZbJ_96gghTVJxjyMQfLBeFCWO27006sRTdKo=.a280d3bc-fc00-4333-ae62-75e6a9c978d5@github.com>
References: <mGFja6UZbJ_96gghTVJxjyMQfLBeFCWO27006sRTdKo=.a280d3bc-fc00-4333-ae62-75e6a9c978d5@github.com>
Message-ID: <sGptrGoMWdfmglTBg4lrKMFgV97Fo8frf7llENg52ts=.1cdeff58-963c-4352-a72c-9c29187244b3@github.com>

On Wed, 14 Jul 2021 21:35:34 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 7d0edb57
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7d0edb5743aacfc22f76ee8aa7b03d7dc0f90dca
Stats:     328 lines in 19 files changed: 240 ins; 14 del; 74 mod

Merge

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

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

From ngasson at openjdk.java.net  Thu Jul 15 00:17:11 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 15 Jul 2021 00:17:11 GMT
Subject: RFR: 8247351: [aarch64] NullPointerException during stack walking
 (clhsdb "where -a")
In-Reply-To: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
References: <n9OCK27-aWFTLTprvp9XBVlVEWjPzC87MRM-pYdADSU=.3106f839-89e5-459d-af1f-805516fad6df@github.com>
Message-ID: <Yek1dtlyKT4rklZ_gisr08PU494Y644HZWIIjawX0fM=.2e5bd34c-5f95-4ab6-bf5c-aa6f81a25d2b@github.com>

On Fri, 9 Jul 2021 08:37:00 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Running the jtreg test serviceability/sa/ClhsdbWhere.java with -Xcomp
> -XX:-TieredCompilation fails with the following exception:
> 
>   Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
>   java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
>           at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.createStackValue(CompiledVFrame.java:270)
>           at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getLocals(CompiledVFrame.java:107)
>           at jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTMLForJavaStackTrace(HTMLGenerator.java:1937)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$43.doit(CommandProcessor.java:1573)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2090)
>           at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2060)
> 
> The oop map for the frame being inspected is:
> 
>    ScopeDesc(pc=0x0000ffff8957e000 offset=140):
>    jdk.test.lib.apps.LingeredApp::steadyState at 7 (line 536)
>    Locals
>     - l0: empty
>     - l1: reg rfp [58],oop
>     - l2: empty
>    Monitor stack
>     - @0: monitor{reg rfp [58],oop,stack[16]}
> 
> But RegisterMap::getLocation() returns a null Address for register
> 58 (=RFP).
> 
> This patch fixes two problems: the fp VMReg value used in
> AARCH64Frame::updateMapWithSavedLink should be 29<<1 not 29 because a
> VMReg has two slots in a 64-bit VM.  The other bug is that
> RegisterMap::setLocation and getLocation calculate the long
> locationValid mask using (1 << (i % locationValidTypeSize)) where i and
> locationValidTypeSize are both int.  We need to do this calculation as a
> long if i % locationValidTypeSize can be > 32.  There's no failure on
> x86_64 because that only has 16 integer registers.

OK, understood. Sorry about that.

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

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

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: <oYpfsJXyV1KVHyGzEKi-9u7ibyTSnlKuFSApw_7QwFI=.ac80fa39-e780-459f-894b-8c46e37898ff@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
 <oYpfsJXyV1KVHyGzEKi-9u7ibyTSnlKuFSApw_7QwFI=.ac80fa39-e780-459f-894b-8c46e37898ff@github.com>
Message-ID: <jBGy4lHzdV1t6X5dUolyHpyPg36I7S_9OrFMDmntvtI=.c87d9738-a7e6-4de6-b75a-a9c709a3bd84@github.com>

On Wed, 14 Jul 2021 04:48:41 GMT, Lin Zang <lzang at openjdk.org> 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 github.com+7837910+xpbob at openjdk.java.net  Fri Jul 16 02:15:11 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Fri, 16 Jul 2021 02:15:11 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v8]
In-Reply-To: <j2nvg27bB4wt11pUAQW175-do1q44HFycxM-TzX1tNg=.bb7aca28-a9de-4a5b-bf03-c4ac8bf73207@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
 <j2nvg27bB4wt11pUAQW175-do1q44HFycxM-TzX1tNg=.bb7aca28-a9de-4a5b-bf03-c4ac8bf73207@github.com>
Message-ID: <__7USH80DXNvB-sGRUDc71KwwGqn9-KEUyXXHOV0hqk=.7ecbca8f-281b-4ac8-b555-50a984b664e7@github.com>

On Wed, 14 Jul 2021 04:00:39 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

>> ?ocess cpu usage in containers
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add  comments

May I get a second review for this change?  Thanks.

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

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

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: <jBGy4lHzdV1t6X5dUolyHpyPg36I7S_9OrFMDmntvtI=.c87d9738-a7e6-4de6-b75a-a9c709a3bd84@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
 <oYpfsJXyV1KVHyGzEKi-9u7ibyTSnlKuFSApw_7QwFI=.ac80fa39-e780-459f-894b-8c46e37898ff@github.com>
 <jBGy4lHzdV1t6X5dUolyHpyPg36I7S_9OrFMDmntvtI=.c87d9738-a7e6-4de6-b75a-a9c709a3bd84@github.com>
Message-ID: <bust7H-eq7t6tYov_YTP7Az73R7CJzs7IiVkX7RWxl0=.5f1fdb5e-3d4e-427f-8aa6-de7b1a9ff6ba@github.com>

On Thu, 15 Jul 2021 17:22:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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 06:12:27 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 16 Jul 2021 06:12:27 GMT
Subject: RFR: 8270814: ProblemList the failing
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor* tests
Message-ID: <XVqdM01DX46HJaNtrJKdE6fI2zqQDYHBEMXISskmkpw=.04d6b54b-ec9e-4e64-9200-30b28799b6d4@github.com>

Two tests have started failing regularly in our CI testing, and also in GHA, so I'm ProblemListing them until the issue can be resolved.

Thanks,
David

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

Commit messages:
 - Added linux-x86 as test fails in GHA
 - 8270814: ProblemList the failing serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor* tests

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

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

From tschatzl at openjdk.java.net  Fri Jul 16 06:45:09 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 16 Jul 2021 06:45:09 GMT
Subject: RFR: 8270814: ProblemList the failing
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor* tests
In-Reply-To: <XVqdM01DX46HJaNtrJKdE6fI2zqQDYHBEMXISskmkpw=.04d6b54b-ec9e-4e64-9200-30b28799b6d4@github.com>
References: <XVqdM01DX46HJaNtrJKdE6fI2zqQDYHBEMXISskmkpw=.04d6b54b-ec9e-4e64-9200-30b28799b6d4@github.com>
Message-ID: <JSg11Po3QbpBzfNFztM708gvgFCMnWBBTStctfGrfIM=.0d67a25d-6134-48dc-9313-dc4658ec4001@github.com>

On Fri, 16 Jul 2021 06:02:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Two tests have started failing regularly in our CI testing, and also in GHA, so I'm ProblemListing them until the issue can be resolved.
> 
> Thanks,
> David

Marked as reviewed by tschatzl (Reviewer).

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

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

From jiefu at openjdk.java.net  Fri Jul 16 06:55:11 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 16 Jul 2021 06:55:11 GMT
Subject: RFR: 8270814: ProblemList the failing
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor* tests
In-Reply-To: <XVqdM01DX46HJaNtrJKdE6fI2zqQDYHBEMXISskmkpw=.04d6b54b-ec9e-4e64-9200-30b28799b6d4@github.com>
References: <XVqdM01DX46HJaNtrJKdE6fI2zqQDYHBEMXISskmkpw=.04d6b54b-ec9e-4e64-9200-30b28799b6d4@github.com>
Message-ID: <97Rs3CfeyuXfHZfWZErh5rjkJPCyWz4oxOODEReGUsg=.c725d70d-b4e1-4836-bccf-a53694cc8ef4@github.com>

On Fri, 16 Jul 2021 06:02:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Two tests have started failing regularly in our CI testing, and also in GHA, so I'm ProblemListing them until the issue can be resolved.
> 
> Thanks,
> David

Marked as reviewed by jiefu (Reviewer).

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

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

From dholmes at openjdk.java.net  Fri Jul 16 07:03:12 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 16 Jul 2021 07:03:12 GMT
Subject: RFR: 8270814: ProblemList the failing
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor* tests
In-Reply-To: <JSg11Po3QbpBzfNFztM708gvgFCMnWBBTStctfGrfIM=.0d67a25d-6134-48dc-9313-dc4658ec4001@github.com>
References: <XVqdM01DX46HJaNtrJKdE6fI2zqQDYHBEMXISskmkpw=.04d6b54b-ec9e-4e64-9200-30b28799b6d4@github.com>
 <JSg11Po3QbpBzfNFztM708gvgFCMnWBBTStctfGrfIM=.0d67a25d-6134-48dc-9313-dc4658ec4001@github.com>
Message-ID: <ZyT_cTsI_BPy3A2G4Ge-jAQcW7-Y3Yl7B6Lfi6USDkY=.160427f9-695d-4d32-85da-0e1a640dfbb2@github.com>

On Fri, 16 Jul 2021 06:41:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Two tests have started failing regularly in our CI testing, and also in GHA, so I'm ProblemListing them until the issue can be resolved.
>> 
>> Thanks,
>> David
>
> Marked as reviewed by tschatzl (Reviewer).

Thanks for the reviews @tschatzl  and @DamonFool !

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

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

From github.com+42199859+nikolaytach at openjdk.java.net  Fri Jul 16 07:03:11 2021
From: github.com+42199859+nikolaytach at openjdk.java.net (NikolayTach)
Date: Fri, 16 Jul 2021 07:03:11 GMT
Subject: RFR: 8270814: ProblemList the failing
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor* tests
In-Reply-To: <XVqdM01DX46HJaNtrJKdE6fI2zqQDYHBEMXISskmkpw=.04d6b54b-ec9e-4e64-9200-30b28799b6d4@github.com>
References: <XVqdM01DX46HJaNtrJKdE6fI2zqQDYHBEMXISskmkpw=.04d6b54b-ec9e-4e64-9200-30b28799b6d4@github.com>
Message-ID: <AA1qSihcIyGj7_P5rrRJiak9oN2FEW6B7LEBFwEWA7g=.ec60973c-5658-4e7b-9c51-608c42c0f69d@github.com>

On Fri, 16 Jul 2021 06:02:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Two tests have started failing regularly in our CI testing, and also in GHA, so I'm ProblemListing them until the issue can be resolved.
> 
> Thanks,
> David

It doesn't include a complete implementation of the Java SE 16 Platform and additional Java APIs to support developing, debugging, and monitoring Java applications. Another source of information about important enhancements and new features in Java SE 16 and JDK 16 is the Java SE 16 (?JSR 391) Platform Specification, which documents the changes to the specification made between Java SE 15 and Java SE 16. This document includes descriptions of those new features and enhancements that are also changes to the specification. The descriptions also identify potential compatibility issues that you might encounter when changing to JDK 16.

https://docs.oracle.com/javase/8/docs/api/java/io/package-frame.html check this one out.

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

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

From dholmes at openjdk.java.net  Fri Jul 16 07:03:12 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 16 Jul 2021 07:03:12 GMT
Subject: Integrated: 8270814: ProblemList the failing
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor* tests
In-Reply-To: <XVqdM01DX46HJaNtrJKdE6fI2zqQDYHBEMXISskmkpw=.04d6b54b-ec9e-4e64-9200-30b28799b6d4@github.com>
References: <XVqdM01DX46HJaNtrJKdE6fI2zqQDYHBEMXISskmkpw=.04d6b54b-ec9e-4e64-9200-30b28799b6d4@github.com>
Message-ID: <Fq5QMdbw5XvMkA11DuycZxuF3QmYW60klXpTTopXATU=.30f9bc52-f141-4304-bc3a-9e51c37714d7@github.com>

On Fri, 16 Jul 2021 06:02:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Two tests have started failing regularly in our CI testing, and also in GHA, so I'm ProblemListing them until the issue can be resolved.
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 4927ee42
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4927ee426aedbeea0f4119bac0a342c6d3576762
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8270814: ProblemList the failing serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor* tests

Reviewed-by: tschatzl, jiefu

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

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

From mbaesken at openjdk.java.net  Fri Jul 16 07:36:22 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 16 Jul 2021 07:36:22 GMT
Subject: RFR: JDK-8270820: remove unused stiFileTableIndex from SDE.c
Message-ID: <R-Nqhpnnj7_6pYx3DfibLJ1AtzNQ0JqGQksYZ68mI2U=.17f73da7-e5e2-4583-8ae2-fa92fe2cda07@github.com>

Hello, please review this very small change. While checking compiler warnings of the type : "function 'xyz' was declared but never referenced" I came across stiFileTableIndex from SDE.c that generated such a warning and can be removed.

Thanks, Matthias

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

Commit messages:
 - JDK-8270820

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

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

From github.com+42199859+nikolaytach at openjdk.java.net  Fri Jul 16 07:49:09 2021
From: github.com+42199859+nikolaytach at openjdk.java.net (NikolayTach)
Date: Fri, 16 Jul 2021 07:49:09 GMT
Subject: RFR: JDK-8270820: remove unused stiFileTableIndex from SDE.c
In-Reply-To: <R-Nqhpnnj7_6pYx3DfibLJ1AtzNQ0JqGQksYZ68mI2U=.17f73da7-e5e2-4583-8ae2-fa92fe2cda07@github.com>
References: <R-Nqhpnnj7_6pYx3DfibLJ1AtzNQ0JqGQksYZ68mI2U=.17f73da7-e5e2-4583-8ae2-fa92fe2cda07@github.com>
Message-ID: <5pnrgPONtdAW6rgKrmx7cKy-eC1w1aFbFZmt4H7xggc=.24b12b94-41ad-4610-9676-d03a39219212@github.com>

On Fri, 16 Jul 2021 07:24:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this very small change. While checking compiler warnings of the type : "function 'xyz' was declared but never referenced" I came across stiFileTableIndex from SDE.c that generated such a warning and can be removed.
> 
> Thanks, Matthias

Documents that changes to the specification made between Java SE 15 and Java SE 16.

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

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

From ngasson at openjdk.java.net  Fri Jul 16 10:31:29 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 16 Jul 2021 10:31:29 GMT
Subject: RFR: 8261236: C2: ClhsdbJstackXcompStress test fails when StressGCM
 is enabled
Message-ID: <3dsIKe2U3zN7oTZlGUFM4PQ0fglWb6bsCUIfCTISM6g=.c5de4eff-f6bb-43ea-96fc-9a155d5d4839@github.com>

The clhsdb jstack command crashes when the debugged program is run with `-Xcomp -XX:+StressGCM -XX:StressSeed=2` on AArch64:


  sun.jvm.hotspot.utilities.AssertionFailure: sanity check
  at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
  at jdk.hotspot.agent/sun.jvm.hotspot.runtime.RegisterMap.setLocation(RegisterMap.java:160)
  at jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet.updateRegisterMap(ImmutableOopMapSet.java:303)
  at jdk.hotspot.agent/sun.jvm.hotspot.runtime.aarch64.AARCH64Frame.senderForCompiledFrame(AARCH64Frame.java:407)


The assertion failure here is:


  Assert.that(0 <= i && i < regCount, "sanity check");


I.e. there's an invalid register in the oop map.

The problem seems to be caused by the changes in JDK-8231586 which changed `OopMapValue::oop_types` from a bit mask to normal integer enum. However the changes in the C++ code weren't mirrored in SA's OopMapStream which still treats OopTypes as a bit mask.

The particular oop map this is crashing on looks like this:


  ImmutableOopMap {[24]=Oop [32]=Oop [40]=Derived_oop_[24] } pc offsets: 324


The code is looking for callee saved values (type=2) by AND-ing with each oop value type in the set, so it wrongly interprets the derived oop [40] (type=3) as a callee saved register.

This patch just mirrors the changes to the C++ code into the corresponding SA classes.  The C++ OopMapStream constructor no longer takes a type filter argument and callers are expected filter themselves, so I've made the same change to the Java code.

This bug can also be seen using the clhsdb "disassemble" command.  For example the above oop map is currently printed incorrectly as:


  OopMap:
  NarrowOops:[40]
  Callee saved:[40] = [24]
  Derived oops:[40] = [24]


With this patch it becomes:


  OopMap:
  Oops:[24]  [32]
  Derived oops:[40] = [24]


This bug was reported on AArch64 but it seems to be just luck that we don't see it on other platforms.

Tested tier1 and hotspot_serviceability on AArch64 and x86.

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

Commit messages:
 - 8261236: C2: ClhsdbJstackXcompStress test fails when StressGCM is enabled

Changes: https://git.openjdk.java.net/jdk/pull/4807/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4807&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261236
  Stats: 58 lines in 3 files changed: 12 ins; 28 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4807.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4807/head:pull/4807

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

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: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
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 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: <jBGy4lHzdV1t6X5dUolyHpyPg36I7S_9OrFMDmntvtI=.c87d9738-a7e6-4de6-b75a-a9c709a3bd84@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
 <oYpfsJXyV1KVHyGzEKi-9u7ibyTSnlKuFSApw_7QwFI=.ac80fa39-e780-459f-894b-8c46e37898ff@github.com>
 <jBGy4lHzdV1t6X5dUolyHpyPg36I7S_9OrFMDmntvtI=.c87d9738-a7e6-4de6-b75a-a9c709a3bd84@github.com>
Message-ID: <PtFjJWxO6Q3A4nkZ58kR2-5uZVhQksYA0qMzS9yeC6g=.a7ded611-b28b-4ea6-a02b-ae58ef02cca4@github.com>

On Thu, 15 Jul 2021 17:22:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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 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: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
 <7LhykR73th0mZIuFtnZ33lxjoOBuJ6GcThnv5KGKWBA=.1b9d903f-0533-463a-a506-08c95f6e2355@github.com>
Message-ID: <fryVt8kz5fGeKlFUWGlqflQeTODYm87Op5nG-g3VjYQ=.41c6f2f1-0425-4657-b173-1008e4cd1f0a@github.com>

On Fri, 16 Jul 2021 11:53:15 GMT, Lin Zang <lzang at openjdk.org> 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 cjplummer at openjdk.java.net  Fri Jul 16 19:07:51 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 16 Jul 2021 19:07:51 GMT
Subject: RFR: JDK-8270820: remove unused stiFileTableIndex from SDE.c
In-Reply-To: <R-Nqhpnnj7_6pYx3DfibLJ1AtzNQ0JqGQksYZ68mI2U=.17f73da7-e5e2-4583-8ae2-fa92fe2cda07@github.com>
References: <R-Nqhpnnj7_6pYx3DfibLJ1AtzNQ0JqGQksYZ68mI2U=.17f73da7-e5e2-4583-8ae2-fa92fe2cda07@github.com>
Message-ID: <98IG4SsZEava1ninj_Hbq3UvK1vOwD-tYzl1extom5Q=.6ada0abf-133c-40e8-9577-d6d1b08cdaa5@github.com>

On Fri, 16 Jul 2021 07:24:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this very small change. While checking compiler warnings of the type : "function 'xyz' was declared but never referenced" I came across stiFileTableIndex from SDE.c that generated such a warning and can be removed.
> 
> Thanks, Matthias

Marked as reviewed by cjplummer (Reviewer).

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

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

From sspitsyn at openjdk.java.net  Fri Jul 16 19:14:49 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 16 Jul 2021 19:14:49 GMT
Subject: RFR: JDK-8270820: remove unused stiFileTableIndex from SDE.c
In-Reply-To: <R-Nqhpnnj7_6pYx3DfibLJ1AtzNQ0JqGQksYZ68mI2U=.17f73da7-e5e2-4583-8ae2-fa92fe2cda07@github.com>
References: <R-Nqhpnnj7_6pYx3DfibLJ1AtzNQ0JqGQksYZ68mI2U=.17f73da7-e5e2-4583-8ae2-fa92fe2cda07@github.com>
Message-ID: <6_7ZRiZZw5508wjVj05ApG-uQqlOmTQPJi9eQHdjM80=.e39beaca-3287-43f9-b01a-31a6f824a389@github.com>

On Fri, 16 Jul 2021 07:24:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this very small change. While checking compiler warnings of the type : "function 'xyz' was declared but never referenced" I came across stiFileTableIndex from SDE.c that generated such a warning and can be removed.
> 
> Thanks, Matthias

Marked as reviewed by sspitsyn (Reviewer).

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

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

From cjplummer at openjdk.java.net  Fri Jul 16 21:12:52 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 16 Jul 2021 21:12:52 GMT
Subject: RFR: 8261236: C2: ClhsdbJstackXcompStress test fails when
 StressGCM is enabled
In-Reply-To: <3dsIKe2U3zN7oTZlGUFM4PQ0fglWb6bsCUIfCTISM6g=.c5de4eff-f6bb-43ea-96fc-9a155d5d4839@github.com>
References: <3dsIKe2U3zN7oTZlGUFM4PQ0fglWb6bsCUIfCTISM6g=.c5de4eff-f6bb-43ea-96fc-9a155d5d4839@github.com>
Message-ID: <VitdKTGyVcz4-WLmMLbfZE__9_hAFapzMb5BHlX1Lto=.a6257fca-f9dd-4872-8230-0b9baa176161@github.com>

On Fri, 16 Jul 2021 10:24:56 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The clhsdb jstack command crashes when the debugged program is run with `-Xcomp -XX:+StressGCM -XX:StressSeed=2` on AArch64:
> 
> 
>   sun.jvm.hotspot.utilities.AssertionFailure: sanity check
>   at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>   at jdk.hotspot.agent/sun.jvm.hotspot.runtime.RegisterMap.setLocation(RegisterMap.java:160)
>   at jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet.updateRegisterMap(ImmutableOopMapSet.java:303)
>   at jdk.hotspot.agent/sun.jvm.hotspot.runtime.aarch64.AARCH64Frame.senderForCompiledFrame(AARCH64Frame.java:407)
> 
> 
> The assertion failure here is:
> 
> 
>   Assert.that(0 <= i && i < regCount, "sanity check");
> 
> 
> I.e. there's an invalid register in the oop map.
> 
> The problem seems to be caused by the changes in JDK-8231586 which changed `OopMapValue::oop_types` from a bit mask to normal integer enum. However the changes in the C++ code weren't mirrored in SA's OopMapStream which still treats OopTypes as a bit mask.
> 
> The particular oop map this is crashing on looks like this:
> 
> 
>   ImmutableOopMap {[24]=Oop [32]=Oop [40]=Derived_oop_[24] } pc offsets: 324
> 
> 
> The code is looking for callee saved values (type=2) by AND-ing with each oop value type in the set, so it wrongly interprets the derived oop [40] (type=3) as a callee saved register.
> 
> This patch just mirrors the changes to the C++ code into the corresponding SA classes.  The C++ OopMapStream constructor no longer takes a type filter argument and callers are expected filter themselves, so I've made the same change to the Java code.
> 
> This bug can also be seen using the clhsdb "disassemble" command.  For example the above oop map is currently printed incorrectly as:
> 
> 
>   OopMap:
>   NarrowOops:[40]
>   Callee saved:[40] = [24]
>   Derived oops:[40] = [24]
> 
> 
> With this patch it becomes:
> 
> 
>   OopMap:
>   Oops:[24]  [32]
>   Derived oops:[40] = [24]
> 
> 
> This bug was reported on AArch64 but it seems to be just luck that we don't see it on other platforms.
> 
> Tested tier1 and hotspot_serviceability on AArch64 and x86.

@nick-arm Although SA is part of serviceability, you'll probably have a hard time finding anyone that currently works on serviceability that understands the code involved and can properly review these changes. Seems compiler expertise would be of more value.

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

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

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: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
 <7LhykR73th0mZIuFtnZ33lxjoOBuJ6GcThnv5KGKWBA=.1b9d903f-0533-463a-a506-08c95f6e2355@github.com>
Message-ID: <eeyUXjqikH5E0lNhAc9AFGNujKRpoiNjfSrDX7LV6eE=.2b037e67-3199-454b-92c3-7a7c4a57d34e@github.com>

On Fri, 16 Jul 2021 11:53:15 GMT, Lin Zang <lzang at openjdk.org> 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 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: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>

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 dholmes at openjdk.java.net  Sat Jul 17 01:01:04 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 17 Jul 2021 01:01:04 GMT
Subject: RFR: 8270862: Fix problem list entries for 32-bit
Message-ID: <Bpjca38ddgJCK7sAaOLRzzAskEnntqYg3zwlm5M0Ng4=.51ae1cfc-600a-4310-890a-5cd79b62cd49@github.com>

32-bit is specified as linux-i586 not linux-x86 

Waiting for GHA results to confirm.

Thanks,
David

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

Commit messages:
 - Fix 32-bit

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

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

From sspitsyn at openjdk.java.net  Sat Jul 17 04:35:51 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sat, 17 Jul 2021 04:35:51 GMT
Subject: RFR: 8270862: Fix problem list entries for 32-bit
In-Reply-To: <Bpjca38ddgJCK7sAaOLRzzAskEnntqYg3zwlm5M0Ng4=.51ae1cfc-600a-4310-890a-5cd79b62cd49@github.com>
References: <Bpjca38ddgJCK7sAaOLRzzAskEnntqYg3zwlm5M0Ng4=.51ae1cfc-600a-4310-890a-5cd79b62cd49@github.com>
Message-ID: <wII9QqNUlR2u6B3HGVrXbuZX_F1FyosuGJBV7q2Ojmk=.7d106b04-e87d-449a-b859-d02141715142@github.com>

On Sat, 17 Jul 2021 00:50:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> 32-bit is specified as linux-i586 not linux-x86 
> 
> Waiting for GHA results to confirm.
> 
> Thanks,
> David

Hi David,
Looks good and trivial.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From dholmes at openjdk.java.net  Sat Jul 17 07:46:51 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 17 Jul 2021 07:46:51 GMT
Subject: RFR: 8270862: Fix problem list entries for 32-bit
In-Reply-To: <wII9QqNUlR2u6B3HGVrXbuZX_F1FyosuGJBV7q2Ojmk=.7d106b04-e87d-449a-b859-d02141715142@github.com>
References: <Bpjca38ddgJCK7sAaOLRzzAskEnntqYg3zwlm5M0Ng4=.51ae1cfc-600a-4310-890a-5cd79b62cd49@github.com>
 <wII9QqNUlR2u6B3HGVrXbuZX_F1FyosuGJBV7q2Ojmk=.7d106b04-e87d-449a-b859-d02141715142@github.com>
Message-ID: <7jo-8emtSyLSTyjVIAuedI5TnSQcApTY9XaY-SGzY7s=.588ea792-384f-4d77-887e-9d00293f8598@github.com>

On Sat, 17 Jul 2021 04:32:55 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> 32-bit is specified as linux-i586 not linux-x86 
>> 
>> Waiting for GHA results to confirm.
>> 
>> Thanks,
>> David
>
> Hi David,
> Looks good and trivial.
> Thanks,
> Serguei

Thanks @sspitsyn !

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

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

From dholmes at openjdk.java.net  Sat Jul 17 07:46:52 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 17 Jul 2021 07:46:52 GMT
Subject: Integrated: 8270862: Fix problem list entries for 32-bit
In-Reply-To: <Bpjca38ddgJCK7sAaOLRzzAskEnntqYg3zwlm5M0Ng4=.51ae1cfc-600a-4310-890a-5cd79b62cd49@github.com>
References: <Bpjca38ddgJCK7sAaOLRzzAskEnntqYg3zwlm5M0Ng4=.51ae1cfc-600a-4310-890a-5cd79b62cd49@github.com>
Message-ID: <VLQJuPPwTuwXAe7YpHd9S06ABOdzeOQInzMVoWWwbig=.3ec2a974-a01e-407a-a85d-de54e00b8c73@github.com>

On Sat, 17 Jul 2021 00:50:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> 32-bit is specified as linux-i586 not linux-x86 
> 
> Waiting for GHA results to confirm.
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: e7cdfebb
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e7cdfebbeebb274b28495b469f39d5874af45e65
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8270862: Fix problem list entries for 32-bit

Reviewed-by: sspitsyn

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

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

From luhenry at openjdk.java.net  Mon Jul 19 07:09:56 2021
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Mon, 19 Jul 2021 07:09:56 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v3]
In-Reply-To: <zEfeAKmEcH3klTLjoOc4ww7yMMlaQmasB0LGXYFREDM=.911f044b-665a-4ca1-a604-66e1270ef191@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <jfohRNi3z8LnjHcxEzmJNhuO7nKKEtBY5bhR-8uycVI=.b410939d-7166-4ea7-a046-c8ca8f2dcc93@github.com>
 <zEfeAKmEcH3klTLjoOc4ww7yMMlaQmasB0LGXYFREDM=.911f044b-665a-4ca1-a604-66e1270ef191@github.com>
Message-ID: <U5QTRyN0fSEVSnt6Dlwtjk8QYbQAXRYFFUN6fJTEvXk=.7bea3615-4fd5-4e3a-bbb4-5c9b4bfe76c2@github.com>

On Sun, 11 Jul 2021 22:21:31 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comments
>
> Hi Ludovic,
> 
> Thank you for working on this long-standing bug.
> I like the idea of the proposed solution, but unfortunately it cannot be applied as is. Since the stack walking code runs inside a signal handler, it is very limited in things it can do. In particular, it must not allocate, acquire locks, etc. In your implementation, FrameParser does allocate though.
> 
> The issue is not just theoretical: when I ran JDK with this patch with async-profiler, I immediately got the following deadlock:
> 
> 
> (gdb) bt
> #0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
> #1  0x00007fa2363ca025 in __GI___pthread_mutex_lock (mutex=0x7fa235da5440 <tc_mutex>)
>     at ../nptl/pthread_mutex_lock.c:80
> #2  0x00007fa235696cb6 in ThreadCritical::ThreadCritical() () from /usr/java/jdk-18/lib/server/libjvm.so
> #3  0x00007fa234b6fe53 in Chunk::next_chop() () from /usr/java/jdk-18/lib/server/libjvm.so
> #4  0x00007fa234e88523 in frame::safe_for_sender(JavaThread*) () from /usr/java/jdk-18/lib/server/libjvm.so
> #5  0x00007fa234e838f2 in vframeStreamForte::forte_next() () from /usr/java/jdk-18/lib/server/libjvm.so
> #6  0x00007fa2349fbb9b in forte_fill_call_trace_given_top(JavaThread*, ASGCT_CallTrace*, int, frame) [clone .isra.20]
>     () from /usr/java/jdk-18/lib/server/libjvm.so
> #7  0x00007fa234e8426e in AsyncGetCallTrace () from /usr/java/jdk-18/lib/server/libjvm.so
> #8  0x00007fa228519312 in Profiler::getJavaTraceAsync(void*, ASGCT_CallFrame*, int) ()
>    from /mnt/c/Users/Andrei/java/async-profiler/build/libasyncProfiler.so
> #9  0x00007fa228519c72 in Profiler::recordSample(void*, unsigned long long, int, Event*) ()
>    from /mnt/c/Users/Andrei/java/async-profiler/build/libasyncProfiler.so
> #10 0x00007fa2285164f8 in WallClock::signalHandler(int, siginfo_t*, void*) ()
>    from /mnt/c/Users/Andrei/java/async-profiler/build/libasyncProfiler.so
> #11 <signal handler called>
> #12 __pthread_mutex_unlock_usercnt (decr=1, mutex=0x7fa235da5440 <tc_mutex>) at pthread_mutex_unlock.c:41
> #13 __GI___pthread_mutex_unlock (mutex=0x7fa235da5440 <tc_mutex>) at pthread_mutex_unlock.c:356
> #14 0x00007fa235696d3b in ThreadCritical::~ThreadCritical() () from /usr/java/jdk-18/lib/server/libjvm.so
> #15 0x00007fa234b6fe71 in Chunk::next_chop() () from /usr/java/jdk-18/lib/server/libjvm.so
> #16 0x00007fa234d1ca62 in ClassFileParser::parse_method(ClassFileStream const*, bool, ConstantPool const*, AccessFlags*, JavaThread*) () from /usr/java/jdk-18/lib/server/libjvm.so
> #17 0x00007fa234d1e338 in ClassFileParser::parse_methods(ClassFileStream const*, bool, AccessFlags*, bool*, bool*, JavaThread*) () from /usr/java/jdk-18/lib/server/libjvm.so
> #18 0x00007fa234d22459 in ClassFileParser::parse_stream(ClassFileStream const*, JavaThread*) ()
>    from /usr/java/jdk-18/lib/server/libjvm.so
> #19 0x00007fa234d2291c in ClassFileParser::ClassFileParser(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const*, ClassFileParser::Publicity, JavaThread*) () from /usr/java/jdk-18/lib/server/libjvm.so
> #20 0x00007fa2351febb6 in KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const&, JavaThread*) ()
>    from /usr/java/jdk-18/lib/server/libjvm.so
> #21 0x00007fa235645b40 in SystemDictionary::resolve_class_from_stream(ClassFileStream*, Symbol*, Handle, ClassLoadInfo const&, JavaThread*) ()
>    from /usr/java/jdk-18/lib/server/libjvm.so
> #22 0x00007fa2350bad0a in jvm_define_class_common(char const*, _jobject*, signed char const*, int, _jobject*, char const*, JavaThread*) [clone .constprop.299] ()
>    from /usr/java/jdk-18/lib/server/libjvm.so
> #23 0x00007fa2350bae6d in JVM_DefineClassWithSource () from /usr/java/jdk-18/lib/server/libjvm.so
> #24 0x00007fa236a0ee12 in Java_java_lang_ClassLoader_defineClass1 () from /usr/java/jdk-18/lib/libjava.so

@apangin Thanks for pointing that out! I'm updating it right now and should be pushing an update very soon. I'll also add examples on how it impacts JFR.

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

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

From lmesnik at openjdk.java.net  Wed Jul 21 22:57:03 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 21 Jul 2021 22:57:03 GMT
Subject: RFR: 8271092: [TESTBUG] Cleanup unused
 HeapMonitor/MyPackage.HeapMonitorStatObjectCorrectnessTest::statsHaveExpectedNumberSamples
Message-ID: <lFK139qHkUhBa-lXTpKkIvN8eusRp06wg1DFJmfAsVY=.b6ecfbca-10c7-4cfe-97d3-c101fd93775a@github.com>

Simple cleanup.

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

Commit messages:
 - method removed

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

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

From lmesnik at openjdk.java.net  Wed Jul 21 23:57:52 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 21 Jul 2021 23:57:52 GMT
Subject: Withdrawn: 8271092: [TESTBUG] Cleanup unused
 HeapMonitor/MyPackage.HeapMonitorStatObjectCorrectnessTest::statsHaveExpectedNumberSamples
In-Reply-To: <lFK139qHkUhBa-lXTpKkIvN8eusRp06wg1DFJmfAsVY=.b6ecfbca-10c7-4cfe-97d3-c101fd93775a@github.com>
References: <lFK139qHkUhBa-lXTpKkIvN8eusRp06wg1DFJmfAsVY=.b6ecfbca-10c7-4cfe-97d3-c101fd93775a@github.com>
Message-ID: <k8ZAeveaqK3x1hcJUvtsbefU0uICe6OctDgvEEELqyc=.8541aac8-8cd3-475f-b2ea-2ba97e5fc802@github.com>

On Wed, 21 Jul 2021 22:49:13 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Simple cleanup.

This pull request has been closed without being integrated.

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

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

From lmesnik at openjdk.java.net  Thu Jul 22 01:37:07 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 22 Jul 2021 01:37:07 GMT
Subject: RFR: 8225313:
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
 failed with Unexpected high difference percentage
Message-ID: <ya3aQQpypui_lXrk_NyN3MNRvVuKDbYFop8qL-XSdRo=.8548bd3a-12dc-4ed4-b9d5-e7be086dc50b@github.com>

Fixed as suggested (increasing accepted error rate and a number of iteration). Verified by 2000 runs in our CI lab.The average test execution time ~5s. The bugs in the problemlist are duplicates of this issue.

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

Commit messages:
 - tests fixed
 - method removed

Changes: https://git.openjdk.java.net/jdk/pull/4864/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4864&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8225313
  Stats: 35 lines in 3 files changed: 10 ins; 16 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4864.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4864/head:pull/4864

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

From lmesnik at openjdk.java.net  Thu Jul 22 01:37:07 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 22 Jul 2021 01:37:07 GMT
Subject: RFR: 8225313:
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
 failed with Unexpected high difference percentage
In-Reply-To: <ya3aQQpypui_lXrk_NyN3MNRvVuKDbYFop8qL-XSdRo=.8548bd3a-12dc-4ed4-b9d5-e7be086dc50b@github.com>
References: <ya3aQQpypui_lXrk_NyN3MNRvVuKDbYFop8qL-XSdRo=.8548bd3a-12dc-4ed4-b9d5-e7be086dc50b@github.com>
Message-ID: <VwN9E-cNOgvZ0A_gh-VH97I92_8hZPH9uEf8uSL97u8=.9b15dfcc-b507-4b27-b7e3-2d87130ca28b@github.com>

On Thu, 22 Jul 2021 01:31:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Fixed as suggested (increasing accepted error rate and a number of iteration). Verified by 2000 runs in our CI lab.The average test execution time ~5s. The bugs in the problemlist are duplicates of this issue.

test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java line 43:

> 41:   private static BigObject obj;
> 42: 
> 43:   private native static boolean statsHaveExpectedNumberSamples(int expected, int percentError);

The method is not implemented and not used.

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

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

From dholmes at openjdk.java.net  Thu Jul 22 01:49:48 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 22 Jul 2021 01:49:48 GMT
Subject: RFR: 8225313:
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
 failed with Unexpected high difference percentage
In-Reply-To: <ya3aQQpypui_lXrk_NyN3MNRvVuKDbYFop8qL-XSdRo=.8548bd3a-12dc-4ed4-b9d5-e7be086dc50b@github.com>
References: <ya3aQQpypui_lXrk_NyN3MNRvVuKDbYFop8qL-XSdRo=.8548bd3a-12dc-4ed4-b9d5-e7be086dc50b@github.com>
Message-ID: <LvedkduST8ItRymdF_ip3SvpfrNJwibDy7yBGSE5Dnc=.c32866f9-9e92-409e-805d-d6511f780129@github.com>

On Thu, 22 Jul 2021 01:31:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Fixed as suggested (increasing accepted error rate and a number of iteration). Verified by 2000 runs in our CI lab.The average test execution time ~5s. The bugs in the problemlist are duplicates of this issue.

Hi Leonid,

These changes seem quite reasonable.

There is a comment in HeapMonitorStatIntervalTest.java that still refers to a 10% threshhold.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From lmesnik at openjdk.java.net  Thu Jul 22 02:10:08 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 22 Jul 2021 02:10:08 GMT
Subject: RFR: 8225313:
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
 failed with Unexpected high difference percentage [v2]
In-Reply-To: <ya3aQQpypui_lXrk_NyN3MNRvVuKDbYFop8qL-XSdRo=.8548bd3a-12dc-4ed4-b9d5-e7be086dc50b@github.com>
References: <ya3aQQpypui_lXrk_NyN3MNRvVuKDbYFop8qL-XSdRo=.8548bd3a-12dc-4ed4-b9d5-e7be086dc50b@github.com>
Message-ID: <w50Qfstu1RFzRzrUiUJMjAQzVvKrVVEu-E7NrAbZrwY=.de4911c0-f8c8-4724-a8e3-30beaba750de@github.com>

> Fixed as suggested (increasing accepted error rate and a number of iteration). Verified by 2000 runs in our CI lab.The average test execution time ~5s. The bugs in the problemlist are duplicates of this issue.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  HeapMonitorStatIntervalTest.java is also updated to allow 15% diff

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4864/files
  - new: https://git.openjdk.java.net/jdk/pull/4864/files/8f2e1a99..b9c185cf

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

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

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

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: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
Message-ID: <nXFwVb6mvp6siJUrbGVRMKEJvk3pi0xGrupqaMBBZgY=.541bd7b2-b11c-4889-a898-ac17fab3d0c4@github.com>

On Wed, 16 Jun 2021 12:57:44 GMT, Thomas Stuefe <stuefe at openjdk.org> 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 <stuefe at openjdk.org>
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 dholmes at openjdk.java.net  Thu Jul 22 04:50:46 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 22 Jul 2021 04:50:46 GMT
Subject: RFR: 8225313:
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
 failed with Unexpected high difference percentage [v2]
In-Reply-To: <w50Qfstu1RFzRzrUiUJMjAQzVvKrVVEu-E7NrAbZrwY=.de4911c0-f8c8-4724-a8e3-30beaba750de@github.com>
References: <ya3aQQpypui_lXrk_NyN3MNRvVuKDbYFop8qL-XSdRo=.8548bd3a-12dc-4ed4-b9d5-e7be086dc50b@github.com>
 <w50Qfstu1RFzRzrUiUJMjAQzVvKrVVEu-E7NrAbZrwY=.de4911c0-f8c8-4724-a8e3-30beaba750de@github.com>
Message-ID: <lvsr0-qYBBmUVJJQWBrEFYv6Grn1yKqdlG1ZPDHUSd4=.d8cffc56-0570-4e69-ad61-373cecddf188@github.com>

On Thu, 22 Jul 2021 02:10:08 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Fixed as suggested (increasing accepted error rate and a number of iteration). Verified by 2000 runs in our CI lab.The average test execution time ~5s. The bugs in the problemlist are duplicates of this issue.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HeapMonitorStatIntervalTest.java is also updated to allow 15% diff

Update looks good.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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

From lmesnik at openjdk.java.net  Thu Jul 22 05:16:08 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 22 Jul 2021 05:16:08 GMT
Subject: RFR: 8225313:
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
 failed with Unexpected high difference percentage [v3]
In-Reply-To: <ya3aQQpypui_lXrk_NyN3MNRvVuKDbYFop8qL-XSdRo=.8548bd3a-12dc-4ed4-b9d5-e7be086dc50b@github.com>
References: <ya3aQQpypui_lXrk_NyN3MNRvVuKDbYFop8qL-XSdRo=.8548bd3a-12dc-4ed4-b9d5-e7be086dc50b@github.com>
Message-ID: <JTnZDJO7IH_m-6PtZHJSK2ZdYvEd-aQmiM5gGa4aEVk=.41a2342a-31ca-4a1e-be12-9d36bad828c0@github.com>

> Fixed as suggested (increasing accepted error rate and a number of iteration). Verified by 2000 runs in our CI lab.The average test execution time ~5s. The bugs in the problemlist are duplicates of this issue.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  Also increased iterations in HeapMonitorStatIntervalTest.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4864/files
  - new: https://git.openjdk.java.net/jdk/pull/4864/files/b9c185cf..e62c22a9

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

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

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

From lmesnik at openjdk.java.net  Thu Jul 22 05:16:09 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 22 Jul 2021 05:16:09 GMT
Subject: RFR: 8225313:
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
 failed with Unexpected high difference percentage [v2]
In-Reply-To: <w50Qfstu1RFzRzrUiUJMjAQzVvKrVVEu-E7NrAbZrwY=.de4911c0-f8c8-4724-a8e3-30beaba750de@github.com>
References: <ya3aQQpypui_lXrk_NyN3MNRvVuKDbYFop8qL-XSdRo=.8548bd3a-12dc-4ed4-b9d5-e7be086dc50b@github.com>
 <w50Qfstu1RFzRzrUiUJMjAQzVvKrVVEu-E7NrAbZrwY=.de4911c0-f8c8-4724-a8e3-30beaba750de@github.com>
Message-ID: <UxEGJ38lYJsZY1xSGqwaaweqWgVMCBpg8lXxxuw_wVA=.3e715432-c786-4047-be1a-f4d300a7d093@github.com>

On Thu, 22 Jul 2021 02:10:08 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Fixed as suggested (increasing accepted error rate and a number of iteration). Verified by 2000 runs in our CI lab.The average test execution time ~5s. The bugs in the problemlist are duplicates of this issue.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HeapMonitorStatIntervalTest.java is also updated to allow 15% diff

testing shows that HeapMonitorStatIntervalTest.java needed to make more iterations a well as other fixed tests.

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

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

From dholmes at openjdk.java.net  Thu Jul 22 05:46:47 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 22 Jul 2021 05:46:47 GMT
Subject: RFR: 8225313:
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
 failed with Unexpected high difference percentage [v3]
In-Reply-To: <JTnZDJO7IH_m-6PtZHJSK2ZdYvEd-aQmiM5gGa4aEVk=.41a2342a-31ca-4a1e-be12-9d36bad828c0@github.com>
References: <ya3aQQpypui_lXrk_NyN3MNRvVuKDbYFop8qL-XSdRo=.8548bd3a-12dc-4ed4-b9d5-e7be086dc50b@github.com>
 <JTnZDJO7IH_m-6PtZHJSK2ZdYvEd-aQmiM5gGa4aEVk=.41a2342a-31ca-4a1e-be12-9d36bad828c0@github.com>
Message-ID: <I79o14WL7ZAn7JdA0K_jSCdb1vp0C1MSfJVMum2YYsc=.f82e6960-1936-48b0-96f0-89294007d50a@github.com>

On Thu, 22 Jul 2021 05:16:08 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Fixed as suggested (increasing accepted error rate and a number of iteration). Verified by 2000 runs in our CI lab.The average test execution time ~5s. The bugs in the problemlist are duplicates of this issue.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also increased iterations in HeapMonitorStatIntervalTest.java

Marked as reviewed by dholmes (Reviewer).

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

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

From kevinw at openjdk.java.net  Thu Jul 22 08:36:50 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 22 Jul 2021 08:36:50 GMT
Subject: RFR: 8225313:
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
 failed with Unexpected high difference percentage [v3]
In-Reply-To: <JTnZDJO7IH_m-6PtZHJSK2ZdYvEd-aQmiM5gGa4aEVk=.41a2342a-31ca-4a1e-be12-9d36bad828c0@github.com>
References: <ya3aQQpypui_lXrk_NyN3MNRvVuKDbYFop8qL-XSdRo=.8548bd3a-12dc-4ed4-b9d5-e7be086dc50b@github.com>
 <JTnZDJO7IH_m-6PtZHJSK2ZdYvEd-aQmiM5gGa4aEVk=.41a2342a-31ca-4a1e-be12-9d36bad828c0@github.com>
Message-ID: <UBsPVyNz7xWqbOOmBJIMzM__YIJOvhetLlTS1REQhP8=.981255ed-bd01-4691-ae60-47c6c5d57e1f@github.com>

On Thu, 22 Jul 2021 05:16:08 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Fixed as suggested (increasing accepted error rate and a number of iteration). Verified by 2000 runs in our CI lab.The average test execution time ~5s. The bugs in the problemlist are duplicates of this issue.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also increased iterations in HeapMonitorStatIntervalTest.java

Marked as reviewed by kevinw (Committer).

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

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

From iwalulya at openjdk.java.net  Thu Jul 22 13:12:49 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 22 Jul 2021 13:12:49 GMT
Subject: RFR: 8271043: Rename G1CollectedHeap::g1mm()
In-Reply-To: <N7CjiGnczjRCLkyAqq16LTpkvma3i1cGJImW9jqFyEg=.b038ef5c-910d-4418-b59d-a9581f15ecd3@github.com>
References: <N7CjiGnczjRCLkyAqq16LTpkvma3i1cGJImW9jqFyEg=.b038ef5c-910d-4418-b59d-a9581f15ecd3@github.com>
Message-ID: <oUBvW1gUKUBe8SIhzNuljJLiQ0_2zisQ3BK6rXKm4xk=.b2438dab-4205-4606-ae74-b4ea0bc41f3d@github.com>

On Wed, 21 Jul 2021 14:12:21 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that renames the somewhat cryptic name `g1mm` with `monitoring_support` which sounds much better to me.
> Feel free to suggest a better name or if you think it's not worth I can also just drop this change.
> 
> Testing: tier1-5

lgtm!

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

Marked as reviewed by iwalulya (Committer).

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

From tschatzl at openjdk.java.net  Thu Jul 22 14:41:48 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 22 Jul 2021 14:41:48 GMT
Subject: RFR: 8271043: Rename G1CollectedHeap::g1mm()
In-Reply-To: <f53u569wW-DxZ6zbc4Jdu6QChv8FZUQCht1CvEGnghw=.860c8b58-1743-4d26-9149-646545a6ccee@github.com>
References: <N7CjiGnczjRCLkyAqq16LTpkvma3i1cGJImW9jqFyEg=.b038ef5c-910d-4418-b59d-a9581f15ecd3@github.com>
 <f53u569wW-DxZ6zbc4Jdu6QChv8FZUQCht1CvEGnghw=.860c8b58-1743-4d26-9149-646545a6ccee@github.com>
Message-ID: <BLnTgWxsokQaQ5vnYmdSLBrbhkxBN8Omtt2JrvDeAio=.5f6cc3be-01cf-40cd-a96a-551bb264ad3d@github.com>

On Wed, 21 Jul 2021 19:18:01 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that renames the somewhat cryptic name `g1mm` with `monitoring_support` which sounds much better to me.
>> Feel free to suggest a better name or if you think it's not worth I can also just drop this change.
>> 
>> Testing: tier1-5
>
> Looks good.

Thanks @kimbarrett @walulyai for your reviews

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

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

From tschatzl at openjdk.java.net  Thu Jul 22 14:41:49 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 22 Jul 2021 14:41:49 GMT
Subject: Integrated: 8271043: Rename G1CollectedHeap::g1mm()
In-Reply-To: <N7CjiGnczjRCLkyAqq16LTpkvma3i1cGJImW9jqFyEg=.b038ef5c-910d-4418-b59d-a9581f15ecd3@github.com>
References: <N7CjiGnczjRCLkyAqq16LTpkvma3i1cGJImW9jqFyEg=.b038ef5c-910d-4418-b59d-a9581f15ecd3@github.com>
Message-ID: <W6WEOCZmXbhteNBhZ4j4uPR3SHdaECje-xrsJxlWx30=.243c4f76-c58f-4c04-9d61-f0870b444409@github.com>

On Wed, 21 Jul 2021 14:12:21 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that renames the somewhat cryptic name `g1mm` with `monitoring_support` which sounds much better to me.
> Feel free to suggest a better name or if you think it's not worth I can also just drop this change.
> 
> Testing: tier1-5

This pull request has now been integrated.

Changeset: 8e27d4e8
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8e27d4e8ceb3c4ea15e3a3a4328368dbe801870b
Stats:     48 lines in 12 files changed: 1 ins; 0 del; 47 mod

8271043: Rename G1CollectedHeap::g1mm()

Reviewed-by: kbarrett, iwalulya

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

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

From mbaesken at openjdk.java.net  Thu Jul 22 15:23:29 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 22 Jul 2021 15:23:29 GMT
Subject: RFR: JDK-8271149: remove unreferenced functions from
 EncodingSupport_md.c
Message-ID: <NdtZisIJ4VvCznLVAitL26nHYwJ0HBdVtBf5WU2rhh0=.08ac593b-69cb-4a45-b638-2aad2160c426@github.com>

Please review this small change.
I was running into those 2 warnings in EncodingSupport_md.c
function "utfTerminate" was declared but never referenced
function "platformToUtf8" was declared but never referenced

Probably those 2 functions can and should be removed.

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

Commit messages:
 - JDK-8271149

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

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

From kevinw at openjdk.java.net  Thu Jul 22 16:40:57 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 22 Jul 2021 16:40:57 GMT
Subject: RFR: 8269616: serviceability/dcmd/framework/VMVersionTest.java
 fails with Address already in use error
In-Reply-To: <cGHTffmXV_fPcR2uzsbb0Xyj7QUqg0Sm1ZkUCkwhXUg=.b4f9adb3-a430-42f0-a95d-e5a906c9e30d@github.com>
References: <cGHTffmXV_fPcR2uzsbb0Xyj7QUqg0Sm1ZkUCkwhXUg=.b4f9adb3-a430-42f0-a95d-e5a906c9e30d@github.com>
Message-ID: <1bvZxBgRwwfuFfNw15JEeEWJazAYaXj5eky39tkFfHA=.8f60d446-2cb4-4b80-89b1-eb2ea2224c8c@github.com>

On Fri, 2 Jul 2021 21:23:39 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> SocketIOPipe/IOPipe classes can select listening port by 2 ways:
> 1. caller specifies "-transport.address=dynamic" argument creating ArgumentHandler,
> and calls Binder.prepareForPipeConnection (actually see nsk.share.jpda.DebugeeBinder.prepareForPipeConnection()) before start listening.
> In the case prepareForPipeConnection creates socket and this socket later is used by IOPipe.
> 2. just start IOPipe listening.
> Then port is selected by calling nsk.share.jpda.DebugeeArgumentHandler.getTransportPort() which use findFreePort() method:
> 
>     ServerSocket ss;
>     try {
>         ss = new ServerSocket(0);
>         return String.valueOf(ss.getLocalPort());
>     }finally {
>         ss.close();
>     }
> 
> This method is known to be error prone (sometimes causes "address in use" error).
> 
> The fix adds "-transport.address=dynamic" argument so IOPipe use 1st method.

Marked as reviewed by kevinw (Committer).

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

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

From lmesnik at openjdk.java.net  Thu Jul 22 18:23:08 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 22 Jul 2021 18:23:08 GMT
Subject: Integrated: 8225313:
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
 failed with Unexpected high difference percentage
In-Reply-To: <ya3aQQpypui_lXrk_NyN3MNRvVuKDbYFop8qL-XSdRo=.8548bd3a-12dc-4ed4-b9d5-e7be086dc50b@github.com>
References: <ya3aQQpypui_lXrk_NyN3MNRvVuKDbYFop8qL-XSdRo=.8548bd3a-12dc-4ed4-b9d5-e7be086dc50b@github.com>
Message-ID: <ykvClAzC0ub4azuTKWc_NJjWnPQyfDskzPguoIlN4m0=.950cfe65-31c8-4b59-9601-cb0281fa9a3b@github.com>

On Thu, 22 Jul 2021 01:31:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Fixed as suggested (increasing accepted error rate and a number of iteration). Verified by 2000 runs in our CI lab.The average test execution time ~5s. The bugs in the problemlist are duplicates of this issue.

This pull request has now been integrated.

Changeset: 09e53217
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/09e5321763f3fafe2b0b562f99ec0cd55a59583c
Stats:     39 lines in 4 files changed: 10 ins; 16 del; 13 mod

8225313: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java failed with Unexpected high difference percentage

Reviewed-by: dholmes, kevinw

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

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

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: <HELRamq0UD-l1EmFoRc7_4PHxmoxB0-oeXQKBBcFLFE=.d8f0f710-8054-46e0-8f36-6eb7bc0899e5@github.com>

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: <HELRamq0UD-l1EmFoRc7_4PHxmoxB0-oeXQKBBcFLFE=.d8f0f710-8054-46e0-8f36-6eb7bc0899e5@github.com>
References: <HELRamq0UD-l1EmFoRc7_4PHxmoxB0-oeXQKBBcFLFE=.d8f0f710-8054-46e0-8f36-6eb7bc0899e5@github.com>
Message-ID: <bih9UdSR0zdIV7X0FZeo6_pkvUf09YZp_09mlMOyB04=.5c50b9ca-7ab0-470e-bf1a-b8544b388abb@github.com>

On Thu, 22 Jul 2021 21:51:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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 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: <HELRamq0UD-l1EmFoRc7_4PHxmoxB0-oeXQKBBcFLFE=.d8f0f710-8054-46e0-8f36-6eb7bc0899e5@github.com>
References: <HELRamq0UD-l1EmFoRc7_4PHxmoxB0-oeXQKBBcFLFE=.d8f0f710-8054-46e0-8f36-6eb7bc0899e5@github.com>
Message-ID: <MjMudMyEedII28MJI72avn3xrImsP31be4pwvrdXQC4=.6697817b-ebac-425d-8278-dba40d343c53@github.com>

On Thu, 22 Jul 2021 21:51:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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 <dcubed at openjdk.org>
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: <bih9UdSR0zdIV7X0FZeo6_pkvUf09YZp_09mlMOyB04=.5c50b9ca-7ab0-470e-bf1a-b8544b388abb@github.com>
References: <HELRamq0UD-l1EmFoRc7_4PHxmoxB0-oeXQKBBcFLFE=.d8f0f710-8054-46e0-8f36-6eb7bc0899e5@github.com>
 <bih9UdSR0zdIV7X0FZeo6_pkvUf09YZp_09mlMOyB04=.5c50b9ca-7ab0-470e-bf1a-b8544b388abb@github.com>
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 <darcy at openjdk.org> 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 04:43:15 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 23 Jul 2021 04:43:15 GMT
Subject: [jdk17] RFR: 8271173: serviceability/jvmti/GetObjectSizeClass.java
 doesn't check exit code
Message-ID: <BWcwu5s1i035ZWygtc6UYegpMF-w3EBthdg2VUPnpFI=.1416f27a-03b2-454a-b60e-05f79a082824@github.com>

Hi all,

could you please review the patch that adds an exit-code check to `serviceability/jvmti/GetObjectSizeClass.java` test?

from JBS:
> `serviceability/jvmti/GetObjectSizeClass.java` test spawns a new JVM but doesn't check its exit code which might lead to both type-I and type-II errors

testing:  `serviceability/jvmti/GetObjectSizeClass.java`  on `{linux,windows,macos}-x64`

Thanks,
-- Igor

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

Commit messages:
 - 8271173

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

PR: https://git.openjdk.java.net/jdk17/pull/277

From alanb at openjdk.java.net  Fri Jul 23 06:21:04 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 23 Jul 2021 06:21:04 GMT
Subject: RFR: JDK-8271149: remove unreferenced functions from
 EncodingSupport_md.c
In-Reply-To: <NdtZisIJ4VvCznLVAitL26nHYwJ0HBdVtBf5WU2rhh0=.08ac593b-69cb-4a45-b638-2aad2160c426@github.com>
References: <NdtZisIJ4VvCznLVAitL26nHYwJ0HBdVtBf5WU2rhh0=.08ac593b-69cb-4a45-b638-2aad2160c426@github.com>
Message-ID: <3KfdjM_d9gRJsZuaVW00kKoix_xIV6_gPOb5l7nhab4=.b3e238d5-b1a2-441c-bd4d-5422901154bd@github.com>

On Thu, 22 Jul 2021 15:12:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small change.
> I was running into those 2 warnings in EncodingSupport_md.c
> function "utfTerminate" was declared but never referenced
> function "platformToUtf8" was declared but never referenced
> 
> Probably those 2 functions can and should be removed.

Marked as reviewed by alanb (Reviewer).

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

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

From dholmes at openjdk.java.net  Fri Jul 23 06:38:03 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 23 Jul 2021 06:38:03 GMT
Subject: [jdk17] RFR: 8271173:
 serviceability/jvmti/GetObjectSizeClass.java doesn't check exit code
In-Reply-To: <BWcwu5s1i035ZWygtc6UYegpMF-w3EBthdg2VUPnpFI=.1416f27a-03b2-454a-b60e-05f79a082824@github.com>
References: <BWcwu5s1i035ZWygtc6UYegpMF-w3EBthdg2VUPnpFI=.1416f27a-03b2-454a-b60e-05f79a082824@github.com>
Message-ID: <9LWyNhy49Hho1vF1ny9qyuOeOl1MMFdJyRX1INAeN20=.336379ec-9685-4f4e-b28e-2d3fcb5dc8cb@github.com>

On Fri, 23 Jul 2021 04:34:50 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch that adds an exit-code check to `serviceability/jvmti/GetObjectSizeClass.java` test?
> 
> from JBS:
>> `serviceability/jvmti/GetObjectSizeClass.java` test spawns a new JVM but doesn't check its exit code which might lead to both type-I and type-II errors
> 
> testing:  `serviceability/jvmti/GetObjectSizeClass.java`  on `{linux,windows,macos}-x64`
> 
> Thanks,
> -- Igor

Looks good and trivial.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/277

From mbaesken at openjdk.java.net  Fri Jul 23 06:42:08 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 23 Jul 2021 06:42:08 GMT
Subject: Integrated: JDK-8271149: remove unreferenced functions from
 EncodingSupport_md.c
In-Reply-To: <NdtZisIJ4VvCznLVAitL26nHYwJ0HBdVtBf5WU2rhh0=.08ac593b-69cb-4a45-b638-2aad2160c426@github.com>
References: <NdtZisIJ4VvCznLVAitL26nHYwJ0HBdVtBf5WU2rhh0=.08ac593b-69cb-4a45-b638-2aad2160c426@github.com>
Message-ID: <ZxVt9hVuaZCEp2R8nm7551EWrMMip--LQsOUBkYevd0=.c215a88a-ad5a-4ba1-872b-6044eb2ce819@github.com>

On Thu, 22 Jul 2021 15:12:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small change.
> I was running into those 2 warnings in EncodingSupport_md.c
> function "utfTerminate" was declared but never referenced
> function "platformToUtf8" was declared but never referenced
> 
> Probably those 2 functions can and should be removed.

This pull request has now been integrated.

Changeset: fb859600
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fb85960015dfbd8e1d95d5fd7fdb65819828a317
Stats:     27 lines in 1 file changed: 0 ins; 26 del; 1 mod

8271149: remove unreferenced functions from EncodingSupport_md.c

Reviewed-by: alanb

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

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

From iignatyev at openjdk.java.net  Fri Jul 23 15:57:03 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 23 Jul 2021 15:57:03 GMT
Subject: [jdk17] RFR: 8271173:
 serviceability/jvmti/GetObjectSizeClass.java doesn't check exit code
In-Reply-To: <BWcwu5s1i035ZWygtc6UYegpMF-w3EBthdg2VUPnpFI=.1416f27a-03b2-454a-b60e-05f79a082824@github.com>
References: <BWcwu5s1i035ZWygtc6UYegpMF-w3EBthdg2VUPnpFI=.1416f27a-03b2-454a-b60e-05f79a082824@github.com>
Message-ID: <Nbs1Fj0paV4gAzJcbSknubEklyLBUeykV5dONSJHMZA=.093588a3-6c8b-469c-beb8-84efecad6c91@github.com>

On Fri, 23 Jul 2021 04:34:50 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch that adds an exit-code check to `serviceability/jvmti/GetObjectSizeClass.java` test?
> 
> from JBS:
>> `serviceability/jvmti/GetObjectSizeClass.java` test spawns a new JVM but doesn't check its exit code which might lead to both type-I and type-II errors
> 
> testing:  `serviceability/jvmti/GetObjectSizeClass.java`  on `{linux,windows,macos}-x64`
> 
> Thanks,
> -- Igor

Thanks, David.

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

PR: https://git.openjdk.java.net/jdk17/pull/277

From iignatyev at openjdk.java.net  Fri Jul 23 15:57:03 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 23 Jul 2021 15:57:03 GMT
Subject: [jdk17] Integrated: 8271173:
 serviceability/jvmti/GetObjectSizeClass.java doesn't check exit code
In-Reply-To: <BWcwu5s1i035ZWygtc6UYegpMF-w3EBthdg2VUPnpFI=.1416f27a-03b2-454a-b60e-05f79a082824@github.com>
References: <BWcwu5s1i035ZWygtc6UYegpMF-w3EBthdg2VUPnpFI=.1416f27a-03b2-454a-b60e-05f79a082824@github.com>
Message-ID: <N2qFp3vaGYK-rvK3CtOCeHso3KQU9qLNgu1n0-PbRS8=.74c546e7-8e0b-4b15-9272-690c41facdec@github.com>

On Fri, 23 Jul 2021 04:34:50 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch that adds an exit-code check to `serviceability/jvmti/GetObjectSizeClass.java` test?
> 
> from JBS:
>> `serviceability/jvmti/GetObjectSizeClass.java` test spawns a new JVM but doesn't check its exit code which might lead to both type-I and type-II errors
> 
> testing:  `serviceability/jvmti/GetObjectSizeClass.java`  on `{linux,windows,macos}-x64`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: e90ed6cc
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/e90ed6cc38ab8f8a2c7c740da1cb38144622b4eb
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8271173: serviceability/jvmti/GetObjectSizeClass.java doesn't check exit code

Reviewed-by: dholmes

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

PR: https://git.openjdk.java.net/jdk17/pull/277

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: <KmXzKbCwFQSOq0SS0IN2BTxajl6WBgXYYljQidzFcL0=.69f22959-2d9d-4a92-96bd-d0c553449f99@github.com>

On Fri, 23 Jul 2021 22:24:14 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 0dcfc42f
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
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 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: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <EbaTKOLj-G9rrAgEbQrbndEKO9ylLIjczIT1cfMUn24=.2ac6a009-349e-433b-ad35-8c72a5a3e262@github.com>

> 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 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: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
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 github.com+741251+turbanoff at openjdk.java.net  Mon Jul 26 11:30:21 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 26 Jul 2021 11:30:21 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
Message-ID: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>

I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

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

Commit messages:
 - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying
 - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying
 - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Jul 26 11:30:21 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 26 Jul 2021 11:30:21 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <RGdfH15SqrmAJ_F_lJsXWPgDXASBawZa6STmTw79O0M=.9a0479b0-2555-4541-95ba-665960ab4fbe@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

I think the same simlification can be done for some classes affected by your previous PR https://github.com/openjdk/jdk/pull/4482, e.g. `HttpsClient`, lines 154-157 and 177-180 and `PKCS7`, so I'd wait for https://github.com/openjdk/jdk/pull/4482 and then add one more commit here.

@turbanoff I've filed a ticket for this: https://bugs.openjdk.java.net/browse/JDK-8269130. Also I think you can integrate https://github.com/openjdk/jdk/pull/4482

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Jul 26 11:30:22 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 26 Jul 2021 11:30:22 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
 <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com>
Message-ID: <HbAuDh-MFnpUrGAxHJTKJX9_0ybK5EbYuHoTI3s2MPE=.6104a076-442a-4c67-9805-5c4008905d10@github.com>

On Tue, 15 Jun 2021 12:06:43 GMT, Michael Bien <github.com+114367+mbien at openjdk.org> wrote:

>> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
>> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.
>
> src/java.base/share/classes/java/security/Security.java line 656:
> 
>> 654:             return null;
>> 655: 
>> 656:         return candidates.toArray(new Provider[0]);
> 
> `candidates.toArray(new Provider[candidates.size()]);`
> 
> would use the fast path of the toArray() implementation. Performance probably doesn't matter much in a lot of this cases, but since its only a few characters more, its still worth considering IMO.
> 
> The only places I would leave this out are on the HashTable and on the Vector collections in this PR, since calling one synchronized method is not the same as calling two - concurrency wise.
> 
> (i am no reviewer)

Actually it's not _the fast path_ - see https://shipilev.net/blog/2016/arrays-wisdom-ancients/

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

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

From github.com+114367+mbien at openjdk.java.net  Mon Jul 26 11:30:21 2021
From: github.com+114367+mbien at openjdk.java.net (Michael Bien)
Date: Mon, 26 Jul 2021 11:30:21 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

src/java.base/share/classes/java/security/Security.java line 656:

> 654:             return null;
> 655: 
> 656:         return candidates.toArray(new Provider[0]);

`candidates.toArray(new Provider[candidates.size()]);`

would use the fast path of the toArray() implementation. Performance probably doesn't matter much in a lot of this cases, but since its only a few characters more, its still worth considering IMO.

The only places I would leave this out are on the HashTable and on the Vector collections in this PR, since calling one synchronized method is not the same as calling two - concurrency wise.

(i am no reviewer)

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

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

From github.com+114367+mbien at openjdk.java.net  Mon Jul 26 11:30:22 2021
From: github.com+114367+mbien at openjdk.java.net (Michael Bien)
Date: Mon, 26 Jul 2021 11:30:22 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <HbAuDh-MFnpUrGAxHJTKJX9_0ybK5EbYuHoTI3s2MPE=.6104a076-442a-4c67-9805-5c4008905d10@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
 <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com>
 <HbAuDh-MFnpUrGAxHJTKJX9_0ybK5EbYuHoTI3s2MPE=.6104a076-442a-4c67-9805-5c4008905d10@github.com>
Message-ID: <XMK9iClcp3uF-aORRgwlw0r7X9TGNvP12JYZSFESnwc=.4ee3292e-f9f0-4fb2-b039-8f4f2b97df34@github.com>

On Tue, 15 Jun 2021 12:34:50 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Security.java line 656:
>> 
>>> 654:             return null;
>>> 655: 
>>> 656:         return candidates.toArray(new Provider[0]);
>> 
>> `candidates.toArray(new Provider[candidates.size()]);`
>> 
>> would use the fast path of the toArray() implementation. Performance probably doesn't matter much in a lot of this cases, but since its only a few characters more, its still worth considering IMO.
>> 
>> The only places I would leave this out are on the HashTable and on the Vector collections in this PR, since calling one synchronized method is not the same as calling two - concurrency wise.
>> 
>> (i am no reviewer)
>
> Actually it's not _the fast path_ - see https://shipilev.net/blog/2016/arrays-wisdom-ancients/

oh I am sorry my mistake - I actually now remember reading the article. (It would be interesting to rerun the benchmark on modern JDKs since I would expect the gap to be smaller now)
Please disregard my suggestion.

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

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

From serb at openjdk.java.net  Mon Jul 26 11:30:23 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 26 Jul 2021 11:30:23 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <522sj45K-E26GUke0gp6dDoq_4dpwfLMytNVmg5V2k8=.2d5a1a6c-4191-4f63-a83e-af35c69cb6e4@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line 191:

> 189:                         installed[i]);
> 190:             }
> 191:             String[] retval = map.keySet().toArray(new String[0]);

Looks like previously the code returns values, and now it will return keys, please recheck.

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

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

From mullan at openjdk.java.net  Mon Jul 26 19:10:35 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 26 Jul 2021 19:10:35 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <w-b3bQRsyksOmZlapJ8a175cxPbajxOHPK5bP2mmfJ0=.dbc900f7-9a03-4233-90dd-8853e410adb2@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

The changes to the security classes look good.

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

Marked as reviewed by mullan (Reviewer).

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

From github.com+2996845+bokken at openjdk.java.net  Mon Jul 26 19:18:33 2021
From: github.com+2996845+bokken at openjdk.java.net (Brett Okken)
Date: Mon, 26 Jul 2021 19:18:33 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <amB5jIt1-LyF6A8_OxgTfO6tDKhujRwvnM1QYqPbzkU=.17cd1c88-0ff5-42f6-ad9b-53d5cbdd74e5@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

src/java.base/share/classes/java/security/Security.java line 656:

> 654:             return null;
> 655: 
> 656:         return candidates.toArray(new Provider[0]);

Is this called often enough to warrant creating a constant of `new Provider[0]` (benefits of this covered in the _Wisdom of the Ancients_ blog linked)?

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

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

From github.com+2996845+bokken at openjdk.java.net  Mon Jul 26 19:58:30 2021
From: github.com+2996845+bokken at openjdk.java.net (Brett Okken)
Date: Mon, 26 Jul 2021 19:58:30 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <FRn0jQHYWMJL5GTfhu4TWGlg8OaBHVpEoIQ_pCka3rs=.151177ce-ac88-4932-b8c9-c6e59a148b5c@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/SystemDictionaryHelper.java line 92:

> 90:       }
> 91: 
> 92:       InstanceKlass[] searchResult = tmp.toArray(new InstanceKlass[0]);

Is it too far outside the scope of these changes to make `tmp` an `ArrayList` rather than a `Vector`?

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

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

From amenkov at openjdk.java.net  Mon Jul 26 20:19:37 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 26 Jul 2021 20:19:37 GMT
Subject: Integrated: 8269616: serviceability/dcmd/framework/VMVersionTest.java
 fails with Address already in use error
In-Reply-To: <cGHTffmXV_fPcR2uzsbb0Xyj7QUqg0Sm1ZkUCkwhXUg=.b4f9adb3-a430-42f0-a95d-e5a906c9e30d@github.com>
References: <cGHTffmXV_fPcR2uzsbb0Xyj7QUqg0Sm1ZkUCkwhXUg=.b4f9adb3-a430-42f0-a95d-e5a906c9e30d@github.com>
Message-ID: <xjyRrHhjdIvf3wRq4HYvAScuAzz0RoZcxI7rsJChiso=.bc140e4c-8abc-4e34-842f-c6e9c45139cf@github.com>

On Fri, 2 Jul 2021 21:23:39 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> SocketIOPipe/IOPipe classes can select listening port by 2 ways:
> 1. caller specifies "-transport.address=dynamic" argument creating ArgumentHandler,
> and calls Binder.prepareForPipeConnection (actually see nsk.share.jpda.DebugeeBinder.prepareForPipeConnection()) before start listening.
> In the case prepareForPipeConnection creates socket and this socket later is used by IOPipe.
> 2. just start IOPipe listening.
> Then port is selected by calling nsk.share.jpda.DebugeeArgumentHandler.getTransportPort() which use findFreePort() method:
> 
>     ServerSocket ss;
>     try {
>         ss = new ServerSocket(0);
>         return String.valueOf(ss.getLocalPort());
>     }finally {
>         ss.close();
>     }
> 
> This method is known to be error prone (sometimes causes "address in use" error).
> 
> The fix adds "-transport.address=dynamic" argument so IOPipe use 1st method.

This pull request has now been integrated.

Changeset: 8785737b
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8785737ba5f398888816ddd0f50adeea6a75bb0f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8269616: serviceability/dcmd/framework/VMVersionTest.java fails with Address already in use error

Reviewed-by: sspitsyn, kevinw

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

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

From amenkov at openjdk.java.net  Mon Jul 26 20:20:33 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 26 Jul 2021 20:20:33 GMT
Subject: RFR: 8269770: nsk tests should start IOPipe channel before launch
 debuggee - Debugee.prepareDebugee [v2]
In-Reply-To: <NN8U4ddBK-4rcoVri_yEo8o13MAOajtLl4smgln4PJ0=.347bd198-8e2e-4b8b-99bf-ef808f5c894f@github.com>
References: <Ul6inNVMRVB_OAtRF6ONX1HfJ1xLxZ-olKE95X_FiF4=.9b6cad69-0927-4750-b28d-e3099ea4f636@github.com>
 <NN8U4ddBK-4rcoVri_yEo8o13MAOajtLl4smgln4PJ0=.347bd198-8e2e-4b8b-99bf-ef808f5c894f@github.com>
Message-ID: <poGjZE28Fiz6E2Lv6jYpSjnbGA6IsnMN5RvIGJKId34=.b77e67b4-57c6-4617-a6b2-e657bf1a5605@github.com>

On Fri, 2 Jul 2021 19:30:11 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The change fixes several hundreds tests which launch debugee by using uses Debugee.prepareDebugee() method or use 
>> debugee = Binder.bindToDebugee(...);
>> IOPipe pipe = debugee.createIOPipe();
>> logic.
>> Debugee.prepareDebugee() and Binder.bindToDebugee() launch debuggee by using CommandLineLaunch JDI connector with suspend=="true" argument, so they return debuggee suspended before the main class is loaded.
>> The fix starts IOPipe listening before debuggee VM is resumed.
>> 
>> Simplified isPackagePrivate/accipp001.java test to use Debugee.prepareDebugee() - it does exactly the same as Debugee.prepareDebugee() does (the only difference is using deprecated IOPipe ctor instead of Debugee.createIOPipe())
>> 
>> Tested all affected tests:
>> test/hotspot/jtreg/vmTestbase/nsk/jdi
>> test/hotspot/jtreg/vmTestbase/nsk/jdwp
>> test/hotspot/jtreg/serviceability/dcmd
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed comment

Ping. Need 2nd reviewer

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

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

From amenkov at openjdk.java.net  Mon Jul 26 20:21:31 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 26 Jul 2021 20:21:31 GMT
Subject: RFR: 8213714: AttachingConnector/attach/attach001 failed due to
 "bind failed: Address already in use"
In-Reply-To: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
References: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
Message-ID: <xbwuo0-gQ4Tfma4DzsE3fCx7zrdHhKmqMKxOa960FgE=.2557cc86-450b-4f10-944d-c9568b6c5174@github.com>

On Sat, 17 Jul 2021 00:38:44 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates the tests to use dynamic port launching debuggee and get the listening port from the debugee output

Ping

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

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

From ngasson at openjdk.java.net  Tue Jul 27 02:07:31 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 27 Jul 2021 02:07:31 GMT
Subject: RFR: 8261236: C2: ClhsdbJstackXcompStress test fails when
 StressGCM is enabled
In-Reply-To: <8U-kroIDfbokzTWhwd1rmxhmVppQa8iE0RosSiShlL0=.dffc71c2-1365-499b-8e20-c0c946001068@github.com>
References: <3dsIKe2U3zN7oTZlGUFM4PQ0fglWb6bsCUIfCTISM6g=.c5de4eff-f6bb-43ea-96fc-9a155d5d4839@github.com>
 <8U-kroIDfbokzTWhwd1rmxhmVppQa8iE0RosSiShlL0=.dffc71c2-1365-499b-8e20-c0c946001068@github.com>
Message-ID: <7b-N3DN5ayPoODzvDsYezhfO5HonGZ3Tzi8HkEkd5KM=.bd8a2ebf-b712-4005-9bdc-115f24153748@github.com>

On Mon, 19 Jul 2021 23:50:07 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> The clhsdb jstack command crashes when the debugged program is run with `-Xcomp -XX:+StressGCM -XX:StressSeed=2` on AArch64:
>> 
>> 
>>   sun.jvm.hotspot.utilities.AssertionFailure: sanity check
>>   at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>>   at jdk.hotspot.agent/sun.jvm.hotspot.runtime.RegisterMap.setLocation(RegisterMap.java:160)
>>   at jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet.updateRegisterMap(ImmutableOopMapSet.java:303)
>>   at jdk.hotspot.agent/sun.jvm.hotspot.runtime.aarch64.AARCH64Frame.senderForCompiledFrame(AARCH64Frame.java:407)
>> 
>> 
>> The assertion failure here is:
>> 
>> 
>>   Assert.that(0 <= i && i < regCount, "sanity check");
>> 
>> 
>> I.e. there's an invalid register in the oop map.
>> 
>> The problem seems to be caused by the changes in JDK-8231586 which changed `OopMapValue::oop_types` from a bit mask to normal integer enum. However the changes in the C++ code weren't mirrored in SA's OopMapStream which still treats OopTypes as a bit mask.
>> 
>> The particular oop map this is crashing on looks like this:
>> 
>> 
>>   ImmutableOopMap {[24]=Oop [32]=Oop [40]=Derived_oop_[24] } pc offsets: 324
>> 
>> 
>> The code is looking for callee saved values (type=2) by AND-ing with each oop value type in the set, so it wrongly interprets the derived oop [40] (type=3) as a callee saved register.
>> 
>> This patch just mirrors the changes to the C++ code into the corresponding SA classes.  The C++ OopMapStream constructor no longer takes a type filter argument and callers are expected filter themselves, so I've made the same change to the Java code.
>> 
>> This bug can also be seen using the clhsdb "disassemble" command.  For example the above oop map is currently printed incorrectly as:
>> 
>> 
>>   OopMap:
>>   NarrowOops:[40]
>>   Callee saved:[40] = [24]
>>   Derived oops:[40] = [24]
>> 
>> 
>> With this patch it becomes:
>> 
>> 
>>   OopMap:
>>   Oops:[24]  [32]
>>   Derived oops:[40] = [24]
>> 
>> 
>> This bug was reported on AArch64 but it seems to be just luck that we don't see it on other platforms.
>> 
>> Tested tier1 and hotspot_serviceability on AArch64 and x86.
>
> Yes that looks like the right fix to me.  Sorry for missing this part.

Thanks @tkrodriguez . Could I get a second review for this please?

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

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

From ngasson at openjdk.java.net  Tue Jul 27 09:33:46 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 27 Jul 2021 09:33:46 GMT
Subject: RFR: 8271323: [TESTBUG] serviceability/sa/ClhsdbCDSCore.java fails
 with -XX:TieredStopAtLevel=1
Message-ID: <xBnQNgFvVEgGfevy49IsSNUjAGXsdiwMmhTncgW82w8=.478f07e7-97ac-4d4c-a6e4-5c31286920c0@github.com>

This test fails reliably with `-XX:TieredStopAtLevel=1` since JDK-8251462. MDOs are no longer allocated in this mode so the clhsdb `printmdo -a` command prints nothing.  The failure is basically the same as JDK-8236042 which happened with `-Xcomp -XX:TieredStopAtLevel=1` so the workaround for that just needs to be adjusted slightly.

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

Commit messages:
 - 8271323: [TESTBUG] serviceability/sa/ClhsdbCDSCore.java fails with -XX:TieredStopAtLevel=1

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

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

From kvn at openjdk.java.net  Tue Jul 27 15:51:29 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Jul 2021 15:51:29 GMT
Subject: RFR: 8261236: C2: ClhsdbJstackXcompStress test fails when
 StressGCM is enabled
In-Reply-To: <3dsIKe2U3zN7oTZlGUFM4PQ0fglWb6bsCUIfCTISM6g=.c5de4eff-f6bb-43ea-96fc-9a155d5d4839@github.com>
References: <3dsIKe2U3zN7oTZlGUFM4PQ0fglWb6bsCUIfCTISM6g=.c5de4eff-f6bb-43ea-96fc-9a155d5d4839@github.com>
Message-ID: <yRCLT3lLpp5zrWoRmHJUa75QJqQ1xJb4JGxt27Ev-6M=.b0438c16-9520-4eb8-a362-c0a67457dca1@github.com>

On Fri, 16 Jul 2021 10:24:56 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The clhsdb jstack command crashes when the debugged program is run with `-Xcomp -XX:+StressGCM -XX:StressSeed=2` on AArch64:
> 
> 
>   sun.jvm.hotspot.utilities.AssertionFailure: sanity check
>   at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>   at jdk.hotspot.agent/sun.jvm.hotspot.runtime.RegisterMap.setLocation(RegisterMap.java:160)
>   at jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet.updateRegisterMap(ImmutableOopMapSet.java:303)
>   at jdk.hotspot.agent/sun.jvm.hotspot.runtime.aarch64.AARCH64Frame.senderForCompiledFrame(AARCH64Frame.java:407)
> 
> 
> The assertion failure here is:
> 
> 
>   Assert.that(0 <= i && i < regCount, "sanity check");
> 
> 
> I.e. there's an invalid register in the oop map.
> 
> The problem seems to be caused by the changes in JDK-8231586 which changed `OopMapValue::oop_types` from a bit mask to normal integer enum. However the changes in the C++ code weren't mirrored in SA's OopMapStream which still treats OopTypes as a bit mask.
> 
> The particular oop map this is crashing on looks like this:
> 
> 
>   ImmutableOopMap {[24]=Oop [32]=Oop [40]=Derived_oop_[24] } pc offsets: 324
> 
> 
> The code is looking for callee saved values (type=2) by AND-ing with each oop value type in the set, so it wrongly interprets the derived oop [40] (type=3) as a callee saved register.
> 
> This patch just mirrors the changes to the C++ code into the corresponding SA classes.  The C++ OopMapStream constructor no longer takes a type filter argument and callers are expected filter themselves, so I've made the same change to the Java code.
> 
> This bug can also be seen using the clhsdb "disassemble" command.  For example the above oop map is currently printed incorrectly as:
> 
> 
>   OopMap:
>   NarrowOops:[40]
>   Callee saved:[40] = [24]
>   Derived oops:[40] = [24]
> 
> 
> With this patch it becomes:
> 
> 
>   OopMap:
>   Oops:[24]  [32]
>   Derived oops:[40] = [24]
> 
> 
> This bug was reported on AArch64 but it seems to be just luck that we don't see it on other platforms.
> 
> Tested tier1 and hotspot_serviceability on AArch64 and x86.

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From cjplummer at openjdk.java.net  Tue Jul 27 19:51:35 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 27 Jul 2021 19:51:35 GMT
Subject: RFR: 8271323: [TESTBUG] serviceability/sa/ClhsdbCDSCore.java
 fails with -XX:TieredStopAtLevel=1
In-Reply-To: <xBnQNgFvVEgGfevy49IsSNUjAGXsdiwMmhTncgW82w8=.478f07e7-97ac-4d4c-a6e4-5c31286920c0@github.com>
References: <xBnQNgFvVEgGfevy49IsSNUjAGXsdiwMmhTncgW82w8=.478f07e7-97ac-4d4c-a6e4-5c31286920c0@github.com>
Message-ID: <FeMceL9qGHQ-dEJ-ToAWVqsOoJ-J9Oc06TQpS5RCAes=.8ee308ea-792c-4f07-9dc3-531b329292de@github.com>

On Tue, 27 Jul 2021 09:24:38 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> This test fails reliably with `-XX:TieredStopAtLevel=1` since JDK-8251462. MDOs are no longer allocated in this mode so the clhsdb `printmdo -a` command prints nothing.  The failure is basically the same as JDK-8236042 which happened with `-Xcomp -XX:TieredStopAtLevel=1` so the workaround for that just needs to be adjusted slightly.

Marked as reviewed by cjplummer (Reviewer).

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

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

From kvn at openjdk.java.net  Tue Jul 27 20:59:42 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Jul 2021 20:59:42 GMT
Subject: RFR: 8271323: [TESTBUG] serviceability/sa/ClhsdbCDSCore.java
 fails with -XX:TieredStopAtLevel=1
In-Reply-To: <xBnQNgFvVEgGfevy49IsSNUjAGXsdiwMmhTncgW82w8=.478f07e7-97ac-4d4c-a6e4-5c31286920c0@github.com>
References: <xBnQNgFvVEgGfevy49IsSNUjAGXsdiwMmhTncgW82w8=.478f07e7-97ac-4d4c-a6e4-5c31286920c0@github.com>
Message-ID: <bncfp1EQWYTC8zxqne-eWAkFTecNABzWijYHY9mnfes=.4f9888d6-3cbe-485d-bedf-40221dbd5a3d@github.com>

On Tue, 27 Jul 2021 09:24:38 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> This test fails reliably with `-XX:TieredStopAtLevel=1` since JDK-8251462. MDOs are no longer allocated in this mode so the clhsdb `printmdo -a` command prints nothing.  The failure is basically the same as JDK-8236042 which happened with `-Xcomp -XX:TieredStopAtLevel=1` so the workaround for that just needs to be adjusted slightly.

Good and trivial.

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

Marked as reviewed by kvn (Reviewer).

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

From jakob at jcornell.net  Tue Jul 27 23:38:04 2021
From: jakob at jcornell.net (Jakob Cornell)
Date: Tue, 27 Jul 2021 18:38:04 -0500
Subject: Information about possible JDB enhancements
In-Reply-To: <f30c39f0-3454-d98d-6472-d9e8b2bd678e@oracle.com>
References: <e3956f34-67dc-90ef-e67d-eed27f6a7ece@gmail.com>
 <230063e5-25b8-b14e-c61d-ed74b85d6e06@jcornell.net>
 <0ed99a75-bd7a-4d5d-e535-2b67dfc8ea4b@oracle.com>
 <f30c39f0-3454-d98d-6472-d9e8b2bd678e@oracle.com>
Message-ID: <c895fb9e-2cb3-1be4-2c21-31f717cc583d@jcornell.net>

Hi all,

I've prepared a patch that makes JDB rerun the previous command when nothing is entered at the prompt.  Looks like the next step is to open a JBS issue so I can submit a PR, but as a new contributor I don't have credentials to open a JBS issue.  Is anybody willing to sponsor my change?  More details can be found in the previous messages on this thread.

Best,
Jakob

From jakob at jcornell.net  Tue Jul 27 23:45:58 2021
From: jakob at jcornell.net (Jakob Cornell)
Date: Tue, 27 Jul 2021 18:45:58 -0500
Subject: Information about possible JDB enhancements
In-Reply-To: <c895fb9e-2cb3-1be4-2c21-31f717cc583d@jcornell.net>
References: <e3956f34-67dc-90ef-e67d-eed27f6a7ece@gmail.com>
 <230063e5-25b8-b14e-c61d-ed74b85d6e06@jcornell.net>
 <0ed99a75-bd7a-4d5d-e535-2b67dfc8ea4b@oracle.com>
 <f30c39f0-3454-d98d-6472-d9e8b2bd678e@oracle.com>
 <c895fb9e-2cb3-1be4-2c21-31f717cc583d@jcornell.net>
Message-ID: <45b0e9b0-7033-fec9-1889-9586bf5366bb@jcornell.net>

Oops, the mailman didn't link this to the previous thread: https://mail.openjdk.java.net/pipermail/serviceability-dev/2021-June/038226.html

From chris.plummer at oracle.com  Wed Jul 28 00:28:34 2021
From: chris.plummer at oracle.com (Chris Plummer)
Date: Tue, 27 Jul 2021 17:28:34 -0700
Subject: Information about possible JDB enhancements
In-Reply-To: <c895fb9e-2cb3-1be4-2c21-31f717cc583d@jcornell.net>
References: <e3956f34-67dc-90ef-e67d-eed27f6a7ece@gmail.com>
 <230063e5-25b8-b14e-c61d-ed74b85d6e06@jcornell.net>
 <0ed99a75-bd7a-4d5d-e535-2b67dfc8ea4b@oracle.com>
 <f30c39f0-3454-d98d-6472-d9e8b2bd678e@oracle.com>
 <c895fb9e-2cb3-1be4-2c21-31f717cc583d@jcornell.net>
Message-ID: <898e2b9b-a077-aaf3-370c-5801e624ec5c@oracle.com>

On 7/27/21 4:38 PM, Jakob Cornell wrote:
> Hi all,
>
> I've prepared a patch that makes JDB rerun the previous command when 
> nothing is entered at the prompt.? Looks like the next step is to open 
> a JBS issue so I can submit a PR, but as a new contributor I don't 
> have credentials to open a JBS issue.? Is anybody willing to sponsor 
> my change?? More details can be found in the previous messages on this 
> thread.
>
> Best,
> Jakob

I've created https://bugs.openjdk.java.net/browse/JDK-8271356. This 
probably also requires a CSR since it changes user interface behavior. 
I'll get that filed too.

Chris


From jakob at jcornell.net  Wed Jul 28 01:14:14 2021
From: jakob at jcornell.net (Jakob Cornell)
Date: Tue, 27 Jul 2021 20:14:14 -0500
Subject: Information about possible JDB enhancements
In-Reply-To: <898e2b9b-a077-aaf3-370c-5801e624ec5c@oracle.com>
References: <e3956f34-67dc-90ef-e67d-eed27f6a7ece@gmail.com>
 <230063e5-25b8-b14e-c61d-ed74b85d6e06@jcornell.net>
 <0ed99a75-bd7a-4d5d-e535-2b67dfc8ea4b@oracle.com>
 <f30c39f0-3454-d98d-6472-d9e8b2bd678e@oracle.com>
 <c895fb9e-2cb3-1be4-2c21-31f717cc583d@jcornell.net>
 <898e2b9b-a077-aaf3-370c-5801e624ec5c@oracle.com>
Message-ID: <7a1ed421-8c5e-925f-8250-dd19ade2e349@jcornell.net>

Thanks for the help Chris.  With the JBS ticket set up are we ready for a PR to be opened, or should I wait for the CSR review?

Jakob

From ngasson at openjdk.java.net  Wed Jul 28 01:59:33 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 28 Jul 2021 01:59:33 GMT
Subject: Integrated: 8261236: C2: ClhsdbJstackXcompStress test fails when
 StressGCM is enabled
In-Reply-To: <3dsIKe2U3zN7oTZlGUFM4PQ0fglWb6bsCUIfCTISM6g=.c5de4eff-f6bb-43ea-96fc-9a155d5d4839@github.com>
References: <3dsIKe2U3zN7oTZlGUFM4PQ0fglWb6bsCUIfCTISM6g=.c5de4eff-f6bb-43ea-96fc-9a155d5d4839@github.com>
Message-ID: <WHpMEoQRWi8XCpbxFEyUGMwyA6rzLsvysU0w6KeRA7o=.ab462264-a690-4ffa-b25b-521d0cc1d069@github.com>

On Fri, 16 Jul 2021 10:24:56 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The clhsdb jstack command crashes when the debugged program is run with `-Xcomp -XX:+StressGCM -XX:StressSeed=2` on AArch64:
> 
> 
>   sun.jvm.hotspot.utilities.AssertionFailure: sanity check
>   at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>   at jdk.hotspot.agent/sun.jvm.hotspot.runtime.RegisterMap.setLocation(RegisterMap.java:160)
>   at jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet.updateRegisterMap(ImmutableOopMapSet.java:303)
>   at jdk.hotspot.agent/sun.jvm.hotspot.runtime.aarch64.AARCH64Frame.senderForCompiledFrame(AARCH64Frame.java:407)
> 
> 
> The assertion failure here is:
> 
> 
>   Assert.that(0 <= i && i < regCount, "sanity check");
> 
> 
> I.e. there's an invalid register in the oop map.
> 
> The problem seems to be caused by the changes in JDK-8231586 which changed `OopMapValue::oop_types` from a bit mask to normal integer enum. However the changes in the C++ code weren't mirrored in SA's OopMapStream which still treats OopTypes as a bit mask.
> 
> The particular oop map this is crashing on looks like this:
> 
> 
>   ImmutableOopMap {[24]=Oop [32]=Oop [40]=Derived_oop_[24] } pc offsets: 324
> 
> 
> The code is looking for callee saved values (type=2) by AND-ing with each oop value type in the set, so it wrongly interprets the derived oop [40] (type=3) as a callee saved register.
> 
> This patch just mirrors the changes to the C++ code into the corresponding SA classes.  The C++ OopMapStream constructor no longer takes a type filter argument and callers are expected filter themselves, so I've made the same change to the Java code.
> 
> This bug can also be seen using the clhsdb "disassemble" command.  For example the above oop map is currently printed incorrectly as:
> 
> 
>   OopMap:
>   NarrowOops:[40]
>   Callee saved:[40] = [24]
>   Derived oops:[40] = [24]
> 
> 
> With this patch it becomes:
> 
> 
>   OopMap:
>   Oops:[24]  [32]
>   Derived oops:[40] = [24]
> 
> 
> This bug was reported on AArch64 but it seems to be just luck that we don't see it on other platforms.
> 
> Tested tier1 and hotspot_serviceability on AArch64 and x86.

This pull request has now been integrated.

Changeset: 752b6df3
Author:    Nick Gasson <ngasson at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/752b6df34c92c02ac0992566e3efa7bc22b96aa1
Stats:     58 lines in 3 files changed: 12 ins; 28 del; 18 mod

8261236: C2: ClhsdbJstackXcompStress test fails when StressGCM is enabled

Reviewed-by: never, kvn

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

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

From ngasson at openjdk.java.net  Wed Jul 28 02:01:32 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 28 Jul 2021 02:01:32 GMT
Subject: Integrated: 8271323: [TESTBUG] serviceability/sa/ClhsdbCDSCore.java
 fails with -XX:TieredStopAtLevel=1
In-Reply-To: <xBnQNgFvVEgGfevy49IsSNUjAGXsdiwMmhTncgW82w8=.478f07e7-97ac-4d4c-a6e4-5c31286920c0@github.com>
References: <xBnQNgFvVEgGfevy49IsSNUjAGXsdiwMmhTncgW82w8=.478f07e7-97ac-4d4c-a6e4-5c31286920c0@github.com>
Message-ID: <_hyta6rRRR9FojBfeyF7lgNrtTHwmYvbO3inkSaScTc=.e281bd78-44f6-4d3c-8bc6-54cb76169f42@github.com>

On Tue, 27 Jul 2021 09:24:38 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> This test fails reliably with `-XX:TieredStopAtLevel=1` since JDK-8251462. MDOs are no longer allocated in this mode so the clhsdb `printmdo -a` command prints nothing.  The failure is basically the same as JDK-8236042 which happened with `-Xcomp -XX:TieredStopAtLevel=1` so the workaround for that just needs to be adjusted slightly.

This pull request has now been integrated.

Changeset: 9bc52afa
Author:    Nick Gasson <ngasson at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9bc52afa481c476ae9c379dff44ae8266777f616
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8271323: [TESTBUG] serviceability/sa/ClhsdbCDSCore.java fails with -XX:TieredStopAtLevel=1

Reviewed-by: cjplummer, kvn

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

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

From jiefu at openjdk.java.net  Wed Jul 28 02:37:28 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 28 Jul 2021 02:37:28 GMT
Subject: RFR: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers [v8]
In-Reply-To: <j2nvg27bB4wt11pUAQW175-do1q44HFycxM-TzX1tNg=.bb7aca28-a9de-4a5b-bf03-c4ac8bf73207@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
 <j2nvg27bB4wt11pUAQW175-do1q44HFycxM-TzX1tNg=.bb7aca28-a9de-4a5b-bf03-c4ac8bf73207@github.com>
Message-ID: <GqwAo2dUgEiourxc0RDWijk7ubrqoJzQpziZwR9lviU=.b3c03020-0528-494e-97f7-a474c020c30f@github.com>

On Wed, 14 Jul 2021 04:00:39 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

>> ?ocess cpu usage in containers
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add  comments

Will sponsor it tomorrow if there is no objection.
Thanks.

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

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

From yyang at openjdk.java.net  Wed Jul 28 07:30:46 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 28 Jul 2021 07:30:46 GMT
Subject: RFR: 8270901: Typo PHASE_CPP in CompilerPhaseType
Message-ID: <WkDPthW3yrw5a1NjVeIiE9eE1NW0StAn9vWVRIFRyCM=.9e2c7b63-df50-456f-9e26-fe376a2b1bbb@github.com>

Should be PHASE_CCP instead of PHASE_CPP, it also affects dumped ideal graph XML.

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

Commit messages:
 - typo

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

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

From jiefu at openjdk.java.net  Wed Jul 28 07:42:29 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 28 Jul 2021 07:42:29 GMT
Subject: RFR: 8270901: Typo PHASE_CPP in CompilerPhaseType
In-Reply-To: <WkDPthW3yrw5a1NjVeIiE9eE1NW0StAn9vWVRIFRyCM=.9e2c7b63-df50-456f-9e26-fe376a2b1bbb@github.com>
References: <WkDPthW3yrw5a1NjVeIiE9eE1NW0StAn9vWVRIFRyCM=.9e2c7b63-df50-456f-9e26-fe376a2b1bbb@github.com>
Message-ID: <Ogq1gzMpWn0lSohW07mkpD_vMttnR9E3Gt9B-hNX1Bs=.c56c8e1e-8540-4665-b144-11862b57e07c@github.com>

On Wed, 28 Jul 2021 07:19:08 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Should be PHASE_CCP instead of PHASE_CPP, it also affects dumped ideal graph XML.

Looks good to me.

The copyright year should also be updated.
Thanks.

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

Marked as reviewed by jiefu (Reviewer).

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

From yyang at openjdk.java.net  Wed Jul 28 08:06:56 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 28 Jul 2021 08:06:56 GMT
Subject: RFR: 8270901: Typo PHASE_CPP in CompilerPhaseType [v2]
In-Reply-To: <WkDPthW3yrw5a1NjVeIiE9eE1NW0StAn9vWVRIFRyCM=.9e2c7b63-df50-456f-9e26-fe376a2b1bbb@github.com>
References: <WkDPthW3yrw5a1NjVeIiE9eE1NW0StAn9vWVRIFRyCM=.9e2c7b63-df50-456f-9e26-fe376a2b1bbb@github.com>
Message-ID: <xhD-YussFk21cO8yhphpLaVPrknGUILPKTQ8FIrIBkM=.2c76061b-80da-4e61-b9d1-3098677cb5dc@github.com>

> Should be PHASE_CCP instead of PHASE_CPP, it also affects dumped ideal graph XML.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4917/files
  - new: https://git.openjdk.java.net/jdk/pull/4917/files/f556d064..8599d930

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

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

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

From yyang at openjdk.java.net  Wed Jul 28 08:06:57 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 28 Jul 2021 08:06:57 GMT
Subject: RFR: 8270901: Typo PHASE_CPP in CompilerPhaseType
In-Reply-To: <WkDPthW3yrw5a1NjVeIiE9eE1NW0StAn9vWVRIFRyCM=.9e2c7b63-df50-456f-9e26-fe376a2b1bbb@github.com>
References: <WkDPthW3yrw5a1NjVeIiE9eE1NW0StAn9vWVRIFRyCM=.9e2c7b63-df50-456f-9e26-fe376a2b1bbb@github.com>
Message-ID: <IYdRSYmWrDgUXv-2aUxgXyhJ-V39JlqWii7du1820XE=.42ac0806-3302-40c7-a579-29d66d144d4a@github.com>

On Wed, 28 Jul 2021 07:19:08 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Should be PHASE_CCP instead of PHASE_CPP, it also affects dumped ideal graph XML.

Thank you Jie for review!

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

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

From yyang at openjdk.java.net  Wed Jul 28 08:06:57 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 28 Jul 2021 08:06:57 GMT
Subject: Integrated: 8270901: Typo PHASE_CPP in CompilerPhaseType
In-Reply-To: <WkDPthW3yrw5a1NjVeIiE9eE1NW0StAn9vWVRIFRyCM=.9e2c7b63-df50-456f-9e26-fe376a2b1bbb@github.com>
References: <WkDPthW3yrw5a1NjVeIiE9eE1NW0StAn9vWVRIFRyCM=.9e2c7b63-df50-456f-9e26-fe376a2b1bbb@github.com>
Message-ID: <M1eaT0CbMcThJa61P1HhM-gChP2FINVH-qKRmoNrBRg=.e24231d3-2a76-4148-93e2-62d95957853e@github.com>

On Wed, 28 Jul 2021 07:19:08 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Should be PHASE_CCP instead of PHASE_CPP, it also affects dumped ideal graph XML.

This pull request has now been integrated.

Changeset: 072fe486
Author:    Yi Yang <yyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/072fe486c952184811f5bff3504ca72deb66e445
Stats:     6 lines in 3 files changed: 0 ins; 0 del; 6 mod

8270901: Typo PHASE_CPP in CompilerPhaseType

Reviewed-by: jiefu

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

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

From jiefu at openjdk.java.net  Wed Jul 28 08:27:36 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 28 Jul 2021 08:27:36 GMT
Subject: RFR: 8270901: Typo PHASE_CPP in CompilerPhaseType [v2]
In-Reply-To: <xhD-YussFk21cO8yhphpLaVPrknGUILPKTQ8FIrIBkM=.2c76061b-80da-4e61-b9d1-3098677cb5dc@github.com>
References: <WkDPthW3yrw5a1NjVeIiE9eE1NW0StAn9vWVRIFRyCM=.9e2c7b63-df50-456f-9e26-fe376a2b1bbb@github.com>
 <xhD-YussFk21cO8yhphpLaVPrknGUILPKTQ8FIrIBkM=.2c76061b-80da-4e61-b9d1-3098677cb5dc@github.com>
Message-ID: <V8KTJdT-uRi9CN2MQgvWqb0fr-BdiW7sjHcPvg7I8uY=.b17aa02f-6a82-4db3-b7e2-d36d5c1b950f@github.com>

On Wed, 28 Jul 2021 08:06:56 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Should be PHASE_CCP instead of PHASE_CPP, it also affects dumped ideal graph XML.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

For hotspot changes, it would be better to have a second review & wait for 24 hours before integration. 
Thanks.

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

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

From yyang at openjdk.java.net  Wed Jul 28 08:42:32 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 28 Jul 2021 08:42:32 GMT
Subject: RFR: 8270901: Typo PHASE_CPP in CompilerPhaseType [v2]
In-Reply-To: <V8KTJdT-uRi9CN2MQgvWqb0fr-BdiW7sjHcPvg7I8uY=.b17aa02f-6a82-4db3-b7e2-d36d5c1b950f@github.com>
References: <WkDPthW3yrw5a1NjVeIiE9eE1NW0StAn9vWVRIFRyCM=.9e2c7b63-df50-456f-9e26-fe376a2b1bbb@github.com>
 <xhD-YussFk21cO8yhphpLaVPrknGUILPKTQ8FIrIBkM=.2c76061b-80da-4e61-b9d1-3098677cb5dc@github.com>
 <V8KTJdT-uRi9CN2MQgvWqb0fr-BdiW7sjHcPvg7I8uY=.b17aa02f-6a82-4db3-b7e2-d36d5c1b950f@github.com>
Message-ID: <WnIpH4X3aJftnwqh7yc5rtM9FaQzhBVTEjfSsnOUUgQ=.4f793e5c-e312-48b8-ab82-4913ebeb0417@github.com>

On Wed, 28 Jul 2021 08:24:41 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> For hotspot changes, it would be better to have a second review & wait for 24 hours before integration.
> Thanks.

Well, it seems a trivial change, maybe one review is okay. For non-trivial changes, we really need more reviews and wait for 24h before merging.

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

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

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: <UzuojghwZRtOLyDt-hVFIOVPJaRA_mlN2w7M6T7r5pY=.341e649c-2cad-4059-b63f-2a89699fa97d@github.com>

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 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: <UzuojghwZRtOLyDt-hVFIOVPJaRA_mlN2w7M6T7r5pY=.341e649c-2cad-4059-b63f-2a89699fa97d@github.com>
References: <UzuojghwZRtOLyDt-hVFIOVPJaRA_mlN2w7M6T7r5pY=.341e649c-2cad-4059-b63f-2a89699fa97d@github.com>
Message-ID: <nkocBZAi9bZ62cQSv36QdSwFxPV19mFtNXysBemp670=.76d80a5e-9680-4766-94ec-39eee68fadc4@github.com>

On Wed, 28 Jul 2021 10:03:10 GMT, David Holmes <dholmes at openjdk.org> 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: <UzuojghwZRtOLyDt-hVFIOVPJaRA_mlN2w7M6T7r5pY=.341e649c-2cad-4059-b63f-2a89699fa97d@github.com>
References: <UzuojghwZRtOLyDt-hVFIOVPJaRA_mlN2w7M6T7r5pY=.341e649c-2cad-4059-b63f-2a89699fa97d@github.com>
Message-ID: <2q5ydXJwaul0jEF2X2c0mDL6dSPmksfoJ2l1a7T7_JM=.01c14a0f-e336-41db-a287-6807f85c1801@github.com>

On Wed, 28 Jul 2021 10:03:10 GMT, David Holmes <dholmes at openjdk.org> 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 github.com+54304+ebourg at openjdk.java.net  Wed Jul 28 15:39:47 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Wed, 28 Jul 2021 15:39:47 GMT
Subject: RFR: 8271396: Spelling errors
Message-ID: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>

This PR fixes the following spelling errors:

 choosen  -> chosen
 commad   -> command
 hiearchy -> hierarchy
 leagacy  -> legacy
 minium   -> minimum
 subsytem -> subsystem
 unamed   -> unnamed

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

Commit messages:
 - 8271396: Fix spelling errors

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

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

From tschatzl at openjdk.java.net  Wed Jul 28 15:39:47 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 28 Jul 2021 15:39:47 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <qaXW0F5RvHQkbBOCClYDaM8g9-AwsGvhfPZT1ALfL8I=.eefdf486-3f44-42bf-a004-c379b6b3c666@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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

From chegar at openjdk.java.net  Wed Jul 28 15:39:48 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Jul 2021 15:39:48 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <XjTat5FN7Pxw0RoEY4EmHVk_ItIxt5MZllXtrHVCQvc=.e4dcfdb0-4c77-4723-a216-4e4eb87d5340@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Trivially, looks ok to me.

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

Marked as reviewed by chegar (Reviewer).

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

From yyang at openjdk.java.net  Wed Jul 28 15:39:48 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 28 Jul 2021 15:39:48 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <QVfb9Ia0KIhLqsqLTdMA1CU7UWY_o9DK_5BZaQt5oxs=.2f3b25f4-3f0d-42ca-b56a-109c2a1c2349@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Hi, I've filed https://bugs.openjdk.java.net/browse/JDK-8271396 for this PR, you can change the title to "8271396: Spelling errors", openjdk bot will link this PR to the corresponding issue. Also you should resolve conflicts and pass jcheck before integrating it.

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

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

From github.com+54304+ebourg at openjdk.java.net  Wed Jul 28 15:39:48 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Wed, 28 Jul 2021 15:39:48 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <10SItkPG_iJXTz8Ya0h8wBgoiXRl-aki9ADR8U_jaj8=.f3b7b05e-2b91-4522-9f7f-4b2ea97c8a50@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

.

.

Thank you!

The PR has been updated

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

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

From dcubed at openjdk.java.net  Wed Jul 28 15:48:36 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 28 Jul 2021 15:48:36 GMT
Subject: RFR: 8270901: Typo PHASE_CPP in CompilerPhaseType [v2]
In-Reply-To: <WnIpH4X3aJftnwqh7yc5rtM9FaQzhBVTEjfSsnOUUgQ=.4f793e5c-e312-48b8-ab82-4913ebeb0417@github.com>
References: <WkDPthW3yrw5a1NjVeIiE9eE1NW0StAn9vWVRIFRyCM=.9e2c7b63-df50-456f-9e26-fe376a2b1bbb@github.com>
 <xhD-YussFk21cO8yhphpLaVPrknGUILPKTQ8FIrIBkM=.2c76061b-80da-4e61-b9d1-3098677cb5dc@github.com>
 <V8KTJdT-uRi9CN2MQgvWqb0fr-BdiW7sjHcPvg7I8uY=.b17aa02f-6a82-4db3-b7e2-d36d5c1b950f@github.com>
 <WnIpH4X3aJftnwqh7yc5rtM9FaQzhBVTEjfSsnOUUgQ=.4f793e5c-e312-48b8-ab82-4913ebeb0417@github.com>
Message-ID: <GSIvDJKYWkL2YVkmoIBCvsn2N6Jwt8xYDmopLvCIkoU=.8acf77d3-51c7-4136-830f-6d161afffd70@github.com>

On Wed, 28 Jul 2021 08:38:04 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> For hotspot changes, it would be better to have a second review & wait for 24 hours before integration. 
>> Thanks.
>
>> For hotspot changes, it would be better to have a second review & wait for 24 hours before integration.
>> Thanks.
> 
> Well, it seems a trivial change, maybe one review is okay. For non-trivial changes, we really need more reviews and wait for 24h before merging.

@kelthuzadx - HotSpot changes require two reviews and a 24 hour waiting period.
You may propose in your review request that a change is "trivial" and if your
(R)eviewer agrees, then you may integrate with a single (R)eviewer and you don't
have to wait for 24 hours.

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

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

From psadhukhan at openjdk.java.net  Wed Jul 28 16:17:31 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 28 Jul 2021 16:17:31 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <Bq3Nm1ILzw1TRD2bA2FpFLsnzuNxAffRspEOokAcBrs=.3c5c2746-d279-4db6-9c7a-47c551e8a1c1@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Thanks for awt/swing correction.

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

Marked as reviewed by psadhukhan (Reviewer).

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

From iris at openjdk.java.net  Wed Jul 28 16:17:31 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 28 Jul 2021 16:17:31 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <IzhHnS2Nir_azY-2MIv9m9UHxi2pQHE1mNxQw2f9nW4=.6a615f55-a7b1-4a81-9c91-57bd6e3fa7fa@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Marked as reviewed by iris (Reviewer).

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

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

From cjplummer at openjdk.java.net  Wed Jul 28 16:25:32 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 28 Jul 2021 16:25:32 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <mF8f_Z4TdIttsMV7_J2yms_a3_eM2qHCbjnHs3XYpwI=.caae749d-6dfa-4be0-b459-2e69cd4d1662@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

jdi, jvmti, and dcmd related changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

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

From jboes at openjdk.java.net  Wed Jul 28 16:29:29 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Wed, 28 Jul 2021 16:29:29 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

I'm happy to sponsor this change, but could you please update the copyright year where necessary, e.g. in 
src/java.desktop/unix/classes/sun/awt/X11/XMSelection.java: 
`Copyright (c) 2003, 2018, Oracle...` -> `Copyright (c) 2003, 2021, Oracle...`

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

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

From github.com+54304+ebourg at openjdk.java.net  Wed Jul 28 17:12:04 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Wed, 28 Jul 2021 17:12:04 GMT
Subject: RFR: 8271396: Spelling errors [v2]
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <axOY0lG3CInpykz-_Ur_wY8dRvr4QsfktJ9gD0vvirA=.c8302d67-79c3-4e99-853c-65701d049c4a@github.com>

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Emmanuel Bourg 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 one additional commit since the last revision:

  8271396: Fix spelling errors
  
   choosen  -> chosen
   commad   -> command
   hiearchy -> hierarchy
   leagacy  -> legacy
   minium   -> minimum
   subsytem -> subsystem
   unamed   -> unnamed

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2385/files
  - new: https://git.openjdk.java.net/jdk/pull/2385/files/31cfcba7..6e1be4f6

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

  Stats: 61642 lines in 1361 files changed: 29147 ins; 26026 del; 6469 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2385.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2385/head:pull/2385

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

From github.com+54304+ebourg at openjdk.java.net  Wed Jul 28 17:12:05 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Wed, 28 Jul 2021 17:12:05 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>
Message-ID: <ECY56wmiBbQOh06b4r_yI7IykEom57iFFgIQNnhQMGY=.a16517dc-67bc-43a6-b0ef-d1eab0d6970a@github.com>

On Wed, 28 Jul 2021 16:26:49 GMT, Julia Boes <jboes at openjdk.org> wrote:

>> This PR fixes the following spelling errors:
>> 
>>  choosen  -> chosen
>>  commad   -> command
>>  hiearchy -> hierarchy
>>  leagacy  -> legacy
>>  minium   -> minimum
>>  subsytem -> subsystem
>>  unamed   -> unnamed
>
> I'm happy to sponsor this change, but could you please update the copyright year where necessary, e.g. in 
> src/java.desktop/unix/classes/sun/awt/X11/XMSelection.java: 
> `Copyright (c) 2003, 2018, Oracle...` -> `Copyright (c) 2003, 2021, Oracle...`

@FrauBoes thank you, the PR has been updated to modify the copyright year

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

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

From kcr at openjdk.java.net  Wed Jul 28 17:26:35 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 28 Jul 2021 17:26:35 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <ECY56wmiBbQOh06b4r_yI7IykEom57iFFgIQNnhQMGY=.a16517dc-67bc-43a6-b0ef-d1eab0d6970a@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>
 <ECY56wmiBbQOh06b4r_yI7IykEom57iFFgIQNnhQMGY=.a16517dc-67bc-43a6-b0ef-d1eab0d6970a@github.com>
Message-ID: <c8D3av6T1vVqUc0YgytVzPMZoVwmk3pAQwgCU9OaTGY=.88b57352-b1a0-4563-b651-6f624560dbe7@github.com>

On Wed, 28 Jul 2021 17:08:01 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

>> I'm happy to sponsor this change, but could you please update the copyright year where necessary, e.g. in 
>> src/java.desktop/unix/classes/sun/awt/X11/XMSelection.java: 
>> `Copyright (c) 2003, 2018, Oracle...` -> `Copyright (c) 2003, 2021, Oracle...`
>
> @FrauBoes thank you, the PR has been updated to modify the copyright year

@ebourg for future PRs please do not force push after the PR is out for review. Just push incremental commits normally. The Skara tooling will squash them all into a single commit.

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

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

From iris at openjdk.java.net  Wed Jul 28 17:26:34 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 28 Jul 2021 17:26:34 GMT
Subject: RFR: 8271396: Spelling errors [v2]
In-Reply-To: <axOY0lG3CInpykz-_Ur_wY8dRvr4QsfktJ9gD0vvirA=.c8302d67-79c3-4e99-853c-65701d049c4a@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <axOY0lG3CInpykz-_Ur_wY8dRvr4QsfktJ9gD0vvirA=.c8302d67-79c3-4e99-853c-65701d049c4a@github.com>
Message-ID: <creDetfFbVTSBqmvtf65RTiUEBDK2hFEh5ESw38QR-4=.3c2ecc4a-82a8-4aa7-ae79-efe2363e68d6@github.com>

On Wed, 28 Jul 2021 17:12:04 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

>> This PR fixes the following spelling errors:
>> 
>>  choosen  -> chosen
>>  commad   -> command
>>  hiearchy -> hierarchy
>>  leagacy  -> legacy
>>  minium   -> minimum
>>  subsytem -> subsystem
>>  unamed   -> unnamed
>
> Emmanuel Bourg 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 one additional commit since the last revision:
> 
>   8271396: Fix spelling errors
>   
>    choosen  -> chosen
>    commad   -> command
>    hiearchy -> hierarchy
>    leagacy  -> legacy
>    minium   -> minimum
>    subsytem -> subsystem
>    unamed   -> unnamed

Marked as reviewed by iris (Reviewer).

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

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

From github.com+54304+ebourg at openjdk.java.net  Wed Jul 28 17:26:35 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Wed, 28 Jul 2021 17:26:35 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <c8D3av6T1vVqUc0YgytVzPMZoVwmk3pAQwgCU9OaTGY=.88b57352-b1a0-4563-b651-6f624560dbe7@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>
 <ECY56wmiBbQOh06b4r_yI7IykEom57iFFgIQNnhQMGY=.a16517dc-67bc-43a6-b0ef-d1eab0d6970a@github.com>
 <c8D3av6T1vVqUc0YgytVzPMZoVwmk3pAQwgCU9OaTGY=.88b57352-b1a0-4563-b651-6f624560dbe7@github.com>
Message-ID: <al0SRVpmZ3Jta5hZkVrGWCBNM9X330njP-87Gtj2Xrk=.d7a1bea3-1b54-4084-be08-831b4eff898b@github.com>

On Wed, 28 Jul 2021 17:20:37 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @FrauBoes thank you, the PR has been updated to modify the copyright year
>
> @ebourg for future PRs please do not force push after the PR is out for review. Just push incremental commits normally. The Skara tooling will squash them all into a single commit.

@kevinrushforth I'll do that, thank you for the hint

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

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

From chris.plummer at oracle.com  Wed Jul 28 17:53:26 2021
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 28 Jul 2021 10:53:26 -0700
Subject: [External] : Re: Information about possible JDB enhancements
In-Reply-To: <7a1ed421-8c5e-925f-8250-dd19ade2e349@jcornell.net>
References: <e3956f34-67dc-90ef-e67d-eed27f6a7ece@gmail.com>
 <230063e5-25b8-b14e-c61d-ed74b85d6e06@jcornell.net>
 <0ed99a75-bd7a-4d5d-e535-2b67dfc8ea4b@oracle.com>
 <f30c39f0-3454-d98d-6472-d9e8b2bd678e@oracle.com>
 <c895fb9e-2cb3-1be4-2c21-31f717cc583d@jcornell.net>
 <898e2b9b-a077-aaf3-370c-5801e624ec5c@oracle.com>
 <7a1ed421-8c5e-925f-8250-dd19ade2e349@jcornell.net>
Message-ID: <6af77cfd-48e1-13fd-5b77-95826281894d@oracle.com>

On 7/27/21 6:14 PM, Jakob Cornell wrote:
> Thanks for the help Chris.? With the JBS ticket set up are we ready 
> for a PR to be opened, or should I wait for the CSR review?
>
> Jakob

It looks like some more discussion is needed before creating the CSR. 
You can still create a PR if you want to show the work you've done. Just 
leave it in draft mode and send a link to it to serviceabilty-dev.

Chris


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: <nkocBZAi9bZ62cQSv36QdSwFxPV19mFtNXysBemp670=.76d80a5e-9680-4766-94ec-39eee68fadc4@github.com>
References: <UzuojghwZRtOLyDt-hVFIOVPJaRA_mlN2w7M6T7r5pY=.341e649c-2cad-4059-b63f-2a89699fa97d@github.com>
 <nkocBZAi9bZ62cQSv36QdSwFxPV19mFtNXysBemp670=.76d80a5e-9680-4766-94ec-39eee68fadc4@github.com>
Message-ID: <3zSeaaAp2WYCrlDGi5j0y44z892n1y2KpyhIiwKu8OI=.d8f7e9ad-07da-48ce-b3ea-1e8912e9e9b8@github.com>

On Wed, 28 Jul 2021 14:22:07 GMT, Thomas Stuefe <stuefe at openjdk.org> 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 github.com+7837910+xpbob at openjdk.java.net  Wed Jul 28 23:15:36 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Wed, 28 Jul 2021 23:15:36 GMT
Subject: Integrated: 8269851: OperatingSystemMXBean getProcessCpuLoad reports
 incorrect process cpu usage in containers
In-Reply-To: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
References: <bqUWqPS6MPqDmoJtnHIsj6xxyaBNsI2nIUm-P4P0zw4=.87576f0b-e351-4c30-bf1b-1087ebcf38b9@github.com>
Message-ID: <nLniSXp3GJB9VXwszDAC6JCXDQBMr71An9RyxNFMBpE=.fa8bb8c3-6c22-4f43-bc64-ecf407b43a0c@github.com>

On Wed, 7 Jul 2021 04:03:27 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

> ?ocess cpu usage in containers

This pull request has now been integrated.

Changeset: 25f00d78
Author:    bobpengxie <bobpengxie at tencent.com>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/25f00d787cf56f6cdca6949115d04e7d8e675554
Stats:     218 lines in 1 file changed: 137 ins; 78 del; 3 mod

8269851: OperatingSystemMXBean getProcessCpuLoad reports incorrect process cpu usage in containers

Co-authored-by: Severin Gehwolf <sgehwolf at openjdk.org>
Reviewed-by: sgehwolf

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

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

From iignatyev at openjdk.java.net  Thu Jul 29 00:53:12 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Jul 2021 00:53:12 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package
Message-ID: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>

Hi all,

could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?

the majority of the patch is the following substitutions:
 - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
 - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
 - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
 - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
 - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
 - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`

testing: tier1-4

Thanks,
-- Igor

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

Commit messages:
 - copyright year
 - update TEST.ROOT
 - jdk: s/sun\.hotspot\.gc/jdk.test.whitebox.gc/g
 - jdk: s/sun\.hotspot\.code/jdk.test.whitebox.code/g
 - jdk: s/sun\.hotspot\.WhiteBox/jdk.test.whitebox.WhiteBox/g
 - hotspot: 's~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g'
 - hotspot: s/sun\.hotspot\.parser/jdk.test.whitebox.parser/g
 - hotspot: s/sun\.hotspot\.cpuinfo/jdk.test.whitebox.cpuinfo/g
 - hotspot: s/sun\.hotspot\.code/jdk.test.whitebox.code/g
 - hotspot: 's/sun\.hotspot\.gc/jdk.test.whitebox.gc/g'
 - ... and 9 more: https://git.openjdk.java.net/jdk17/compare/c8ae7e5b...8f12f2cf

Changes: https://git.openjdk.java.net/jdk17/pull/290/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=290&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8067223
  Stats: 2310 lines in 949 files changed: 0 ins; 0 del; 2310 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/290.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/290/head:pull/290

PR: https://git.openjdk.java.net/jdk17/pull/290

From kvn at openjdk.java.net  Thu Jul 29 01:33:29 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 29 Jul 2021 01:33:29 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package
In-Reply-To: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
Message-ID: <_3viZFs2iZ00hMdeP3Nq9gTmwfIHeTzZ7NVT8thQ1BM=.10005882-f135-4592-a663-b75747da3f6c@github.com>

On Wed, 28 Jul 2021 17:13:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
> 
> the majority of the patch is the following substitutions:
>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
> 
> testing: tier1-4
> 
> Thanks,
> -- Igor

I know that tests fixes could be pushed during RDP2 without approval.
But these one is very big and it is not a fix - it is enhancement.

What is the reason you want to push it into JDK 17 just few days before first Release Candidate? Instead of pushing it into JDK 18.

And I can't even review it because GutHub UI hangs on these big changes.

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

PR: https://git.openjdk.java.net/jdk17/pull/290

From dholmes at openjdk.java.net  Thu Jul 29 01:59:34 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 29 Jul 2021 01:59:34 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package
In-Reply-To: <_3viZFs2iZ00hMdeP3Nq9gTmwfIHeTzZ7NVT8thQ1BM=.10005882-f135-4592-a663-b75747da3f6c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <_3viZFs2iZ00hMdeP3Nq9gTmwfIHeTzZ7NVT8thQ1BM=.10005882-f135-4592-a663-b75747da3f6c@github.com>
Message-ID: <uS-q6EG6pQtgTQbK3VDUnBF5MovH0hpRlC9CDTlEGDc=.01714903-9472-417a-a901-ea52bea6ed0a@github.com>

On Thu, 29 Jul 2021 01:30:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>> 
>> the majority of the patch is the following substitutions:
>>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>> 
>> testing: tier1-4
>> 
>> Thanks,
>> -- Igor
>
> I know that tests fixes could be pushed during RDP2 without approval.
> But these one is very big and it is not a fix - it is enhancement.
> 
> What is the reason you want to push it into JDK 17 just few days before first Release Candidate? Instead of pushing it into JDK 18.
> 
> And I can't even review it because GutHub UI hangs on these big changes.

I agree with @vnkozlov this too big and disruptive for 17 at this stage of the release.

I also think a better approach to this cleanup would have been to copy the WhiteBox class to the new package structure, then update the tests in chunks, then remove the old WhiteBox classes when that is complete.

Thanks,
David

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

PR: https://git.openjdk.java.net/jdk17/pull/290

From jboes at openjdk.java.net  Thu Jul 29 15:58:29 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Thu, 29 Jul 2021 15:58:29 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <al0SRVpmZ3Jta5hZkVrGWCBNM9X330njP-87Gtj2Xrk=.d7a1bea3-1b54-4084-be08-831b4eff898b@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>
 <ECY56wmiBbQOh06b4r_yI7IykEom57iFFgIQNnhQMGY=.a16517dc-67bc-43a6-b0ef-d1eab0d6970a@github.com>
 <c8D3av6T1vVqUc0YgytVzPMZoVwmk3pAQwgCU9OaTGY=.88b57352-b1a0-4563-b651-6f624560dbe7@github.com>
 <al0SRVpmZ3Jta5hZkVrGWCBNM9X330njP-87Gtj2Xrk=.d7a1bea3-1b54-4084-be08-831b4eff898b@github.com>
Message-ID: <6pKjSeljbRVUY95MMl6XydDzNvJde-Pa1DSN6OfM7mM=.8b5ea3f5-dce4-49d3-8090-023734e19061@github.com>

On Wed, 28 Jul 2021 17:23:51 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

>> @ebourg for future PRs please do not force push after the PR is out for review. Just push incremental commits normally. The Skara tooling will squash them all into a single commit.
>
> @kevinrushforth I'll do that, thank you for the hint

@ebourg Thanks for updating the copyright. If you integrate again, I can sponsor.

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

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

From github.com+54304+ebourg at openjdk.java.net  Thu Jul 29 16:06:37 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Thu, 29 Jul 2021 16:06:37 GMT
Subject: Integrated: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <9uAMUJBjsby1KkwiwU8wrYEw0ozGjXD7Xnjil0nLoXg=.fd3b9a16-c42a-4806-a174-8b6b0b565abb@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

This pull request has now been integrated.

Changeset: d09b0284
Author:    Emmanuel Bourg <ebourg at apache.org>
Committer: Julia Boes <jboes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d09b028407ff9d0e8c2dfd9cc5d0dca19c4497e3
Stats:     103 lines in 34 files changed: 0 ins; 0 del; 103 mod

8271396: Spelling errors

Reviewed-by: tschatzl, chegar, iris, psadhukhan, cjplummer

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

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

From github.com+54304+ebourg at openjdk.java.net  Thu Jul 29 16:11:36 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Thu, 29 Jul 2021 16:11:36 GMT
Subject: RFR: 8271396: Spelling errors [v2]
In-Reply-To: <axOY0lG3CInpykz-_Ur_wY8dRvr4QsfktJ9gD0vvirA=.c8302d67-79c3-4e99-853c-65701d049c4a@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <axOY0lG3CInpykz-_Ur_wY8dRvr4QsfktJ9gD0vvirA=.c8302d67-79c3-4e99-853c-65701d049c4a@github.com>
Message-ID: <1IourDXaaOqLbUP1_8BfEui3NErozrWkUoBcYUmYAx8=.82ca7fd0-732d-41ab-ad90-8e77412b8ac2@github.com>

On Wed, 28 Jul 2021 17:12:04 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

>> This PR fixes the following spelling errors:
>> 
>>  choosen  -> chosen
>>  commad   -> command
>>  hiearchy -> hierarchy
>>  leagacy  -> legacy
>>  minium   -> minimum
>>  subsytem -> subsystem
>>  unamed   -> unnamed
>
> Emmanuel Bourg 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 one additional commit since the last revision:
> 
>   8271396: Fix spelling errors
>   
>    choosen  -> chosen
>    commad   -> command
>    hiearchy -> hierarchy
>    leagacy  -> legacy
>    minium   -> minimum
>    subsytem -> subsystem
>    unamed   -> unnamed

Thank you, glad to land my first commit to OpenJDK

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

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

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: <ca_NMBywC5tsxqpb955V06eYsqfClX3zmKzPYXl_LoQ=.d7c6f7d0-fd18-4855-9f75-3731074add54@github.com>

> 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 cjplummer at openjdk.java.net  Thu Jul 29 19:55:41 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 29 Jul 2021 19:55:41 GMT
Subject: [jdk17] RFR: 8271507: ProblemList SA tests that are failing with ZGC
 due to JDK-8248912
Message-ID: <kIiJ_UbJRrtDnZUDxYCqSM3GczFbHDav3fh8uXZYMOY=.b139de2e-dfa9-4a6a-9212-a6abf34dc61e@github.com>

These tests recently started failing frequently with ZGC

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

Commit messages:
 - Problem list failing SA tests.

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

PR: https://git.openjdk.java.net/jdk17/pull/294

From cjplummer at openjdk.java.net  Thu Jul 29 19:56:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 29 Jul 2021 19:56:40 GMT
Subject: RFR: 8270341: Test serviceability/dcmd/gc/HeapDumpAllTest.java
 timed-out
Message-ID: <hnvMbKEroTuq9Kp-xMy8WBIfrVIzaqS36pHYJNk6-VE=.33e8359f-95ca-4d4b-8203-85001208f2fc@github.com>

[JDK-8267666](https://bugs.openjdk.java.net/browse/JDK-8267666) added a 2nd test case, which doubles the run time of this test. As a result it occasionally times out. This change double the timeout to 240 seconds.

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

Commit messages:
 - Longer timeout for HeapDumpAllTest needed after new test case added.

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

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

From dcubed at openjdk.java.net  Thu Jul 29 19:59:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 29 Jul 2021 19:59:40 GMT
Subject: [jdk17] RFR: 8271507: ProblemList SA tests that are failing with
 ZGC due to JDK-8248912
In-Reply-To: <kIiJ_UbJRrtDnZUDxYCqSM3GczFbHDav3fh8uXZYMOY=.b139de2e-dfa9-4a6a-9212-a6abf34dc61e@github.com>
References: <kIiJ_UbJRrtDnZUDxYCqSM3GczFbHDav3fh8uXZYMOY=.b139de2e-dfa9-4a6a-9212-a6abf34dc61e@github.com>
Message-ID: <hGTVtaAGvU1tAxhDiFT5tLvtJi3C7c4LzYkSk4nzRCM=.2a0dddbe-cd40-4e0d-aba2-3cc3edca4824@github.com>

On Thu, 29 Jul 2021 19:40:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> These tests recently started failing frequently with ZGC

Marked as reviewed by dcubed (Reviewer).

test/hotspot/jtreg/ProblemList-zgc.txt line 46:

> 44: serviceability/sa/TestJhsdbJstackMixed.java                   8248912   generic-all
> 45: serviceability/sa/ClhsdbPstack.java#id0                       8248912   generic-all
> 46: serviceability/sa/ClhsdbPstack.java#id1                       8248912   generic-all

I'm only seeing failures for 8248912 on linux-x64. You might
want to limit it to that platform.

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

PR: https://git.openjdk.java.net/jdk17/pull/294

From dcubed at openjdk.java.net  Thu Jul 29 20:04:28 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 29 Jul 2021 20:04:28 GMT
Subject: RFR: 8270341: Test serviceability/dcmd/gc/HeapDumpAllTest.java
 timed-out
In-Reply-To: <hnvMbKEroTuq9Kp-xMy8WBIfrVIzaqS36pHYJNk6-VE=.33e8359f-95ca-4d4b-8203-85001208f2fc@github.com>
References: <hnvMbKEroTuq9Kp-xMy8WBIfrVIzaqS36pHYJNk6-VE=.33e8359f-95ca-4d4b-8203-85001208f2fc@github.com>
Message-ID: <E1K9dsilO3ksdrv4d98e7quwyXXS0IzjOot-uzLCjRY=.61ea9f5d-51e8-453e-9c33-2a55373c351b@github.com>

On Thu, 29 Jul 2021 19:50:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> [JDK-8267666](https://bugs.openjdk.java.net/browse/JDK-8267666) added a 2nd test case, which doubles the run time of this test. As a result it occasionally times out. This change double the timeout to 240 seconds.

Changes requested by dcubed (Reviewer).

test/hotspot/jtreg/ProblemList.txt line 121:

> 119: serviceability/sa/ClhsdbPstack.java#id1 8269982 macosx-aarch64
> 120: 
> 121: #serviceability/dcmd/gc/HeapDumpAllTest.java 8270341 generic-x64

Please delete the entry rather than commenting it out.

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

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

From cjplummer at openjdk.java.net  Thu Jul 29 20:04:28 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 29 Jul 2021 20:04:28 GMT
Subject: RFR: 8270341: Test serviceability/dcmd/gc/HeapDumpAllTest.java
 timed-out
In-Reply-To: <E1K9dsilO3ksdrv4d98e7quwyXXS0IzjOot-uzLCjRY=.61ea9f5d-51e8-453e-9c33-2a55373c351b@github.com>
References: <hnvMbKEroTuq9Kp-xMy8WBIfrVIzaqS36pHYJNk6-VE=.33e8359f-95ca-4d4b-8203-85001208f2fc@github.com>
 <E1K9dsilO3ksdrv4d98e7quwyXXS0IzjOot-uzLCjRY=.61ea9f5d-51e8-453e-9c33-2a55373c351b@github.com>
Message-ID: <wB53DfaYsaGjQdNLC42hR9wDBDMTKaQRwnmd8ADe8qI=.efccbed5-e900-44f5-9a7b-770155e22438@github.com>

On Thu, 29 Jul 2021 19:58:59 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> [JDK-8267666](https://bugs.openjdk.java.net/browse/JDK-8267666) added a 2nd test case, which doubles the run time of this test. As a result it occasionally times out. This change double the timeout to 240 seconds.
>
> test/hotspot/jtreg/ProblemList.txt line 121:
> 
>> 119: serviceability/sa/ClhsdbPstack.java#id1 8269982 macosx-aarch64
>> 120: 
>> 121: #serviceability/dcmd/gc/HeapDumpAllTest.java 8270341 generic-x64
> 
> Please delete the entry rather than commenting it out.

Sorry. I initially commented it out for testing since I didn't plan on being the one to push this change, and forgot to delete it. Will fix.

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

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

From cjplummer at openjdk.java.net  Thu Jul 29 20:07:33 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 29 Jul 2021 20:07:33 GMT
Subject: [jdk17] RFR: 8271507: ProblemList SA tests that are failing with
 ZGC due to JDK-8248912
In-Reply-To: <hGTVtaAGvU1tAxhDiFT5tLvtJi3C7c4LzYkSk4nzRCM=.2a0dddbe-cd40-4e0d-aba2-3cc3edca4824@github.com>
References: <kIiJ_UbJRrtDnZUDxYCqSM3GczFbHDav3fh8uXZYMOY=.b139de2e-dfa9-4a6a-9212-a6abf34dc61e@github.com>
 <hGTVtaAGvU1tAxhDiFT5tLvtJi3C7c4LzYkSk4nzRCM=.2a0dddbe-cd40-4e0d-aba2-3cc3edca4824@github.com>
Message-ID: <thRNOQXydyBDnTMjj_zlqDxypVSy4nmZTrYhKpmK-s8=.0632aefb-3c6f-414a-b5e2-0dcb55512760@github.com>

On Thu, 29 Jul 2021 19:56:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> These tests recently started failing frequently with ZGC
>
> test/hotspot/jtreg/ProblemList-zgc.txt line 46:
> 
>> 44: serviceability/sa/TestJhsdbJstackMixed.java                   8248912   generic-all
>> 45: serviceability/sa/ClhsdbPstack.java#id0                       8248912   generic-all
>> 46: serviceability/sa/ClhsdbPstack.java#id1                       8248912   generic-all
> 
> I'm only seeing failures for 8248912 on linux-x64. You might
> want to limit it to that platform.

I considered it, but given it's ZGC, and the SA support for it is not that stable, I thought it best just to silence it on all platforms.

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

PR: https://git.openjdk.java.net/jdk17/pull/294

From cjplummer at openjdk.java.net  Thu Jul 29 20:09:44 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 29 Jul 2021 20:09:44 GMT
Subject: [jdk17] RFR: 8271512: ProblemList
 serviceability/sa/sadebugd/DebugdConnectTest.java due to 8270326
Message-ID: <5XK-H8XM3MKqBPaCuHu6b9MSsO5onRNptnJTgB9KWa8=.f7ef5e0f-13fc-4a9f-ac2d-8152344e8b95@github.com>

This test currently doesn't fail because it is skipped, but JDK-8270199 is fixed (which causes SA tests to be erroneously skipped skipped), we will start to see failures due to JDK-8270326, so DebugdConnectTest.java needs to be problem listed before JDK-8270199 is fixed.

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

Commit messages:
 - Problemlist DebugdConnectTest.java

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

PR: https://git.openjdk.java.net/jdk17/pull/295

From cjplummer at openjdk.java.net  Thu Jul 29 20:11:54 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 29 Jul 2021 20:11:54 GMT
Subject: RFR: 8270341: Test serviceability/dcmd/gc/HeapDumpAllTest.java
 timed-out [v2]
In-Reply-To: <hnvMbKEroTuq9Kp-xMy8WBIfrVIzaqS36pHYJNk6-VE=.33e8359f-95ca-4d4b-8203-85001208f2fc@github.com>
References: <hnvMbKEroTuq9Kp-xMy8WBIfrVIzaqS36pHYJNk6-VE=.33e8359f-95ca-4d4b-8203-85001208f2fc@github.com>
Message-ID: <tupBO-SDJUXxD1qbuqNnZWqAiBAjKgYPQxMjKlzwXbM=.f3e2c7e0-7c37-4ac3-89e7-6c4db2d98962@github.com>

> [JDK-8267666](https://bugs.openjdk.java.net/browse/JDK-8267666) added a 2nd test case, which doubles the run time of this test. As a result it occasionally times out. This change double the timeout to 240 seconds.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Delete entry, don't just comment it out.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4935/files
  - new: https://git.openjdk.java.net/jdk/pull/4935/files/0218344f..27b3c756

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

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

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

From dcubed at openjdk.java.net  Thu Jul 29 20:16:30 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 29 Jul 2021 20:16:30 GMT
Subject: [jdk17] RFR: 8271507: ProblemList SA tests that are failing with
 ZGC due to JDK-8248912
In-Reply-To: <kIiJ_UbJRrtDnZUDxYCqSM3GczFbHDav3fh8uXZYMOY=.b139de2e-dfa9-4a6a-9212-a6abf34dc61e@github.com>
References: <kIiJ_UbJRrtDnZUDxYCqSM3GczFbHDav3fh8uXZYMOY=.b139de2e-dfa9-4a6a-9212-a6abf34dc61e@github.com>
Message-ID: <7PK4nSeL3Xi0zyP_wjHCre1hd8pgMXIa2XTG2v9yrMY=.1f73c153-45e1-4a3d-8d99-0a734ecda9ef@github.com>

On Thu, 29 Jul 2021 19:40:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> These tests recently started failing frequently with ZGC

Marked as reviewed by dcubed (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/294

From dcubed at openjdk.java.net  Thu Jul 29 20:16:31 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 29 Jul 2021 20:16:31 GMT
Subject: [jdk17] RFR: 8271507: ProblemList SA tests that are failing with
 ZGC due to JDK-8248912
In-Reply-To: <thRNOQXydyBDnTMjj_zlqDxypVSy4nmZTrYhKpmK-s8=.0632aefb-3c6f-414a-b5e2-0dcb55512760@github.com>
References: <kIiJ_UbJRrtDnZUDxYCqSM3GczFbHDav3fh8uXZYMOY=.b139de2e-dfa9-4a6a-9212-a6abf34dc61e@github.com>
 <hGTVtaAGvU1tAxhDiFT5tLvtJi3C7c4LzYkSk4nzRCM=.2a0dddbe-cd40-4e0d-aba2-3cc3edca4824@github.com>
 <thRNOQXydyBDnTMjj_zlqDxypVSy4nmZTrYhKpmK-s8=.0632aefb-3c6f-414a-b5e2-0dcb55512760@github.com>
Message-ID: <hn4Ol5w_NmOaPegwYp9SMXPPiRr-sfepoQJ_YH8-4tU=.55ddd723-b04a-4f32-8463-02f2184ea658@github.com>

On Thu, 29 Jul 2021 20:04:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/hotspot/jtreg/ProblemList-zgc.txt line 46:
>> 
>>> 44: serviceability/sa/TestJhsdbJstackMixed.java                   8248912   generic-all
>>> 45: serviceability/sa/ClhsdbPstack.java#id0                       8248912   generic-all
>>> 46: serviceability/sa/ClhsdbPstack.java#id1                       8248912   generic-all
>> 
>> I'm only seeing failures for 8248912 on linux-x64. You might
>> want to limit it to that platform.
>
> I considered it, but given it's ZGC, and the SA support for it is not that stable, I thought it best just to silence it on all platforms.

Sounds like a reasonable plan. Thumbs up.

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

PR: https://git.openjdk.java.net/jdk17/pull/294

From dcubed at openjdk.java.net  Thu Jul 29 20:17:39 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 29 Jul 2021 20:17:39 GMT
Subject: RFR: 8270341: Test serviceability/dcmd/gc/HeapDumpAllTest.java
 timed-out [v2]
In-Reply-To: <tupBO-SDJUXxD1qbuqNnZWqAiBAjKgYPQxMjKlzwXbM=.f3e2c7e0-7c37-4ac3-89e7-6c4db2d98962@github.com>
References: <hnvMbKEroTuq9Kp-xMy8WBIfrVIzaqS36pHYJNk6-VE=.33e8359f-95ca-4d4b-8203-85001208f2fc@github.com>
 <tupBO-SDJUXxD1qbuqNnZWqAiBAjKgYPQxMjKlzwXbM=.f3e2c7e0-7c37-4ac3-89e7-6c4db2d98962@github.com>
Message-ID: <7pvOb3DfzRDF2tC6A3qiSOKptPbWQt3k7N8pg7Wrnuc=.dd601324-91c7-4813-be35-d7b925db779a@github.com>

On Thu, 29 Jul 2021 20:11:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> [JDK-8267666](https://bugs.openjdk.java.net/browse/JDK-8267666) added a 2nd test case, which doubles the run time of this test. As a result it occasionally times out. This change double the timeout to 240 seconds.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete entry, don't just comment it out.

Thumbs up.

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

Marked as reviewed by dcubed (Reviewer).

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

From dcubed at openjdk.java.net  Thu Jul 29 20:18:33 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 29 Jul 2021 20:18:33 GMT
Subject: [jdk17] RFR: 8271512: ProblemList
 serviceability/sa/sadebugd/DebugdConnectTest.java due to 8270326
In-Reply-To: <5XK-H8XM3MKqBPaCuHu6b9MSsO5onRNptnJTgB9KWa8=.f7ef5e0f-13fc-4a9f-ac2d-8152344e8b95@github.com>
References: <5XK-H8XM3MKqBPaCuHu6b9MSsO5onRNptnJTgB9KWa8=.f7ef5e0f-13fc-4a9f-ac2d-8152344e8b95@github.com>
Message-ID: <6D9qqivzTDu_hHJjTWZG4P0yBjgwIqhN1DO1ssrniQs=.fc7f9921-5a9c-4eb3-be25-cf0c5f643525@github.com>

On Thu, 29 Jul 2021 20:03:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test currently doesn't fail because it is skipped, but JDK-8270199 is fixed (which causes SA tests to be erroneously skipped skipped), we will start to see failures due to JDK-8270326, so DebugdConnectTest.java needs to be problem listed before JDK-8270199 is fixed.

Thumbs up. This is a trivial change.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/295

From dcubed at openjdk.java.net  Thu Jul 29 20:20:29 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 29 Jul 2021 20:20:29 GMT
Subject: RFR: 8270341: Test serviceability/dcmd/gc/HeapDumpAllTest.java
 timed-out [v2]
In-Reply-To: <tupBO-SDJUXxD1qbuqNnZWqAiBAjKgYPQxMjKlzwXbM=.f3e2c7e0-7c37-4ac3-89e7-6c4db2d98962@github.com>
References: <hnvMbKEroTuq9Kp-xMy8WBIfrVIzaqS36pHYJNk6-VE=.33e8359f-95ca-4d4b-8203-85001208f2fc@github.com>
 <tupBO-SDJUXxD1qbuqNnZWqAiBAjKgYPQxMjKlzwXbM=.f3e2c7e0-7c37-4ac3-89e7-6c4db2d98962@github.com>
Message-ID: <zPEiV8JCQDgmHEfJoQoyVjCU3Z2sO73QVenRJ5fWWks=.805819b7-d16f-4b1c-a3b3-4befbf7b929b@github.com>

On Thu, 29 Jul 2021 20:11:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> [JDK-8267666](https://bugs.openjdk.java.net/browse/JDK-8267666) added a 2nd test case, which doubles the run time of this test. As a result it occasionally times out. This change double the timeout to 240 seconds.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete entry, don't just comment it out.

Also, this is a trivial fix.

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

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

From dcubed at openjdk.java.net  Thu Jul 29 20:21:35 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 29 Jul 2021 20:21:35 GMT
Subject: [jdk17] RFR: 8271507: ProblemList SA tests that are failing with
 ZGC due to JDK-8248912
In-Reply-To: <kIiJ_UbJRrtDnZUDxYCqSM3GczFbHDav3fh8uXZYMOY=.b139de2e-dfa9-4a6a-9212-a6abf34dc61e@github.com>
References: <kIiJ_UbJRrtDnZUDxYCqSM3GczFbHDav3fh8uXZYMOY=.b139de2e-dfa9-4a6a-9212-a6abf34dc61e@github.com>
Message-ID: <2y563nmT6c3afXjegOh6MXXUzpCXxxJTrB7EKmUoCcw=.14a602a3-138a-4a3c-9630-976edad97d48@github.com>

On Thu, 29 Jul 2021 19:40:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> These tests recently started failing frequently with ZGC

Also, this is a trivial fix.

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

PR: https://git.openjdk.java.net/jdk17/pull/294

From cjplummer at openjdk.java.net  Fri Jul 30 01:00:29 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 30 Jul 2021 01:00:29 GMT
Subject: [jdk17] Integrated: 8271507: ProblemList SA tests that are failing
 with ZGC due to JDK-8248912
In-Reply-To: <kIiJ_UbJRrtDnZUDxYCqSM3GczFbHDav3fh8uXZYMOY=.b139de2e-dfa9-4a6a-9212-a6abf34dc61e@github.com>
References: <kIiJ_UbJRrtDnZUDxYCqSM3GczFbHDav3fh8uXZYMOY=.b139de2e-dfa9-4a6a-9212-a6abf34dc61e@github.com>
Message-ID: <9HnlJ-VXei0aOaqVAnh_i2oOR1Sr1gOckX8Bkuyw3Rc=.8d60b7e0-6c33-405d-b7c2-b456bcf60af2@github.com>

On Thu, 29 Jul 2021 19:40:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> These tests recently started failing frequently with ZGC

This pull request has now been integrated.

Changeset: a1b5b818
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/a1b5b818c5e276c21c05bce71ca01c18c35aef40
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8271507: ProblemList SA tests that are failing with ZGC due to JDK-8248912

Reviewed-by: dcubed

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

PR: https://git.openjdk.java.net/jdk17/pull/294

From cjplummer at openjdk.java.net  Fri Jul 30 01:01:34 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 30 Jul 2021 01:01:34 GMT
Subject: Integrated: 8270341: Test serviceability/dcmd/gc/HeapDumpAllTest.java
 timed-out
In-Reply-To: <hnvMbKEroTuq9Kp-xMy8WBIfrVIzaqS36pHYJNk6-VE=.33e8359f-95ca-4d4b-8203-85001208f2fc@github.com>
References: <hnvMbKEroTuq9Kp-xMy8WBIfrVIzaqS36pHYJNk6-VE=.33e8359f-95ca-4d4b-8203-85001208f2fc@github.com>
Message-ID: <PKZhAbnqAFbdhIXuDax3GrQlG1df5iLqCP2VuK-Z3Zc=.2f61dde1-8510-410b-a17e-43d44dc04892@github.com>

On Thu, 29 Jul 2021 19:50:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> [JDK-8267666](https://bugs.openjdk.java.net/browse/JDK-8267666) added a 2nd test case, which doubles the run time of this test. As a result it occasionally times out. This change double the timeout to 240 seconds.

This pull request has now been integrated.

Changeset: 77fbd99f
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/77fbd99f792c42bb92a240d38f35e3af25500f99
Stats:     5 lines in 2 files changed: 0 ins; 3 del; 2 mod

8270341: Test serviceability/dcmd/gc/HeapDumpAllTest.java timed-out

Reviewed-by: dcubed

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

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

From cjplummer at openjdk.java.net  Fri Jul 30 01:05:29 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 30 Jul 2021 01:05:29 GMT
Subject: [jdk17] Integrated: 8271512: ProblemList
 serviceability/sa/sadebugd/DebugdConnectTest.java due to 8270326
In-Reply-To: <5XK-H8XM3MKqBPaCuHu6b9MSsO5onRNptnJTgB9KWa8=.f7ef5e0f-13fc-4a9f-ac2d-8152344e8b95@github.com>
References: <5XK-H8XM3MKqBPaCuHu6b9MSsO5onRNptnJTgB9KWa8=.f7ef5e0f-13fc-4a9f-ac2d-8152344e8b95@github.com>
Message-ID: <0BO6DwZ4gu6Bh3cTHRNml1RjkE0jLiEAEV1F4anCWQI=.ea8d3c80-52a2-4b43-b10b-64f8b042dabd@github.com>

On Thu, 29 Jul 2021 20:03:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test currently doesn't fail because it is skipped, but when JDK-8270199 is fixed (which causes SA tests to be erroneously skipped skipped), we will start to see failures due to JDK-8270326, so DebugdConnectTest.java needs to be problem listed before JDK-8270199 is fixed.

This pull request has now been integrated.

Changeset: 6180cf1f
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/6180cf1f0d868052709cd55cee53f37f0fc42e21
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8271512: ProblemList serviceability/sa/sadebugd/DebugdConnectTest.java due to 8270326

Reviewed-by: dcubed

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

PR: https://git.openjdk.java.net/jdk17/pull/295

From iignatyev at openjdk.java.net  Fri Jul 30 15:36:35 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 30 Jul 2021 15:36:35 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package
In-Reply-To: <_3viZFs2iZ00hMdeP3Nq9gTmwfIHeTzZ7NVT8thQ1BM=.10005882-f135-4592-a663-b75747da3f6c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <_3viZFs2iZ00hMdeP3Nq9gTmwfIHeTzZ7NVT8thQ1BM=.10005882-f135-4592-a663-b75747da3f6c@github.com>
Message-ID: <vbMMrWc-L2sFBeqYiJ65t7TlmvhtrG_bXJhpONPqBfs=.ea8d576a-7a39-4cd0-b709-a6b5b96637e9@github.com>

On Thu, 29 Jul 2021 01:30:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>> 
>> the majority of the patch is the following substitutions:
>>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>> 
>> testing: tier1-4
>> 
>> Thanks,
>> -- Igor
>
> I know that tests fixes could be pushed during RDP2 without approval.
> But these one is very big and it is not a fix - it is enhancement.
> 
> What is the reason you want to push it into JDK 17 just few days before first Release Candidate? Instead of pushing it into JDK 18.
> 
> And I can't even review it because GutHub UI hangs on these big changes.

@vnkozlov, @dholmes-ora,

Thank you for looking at this!

I want this to be integrated into JDK 17 b/c some "external" libraries use (used to use) WhiteBox API, e.g. jcstress[[2]] used WhiteBox API to deoptimize compiled methods[[3]], and it would be easier for maintainers of such libraries to condition package name based on JDK major version. Also, given JDK 17 is an LTS, it would be beneficial for everyone not to have big differences in test bases b/w it and the mainline.

according to JEP 3, test RFEs are allowed until the very end and don't require late enhancement approval: "Enhancements to tests and documentation during RDP 1 and RDP 2 do not require approval, as long as the relevant issues are identified with a noreg-self or noreg-doc label, as appropriate"[[1]]. So, process-wise, I don't see any issues w/ integrating this RFE, yet, I fully agree that due to its size, this patch can be disruptive and can cause massive failures, which is something we obviously don't want at the current stage of JDK 17. 

I like David's idea about phasing this clean-up, and, due to the reasons described above, I would like to integrate the first part, copying WhiteBox classes to the new package structure and associated changes w/o updating all the tests, into JDK 17 and update the tests on the mainline (w/ backporting into jdk17u).

WDYT?

Cheers,
-- Igor

[1]: https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process
[2]: https://github.com/openjdk/jcstress
[3]: https://github.com/openjdk/jcstress/blob/df83b446f187ae0b0fa31fa54decb59db9e955da/jcstress-core/src/main/java/org/openjdk/jcstress/vm/WhiteBoxSupport.java

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

PR: https://git.openjdk.java.net/jdk17/pull/290

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 iignatyev at openjdk.java.net  Sat Jul 31 20:42:10 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 31 Jul 2021 20:42:10 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
Message-ID: <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>

> Hi all,
> 
> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
> 
> the majority of the patch is the following substitutions:
>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
> 
> testing: tier1-4
> 
> Thanks,
> -- Igor

Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 12 new commits since the last revision:

 - fixed ctw build
 - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's inner class
 - updated requires.VMProps
 - updated TEST.ROOT
 - adjusted hotspot source
 - added test
 - moved and adjusted WhiteBox tests (test/lib-test/sun/hotspot/whitebox)
 - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class
 - removed sun/hotspot/parser/DiagnosticCommand
 - deprecated sun/hotspot classes
   disallowed s.h.WhiteBox w/ security manager
 - ... and 2 more: https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/290/files
  - new: https://git.openjdk.java.net/jdk17/pull/290/files/8f12f2cf..237e8860

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

  Stats: 3248 lines in 939 files changed: 969 ins; 0 del; 2279 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/290.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/290/head:pull/290

PR: https://git.openjdk.java.net/jdk17/pull/290

From iignatyev at openjdk.java.net  Sat Jul 31 20:51:46 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 31 Jul 2021 20:51:46 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
Message-ID: <dy5pWN9zaFu2PCgZkfSir78NuuZxPS4JoVNIuPwVAwM=.8d3eb7ec-c4d0-4ac7-9165-f6f203215ca4@github.com>

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>> 
>> the majority of the patch is the following substitutions:
>>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>> 
>> testing: tier1-4
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Vladimir, David,

I've (forced) pushed a smaller version of the renaming. instead of removing `sun.hotspot` classes, it copies them to `jdk.test.whitebox` (w/ `s.h.parser.DiagnosticCommand` being removed as it's used in WhiteBox signature and it was easier to update a few tests that use it), updates hotspot code to register native methods for both `sun.hotspot.WhiteBox` and `jdk.test.whitebox.WhiteBox` classes. To make it easier and not to introduce extra dependency, I've made it impossible to use `s.h.WB` w/ a security manager enabled, otherwise there would be a dependency b/w `s.h.WB` and `j.t.w.WB$WhiteBoxPermission` or there would be 2 permissions. There are no open JDK tests that are impacted by this limitation.

With minor tweaks in closed source, the patch successfully passes Oracle's tier1-4.

-- Igor

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

PR: https://git.openjdk.java.net/jdk17/pull/290