From sspitsyn at openjdk.org  Wed Feb  1 00:00:59 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 Feb 2023 00:00:59 GMT
Subject: [jdk20] RFR: 8299891: JMX ObjectInputFilter additional classes
 needed [v3]
In-Reply-To: <PFSKFfXoQq5HBrGAcoZWHtQ5iM915Opp-pQoWkTNoeA=.85a93461-9cc8-46c7-bcd4-0119b16a91bc@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
 <PFSKFfXoQq5HBrGAcoZWHtQ5iM915Opp-pQoWkTNoeA=.85a93461-9cc8-46c7-bcd4-0119b16a91bc@github.com>
Message-ID: <-J-a_66vQS4h2q-xWRfdBiPyUO95jOkPdg1HVNR-2LQ=.fe3e2707-9132-4f75-a3f9-2e2d9b7f9466@github.com>

On Tue, 31 Jan 2023 14:29:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive.
>> javax.management.Attribute and AttributeList classes are also needed, and Query related classes.
>> 
>> There are a number of Query-related classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage.  This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list.
>
> Kevin Walls has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Test additional print, and comment edit
>  - properties comment and formatting
>  - Print in getNotificationInfo

Thank you for the update, Kevin!
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/97

From sspitsyn at openjdk.org  Wed Feb  1 00:07:50 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 Feb 2023 00:07:50 GMT
Subject: RFR: 8300811: jdb ThreadStartRequest and ThreadDeathRequest should
 use SUSPEND_NONE instead of SUSPEND_ALL
In-Reply-To: <eTTDNcnt4FN8_tIcbNCjhoPoqbP-RIPOox3frGETA3s=.ac85c211-c8e4-42f8-aafa-4cb993bb35e1@github.com>
References: <eTTDNcnt4FN8_tIcbNCjhoPoqbP-RIPOox3frGETA3s=.ac85c211-c8e4-42f8-aafa-4cb993bb35e1@github.com>
Message-ID: <Q87qVHhv-GnZDoJ36koTRhryrurDwFuOX_L0b5umKuQ=.ee1878f4-9278-4a91-a288-6ae990e56875@github.com>

On Mon, 23 Jan 2023 21:02:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> jdb creates a ThreadStartRequest and ThreadDeathRequest so it can track all created threads. It creates them with the SUSPEND_ALL policy. This is unnecessary since jdb always immediately resumes all threads after doing the thread bookkeeping. There is no interaction with the jdb user like there would be with something like a Breakpoint event, and therefore no reason to suspend.
> 
> I was debugging an app that does nothing except create threads and allow them to quickly exit. Changing the policy to SUSPEND_NONE sped up the execution of the app by about 100x (that's 100 times faster, not 100%)

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12152

From sspitsyn at openjdk.org  Wed Feb  1 04:12:47 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 Feb 2023 04:12:47 GMT
Subject: RFR: 8228604: StackMapFrames are missing from redefined class
 bytes of retransformed classes
In-Reply-To: <Kbnk8iFV0fOWMvi3sHmdzS50clZJw48LlgpVlwsVv2c=.ff8a12a4-d5bf-4a58-808a-c7e38b6f25bd@github.com>
References: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
 <Kbnk8iFV0fOWMvi3sHmdzS50clZJw48LlgpVlwsVv2c=.ff8a12a4-d5bf-4a58-808a-c7e38b6f25bd@github.com>
Message-ID: <x5YB7K8IMMLbIdfAO8rybALstxtmFp4JRoOUjFqHr4E=.66944f66-2891-4e5e-bf94-bc1d60c8eb9a@github.com>

On Tue, 31 Jan 2023 07:38:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I guess I would assume that an agent/tool modifying a class would require it to be regenerated.

This is my understanding too. My understanding is that eliding the StackMapTable attribute when there is no split-verifier is an optimization which can cause problems for agents/tools. So, the suggestion from Alex to simplify this by removing this optimization looks reasonable to me.
We can run more Runtime tests to make sure this does not break anything.

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

PR: https://git.openjdk.org/jdk/pull/12155

From dholmes at openjdk.org  Wed Feb  1 04:34:58 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 1 Feb 2023 04:34:58 GMT
Subject: RFR: 8228604: StackMapFrames are missing from redefined class
 bytes of retransformed classes
In-Reply-To: <x5YB7K8IMMLbIdfAO8rybALstxtmFp4JRoOUjFqHr4E=.66944f66-2891-4e5e-bf94-bc1d60c8eb9a@github.com>
References: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
 <Kbnk8iFV0fOWMvi3sHmdzS50clZJw48LlgpVlwsVv2c=.ff8a12a4-d5bf-4a58-808a-c7e38b6f25bd@github.com>
 <x5YB7K8IMMLbIdfAO8rybALstxtmFp4JRoOUjFqHr4E=.66944f66-2891-4e5e-bf94-bc1d60c8eb9a@github.com>
Message-ID: <EXdU_QZiA1-oVpFLhs4EPgSNdEVv1lKd_8TgGi4GotE=.05c31bf0-eb1a-4a24-915d-e6ea7f8d2bd7@github.com>

On Wed, 1 Feb 2023 04:10:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> My understanding is that eliding the StackMapTable attribute when there is no split-verifier is an optimization which can cause problems for agents/tools. 

Sure we can keep the attribute, but I have to question why these agents/tools are using something that is only present for the purposes of verification and is not required to be present. Seems like we are encouraging buggy agent/tool behaviour.

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

PR: https://git.openjdk.org/jdk/pull/12155

From sspitsyn at openjdk.org  Wed Feb  1 04:53:52 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 Feb 2023 04:53:52 GMT
Subject: RFR: 8228604: StackMapFrames are missing from redefined class
 bytes of retransformed classes
In-Reply-To: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
References: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
Message-ID: <rpNdaEwlxvwyNeoUCwQCNSJxUzBbj8nP_PLMe0kZvVw=.5983d69e-d8be-4251-9ca5-eec536960065@github.com>

On Tue, 24 Jan 2023 00:16:10 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> classFileParser drops stack map frames for JDK classes (when verification is not required).
> As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition.
> Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS.
> This code is old (from "initial load") and I don't understand the reason it was implemented this way.
> 
> Testing: tier1-tier6

The fix looks good in general.
I've posted a couple of suggestions.
Will make another pass through it tomorrow.
Thanks,
Serguei

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/MissedStackMapFrames.java line 62:

> 60:     private static int getStackMapFrameCount(byte[] classfileBuffer) {
> 61:         ClassReader reader = new ClassReader(classfileBuffer);
> 62:         final int[] frameCount = {0};

I guess, we can use just int instead of an array element.

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/libMissedStackMapFrames.cpp line 34:

> 32:     vprintf(format, args);
> 33:     va_end(args);
> 34:     fflush(0);

We normally use indent 2 for native code in JVMTI tests.

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

PR: https://git.openjdk.org/jdk/pull/12155

From sspitsyn at openjdk.org  Wed Feb  1 04:53:54 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 Feb 2023 04:53:54 GMT
Subject: RFR: 8228604: StackMapFrames are missing from redefined class
 bytes of retransformed classes
In-Reply-To: <672UTbipXNoOK-cibNxBjYf7SQ6liXhCIGv5AW2JpeI=.31499f3f-58e5-4bf8-8393-4f6ab5c29f8d@github.com>
References: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
 <672UTbipXNoOK-cibNxBjYf7SQ6liXhCIGv5AW2JpeI=.31499f3f-58e5-4bf8-8393-4f6ab5c29f8d@github.com>
Message-ID: <5KduwxUx51zFMceWpTNPLnXTeMAiVDJLNRbIIUDNGgY=.4c4b86da-e2a0-419e-bb2a-f5bd9185b7f6@github.com>

On Tue, 24 Jan 2023 03:17:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> classFileParser drops stack map frames for JDK classes (when verification is not required).
>> As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition.
>> Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS.
>> This code is old (from "initial load") and I don't understand the reason it was implemented this way.
>> 
>> Testing: tier1-tier6
>
> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/MissedStackMapFrames.java line 107:
> 
>> 105:             byte[] retransformBytes = retransformBytes(i);
>> 106:             checkStackMapFrames(cls + "(load)", loadBytes);
>> 107:             checkStackMapFrames(cls + "(retranform)", retransformBytes);
> 
> "retransform"

I'd also suggest a couple of name changes to increase readability:
  loadBytes => loadedBytes
  retransformBytes => retransformedBytes

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

PR: https://git.openjdk.org/jdk/pull/12155

From kvn at openjdk.org  Wed Feb  1 05:01:50 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 1 Feb 2023 05:01:50 GMT
Subject: RFR: JDK-8301447: [REDO] CodeHeap has virtual methods that are not
 overridden
In-Reply-To: <ye9zfWiUpmPKI85Z3W9VtMnZlUEIRkzZUbjkrHQPp6w=.19fc5050-dc38-4667-8a2b-3f11f9e3cfff@github.com>
References: <ye9zfWiUpmPKI85Z3W9VtMnZlUEIRkzZUbjkrHQPp6w=.19fc5050-dc38-4667-8a2b-3f11f9e3cfff@github.com>
Message-ID: <VmxH1hyJ27yrZV8xWkPXahoRzHCmM9isH-yDkgHLF2o=.d49475f7-debf-4c53-925c-efcfcc99af31@github.com>

On Tue, 31 Jan 2023 14:30:29 GMT, Justin King <jcking at openjdk.org> wrote:

> Redo [JDK-8301378](https://bugs.openjdk.org/browse/JDK-8301378), this time also fixing the serviceability code.

I ran tier1-3 and -Xcomp testing and it passed. Except serviceability/sa/ClhsdbDumpheap.java timed out with -Xcomp but we saw this before.

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

PR: https://git.openjdk.org/jdk/pull/12345

From sspitsyn at openjdk.org  Wed Feb  1 05:01:50 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 Feb 2023 05:01:50 GMT
Subject: RFR: 8228604: StackMapFrames are missing from redefined class
 bytes of retransformed classes
In-Reply-To: <EXdU_QZiA1-oVpFLhs4EPgSNdEVv1lKd_8TgGi4GotE=.05c31bf0-eb1a-4a24-915d-e6ea7f8d2bd7@github.com>
References: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
 <Kbnk8iFV0fOWMvi3sHmdzS50clZJw48LlgpVlwsVv2c=.ff8a12a4-d5bf-4a58-808a-c7e38b6f25bd@github.com>
 <x5YB7K8IMMLbIdfAO8rybALstxtmFp4JRoOUjFqHr4E=.66944f66-2891-4e5e-bf94-bc1d60c8eb9a@github.com>
 <EXdU_QZiA1-oVpFLhs4EPgSNdEVv1lKd_8TgGi4GotE=.05c31bf0-eb1a-4a24-915d-e6ea7f8d2bd7@github.com>
Message-ID: <A_6w0z8439x0vbrLcbBDHgDkK6bWJG0fSFJaIilUb4w=.7a18c2e9-79d9-42e2-92a7-30debfd295d9@github.com>

On Wed, 1 Feb 2023 04:32:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > My understanding is that eliding the StackMapTable attribute when there is no split-verifier is an optimization which can cause problems for agents/tools.
> 
> Sure we can keep the attribute, but I have to question why these agents/tools are using something that is only present for the purposes of verification and is not required to be present. Seems like we are encouraging buggy agent/tool behaviour.

I see your point. Tools may need this attribute for similar purpose as the split-verifier. Your question is valid anyway.
In our case (testing purpose), we want to make sure we can reconstitute this attribute correctly.

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

PR: https://git.openjdk.org/jdk/pull/12155

From kevinw at openjdk.org  Wed Feb  1 09:05:02 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 1 Feb 2023 09:05:02 GMT
Subject: [jdk20] RFR: 8299891: JMX ObjectInputFilter additional classes
 needed [v3]
In-Reply-To: <PFSKFfXoQq5HBrGAcoZWHtQ5iM915Opp-pQoWkTNoeA=.85a93461-9cc8-46c7-bcd4-0119b16a91bc@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
 <PFSKFfXoQq5HBrGAcoZWHtQ5iM915Opp-pQoWkTNoeA=.85a93461-9cc8-46c7-bcd4-0119b16a91bc@github.com>
Message-ID: <6nfH7bI5HvpnWpmw_vd1tq__S__pOhSpDF1tH5Of4ug=.d5e303af-a616-4337-8784-6f40fd0d3a1a@github.com>

On Tue, 31 Jan 2023 14:29:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive.
>> javax.management.Attribute and AttributeList classes are also needed, and Query related classes.
>> 
>> There are a number of Query-related classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage.  This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list.
>
> Kevin Walls has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Test additional print, and comment edit
>  - properties comment and formatting
>  - Print in getNotificationInfo

Thanks for the suggestions and reviews, will integrate.

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

PR: https://git.openjdk.org/jdk20/pull/97

From kevinw at openjdk.org  Wed Feb  1 09:18:04 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 1 Feb 2023 09:18:04 GMT
Subject: [jdk20] Integrated: 8299891: JMX ObjectInputFilter additional classes
 needed
In-Reply-To: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
References: <h4CeVFsM2p0D4FwjcVnNKQfbVZEIYs_Asq8vwMW5frY=.f14d64ce-253c-4908-a8d5-5040cdcf3459@github.com>
Message-ID: <5zBtoPQqwjbHQqYHfI2jUGOYZ9jbMrk2Z9u9d53GQnM=.f9c16acb-04de-48c2-95e5-d7507d7a444c@github.com>

On Wed, 11 Jan 2023 09:40:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive.
> javax.management.Attribute and AttributeList classes are also needed, and Query related classes.
> 
> There are a number of Query-related classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage.  This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list.

This pull request has now been integrated.

Changeset: 225f8053
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/225f80532cbeb1597c7f5d660e67d4fa4248c83f
Stats:     158 lines in 2 files changed: 145 ins; 0 del; 13 mod

8299891: JMX ObjectInputFilter additional classes needed

Reviewed-by: dfuchs, sspitsyn, cjplummer

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

PR: https://git.openjdk.org/jdk20/pull/97

From thartmann at openjdk.org  Wed Feb  1 13:13:57 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 1 Feb 2023 13:13:57 GMT
Subject: RFR: JDK-8301447: [REDO] CodeHeap has virtual methods that are not
 overridden
In-Reply-To: <ye9zfWiUpmPKI85Z3W9VtMnZlUEIRkzZUbjkrHQPp6w=.19fc5050-dc38-4667-8a2b-3f11f9e3cfff@github.com>
References: <ye9zfWiUpmPKI85Z3W9VtMnZlUEIRkzZUbjkrHQPp6w=.19fc5050-dc38-4667-8a2b-3f11f9e3cfff@github.com>
Message-ID: <435cHWzL2CzyeAiTTAtwvjjv8tPvPodAjlmoYwH-OYM=.29ecda82-9ebf-4248-bf8c-8e2a33b28289@github.com>

On Tue, 31 Jan 2023 14:30:29 GMT, Justin King <jcking at openjdk.org> wrote:

> Redo [JDK-8301378](https://bugs.openjdk.org/browse/JDK-8301378), this time also fixing the serviceability code.

Looks good to me and Vladimir's testing all passed.

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12345

From jcking at openjdk.org  Wed Feb  1 13:13:58 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 1 Feb 2023 13:13:58 GMT
Subject: Integrated: JDK-8301447: [REDO] CodeHeap has virtual methods that are
 not overridden
In-Reply-To: <ye9zfWiUpmPKI85Z3W9VtMnZlUEIRkzZUbjkrHQPp6w=.19fc5050-dc38-4667-8a2b-3f11f9e3cfff@github.com>
References: <ye9zfWiUpmPKI85Z3W9VtMnZlUEIRkzZUbjkrHQPp6w=.19fc5050-dc38-4667-8a2b-3f11f9e3cfff@github.com>
Message-ID: <dA1-97HOJxExtopO0HSxfBrjVNj1VGPD6tIRsCeDJRQ=.b5a00211-77b9-4ec1-ae4b-03fe2e7ae983@github.com>

On Tue, 31 Jan 2023 14:30:29 GMT, Justin King <jcking at openjdk.org> wrote:

> Redo [JDK-8301378](https://bugs.openjdk.org/browse/JDK-8301378), this time also fixing the serviceability code.

This pull request has now been integrated.

Changeset: 7c6a8db3
Author:    Justin King <jcking at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7c6a8db328e386b33b9b7a61fccabaec9a17dc66
Stats:     10 lines in 2 files changed: 0 ins; 5 del; 5 mod

8301447: [REDO] CodeHeap has virtual methods that are not overridden

Reviewed-by: kvn, thartmann

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

PR: https://git.openjdk.org/jdk/pull/12345

From cjplummer at openjdk.org  Wed Feb  1 19:02:11 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 1 Feb 2023 19:02:11 GMT
Subject: Integrated: 8300811: jdb ThreadStartRequest and ThreadDeathRequest
 should use SUSPEND_NONE instead of SUSPEND_ALL
In-Reply-To: <eTTDNcnt4FN8_tIcbNCjhoPoqbP-RIPOox3frGETA3s=.ac85c211-c8e4-42f8-aafa-4cb993bb35e1@github.com>
References: <eTTDNcnt4FN8_tIcbNCjhoPoqbP-RIPOox3frGETA3s=.ac85c211-c8e4-42f8-aafa-4cb993bb35e1@github.com>
Message-ID: <rPTQubzWYJF1M4fng43TO4PZBxw2MFTaK7A4Zk8RSsg=.078d95f3-bfed-4a47-bfea-fcc75240b64c@github.com>

On Mon, 23 Jan 2023 21:02:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> jdb creates a ThreadStartRequest and ThreadDeathRequest so it can track all created threads. It creates them with the SUSPEND_ALL policy. This is unnecessary since jdb always immediately resumes all threads after doing the thread bookkeeping. There is no interaction with the jdb user like there would be with something like a Breakpoint event, and therefore no reason to suspend.
> 
> I was debugging an app that does nothing except create threads and allow them to quickly exit. Changing the policy to SUSPEND_NONE sped up the execution of the app by about 100x (that's 100 times faster, not 100%)

This pull request has now been integrated.

Changeset: 99521087
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/995210873497eb2400b7672096e6f3cac7fde9a6
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8300811: jdb ThreadStartRequest and ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL

Reviewed-by: alanb, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/12152

From jwilhelm at openjdk.org  Wed Feb  1 20:10:46 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 1 Feb 2023 20:10:46 GMT
Subject: RFR: Merge jdk20
Message-ID: <uECVXFD4DaiFB8oJ8sMqMnncDYZTXZSlJ0qpvN_nVao=.0ca72a0b-5528-46f8-9876-690dda3313c3@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298377: JfrVframeStream causes deadlocks in ZGC
 - 8299891: JMX ObjectInputFilter additional classes needed

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/12374/files
  Stats: 158 lines in 2 files changed: 145 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/12374.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12374/head:pull/12374

PR: https://git.openjdk.org/jdk/pull/12374

From amenkov at openjdk.org  Wed Feb  1 20:58:03 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 1 Feb 2023 20:58:03 GMT
Subject: RFR: 8228604: StackMapFrames are missing from redefined class
 bytes of retransformed classes [v2]
In-Reply-To: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
References: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
Message-ID: <2M1uK5bpkZgeBrfG0yOowgSzcBijk7laUFxJcKYOQsE=.f68f6deb-f989-41ca-aac7-993b00319406@github.com>

> classFileParser drops stack map frames for JDK classes (when verification is not required).
> As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition.
> Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS.
> This code is old (from "initial load") and I don't understand the reason it was implemented this way.
> 
> Testing: tier1-tier6

Alex Menkov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into class_parser_stackmap
 - removed trailing spaces
 - Fixes class parser to not drop stackmap frames

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

Changes: https://git.openjdk.org/jdk/pull/12155/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12155&range=01
  Stats: 344 lines in 3 files changed: 338 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12155.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12155/head:pull/12155

PR: https://git.openjdk.org/jdk/pull/12155

From jwilhelm at openjdk.org  Wed Feb  1 22:39:33 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 1 Feb 2023 22:39:33 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <uECVXFD4DaiFB8oJ8sMqMnncDYZTXZSlJ0qpvN_nVao=.0ca72a0b-5528-46f8-9876-690dda3313c3@github.com>
References: <uECVXFD4DaiFB8oJ8sMqMnncDYZTXZSlJ0qpvN_nVao=.0ca72a0b-5528-46f8-9876-690dda3313c3@github.com>
Message-ID: <m1huL7ABF-nuCXMUMXLb430DmlrwcReSTLks1lVGkno=.ee42b0b4-ac46-4039-82ae-eb409e58bf58@github.com>

On Wed, 1 Feb 2023 19:43:51 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: d6832121
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d6832121b718d40df263da6e2f9261dee2c4c508
Stats:     158 lines in 2 files changed: 145 ins; 0 del; 13 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/12374

From cjplummer at openjdk.org  Wed Feb  1 23:58:11 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 1 Feb 2023 23:58:11 GMT
Subject: RFR: 8301644: com/sun/jdi/JdbStopThreadTest.java fails after
 JDK-8300811
Message-ID: <lJSRRFuBzSVqIlDfhW10tzNEBt_rlMq09EcqKeuMu5w=.80705af7-7c31-4c12-9eff-09180a4f1bfc@github.com>

This test started failing after [JDK-8300811](https://bugs.openjdk.org/browse/JDK-8300811), which made the jdb ThreadStartRequest and ThreadDeathRequest use SUSPEND_NONE instead of SUSPEND_ALL. This sped up the handling of these events a lot, which has impacted the timing of this test and exposed a bug.

The 2nd (last) breakpoint this test sets up uses SUSPEND_NONE. The debuggee quickly exits after hitting the breakpoint because it is not suspended. This puts the test at risk of having the debuggee exit before jdb can produce the full output for the breakpoint that includes the line number information. The test is looking for this output When it is not there, the test fails. Although the risk was always there, it was made worse by speeding up the handling of the ThreadDeath event. This is why this issue is also only seen on product builds (jdb needs to be running fast).

This failure is somewhat noisy so I'd like to push it quickly, but it should still have two reviews.

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

Commit messages:
 - Fix JdbStopThreadTest.java after JDK-8301644 broke it.

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

PR: https://git.openjdk.org/jdk/pull/12378

From amenkov at openjdk.org  Thu Feb  2 00:17:58 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 2 Feb 2023 00:17:58 GMT
Subject: RFR: 8228604: StackMapFrames are missing from redefined class
 bytes of retransformed classes [v3]
In-Reply-To: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
References: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
Message-ID: <MSIcChNDDD404MpUfKu1g6PAe64NtYkvY-6OkRtoIT0=.7963ac00-e469-43d7-8142-97f076e04740@github.com>

> classFileParser drops stack map frames for JDK classes (when verification is not required).
> As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition.
> Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS.
> This code is old (from "initial load") and I don't understand the reason it was implemented this way.
> 
> Testing: tier1-tier6

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

  Updated test - addressed review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12155/files
  - new: https://git.openjdk.org/jdk/pull/12155/files/76970bec..3ff8a90e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12155&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12155&range=01-02

  Stats: 134 lines in 2 files changed: 15 ins; 6 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/12155.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12155/head:pull/12155

PR: https://git.openjdk.org/jdk/pull/12155

From amenkov at openjdk.org  Thu Feb  2 00:23:24 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 2 Feb 2023 00:23:24 GMT
Subject: RFR: 8228604: StackMapFrames are missing from redefined class
 bytes of retransformed classes [v3]
In-Reply-To: <5KduwxUx51zFMceWpTNPLnXTeMAiVDJLNRbIIUDNGgY=.4c4b86da-e2a0-419e-bb2a-f5bd9185b7f6@github.com>
References: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
 <672UTbipXNoOK-cibNxBjYf7SQ6liXhCIGv5AW2JpeI=.31499f3f-58e5-4bf8-8393-4f6ab5c29f8d@github.com>
 <5KduwxUx51zFMceWpTNPLnXTeMAiVDJLNRbIIUDNGgY=.4c4b86da-e2a0-419e-bb2a-f5bd9185b7f6@github.com>
Message-ID: <P2G5fSUeI4F4QfwPaV_Zn6FOafbFscnmrwuDJF7tAiw=.790eb6a6-72c9-4894-b608-5358071ccc29@github.com>

On Wed, 1 Feb 2023 04:22:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> "retransform"

fixed

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

PR: https://git.openjdk.org/jdk/pull/12155

From amenkov at openjdk.org  Thu Feb  2 00:29:26 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 2 Feb 2023 00:29:26 GMT
Subject: RFR: 8228604: StackMapFrames are missing from redefined class
 bytes of retransformed classes [v3]
In-Reply-To: <672UTbipXNoOK-cibNxBjYf7SQ6liXhCIGv5AW2JpeI=.31499f3f-58e5-4bf8-8393-4f6ab5c29f8d@github.com>
References: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
 <672UTbipXNoOK-cibNxBjYf7SQ6liXhCIGv5AW2JpeI=.31499f3f-58e5-4bf8-8393-4f6ab5c29f8d@github.com>
Message-ID: <fdWY9D50RiFEKHdIxx89LtoqgyK8Ldiyc_Jlwziz830=.bb48d897-84ea-4f3d-a2f8-f94d8f5e8605@github.com>

On Tue, 24 Jan 2023 03:58:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> 



> Copyright needs updating.

It was updated by other fix in master branch

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

PR: https://git.openjdk.org/jdk/pull/12155

From amenkov at openjdk.org  Thu Feb  2 00:29:27 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 2 Feb 2023 00:29:27 GMT
Subject: RFR: 8228604: StackMapFrames are missing from redefined class
 bytes of retransformed classes [v3]
In-Reply-To: <P2G5fSUeI4F4QfwPaV_Zn6FOafbFscnmrwuDJF7tAiw=.790eb6a6-72c9-4894-b608-5358071ccc29@github.com>
References: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
 <672UTbipXNoOK-cibNxBjYf7SQ6liXhCIGv5AW2JpeI=.31499f3f-58e5-4bf8-8393-4f6ab5c29f8d@github.com>
 <5KduwxUx51zFMceWpTNPLnXTeMAiVDJLNRbIIUDNGgY=.4c4b86da-e2a0-419e-bb2a-f5bd9185b7f6@github.com>
 <P2G5fSUeI4F4QfwPaV_Zn6FOafbFscnmrwuDJF7tAiw=.790eb6a6-72c9-4894-b608-5358071ccc29@github.com>
Message-ID: <HwmVxBleoyJ0cQzzcd9_Am4e_TKjoLf3zvTcdFJn7w4=.97c07f16-a4f5-4492-b91e-abaf1e8ff4da@github.com>

On Thu, 2 Feb 2023 00:20:06 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> I'd also suggest a couple of name changes to increase readability:
>>   loadBytes => loadedBytes
>>   retransformBytes => retransformedBytes
>
>> "retransform"
> 
> fixed

> I'd also suggest a couple of name changes to increase readability: loadBytes => loadedBytes retransformBytes => retransformedBytes

I think it would make it be misleading.
this bytes are class file bytes passed to CFLH on class loading/retransformation, not the bytes loaded/transformed

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

PR: https://git.openjdk.org/jdk/pull/12155

From amenkov at openjdk.org  Thu Feb  2 02:35:21 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 2 Feb 2023 02:35:21 GMT
Subject: RFR: 8301644: com/sun/jdi/JdbStopThreadTest.java fails after
 JDK-8300811
In-Reply-To: <lJSRRFuBzSVqIlDfhW10tzNEBt_rlMq09EcqKeuMu5w=.80705af7-7c31-4c12-9eff-09180a4f1bfc@github.com>
References: <lJSRRFuBzSVqIlDfhW10tzNEBt_rlMq09EcqKeuMu5w=.80705af7-7c31-4c12-9eff-09180a4f1bfc@github.com>
Message-ID: <xzEIFHF8d05EZ-6UtNh1KXrR6b1ZnSn1RKcdCgP43RA=.c100c1ff-22b4-4791-a36f-8c4024520470@github.com>

On Wed, 1 Feb 2023 23:51:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test started failing after [JDK-8300811](https://bugs.openjdk.org/browse/JDK-8300811), which made the jdb ThreadStartRequest and ThreadDeathRequest use SUSPEND_NONE instead of SUSPEND_ALL. This sped up the handling of these events a lot, which has impacted the timing of this test and exposed a bug.
> 
> The 2nd (last) breakpoint this test sets up uses SUSPEND_NONE. The debuggee quickly exits after hitting the breakpoint because it is not suspended. This puts the test at risk of having the debuggee exit before jdb can produce the full output for the breakpoint that includes the line number information. The test is looking for this output When it is not there, the test fails. Although the risk was always there, it was made worse by speeding up the handling of the ThreadDeath event. This is why this issue is also only seen on product builds (jdb needs to be running fast).
> 
> This failure is somewhat noisy so I'd like to push it quickly, but it should still have two reviews.

Marked as reviewed by amenkov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12378

From jwaters at openjdk.org  Thu Feb  2 06:19:03 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Feb 2023 06:19:03 GMT
Subject: RFR: 8301659: Resolve initialization reordering issues on Windows for
 libawt and libsaproc
Message-ID: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>

Small, trivial change to resolve initialization order reordering in constructors, required for [JDK-8301659](https://bugs.openjdk.org/browse/JDK-8301659)

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

Commit messages:
 - Resolve reordering issues in libawt and libsaproc

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

PR: https://git.openjdk.org/jdk/pull/12382

From dholmes at openjdk.org  Thu Feb  2 06:47:23 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 Feb 2023 06:47:23 GMT
Subject: RFR: 8301659: Resolve initialization reordering issues on Windows
 for libawt and libsaproc
In-Reply-To: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
References: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
Message-ID: <GscycQ56rVy-uNOMZeuGwcY79cdbgV0fn3ewsCZB49w=.ffeecf81-87c1-4481-b980-f78e4f364614@github.com>

On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Small, trivial change to resolve initialization order reordering in constructors, required for [JDK-8301659](https://bugs.openjdk.org/browse/JDK-8301659)

Bundling unrelated changes like this together is rarely a good idea, but these changes seem trivial enough. I thought the compiler already checked fields where initialized in declaration order, but I guess not with Visual Studio.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12382

From kevinw at openjdk.org  Thu Feb  2 10:52:24 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 2 Feb 2023 10:52:24 GMT
Subject: RFR: 8301644: com/sun/jdi/JdbStopThreadTest.java fails after
 JDK-8300811
In-Reply-To: <lJSRRFuBzSVqIlDfhW10tzNEBt_rlMq09EcqKeuMu5w=.80705af7-7c31-4c12-9eff-09180a4f1bfc@github.com>
References: <lJSRRFuBzSVqIlDfhW10tzNEBt_rlMq09EcqKeuMu5w=.80705af7-7c31-4c12-9eff-09180a4f1bfc@github.com>
Message-ID: <o6pQJJyNABnGGMjxEe7bOsZQtrLNr4UH3Gs4zk1OWjs=.2043424e-2f13-45ba-986c-d46839e41feb@github.com>

On Wed, 1 Feb 2023 23:51:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test started failing after [JDK-8300811](https://bugs.openjdk.org/browse/JDK-8300811), which made the jdb ThreadStartRequest and ThreadDeathRequest use SUSPEND_NONE instead of SUSPEND_ALL. This sped up the handling of these events a lot, which has impacted the timing of this test and exposed a bug.
> 
> The 2nd (last) breakpoint this test sets up uses SUSPEND_NONE. The debuggee quickly exits after hitting the breakpoint because it is not suspended. This puts the test at risk of having the debuggee exit before jdb can produce the full output for the breakpoint that includes the line number information. The test is looking for this output When it is not there, the test fails. Although the risk was always there, it was made worse by speeding up the handling of the ThreadDeath event. This is why this issue is also only seen on product builds (jdb needs to be running fast).
> 
> This failure is somewhat noisy so I'd like to push it quickly, but it should still have two reviews.

Marked as reviewed by kevinw (Committer).

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

PR: https://git.openjdk.org/jdk/pull/12378

From kevinw at openjdk.org  Thu Feb  2 12:15:21 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 2 Feb 2023 12:15:21 GMT
Subject: RFR: 8301659: Resolve initialization reordering issues on Windows
 for libawt and libsaproc
In-Reply-To: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
References: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
Message-ID: <AzWzL8X2e1ARIp9ViZQwHImDyROCQfbPh99l8Gi4otU=.0263bbd4-bca4-4df2-acf2-f36def422430@github.com>

On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Small, trivial change to resolve initialization order reordering in constructors, required for [JDK-8301659](https://bugs.openjdk.org/browse/JDK-8301659)

(In the description you mean it is required for JDK-8288293.)
Could we say in the bug exactly when this is an issue (maybe it's a certain compiler?), and include a copy of the error or warning that is seen?  That would help somebody find this change if they hit the issue, and clarify if it's a build failure or something else.
The changes look ok to me.

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

PR: https://git.openjdk.org/jdk/pull/12382

From abakhtin at openjdk.org  Thu Feb  2 13:42:51 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 2 Feb 2023 13:42:51 GMT
Subject: RFR: 8299234: JMX Repository.query performance [v5]
In-Reply-To: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
References: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
Message-ID: <YH-y2lwy0IU4s9Ri6vuNwwgpZpJzFIQW_ttuE8KkFFs=.ccabc1f9-d27d-469a-847b-69c4e882d7e6@github.com>

> Please find a patch to improve JMX Repository.query performance
> 
> Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles:
> Before:
> 
> $ java test 1000000 1000000
> Test PASSED in 8943169791 ns.
> GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118
> 
> 
> After:
> 
> $ java test 1000000 1000000
> Test PASSED in 4808213917 ns.
> GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53
> 
> Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation.
> 
> All javax/management jtreg tests passed successfully.

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

  Optimize ObjectName.matchDomains

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11758/files
  - new: https://git.openjdk.org/jdk/pull/11758/files/594dfa5b..0bdbbcb5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11758&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11758&range=03-04

  Stats: 10 lines in 2 files changed: 9 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11758.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11758/head:pull/11758

PR: https://git.openjdk.org/jdk/pull/11758

From abakhtin at openjdk.org  Thu Feb  2 13:59:27 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 2 Feb 2023 13:59:27 GMT
Subject: RFR: 8299234: JMX Repository.query performance [v3]
In-Reply-To: <T31g8Y89vg_a1A0KXw6rRjj5cpzi0wfSCcNfOvGcJkQ=.74dee506-795b-4bdf-9938-e7b8de64a2fd@github.com>
References: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
 <i9TaxZV335n0KXtM2NRKDz6vK2Uv7PNh95X-b-ot--w=.ed6e43dc-7c7a-45c0-86e8-abe9ef29bb16@github.com>
 <T31g8Y89vg_a1A0KXw6rRjj5cpzi0wfSCcNfOvGcJkQ=.74dee506-795b-4bdf-9938-e7b8de64a2fd@github.com>
Message-ID: <z2hZb8nMhG4D5jZkFVdzlaJIuWh_cDiBUaQsgfgpXMs=.1946dc2d-dbea-40e2-81d2-97c39f5f1a78@github.com>

On Mon, 23 Jan 2023 14:14:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix parameters order for Util.wildmatch
>
> Hi Alexey - you have addressed most of my concerns but let me reinstate that the changes to ObjectName are observable by subclasses and thus will require a CSR. As such this fix may also not be a good candidate for backport (if that was your intention), as it comes with a potential regression risk. A possibility could be to implement the ObjectName changes as a separate PR.

@dfuch, I've returned ObjectName optimization for the instances of ObjectName class only.
JMH benchmark does not show much difference without these changes.
Benchmark results for original implementation:

Benchmark                                 (N)   Mode  Cnt    Score    Error  Units
JmxBenchmark.applyForMyObjectName        1000  thrpt   10  539.134 ? 11.643  ops/s
JmxBenchmark.applyForObjectName          1000  thrpt   10  495.961 ? 10.550  ops/s
JmxBenchmark.queryMBeansForMyObjectName  1000  thrpt   10   75.482 ?  0.302  ops/s
JmxBenchmark.queryMBeansForObjectName    1000  thrpt   10  111.721 ?  0.462  ops/s
JmxBenchmark.queryNamesForMyObjectName   1000  thrpt   10   79.004 ?  0.398  ops/s
JmxBenchmark.queryNamesForObjectName     1000  thrpt   10  125.877 ?  2.024  ops/s

Benchmark results for the proposed implementation:

Benchmark                                 (N)   Mode  Cnt    Score    Error  Units
JmxBenchmark.applyForMyObjectName        1000  thrpt   10  542.233 ?  4.137  ops/s
JmxBenchmark.applyForObjectName          1000  thrpt   10  668.710 ? 13.124  ops/s
JmxBenchmark.queryMBeansForMyObjectName  1000  thrpt   10  123.381 ?  4.254  ops/s
JmxBenchmark.queryMBeansForObjectName    1000  thrpt   10  237.607 ?  3.298  ops/s
JmxBenchmark.queryNamesForMyObjectName   1000  thrpt   10  122.576 ?  2.364  ops/s
JmxBenchmark.queryNamesForObjectName     1000  thrpt   10  238.275 ?  4.904  ops/s


JmxBenchmark.applyForMyObjectName - tests ObjectName.apply() for subclasses of ObjcetName instances
JmxBenchmark.applyForObjectName - tests ObjectName.apply() for ObjectName instances
JmxBenchmark.queryMBeansForMyObjectName - tests MBeanServer.queryMBeans() for subclasses of ObjcetName instances
JmxBenchmark.queryMBeansForObjectName - tests MBeanServer.queryMBeans() for ObjcetName instances
JmxBenchmark.queryNamesForMyObjectName - tests MBeanServer.queryNames() for subclasses of ObjcetName instances
JmxBenchmark.queryNamesForObjectName - tests MBeanServer.queryNames() for ObjcetName instances

JmxBenchmark is attached to the https://bugs.openjdk.org/browse/JDK-8299234

@sspitsyn, Could you please look at the proposed enhancement

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

PR: https://git.openjdk.org/jdk/pull/11758

From aivanov at openjdk.org  Thu Feb  2 14:09:36 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Feb 2023 14:09:36 GMT
Subject: RFR: 8301659: Resolve initialization reordering issues on Windows
 for libawt and libsaproc
In-Reply-To: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
References: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
Message-ID: <Sa1gLIhTRLVWgm6lakg3UvYAg8PX-CTEKW6jzqN9GQg=.06fde780-2127-47cd-8d4b-d1926e9b059c@github.com>

On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Small, trivial change to resolve initialization order reordering in constructors, required for [JDK-8301659](https://bugs.openjdk.org/browse/JDK-8301659)

Looks good to me.

David's comment sheds some light on why it's needed. I will appreciate if you add more details though.

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

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12382

From aivanov at openjdk.org  Thu Feb  2 14:09:38 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Feb 2023 14:09:38 GMT
Subject: RFR: 8301659: Resolve initialization reordering issues on Windows
 for libawt and libsaproc
In-Reply-To: <AzWzL8X2e1ARIp9ViZQwHImDyROCQfbPh99l8Gi4otU=.0263bbd4-bca4-4df2-acf2-f36def422430@github.com>
References: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
 <AzWzL8X2e1ARIp9ViZQwHImDyROCQfbPh99l8Gi4otU=.0263bbd4-bca4-4df2-acf2-f36def422430@github.com>
Message-ID: <XrwA3Xmm0rplAkGF8OIl0DDaHkPf86Su7ZgbdmeUgrQ=.53f3f983-668a-4bee-9004-fb2abb9a6471@github.com>

On Thu, 2 Feb 2023 12:12:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Could we say in the bug exactly when this is an issue (maybe it's a certain compiler?), and include a copy of the error or warning that is seen?

Yes, I agree. The change is simple enough yet there are no details why it's needed.

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

PR: https://git.openjdk.org/jdk/pull/12382

From lmesnik at openjdk.org  Thu Feb  2 15:13:37 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 2 Feb 2023 15:13:37 GMT
Subject: Integrated: 8298979: Remove duplicated
 serviceability/jvmti/thread/GetAllThreads/allthr01/allthr01.java
In-Reply-To: <7N18GctUO6Kt5_VJe5lJBV-ga-jZv-z9vtnh99dKHZo=.390887cd-5af8-4a61-bd2c-b4b5f74353e8@github.com>
References: <7N18GctUO6Kt5_VJe5lJBV-ga-jZv-z9vtnh99dKHZo=.390887cd-5af8-4a61-bd2c-b4b5f74353e8@github.com>
Message-ID: <aRMh3nDD_Oql1YS95jWrQNr2NAs21p0tHCV1pjXmdWI=.bc542e5b-3d28-4724-9e86-7552a820f549@github.com>

On Fri, 27 Jan 2023 05:06:25 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> PR adds fix "8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is failing" to new test and remove duplication.
> 
> Test allthr002 ported as
> serviceability/jvmti/negative/GetAllThreadsNullTest/GetAllThreadsNullTest.java

This pull request has now been integrated.

Changeset: 2d50c7d4
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d50c7d477b4141d58ae4ad01c254cde03050373
Stats:     844 lines in 11 files changed: 34 ins; 785 del; 25 mod

8298979: Remove duplicated serviceability/jvmti/thread/GetAllThreads/allthr01/allthr01.java

Reviewed-by: sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/12240

From jwaters at openjdk.org  Thu Feb  2 15:17:29 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Feb 2023 15:17:29 GMT
Subject: RFR: 8301659: Resolve initialization reordering issues on Windows
 for libawt and libsaproc
In-Reply-To: <AzWzL8X2e1ARIp9ViZQwHImDyROCQfbPh99l8Gi4otU=.0263bbd4-bca4-4df2-acf2-f36def422430@github.com>
References: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
 <AzWzL8X2e1ARIp9ViZQwHImDyROCQfbPh99l8Gi4otU=.0263bbd4-bca4-4df2-acf2-f36def422430@github.com>
Message-ID: <lB3Mi8iJyWhrXB7XDBfE281RkA59eqJsnysMp617rn8=.0365956e-a05a-45a3-9d84-d8a19d305d53@github.com>

On Thu, 2 Feb 2023 12:12:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> (In the description you mean it is required for JDK-8288293.)

Ah, yes that was what I meant, sorry for the oversight

kevin and aivanov: When compiling for Windows with gcc instead of Visual C++, gcc will raise the following warnings
`m_nCounter is initialized before m_nDestroyPeriod [-Werror=reorder]` for libawt
`bytePtr is initialized before releaseMode [-Werror=reorder]` for libsaproc

(Note that the Windows JDK itself cannot yet be compiled with gcc, these errors were found on a local experimental branch)

Both will also get promoted to errors and cause build failures in debug or adhoc builds. All can be easily suppressed by disabling the reorder warning, but there isn't much of a reason to do so when you could easily fix the initializer list directly

Thanks for the heads up, will add more details to the main PR comment and the linked entry in JBS first

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

PR: https://git.openjdk.org/jdk/pull/12382

From jwaters at openjdk.org  Thu Feb  2 15:22:47 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Feb 2023 15:22:47 GMT
Subject: RFR: 8301659: Resolve initialization reordering issues on Windows
 for libawt and libsaproc
In-Reply-To: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
References: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
Message-ID: <8D8bf0czao126AMkWYxQVSA-mDR-DmOcGQuwY3sWCO0=.b89461d3-31e0-4bbc-a854-35eb732238f6@github.com>

On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Small, trivial change to resolve initialization order reordering in constructors, required for [JDK-8288293](https://bugs.openjdk.org/browse/JDK-8288293)
> 
> gcc will fail to compile a Windows JDK with the following errors, which causes a build failure eventually:
> `GDIHashtable.cpp: m_nCounter is initialized before m_nDestroyPeriod [-Werror=reorder]` for libawt
> `sawindbg.cpp: bytePtr is initialized before releaseMode [-Werror=reorder]` for libsaproc
> 
> Reordering these initializer lists to appear in the order of their declarations will resolve the build failure

Thanks David and aivanov for the reviews

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

PR: https://git.openjdk.org/jdk/pull/12382

From jwaters at openjdk.org  Thu Feb  2 15:25:41 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Feb 2023 15:25:41 GMT
Subject: Integrated: 8301659: Resolve initialization reordering issues on
 Windows for libawt and libsaproc
In-Reply-To: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
References: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
Message-ID: <xklgJrsjRNAroKzwiPD-4gXAm0b2Rlr_rwlEgqDer3c=.deccbf60-dd1e-43cc-9374-eada1919f4e9@github.com>

On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Small, trivial change to resolve initialization order reordering in constructors, required for [JDK-8288293](https://bugs.openjdk.org/browse/JDK-8288293)
> 
> gcc will fail to compile a Windows JDK with the following errors, which causes a build failure eventually:
> `GDIHashtable.cpp: m_nCounter is initialized before m_nDestroyPeriod [-Werror=reorder]` for libawt
> `sawindbg.cpp: bytePtr is initialized before releaseMode [-Werror=reorder]` for libsaproc
> 
> Reordering these initializer lists to appear in the order of their declarations will resolve the build failure

This pull request has now been integrated.

Changeset: 725d57b2
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/725d57b2e2b78c1536d8a4adae67b27a2c8aee21
Stats:     5 lines in 2 files changed: 2 ins; 1 del; 2 mod

8301659: Resolve initialization reordering issues on Windows for libawt and libsaproc

Reviewed-by: dholmes, aivanov

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

PR: https://git.openjdk.org/jdk/pull/12382

From kevinw at openjdk.org  Thu Feb  2 16:20:01 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 2 Feb 2023 16:20:01 GMT
Subject: RFR: 8301659: Resolve initialization reordering issues on Windows
 for libawt and libsaproc
In-Reply-To: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
References: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
Message-ID: <MHx-lBRP_VZQVnin8JvUWPlQbLJQ7Vd9dfOMYtJ2m6E=.133dbb92-3381-4395-8480-39f76cda4372@github.com>

On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Small, trivial change to resolve initialization order reordering in constructors, required for [JDK-8288293](https://bugs.openjdk.org/browse/JDK-8288293)
> 
> gcc will fail to compile a Windows JDK with the following errors, which causes a build failure eventually:
> `GDIHashtable.cpp: m_nCounter is initialized before m_nDestroyPeriod [-Werror=reorder]` for libawt
> `sawindbg.cpp: bytePtr is initialized before releaseMode [-Werror=reorder]` for libsaproc
> 
> Reordering these initializer lists to appear in the order of their declarations will resolve the build failure

Thanks for filling in the details 8-)

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

PR: https://git.openjdk.org/jdk/pull/12382

From cjplummer at openjdk.org  Thu Feb  2 17:01:40 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 Feb 2023 17:01:40 GMT
Subject: Integrated: 8301644: com/sun/jdi/JdbStopThreadTest.java fails after
 JDK-8300811
In-Reply-To: <lJSRRFuBzSVqIlDfhW10tzNEBt_rlMq09EcqKeuMu5w=.80705af7-7c31-4c12-9eff-09180a4f1bfc@github.com>
References: <lJSRRFuBzSVqIlDfhW10tzNEBt_rlMq09EcqKeuMu5w=.80705af7-7c31-4c12-9eff-09180a4f1bfc@github.com>
Message-ID: <qIuXGkRMhQaSARBDwl4kQIsyNjoLF8KP_uRTg90Vwso=.29b733db-d910-4314-b185-2b7e164bf5c9@github.com>

On Wed, 1 Feb 2023 23:51:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test started failing after [JDK-8300811](https://bugs.openjdk.org/browse/JDK-8300811), which made the jdb ThreadStartRequest and ThreadDeathRequest use SUSPEND_NONE instead of SUSPEND_ALL. This sped up the handling of these events a lot, which has impacted the timing of this test and exposed a bug.
> 
> The 2nd (last) breakpoint this test sets up uses SUSPEND_NONE. The debuggee quickly exits after hitting the breakpoint because it is not suspended. This puts the test at risk of having the debuggee exit before jdb can produce the full output for the breakpoint that includes the line number information. The test is looking for this output When it is not there, the test fails. Although the risk was always there, it was made worse by speeding up the handling of the ThreadDeath event. This is why this issue is also only seen on product builds (jdb needs to be running fast).
> 
> This failure is somewhat noisy so I'd like to push it quickly, but it should still have two reviews.

This pull request has now been integrated.

Changeset: de577332
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de5773325d15ebefde80cb1bef734c50343958b8
Stats:     8 lines in 1 file changed: 6 ins; 0 del; 2 mod

8301644: com/sun/jdi/JdbStopThreadTest.java fails after JDK-8300811

Reviewed-by: amenkov, kevinw

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

PR: https://git.openjdk.org/jdk/pull/12378

From cjplummer at openjdk.org  Thu Feb  2 17:01:40 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 Feb 2023 17:01:40 GMT
Subject: RFR: 8301644: com/sun/jdi/JdbStopThreadTest.java fails after
 JDK-8300811
In-Reply-To: <lJSRRFuBzSVqIlDfhW10tzNEBt_rlMq09EcqKeuMu5w=.80705af7-7c31-4c12-9eff-09180a4f1bfc@github.com>
References: <lJSRRFuBzSVqIlDfhW10tzNEBt_rlMq09EcqKeuMu5w=.80705af7-7c31-4c12-9eff-09180a4f1bfc@github.com>
Message-ID: <aqy7HY88iw2PvSARZQTSonNrLQ83Ih6w9tca1O9E800=.9f5c6b0b-336f-4053-a49e-4fe701595a45@github.com>

On Wed, 1 Feb 2023 23:51:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test started failing after [JDK-8300811](https://bugs.openjdk.org/browse/JDK-8300811), which made the jdb ThreadStartRequest and ThreadDeathRequest use SUSPEND_NONE instead of SUSPEND_ALL. This sped up the handling of these events a lot, which has impacted the timing of this test and exposed a bug.
> 
> The 2nd (last) breakpoint this test sets up uses SUSPEND_NONE. The debuggee quickly exits after hitting the breakpoint because it is not suspended. This puts the test at risk of having the debuggee exit before jdb can produce the full output for the breakpoint that includes the line number information. The test is looking for this output When it is not there, the test fails. Although the risk was always there, it was made worse by speeding up the handling of the ThreadDeath event. This is why this issue is also only seen on product builds (jdb needs to be running fast).
> 
> This failure is somewhat noisy so I'd like to push it quickly, but it should still have two reviews.

Thanks for the reviews Alex and Kevin!

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

PR: https://git.openjdk.org/jdk/pull/12378

From dcubed at openjdk.org  Thu Feb  2 17:35:30 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 2 Feb 2023 17:35:30 GMT
Subject: RFR: 8300811: jdb ThreadStartRequest and ThreadDeathRequest should
 use SUSPEND_NONE instead of SUSPEND_ALL
In-Reply-To: <eTTDNcnt4FN8_tIcbNCjhoPoqbP-RIPOox3frGETA3s=.ac85c211-c8e4-42f8-aafa-4cb993bb35e1@github.com>
References: <eTTDNcnt4FN8_tIcbNCjhoPoqbP-RIPOox3frGETA3s=.ac85c211-c8e4-42f8-aafa-4cb993bb35e1@github.com>
Message-ID: <kisCdX8zuqtXNkekiaIkIx4MvM0G5YmTt-uvSWYfI3A=.28660a9c-44e5-44c4-b290-dcbdc994e000@github.com>

On Mon, 23 Jan 2023 21:02:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> jdb creates a ThreadStartRequest and ThreadDeathRequest so it can track all created threads. It creates them with the SUSPEND_ALL policy. This is unnecessary since jdb always immediately resumes all threads after doing the thread bookkeeping. There is no interaction with the jdb user like there would be with something like a Breakpoint event, and therefore no reason to suspend.
> 
> I was debugging an app that does nothing except create threads and allow them to quickly exit. Changing the policy to SUSPEND_NONE sped up the execution of the app by about 100x (that's 100 times faster, not 100%)

This PR does not document the type of pre-integration testing that was done
on these changes. We're seeing intermittent test failures in Mach5 Tier3 with
'release' bits:

[JDK-8301644](https://bugs.openjdk.org/browse/JDK-8301644) com/sun/jdi/JdbStopThreadTest.java fails after JDK-8300811

@plummercj fixed JDK-8301644 a short while ago so any failures with
com/sun/jdi/JdbStopThreadTest.java should subside.

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

PR: https://git.openjdk.org/jdk/pull/12152

From dcubed at openjdk.org  Thu Feb  2 17:45:34 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 2 Feb 2023 17:45:34 GMT
Subject: RFR: 8300811: jdb ThreadStartRequest and ThreadDeathRequest should
 use SUSPEND_NONE instead of SUSPEND_ALL
In-Reply-To: <eTTDNcnt4FN8_tIcbNCjhoPoqbP-RIPOox3frGETA3s=.ac85c211-c8e4-42f8-aafa-4cb993bb35e1@github.com>
References: <eTTDNcnt4FN8_tIcbNCjhoPoqbP-RIPOox3frGETA3s=.ac85c211-c8e4-42f8-aafa-4cb993bb35e1@github.com>
Message-ID: <Afvc0yqT5K8rLrEFTzgugLkSrLMbEX52yJQrD0nLklo=.eafe03de-479b-4d58-9685-e453a6edcfa2@github.com>

On Mon, 23 Jan 2023 21:02:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> jdb creates a ThreadStartRequest and ThreadDeathRequest so it can track all created threads. It creates them with the SUSPEND_ALL policy. This is unnecessary since jdb always immediately resumes all threads after doing the thread bookkeeping. There is no interaction with the jdb user like there would be with something like a Breakpoint event, and therefore no reason to suspend.
> 
> I was debugging an app that does nothing except create threads and allow them to quickly exit. Changing the policy to SUSPEND_NONE sped up the execution of the app by about 100x (that's 100 times faster, not 100%)

Also, I think this fix is going to do a great job of "shaking the trees" and will
reveal some tests that were passing by accident. I'm looking forward to next
week when I roll from JDK20 Stress Kit testing to JDK21 Stress Kit testing!

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

PR: https://git.openjdk.org/jdk/pull/12152

From cjplummer at openjdk.org  Thu Feb  2 17:57:34 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 Feb 2023 17:57:34 GMT
Subject: RFR: 8300811: jdb ThreadStartRequest and ThreadDeathRequest should
 use SUSPEND_NONE instead of SUSPEND_ALL
In-Reply-To: <kisCdX8zuqtXNkekiaIkIx4MvM0G5YmTt-uvSWYfI3A=.28660a9c-44e5-44c4-b290-dcbdc994e000@github.com>
References: <eTTDNcnt4FN8_tIcbNCjhoPoqbP-RIPOox3frGETA3s=.ac85c211-c8e4-42f8-aafa-4cb993bb35e1@github.com>
 <kisCdX8zuqtXNkekiaIkIx4MvM0G5YmTt-uvSWYfI3A=.28660a9c-44e5-44c4-b290-dcbdc994e000@github.com>
Message-ID: <Alh_u9ddfEbP2iBZFtsKDa9T040XAOc137XjMh5eKhw=.2e183114-d0e6-4ba9-8c07-1243eb8a28e6@github.com>

On Thu, 2 Feb 2023 17:32:15 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This PR does not document the type of pre-integration testing that was done
on these changes. We're seeing intermittent test failures in Mach5 Tier3 with

I ran all com/sun/jdi, nsk/jdb, nsk/jdi, and nsk/jdwp tests on all supported hosts multiple times, and ran tier1. What I didn't test were product builds, which is where the failures seem to be prevalent.

> Also, I think this fix is going to do a great job of "shaking the trees" and will reveal some tests that were passing by accident.

Yes, the tests that use jdb have always been sensitive to timing issues. Many fixes have been put in place in the past and the tests have been pretty stable for a while now.

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

PR: https://git.openjdk.org/jdk/pull/12152

From cjplummer at openjdk.org  Thu Feb  2 18:43:26 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 Feb 2023 18:43:26 GMT
Subject: RFR: 8228604: StackMapFrames are missing from redefined class
 bytes of retransformed classes [v3]
In-Reply-To: <MSIcChNDDD404MpUfKu1g6PAe64NtYkvY-6OkRtoIT0=.7963ac00-e469-43d7-8142-97f076e04740@github.com>
References: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
 <MSIcChNDDD404MpUfKu1g6PAe64NtYkvY-6OkRtoIT0=.7963ac00-e469-43d7-8142-97f076e04740@github.com>
Message-ID: <JRsUlYqN6nC3NJRoFBw255-9NjQjTsnNtuRGdy5wb3E=.ba5558e5-2add-41f4-8bfe-de53db7111a3@github.com>

On Thu, 2 Feb 2023 00:17:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> classFileParser drops stack map frames for JDK classes (when verification is not required).
>> As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition.
>> Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS.
>> This code is old (from "initial load") and I don't understand the reason it was implemented this way.
>> 
>> Testing: tier1-tier6
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated test - addressed review comments

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/MissedStackMapFrames.java line 103:

> 101:                                        + " (expected " + expectedCount + ")");
> 102:         }
> 103:     }

You added this method but are not using it. I think below the first call to checkStackMapFrames() needs to save the frameCount returned and then pass it in to the second call to checkStackMapFrames().

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

PR: https://git.openjdk.org/jdk/pull/12155

From amenkov at openjdk.org  Thu Feb  2 19:08:49 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 2 Feb 2023 19:08:49 GMT
Subject: RFR: 8228604: StackMapFrames are missing from redefined class
 bytes of retransformed classes [v4]
In-Reply-To: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
References: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
Message-ID: <W-G_bEXaEzrhQFXDubMand8hMAZrGOblsRrSmT4qXgA=.48e07f3e-f9db-4be1-9ec5-17f8031f4a75@github.com>

> classFileParser drops stack map frames for JDK classes (when verification is not required).
> As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition.
> Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS.
> This code is old (from "initial load") and I don't understand the reason it was implemented this way.
> 
> Testing: tier1-tier6

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

  updated test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12155/files
  - new: https://git.openjdk.org/jdk/pull/12155/files/3ff8a90e..8dc60403

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12155&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12155&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/12155

From cjplummer at openjdk.org  Thu Feb  2 19:13:26 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 Feb 2023 19:13:26 GMT
Subject: RFR: 8228604: StackMapFrames are missing from redefined class
 bytes of retransformed classes [v4]
In-Reply-To: <W-G_bEXaEzrhQFXDubMand8hMAZrGOblsRrSmT4qXgA=.48e07f3e-f9db-4be1-9ec5-17f8031f4a75@github.com>
References: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
 <W-G_bEXaEzrhQFXDubMand8hMAZrGOblsRrSmT4qXgA=.48e07f3e-f9db-4be1-9ec5-17f8031f4a75@github.com>
Message-ID: <AaaFeWma5sCMFDkIlAQuRLQMRikGQ0f8DOzs-C9YZqE=.b942fd21-a8e6-4689-8c6a-d6fc9b38107a@github.com>

On Thu, 2 Feb 2023 19:08:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> classFileParser drops stack map frames for JDK classes (when verification is not required).
>> As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition.
>> Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS.
>> This code is old (from "initial load") and I don't understand the reason it was implemented this way.
>> 
>> Testing: tier1-tier6
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated test

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12155

From cjplummer at openjdk.org  Fri Feb  3 19:08:43 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 3 Feb 2023 19:08:43 GMT
Subject: RFR: 8301798: [BACKOUT] jdb ThreadStartRequest and ThreadDeathRequest
 should use SUSPEND_NONE instead of SUSPEND_ALL
Message-ID: <yr_czRMTLsE5JF9IjYko5Dvpl8b787a728OQofNH6A8=.040f3731-0d41-4e99-bab4-0c00b1b021d2@github.com>

Backing out the following due to numerous failing tests. There will be no redo. The original change was an enhancement, not a bug fix.

[JDK-8300811](https://bugs.openjdk.org/browse/JDK-8300811) jdb ThreadStartRequest and ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL

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

Commit messages:
 - Revert "8300811: jdb ThreadStartRequest and ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL"

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

PR: https://git.openjdk.org/jdk/pull/12416

From dcubed at openjdk.org  Fri Feb  3 19:36:52 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 3 Feb 2023 19:36:52 GMT
Subject: RFR: 8301798: [BACKOUT] jdb ThreadStartRequest and
 ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL
In-Reply-To: <yr_czRMTLsE5JF9IjYko5Dvpl8b787a728OQofNH6A8=.040f3731-0d41-4e99-bab4-0c00b1b021d2@github.com>
References: <yr_czRMTLsE5JF9IjYko5Dvpl8b787a728OQofNH6A8=.040f3731-0d41-4e99-bab4-0c00b1b021d2@github.com>
Message-ID: <9XqwfBWP8Cb7t7AFjH32RdMURAyaloTiOlQSZr3TMQE=.23af7093-8eb3-437f-b3bb-5e723f373f29@github.com>

On Fri, 3 Feb 2023 18:56:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Backing out the following due to numerous failing tests. There will be no redo. The original change was an enhancement, not a bug fix.
> 
> [JDK-8300811](https://bugs.openjdk.org/browse/JDK-8300811) jdb ThreadStartRequest and ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL

This looks like a clean [BACKOUT] to me. So thumbs up and it looks trivial.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12416

From dholmes at openjdk.org  Fri Feb  3 21:23:52 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Feb 2023 21:23:52 GMT
Subject: RFR: 8301798: [BACKOUT] jdb ThreadStartRequest and
 ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL
In-Reply-To: <yr_czRMTLsE5JF9IjYko5Dvpl8b787a728OQofNH6A8=.040f3731-0d41-4e99-bab4-0c00b1b021d2@github.com>
References: <yr_czRMTLsE5JF9IjYko5Dvpl8b787a728OQofNH6A8=.040f3731-0d41-4e99-bab4-0c00b1b021d2@github.com>
Message-ID: <QsfLu9o6B3A1xS283U-F569K_qa8H0Znzh-0na-_EGs=.8fd9358e-b5f9-473f-b0af-8b08268702fa@github.com>

On Fri, 3 Feb 2023 18:56:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Backing out the following due to numerous failing tests. There will be no redo. The original change was an enhancement, not a bug fix.
> 
> [JDK-8300811](https://bugs.openjdk.org/browse/JDK-8300811) jdb ThreadStartRequest and ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL

Looks good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12416

From dholmes at openjdk.org  Fri Feb  3 21:26:52 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Feb 2023 21:26:52 GMT
Subject: RFR: 8301798: [BACKOUT] jdb ThreadStartRequest and
 ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL
In-Reply-To: <yr_czRMTLsE5JF9IjYko5Dvpl8b787a728OQofNH6A8=.040f3731-0d41-4e99-bab4-0c00b1b021d2@github.com>
References: <yr_czRMTLsE5JF9IjYko5Dvpl8b787a728OQofNH6A8=.040f3731-0d41-4e99-bab4-0c00b1b021d2@github.com>
Message-ID: <bpxe2cgK4HJQju_D1Au4w0dEveHbSB0cvz7EH_DkjWM=.d2a0d638-e9bb-4764-a2f8-3ea3cdc2b554@github.com>

On Fri, 3 Feb 2023 18:56:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Backing out the following due to numerous failing tests. There will be no redo. The original change was an enhancement, not a bug fix.
> 
> [JDK-8300811](https://bugs.openjdk.org/browse/JDK-8300811) jdb ThreadStartRequest and ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL

@plummercj  I don't think this PR should list all the test failure issues. While it is true that the backout will "fix" those failures, I don't think that is the intended use of the mechanism. What do you think @dcubed-ojdk ?

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

PR: https://git.openjdk.org/jdk/pull/12416

From cjplummer at openjdk.org  Fri Feb  3 21:30:50 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 3 Feb 2023 21:30:50 GMT
Subject: RFR: 8301798: [BACKOUT] jdb ThreadStartRequest and
 ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL
In-Reply-To: <yr_czRMTLsE5JF9IjYko5Dvpl8b787a728OQofNH6A8=.040f3731-0d41-4e99-bab4-0c00b1b021d2@github.com>
References: <yr_czRMTLsE5JF9IjYko5Dvpl8b787a728OQofNH6A8=.040f3731-0d41-4e99-bab4-0c00b1b021d2@github.com>
Message-ID: <WSWXrtw1RADf-HhmCSa6SVWytoaGybJQGNl5F3poyNM=.1c0e5323-4b87-4c10-a3cf-1212ab778a73@github.com>

On Fri, 3 Feb 2023 18:56:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Backing out the following due to numerous failing tests. There will be no redo. The original change was an enhancement, not a bug fix.
> 
> [JDK-8300811](https://bugs.openjdk.org/browse/JDK-8300811) jdb ThreadStartRequest and ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL

Should I close thos issues as dups of the backup issue?

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

PR: https://git.openjdk.org/jdk/pull/12416

From cjplummer at openjdk.org  Fri Feb  3 21:48:37 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 3 Feb 2023 21:48:37 GMT
Subject: RFR: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails
Message-ID: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>

A number of tests that use JDI invokeMethod() support occasionally fail when run using virtual threads. The tests fail with:


# ERROR: TEST FAILED: wrong invocation:
# ERROR: invoking debuggee thread instance of java.lang.VirtualThread(name='invokemethod010tThr', id=272)
# ERROR: is not suspended again after the invocation 


Although as explained later, this is a misleading message, and does not accurately reflect why the test is failing. More on that below.

The root cause of the failure is due to these tests using JDI invokeMethod support with the  INVOKE_SINGLE_THREADED flag. This is not always going to work with virtual threads because the invoked method is doing a Thread.sleep(400), and that is at risk of blocking indefinitely if all other threads are blocked form making progress. Note that technically platform threads could fail in the same manner. However, the reason the failure only happens now with virtual threads is because the implementation of Thread.sleep() differs for virtual threads, and may require ownership of a monitor that sometimes is held by another thread.

Another issue is that the tests do not do a very good job of error handling when this happens, and give the misleading failure reason of the invoked thread not being suspended after the invoke completed. The reason it is not suspended is because the invoke has actually not completed. There was a timeout that the test did not properly note as the cause of the failure. The test (debugger side) spawns a thread to do the JDI invokeMethod with, and then waits for it with:

                invThr.join(argHandler.getWaitTime()*60000);

This join() times out, but the test assumes once it returns the invoke is complete, even though the invoked thread is actually still in the middle of the invoke. So that is the reason debuggee invokemethod thread is not currently suspended. I've fixed this by having a test check if invThr is still alive after the join. If it is, then the test is made to fail at that point, rather than continuing on and checking the debuggee threads status. The failure then becomes:

nsk.share.TestFailure: TEST FAILED: invoke never completed

At that point a vm.resume() is done to allow the invoke to complete, and the test will exit with this failure.

As for avoiding the failure in the first place (the deadlock in the debuggee during the invoke), this is really a test bug for relying on INVOKE_SINGLE_THREADED and assuming that the invoked thread won't become deadlocked. Since there is a Thread.sleep() call in the invoked method, it can't make this assumption. From the ObjectReference.invoke() spec:

"By default, all threads in the target VM are resumed while the method is being invoked if they were previously suspended by an event or by VirtualMachine.suspend() or ThreadReference.suspend(). This is done to prevent the deadlocks that will occur if any of the threads own monitors that will be needed by the invoked method."

"The resumption of other threads during the invocation can be prevented by specifying the INVOKE_SINGLE_THREADED bit flag in the options argument; however, there is no protection against or recovery from the deadlocks described above, so this option should be used with great caution."

For platform threads, sleep() doesn't require any monitors, so these tests never ran into problems before. For virtual threads however there is some synchronization done, and potential reliance on other threads not being suspended. A way around this is to always use sleep(0), which will at least attempt to yield the thread. For platform threads an actual yield is likely. For a virtual thread it will not yield in this particular case because the virtual thread is pinned to the carrier thread due to the jvmti breakpoint callback that is currently in the call chain of the invoked thread. So for virtual threads this effectively the same as sitting in a spin loop with no yielding. This is ok. CPU wasting is not a concern.

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

Commit messages:
 - Remove invokemethod011 from problem list.
 - Fix invokemethod tests that can fail when using INVOKE_SINGLE_THREADED.
 - Fix invokemethod tests that can fail when using INVOKE_SINGLE_THREADED.

Changes: https://git.openjdk.org/jdk/pull/12420/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12420&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8282379
  Stats: 89 lines in 15 files changed: 66 ins; 2 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/12420.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12420/head:pull/12420

PR: https://git.openjdk.org/jdk/pull/12420

From dcubed at openjdk.org  Fri Feb  3 21:56:49 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 3 Feb 2023 21:56:49 GMT
Subject: RFR: 8301798: [BACKOUT] jdb ThreadStartRequest and
 ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL
In-Reply-To: <yr_czRMTLsE5JF9IjYko5Dvpl8b787a728OQofNH6A8=.040f3731-0d41-4e99-bab4-0c00b1b021d2@github.com>
References: <yr_czRMTLsE5JF9IjYko5Dvpl8b787a728OQofNH6A8=.040f3731-0d41-4e99-bab4-0c00b1b021d2@github.com>
Message-ID: <JCyWHvlvaFNH-E2KDw6OXbCLuTyX1Q37yFK_rNu_lj4=.d4fc642c-9de0-41ef-85ca-ae508ef46fcc@github.com>

On Fri, 3 Feb 2023 18:56:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Backing out the following due to numerous failing tests. There will be no redo. The original change was an enhancement, not a bug fix.
> 
> [JDK-8300811](https://bugs.openjdk.org/browse/JDK-8300811) jdb ThreadStartRequest and ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL

I would be fine with either mechanism. I think closing the test failure bugs as
dups is the more typical usage model.

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

PR: https://git.openjdk.org/jdk/pull/12416

From cjplummer at openjdk.org  Fri Feb  3 22:25:58 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 3 Feb 2023 22:25:58 GMT
Subject: RFR: 8301798: [BACKOUT] jdb ThreadStartRequest and
 ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL
In-Reply-To: <yr_czRMTLsE5JF9IjYko5Dvpl8b787a728OQofNH6A8=.040f3731-0d41-4e99-bab4-0c00b1b021d2@github.com>
References: <yr_czRMTLsE5JF9IjYko5Dvpl8b787a728OQofNH6A8=.040f3731-0d41-4e99-bab4-0c00b1b021d2@github.com>
Message-ID: <rh-rWudJKK-q4X05pwql9fybar0hzZ0X-5HRoFLIoag=.609a9f84-3566-4ccb-87be-07e4675e1a8e@github.com>

On Fri, 3 Feb 2023 18:56:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Backing out the following due to numerous failing tests. There will be no redo. The original change was an enhancement, not a bug fix.
> 
> [JDK-8300811](https://bugs.openjdk.org/browse/JDK-8300811) jdb ThreadStartRequest and ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL
> 
> Tested with 100 runs of com/sun/jdi on macosx-x64 (product build) which is where almost all of the failures were reported. Also did a full tier3 mach5 run.

Thanks for the reviews David and Dan!

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

PR: https://git.openjdk.org/jdk/pull/12416

From cjplummer at openjdk.org  Fri Feb  3 22:25:59 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 3 Feb 2023 22:25:59 GMT
Subject: Integrated: 8301798: [BACKOUT] jdb ThreadStartRequest and
 ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL
In-Reply-To: <yr_czRMTLsE5JF9IjYko5Dvpl8b787a728OQofNH6A8=.040f3731-0d41-4e99-bab4-0c00b1b021d2@github.com>
References: <yr_czRMTLsE5JF9IjYko5Dvpl8b787a728OQofNH6A8=.040f3731-0d41-4e99-bab4-0c00b1b021d2@github.com>
Message-ID: <8oCG218fB-NqpENEoVZSkaQSv_nyGLCbINMVpmsKrA8=.bff4533b-74cc-4bc7-b5a9-47724e5e5cf0@github.com>

On Fri, 3 Feb 2023 18:56:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Backing out the following due to numerous failing tests. There will be no redo. The original change was an enhancement, not a bug fix.
> 
> [JDK-8300811](https://bugs.openjdk.org/browse/JDK-8300811) jdb ThreadStartRequest and ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL
> 
> Tested with 100 runs of com/sun/jdi on macosx-x64 (product build) which is where almost all of the failures were reported. Also did a full tier3 mach5 run.

This pull request has now been integrated.

Changeset: 3be5317b
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3be5317b592f1bda76aea5fbcbb98c6fa633401c
Stats:     4 lines in 1 file changed: 0 ins; 3 del; 1 mod

8301798: [BACKOUT] jdb ThreadStartRequest and ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL

Reviewed-by: dcubed, dholmes

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

PR: https://git.openjdk.org/jdk/pull/12416

From dholmes at openjdk.org  Mon Feb  6 00:37:48 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Feb 2023 00:37:48 GMT
Subject: RFR: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails
In-Reply-To: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
References: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
Message-ID: <YIs6297gy2NhObUOw3ywpSIXY9tUCO6XU6raoNSjsEU=.0acc32d5-abd5-496d-bcdf-df7d40d81fb0@github.com>

On Fri, 3 Feb 2023 21:40:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> A number of tests that use JDI invokeMethod() support occasionally fail when run using virtual threads. The tests fail with:
> 
> 
> # ERROR: TEST FAILED: wrong invocation:
> # ERROR: invoking debuggee thread instance of java.lang.VirtualThread(name='invokemethod010tThr', id=272)
> # ERROR: is not suspended again after the invocation 
> 
> 
> Although as explained later, this is a misleading message, and does not accurately reflect why the test is failing. More on that below.
> 
> The root cause of the failure is due to these tests using JDI invokeMethod support with the  INVOKE_SINGLE_THREADED flag. This is not always going to work with virtual threads because the invoked method is doing a Thread.sleep(400), and that is at risk of blocking indefinitely if all other threads are blocked form making progress. Note that technically platform threads could fail in the same manner. However, the reason the failure only happens now with virtual threads is because the implementation of Thread.sleep() differs for virtual threads, and may require ownership of a monitor that sometimes is held by another thread.
> 
> Another issue is that the tests do not do a very good job of error handling when this happens, and give the misleading failure reason of the invoked thread not being suspended after the invoke completed. The reason it is not suspended is because the invoke has actually not completed. There was a timeout that the test did not properly note as the cause of the failure. The test (debugger side) spawns a thread to do the JDI invokeMethod with, and then waits for it with:
> 
>                 invThr.join(argHandler.getWaitTime()*60000);
> 
> This join() times out, but the test assumes once it returns the invoke is complete, even though the invoked thread is actually still in the middle of the invoke. So that is the reason debuggee invokemethod thread is not currently suspended. I've fixed this by having a test check if invThr is still alive after the join. If it is, then the test is made to fail at that point, rather than continuing on and checking the debuggee threads status. The failure then becomes:
> 
> nsk.share.TestFailure: TEST FAILED: invoke never completed
> 
> At that point a vm.resume() is done to allow the invoke to complete, and the test will exit with this failure.
> 
> As for avoiding the failure in the first place (the deadlock in the debuggee during the invoke), this is really a test bug for relying on INVOKE_SINGLE_THREADED and assuming that the invoked thread won't become deadlocked. Since there is a Thread.sleep() call in the invoked method, it can't make this assumption. From the ObjectReference.invoke() spec:
> 
> "By default, all threads in the target VM are resumed while the method is being invoked if they were previously suspended by an event or by VirtualMachine.suspend() or ThreadReference.suspend(). This is done to prevent the deadlocks that will occur if any of the threads own monitors that will be needed by the invoked method."
> 
> "The resumption of other threads during the invocation can be prevented by specifying the INVOKE_SINGLE_THREADED bit flag in the options argument; however, there is no protection against or recovery from the deadlocks described above, so this option should be used with great caution."
> 
> For platform threads, sleep() doesn't require any monitors, so these tests never ran into problems before. For virtual threads however there is some synchronization done, and potential reliance on other threads not being suspended. A way around this is to always use sleep(0), which will at least attempt to yield the thread. For platform threads an actual yield is likely. For a virtual thread it will not yield in this particular case because the virtual thread is pinned to the carrier thread due to the jvmti breakpoint callback that is currently in the call chain of the invoked thread. So for virtual threads this effectively the same as sitting in a spin loop with no yielding. This is ok. CPU wasting is not a concern.

Relying on `sleep(0)` to avoid the problem with virtual threads seems fragile - what if the action of that changes for VTs in the future? In any case the use of  `sleep(0)` needs to be documented so it doesn't get changed back, or converted to the logically equivalent `Thread.yield`.

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

PR: https://git.openjdk.org/jdk/pull/12420

From kevinw at openjdk.org  Mon Feb  6 14:55:23 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 6 Feb 2023 14:55:23 GMT
Subject: RFR: 8296646: com/sun/jdi/JdbLastErrorTest.java test failure
Message-ID: <JcLQhxM4bgBOXJMv3BW3-GFXYOcchUzoQ73IQuQwSa4=.b59a023f-30eb-47b0-ba51-dbdc3997b7ac@github.com>

This test fails sometimes with ZGC. It is testing using Panama to access Windows' last error value, and can of course be interrupted by VM work that changes the value, but it does generally work. Skipping the test with ZGC is reasonable as you don't really _have_ to step through this kind of Panama code with ZGC.

More rare is a failure where "The application exited" is not observed.  This test is not here to test the exit mode, and logging that failure avoids telling you whether the correct lastError value was seen.  Test should prioritise saying if the correct last error value was observed, and should check for the exception being thrown when the correct value is not seen.

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

Commit messages:
 - whitespace
 - 8296646: com/sun/jdi/JdbLastErrorTest.java test failure

Changes: https://git.openjdk.org/jdk/pull/12441/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12441&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296646
  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12441.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12441/head:pull/12441

PR: https://git.openjdk.org/jdk/pull/12441

From kevinw at openjdk.org  Mon Feb  6 17:34:52 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 6 Feb 2023 17:34:52 GMT
Subject: RFR: 8299739: HashedPasswordFileTest.java and ExceptionTest.java
 can fail with java.lang.NullPointerException
In-Reply-To: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
Message-ID: <KR_EOBTk8MwuALMQWC36f2gMZ8SE2APczad9Tx_Z_LU=.e30ae867-5e40-4770-ab50-650b2f430225@github.com>

On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
> But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
> We must only call close if this is not null.

Thanks Chris -
Actually yes the ExceptionTest failure is a little odd...

HashedPasswordFileTest more clearly doesn't show an Exception on the way to its finally clause that hits the NPE.

The CI failures where there's an NPE at ExceptionTest.java:126, do not include an earlier exception.  I see it would/should have been shown by the printThrowable at line 121.

Even looking at the full log, there is no earlier exception, so that is odd.   If cs is null, I don't see how there isn't an Exception at that point.  The newConnectorServer and JMXConnectorFactory.connect methods might give an IOException... but that should have been logged, so it's not clear how we get to that state.  (There are ExceptionTest failures in jdk11 and jdk19/panama, but they are the same test.)

There are other things that ExceptionTest should have printed if it had got a connection and made progress through the test, and we don't see them, so seems that we failed early on, probably at JMXConnectorFactory.connect(addr);

I checked and saw the printThrowable IS called if I make something get thrown in the test, and printThrowable IS being used to print the NPE in the failures, so those things do all work.

Having the NPE when we don't have a connection to close is still misleading, so I think we should check them for null.  If the connection failed with no Exception, it would hit a real NPE soon after which would be a useful message.  But I think more likely the connect does throw an Exception, but in those builds/runs it didn't get captured in the log for some unclear reason.  We should still fail correctly - if we are handling an Exception, even if our print was lost, we are throwing a RuntimeException, and with the finally block not throwing a new NPE, we should see that RuntimeException and have the test fail. 8-)

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

PR: https://git.openjdk.org/jdk/pull/11881

From cjplummer at openjdk.org  Mon Feb  6 19:04:50 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 6 Feb 2023 19:04:50 GMT
Subject: RFR: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails
In-Reply-To: <YIs6297gy2NhObUOw3ywpSIXY9tUCO6XU6raoNSjsEU=.0acc32d5-abd5-496d-bcdf-df7d40d81fb0@github.com>
References: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
 <YIs6297gy2NhObUOw3ywpSIXY9tUCO6XU6raoNSjsEU=.0acc32d5-abd5-496d-bcdf-df7d40d81fb0@github.com>
Message-ID: <qVQkbCSu9L3EJ-35mh2qABxQrgHUIdNanX9kwJ6-Z8Q=.33850ac4-12bd-4f56-9728-67854e29f52b@github.com>

On Mon, 6 Feb 2023 00:34:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Relying on `sleep(0)` to avoid the problem with virtual threads seems fragile - what if the action of that changes for VTs in the future? In any case the use of `sleep(0)` needs to be documented so it doesn't get changed back, or converted to the logically equivalent `Thread.yield`.

I could just remove the sleep(0) call altogether, or I could make the original sleep(400) call conditional on not being a virtual thread, although I don't like that solution so much. In either case is sounds like you want a comment. A more general one would simply state not to call anything that might block since other threads are suspended. Now that I think of it, it seems like the two display() calls could block since they do I/O, although the way this test is run it seems they never do. I bet if you had some other thread(s) doing display() calls at the same time, and one of them got suspended in the middle of the display, then you might see issues.

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

PR: https://git.openjdk.org/jdk/pull/12420

From cjplummer at openjdk.org  Mon Feb  6 20:05:52 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 6 Feb 2023 20:05:52 GMT
Subject: RFR: 8297638: Memory leak in case of many started-dead threads
 [v2]
In-Reply-To: <6A-Igi24IpuNPsjq1vJMscoKvujmMvYqDuMq6BncUsI=.9102a5c7-2f90-444c-b79a-00cb82b809bb@github.com>
References: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com>
 <6A-Igi24IpuNPsjq1vJMscoKvujmMvYqDuMq6BncUsI=.9102a5c7-2f90-444c-b79a-00cb82b809bb@github.com>
Message-ID: <NE5uFeQNbuemCTveNQU6K52UHKXg5GuA58PklzWn_EY=.255e12e1-8284-47f9-b74e-81d32a27aa09@github.com>

On Thu, 19 Jan 2023 21:59:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Fix JDI leak when the debuggee creates a lot of threads, while at the same the debugger is not sending any commands. The lack of commands being sent results in code not being triggered that normally would clear out unreachable listeners and also clear out ObjectReferences queued for disposal.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaned up removeUnreachableListeners().

Ping! I could use one more review. Thanks!

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

PR: https://git.openjdk.org/jdk/pull/12081

From cjplummer at openjdk.org  Mon Feb  6 21:57:11 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 6 Feb 2023 21:57:11 GMT
Subject: RFR: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails [v2]
In-Reply-To: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
References: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
Message-ID: <jPVFVRgngvBtyYqyVU8x8uzyKPezzhrmBmipa4QPw2M=.531d31e2-c1d9-4347-b712-811e70c3a974@github.com>

> A number of tests that use JDI invokeMethod() support occasionally fail when run using virtual threads. The tests fail with:
> 
> 
> # ERROR: TEST FAILED: wrong invocation:
> # ERROR: invoking debuggee thread instance of java.lang.VirtualThread(name='invokemethod010tThr', id=272)
> # ERROR: is not suspended again after the invocation 
> 
> 
> Although as explained later, this is a misleading message, and does not accurately reflect why the test is failing. More on that below.
> 
> The root cause of the failure is due to these tests using JDI invokeMethod support with the  INVOKE_SINGLE_THREADED flag. This is not always going to work with virtual threads because the invoked method is doing a Thread.sleep(400), and that is at risk of blocking indefinitely if all other threads are blocked form making progress. Note that technically platform threads could fail in the same manner. However, the reason the failure only happens now with virtual threads is because the implementation of Thread.sleep() differs for virtual threads, and may require ownership of a monitor that sometimes is held by another thread.
> 
> Another issue is that the tests do not do a very good job of error handling when this happens, and give the misleading failure reason of the invoked thread not being suspended after the invoke completed. The reason it is not suspended is because the invoke has actually not completed. There was a timeout that the test did not properly note as the cause of the failure. The test (debugger side) spawns a thread to do the JDI invokeMethod with, and then waits for it with:
> 
>                 invThr.join(argHandler.getWaitTime()*60000);
> 
> This join() times out, but the test assumes once it returns the invoke is complete, even though the invoked thread is actually still in the middle of the invoke. So that is the reason debuggee invokemethod thread is not currently suspended. I've fixed this by having a test check if invThr is still alive after the join. If it is, then the test is made to fail at that point, rather than continuing on and checking the debuggee threads status. The failure then becomes:
> 
> nsk.share.TestFailure: TEST FAILED: invoke never completed
> 
> At that point a vm.resume() is done to allow the invoke to complete, and the test will exit with this failure.
> 
> As for avoiding the failure in the first place (the deadlock in the debuggee during the invoke), this is really a test bug for relying on INVOKE_SINGLE_THREADED and assuming that the invoked thread won't become deadlocked. Since there is a Thread.sleep() call in the invoked method, it can't make this assumption. From the ObjectReference.invoke() spec:
> 
> "By default, all threads in the target VM are resumed while the method is being invoked if they were previously suspended by an event or by VirtualMachine.suspend() or ThreadReference.suspend(). This is done to prevent the deadlocks that will occur if any of the threads own monitors that will be needed by the invoked method."
> 
> "The resumption of other threads during the invocation can be prevented by specifying the INVOKE_SINGLE_THREADED bit flag in the options argument; however, there is no protection against or recovery from the deadlocks described above, so this option should be used with great caution."
> 
> For platform threads, sleep() doesn't require any monitors, so these tests never ran into problems before. For virtual threads however there is some synchronization done, and potential reliance on other threads not being suspended. A way around this is to always use sleep(0), which will at least attempt to yield the thread. For platform threads an actual yield is likely. For a virtual thread it will not yield in this particular case because the virtual thread is pinned to the carrier thread due to the jvmti breakpoint callback that is currently in the call chain of the invoked thread. So for virtual threads this effectively the same as sitting in a spin loop with no yielding. This is ok. CPU wasting is not a concern.

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

  Get rid of Thread.sleep() in the invoked method can add warning comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12420/files
  - new: https://git.openjdk.org/jdk/pull/12420/files/4b40bda1..c1bcaef5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12420&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12420&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12420

From cjplummer at openjdk.org  Mon Feb  6 21:57:13 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 6 Feb 2023 21:57:13 GMT
Subject: RFR: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails
In-Reply-To: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
References: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
Message-ID: <Vprn2jRPNbez8ZK4Hl2bjRGfsD1j0FtwRrmnKWby_L0=.cb2c56a1-fc77-4134-8a4d-e2f86da2376d@github.com>

On Fri, 3 Feb 2023 21:40:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> A number of tests that use JDI invokeMethod() support occasionally fail when run using virtual threads. The tests fail with:
> 
> 
> # ERROR: TEST FAILED: wrong invocation:
> # ERROR: invoking debuggee thread instance of java.lang.VirtualThread(name='invokemethod010tThr', id=272)
> # ERROR: is not suspended again after the invocation 
> 
> 
> Although as explained later, this is a misleading message, and does not accurately reflect why the test is failing. More on that below.
> 
> The root cause of the failure is due to these tests using JDI invokeMethod support with the  INVOKE_SINGLE_THREADED flag. This is not always going to work with virtual threads because the invoked method is doing a Thread.sleep(400), and that is at risk of blocking indefinitely if all other threads are blocked form making progress. Note that technically platform threads could fail in the same manner. However, the reason the failure only happens now with virtual threads is because the implementation of Thread.sleep() differs for virtual threads, and may require ownership of a monitor that sometimes is held by another thread.
> 
> Another issue is that the tests do not do a very good job of error handling when this happens, and give the misleading failure reason of the invoked thread not being suspended after the invoke completed. The reason it is not suspended is because the invoke has actually not completed. There was a timeout that the test did not properly note as the cause of the failure. The test (debugger side) spawns a thread to do the JDI invokeMethod with, and then waits for it with:
> 
>                 invThr.join(argHandler.getWaitTime()*60000);
> 
> This join() times out, but the test assumes once it returns the invoke is complete, even though the invoked thread is actually still in the middle of the invoke. So that is the reason debuggee invokemethod thread is not currently suspended. I've fixed this by having a test check if invThr is still alive after the join. If it is, then the test is made to fail at that point, rather than continuing on and checking the debuggee threads status. The failure then becomes:
> 
> nsk.share.TestFailure: TEST FAILED: invoke never completed
> 
> At that point a vm.resume() is done to allow the invoke to complete, and the test will exit with this failure.
> 
> As for avoiding the failure in the first place (the deadlock in the debuggee during the invoke), this is really a test bug for relying on INVOKE_SINGLE_THREADED and assuming that the invoked thread won't become deadlocked. Since there is a Thread.sleep() call in the invoked method, it can't make this assumption. From the ObjectReference.invoke() spec:
> 
> "By default, all threads in the target VM are resumed while the method is being invoked if they were previously suspended by an event or by VirtualMachine.suspend() or ThreadReference.suspend(). This is done to prevent the deadlocks that will occur if any of the threads own monitors that will be needed by the invoked method."
> 
> "The resumption of other threads during the invocation can be prevented by specifying the INVOKE_SINGLE_THREADED bit flag in the options argument; however, there is no protection against or recovery from the deadlocks described above, so this option should be used with great caution."
> 
> For platform threads, sleep() doesn't require any monitors, so these tests never ran into problems before. For virtual threads however there is some synchronization done, and potential reliance on other threads not being suspended. A way around this is to always use sleep(0), which will at least attempt to yield the thread. For platform threads an actual yield is likely. For a virtual thread it will not yield in this particular case because the virtual thread is pinned to the carrier thread due to the jvmti breakpoint callback that is currently in the call chain of the invoked thread. So for virtual threads this effectively the same as sitting in a spin loop with no yielding. This is ok. CPU wasting is not a concern.

I updated one of the tests to get rid of the sleep and added a comment. Let me know what you think. Once it's ok'd I'll apply the same change to the rest of the tests:

https://github.com/openjdk/jdk/pull/12420/commits/c1bcaef5952f8f95333c6481983b290b8bc9990d

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

PR: https://git.openjdk.org/jdk/pull/12420

From sspitsyn at openjdk.org  Mon Feb  6 23:32:46 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 6 Feb 2023 23:32:46 GMT
Subject: RFR: 8228604: StackMapFrames are missing from redefined class
 bytes of retransformed classes [v4]
In-Reply-To: <W-G_bEXaEzrhQFXDubMand8hMAZrGOblsRrSmT4qXgA=.48e07f3e-f9db-4be1-9ec5-17f8031f4a75@github.com>
References: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
 <W-G_bEXaEzrhQFXDubMand8hMAZrGOblsRrSmT4qXgA=.48e07f3e-f9db-4be1-9ec5-17f8031f4a75@github.com>
Message-ID: <BQFlq3SaTn6lZMkASMP__tcsBu9e4UDwDjA3lad21zI=.340bd28c-cfac-471d-ab42-d113f8d3105c@github.com>

On Thu, 2 Feb 2023 19:08:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> classFileParser drops stack map frames for JDK classes (when verification is not required).
>> As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition.
>> Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS.
>> This code is old (from "initial load") and I don't understand the reason it was implemented this way.
>> 
>> Testing: tier1-tier6
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated test

Marked as reviewed by sspitsyn (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12155

From dholmes at openjdk.org  Tue Feb  7 00:58:44 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Feb 2023 00:58:44 GMT
Subject: RFR: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails [v2]
In-Reply-To: <jPVFVRgngvBtyYqyVU8x8uzyKPezzhrmBmipa4QPw2M=.531d31e2-c1d9-4347-b712-811e70c3a974@github.com>
References: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
 <jPVFVRgngvBtyYqyVU8x8uzyKPezzhrmBmipa4QPw2M=.531d31e2-c1d9-4347-b712-811e70c3a974@github.com>
Message-ID: <fhEKLH0S8VQ0h1tHfa_XRw8orYlOrOml3yvTz0RESyU=.8a710084-5844-4516-a9d8-03b2caf98791@github.com>

On Mon, 6 Feb 2023 21:57:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> A number of tests that use JDI invokeMethod() support occasionally fail when run using virtual threads. The tests fail with:
>> 
>> 
>> # ERROR: TEST FAILED: wrong invocation:
>> # ERROR: invoking debuggee thread instance of java.lang.VirtualThread(name='invokemethod010tThr', id=272)
>> # ERROR: is not suspended again after the invocation 
>> 
>> 
>> Although as explained later, this is a misleading message, and does not accurately reflect why the test is failing. More on that below.
>> 
>> The root cause of the failure is due to these tests using JDI invokeMethod support with the  INVOKE_SINGLE_THREADED flag. This is not always going to work with virtual threads because the invoked method is doing a Thread.sleep(400), and that is at risk of blocking indefinitely if all other threads are blocked form making progress. Note that technically platform threads could fail in the same manner. However, the reason the failure only happens now with virtual threads is because the implementation of Thread.sleep() differs for virtual threads, and may require ownership of a monitor that sometimes is held by another thread.
>> 
>> Another issue is that the tests do not do a very good job of error handling when this happens, and give the misleading failure reason of the invoked thread not being suspended after the invoke completed. The reason it is not suspended is because the invoke has actually not completed. There was a timeout that the test did not properly note as the cause of the failure. The test (debugger side) spawns a thread to do the JDI invokeMethod with, and then waits for it with:
>> 
>>                 invThr.join(argHandler.getWaitTime()*60000);
>> 
>> This join() times out, but the test assumes once it returns the invoke is complete, even though the invoked thread is actually still in the middle of the invoke. So that is the reason debuggee invokemethod thread is not currently suspended. I've fixed this by having a test check if invThr is still alive after the join. If it is, then the test is made to fail at that point, rather than continuing on and checking the debuggee threads status. The failure then becomes:
>> 
>> nsk.share.TestFailure: TEST FAILED: invoke never completed
>> 
>> At that point a vm.resume() is done to allow the invoke to complete, and the test will exit with this failure.
>> 
>> As for avoiding the failure in the first place (the deadlock in the debuggee during the invoke), this is really a test bug for relying on INVOKE_SINGLE_THREADED and assuming that the invoked thread won't become deadlocked. Since there is a Thread.sleep() call in the invoked method, it can't make this assumption. From the ObjectReference.invoke() spec:
>> 
>> "By default, all threads in the target VM are resumed while the method is being invoked if they were previously suspended by an event or by VirtualMachine.suspend() or ThreadReference.suspend(). This is done to prevent the deadlocks that will occur if any of the threads own monitors that will be needed by the invoked method."
>> 
>> "The resumption of other threads during the invocation can be prevented by specifying the INVOKE_SINGLE_THREADED bit flag in the options argument; however, there is no protection against or recovery from the deadlocks described above, so this option should be used with great caution."
>> 
>> For platform threads, sleep() doesn't require any monitors, so these tests never ran into problems before. For virtual threads however there is some synchronization done, and potential reliance on other threads not being suspended. A way around this is to always use sleep(0), which will at least attempt to yield the thread. For platform threads an actual yield is likely. For a virtual thread it will not yield in this particular case because the virtual thread is pinned to the carrier thread due to the jvmti breakpoint callback that is currently in the call chain of the invoked thread. So for virtual threads this effectively the same as sitting in a spin loop with no yielding. This is ok. CPU wasting is not a concern.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of Thread.sleep() in the invoked method can add warning comment.

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011t.java line 94:

> 92:         while(!doExit) {
> 93:             l--; l++;
> 94:             Thread.currentThread().sleep(0);

BTW this is an anti-pattern - use `Thread.sleep(n)` - it always applies to the current thread.

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

PR: https://git.openjdk.org/jdk/pull/12420

From dholmes at openjdk.org  Tue Feb  7 01:03:47 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Feb 2023 01:03:47 GMT
Subject: RFR: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails [v2]
In-Reply-To: <jPVFVRgngvBtyYqyVU8x8uzyKPezzhrmBmipa4QPw2M=.531d31e2-c1d9-4347-b712-811e70c3a974@github.com>
References: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
 <jPVFVRgngvBtyYqyVU8x8uzyKPezzhrmBmipa4QPw2M=.531d31e2-c1d9-4347-b712-811e70c3a974@github.com>
Message-ID: <lw5vOizcOcY3gOJs931H_TGxg8S6SH2sS0YffyEOjCI=.2572328e-0c7a-4cbb-9c0b-c73a657a7ade@github.com>

On Mon, 6 Feb 2023 21:57:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> A number of tests that use JDI invokeMethod() support occasionally fail when run using virtual threads. The tests fail with:
>> 
>> 
>> # ERROR: TEST FAILED: wrong invocation:
>> # ERROR: invoking debuggee thread instance of java.lang.VirtualThread(name='invokemethod010tThr', id=272)
>> # ERROR: is not suspended again after the invocation 
>> 
>> 
>> Although as explained later, this is a misleading message, and does not accurately reflect why the test is failing. More on that below.
>> 
>> The root cause of the failure is due to these tests using JDI invokeMethod support with the  INVOKE_SINGLE_THREADED flag. This is not always going to work with virtual threads because the invoked method is doing a Thread.sleep(400), and that is at risk of blocking indefinitely if all other threads are blocked form making progress. Note that technically platform threads could fail in the same manner. However, the reason the failure only happens now with virtual threads is because the implementation of Thread.sleep() differs for virtual threads, and may require ownership of a monitor that sometimes is held by another thread.
>> 
>> Another issue is that the tests do not do a very good job of error handling when this happens, and give the misleading failure reason of the invoked thread not being suspended after the invoke completed. The reason it is not suspended is because the invoke has actually not completed. There was a timeout that the test did not properly note as the cause of the failure. The test (debugger side) spawns a thread to do the JDI invokeMethod with, and then waits for it with:
>> 
>>                 invThr.join(argHandler.getWaitTime()*60000);
>> 
>> This join() times out, but the test assumes once it returns the invoke is complete, even though the invoked thread is actually still in the middle of the invoke. So that is the reason debuggee invokemethod thread is not currently suspended. I've fixed this by having a test check if invThr is still alive after the join. If it is, then the test is made to fail at that point, rather than continuing on and checking the debuggee threads status. The failure then becomes:
>> 
>> nsk.share.TestFailure: TEST FAILED: invoke never completed
>> 
>> At that point a vm.resume() is done to allow the invoke to complete, and the test will exit with this failure.
>> 
>> As for avoiding the failure in the first place (the deadlock in the debuggee during the invoke), this is really a test bug for relying on INVOKE_SINGLE_THREADED and assuming that the invoked thread won't become deadlocked. Since there is a Thread.sleep() call in the invoked method, it can't make this assumption. From the ObjectReference.invoke() spec:
>> 
>> "By default, all threads in the target VM are resumed while the method is being invoked if they were previously suspended by an event or by VirtualMachine.suspend() or ThreadReference.suspend(). This is done to prevent the deadlocks that will occur if any of the threads own monitors that will be needed by the invoked method."
>> 
>> "The resumption of other threads during the invocation can be prevented by specifying the INVOKE_SINGLE_THREADED bit flag in the options argument; however, there is no protection against or recovery from the deadlocks described above, so this option should be used with great caution."
>> 
>> For platform threads, sleep() doesn't require any monitors, so these tests never ran into problems before. For virtual threads however there is some synchronization done, and potential reliance on other threads not being suspended. A way around this is to always use sleep(0), which will at least attempt to yield the thread. For platform threads an actual yield is likely. For a virtual thread it will not yield in this particular case because the virtual thread is pinned to the carrier thread due to the jvmti breakpoint callback that is currently in the call chain of the invoked thread. So for virtual threads this effectively the same as sitting in a spin loop with no yielding. This is ok. CPU wasting is not a concern.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of Thread.sleep() in the invoked method can add warning comment.

Okay so these tests are incredibly fragile - as you note display() may be a problem in theory, as could any potential class-loading or initialization. But without the sleep you have a busy-wait loop that may cause problems of its own (e.g. it might trigger on-stack-replacement but the compiler thread may require a resource held by one of the suspended threads!). It is impossible to know that something is 100% safe to do in this kind of situation.

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

PR: https://git.openjdk.org/jdk/pull/12420

From amenkov at openjdk.org  Tue Feb  7 01:13:46 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 7 Feb 2023 01:13:46 GMT
Subject: RFR: 8297638: Memory leak in case of many started-dead threads
 [v2]
In-Reply-To: <6A-Igi24IpuNPsjq1vJMscoKvujmMvYqDuMq6BncUsI=.9102a5c7-2f90-444c-b79a-00cb82b809bb@github.com>
References: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com>
 <6A-Igi24IpuNPsjq1vJMscoKvujmMvYqDuMq6BncUsI=.9102a5c7-2f90-444c-b79a-00cb82b809bb@github.com>
Message-ID: <_YK8jGH6JcO1waLj7XjaV6at6GPNZT7mnh2OK1TQ-m8=.aeed8f81-7af4-4212-a5d9-e11f40c5b467@github.com>

On Thu, 19 Jan 2023 21:59:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Fix JDI leak when the debuggee creates a lot of threads, while at the same the debugger is not sending any commands. The lack of commands being sent results in code not being triggered that normally would clear out unreachable listeners and also clear out ObjectReferences queued for disposal.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaned up removeUnreachableListeners().

Marked as reviewed by amenkov (Reviewer).

test/jdk/com/sun/jdi/ThreadMemoryLeakTest.java line 92:

> 90:     }
> 91: 
> 92:     public static void main(String[] args)      throws Exception {

extra spaces before "throws"

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

PR: https://git.openjdk.org/jdk/pull/12081

From dholmes at openjdk.org  Tue Feb  7 01:37:51 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Feb 2023 01:37:51 GMT
Subject: RFR: 8296646: com/sun/jdi/JdbLastErrorTest.java test failure
In-Reply-To: <JcLQhxM4bgBOXJMv3BW3-GFXYOcchUzoQ73IQuQwSa4=.b59a023f-30eb-47b0-ba51-dbdc3997b7ac@github.com>
References: <JcLQhxM4bgBOXJMv3BW3-GFXYOcchUzoQ73IQuQwSa4=.b59a023f-30eb-47b0-ba51-dbdc3997b7ac@github.com>
Message-ID: <BaSY4LTVXLvwxn15QBKOJ72GURSSF4GNYOpotEKHL1s=.a762414d-ffac-4f0f-afc8-c45df38ba0b8@github.com>

On Mon, 6 Feb 2023 14:24:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails sometimes with ZGC. It is testing using Panama to access Windows' last error value, and can of course be interrupted by VM work that changes the value, but it does generally work. Skipping the test with ZGC is reasonable as you don't really _have_ to step through this kind of Panama code with ZGC.
> 
> More rare is a failure where "The application exited" is not observed.  This test is not here to test the exit mode, and logging that failure avoids telling you whether the correct lastError value was seen.  Test should prioritise saying if the correct last error value was observed, and should check for the exception being thrown when the correct value is not seen.

Seems reasonable.

Thanks.

test/jdk/com/sun/jdi/JdbLastErrorTest.java line 68:

> 66:             System.out.println("lastError = " + lastError);
> 67:             if (lastError != VALUE) {
> 68:                 System.err.println("iteration " + i + " gets lastError = " + lastError);

s/gets/got/

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12441

From amenkov at openjdk.org  Tue Feb  7 01:49:43 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 7 Feb 2023 01:49:43 GMT
Subject: RFR: 8299739: HashedPasswordFileTest.java and ExceptionTest.java
 can fail with java.lang.NullPointerException
In-Reply-To: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
Message-ID: <0pnKAw5nBEU23sx6LNQ9vqDpvHBZE8GX6tWFl0Lb0Io=.51a2b197-3050-441b-b0c2-a45b42a2bbeb@github.com>

On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
> But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
> We must only call close if this is not null.

ExceptionTest failure looks strange, but anyway we need the checks to avoid NPE on failures

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

Marked as reviewed by amenkov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11881

From sspitsyn at openjdk.org  Tue Feb  7 01:52:50 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Feb 2023 01:52:50 GMT
Subject: RFR: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails [v2]
In-Reply-To: <fhEKLH0S8VQ0h1tHfa_XRw8orYlOrOml3yvTz0RESyU=.8a710084-5844-4516-a9d8-03b2caf98791@github.com>
References: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
 <jPVFVRgngvBtyYqyVU8x8uzyKPezzhrmBmipa4QPw2M=.531d31e2-c1d9-4347-b712-811e70c3a974@github.com>
 <fhEKLH0S8VQ0h1tHfa_XRw8orYlOrOml3yvTz0RESyU=.8a710084-5844-4516-a9d8-03b2caf98791@github.com>
Message-ID: <tkoO58wwrDnEHdUkHRUoJ70MZOysbC9Wb0aU5GNO5XQ=.6b00ff6c-6ac8-4f77-be61-607216659d26@github.com>

On Tue, 7 Feb 2023 00:56:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Get rid of Thread.sleep() in the invoked method can add warning comment.
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011t.java line 94:
> 
>> 92:         while(!doExit) {
>> 93:             l--; l++;
>> 94:             Thread.currentThread().sleep(0);
> 
> BTW this is an anti-pattern - use `Thread.sleep(n)` - it always applies to the current thread.

What about replacing sleep(0) with yield()?
Do we expect it also causing deadlocks? Was it considered?

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

PR: https://git.openjdk.org/jdk/pull/12420

From amenkov at openjdk.org  Tue Feb  7 02:00:43 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 7 Feb 2023 02:00:43 GMT
Subject: RFR: 8299739: HashedPasswordFileTest.java and ExceptionTest.java
 can fail with java.lang.NullPointerException
In-Reply-To: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
Message-ID: <jpFfcft321u195bhJmtEFsX0tfkUvjUwl-P-OS5HoH8=.a7823f7c-9742-4ecd-a2d1-c98fac09313b@github.com>

On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
> But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
> We must only call close if this is not null.

My only guess is ExceptionTest failed with some Error, so catch (Exception) didn't catch it

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

PR: https://git.openjdk.org/jdk/pull/11881

From sspitsyn at openjdk.org  Tue Feb  7 02:01:46 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Feb 2023 02:01:46 GMT
Subject: RFR: 8296646: com/sun/jdi/JdbLastErrorTest.java test failure
In-Reply-To: <JcLQhxM4bgBOXJMv3BW3-GFXYOcchUzoQ73IQuQwSa4=.b59a023f-30eb-47b0-ba51-dbdc3997b7ac@github.com>
References: <JcLQhxM4bgBOXJMv3BW3-GFXYOcchUzoQ73IQuQwSa4=.b59a023f-30eb-47b0-ba51-dbdc3997b7ac@github.com>
Message-ID: <NO1wTEB8slu7gsyQ6AnlPrw9Efv_MghZjGgpVu0_VwE=.cfed2c5d-9ba5-4538-b6d0-8bc4bf19353c@github.com>

On Mon, 6 Feb 2023 14:24:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails sometimes with ZGC. It is testing using Panama to access Windows' last error value, and can of course be interrupted by VM work that changes the value, but it does generally work. Skipping the test with ZGC is reasonable as you don't really _have_ to step through this kind of Panama code with ZGC.
> 
> More rare is a failure where "The application exited" is not observed.  This test is not here to test the exit mode, and logging that failure avoids telling you whether the correct lastError value was seen.  Test should prioritise saying if the correct last error value was observed, and should check for the exception being thrown when the correct value is not seen.

Looks good to me.
Posted one nit.
Thanks,
Serguei

test/jdk/com/sun/jdi/JdbLastErrorTest.java line 68:

> 66:             System.out.println("lastError = " + lastError);
> 67:             if (lastError != VALUE) {
> 68:                 System.err.println("iteration " + i + " gets lastError = " + lastError);

It'd be nice to print the expected VALUE as well.

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12441

From cjplummer at openjdk.org  Tue Feb  7 02:20:43 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 7 Feb 2023 02:20:43 GMT
Subject: RFR: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails [v2]
In-Reply-To: <lw5vOizcOcY3gOJs931H_TGxg8S6SH2sS0YffyEOjCI=.2572328e-0c7a-4cbb-9c0b-c73a657a7ade@github.com>
References: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
 <jPVFVRgngvBtyYqyVU8x8uzyKPezzhrmBmipa4QPw2M=.531d31e2-c1d9-4347-b712-811e70c3a974@github.com>
 <lw5vOizcOcY3gOJs931H_TGxg8S6SH2sS0YffyEOjCI=.2572328e-0c7a-4cbb-9c0b-c73a657a7ade@github.com>
Message-ID: <-VaMZeK660OLsiUxgJFkShoeRFbqX_jQC8QTK2PyAKg=.b72dc190-d4ce-4fa1-95a4-0410cc9a2af7@github.com>

On Tue, 7 Feb 2023 01:00:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Okay so these tests are incredibly fragile - as you note display() may be a problem in theory, as could any potential class-loading or initialization. 

Yes, the more that is done int the called method the more fragile it becomes. The javadoc is pretty clear about the risks of using  INVOKE_SINGLE_THREADED, and I think most users (such as IntelliJ) will quickly timeout the invoke, do a vm.resume() to unstick it, and then try the invoke again. The common use of JDI invoke by IDEs is to call toString() on local variables that are references to objects, which means even during common usage the invoke has the potential to do just about anything.
 
> But without the sleep you have a busy-wait loop that may cause problems of its own (e.g. it might trigger on-stack-replacement but the compiler thread may require a resource held by one of the suspended threads!). It is impossible to know that something is 100% safe to do in this kind of situation.

That's not possible since the thread will be in interpOnly mode (because invokes can only be done when suspended at an event).

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

PR: https://git.openjdk.org/jdk/pull/12420

From cjplummer at openjdk.org  Tue Feb  7 02:24:44 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 7 Feb 2023 02:24:44 GMT
Subject: RFR: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails [v2]
In-Reply-To: <tkoO58wwrDnEHdUkHRUoJ70MZOysbC9Wb0aU5GNO5XQ=.6b00ff6c-6ac8-4f77-be61-607216659d26@github.com>
References: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
 <jPVFVRgngvBtyYqyVU8x8uzyKPezzhrmBmipa4QPw2M=.531d31e2-c1d9-4347-b712-811e70c3a974@github.com>
 <fhEKLH0S8VQ0h1tHfa_XRw8orYlOrOml3yvTz0RESyU=.8a710084-5844-4516-a9d8-03b2caf98791@github.com>
 <tkoO58wwrDnEHdUkHRUoJ70MZOysbC9Wb0aU5GNO5XQ=.6b00ff6c-6ac8-4f77-be61-607216659d26@github.com>
Message-ID: <6PpuQZ_9ZRIBqCW-DvTGoVnyTGDebnpXRiWGKgjNOAs=.1b0d7ab7-3504-48ca-95c2-5181630a313b@github.com>

On Tue, 7 Feb 2023 01:49:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011t.java line 94:
>> 
>>> 92:         while(!doExit) {
>>> 93:             l--; l++;
>>> 94:             Thread.currentThread().sleep(0);
>> 
>> BTW this is an anti-pattern - use `Thread.sleep(n)` - it always applies to the current thread.
>
> What about replacing sleep(0) with yield()?
> Do we expect it also causing deadlocks? Was it considered?

sleep(0) on a virtual thread ends up doing a tryYield(), which is the same as what is done when calling sleep(0), so it should work, although I'm not so sure it is any better.

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

PR: https://git.openjdk.org/jdk/pull/12420

From sspitsyn at openjdk.org  Tue Feb  7 02:28:46 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Feb 2023 02:28:46 GMT
Subject: RFR: 8297638: Memory leak in case of many started-dead threads
 [v2]
In-Reply-To: <6A-Igi24IpuNPsjq1vJMscoKvujmMvYqDuMq6BncUsI=.9102a5c7-2f90-444c-b79a-00cb82b809bb@github.com>
References: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com>
 <6A-Igi24IpuNPsjq1vJMscoKvujmMvYqDuMq6BncUsI=.9102a5c7-2f90-444c-b79a-00cb82b809bb@github.com>
Message-ID: <YJ0Wr0cqec-nm3AyKYJH7Jsaxs6BLM79dLuyXX9ujmk=.33ba735c-cef0-4be6-9afc-7fd4d8ed3192@github.com>

On Thu, 19 Jan 2023 21:59:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Fix JDI leak when the debuggee creates a lot of threads, while at the same the debugger is not sending any commands. The lack of commands being sent results in code not being triggered that normally would clear out unreachable listeners and also clear out ObjectReferences queued for disposal.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaned up removeUnreachableListeners().

src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java line 184:

> 182:         // We always need to clear the ReferenceQueue
> 183:         while (listenersReferenceQueue.poll() != null)
> 184:             ;

I'm not sure how does this work.
Do we keep polling if there is any reference object in the queue?
Can it be an endless loop? Does the poll() remove the reverence object from the queue?

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

PR: https://git.openjdk.org/jdk/pull/12081

From cjplummer at openjdk.org  Tue Feb  7 02:28:46 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 7 Feb 2023 02:28:46 GMT
Subject: RFR: 8297638: Memory leak in case of many started-dead threads
 [v2]
In-Reply-To: <YJ0Wr0cqec-nm3AyKYJH7Jsaxs6BLM79dLuyXX9ujmk=.33ba735c-cef0-4be6-9afc-7fd4d8ed3192@github.com>
References: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com>
 <6A-Igi24IpuNPsjq1vJMscoKvujmMvYqDuMq6BncUsI=.9102a5c7-2f90-444c-b79a-00cb82b809bb@github.com>
 <YJ0Wr0cqec-nm3AyKYJH7Jsaxs6BLM79dLuyXX9ujmk=.33ba735c-cef0-4be6-9afc-7fd4d8ed3192@github.com>
Message-ID: <vGDY3A0QJ4IXut8KRkXaD6F3Km857YkQ2hUXooO1AB0=.570bb408-9101-4a61-aa56-cbecf600b0de@github.com>

On Tue, 7 Feb 2023 02:21:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleaned up removeUnreachableListeners().
>
> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java line 184:
> 
>> 182:         // We always need to clear the ReferenceQueue
>> 183:         while (listenersReferenceQueue.poll() != null)
>> 184:             ;
> 
> I'm not sure how does this work.
> Do we keep polling if there is any reference object in the queue?
> Can it be an endless loop? Does the poll() remove the reverence object from the queue?

The poll() removes the next object from the queue.

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

PR: https://git.openjdk.org/jdk/pull/12081

From cjplummer at openjdk.org  Tue Feb  7 02:28:47 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 7 Feb 2023 02:28:47 GMT
Subject: RFR: 8297638: Memory leak in case of many started-dead threads
 [v2]
In-Reply-To: <vGDY3A0QJ4IXut8KRkXaD6F3Km857YkQ2hUXooO1AB0=.570bb408-9101-4a61-aa56-cbecf600b0de@github.com>
References: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com>
 <6A-Igi24IpuNPsjq1vJMscoKvujmMvYqDuMq6BncUsI=.9102a5c7-2f90-444c-b79a-00cb82b809bb@github.com>
 <YJ0Wr0cqec-nm3AyKYJH7Jsaxs6BLM79dLuyXX9ujmk=.33ba735c-cef0-4be6-9afc-7fd4d8ed3192@github.com>
 <vGDY3A0QJ4IXut8KRkXaD6F3Km857YkQ2hUXooO1AB0=.570bb408-9101-4a61-aa56-cbecf600b0de@github.com>
Message-ID: <NAXX1C2f9TR_-yi5lexQQWahmHNmsQxj38blgbro6ew=.62fdc7f8-387f-47db-81d7-8900501ea43e@github.com>

On Tue, 7 Feb 2023 02:23:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java line 184:
>> 
>>> 182:         // We always need to clear the ReferenceQueue
>>> 183:         while (listenersReferenceQueue.poll() != null)
>>> 184:             ;
>> 
>> I'm not sure how does this work.
>> Do we keep polling if there is any reference object in the queue?
>> Can it be an endless loop? Does the poll() remove the reverence object from the queue?
>
> The poll() removes the next object from the queue.

This code is a bit odd in that it uses the reference queue to find out if there are one or more unreachable listeners. If there are, then it uses the code below to remove them. So the reference queue is really just a unreachable object detection mechanism, and not used for the actual processing of the objects.

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

PR: https://git.openjdk.org/jdk/pull/12081

From dholmes at openjdk.org  Tue Feb  7 02:30:46 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Feb 2023 02:30:46 GMT
Subject: RFR: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails [v2]
In-Reply-To: <jPVFVRgngvBtyYqyVU8x8uzyKPezzhrmBmipa4QPw2M=.531d31e2-c1d9-4347-b712-811e70c3a974@github.com>
References: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
 <jPVFVRgngvBtyYqyVU8x8uzyKPezzhrmBmipa4QPw2M=.531d31e2-c1d9-4347-b712-811e70c3a974@github.com>
Message-ID: <vd8F3SQRgm-SoNAqjoPYK-Y1m0yA2KCIVRpRXbh7yP4=.0c298304-f05f-43f9-ab3f-9f7082920f13@github.com>

On Mon, 6 Feb 2023 21:57:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> A number of tests that use JDI invokeMethod() support occasionally fail when run using virtual threads. The tests fail with:
>> 
>> 
>> # ERROR: TEST FAILED: wrong invocation:
>> # ERROR: invoking debuggee thread instance of java.lang.VirtualThread(name='invokemethod010tThr', id=272)
>> # ERROR: is not suspended again after the invocation 
>> 
>> 
>> Although as explained later, this is a misleading message, and does not accurately reflect why the test is failing. More on that below.
>> 
>> The root cause of the failure is due to these tests using JDI invokeMethod support with the  INVOKE_SINGLE_THREADED flag. This is not always going to work with virtual threads because the invoked method is doing a Thread.sleep(400), and that is at risk of blocking indefinitely if all other threads are blocked form making progress. Note that technically platform threads could fail in the same manner. However, the reason the failure only happens now with virtual threads is because the implementation of Thread.sleep() differs for virtual threads, and may require ownership of a monitor that sometimes is held by another thread.
>> 
>> Another issue is that the tests do not do a very good job of error handling when this happens, and give the misleading failure reason of the invoked thread not being suspended after the invoke completed. The reason it is not suspended is because the invoke has actually not completed. There was a timeout that the test did not properly note as the cause of the failure. The test (debugger side) spawns a thread to do the JDI invokeMethod with, and then waits for it with:
>> 
>>                 invThr.join(argHandler.getWaitTime()*60000);
>> 
>> This join() times out, but the test assumes once it returns the invoke is complete, even though the invoked thread is actually still in the middle of the invoke. So that is the reason debuggee invokemethod thread is not currently suspended. I've fixed this by having a test check if invThr is still alive after the join. If it is, then the test is made to fail at that point, rather than continuing on and checking the debuggee threads status. The failure then becomes:
>> 
>> nsk.share.TestFailure: TEST FAILED: invoke never completed
>> 
>> At that point a vm.resume() is done to allow the invoke to complete, and the test will exit with this failure.
>> 
>> As for avoiding the failure in the first place (the deadlock in the debuggee during the invoke), this is really a test bug for relying on INVOKE_SINGLE_THREADED and assuming that the invoked thread won't become deadlocked. Since there is a Thread.sleep() call in the invoked method, it can't make this assumption. From the ObjectReference.invoke() spec:
>> 
>> "By default, all threads in the target VM are resumed while the method is being invoked if they were previously suspended by an event or by VirtualMachine.suspend() or ThreadReference.suspend(). This is done to prevent the deadlocks that will occur if any of the threads own monitors that will be needed by the invoked method."
>> 
>> "The resumption of other threads during the invocation can be prevented by specifying the INVOKE_SINGLE_THREADED bit flag in the options argument; however, there is no protection against or recovery from the deadlocks described above, so this option should be used with great caution."
>> 
>> For platform threads, sleep() doesn't require any monitors, so these tests never ran into problems before. For virtual threads however there is some synchronization done, and potential reliance on other threads not being suspended. A way around this is to always use sleep(0), which will at least attempt to yield the thread. For platform threads an actual yield is likely. For a virtual thread it will not yield in this particular case because the virtual thread is pinned to the carrier thread due to the jvmti breakpoint callback that is currently in the call chain of the invoked thread. So for virtual threads this effectively the same as sitting in a spin loop with no yielding. This is ok. CPU wasting is not a concern.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of Thread.sleep() in the invoked method can add warning comment.

Good to know interpOnly mode at least places some limits on what may happen. The busy-loop is not likely to trigger any deadlock in that case.

I will leave it to you whether to select sleep(0) or no sleep at all.

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

PR: https://git.openjdk.org/jdk/pull/12420

From cjplummer at openjdk.org  Tue Feb  7 02:33:45 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 7 Feb 2023 02:33:45 GMT
Subject: RFR: 8296646: com/sun/jdi/JdbLastErrorTest.java test failure
In-Reply-To: <JcLQhxM4bgBOXJMv3BW3-GFXYOcchUzoQ73IQuQwSa4=.b59a023f-30eb-47b0-ba51-dbdc3997b7ac@github.com>
References: <JcLQhxM4bgBOXJMv3BW3-GFXYOcchUzoQ73IQuQwSa4=.b59a023f-30eb-47b0-ba51-dbdc3997b7ac@github.com>
Message-ID: <8vI2t9ihEXLQto3fobS0rsBXaaFQgQYO-rGjwkTqO1s=.38efd772-a60f-4e1c-beb9-5201512741b4@github.com>

On Mon, 6 Feb 2023 14:24:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails sometimes with ZGC. It is testing using Panama to access Windows' last error value, and can of course be interrupted by VM work that changes the value, but it does generally work. Skipping the test with ZGC is reasonable as you don't really _have_ to step through this kind of Panama code with ZGC.
> 
> More rare is a failure where "The application exited" is not observed.  This test is not here to test the exit mode, and logging that failure avoids telling you whether the correct lastError value was seen.  Test should prioritise saying if the correct last error value was observed, and should check for the exception being thrown when the correct value is not seen.

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12441

From sspitsyn at openjdk.org  Tue Feb  7 03:04:44 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Feb 2023 03:04:44 GMT
Subject: RFR: 8297638: Memory leak in case of many started-dead threads
 [v2]
In-Reply-To: <NAXX1C2f9TR_-yi5lexQQWahmHNmsQxj38blgbro6ew=.62fdc7f8-387f-47db-81d7-8900501ea43e@github.com>
References: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com>
 <6A-Igi24IpuNPsjq1vJMscoKvujmMvYqDuMq6BncUsI=.9102a5c7-2f90-444c-b79a-00cb82b809bb@github.com>
 <YJ0Wr0cqec-nm3AyKYJH7Jsaxs6BLM79dLuyXX9ujmk=.33ba735c-cef0-4be6-9afc-7fd4d8ed3192@github.com>
 <vGDY3A0QJ4IXut8KRkXaD6F3Km857YkQ2hUXooO1AB0=.570bb408-9101-4a61-aa56-cbecf600b0de@github.com>
 <NAXX1C2f9TR_-yi5lexQQWahmHNmsQxj38blgbro6ew=.62fdc7f8-387f-47db-81d7-8900501ea43e@github.com>
Message-ID: <dvPVdLFQFec4BpsO7jBl3CUll8POpPaBhQRn9gx2wmc=.c54e1a6e-e76d-46dd-b7b5-f8e81b7bbaa5@github.com>

On Tue, 7 Feb 2023 02:25:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The poll() removes the next object from the queue.
>
> This code is a bit odd in that it uses the reference queue to find out if there are one or more unreachable listeners. If there are, then it uses the code below to remove them. So the reference queue is really just a unreachable object detection mechanism, and not used for the actual processing of the objects.

Okay. Thank you for explanation. It looks reasonable then.

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

PR: https://git.openjdk.org/jdk/pull/12081

From alanb at openjdk.org  Tue Feb  7 07:13:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Feb 2023 07:13:40 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit
Message-ID: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>

The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:

- BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
- Tests using data providers are changed to parameterized tests
- The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
- Usages of expectThrows are changed to assertThrows
- Tests that threw SkipException are changed to the Assumptions API

There are a small number of drive-by changes to the tests, nothing significant, e.g.

- GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
- A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.

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

Commit messages:
 - Fix typos in comments
 - GetStackTrace.java test missing @requires vm.continuations
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/12426/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12426&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301767
  Stats: 1416 lines in 34 files changed: 205 ins; 79 del; 1132 mod
  Patch: https://git.openjdk.org/jdk/pull/12426.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12426/head:pull/12426

PR: https://git.openjdk.org/jdk/pull/12426

From cstein at openjdk.org  Tue Feb  7 08:36:44 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 7 Feb 2023 08:36:44 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit
In-Reply-To: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
Message-ID: <jMwCmrAMI9A0RLUzlt41fT8KOMhFLA_ym9der9ZH2Yo=.ad246769-d203-410c-b30a-320922e1c540@github.com>

On Sat, 4 Feb 2023 08:59:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
> 
> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
> - Tests using data providers are changed to parameterized tests
> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
> - Usages of expectThrows are changed to assertThrows
> - Tests that threw SkipException are changed to the Assumptions API
> 
> There are a small number of drive-by changes to the tests, nothing significant, e.g.
> 
> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.

Marked as reviewed by cstein (Committer).

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

PR: https://git.openjdk.org/jdk/pull/12426

From kevinw at openjdk.org  Tue Feb  7 10:09:23 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 7 Feb 2023 10:09:23 GMT
Subject: RFR: 8296646: com/sun/jdi/JdbLastErrorTest.java test failure [v2]
In-Reply-To: <JcLQhxM4bgBOXJMv3BW3-GFXYOcchUzoQ73IQuQwSa4=.b59a023f-30eb-47b0-ba51-dbdc3997b7ac@github.com>
References: <JcLQhxM4bgBOXJMv3BW3-GFXYOcchUzoQ73IQuQwSa4=.b59a023f-30eb-47b0-ba51-dbdc3997b7ac@github.com>
Message-ID: <GR4IGqjP1fERt3OmG2PhH4sHDz8sjErE8e89PiyzhP8=.2b30a88e-aa8c-4647-9670-02613c5081a8@github.com>

> This test fails sometimes with ZGC. It is testing using Panama to access Windows' last error value, and can of course be interrupted by VM work that changes the value, but it does generally work. Skipping the test with ZGC is reasonable as you don't really _have_ to step through this kind of Panama code with ZGC.
> 
> More rare is a failure where "The application exited" is not observed.  This test is not here to test the exit mode, and logging that failure avoids telling you whether the correct lastError value was seen.  Test should prioritise saying if the correct last error value was observed, and should check for the exception being thrown when the correct value is not seen.

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

  exception message update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12441/files
  - new: https://git.openjdk.org/jdk/pull/12441/files/e37f1e73..bbe811be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12441&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12441&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12441

From kevinw at openjdk.org  Tue Feb  7 10:10:05 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 7 Feb 2023 10:10:05 GMT
Subject: RFR: 8296646: com/sun/jdi/JdbLastErrorTest.java test failure
In-Reply-To: <JcLQhxM4bgBOXJMv3BW3-GFXYOcchUzoQ73IQuQwSa4=.b59a023f-30eb-47b0-ba51-dbdc3997b7ac@github.com>
References: <JcLQhxM4bgBOXJMv3BW3-GFXYOcchUzoQ73IQuQwSa4=.b59a023f-30eb-47b0-ba51-dbdc3997b7ac@github.com>
Message-ID: <aaUD6IcxHpE7yMGuWOecrpIxD0TKKO-kyl0uqNYy6DM=.92514d97-f8b3-4d23-ad5b-3f96d6a272d4@github.com>

On Mon, 6 Feb 2023 14:24:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails sometimes with ZGC. It is testing using Panama to access Windows' last error value, and can of course be interrupted by VM work that changes the value, but it does generally work. Skipping the test with ZGC is reasonable as you don't really _have_ to step through this kind of Panama code with ZGC.
> 
> More rare is a failure where "The application exited" is not observed.  This test is not here to test the exit mode, and logging that failure avoids telling you whether the correct lastError value was seen.  Test should prioritise saying if the correct last error value was observed, and should check for the exception being thrown when the correct value is not seen.

Thanks for the comments, will have the test logging for example:

[debuggee] iteration 0 got lastError = 0 (expected 42)

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

PR: https://git.openjdk.org/jdk/pull/12441

From kevinw at openjdk.org  Tue Feb  7 10:18:14 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 7 Feb 2023 10:18:14 GMT
Subject: Integrated: 8296646: com/sun/jdi/JdbLastErrorTest.java test failure
In-Reply-To: <JcLQhxM4bgBOXJMv3BW3-GFXYOcchUzoQ73IQuQwSa4=.b59a023f-30eb-47b0-ba51-dbdc3997b7ac@github.com>
References: <JcLQhxM4bgBOXJMv3BW3-GFXYOcchUzoQ73IQuQwSa4=.b59a023f-30eb-47b0-ba51-dbdc3997b7ac@github.com>
Message-ID: <dhq3T7quJ6ppTgqi1QgM414jQr9Iq7VNr7BvGbGeSGA=.b3493568-312c-42bf-81b9-591e75b8b856@github.com>

On Mon, 6 Feb 2023 14:24:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails sometimes with ZGC. It is testing using Panama to access Windows' last error value, and can of course be interrupted by VM work that changes the value, but it does generally work. Skipping the test with ZGC is reasonable as you don't really _have_ to step through this kind of Panama code with ZGC.
> 
> More rare is a failure where "The application exited" is not observed.  This test is not here to test the exit mode, and logging that failure avoids telling you whether the correct lastError value was seen.  Test should prioritise saying if the correct last error value was observed, and should check for the exception being thrown when the correct value is not seen.

This pull request has now been integrated.

Changeset: c61a3821
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c61a38212e8d7ab8d9ece4c414dddd5032bfd6aa
Stats:     8 lines in 1 file changed: 4 ins; 0 del; 4 mod

8296646: com/sun/jdi/JdbLastErrorTest.java test failure

Reviewed-by: dholmes, sspitsyn, cjplummer

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

PR: https://git.openjdk.org/jdk/pull/12441

From jcking at openjdk.org  Tue Feb  7 14:23:40 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Feb 2023 14:23:40 GMT
Subject: RFR: JDK-8301983: Refactor MEMFLAGS and AllocFailStrategy
Message-ID: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>

- Rename `MEMFLAGS` to `MemoryType`. `MEMFLAGS` is highly misleading as flags typically can be combined.
- Update `MemoryType` to have enumeration names that follow the style guide, no `mt` prefix.
- Create aliases for old `mtXXX` names.
- Remove `mt_number_of_types` from the enumeration.
- Shift implementation of utilities related to `MEMFLAGS` from `NMTUtil` to `MemoryTypes`. Handle missing `mt` prefix during parsing.
- `NMTUtil` references are not updated to avoid increasing patch size.
- Merge `AllocFailStrategy` and `AllocFailType` into `AllocationFailureStrategy`.
- Move `MemoryType` and `AllocationFailureStrategy` to their own respective headers.

This change does not update variable verbiage. That should be something done over time.

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

Commit messages:
 - Fix undefined variable reference
 - Cleanup memory types and allocation failure strategies

Changes: https://git.openjdk.org/jdk/pull/12454/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12454&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301983
  Stats: 794 lines in 80 files changed: 213 ins; 94 del; 487 mod
  Patch: https://git.openjdk.org/jdk/pull/12454.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12454/head:pull/12454

PR: https://git.openjdk.org/jdk/pull/12454

From jcking at openjdk.org  Tue Feb  7 14:33:34 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Feb 2023 14:33:34 GMT
Subject: RFR: JDK-8301983: Refactor MEMFLAGS and AllocFailStrategy [v2]
In-Reply-To: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>
References: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>
Message-ID: <q6kz-N8h3oSr8jCWhScOHOogZxEYsfbIUMuqXYxh3Pc=.cab786a9-2730-4f2c-a37b-8da5759c368a@github.com>

> - Rename `MEMFLAGS` to `MemoryType`. `MEMFLAGS` is highly misleading as flags typically can be combined.
> - Update `MemoryType` to have enumeration names that follow the style guide, no `mt` prefix.
> - Create aliases for old `mtXXX` names.
> - Remove `mt_number_of_types` from the enumeration.
> - Shift implementation of utilities related to `MEMFLAGS` from `NMTUtil` to `MemoryTypes`. Handle missing `mt` prefix during parsing.
> - `NMTUtil` references are not updated to avoid increasing patch size.
> - Merge `AllocFailStrategy` and `AllocFailType` into `AllocationFailureStrategy`.
> - Move `MemoryType` and `AllocationFailureStrategy` to their own respective headers.
> 
> This change does not update variable verbiage. That should be something done over time.

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

  Fix printf formatting error
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12454/files
  - new: https://git.openjdk.org/jdk/pull/12454/files/be6c2307..c2f229ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12454&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12454&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12454

From jcking at openjdk.org  Tue Feb  7 14:40:49 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Feb 2023 14:40:49 GMT
Subject: RFR: JDK-8301983: Refactor MEMFLAGS and AllocFailStrategy [v3]
In-Reply-To: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>
References: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>
Message-ID: <h1T-34Uuk3tteNRfjJKhZqiPJCu-_mxT8fFw5SAnOyc=.055e0ef2-11cf-4ecc-8b5b-52636ad8ab97@github.com>

> - Rename `MEMFLAGS` to `MemoryType`. `MEMFLAGS` is highly misleading as flags typically can be combined.
> - Update `MemoryType` to have enumeration names that follow the style guide, no `mt` prefix.
> - Create aliases for old `mtXXX` names.
> - Remove `mt_number_of_types` from the enumeration.
> - Shift implementation of utilities related to `MEMFLAGS` from `NMTUtil` to `MemoryTypes`. Handle missing `mt` prefix during parsing.
> - `NMTUtil` references are not updated to avoid increasing patch size.
> - Merge `AllocFailStrategy` and `AllocFailType` into `AllocationFailureStrategy`.
> - Move `MemoryType` and `AllocationFailureStrategy` to their own respective headers.
> 
> This change does not update variable verbiage. That should be something done over time.

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

  Fix refactor mistake
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12454/files
  - new: https://git.openjdk.org/jdk/pull/12454/files/c2f229ba..fe293c42

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12454&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12454&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/12454

From coleenp at openjdk.org  Tue Feb  7 14:45:56 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Feb 2023 14:45:56 GMT
Subject: RFR: JDK-8301983: Refactor MEMFLAGS and AllocFailStrategy [v3]
In-Reply-To: <h1T-34Uuk3tteNRfjJKhZqiPJCu-_mxT8fFw5SAnOyc=.055e0ef2-11cf-4ecc-8b5b-52636ad8ab97@github.com>
References: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>
 <h1T-34Uuk3tteNRfjJKhZqiPJCu-_mxT8fFw5SAnOyc=.055e0ef2-11cf-4ecc-8b5b-52636ad8ab97@github.com>
Message-ID: <YQRcdBnYTdBOacDbjEXf7XyzSw34cPV2LOROOfGv2lM=.29afcf7a-0d45-420c-9a0d-5e225f6800ff@github.com>

On Tue, 7 Feb 2023 14:40:49 GMT, Justin King <jcking at openjdk.org> wrote:

>> - Rename `MEMFLAGS` to `MemoryType`. `MEMFLAGS` is highly misleading as flags typically can be combined.
>> - Update `MemoryType` to have enumeration names that follow the style guide, no `mt` prefix.
>> - Create aliases for old `mtXXX` names.
>> - Remove `mt_number_of_types` from the enumeration.
>> - Shift implementation of utilities related to `MEMFLAGS` from `NMTUtil` to `MemoryTypes`. Handle missing `mt` prefix during parsing.
>> - `NMTUtil` references are not updated to avoid increasing patch size.
>> - Merge `AllocFailStrategy` and `AllocFailType` into `AllocationFailureStrategy`.
>> - Move `MemoryType` and `AllocationFailureStrategy` to their own respective headers.
>> 
>> This change does not update variable verbiage. That should be something done over time.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix refactor mistake
>   
>   Signed-off-by: Justin King <jcking at google.com>

I don't like MemoryType.  MEMFLAGS makes it indicative that it's a flag for some purpose and sticks out to my eyes as a template parameter, which is part of our coding style. mtWhatever is easy to spot in the code where used.  I don't agree with the reasoning for this change.   Moving the header file out of allocation.hpp seems good though although we still need to include allocation.hpp to get CHeapObj so not sure how much inclusion that saves.

I think also having a PR with a bullet list is a good sign that you're doing too much in one change.

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

PR: https://git.openjdk.org/jdk/pull/12454

From jcking at openjdk.org  Tue Feb  7 15:07:26 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Feb 2023 15:07:26 GMT
Subject: RFR: JDK-8301983: Refactor MEMFLAGS and AllocFailStrategy [v3]
In-Reply-To: <YQRcdBnYTdBOacDbjEXf7XyzSw34cPV2LOROOfGv2lM=.29afcf7a-0d45-420c-9a0d-5e225f6800ff@github.com>
References: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>
 <h1T-34Uuk3tteNRfjJKhZqiPJCu-_mxT8fFw5SAnOyc=.055e0ef2-11cf-4ecc-8b5b-52636ad8ab97@github.com>
 <YQRcdBnYTdBOacDbjEXf7XyzSw34cPV2LOROOfGv2lM=.29afcf7a-0d45-420c-9a0d-5e225f6800ff@github.com>
Message-ID: <cw9vUyfkiRxOCf72J7ITQhQNx1kPAWscOLQofLo1Y08=.7e8a4549-9043-4818-85c2-303edaa9193a@github.com>

On Tue, 7 Feb 2023 14:42:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I don't like MemoryType. MEMFLAGS makes it indicative that it's a flag for some purpose and sticks out to my eyes as a template parameter, which is part of our coding style. mtWhatever is easy to spot in the code where used. I don't agree with the reasoning for this change. Moving the header file out of allocation.hpp seems good though although we still need to include allocation.hpp to get CHeapObj so not sure how much inclusion that saves.

MEMFLAGS implies it's flags. In C/C++ that almost always means they can be combined together and passed as a single argument. The only other usage I've seen it with is command line options. That is not the case here, it's just an enumeration of types/categories/kinds. It's not a combination of bits or a pattern. The mt prefix is preserved, you can still use mtWhatever, it's just an alias. The prefix mt, AFAIK, quite literally means memory type, hence the chosen name. MEMFLAGS isn't always a template parameter either.

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

PR: https://git.openjdk.org/jdk/pull/12454

From jcking at openjdk.org  Tue Feb  7 15:44:36 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Feb 2023 15:44:36 GMT
Subject: RFR: JDK-8301983: Refactor MEMFLAGS and AllocFailStrategy [v4]
In-Reply-To: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>
References: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>
Message-ID: <9KjUQXJRYFeVtfzbRh-OY9CaQaAjwguxJJpqR92xFAo=.409e3276-9c9d-4d82-9bcc-27fad82e7074@github.com>

> - Rename `MEMFLAGS` to `MemoryType`. `MEMFLAGS` is highly misleading as flags typically can be combined.
> - Update `MemoryType` to have enumeration names that follow the style guide, no `mt` prefix.
> - Create aliases for old `mtXXX` names.
> - Remove `mt_number_of_types` from the enumeration.
> - Shift implementation of utilities related to `MEMFLAGS` from `NMTUtil` to `MemoryTypes`. Handle missing `mt` prefix during parsing.
> - `NMTUtil` references are not updated to avoid increasing patch size.
> - Merge `AllocFailStrategy` and `AllocFailType` into `AllocationFailureStrategy`.
> - Move `MemoryType` and `AllocationFailureStrategy` to their own respective headers.
> 
> This change does not update variable verbiage. That should be something done over time.

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

  Fix printf formatting error
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12454/files
  - new: https://git.openjdk.org/jdk/pull/12454/files/fe293c42..61596ca6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12454&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12454&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/12454

From jcking at openjdk.org  Tue Feb  7 17:25:02 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Feb 2023 17:25:02 GMT
Subject: RFR: JDK-8301983: Refactor MEMFLAGS and AllocFailStrategy [v5]
In-Reply-To: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>
References: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>
Message-ID: <60XHlRRmnr8C-BcA_pRbLwIs7P5lqv5cayfc4ifBHeE=.12ed00cf-afc1-410a-b415-4425769be62b@github.com>

> - Rename `MEMFLAGS` to `MemoryType`. `MEMFLAGS` is highly misleading as flags typically can be combined.
> - Update `MemoryType` to have enumeration names that follow the style guide, no `mt` prefix.
> - Create aliases for old `mtXXX` names.
> - Remove `mt_number_of_types` from the enumeration.
> - Shift implementation of utilities related to `MEMFLAGS` from `NMTUtil` to `MemoryTypes`. Handle missing `mt` prefix during parsing.
> - `NMTUtil` references are not updated to avoid increasing patch size.
> - Merge `AllocFailStrategy` and `AllocFailType` into `AllocationFailureStrategy`.
> - Move `MemoryType` and `AllocationFailureStrategy` to their own respective headers.
> 
> This change does not update variable verbiage. That should be something done over time.

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

  Add precompiled header
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12454/files
  - new: https://git.openjdk.org/jdk/pull/12454/files/61596ca6..eaa44d06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12454&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12454&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/12454

From stuefe at openjdk.org  Tue Feb  7 17:43:35 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 7 Feb 2023 17:43:35 GMT
Subject: RFR: JDK-8301983: Refactor MEMFLAGS and AllocFailStrategy [v3]
In-Reply-To: <YQRcdBnYTdBOacDbjEXf7XyzSw34cPV2LOROOfGv2lM=.29afcf7a-0d45-420c-9a0d-5e225f6800ff@github.com>
References: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>
 <h1T-34Uuk3tteNRfjJKhZqiPJCu-_mxT8fFw5SAnOyc=.055e0ef2-11cf-4ecc-8b5b-52636ad8ab97@github.com>
 <YQRcdBnYTdBOacDbjEXf7XyzSw34cPV2LOROOfGv2lM=.29afcf7a-0d45-420c-9a0d-5e225f6800ff@github.com>
Message-ID: <mI8pcufuZ76GGcI_3Mk8yZA0tEW1kN_saihx_ZcxFos=.6faba173-8601-4e23-a76f-cdf41152c1b8@github.com>

On Tue, 7 Feb 2023 14:43:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix refactor mistake
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> I think also having a PR with a bullet list is a good sign that you're doing too much in one change.

I agree with @coleenp, sorry. I think this PR is premature. My advice would be to discuss such invasive changes on the ML first before opening a PR.

Sometimes we do broad changes like this to keep the code base fresh. But it's always a tradeoff. Often the benefits of correcting the code base outweigh the cost, so we do it. But sometimes they don't. And I argue that in this case, they don't.

Mental load cost: Not every name in the hotspot adheres to our naming guides, but may nevertheless be burnt into the collective brain of developers who have worked with the code base for many years. We talked about them, argued about them, there are tons of ML discussions and private emails and documentation surrounding them, they appear in scripts and test documentation... I'd hate to talk about the flag previously known as MEMFLAGS. 

It is a dividing line, and necessarily an arbitrary one. Not everyone sees this line at the same point. For a broad change that lies on this side of the line see the recent NULL->nullptr changes. Invasive, sure, but useful enough to do.

Backporting cost: three LTS releases are still maintained by vendors, soon to be joined by a fourth one. Such a broad change makes backporting fixes difficult. The NULL->nullptr change was simpler in that regard because even though it spoils automatic merges, merging manually is straightforward. But renaming is a different matter. We have seen such problems in the past with Metaspace class renames, and that is just an isolated subsystem.

Moreover, with MEMFLAGS, things are in flux; we may change the implementation in the future, and there are different plans for it. So I'd leave this as it is.

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

PR: https://git.openjdk.org/jdk/pull/12454

From jcking at openjdk.org  Tue Feb  7 18:02:52 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Feb 2023 18:02:52 GMT
Subject: RFR: JDK-8301983: Refactor MEMFLAGS and AllocFailStrategy [v3]
In-Reply-To: <YQRcdBnYTdBOacDbjEXf7XyzSw34cPV2LOROOfGv2lM=.29afcf7a-0d45-420c-9a0d-5e225f6800ff@github.com>
References: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>
 <h1T-34Uuk3tteNRfjJKhZqiPJCu-_mxT8fFw5SAnOyc=.055e0ef2-11cf-4ecc-8b5b-52636ad8ab97@github.com>
 <YQRcdBnYTdBOacDbjEXf7XyzSw34cPV2LOROOfGv2lM=.29afcf7a-0d45-420c-9a0d-5e225f6800ff@github.com>
Message-ID: <jGncJe919d2526Xz_PTrMpKzCf4mvXikq0G6-EPdNwg=.98bc38b6-8727-4f32-9d68-950d1078b910@github.com>

On Tue, 7 Feb 2023 14:43:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix refactor mistake
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> I think also having a PR with a bullet list is a good sign that you're doing too much in one change.

> I agree with @coleenp, sorry. I think this PR is premature. My advice would be to discuss such invasive changes on the ML first before opening a PR.
> 
> Sometimes we do broad changes like this to keep the code base fresh. But it's always a tradeoff. Often the benefits of correcting the code base outweigh the cost, so we do it. But sometimes they don't. And I argue that in this case, they don't.
> 
> Mental load cost: Not every name in the hotspot adheres to our naming guides, but may nevertheless be burnt into the collective brain of developers who have worked with the code base for many years. We talked about them, argued about them, there are tons of ML discussions and private emails and documentation surrounding them, they appear in scripts and test documentation... I'd hate to talk about the flag previously known as MEMFLAGS.
> 
> It is a dividing line, and necessarily an arbitrary one. Not everyone sees this line at the same point. For a broad change that lies on this side of the line see the recent NULL->nullptr changes. Invasive, sure, but useful enough to do.
> 
> Backporting cost: three LTS releases are still maintained by vendors, soon to be joined by a fourth one. Such a broad change makes backporting fixes difficult. The NULL->nullptr change was simpler in that regard because even though it spoils automatic merges, merging manually is straightforward. But renaming is a different matter. We have seen such problems in the past with Metaspace class renames, and that is just an isolated subsystem.
> 
> Moreover, with MEMFLAGS, things are in flux; we may change the implementation in the future, and there are different plans for it. So I'd leave this as it is.

I can agree with the reasoning (except backporting, that can be applied to any change touching an existing file), it is arbitrary and depends where it is draw. It didn't take very long to do this PR, so it doesn't particularly matter to me.

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

PR: https://git.openjdk.org/jdk/pull/12454

From jcking at openjdk.org  Tue Feb  7 18:02:54 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Feb 2023 18:02:54 GMT
Subject: Withdrawn: JDK-8301983: Refactor MEMFLAGS and AllocFailStrategy
In-Reply-To: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>
References: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>
Message-ID: <P3Nd4ccJtg8_kji0d82_3nM8fP_GryjuhD46sUN3Bh0=.b7a8adc0-c585-48cc-ae5f-ab739babfc8a@github.com>

On Tue, 7 Feb 2023 14:14:07 GMT, Justin King <jcking at openjdk.org> wrote:

> - Rename `MEMFLAGS` to `MemoryType`. `MEMFLAGS` is highly misleading as flags typically can be combined.
> - Update `MemoryType` to have enumeration names that follow the style guide, no `mt` prefix.
> - Create aliases for old `mtXXX` names.
> - Remove `mt_number_of_types` from the enumeration.
> - Shift implementation of utilities related to `MEMFLAGS` from `NMTUtil` to `MemoryTypes`. Handle missing `mt` prefix during parsing.
> - `NMTUtil` references are not updated to avoid increasing patch size.
> - Merge `AllocFailStrategy` and `AllocFailType` into `AllocationFailureStrategy`.
> - Move `MemoryType` and `AllocationFailureStrategy` to their own respective headers.
> 
> This change does not update variable verbiage. That should be something done over time.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/12454

From lancea at openjdk.org  Tue Feb  7 18:42:14 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 7 Feb 2023 18:42:14 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit
In-Reply-To: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
Message-ID: <LRtKXRE4cHAMZKH1J_Mt2rPxMxf_L-xaaiWHgHtCDwg=.049fdf82-0c34-4734-965e-8a3495a2baf7@github.com>

On Sat, 4 Feb 2023 08:59:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
> 
> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
> - Tests using data providers are changed to parameterized tests
> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
> - Usages of expectThrows are changed to assertThrows
> - Tests that threw SkipException are changed to the Assumptions API
> 
> There are a small number of drive-by changes to the tests, nothing significant, e.g.
> 
> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.

Changes look good Alan

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12426

From cjplummer at openjdk.org  Tue Feb  7 19:47:26 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 7 Feb 2023 19:47:26 GMT
Subject: RFR: 8299739: HashedPasswordFileTest.java and ExceptionTest.java
 can fail with java.lang.NullPointerException
In-Reply-To: <jpFfcft321u195bhJmtEFsX0tfkUvjUwl-P-OS5HoH8=.a7823f7c-9742-4ecd-a2d1-c98fac09313b@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
 <jpFfcft321u195bhJmtEFsX0tfkUvjUwl-P-OS5HoH8=.a7823f7c-9742-4ecd-a2d1-c98fac09313b@github.com>
Message-ID: <WXFVUbPaEP8vVEzCvgJQkzCk5fDH4T27vHiK_w2ZtSM=.001c92c7-b7b0-408d-bb3e-f1a4c6e4c333@github.com>

On Tue, 7 Feb 2023 01:58:15 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> My only guess is ExceptionTest failed with some Error, so catch (Exception) didn't catch it

Yes, that makes sense. Kevin, can you try changing this to catch Throwable and see if you can get the initial exception printed?

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

PR: https://git.openjdk.org/jdk/pull/11881

From cjplummer at openjdk.org  Wed Feb  8 04:22:16 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Feb 2023 04:22:16 GMT
Subject: RFR: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails [v3]
In-Reply-To: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
References: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
Message-ID: <62ZKDafTprIia8l5QIFhcnQCtvezYHepQEqUPlPV7Qs=.8fea3324-95e9-4c93-816d-51ebe8bb78fd@github.com>

> A number of tests that use JDI invokeMethod() support occasionally fail when run using virtual threads. The tests fail with:
> 
> 
> # ERROR: TEST FAILED: wrong invocation:
> # ERROR: invoking debuggee thread instance of java.lang.VirtualThread(name='invokemethod010tThr', id=272)
> # ERROR: is not suspended again after the invocation 
> 
> 
> Although as explained later, this is a misleading message, and does not accurately reflect why the test is failing. More on that below.
> 
> The root cause of the failure is due to these tests using JDI invokeMethod support with the  INVOKE_SINGLE_THREADED flag. This is not always going to work with virtual threads because the invoked method is doing a Thread.sleep(400), and that is at risk of blocking indefinitely if all other threads are blocked form making progress. Note that technically platform threads could fail in the same manner. However, the reason the failure only happens now with virtual threads is because the implementation of Thread.sleep() differs for virtual threads, and may require ownership of a monitor that sometimes is held by another thread.
> 
> Another issue is that the tests do not do a very good job of error handling when this happens, and give the misleading failure reason of the invoked thread not being suspended after the invoke completed. The reason it is not suspended is because the invoke has actually not completed. There was a timeout that the test did not properly note as the cause of the failure. The test (debugger side) spawns a thread to do the JDI invokeMethod with, and then waits for it with:
> 
>                 invThr.join(argHandler.getWaitTime()*60000);
> 
> This join() times out, but the test assumes once it returns the invoke is complete, even though the invoked thread is actually still in the middle of the invoke. So that is the reason debuggee invokemethod thread is not currently suspended. I've fixed this by having a test check if invThr is still alive after the join. If it is, then the test is made to fail at that point, rather than continuing on and checking the debuggee threads status. The failure then becomes:
> 
> nsk.share.TestFailure: TEST FAILED: invoke never completed
> 
> At that point a vm.resume() is done to allow the invoke to complete, and the test will exit with this failure.
> 
> As for avoiding the failure in the first place (the deadlock in the debuggee during the invoke), this is really a test bug for relying on INVOKE_SINGLE_THREADED and assuming that the invoked thread won't become deadlocked. Since there is a Thread.sleep() call in the invoked method, it can't make this assumption. From the ObjectReference.invoke() spec:
> 
> "By default, all threads in the target VM are resumed while the method is being invoked if they were previously suspended by an event or by VirtualMachine.suspend() or ThreadReference.suspend(). This is done to prevent the deadlocks that will occur if any of the threads own monitors that will be needed by the invoked method."
> 
> "The resumption of other threads during the invocation can be prevented by specifying the INVOKE_SINGLE_THREADED bit flag in the options argument; however, there is no protection against or recovery from the deadlocks described above, so this option should be used with great caution."
> 
> For platform threads, sleep() doesn't require any monitors, so these tests never ran into problems before. For virtual threads however there is some synchronization done, and potential reliance on other threads not being suspended. A way around this is to always use sleep(0), which will at least attempt to yield the thread. For platform threads an actual yield is likely. For a virtual thread it will not yield in this particular case because the virtual thread is pinned to the carrier thread due to the jvmti breakpoint callback that is currently in the call chain of the invoked thread. So for virtual threads this effectively the same as sitting in a spin loop with no yielding. This is ok. CPU wasting is not a concern.

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

  Get rid of sleep(0). Add warning comment to invoked method.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12420/files
  - new: https://git.openjdk.org/jdk/pull/12420/files/c1bcaef5..7d6cb24b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12420&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12420&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/12420

From sspitsyn at openjdk.org  Wed Feb  8 06:00:47 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 Feb 2023 06:00:47 GMT
Subject: RFR: 8297638: Memory leak in case of many started-dead threads
 [v2]
In-Reply-To: <6A-Igi24IpuNPsjq1vJMscoKvujmMvYqDuMq6BncUsI=.9102a5c7-2f90-444c-b79a-00cb82b809bb@github.com>
References: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com>
 <6A-Igi24IpuNPsjq1vJMscoKvujmMvYqDuMq6BncUsI=.9102a5c7-2f90-444c-b79a-00cb82b809bb@github.com>
Message-ID: <N2vrKRRkPwm1ta2KWLnqDgncx2_1U4t-gajou41SsQQ=.21c05fbf-c79e-4fac-a6ec-a20d81879f40@github.com>

On Thu, 19 Jan 2023 21:59:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Fix JDI leak when the debuggee creates a lot of threads, while at the same the debugger is not sending any commands. The lack of commands being sent results in code not being triggered that normally would clear out unreachable listeners and also clear out ObjectReferences queued for disposal.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaned up removeUnreachableListeners().

Looks good.
Sorry for latency.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12081

From cjplummer at openjdk.org  Wed Feb  8 06:11:43 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Feb 2023 06:11:43 GMT
Subject: RFR: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails [v3]
In-Reply-To: <62ZKDafTprIia8l5QIFhcnQCtvezYHepQEqUPlPV7Qs=.8fea3324-95e9-4c93-816d-51ebe8bb78fd@github.com>
References: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
 <62ZKDafTprIia8l5QIFhcnQCtvezYHepQEqUPlPV7Qs=.8fea3324-95e9-4c93-816d-51ebe8bb78fd@github.com>
Message-ID: <0yQp6vwkMenLmrCGqiSg92SyzOAT4j1q5YuOgi-Jb0U=.e1595038-fbd3-4dc5-847d-063e055731f3@github.com>

On Wed, 8 Feb 2023 04:22:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> A number of tests that use JDI invokeMethod() support occasionally fail when run using virtual threads. The tests fail with:
>> 
>> 
>> # ERROR: TEST FAILED: wrong invocation:
>> # ERROR: invoking debuggee thread instance of java.lang.VirtualThread(name='invokemethod010tThr', id=272)
>> # ERROR: is not suspended again after the invocation 
>> 
>> 
>> Although as explained later, this is a misleading message, and does not accurately reflect why the test is failing. More on that below.
>> 
>> The root cause of the failure is due to these tests using JDI invokeMethod support with the  INVOKE_SINGLE_THREADED flag. This is not always going to work with virtual threads because the invoked method is doing a Thread.sleep(400), and that is at risk of blocking indefinitely if all other threads are blocked form making progress. Note that technically platform threads could fail in the same manner. However, the reason the failure only happens now with virtual threads is because the implementation of Thread.sleep() differs for virtual threads, and may require ownership of a monitor that sometimes is held by another thread.
>> 
>> Another issue is that the tests do not do a very good job of error handling when this happens, and give the misleading failure reason of the invoked thread not being suspended after the invoke completed. The reason it is not suspended is because the invoke has actually not completed. There was a timeout that the test did not properly note as the cause of the failure. The test (debugger side) spawns a thread to do the JDI invokeMethod with, and then waits for it with:
>> 
>>                 invThr.join(argHandler.getWaitTime()*60000);
>> 
>> This join() times out, but the test assumes once it returns the invoke is complete, even though the invoked thread is actually still in the middle of the invoke. So that is the reason debuggee invokemethod thread is not currently suspended. I've fixed this by having a test check if invThr is still alive after the join. If it is, then the test is made to fail at that point, rather than continuing on and checking the debuggee threads status. The failure then becomes:
>> 
>> nsk.share.TestFailure: TEST FAILED: invoke never completed
>> 
>> At that point a vm.resume() is done to allow the invoke to complete, and the test will exit with this failure.
>> 
>> As for avoiding the failure in the first place (the deadlock in the debuggee during the invoke), this is really a test bug for relying on INVOKE_SINGLE_THREADED and assuming that the invoked thread won't become deadlocked. Since there is a Thread.sleep() call in the invoked method, it can't make this assumption. From the ObjectReference.invoke() spec:
>> 
>> "By default, all threads in the target VM are resumed while the method is being invoked if they were previously suspended by an event or by VirtualMachine.suspend() or ThreadReference.suspend(). This is done to prevent the deadlocks that will occur if any of the threads own monitors that will be needed by the invoked method."
>> 
>> "The resumption of other threads during the invocation can be prevented by specifying the INVOKE_SINGLE_THREADED bit flag in the options argument; however, there is no protection against or recovery from the deadlocks described above, so this option should be used with great caution."
>> 
>> For platform threads, sleep() doesn't require any monitors, so these tests never ran into problems before. For virtual threads however there is some synchronization done, and potential reliance on other threads not being suspended. A way around this is to always use sleep(0), which will at least attempt to yield the thread. For platform threads an actual yield is likely. For a virtual thread it will not yield in this particular case because the virtual thread is pinned to the carrier thread due to the jvmti breakpoint callback that is currently in the call chain of the invoked thread. So for virtual threads this effectively the same as sitting in a spin loop with no yielding. This is ok. CPU wasting is not a concern.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of sleep(0). Add warning comment to invoked method.

All the tests now have the sleep() call removed and I added the warning comment.

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

PR: https://git.openjdk.org/jdk/pull/12420

From alanb at openjdk.org  Wed Feb  8 08:14:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 08:14:33 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
Message-ID: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>

> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
> 
> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
> - Tests using data providers are changed to parameterized tests
> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
> - Usages of expectThrows are changed to assertThrows
> - Tests that threw SkipException are changed to the Assumptions API
> 
> There are a small number of drive-by changes to the tests, nothing significant, e.g.
> 
> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge
 - Merge
 - Fix typos in comments
 - GetStackTrace.java test missing @requires vm.continuations
 - Initial commit

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

Changes: https://git.openjdk.org/jdk/pull/12426/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12426&range=01
  Stats: 1415 lines in 34 files changed: 205 ins; 79 del; 1131 mod
  Patch: https://git.openjdk.org/jdk/pull/12426.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12426/head:pull/12426

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 09:16:52 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 09:16:52 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
Message-ID: <ORxqaxpUaUXmz6N3cg0R5vYgFLswtxpi3BCh6xQF6tM=.1ffa8327-e143-4ef6-b479-53d2cd0451b9@github.com>

On Wed, 8 Feb 2023 08:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - Merge
>  - Fix typos in comments
>  - GetStackTrace.java test missing @requires vm.continuations
>  - Initial commit

test/jdk/java/lang/Thread/BuilderTest.java line 294:

> 292:     void testPriority3() {
> 293:         Thread currentThread = Thread.currentThread();
> 294:         assumeFalse(currentThread.isVirtual(), "Main test is a virtual thread");

Hello Alan, not specifically related to the changes in this PR, but should that message have been "Main thread ..." instead of "Main test ..."?

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

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 09:25:46 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 09:25:46 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <ORxqaxpUaUXmz6N3cg0R5vYgFLswtxpi3BCh6xQF6tM=.1ffa8327-e143-4ef6-b479-53d2cd0451b9@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <ORxqaxpUaUXmz6N3cg0R5vYgFLswtxpi3BCh6xQF6tM=.1ffa8327-e143-4ef6-b479-53d2cd0451b9@github.com>
Message-ID: <oBvBwEYRlbD2_liqdooldaUfQBz1nPVJvk9K1KOXa-Q=.c521a5dd-4450-4e26-8479-3f8c3450fba7@github.com>

On Wed, 8 Feb 2023 09:13:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge
>>  - Merge
>>  - Fix typos in comments
>>  - GetStackTrace.java test missing @requires vm.continuations
>>  - Initial commit
>
> test/jdk/java/lang/Thread/BuilderTest.java line 294:
> 
>> 292:     void testPriority3() {
>> 293:         Thread currentThread = Thread.currentThread();
>> 294:         assumeFalse(currentThread.isVirtual(), "Main test is a virtual thread");
> 
> Hello Alan, not specifically related to the changes in this PR, but should that message have been "Main thread ..." instead of "Main test ..."?

Same comment for test methods in `CustomScheduler`

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

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 09:25:48 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 09:25:48 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
Message-ID: <ntD3tzvoYDf6d5ZL3okOnC6sfcZPnsyr41aRPH4CN0o=.4eb4bccf-caf4-47d8-8901-c9d4d4362434@github.com>

On Wed, 8 Feb 2023 08:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - Merge
>  - Fix typos in comments
>  - GetStackTrace.java test missing @requires vm.continuations
>  - Initial commit

test/jdk/java/lang/Thread/UncaughtExceptionsTest.java line 30:

> 28: import org.junit.jupiter.api.Test;
> 29: import org.junit.jupiter.api.BeforeAll;
> 30: import org.junit.jupiter.api.AfterAll;

It looks like BeforeAll and AfterAll imports are unused in this test.

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

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 09:35:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 09:35:45 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
Message-ID: <L60W-QEFW8rqFe7wDJgs5chNinnVgkCkjXH0DK4WH34=.4de50ddb-b11d-422e-bc96-a6fc0e00dd17@github.com>

On Wed, 8 Feb 2023 08:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - Merge
>  - Fix typos in comments
>  - GetStackTrace.java test missing @requires vm.continuations
>  - Initial commit

test/jdk/java/lang/Thread/virtual/GetStackTrace.java line 31:

> 29:  * @enablePreview
> 30:  * @modules java.base/java.lang:+open
> 31:  * @run main GetStackTrace

That's interesting - so this test was marked as a testng test previously, but had not test methods in it. I had a look at the test run history of this one and I see that the test execution results in:

> java/lang/Thread/virtual/GetStackTrace.java
> Total tests run: 0, Passes: 0, Failures: 0, Skips: 0

I wonder if testng (and junit) can be configured to fail the test if no test methods were present, to flag such mistakes.

Keeping that aside, the change to make this `@run main` looks fine.

As for adding the `@requires vm.continuations`, I'm not familiar with its expectations. Looking at the test case, it just captures stacktraces using `Thread.getStackTrace()` and then just does some basic validation of those stacktrace elements. Do we use this `@requires vm.continuations` even in such tests?

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

PR: https://git.openjdk.org/jdk/pull/12426

From cstein at openjdk.org  Wed Feb  8 09:42:48 2023
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 8 Feb 2023 09:42:48 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <L60W-QEFW8rqFe7wDJgs5chNinnVgkCkjXH0DK4WH34=.4de50ddb-b11d-422e-bc96-a6fc0e00dd17@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <L60W-QEFW8rqFe7wDJgs5chNinnVgkCkjXH0DK4WH34=.4de50ddb-b11d-422e-bc96-a6fc0e00dd17@github.com>
Message-ID: <X2T458nbl6j97CLOuAUc8sytIPfAjVkjZWYTxEK-H1w=.b2cc8410-2245-4f6e-9dcf-5ebe6febeede@github.com>

On Wed, 8 Feb 2023 09:32:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I wonder if testng (and junit) can be configured to fail the test if no test methods were present, to flag such mistakes.

JUnit's CLI tool has:

`--fail-if-no-tests     Fail and return exit status code 2 if no tests are found.`

We can add such a check into `jtreg`'s JUnit runner at
https://github.com/openjdk/jtreg/blob/524161b73dca250639ad3f00a42518e384276906/src/share/classes/com/sun/javatest/regtest/agent/JUnitRunner.java#L149-L151

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

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 09:42:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 09:42:54 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
Message-ID: <Elipcpaj2eeNZPXIpFI1r4spLHR1fWUb8F7OHxKfyhQ=.028ac978-837c-432c-aac4-7435e87ecfdd@github.com>

On Wed, 8 Feb 2023 08:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - Merge
>  - Fix typos in comments
>  - GetStackTrace.java test missing @requires vm.continuations
>  - Initial commit

test/jdk/java/lang/Thread/virtual/HoldsLock.java line 131:

> 129:                 assertEquals(vthread.getClass().getName(), info.getLockInfo().getClassName());
> 130:                 assertTrue(info.getLockInfo().getIdentityHashCode() == System.identityHashCode(vthread));
> 131:                 assertTrue(info.getLockOwnerId() == vthreadId);

Previously, before the change to these lines, in case of failure, the `assertEquals` would have printed even the incorrect/unexpected value in the log file/exception. Now with the usage of `assertTrue`, that information is lost from the failures. Do you think, in the context of this test, it would be worth to continue using assertEquals and just switch the param order to match junit expectations.

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

PR: https://git.openjdk.org/jdk/pull/12426

From alanb at openjdk.org  Wed Feb  8 09:51:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 09:51:44 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <oBvBwEYRlbD2_liqdooldaUfQBz1nPVJvk9K1KOXa-Q=.c521a5dd-4450-4e26-8479-3f8c3450fba7@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <ORxqaxpUaUXmz6N3cg0R5vYgFLswtxpi3BCh6xQF6tM=.1ffa8327-e143-4ef6-b479-53d2cd0451b9@github.com>
 <oBvBwEYRlbD2_liqdooldaUfQBz1nPVJvk9K1KOXa-Q=.c521a5dd-4450-4e26-8479-3f8c3450fba7@github.com>
Message-ID: <Hx-ZBOj60zEPGka1-UHfE6S4Cp7botqKZz0qSPIXzp4=.2657065e-f1d8-4b18-9cc7-b4ac5e903521@github.com>

On Wed, 8 Feb 2023 09:22:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/lang/Thread/BuilderTest.java line 294:
>> 
>>> 292:     void testPriority3() {
>>> 293:         Thread currentThread = Thread.currentThread();
>>> 294:         assumeFalse(currentThread.isVirtual(), "Main test is a virtual thread");
>> 
>> Hello Alan, not specifically related to the changes in this PR, but should that message have been "Main thread ..." instead of "Main test ..."?
>
> Same comment for test methods in `CustomScheduler`

Well spotted. This was a find+replace change so I didn't notice that the original exception message had a typo.

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

PR: https://git.openjdk.org/jdk/pull/12426

From alanb at openjdk.org  Wed Feb  8 09:51:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 09:51:46 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <X2T458nbl6j97CLOuAUc8sytIPfAjVkjZWYTxEK-H1w=.b2cc8410-2245-4f6e-9dcf-5ebe6febeede@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <L60W-QEFW8rqFe7wDJgs5chNinnVgkCkjXH0DK4WH34=.4de50ddb-b11d-422e-bc96-a6fc0e00dd17@github.com>
 <X2T458nbl6j97CLOuAUc8sytIPfAjVkjZWYTxEK-H1w=.b2cc8410-2245-4f6e-9dcf-5ebe6febeede@github.com>
Message-ID: <3L-yZYrXApfYMYtQ5uBGVyrD9O5ExrY2MsgrG6pbEMQ=.d0e9d875-4e9e-46a7-8a90-9f15b6448d17@github.com>

On Wed, 8 Feb 2023 09:39:37 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> test/jdk/java/lang/Thread/virtual/GetStackTrace.java line 31:
>> 
>>> 29:  * @enablePreview
>>> 30:  * @modules java.base/java.lang:+open
>>> 31:  * @run main GetStackTrace
>> 
>> That's interesting - so this test was marked as a testng test previously, but had not test methods in it. I had a look at the test run history of this one and I see that the test execution results in:
>> 
>>> java/lang/Thread/virtual/GetStackTrace.java
>>> Total tests run: 0, Passes: 0, Failures: 0, Skips: 0
>> 
>> I wonder if testng (and junit) can be configured to fail the test if no test methods were present, to flag such mistakes.
>> 
>> Keeping that aside, the change to make this `@run main` looks fine.
>> 
>> As for adding the `@requires vm.continuations`, I'm not familiar with its expectations. Looking at the test case, it just captures stacktraces using `Thread.getStackTrace()` and then just does some basic validation of those stacktrace elements. Do we use this `@requires vm.continuations` even in such tests?
>
>> I wonder if testng (and junit) can be configured to fail the test if no test methods were present, to flag such mistakes.
> 
> JUnit's CLI tool has:
> 
> `--fail-if-no-tests     Fail and return exit status code 2 if no tests are found.`
> 
> We can add such a check into `jtreg`'s JUnit runner at
> https://github.com/openjdk/jtreg/blob/524161b73dca250639ad3f00a42518e384276906/src/share/classes/com/sun/javatest/regtest/agent/JUnitRunner.java#L149-L151

> As for adding the `@requires vm.continuations`, I'm not familiar with its expectations. Looking at the test case, it just captures stacktraces using `Thread.getStackTrace()` and then just does some basic validation of those stacktrace elements. Do we use this `@requires vm.continuations` even in such tests?

Yes, it is needed as the alternative implementation of virtual threads (used on x86_32 and a few other ports) don't allow custom schedulers.

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

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 09:51:50 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 09:51:50 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
Message-ID: <60s9cige1Vx5fbCW0HoSE6UbfTwn-lWYkvX9PLDLFt4=.5c5c67dd-b0bd-4fe8-86d2-e5d812436fb9@github.com>

On Wed, 8 Feb 2023 08:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - Merge
>  - Fix typos in comments
>  - GetStackTrace.java test missing @requires vm.continuations
>  - Initial commit

test/jdk/java/lang/Thread/virtual/ThreadAPI.java line 82:

> 80:     @BeforeAll
> 81:     static void setup() throws Exception {
> 82:         ThreadFactory factory = Executors.defaultThreadFactory();

Unlike previously, this change now uses a `ThreadFactory` which creates non-daemon threads. Is that intentional?

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

PR: https://git.openjdk.org/jdk/pull/12426

From alanb at openjdk.org  Wed Feb  8 09:54:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 09:54:45 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <60s9cige1Vx5fbCW0HoSE6UbfTwn-lWYkvX9PLDLFt4=.5c5c67dd-b0bd-4fe8-86d2-e5d812436fb9@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <60s9cige1Vx5fbCW0HoSE6UbfTwn-lWYkvX9PLDLFt4=.5c5c67dd-b0bd-4fe8-86d2-e5d812436fb9@github.com>
Message-ID: <PyjsxQ6AWh5l7ErmTbt-qUNyeYPjLbo-p3D7N7o4zGo=.65eb199e-9adb-4499-84ca-eeef782275d8@github.com>

On Wed, 8 Feb 2023 09:49:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge
>>  - Merge
>>  - Fix typos in comments
>>  - GetStackTrace.java test missing @requires vm.continuations
>>  - Initial commit
>
> test/jdk/java/lang/Thread/virtual/ThreadAPI.java line 82:
> 
>> 80:     @BeforeAll
>> 81:     static void setup() throws Exception {
>> 82:         ThreadFactory factory = Executors.defaultThreadFactory();
> 
> Unlike previously, this change now uses a `ThreadFactory` which creates non-daemon threads. Is that intentional?

It's not an issue. The `@AfterAll` finish method does the shutdown so it doesn't matter if the STPE threads are daemon or not.

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

PR: https://git.openjdk.org/jdk/pull/12426

From alanb at openjdk.org  Wed Feb  8 10:26:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 10:26:12 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v3]
In-Reply-To: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
Message-ID: <cIruXOF-Q6fcx9ZYYBaM6yJlTxoCh-sAy5K0z7mJndU=.4f84f9e9-6e76-4b87-b460-9c15ca8f94a5@github.com>

> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
> 
> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
> - Tests using data providers are changed to parameterized tests
> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
> - Usages of expectThrows are changed to assertThrows
> - Tests that threw SkipException are changed to the Assumptions API
> 
> There are a small number of drive-by changes to the tests, nothing significant, e.g.
> 
> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.

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

  Fix typo in assumption message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12426/files
  - new: https://git.openjdk.org/jdk/pull/12426/files/7dc07c4b..75176342

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12426&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12426&range=01-02

  Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12426.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12426/head:pull/12426

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 10:26:15 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 10:26:15 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
Message-ID: <oXcM_Fltsi1oxChITx4PhE_IBY8bN-PeduFear4gGDE=.1da4240d-678e-41a6-bf8a-96132831eba7@github.com>

On Wed, 8 Feb 2023 08:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - Merge
>  - Fix typos in comments
>  - GetStackTrace.java test missing @requires vm.continuations
>  - Initial commit

test/jdk/jdk/incubator/concurrent/ScopedValue/ScopeValueAPI.java line 310:

> 308:             ScopedValue.where(name, null, () -> {
> 309:                 assertTrue(name.isBound());
> 310:                 assertTrue(name.get() == null);

Perhaps `assertNull(name.get())`?. Same on line 325.

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

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 10:32:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 10:32:45 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
Message-ID: <u5_YHDGu-eiFXGelIbl_Aa130SIfzwvyrG2dp2q6Ao4=.954e07e1-c46d-4a9e-944b-704bb0e7540f@github.com>

On Wed, 8 Feb 2023 08:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - Merge
>  - Fix typos in comments
>  - GetStackTrace.java test missing @requires vm.continuations
>  - Initial commit

test/jdk/jdk/internal/misc/ThreadFlock/ThreadFlockTest.java line 92:

> 90:             assertTrue(flock.name() == null);
> 91:             flock.close();
> 92:             assertTrue(flock.name() == null);  // after close

assertNull, here and line 90?

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

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 10:39:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 10:39:45 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
Message-ID: <pRk9Bm5maTzevQy3-dF5KCc55GkwxBFSJW5MEELi8fg=.500f3452-e14e-49ce-845e-16ce5214afc4@github.com>

On Wed, 8 Feb 2023 08:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - Merge
>  - Fix typos in comments
>  - GetStackTrace.java test missing @requires vm.continuations
>  - Initial commit

test/jdk/jdk/internal/misc/ThreadFlock/WithScopedValue.java line 48:

> 46: 
> 47:     private static Stream<ThreadFactory> factories() {
> 48:         return Stream.of(Thread.ofPlatform().factory(), Thread.ofVirtual().factory());

Previously, before this change, the data provided to the test methods, comprised of a virtual ThreadFactory and a `Executors.defaultThreadFactory()`. Is this switch to using a `Thread.ofPlatform().factory()` OK in the context of this test?

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

PR: https://git.openjdk.org/jdk/pull/12426

From alanb at openjdk.org  Wed Feb  8 11:28:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 11:28:44 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <pRk9Bm5maTzevQy3-dF5KCc55GkwxBFSJW5MEELi8fg=.500f3452-e14e-49ce-845e-16ce5214afc4@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <pRk9Bm5maTzevQy3-dF5KCc55GkwxBFSJW5MEELi8fg=.500f3452-e14e-49ce-845e-16ce5214afc4@github.com>
Message-ID: <pIrSEwmja8aPlCL2-KA9Ls0HEH9MAgrYCB7LU1HxQeQ=.c9dd145e-7df0-425d-902e-4f3922c84bd3@github.com>

On Wed, 8 Feb 2023 10:37:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge
>>  - Merge
>>  - Fix typos in comments
>>  - GetStackTrace.java test missing @requires vm.continuations
>>  - Initial commit
>
> test/jdk/jdk/internal/misc/ThreadFlock/WithScopedValue.java line 48:
> 
>> 46: 
>> 47:     private static Stream<ThreadFactory> factories() {
>> 48:         return Stream.of(Thread.ofPlatform().factory(), Thread.ofVirtual().factory());
> 
> Previously, before this change, the data provided to the test methods, comprised of a virtual ThreadFactory and a `Executors.defaultThreadFactory()`. Is this switch to using a `Thread.ofPlatform().factory()` OK in the context of this test?

The tests run with both platform and virtual threads, it doesn't matter if the ThreadFactory for platform threads is Thread.ofPlatform().factory() or Executors.defaultThreadFactory(). It is changed to be former so it's consistent with the other tests.

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

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 11:53:43 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 11:53:43 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <3L-yZYrXApfYMYtQ5uBGVyrD9O5ExrY2MsgrG6pbEMQ=.d0e9d875-4e9e-46a7-8a90-9f15b6448d17@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <L60W-QEFW8rqFe7wDJgs5chNinnVgkCkjXH0DK4WH34=.4de50ddb-b11d-422e-bc96-a6fc0e00dd17@github.com>
 <X2T458nbl6j97CLOuAUc8sytIPfAjVkjZWYTxEK-H1w=.b2cc8410-2245-4f6e-9dcf-5ebe6febeede@github.com>
 <3L-yZYrXApfYMYtQ5uBGVyrD9O5ExrY2MsgrG6pbEMQ=.d0e9d875-4e9e-46a7-8a90-9f15b6448d17@github.com>
Message-ID: <XydoShVXrynsAMVfzSD-ZsQ7gujMO3g_XeDrFx1YxYQ=.30cdf3cd-e1be-4f3c-b155-8f6244779619@github.com>

On Wed, 8 Feb 2023 09:47:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> as the alternative implementation of virtual threads (used on x86_32 and a few other ports) don't allow custom schedulers.

Thank you for that detail.

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

PR: https://git.openjdk.org/jdk/pull/12426

From alanb at openjdk.org  Wed Feb  8 12:25:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 12:25:30 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v4]
In-Reply-To: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
Message-ID: <aK7UhZmA39CX1XvdwYBpzknTtICsI_m7RGq6p6pBBdA=.be56bf29-bfb3-496c-a1da-50db5c895781@github.com>

> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
> 
> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
> - Tests using data providers are changed to parameterized tests
> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
> - Usages of expectThrows are changed to assertThrows
> - Tests that threw SkipException are changed to the Assumptions API
> 
> There are a small number of drive-by changes to the tests, nothing significant, e.g.
> 
> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.

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

  Replace assertTrue(x == null) with assertNull(x)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12426/files
  - new: https://git.openjdk.org/jdk/pull/12426/files/75176342..86af1887

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12426&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12426&range=02-03

  Stats: 47 lines in 6 files changed: 1 ins; 0 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/12426.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12426/head:pull/12426

PR: https://git.openjdk.org/jdk/pull/12426

From alanb at openjdk.org  Wed Feb  8 12:25:37 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 12:25:37 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <Elipcpaj2eeNZPXIpFI1r4spLHR1fWUb8F7OHxKfyhQ=.028ac978-837c-432c-aac4-7435e87ecfdd@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <Elipcpaj2eeNZPXIpFI1r4spLHR1fWUb8F7OHxKfyhQ=.028ac978-837c-432c-aac4-7435e87ecfdd@github.com>
Message-ID: <CIC1WkGt_mMOaWAd2Dp57x7jz8teQXznUYj4nSoTsNM=.590384c0-43c3-48ef-b8ef-319d4123012f@github.com>

On Wed, 8 Feb 2023 09:39:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge
>>  - Merge
>>  - Fix typos in comments
>>  - GetStackTrace.java test missing @requires vm.continuations
>>  - Initial commit
>
> test/jdk/java/lang/Thread/virtual/HoldsLock.java line 131:
> 
>> 129:                 assertEquals(vthread.getClass().getName(), info.getLockInfo().getClassName());
>> 130:                 assertTrue(info.getLockInfo().getIdentityHashCode() == System.identityHashCode(vthread));
>> 131:                 assertTrue(info.getLockOwnerId() == vthreadId);
> 
> Previously, before the change to these lines, in case of failure, the `assertEquals` would have printed even the incorrect/unexpected value in the log file/exception. Now with the usage of `assertTrue`, that information is lost from the failures. Do you think, in the context of this test, it would be worth to continue using assertEquals and just switch the param order to match junit expectations.

We will be coming back to this test in the future (part of it is disabled) so we can re-visit this test at that time.

> Perhaps `assertNull(name.get())`?. Same on line 325.

Okay, we can do that, note that it impacts 45+ usages and I had hoped to avoid changing the tests too much.

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

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 12:25:39 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 12:25:39 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <CIC1WkGt_mMOaWAd2Dp57x7jz8teQXznUYj4nSoTsNM=.590384c0-43c3-48ef-b8ef-319d4123012f@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <Elipcpaj2eeNZPXIpFI1r4spLHR1fWUb8F7OHxKfyhQ=.028ac978-837c-432c-aac4-7435e87ecfdd@github.com>
 <CIC1WkGt_mMOaWAd2Dp57x7jz8teQXznUYj4nSoTsNM=.590384c0-43c3-48ef-b8ef-319d4123012f@github.com>
Message-ID: <g0Crvt_GRhQfB20XlJ7HVF5D2rjArzAgbOPH-UAmzj4=.a4a38feb-edb4-43d9-82ed-c725573ad057@github.com>

On Wed, 8 Feb 2023 12:18:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> note that it impacts 45+ usages and I had hoped to avoid changing the tests too much.

I hadn't realized this construct was used in multiple other places. I see that you already fixed them in a newer commit in this PR; thank you.

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

PR: https://git.openjdk.org/jdk/pull/12426

From kevinw at openjdk.org  Wed Feb  8 12:28:31 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 8 Feb 2023 12:28:31 GMT
Subject: RFR: 8302069:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java update
Message-ID: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>

NotifReconnectDeadlockTest.java has been problemlisted for a long time (although 8042215 is the wrong bug id).

The originally reported problem ("No reconnection happened") cannot be reproduced, although there are occasional failures when the test is run.

Those failures are more like the connection failures fixed in similar tests (e.g. JDK-8227337), where:
java.rmi.NoSuchObjectException: no such object in table
..is reported, a startup issue, before the notification work, a failure to connect:
at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
at NotifReconnectDeadlockTest.main(NotifReconnectDeadlockTest.java:88)

We should do something similar here, but not such that it affects the deadlock timing.  Increase serverTimeout, it needs a longer timeout to permit the initial connect to work reliably (fails occasionally, particularly but not exclusively on Windows debug builds).  Not using the test library timeout scaling here as the timeout has to be kept fairly short, to let the test intentionally block the notification handler and try to cause the original issue.

Additional prints to make the test logs hopefully easier to follow, and tried to clarify a few comments that made no sense to me.

Passing on many runs on all platforms.

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

Commit messages:
 - 8042596: javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java No reconnection happened

Changes: https://git.openjdk.org/jdk/pull/12472/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12472&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302069
  Stats: 16 lines in 2 files changed: 6 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12472.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12472/head:pull/12472

PR: https://git.openjdk.org/jdk/pull/12472

From jpai at openjdk.org  Wed Feb  8 12:32:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 12:32:45 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <CIC1WkGt_mMOaWAd2Dp57x7jz8teQXznUYj4nSoTsNM=.590384c0-43c3-48ef-b8ef-319d4123012f@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <Elipcpaj2eeNZPXIpFI1r4spLHR1fWUb8F7OHxKfyhQ=.028ac978-837c-432c-aac4-7435e87ecfdd@github.com>
 <CIC1WkGt_mMOaWAd2Dp57x7jz8teQXznUYj4nSoTsNM=.590384c0-43c3-48ef-b8ef-319d4123012f@github.com>
Message-ID: <w0J-G-j-jphFNYAj8WD7LTGSm_rKJ31p05lHfBUB30I=.a8c108f8-cc75-4242-bf63-f87b5748ca9e@github.com>

On Wed, 8 Feb 2023 12:19:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/lang/Thread/virtual/HoldsLock.java line 131:
>> 
>>> 129:                 assertEquals(vthread.getClass().getName(), info.getLockInfo().getClassName());
>>> 130:                 assertTrue(info.getLockInfo().getIdentityHashCode() == System.identityHashCode(vthread));
>>> 131:                 assertTrue(info.getLockOwnerId() == vthreadId);
>> 
>> Previously, before the change to these lines, in case of failure, the `assertEquals` would have printed even the incorrect/unexpected value in the log file/exception. Now with the usage of `assertTrue`, that information is lost from the failures. Do you think, in the context of this test, it would be worth to continue using assertEquals and just switch the param order to match junit expectations.
>
> We will be coming back to this test in the future (part of it is disabled) so we can re-visit this test at that time.

That sounds fine to me.

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

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 12:37:46 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 12:37:46 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v4]
In-Reply-To: <aK7UhZmA39CX1XvdwYBpzknTtICsI_m7RGq6p6pBBdA=.be56bf29-bfb3-496c-a1da-50db5c895781@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <aK7UhZmA39CX1XvdwYBpzknTtICsI_m7RGq6p6pBBdA=.be56bf29-bfb3-496c-a1da-50db5c895781@github.com>
Message-ID: <y6BIxFJz7YUMAc9QVcOjULuYULIwfYgOUIE9nB5WHR0=.6db24067-2130-4e58-ad02-70b3eca01151@github.com>

On Wed, 8 Feb 2023 12:25:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace assertTrue(x == null) with assertNull(x)

Thank you Alan for the changes. The latest version of this PR (commit 86af1887), looks fine to me.

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

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12426

From kevinw at openjdk.org  Wed Feb  8 13:07:42 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 8 Feb 2023 13:07:42 GMT
Subject: RFR: 8299739: HashedPasswordFileTest.java and ExceptionTest.java
 can fail with java.lang.NullPointerException
In-Reply-To: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
Message-ID: <AiPFYMsaqZh4WydM9A1iGIKeiItyU1yDEPXANXjE6xc=.080facc6-4346-4bf4-ab27-8d79f5863cfd@github.com>

On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
> But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
> We must only call close if this is not null.

Yes, that's exactly what's happening...
The NPEs on the connection stop us seeing an earlier Error from e.g. the connection attempt, and an NPE is reported as the reason for the test failure.

If I add a "throw new OutOfMemoryError" before it makes the connection, then that is not seen with the original version, just the misleading NPE on the cleanup attempt in the finally block.

With the new null checks, that OutOfMemoryError is reported by the test harness as the reason for the test failure (JavaTest Message: Test threw exception: java.lang.OutOfMemoryError).  This seems like the kind of Error the test harness should be reporting for us (I don't think the test should necessarily catch Throwable/Error, but it should be well-behaved in its finally).

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

PR: https://git.openjdk.org/jdk/pull/11881

From alanb at openjdk.org  Wed Feb  8 15:00:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 15:00:06 GMT
Subject: Integrated: 8301767: Convert virtual thread tests to JUnit
In-Reply-To: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
Message-ID: <8MoZw1JVFGXMlFsi6xdcio3G5iqxS_rvJh0EcOJOn6s=.ba9fbe0d-c465-4ab8-b5c2-40717efc089f@github.com>

On Sat, 4 Feb 2023 08:59:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
> 
> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
> - Tests using data providers are changed to parameterized tests
> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
> - Usages of expectThrows are changed to assertThrows
> - Tests that threw SkipException are changed to the Assumptions API
> 
> There are a small number of drive-by changes to the tests, nothing significant, e.g.
> 
> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.

This pull request has now been integrated.

Changeset: ecf21a9a
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ecf21a9a24d067725fda916ab197b5711c56a1d7
Stats:     1456 lines in 34 files changed: 204 ins; 79 del; 1173 mod

8301767: Convert virtual thread tests to JUnit

Reviewed-by: cstein, lancea, jpai

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

PR: https://git.openjdk.org/jdk/pull/12426

From cjplummer at openjdk.org  Wed Feb  8 20:25:44 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Feb 2023 20:25:44 GMT
Subject: RFR: 8299739: HashedPasswordFileTest.java and ExceptionTest.java
 can fail with java.lang.NullPointerException
In-Reply-To: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
Message-ID: <HMtu4_XECp9l6qpiecEquY09AqNo6DbMTNL9aqgSivI=.3c4159e9-e793-424e-83dc-a04e96720fb1@github.com>

On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
> But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
> We must only call close if this is not null.

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11881

From cjplummer at openjdk.org  Wed Feb  8 21:40:43 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Feb 2023 21:40:43 GMT
Subject: RFR: 8302069:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java update
In-Reply-To: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>
References: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>
Message-ID: <iVsUgWjYS6wgYdQHml8YlajJsZLq9eanO25M-q6KaQY=.0ec88b7d-59f4-4758-9533-cd6be7a59bd0@github.com>

On Wed, 8 Feb 2023 11:57:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> NotifReconnectDeadlockTest.java has been problemlisted for a long time (although 8042215 is the wrong bug id).
> 
> The originally reported problem ("No reconnection happened") cannot be reproduced, although there are occasional failures when the test is run.
> 
> Those failures are more like the connection failures fixed in similar tests (e.g. JDK-8227337), where:
> java.rmi.NoSuchObjectException: no such object in table
> ..is reported, a startup issue, before the notification work, a failure to connect:
> at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> at NotifReconnectDeadlockTest.main(NotifReconnectDeadlockTest.java:88)
> 
> We should do something similar here, but not such that it affects the deadlock timing.  Increase serverTimeout, it needs a longer timeout to permit the initial connect to work reliably (fails occasionally, particularly but not exclusively on Windows debug builds).  Not using the test library timeout scaling here as the timeout has to be kept fairly short, to let the test intentionally block the notification handler and try to cause the original issue.
> 
> Additional prints to make the test logs hopefully easier to follow, and tried to clarify a few comments that made no sense to me.
> 
> Passing on many runs on all platforms.

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12472

From pchilanomate at openjdk.org  Wed Feb  8 22:39:51 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 8 Feb 2023 22:39:51 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v5]
In-Reply-To: <ONO1PEI-tgHm4z4-mppmc-st3WhwecI3z9T-xKz4KgY=.0c905a1c-8124-4cb0-aecb-8bc377486600@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <ONO1PEI-tgHm4z4-mppmc-st3WhwecI3z9T-xKz4KgY=.0c905a1c-8124-4cb0-aecb-8bc377486600@github.com>
Message-ID: <RvWlkSKELZdDeDouaXRt44aoWy1dBZRbvqpCMXNhlJE=.d4a11af6-5f9a-4f10-ac82-3109653f5eec@github.com>

On Sat, 24 Dec 2022 04:14:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
>> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
>> 
>> Testing:
>>   mach5 jobs are TBD (preliminary testing was completed):
>>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>>    - Kitchensink
>>    - tier5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix race between VTMS_transition_disable_for_one and start_VTMS_transition

Hi Serguei,

I looked at the latest changes and it all looks good to me. Thanks!

Patricio

src/hotspot/share/prims/jvmtiThreadState.cpp line 376:

> 374:   Atomic::dec(&_VTMS_transition_disable_for_one_count);
> 375:   if (_VTMS_transition_disable_for_one_count == 0 || _is_SR) {
> 376:     ml.notify_all();

I was going to say that we don't really need the global _VTMS_transition_disable_for_one_count since we can notify here if java_lang_Thread::VTMS_transition_disable_count(vth()) is zero, which is what the target checks. But I realized everybody uses the same lock so we would be notifying everybody. Using _VTMS_transition_disable_for_one_count as it is at least we notify everybody at once when there are no more single disablers. Not sure if that was the purpose, otherwise I think we could remove it.

src/hotspot/share/prims/jvmtiThreadState.cpp line 479:

> 477: 
> 478:   // Unblock waiting VTMS transition disablers.
> 479:   if (_VTMS_transition_disable_for_one_count > 0 ||

In here it would actually be the other way. If we would check java_lang_Thread::VTMS_transition_disable_count(vth()) > 0 instead of the global _VTMS_transition_disable_for_one_count we would avoid the notify in case there are singler disablers waiting but not for this thread.

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

Marked as reviewed by pchilanomate (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11690

From dholmes at openjdk.org  Thu Feb  9 02:41:43 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Feb 2023 02:41:43 GMT
Subject: RFR: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails [v3]
In-Reply-To: <62ZKDafTprIia8l5QIFhcnQCtvezYHepQEqUPlPV7Qs=.8fea3324-95e9-4c93-816d-51ebe8bb78fd@github.com>
References: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
 <62ZKDafTprIia8l5QIFhcnQCtvezYHepQEqUPlPV7Qs=.8fea3324-95e9-4c93-816d-51ebe8bb78fd@github.com>
Message-ID: <Z-BYzhUOfe3EwaJxjUsRVURqfR8YIH-NNJTWKLcoVek=.9ceacfa7-7b37-48fc-af66-ead54ea2a4c4@github.com>

On Wed, 8 Feb 2023 04:22:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> A number of tests that use JDI invokeMethod() support occasionally fail when run using virtual threads. The tests fail with:
>> 
>> 
>> # ERROR: TEST FAILED: wrong invocation:
>> # ERROR: invoking debuggee thread instance of java.lang.VirtualThread(name='invokemethod010tThr', id=272)
>> # ERROR: is not suspended again after the invocation 
>> 
>> 
>> Although as explained later, this is a misleading message, and does not accurately reflect why the test is failing. More on that below.
>> 
>> The root cause of the failure is due to these tests using JDI invokeMethod support with the  INVOKE_SINGLE_THREADED flag. This is not always going to work with virtual threads because the invoked method is doing a Thread.sleep(400), and that is at risk of blocking indefinitely if all other threads are blocked form making progress. Note that technically platform threads could fail in the same manner. However, the reason the failure only happens now with virtual threads is because the implementation of Thread.sleep() differs for virtual threads, and may require ownership of a monitor that sometimes is held by another thread.
>> 
>> Another issue is that the tests do not do a very good job of error handling when this happens, and give the misleading failure reason of the invoked thread not being suspended after the invoke completed. The reason it is not suspended is because the invoke has actually not completed. There was a timeout that the test did not properly note as the cause of the failure. The test (debugger side) spawns a thread to do the JDI invokeMethod with, and then waits for it with:
>> 
>>                 invThr.join(argHandler.getWaitTime()*60000);
>> 
>> This join() times out, but the test assumes once it returns the invoke is complete, even though the invoked thread is actually still in the middle of the invoke. So that is the reason debuggee invokemethod thread is not currently suspended. I've fixed this by having a test check if invThr is still alive after the join. If it is, then the test is made to fail at that point, rather than continuing on and checking the debuggee threads status. The failure then becomes:
>> 
>> nsk.share.TestFailure: TEST FAILED: invoke never completed
>> 
>> At that point a vm.resume() is done to allow the invoke to complete, and the test will exit with this failure.
>> 
>> As for avoiding the failure in the first place (the deadlock in the debuggee during the invoke), this is really a test bug for relying on INVOKE_SINGLE_THREADED and assuming that the invoked thread won't become deadlocked. Since there is a Thread.sleep() call in the invoked method, it can't make this assumption. From the ObjectReference.invoke() spec:
>> 
>> "By default, all threads in the target VM are resumed while the method is being invoked if they were previously suspended by an event or by VirtualMachine.suspend() or ThreadReference.suspend(). This is done to prevent the deadlocks that will occur if any of the threads own monitors that will be needed by the invoked method."
>> 
>> "The resumption of other threads during the invocation can be prevented by specifying the INVOKE_SINGLE_THREADED bit flag in the options argument; however, there is no protection against or recovery from the deadlocks described above, so this option should be used with great caution."
>> 
>> For platform threads, sleep() doesn't require any monitors, so these tests never ran into problems before. For virtual threads however there is some synchronization done, and potential reliance on other threads not being suspended. A way around this is to always use sleep(0), which will at least attempt to yield the thread. For platform threads an actual yield is likely. For a virtual thread it will not yield in this particular case because the virtual thread is pinned to the carrier thread due to the jvmti breakpoint callback that is currently in the call chain of the invoked thread. So for virtual threads this effectively the same as sitting in a spin loop with no yielding. This is ok. CPU wasting is not a concern.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of sleep(0). Add warning comment to invoked method.

Okay by me. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12420

From sspitsyn at openjdk.org  Thu Feb  9 08:54:46 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 Feb 2023 08:54:46 GMT
Subject: RFR: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails [v3]
In-Reply-To: <62ZKDafTprIia8l5QIFhcnQCtvezYHepQEqUPlPV7Qs=.8fea3324-95e9-4c93-816d-51ebe8bb78fd@github.com>
References: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
 <62ZKDafTprIia8l5QIFhcnQCtvezYHepQEqUPlPV7Qs=.8fea3324-95e9-4c93-816d-51ebe8bb78fd@github.com>
Message-ID: <HSUoSoh-bRk7_L1lgxFxcS1qKVt7LJP_Fui--i4UM-k=.3925ff06-91df-4ad3-831b-bd72be6b8ea5@github.com>

On Wed, 8 Feb 2023 04:22:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> A number of tests that use JDI invokeMethod() support occasionally fail when run using virtual threads. The tests fail with:
>> 
>> 
>> # ERROR: TEST FAILED: wrong invocation:
>> # ERROR: invoking debuggee thread instance of java.lang.VirtualThread(name='invokemethod010tThr', id=272)
>> # ERROR: is not suspended again after the invocation 
>> 
>> 
>> Although as explained later, this is a misleading message, and does not accurately reflect why the test is failing. More on that below.
>> 
>> The root cause of the failure is due to these tests using JDI invokeMethod support with the  INVOKE_SINGLE_THREADED flag. This is not always going to work with virtual threads because the invoked method is doing a Thread.sleep(400), and that is at risk of blocking indefinitely if all other threads are blocked form making progress. Note that technically platform threads could fail in the same manner. However, the reason the failure only happens now with virtual threads is because the implementation of Thread.sleep() differs for virtual threads, and may require ownership of a monitor that sometimes is held by another thread.
>> 
>> Another issue is that the tests do not do a very good job of error handling when this happens, and give the misleading failure reason of the invoked thread not being suspended after the invoke completed. The reason it is not suspended is because the invoke has actually not completed. There was a timeout that the test did not properly note as the cause of the failure. The test (debugger side) spawns a thread to do the JDI invokeMethod with, and then waits for it with:
>> 
>>                 invThr.join(argHandler.getWaitTime()*60000);
>> 
>> This join() times out, but the test assumes once it returns the invoke is complete, even though the invoked thread is actually still in the middle of the invoke. So that is the reason debuggee invokemethod thread is not currently suspended. I've fixed this by having a test check if invThr is still alive after the join. If it is, then the test is made to fail at that point, rather than continuing on and checking the debuggee threads status. The failure then becomes:
>> 
>> nsk.share.TestFailure: TEST FAILED: invoke never completed
>> 
>> At that point a vm.resume() is done to allow the invoke to complete, and the test will exit with this failure.
>> 
>> As for avoiding the failure in the first place (the deadlock in the debuggee during the invoke), this is really a test bug for relying on INVOKE_SINGLE_THREADED and assuming that the invoked thread won't become deadlocked. Since there is a Thread.sleep() call in the invoked method, it can't make this assumption. From the ObjectReference.invoke() spec:
>> 
>> "By default, all threads in the target VM are resumed while the method is being invoked if they were previously suspended by an event or by VirtualMachine.suspend() or ThreadReference.suspend(). This is done to prevent the deadlocks that will occur if any of the threads own monitors that will be needed by the invoked method."
>> 
>> "The resumption of other threads during the invocation can be prevented by specifying the INVOKE_SINGLE_THREADED bit flag in the options argument; however, there is no protection against or recovery from the deadlocks described above, so this option should be used with great caution."
>> 
>> For platform threads, sleep() doesn't require any monitors, so these tests never ran into problems before. For virtual threads however there is some synchronization done, and potential reliance on other threads not being suspended. A way around this is to always use sleep(0), which will at least attempt to yield the thread. For platform threads an actual yield is likely. For a virtual thread it will not yield in this particular case because the virtual thread is pinned to the carrier thread due to the jvmti breakpoint callback that is currently in the call chain of the invoked thread. So for virtual threads this effectively the same as sitting in a spin loop with no yielding. This is ok. CPU wasting is not a concern.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of sleep(0). Add warning comment to invoked method.

Marked as reviewed by sspitsyn (Reviewer).

Looks good.
Thanks,
Serguei

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

PR: https://git.openjdk.org/jdk/pull/12420

From kevinw at openjdk.org  Thu Feb  9 09:30:44 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 9 Feb 2023 09:30:44 GMT
Subject: RFR: 8299739: HashedPasswordFileTest.java and ExceptionTest.java
 can fail with java.lang.NullPointerException
In-Reply-To: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
Message-ID: <HafzDWTbQddQOVpeJJJW1brnnAHpfXNmHfX3i5xmUGs=.2ced21d7-1e9e-496a-a747-2533b4764977@github.com>

On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
> But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
> We must only call close if this is not null.

Thanks for all the comments/reviews.

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

PR: https://git.openjdk.org/jdk/pull/11881

From kevinw at openjdk.org  Thu Feb  9 09:33:54 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 9 Feb 2023 09:33:54 GMT
Subject: Integrated: 8299739: HashedPasswordFileTest.java and
 ExceptionTest.java can fail with java.lang.NullPointerException
In-Reply-To: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
References: <WucMed6wC52ogQSVVaElC72Z2D6UT-vidZlWFGWNrs4=.834ad756-ac66-4896-b5bd-ffb0a8347b08@github.com>
Message-ID: <mJ96BPcmVNrs8-xLecJKKEJuHEzgNH_Pk1bzV6ZJXp4=.b6b6b010-32b4-4133-b44b-9aad2f5ca403@github.com>

On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Exceptions during setup of these tests could leave e.g. JMXConnector cs as null.
> But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure.
> We must only call close if this is not null.

This pull request has now been integrated.

Changeset: 04f30185
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/04f30185e914c10c918d0eff1fb63fd96e1139fb
Stats:     18 lines in 2 files changed: 9 ins; 0 del; 9 mod

8299739: HashedPasswordFileTest.java and ExceptionTest.java can fail with java.lang.NullPointerException

Reviewed-by: sspitsyn, amenkov, cjplummer

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

PR: https://git.openjdk.org/jdk/pull/11881

From rkennke at openjdk.org  Thu Feb  9 12:48:02 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 9 Feb 2023 12:48:02 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v8]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <yTVPOTS5Hez-68txdwW3A_jBOJCoQmoTPV-L0ZCQF9M=.64321a59-4dc9-4dc2-9166-a8710adf55b0@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock.
> 
> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking.
> 
> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread.
> 
> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it.
> 
> This change enables to simplify (and speed-up!) a lot of code:
> 
> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header.
> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Renaissance
> 
> 
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

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

  Fix anon owner in fast-path, avoid runtime call (x86_64)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/bbe8c186..74f3974d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=06-07

  Stats: 34 lines in 3 files changed: 34 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Thu Feb  9 13:04:11 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 9 Feb 2023 13:04:11 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v9]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <m9lWACq6XIDNE38MxKkSJgUgRE2mj7WyKvV-htUNyn4=.2d06d649-9e38-4a18-b644-4cb7843b6f67@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock.
> 
> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking.
> 
> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread.
> 
> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it.
> 
> This change enables to simplify (and speed-up!) a lot of code:
> 
> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header.
> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Renaissance
> 
> 
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

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

  Fix anon owner in fast-path, avoid runtime call (aarch64)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/74f3974d..38dae002

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=07-08

  Stats: 29 lines in 3 files changed: 27 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Thu Feb  9 18:05:15 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 9 Feb 2023 18:05:15 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v10]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <BfUuYZE58J6gqnFQkxhDvmJtUNwpCGJr4H6tdGD_6uU=.7ab29674-c1c6-4f0d-b257-992c87ce41a7@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock.
> 
> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking.
> 
> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread.
> 
> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it.
> 
> This change enables to simplify (and speed-up!) a lot of code:
> 
> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header.
> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Renaissance
> 
> 
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

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

  Small fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/38dae002..2af1ce38

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=08-09

  Stats: 7 lines in 4 files changed: 0 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From cjplummer at openjdk.org  Thu Feb  9 18:28:54 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 9 Feb 2023 18:28:54 GMT
Subject: RFR: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails [v3]
In-Reply-To: <62ZKDafTprIia8l5QIFhcnQCtvezYHepQEqUPlPV7Qs=.8fea3324-95e9-4c93-816d-51ebe8bb78fd@github.com>
References: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
 <62ZKDafTprIia8l5QIFhcnQCtvezYHepQEqUPlPV7Qs=.8fea3324-95e9-4c93-816d-51ebe8bb78fd@github.com>
Message-ID: <YN5jf12MYFZFwlkRBVwjEfcFM6OQ6doQzK8o0ZNgUXU=.8d1f3456-fe2b-4c6b-a31a-a39abd5d776a@github.com>

On Wed, 8 Feb 2023 04:22:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> A number of tests that use JDI invokeMethod() support occasionally fail when run using virtual threads. The tests fail with:
>> 
>> 
>> # ERROR: TEST FAILED: wrong invocation:
>> # ERROR: invoking debuggee thread instance of java.lang.VirtualThread(name='invokemethod010tThr', id=272)
>> # ERROR: is not suspended again after the invocation 
>> 
>> 
>> Although as explained later, this is a misleading message, and does not accurately reflect why the test is failing. More on that below.
>> 
>> The root cause of the failure is due to these tests using JDI invokeMethod support with the  INVOKE_SINGLE_THREADED flag. This is not always going to work with virtual threads because the invoked method is doing a Thread.sleep(400), and that is at risk of blocking indefinitely if all other threads are blocked form making progress. Note that technically platform threads could fail in the same manner. However, the reason the failure only happens now with virtual threads is because the implementation of Thread.sleep() differs for virtual threads, and may require ownership of a monitor that sometimes is held by another thread.
>> 
>> Another issue is that the tests do not do a very good job of error handling when this happens, and give the misleading failure reason of the invoked thread not being suspended after the invoke completed. The reason it is not suspended is because the invoke has actually not completed. There was a timeout that the test did not properly note as the cause of the failure. The test (debugger side) spawns a thread to do the JDI invokeMethod with, and then waits for it with:
>> 
>>                 invThr.join(argHandler.getWaitTime()*60000);
>> 
>> This join() times out, but the test assumes once it returns the invoke is complete, even though the invoked thread is actually still in the middle of the invoke. So that is the reason debuggee invokemethod thread is not currently suspended. I've fixed this by having a test check if invThr is still alive after the join. If it is, then the test is made to fail at that point, rather than continuing on and checking the debuggee threads status. The failure then becomes:
>> 
>> nsk.share.TestFailure: TEST FAILED: invoke never completed
>> 
>> At that point a vm.resume() is done to allow the invoke to complete, and the test will exit with this failure.
>> 
>> As for avoiding the failure in the first place (the deadlock in the debuggee during the invoke), this is really a test bug for relying on INVOKE_SINGLE_THREADED and assuming that the invoked thread won't become deadlocked. Since there is a Thread.sleep() call in the invoked method, it can't make this assumption. From the ObjectReference.invoke() spec:
>> 
>> "By default, all threads in the target VM are resumed while the method is being invoked if they were previously suspended by an event or by VirtualMachine.suspend() or ThreadReference.suspend(). This is done to prevent the deadlocks that will occur if any of the threads own monitors that will be needed by the invoked method."
>> 
>> "The resumption of other threads during the invocation can be prevented by specifying the INVOKE_SINGLE_THREADED bit flag in the options argument; however, there is no protection against or recovery from the deadlocks described above, so this option should be used with great caution."
>> 
>> For platform threads, sleep() doesn't require any monitors, so these tests never ran into problems before. For virtual threads however there is some synchronization done, and potential reliance on other threads not being suspended. A way around this is to always use sleep(0), which will at least attempt to yield the thread. For platform threads an actual yield is likely. For a virtual thread it will not yield in this particular case because the virtual thread is pinned to the carrier thread due to the jvmti breakpoint callback that is currently in the call chain of the invoked thread. So for virtual threads this effectively the same as sitting in a spin loop with no yielding. This is ok. CPU wasting is not a concern.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of sleep(0). Add warning comment to invoked method.

Thanks for the reviews Serguei and David!

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

PR: https://git.openjdk.org/jdk/pull/12420

From cjplummer at openjdk.org  Thu Feb  9 18:28:55 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 9 Feb 2023 18:28:55 GMT
Subject: Integrated: 8282379: [LOOM]
 vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails
In-Reply-To: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
References: <1WQhFY0lxX5sYh1YKUul4PhaQDrpJR5Ko6pBo26DqI8=.679bd9f3-7de6-4288-b324-75071d727944@github.com>
Message-ID: <uH0IZzfYThbxCl9GE63Z2ci32lPH__AkXce8koNq9mo=.5a33a2d7-69e5-4025-9997-1afcfda85640@github.com>

On Fri, 3 Feb 2023 21:40:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> A number of tests that use JDI invokeMethod() support occasionally fail when run using virtual threads. The tests fail with:
> 
> 
> # ERROR: TEST FAILED: wrong invocation:
> # ERROR: invoking debuggee thread instance of java.lang.VirtualThread(name='invokemethod010tThr', id=272)
> # ERROR: is not suspended again after the invocation 
> 
> 
> Although as explained later, this is a misleading message, and does not accurately reflect why the test is failing. More on that below.
> 
> The root cause of the failure is due to these tests using JDI invokeMethod support with the  INVOKE_SINGLE_THREADED flag. This is not always going to work with virtual threads because the invoked method is doing a Thread.sleep(400), and that is at risk of blocking indefinitely if all other threads are blocked form making progress. Note that technically platform threads could fail in the same manner. However, the reason the failure only happens now with virtual threads is because the implementation of Thread.sleep() differs for virtual threads, and may require ownership of a monitor that sometimes is held by another thread.
> 
> Another issue is that the tests do not do a very good job of error handling when this happens, and give the misleading failure reason of the invoked thread not being suspended after the invoke completed. The reason it is not suspended is because the invoke has actually not completed. There was a timeout that the test did not properly note as the cause of the failure. The test (debugger side) spawns a thread to do the JDI invokeMethod with, and then waits for it with:
> 
>                 invThr.join(argHandler.getWaitTime()*60000);
> 
> This join() times out, but the test assumes once it returns the invoke is complete, even though the invoked thread is actually still in the middle of the invoke. So that is the reason debuggee invokemethod thread is not currently suspended. I've fixed this by having a test check if invThr is still alive after the join. If it is, then the test is made to fail at that point, rather than continuing on and checking the debuggee threads status. The failure then becomes:
> 
> nsk.share.TestFailure: TEST FAILED: invoke never completed
> 
> At that point a vm.resume() is done to allow the invoke to complete, and the test will exit with this failure.
> 
> As for avoiding the failure in the first place (the deadlock in the debuggee during the invoke), this is really a test bug for relying on INVOKE_SINGLE_THREADED and assuming that the invoked thread won't become deadlocked. Since there is a Thread.sleep() call in the invoked method, it can't make this assumption. From the ObjectReference.invoke() spec:
> 
> "By default, all threads in the target VM are resumed while the method is being invoked if they were previously suspended by an event or by VirtualMachine.suspend() or ThreadReference.suspend(). This is done to prevent the deadlocks that will occur if any of the threads own monitors that will be needed by the invoked method."
> 
> "The resumption of other threads during the invocation can be prevented by specifying the INVOKE_SINGLE_THREADED bit flag in the options argument; however, there is no protection against or recovery from the deadlocks described above, so this option should be used with great caution."
> 
> For platform threads, sleep() doesn't require any monitors, so these tests never ran into problems before. For virtual threads however there is some synchronization done, and potential reliance on other threads not being suspended. A way around this is to always use sleep(0), which will at least attempt to yield the thread. For platform threads an actual yield is likely. For a virtual thread it will not yield in this particular case because the virtual thread is pinned to the carrier thread due to the jvmti breakpoint callback that is currently in the call chain of the invoked thread. So for virtual threads this effectively the same as sitting in a spin loop with no yielding. This is ok. CPU wasting is not a concern.

This pull request has now been integrated.

Changeset: f4b72df4
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f4b72df42863c321d03c32d1d0349892c3e87d50
Stats:     124 lines in 15 files changed: 101 ins; 9 del; 14 mod

8282379: [LOOM] vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011 sometimes fails

Reviewed-by: dholmes, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/12420

From amenkov at openjdk.org  Thu Feb  9 19:41:01 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 9 Feb 2023 19:41:01 GMT
Subject: Integrated: 8228604: StackMapFrames are missing from redefined class
 bytes of retransformed classes
In-Reply-To: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
References: <iSmclrg8PyMT5j1kocEtwj-56VlAycw2aMiSt9Mm-p4=.15533f68-a1d2-40a7-aa60-ba5c635213a7@github.com>
Message-ID: <-FnJY081DHRjUvq-Z36icuaLAwubislIcO2vd27U6tU=.4f52c4fd-5185-4ec9-bcf4-52609af28897@github.com>

On Tue, 24 Jan 2023 00:16:10 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> classFileParser drops stack map frames for JDK classes (when verification is not required).
> As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition.
> Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS.
> This code is old (from "initial load") and I don't understand the reason it was implemented this way.
> 
> Testing: tier1-tier6

This pull request has now been integrated.

Changeset: 48155662
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/48155662af04bf7532799d507c23f6d5aa66a632
Stats:     353 lines in 3 files changed: 347 ins; 4 del; 2 mod

8228604: StackMapFrames are missing from redefined class bytes of retransformed classes

Reviewed-by: cjplummer, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/12155

From cjplummer at openjdk.org  Thu Feb  9 19:45:22 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 9 Feb 2023 19:45:22 GMT
Subject: RFR: 8301638: A number of nsk/jdi invokemethod tests should be
 converted to create virtual threads
Message-ID: <WtkxMXFaaWfBmLQVPg41Nkf5JZyRSDnx23hF-BSH4sI=.b07840f7-4826-437a-9a05-7b75b09111ae@github.com>

As part of the initial loom work, some nsk/jdi invokemethod tests were converted to support testing with virtual threads.  However, for some reason a few of the tests were skipped when the initial conversion was done. This PR converts the remaining tests.

The general approach is to take the Thread subclass defined by the debuggee and change it to instead extend NamedTask. Then  JDIThreadFactory.newThread(NamedTask) is used to create the Thread instance, passing the task instance in as argument. JDIThreadFactory.newThread(NamedTask) will create a virtual thread or a platform thread depending on the setting of the main.wrapper property. Tests are run with -Dmain.wrapper=Virtual to trigger using virtual threads.

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

Commit messages:
 - Convert a few invokemethod tests to use more vthreads on the debuggee side.

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

PR: https://git.openjdk.org/jdk/pull/12500

From lmesnik at openjdk.org  Thu Feb  9 21:13:43 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 9 Feb 2023 21:13:43 GMT
Subject: RFR: 8301638: A number of nsk/jdi invokemethod tests should be
 converted to create virtual threads
In-Reply-To: <WtkxMXFaaWfBmLQVPg41Nkf5JZyRSDnx23hF-BSH4sI=.b07840f7-4826-437a-9a05-7b75b09111ae@github.com>
References: <WtkxMXFaaWfBmLQVPg41Nkf5JZyRSDnx23hF-BSH4sI=.b07840f7-4826-437a-9a05-7b75b09111ae@github.com>
Message-ID: <Z0GCdYIpcWSpsaHpITb6KB4VO0yM9UlqUpGaTnikKUE=.85fe3ae8-0dd3-47d8-ab73-512facd095de@github.com>

On Thu, 9 Feb 2023 19:37:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> As part of the initial loom work, some nsk/jdi invokemethod tests were converted to support testing with virtual threads.  However, for some reason a few of the tests were skipped when the initial conversion was done. This PR converts the remaining tests.
> 
> The general approach is to take the Thread subclass defined by the debuggee and change it to instead extend NamedTask. Then  JDIThreadFactory.newThread(NamedTask) is used to create the Thread instance, passing the task instance in as argument. JDIThreadFactory.newThread(NamedTask) will create a virtual thread or a platform thread depending on the setting of the main.wrapper property. Tests are run with -Dmain.wrapper=Virtual to trigger using virtual threads.

Marked as reviewed by lmesnik (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12500

From amenkov at openjdk.org  Thu Feb  9 21:42:43 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 9 Feb 2023 21:42:43 GMT
Subject: RFR: 8302069:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java update
In-Reply-To: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>
References: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>
Message-ID: <W-7bnW8CcNqOiCyezQervI0szTNoY-wWgi8pn4dh16w=.1b60967d-1b71-4d95-abb6-d80d3f8ba804@github.com>

On Wed, 8 Feb 2023 11:57:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> NotifReconnectDeadlockTest.java has been problemlisted for a long time (although 8042215 is the wrong bug id).
> 
> The originally reported problem ("No reconnection happened") cannot be reproduced, although there are occasional failures when the test is run.
> 
> Those failures are more like the connection failures fixed in similar tests (e.g. JDK-8227337), where:
> java.rmi.NoSuchObjectException: no such object in table
> ..is reported, a startup issue, before the notification work, a failure to connect:
> at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> at NotifReconnectDeadlockTest.main(NotifReconnectDeadlockTest.java:88)
> 
> We should do something similar here, but not such that it affects the deadlock timing.  Increase serverTimeout, it needs a longer timeout to permit the initial connect to work reliably (fails occasionally, particularly but not exclusively on Windows debug builds).  Not using the test library timeout scaling here as the timeout has to be kept fairly short, to let the test intentionally block the notification handler and try to cause the original issue.
> 
> Additional prints to make the test logs hopefully easier to follow, and tried to clarify a few comments that made no sense to me.
> 
> Passing on many runs on all platforms.

Marked as reviewed by amenkov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12472

From amenkov at openjdk.org  Thu Feb  9 21:49:46 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 9 Feb 2023 21:49:46 GMT
Subject: RFR: 8301638: A number of nsk/jdi invokemethod tests should be
 converted to create virtual threads
In-Reply-To: <WtkxMXFaaWfBmLQVPg41Nkf5JZyRSDnx23hF-BSH4sI=.b07840f7-4826-437a-9a05-7b75b09111ae@github.com>
References: <WtkxMXFaaWfBmLQVPg41Nkf5JZyRSDnx23hF-BSH4sI=.b07840f7-4826-437a-9a05-7b75b09111ae@github.com>
Message-ID: <rlX9ypbNBNu5qLW2OgTwHtIKmE1V2DCCqT13GQZ7Hpo=.8f51782a-6105-4f6a-93f7-65322aef070a@github.com>

On Thu, 9 Feb 2023 19:37:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> As part of the initial loom work, some nsk/jdi invokemethod tests were converted to support testing with virtual threads.  However, for some reason a few of the tests were skipped when the initial conversion was done. This PR converts the remaining tests.
> 
> The general approach is to take the Thread subclass defined by the debuggee and change it to instead extend NamedTask. Then  JDIThreadFactory.newThread(NamedTask) is used to create the Thread instance, passing the task instance in as argument. JDIThreadFactory.newThread(NamedTask) will create a virtual thread or a platform thread depending on the setting of the main.wrapper property. Tests are run with -Dmain.wrapper=Virtual to trigger using virtual threads.

Marked as reviewed by amenkov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12500

From sspitsyn at openjdk.org  Fri Feb 10 06:31:43 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Feb 2023 06:31:43 GMT
Subject: RFR: 8301638: A number of nsk/jdi invokemethod tests should be
 converted to create virtual threads
In-Reply-To: <WtkxMXFaaWfBmLQVPg41Nkf5JZyRSDnx23hF-BSH4sI=.b07840f7-4826-437a-9a05-7b75b09111ae@github.com>
References: <WtkxMXFaaWfBmLQVPg41Nkf5JZyRSDnx23hF-BSH4sI=.b07840f7-4826-437a-9a05-7b75b09111ae@github.com>
Message-ID: <KFgd98mbXEUcwfBOfGlqRP_Qm7qXQ6ElYFgy8iIcfbw=.1c39aeb5-9bbb-4563-9020-41941cecdd8e@github.com>

On Thu, 9 Feb 2023 19:37:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> As part of the initial loom work, some nsk/jdi invokemethod tests were converted to support testing with virtual threads.  However, for some reason a few of the tests were skipped when the initial conversion was done. This PR converts the remaining tests.
> 
> The general approach is to take the Thread subclass defined by the debuggee and change it to instead extend NamedTask. Then  JDIThreadFactory.newThread(NamedTask) is used to create the Thread instance, passing the task instance in as argument. JDIThreadFactory.newThread(NamedTask) will create a virtual thread or a platform thread depending on the setting of the main.wrapper property. Tests are run with -Dmain.wrapper=Virtual to trigger using virtual threads.

Looks okay to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12500

From kevinw at openjdk.org  Fri Feb 10 08:35:04 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 10 Feb 2023 08:35:04 GMT
Subject: Integrated: 8302069:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java update
In-Reply-To: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>
References: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>
Message-ID: <grKehVE5IxiuLuCTbOMmuCpZJjvWgLIdhH-Mw-ybHKk=.c24cbdc1-ddae-418c-b915-218bb3f1c046@github.com>

On Wed, 8 Feb 2023 11:57:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> NotifReconnectDeadlockTest.java has been problemlisted for a long time (although 8042215 is the wrong bug id).
> 
> The originally reported problem ("No reconnection happened") cannot be reproduced, although there are occasional failures when the test is run.
> 
> Those failures are more like the connection failures fixed in similar tests (e.g. JDK-8227337), where:
> java.rmi.NoSuchObjectException: no such object in table
> ..is reported, a startup issue, before the notification work, a failure to connect:
> at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> at NotifReconnectDeadlockTest.main(NotifReconnectDeadlockTest.java:88)
> 
> We should do something similar here, but not such that it affects the deadlock timing.  Increase serverTimeout, it needs a longer timeout to permit the initial connect to work reliably (fails occasionally, particularly but not exclusively on Windows debug builds).  Not using the test library timeout scaling here as the timeout has to be kept fairly short, to let the test intentionally block the notification handler and try to cause the original issue.
> 
> Additional prints to make the test logs hopefully easier to follow, and tried to clarify a few comments that made no sense to me.
> 
> Passing on many runs on all platforms.

This pull request has now been integrated.

Changeset: 1c7b09bc
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1c7b09bc23ac37f83b9043de35b71bea7e814da5
Stats:     16 lines in 2 files changed: 6 ins; 2 del; 8 mod

8302069: javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java update

Reviewed-by: cjplummer, amenkov

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

PR: https://git.openjdk.org/jdk/pull/12472

From kevinw at openjdk.org  Fri Feb 10 08:35:02 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 10 Feb 2023 08:35:02 GMT
Subject: RFR: 8302069:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java update
In-Reply-To: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>
References: <cUHkFe8QZAUzzoMFF9AXNwCnnnYgarzYp2n98CclU_U=.29382486-f376-4429-8891-1d774714a461@github.com>
Message-ID: <y6lontvhcfdcRvSHdeFJanVuMxJFnETR01MSavX7JpE=.48c4d8d6-ac6e-465b-9b00-f60d7417e4a6@github.com>

On Wed, 8 Feb 2023 11:57:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> NotifReconnectDeadlockTest.java has been problemlisted for a long time (although 8042215 is the wrong bug id).
> 
> The originally reported problem ("No reconnection happened") cannot be reproduced, although there are occasional failures when the test is run.
> 
> Those failures are more like the connection failures fixed in similar tests (e.g. JDK-8227337), where:
> java.rmi.NoSuchObjectException: no such object in table
> ..is reported, a startup issue, before the notification work, a failure to connect:
> at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> at NotifReconnectDeadlockTest.main(NotifReconnectDeadlockTest.java:88)
> 
> We should do something similar here, but not such that it affects the deadlock timing.  Increase serverTimeout, it needs a longer timeout to permit the initial connect to work reliably (fails occasionally, particularly but not exclusively on Windows debug builds).  Not using the test library timeout scaling here as the timeout has to be kept fairly short, to let the test intentionally block the notification handler and try to cause the original issue.
> 
> Additional prints to make the test logs hopefully easier to follow, and tried to clarify a few comments that made no sense to me.
> 
> Passing on many runs on all platforms.

Thanks!

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

PR: https://git.openjdk.org/jdk/pull/12472

From sspitsyn at openjdk.org  Fri Feb 10 08:35:58 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Feb 2023 08:35:58 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v5]
In-Reply-To: <RvWlkSKELZdDeDouaXRt44aoWy1dBZRbvqpCMXNhlJE=.d4a11af6-5f9a-4f10-ac82-3109653f5eec@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <ONO1PEI-tgHm4z4-mppmc-st3WhwecI3z9T-xKz4KgY=.0c905a1c-8124-4cb0-aecb-8bc377486600@github.com>
 <RvWlkSKELZdDeDouaXRt44aoWy1dBZRbvqpCMXNhlJE=.d4a11af6-5f9a-4f10-ac82-3109653f5eec@github.com>
Message-ID: <v92fcpcccGWco28-m2WUNJ5YB7ALfduMfrS0TmLw6dQ=.96912373-a27f-4664-b1a0-1ec54801da84@github.com>

On Wed, 8 Feb 2023 22:17:34 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix race between VTMS_transition_disable_for_one and start_VTMS_transition
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 479:
> 
>> 477: 
>> 478:   // Unblock waiting VTMS transition disablers.
>> 479:   if (_VTMS_transition_disable_for_one_count > 0 ||
> 
> In here it would actually be the other way. If we would check java_lang_Thread::VTMS_transition_disable_count(vth()) > 0 instead of the global _VTMS_transition_disable_for_one_count we would avoid the notify in case there are singler disablers waiting but not for this thread.

Good comment.
Yes, I considered the same as you about to suggest.
It is on my plan to work on optimization of these fragments.
Will keep in mind this your comment.

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

PR: https://git.openjdk.org/jdk/pull/11690

From sspitsyn at openjdk.org  Fri Feb 10 08:35:55 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Feb 2023 08:35:55 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v5]
In-Reply-To: <ONO1PEI-tgHm4z4-mppmc-st3WhwecI3z9T-xKz4KgY=.0c905a1c-8124-4cb0-aecb-8bc377486600@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <ONO1PEI-tgHm4z4-mppmc-st3WhwecI3z9T-xKz4KgY=.0c905a1c-8124-4cb0-aecb-8bc377486600@github.com>
Message-ID: <PG8cjzCRq3VQIekJHV8GCoSCL0msk09IGkAVXy9-OBs=.2d833393-1f93-4f72-a328-d8ae76f27cb8@github.com>

On Sat, 24 Dec 2022 04:14:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
>> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
>> 
>> Testing:
>>   mach5 jobs are TBD (preliminary testing was completed):
>>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>>    - Kitchensink
>>    - tier5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix race between VTMS_transition_disable_for_one and start_VTMS_transition

Thank you a lot for reviewing it, Patricio!

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

PR: https://git.openjdk.org/jdk/pull/11690

From cjplummer at openjdk.org  Fri Feb 10 19:32:53 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 10 Feb 2023 19:32:53 GMT
Subject: RFR: 8301638: A number of nsk/jdi invokemethod tests should be
 converted to create virtual threads
In-Reply-To: <WtkxMXFaaWfBmLQVPg41Nkf5JZyRSDnx23hF-BSH4sI=.b07840f7-4826-437a-9a05-7b75b09111ae@github.com>
References: <WtkxMXFaaWfBmLQVPg41Nkf5JZyRSDnx23hF-BSH4sI=.b07840f7-4826-437a-9a05-7b75b09111ae@github.com>
Message-ID: <dR2HkqxXfyzaXQkwAE-COD8v4Jv_VXS0F3imd8PEBCk=.5f3b5ea5-3f45-480e-85cc-de3fbb91a0ea@github.com>

On Thu, 9 Feb 2023 19:37:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> As part of the initial loom work, some nsk/jdi invokemethod tests were converted to support testing with virtual threads.  However, for some reason a few of the tests were skipped when the initial conversion was done. This PR converts the remaining tests.
> 
> The general approach is to take the Thread subclass defined by the debuggee and change it to instead extend NamedTask. Then  JDIThreadFactory.newThread(NamedTask) is used to create the Thread instance, passing the task instance in as argument. JDIThreadFactory.newThread(NamedTask) will create a virtual thread or a platform thread depending on the setting of the main.wrapper property. Tests are run with -Dmain.wrapper=Virtual to trigger using virtual threads.

thanks for the reviews Serguei, Alex, and Leonid.

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

PR: https://git.openjdk.org/jdk/pull/12500

From cjplummer at openjdk.org  Fri Feb 10 19:32:54 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 10 Feb 2023 19:32:54 GMT
Subject: Integrated: 8301638: A number of nsk/jdi invokemethod tests should be
 converted to create virtual threads
In-Reply-To: <WtkxMXFaaWfBmLQVPg41Nkf5JZyRSDnx23hF-BSH4sI=.b07840f7-4826-437a-9a05-7b75b09111ae@github.com>
References: <WtkxMXFaaWfBmLQVPg41Nkf5JZyRSDnx23hF-BSH4sI=.b07840f7-4826-437a-9a05-7b75b09111ae@github.com>
Message-ID: <tjI_ybVlLWQzuVOLp-Ri6G9rEuXFUYSVJfzKrEYrsUY=.dd993356-fb33-4960-9cf7-a14ab14de23f@github.com>

On Thu, 9 Feb 2023 19:37:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> As part of the initial loom work, some nsk/jdi invokemethod tests were converted to support testing with virtual threads.  However, for some reason a few of the tests were skipped when the initial conversion was done. This PR converts the remaining tests.
> 
> The general approach is to take the Thread subclass defined by the debuggee and change it to instead extend NamedTask. Then  JDIThreadFactory.newThread(NamedTask) is used to create the Thread instance, passing the task instance in as argument. JDIThreadFactory.newThread(NamedTask) will create a virtual thread or a platform thread depending on the setting of the main.wrapper property. Tests are run with -Dmain.wrapper=Virtual to trigger using virtual threads.

This pull request has now been integrated.

Changeset: 880f52fd
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/880f52fda0335283b0fdd932030051d653779e7d
Stats:     30 lines in 5 files changed: 0 ins; 0 del; 30 mod

8301638: A number of nsk/jdi invokemethod tests should be converted to create virtual threads

Reviewed-by: lmesnik, amenkov, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/12500

From pchilanomate at openjdk.org  Fri Feb 10 19:36:28 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 10 Feb 2023 19:36:28 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation
Message-ID: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>

Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime, PopFrame, ForceEarlyReturnXXX) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.

There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
>From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.

Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).

I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.

I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.

Thanks,
Patricio

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

Commit messages:
 - v1

Changes: https://git.openjdk.org/jdk/pull/12512/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12512&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300575
  Stats: 560 lines in 63 files changed: 467 ins; 74 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/12512.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12512/head:pull/12512

PR: https://git.openjdk.org/jdk/pull/12512

From sspitsyn at openjdk.org  Sat Feb 11 01:37:34 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 11 Feb 2023 01:37:34 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v5]
In-Reply-To: <ONO1PEI-tgHm4z4-mppmc-st3WhwecI3z9T-xKz4KgY=.0c905a1c-8124-4cb0-aecb-8bc377486600@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <ONO1PEI-tgHm4z4-mppmc-st3WhwecI3z9T-xKz4KgY=.0c905a1c-8124-4cb0-aecb-8bc377486600@github.com>
Message-ID: <NWsp92-KSM1lPNW88yWgitJmbpK9KUmmaKm6Ad_xq2A=.dd1a40c1-9d86-43d5-8611-7e8310d2c796@github.com>

On Sat, 24 Dec 2022 04:14:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
>> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
>> 
>> Testing:
>>   mach5 jobs are TBD (preliminary testing was completed):
>>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>>    - Kitchensink
>>    - tier5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix race between VTMS_transition_disable_for_one and start_VTMS_transition

PING: one more review is needed!

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

PR: https://git.openjdk.org/jdk/pull/11690

From sspitsyn at openjdk.org  Sat Feb 11 01:43:07 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 11 Feb 2023 01:43:07 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v6]
In-Reply-To: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
Message-ID: <Ob--uRnH6tA2oT4TvgnUnRPHZWBw1nVfMGgmNMZKXkg=.5e4eb738-2b3d-4e41-a02a-e100f07bf17f@github.com>

> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
> 
> Testing:
>   mach5 jobs are TBD (preliminary testing was completed):
>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>    - Kitchensink
>    - tier5

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

  minor comments are resolved

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11690/files
  - new: https://git.openjdk.org/jdk/pull/11690/files/3effc27d..146c2a59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/11690

From lmesnik at openjdk.org  Sat Feb 11 04:22:32 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 11 Feb 2023 04:22:32 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v6]
In-Reply-To: <Ob--uRnH6tA2oT4TvgnUnRPHZWBw1nVfMGgmNMZKXkg=.5e4eb738-2b3d-4e41-a02a-e100f07bf17f@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <Ob--uRnH6tA2oT4TvgnUnRPHZWBw1nVfMGgmNMZKXkg=.5e4eb738-2b3d-4e41-a02a-e100f07bf17f@github.com>
Message-ID: <JqbrEzwlV3guzQljVeixLwBB-MI6z6f76tdmSbd8k9o=.98a02392-162e-4a5b-ae40-0940ca4e54dc@github.com>

On Sat, 11 Feb 2023 01:43:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
>> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
>> 
>> Testing:
>>   mach5 jobs are TBD (preliminary testing was completed):
>>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>>    - Kitchensink
>>    - tier5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor comments are resolved

Please update the copyrights. (I quickly check a couple of files and that had old year.)

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

Marked as reviewed by lmesnik (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11690

From alanb at openjdk.org  Sat Feb 11 07:33:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 11 Feb 2023 07:33:27 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation
In-Reply-To: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
Message-ID: <eUdNIEqogLvO4vnXYOCFPaISwh0I8GowNE7mJICFKCg=.df92e3b2-33d4-403a-b5c4-b1ab7080f992@github.com>

On Fri, 10 Feb 2023 14:50:36 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime, PopFrame, ForceEarlyReturnXXX) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
> 
> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
> 
> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
> 
> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
> 
> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
> 
> Thanks,
> Patricio

src/hotspot/share/classfile/vmClassMacros.hpp line 92:

> 90:   do_klass(Thread_Constants_klass,                      java_lang_Thread_Constants                            ) \
> 91:   do_klass(ThreadGroup_klass,                           java_lang_ThreadGroup                                 ) \
> 92:   do_klass(BasicVirtualThread_klass,                    java_lang_BaseVirtualThread                           ) \

It should be BaseVirtualThread_klass rather BasicVirtualThread_klass (probably my fault when adding the alt implementation).

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

PR: https://git.openjdk.org/jdk/pull/12512

From alanb at openjdk.org  Sat Feb 11 07:40:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 11 Feb 2023 07:40:26 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation
In-Reply-To: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
Message-ID: <QR3zlA7ClDQkHo0yopsNS2pc7AeH3WVbVzctsIUMjBc=.138a47c1-f1da-485b-b588-23845972a83f@github.com>

On Fri, 10 Feb 2023 14:50:36 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime, PopFrame, ForceEarlyReturnXXX) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
> 
> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
> 
> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
> 
> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
> 
> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
> 
> Thanks,
> Patricio

I see that JVM_GetAllThreads will now returned the filtered list (as an array). That looks okay. There's another part to this in the ThreadMXBean implementation where the filtering is done in the Java implementation. We can look at that in a follow-up issue, to avoid adding more to this PR.

On tests, there are a few other tests that can be changed to drop `@requires vm.continuations`, e.g. the jshell tests that run with --enable-preview should no longer need the `@requires`. There are also a few JDI and at least one AppCDS test. A search will find them. The tests re-running with -XX:-VMContinuations is fine but it does mean they will run twice on the ports without an implementation. The test runtime/jni/IsVirtualThread/IsVirtualThread.java is an example where it only runs once on these ports, at the cost of additional `@test` tag.

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

PR: https://git.openjdk.org/jdk/pull/12512

From alanb at openjdk.org  Sun Feb 12 08:18:25 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 12 Feb 2023 08:18:25 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation
In-Reply-To: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
Message-ID: <2MCpmgUCa9wZNv4hBjb7tspJVRmx_0iEDvhwuWGsC18=.afad6f08-3ff8-4002-a29e-f17c4cd0b813@github.com>

On Fri, 10 Feb 2023 14:50:36 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).

The timer functions need re-visiting to allow an implementation support these functions on virtual threads. Same for StopThread which needs a spec change to minimally support this function on a thread that is suspended at a breakpoint or single step event. So if we sort out these spec issues then it looks like JavaThread:: _is_bound_vthread could go away and there would be less coupling with the alt implementation.

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

PR: https://git.openjdk.org/jdk/pull/12512

From duke at openjdk.org  Mon Feb 13 14:47:08 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Mon, 13 Feb 2023 14:47:08 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in sanity
 test
Message-ID: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>

Fixes the issue by applying a fix that is already implemented in PPC.

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

Commit messages:
 - Fix typo in ARM change
 - Fix ASGCT sanity test
 - Check more frames in ASGCT sanity test

Changes: https://git.openjdk.org/jdk/pull/12535/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12535&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302320
  Stats: 37 lines in 3 files changed: 33 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12535.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12535/head:pull/12535

PR: https://git.openjdk.org/jdk/pull/12535

From abakhtin at openjdk.org  Mon Feb 13 14:49:30 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Mon, 13 Feb 2023 14:49:30 GMT
Subject: RFR: 8299234: JMX Repository.query performance [v5]
In-Reply-To: <YH-y2lwy0IU4s9Ri6vuNwwgpZpJzFIQW_ttuE8KkFFs=.ccabc1f9-d27d-469a-847b-69c4e882d7e6@github.com>
References: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
 <YH-y2lwy0IU4s9Ri6vuNwwgpZpJzFIQW_ttuE8KkFFs=.ccabc1f9-d27d-469a-847b-69c4e882d7e6@github.com>
Message-ID: <Qx5_TLByVoQ5hKifw2En6GllV2hGNntaFYuf2nzYBD0=.7e2af6d3-37a0-4657-8489-f143971f7ba1@github.com>

On Thu, 2 Feb 2023 13:42:51 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please find a patch to improve JMX Repository.query performance
>> 
>> Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles:
>> Before:
>> 
>> $ java test 1000000 1000000
>> Test PASSED in 8943169791 ns.
>> GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118
>> 
>> 
>> After:
>> 
>> $ java test 1000000 1000000
>> Test PASSED in 4808213917 ns.
>> GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53
>> 
>> Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation.
>> 
>> All javax/management jtreg tests passed successfully.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize ObjectName.matchDomains

@sspitsyn, Could you take a look at the proposed enhancement or suggest someone who can review it? Thank you

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

PR: https://git.openjdk.org/jdk/pull/11758

From pchilanomate at openjdk.org  Mon Feb 13 19:51:12 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 13 Feb 2023 19:51:12 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v2]
In-Reply-To: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
Message-ID: <WiEiO1ZIvhcSkZYtVPdi8jiC6_cyGWaE0FYKvg8ZQwA=.8b387305-0b2a-4e9d-ad10-43abb4a415e6@github.com>

> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime, PopFrame, ForceEarlyReturnXXX) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
> 
> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
> 
> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
> 
> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
> 
> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:

 - use different @test to run with -XX:-VMContinuations
 - more removals of @requires vm.continuations
 - change BasicVirtualThread_klass -> BaseVirtualThread_klass

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12512/files
  - new: https://git.openjdk.org/jdk/pull/12512/files/571f0d2e..99cf204c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12512&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12512&range=00-01

  Stats: 105 lines in 22 files changed: 69 ins; 7 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/12512.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12512/head:pull/12512

PR: https://git.openjdk.org/jdk/pull/12512

From pchilanomate at openjdk.org  Mon Feb 13 19:57:26 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 13 Feb 2023 19:57:26 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation
In-Reply-To: <QR3zlA7ClDQkHo0yopsNS2pc7AeH3WVbVzctsIUMjBc=.138a47c1-f1da-485b-b588-23845972a83f@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <QR3zlA7ClDQkHo0yopsNS2pc7AeH3WVbVzctsIUMjBc=.138a47c1-f1da-485b-b588-23845972a83f@github.com>
Message-ID: <eyomNlcAUXAn__JvmgXhQ5enVSiTd8qa0YZmVoeZzlY=.cb5c77c8-d155-4611-a4b1-bdd0043ca360@github.com>

On Sat, 11 Feb 2023 07:37:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> On tests, there are a few other tests that can be changed to drop `@requires vm.continuations`, e.g. the jshell tests that run with --enable-preview should no longer need the `@requires`. There are also a few JDI and at least one AppCDS test. A search will find them. 
>
I removed the vm.continuations requirement on those tests (only SuspendAfterDeath.java and RedefineRunningMethods_Shared.java were actually creating a JVMTI environment though).

>The tests re-running with -XX:-VMContinuations is fine but it does mean they will run twice on the ports without an implementation. The test runtime/jni/IsVirtualThread/IsVirtualThread.java is an example where it only runs once on these ports, at the cost of additional `@test` tag.
>
I see, I removed the extra run and created another @test tag for that with `@requires vm.continuations`, like it is done in IsVirtualThread.java.

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

PR: https://git.openjdk.org/jdk/pull/12512

From pchilanomate at openjdk.org  Mon Feb 13 19:57:30 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 13 Feb 2023 19:57:30 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v2]
In-Reply-To: <WiEiO1ZIvhcSkZYtVPdi8jiC6_cyGWaE0FYKvg8ZQwA=.8b387305-0b2a-4e9d-ad10-43abb4a415e6@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <WiEiO1ZIvhcSkZYtVPdi8jiC6_cyGWaE0FYKvg8ZQwA=.8b387305-0b2a-4e9d-ad10-43abb4a415e6@github.com>
Message-ID: <w66csxh3CfJ0hS5QC9UkK80KM9XzHEOPuZKk6QX2Hqg=.c639ea33-a971-4e3a-a334-482ac1a53dfc@github.com>

On Mon, 13 Feb 2023 19:51:12 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
>> 
>> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
>> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
>> 
>> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
>> 
>> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
>> 
>> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - use different @test to run with -XX:-VMContinuations
>  - more removals of @requires vm.continuations
>  - change BasicVirtualThread_klass -> BaseVirtualThread_klass

Also fixed a bug in the description. PopFrame and ForceEarlyReturnXXX don't actually need to return UNSUPPORTED_OPERATION (optionally supported by the specs), but when looking at jvmtiEnv.cpp, I saw the "// No support for virtual threads (yet)" comment, so I just changed them to return UNSUPPORTED_OPERATION for the alternative implementation too to match the behavior with normal virtual threads. But I could revert that if agreed. In fact I left SetLocalXXX unmodified where currently the implementation has different support on virtual threads than platform threads.

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

PR: https://git.openjdk.org/jdk/pull/12512

From pchilanomate at openjdk.org  Mon Feb 13 19:57:33 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 13 Feb 2023 19:57:33 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v2]
In-Reply-To: <eUdNIEqogLvO4vnXYOCFPaISwh0I8GowNE7mJICFKCg=.df92e3b2-33d4-403a-b5c4-b1ab7080f992@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <eUdNIEqogLvO4vnXYOCFPaISwh0I8GowNE7mJICFKCg=.df92e3b2-33d4-403a-b5c4-b1ab7080f992@github.com>
Message-ID: <Cw9ZjIfVbSKi3Ugzztpw9fHVsxnpk9_z2h3_D853Xnw=.dca9092e-93ff-4faf-803c-14ce935d4f01@github.com>

On Sat, 11 Feb 2023 07:31:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - use different @test to run with -XX:-VMContinuations
>>  - more removals of @requires vm.continuations
>>  - change BasicVirtualThread_klass -> BaseVirtualThread_klass
>
> src/hotspot/share/classfile/vmClassMacros.hpp line 92:
> 
>> 90:   do_klass(Thread_Constants_klass,                      java_lang_Thread_Constants                            ) \
>> 91:   do_klass(ThreadGroup_klass,                           java_lang_ThreadGroup                                 ) \
>> 92:   do_klass(BasicVirtualThread_klass,                    java_lang_BaseVirtualThread                           ) \
> 
> It should be BaseVirtualThread_klass rather than BasicVirtualThread_klass (probably my fault when adding the alt implementation).

Fixed.

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

PR: https://git.openjdk.org/jdk/pull/12512

From xuelei at openjdk.org  Mon Feb 13 20:01:31 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 13 Feb 2023 20:01:31 GMT
Subject: RFR: 8301279: update for deprecated sprintf for management
 components
In-Reply-To: <GWoNgierf17aTWNajU0zV15VGoRNbh7rYHHG603jr2E=.6c03bfc9-2456-4981-8aaf-318e7b71466f@github.com>
References: <GWoNgierf17aTWNajU0zV15VGoRNbh7rYHHG603jr2E=.6c03bfc9-2456-4981-8aaf-318e7b71466f@github.com>
Message-ID: <A3fAEnJuDfZYg3jYzdKW5SMOGoz-dYx6BHLAzRiN_jg=.2db066fb-b95f-49be-ac88-e55e66859733@github.com>

On Fri, 27 Jan 2023 20:32:35 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in management components.

Ping .... an Reviewer reviewing is required.  Thanks!

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

PR: https://git.openjdk.org/jdk/pull/12266

From sspitsyn at openjdk.org  Mon Feb 13 20:28:29 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 13 Feb 2023 20:28:29 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v7]
In-Reply-To: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
Message-ID: <ub_3oivX-Ppsmf35GVb3HIIeL6vqXBXIct_WLLQmIso=.633a0665-0806-4eb5-b1b7-733e3a80cb94@github.com>

> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
> 
> Testing:
>   mach5 jobs are TBD (preliminary testing was completed):
>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>    - Kitchensink
>    - tier5

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into br21
 - minor comments are resolved
 - fix race between VTMS_transition_disable_for_one and start_VTMS_transition
 - use owned_by_self vs is_locked in JvmtiVTMSTransition_lock asserts
 - address wqsecond round review comments
 - review comments are addressed
 - fix trailing white spaces in javaClasses.cpp and jvmtiThreadState.cpp
 - 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions

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

Changes: https://git.openjdk.org/jdk/pull/11690/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=06
  Stats: 198 lines in 8 files changed: 129 ins; 16 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/11690.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11690/head:pull/11690

PR: https://git.openjdk.org/jdk/pull/11690

From sspitsyn at openjdk.org  Mon Feb 13 20:28:33 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 13 Feb 2023 20:28:33 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v6]
In-Reply-To: <Ob--uRnH6tA2oT4TvgnUnRPHZWBw1nVfMGgmNMZKXkg=.5e4eb738-2b3d-4e41-a02a-e100f07bf17f@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <Ob--uRnH6tA2oT4TvgnUnRPHZWBw1nVfMGgmNMZKXkg=.5e4eb738-2b3d-4e41-a02a-e100f07bf17f@github.com>
Message-ID: <kXmbCRrLBYocO3J7Z-ejVtPiPmgel6PPPGxLtNeRtU8=.a22cea20-5b65-45ac-a379-75875908a772@github.com>

On Sat, 11 Feb 2023 01:43:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
>> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
>> 
>> Testing:
>>   mach5 jobs are TBD (preliminary testing was completed):
>>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>>    - Kitchensink
>>    - tier5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor comments are resolved

Thank you a lot for reviewing, Leonid!
Will update the copyrights.

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

PR: https://git.openjdk.org/jdk/pull/11690

From sspitsyn at openjdk.org  Tue Feb 14 01:32:03 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 14 Feb 2023 01:32:03 GMT
Subject: Integrated: 8298853: JvmtiVTMSTransitionDisabler should support
 disabling one virtual thread transitions
In-Reply-To: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
Message-ID: <YG-ZczgUK3LZWsg-1kxLkzhJ7GDvdWWh0ko-5bLSyBs=.08773df7-1da9-46fd-aa63-1be60c8c8d5a@github.com>

On Thu, 15 Dec 2022 11:51:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
> 
> Testing:
>   mach5 jobs are TBD (preliminary testing was completed):
>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>    - Kitchensink
>    - tier5

This pull request has now been integrated.

Changeset: 13b1ebba
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/13b1ebba276940ff83e53b8ec3659280b3574204
Stats:     198 lines in 8 files changed: 129 ins; 16 del; 53 mod

8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions

Reviewed-by: pchilanomate, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/11690

From dholmes at openjdk.org  Tue Feb 14 02:55:47 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Feb 2023 02:55:47 GMT
Subject: RFR: 8301279: update for deprecated sprintf for management
 components
In-Reply-To: <GWoNgierf17aTWNajU0zV15VGoRNbh7rYHHG603jr2E=.6c03bfc9-2456-4981-8aaf-318e7b71466f@github.com>
References: <GWoNgierf17aTWNajU0zV15VGoRNbh7rYHHG603jr2E=.6c03bfc9-2456-4981-8aaf-318e7b71466f@github.com>
Message-ID: <7JZfDcmDk4DxBzFugvlhPR5jUWSTpC6Wqo0jiPBlQFw=.bd5e3b72-6ead-4a27-9d98-f86295755075@github.com>

On Fri, 27 Jan 2023 20:32:35 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in management components.

Looks good. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12266

From sspitsyn at openjdk.org  Tue Feb 14 05:45:34 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 14 Feb 2023 05:45:34 GMT
Subject: RFR: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint
Message-ID: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>

The rank of JvmtiVTMSTransition_lock is better to be safepoint instead of nosafepoint.
The fix includes removal of the function `check_vthread_and_suspend_at_safepoint` which is not needed anymore.

Testing:
mach5 jobs are in progress:
 Kitchensink, tiers1-6 (all JVMTI, JDWP, JDI and JDB tests have to be included)

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

Commit messages:
 - 8299240: rank of JvmtiVTMSTransition_lock can be safepoint

Changes: https://git.openjdk.org/jdk/pull/12550/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12550&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299240
  Stats: 49 lines in 6 files changed: 8 ins; 30 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12550.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12550/head:pull/12550

PR: https://git.openjdk.org/jdk/pull/12550

From dholmes at openjdk.org  Tue Feb 14 06:43:42 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Feb 2023 06:43:42 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
Message-ID: <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>

On Mon, 13 Feb 2023 14:39:00 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

> Fixes the issue by applying a fix that is already implemented in PPC.

src/hotspot/cpu/x86/frame_x86.cpp line 72:

> 70: 
> 71:   // unextended sp must be within the stack
> 72:   if (!thread->is_in_full_stack_checked(unextended_sp)) {

I'm not at all sure this relaxation is valid. What are you basing this on?

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

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Tue Feb 14 07:06:44 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Tue, 14 Feb 2023 07:06:44 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
Message-ID: <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>

On Tue, 14 Feb 2023 06:41:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fixes the issue by applying a fix that is already implemented in PPC.
>
> src/hotspot/cpu/x86/frame_x86.cpp line 72:
> 
>> 70: 
>> 71:   // unextended sp must be within the stack
>> 72:   if (!thread->is_in_full_stack_checked(unextended_sp)) {
> 
> I'm not at all sure this relaxation is valid. What are you basing this on?

The test fails without this relaxation and the relaxation has been used on PPC to solve a similar issue a few years back.

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

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Tue Feb 14 07:40:48 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Tue, 14 Feb 2023 07:40:48 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
Message-ID: <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>

On Tue, 14 Feb 2023 07:04:16 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/frame_x86.cpp line 72:
>> 
>>> 70: 
>>> 71:   // unextended sp must be within the stack
>>> 72:   if (!thread->is_in_full_stack_checked(unextended_sp)) {
>> 
>> I'm not at all sure this relaxation is valid. What are you basing this on?
>
> The test fails without this relaxation and the relaxation has been used on PPC to solve a similar issue a few years back.

The original assumption does not always hold anymore and should therefore relaxed.

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

PR: https://git.openjdk.org/jdk/pull/12535

From stefank at openjdk.org  Tue Feb 14 09:00:55 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 14 Feb 2023 09:00:55 GMT
Subject: RFR: JDK-8301983: Refactor MEMFLAGS and AllocFailStrategy [v5]
In-Reply-To: <60XHlRRmnr8C-BcA_pRbLwIs7P5lqv5cayfc4ifBHeE=.12ed00cf-afc1-410a-b415-4425769be62b@github.com>
References: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>
 <60XHlRRmnr8C-BcA_pRbLwIs7P5lqv5cayfc4ifBHeE=.12ed00cf-afc1-410a-b415-4425769be62b@github.com>
Message-ID: <XahRZnW-vie-MLr50q9_HfjQ2Yvvif55W2IYbQUIIP4=.8f4225c1-8479-4515-86e2-27d3766775a9@github.com>

On Tue, 7 Feb 2023 17:25:02 GMT, Justin King <jcking at openjdk.org> wrote:

>> - Rename `MEMFLAGS` to `MemoryType`. `MEMFLAGS` is highly misleading as flags typically can be combined.
>> - Update `MemoryType` to have enumeration names that follow the style guide, no `mt` prefix.
>> - Create aliases for old `mtXXX` names.
>> - Remove `mt_number_of_types` from the enumeration.
>> - Shift implementation of utilities related to `MEMFLAGS` from `NMTUtil` to `MemoryTypes`. Handle missing `mt` prefix during parsing.
>> - `NMTUtil` references are not updated to avoid increasing patch size.
>> - Merge `AllocFailStrategy` and `AllocFailType` into `AllocationFailureStrategy`.
>> - Move `MemoryType` and `AllocationFailureStrategy` to their own respective headers.
>> 
>> This change does not update variable verbiage. That should be something done over time.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add precompiled header
>   
>   Signed-off-by: Justin King <jcking at google.com>

FWIW, I strongly dislike the uppercase MEMFLAGS name. I wouldn't mind this rename at all.

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

PR: https://git.openjdk.org/jdk/pull/12454

From rrich at openjdk.org  Tue Feb 14 09:24:43 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 14 Feb 2023 09:24:43 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
Message-ID: <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>

On Tue, 14 Feb 2023 07:38:21 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> The test fails without this relaxation and the relaxation has been used on PPC to solve a similar issue a few years back.
>
> The original assumption does not always hold anymore and should therefore relaxed.

I think `unextended_sp < sp` is possible on x86 when interpreter entries generated by `MethodHandles::generate_method_handle_interpreter_entry()` are executed. They modify `sp` ([here for example](https://github.com/openjdk/jdk/blob/7f71a1040d9c03f72d082e329ccaf2c4a3c060a6/src/hotspot/cpu/x86/methodHandles_x86.cpp#L310-L314)) but not `sender_sp` (`InterpreterMacroAssembler ::_bcp_register`).

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

PR: https://git.openjdk.org/jdk/pull/12535

From stuefe at openjdk.org  Tue Feb 14 13:48:28 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 14 Feb 2023 13:48:28 GMT
Subject: RFR: JDK-8302455: VM.classloader_stats memory size values are wrong
Message-ID: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>

VM.classloader_stats shows metaspace consumption in words, but should show bytes. 

Patch fixes that, and adjusts the associated jtreg test to catch regressions like this.

I manually tested the test with the unpatched hotspot to see if the regression shows up, it does.

Tested the patch on x64 (fastdebug, release) and x86.

Note: "calculate_jfr_stats" is misnamed, actually only ever used by this dcmd, not by jfr. I will clear this up in a separate RFE.

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

Commit messages:
 - Fix VM.classloader_stats

Changes: https://git.openjdk.org/jdk/pull/12556/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12556&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302455
  Stats: 19 lines in 2 files changed: 15 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12556.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12556/head:pull/12556

PR: https://git.openjdk.org/jdk/pull/12556

From alanb at openjdk.org  Tue Feb 14 14:23:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Feb 2023 14:23:56 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v2]
In-Reply-To: <WiEiO1ZIvhcSkZYtVPdi8jiC6_cyGWaE0FYKvg8ZQwA=.8b387305-0b2a-4e9d-ad10-43abb4a415e6@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <WiEiO1ZIvhcSkZYtVPdi8jiC6_cyGWaE0FYKvg8ZQwA=.8b387305-0b2a-4e9d-ad10-43abb4a415e6@github.com>
Message-ID: <H_gu7W6pVefDOJ9RghztPNaLssZJvCJSXQu0NPJPSwg=.89618054-6c3f-4a31-a054-4598bebaad86@github.com>

On Mon, 13 Feb 2023 19:51:12 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
>> 
>> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
>> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
>> 
>> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
>> 
>> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
>> 
>> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - use different @test to run with -XX:-VMContinuations
>  - more removals of @requires vm.continuations
>  - change BasicVirtualThread_klass -> BaseVirtualThread_klass

The changes in the updates look good. I think the main thing to decide on is whether JavaThread:: _is_bound_vthread is needed or not. If GetCurrentThreadCpuTime is changed to allow an implementation support this function then it looks like the additional field would not be needed.

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

PR: https://git.openjdk.org/jdk/pull/12512

From rkennke at openjdk.org  Tue Feb 14 14:38:51 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 14 Feb 2023 14:38:51 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v11]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <Ed1e1XIDEBHSXJjAqDT-Ol8PVbj-UM9qJaU_xlG0hr4=.9b3b96ee-cf49-437e-83f0-3d54ea8c99bc@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock.
> 
> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking.
> 
> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread.
> 
> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it.
> 
> This change enables to simplify (and speed-up!) a lot of code:
> 
> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header.
> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Renaissance
> 
> 
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 92 commits:

 - Merge branch 'master' into JDK-8291555-v2
 - Small fixes
 - Fix anon owner in fast-path, avoid runtime call (aarch64)
 - Fix anon owner in fast-path, avoid runtime call (x86_64)
 - Daniel's suggested changes
 - 8291555-dcubed-editorial-1
 - Merge branch 'master' into JDK-8291556-v2
 - Revert UseFastLocking to default to off
 - Change log message inflate(locked) -> inflate(has_locker)
 - Properly set ZF on anon-check path; avoid some conditional branches
 - ... and 82 more: https://git.openjdk.org/jdk/compare/8c2c8b3f...8bdeda39

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

Changes: https://git.openjdk.org/jdk/pull/10907/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=10
  Stats: 2066 lines in 74 files changed: 1309 ins; 93 del; 664 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From xuelei at openjdk.org  Tue Feb 14 15:39:35 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 14 Feb 2023 15:39:35 GMT
Subject: Integrated: 8301279: update for deprecated sprintf for management
 components
In-Reply-To: <GWoNgierf17aTWNajU0zV15VGoRNbh7rYHHG603jr2E=.6c03bfc9-2456-4981-8aaf-318e7b71466f@github.com>
References: <GWoNgierf17aTWNajU0zV15VGoRNbh7rYHHG603jr2E=.6c03bfc9-2456-4981-8aaf-318e7b71466f@github.com>
Message-ID: <Y3H9LwPuGQd9iMpV8O3CJxEShHetboCGb4EFvFliknY=.a6eb7235-a404-448b-8cec-2d0c7871b3f3@github.com>

On Fri, 27 Jan 2023 20:32:35 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in management components.

This pull request has now been integrated.

Changeset: ec901f28
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec901f28c3fde1aa7cef0ea41fe8bc3896ad962e
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8301279: update for deprecated sprintf for management components

Reviewed-by: kevinw, dholmes

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

PR: https://git.openjdk.org/jdk/pull/12266

From lmesnik at openjdk.org  Tue Feb 14 22:34:42 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 14 Feb 2023 22:34:42 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v2]
In-Reply-To: <WiEiO1ZIvhcSkZYtVPdi8jiC6_cyGWaE0FYKvg8ZQwA=.8b387305-0b2a-4e9d-ad10-43abb4a415e6@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <WiEiO1ZIvhcSkZYtVPdi8jiC6_cyGWaE0FYKvg8ZQwA=.8b387305-0b2a-4e9d-ad10-43abb4a415e6@github.com>
Message-ID: <TdISPWXMZrdFNTLHAEdpERr1gF-_omNuk0eed7Dv8Zg=.1bf41126-f5b8-4865-97cb-53cb947866c6@github.com>

On Mon, 13 Feb 2023 19:51:12 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
>> 
>> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
>> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
>> 
>> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
>> 
>> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
>> 
>> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - use different @test to run with -XX:-VMContinuations
>  - more removals of @requires vm.continuations
>  - change BasicVirtualThread_klass -> BaseVirtualThread_klass

I've left one comment. Otherwise test changes looks good to me.

test/hotspot/jtreg/serviceability/jvmti/vthread/BoundVThreadTest/BoundVThreadTest.java line 27:

> 25:  * @test
> 26:  * @summary Verifies correct JVMTI behavior for BoundVirtualThreads.
> 27:  * @compile --enable-preview -source ${jdk.version} BoundVThreadTest.java

You could use @enablePreview instead.

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

Marked as reviewed by lmesnik (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12512

From coleenp at openjdk.org  Wed Feb 15 00:56:45 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Feb 2023 00:56:45 GMT
Subject: RFR: JDK-8302455: VM.classloader_stats memory size values are
 wrong
In-Reply-To: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>
References: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>
Message-ID: <c-iR_I2F_wr6IOWwuscCTUker9FBRDVyrHx1JTRwBxg=.1fcf2c57-27b6-47be-b09b-24d0843ec21b@github.com>

On Tue, 14 Feb 2023 13:40:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> VM.classloader_stats shows metaspace consumption in words, but should show bytes. 
> 
> Patch fixes that, and adjusts the associated jtreg test to catch regressions like this.
> 
> I manually tested the test with the unpatched hotspot to see if the regression shows up, it does.
> 
> Tested the patch on x64 (fastdebug, release) and x86.
> 
> Note: "calculate_jfr_stats" is misnamed, actually only ever used by this dcmd, not by jfr. I will clear this up in a separate RFE.

Looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12556

From pchilanomate at openjdk.org  Wed Feb 15 01:22:33 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 15 Feb 2023 01:22:33 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v3]
In-Reply-To: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
Message-ID: <PXNLfQ0zN-PVmukV4zfJ1Vx1YoQTQ2sH5SaztW2pBpQ=.0bc3e63b-158a-4e9e-a591-71c3eec40bac@github.com>

> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
> 
> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
> 
> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
> 
> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
> 
> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  use @enablePreview instead

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12512/files
  - new: https://git.openjdk.org/jdk/pull/12512/files/99cf204c..f7f9553e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12512&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12512&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/12512

From pchilanomate at openjdk.org  Wed Feb 15 01:22:35 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 15 Feb 2023 01:22:35 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v2]
In-Reply-To: <H_gu7W6pVefDOJ9RghztPNaLssZJvCJSXQu0NPJPSwg=.89618054-6c3f-4a31-a054-4598bebaad86@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <WiEiO1ZIvhcSkZYtVPdi8jiC6_cyGWaE0FYKvg8ZQwA=.8b387305-0b2a-4e9d-ad10-43abb4a415e6@github.com>
 <H_gu7W6pVefDOJ9RghztPNaLssZJvCJSXQu0NPJPSwg=.89618054-6c3f-4a31-a054-4598bebaad86@github.com>
Message-ID: <dYqPjhTzPGphQ2iHt_dyPDkaoIIcoUIHps8RltQG9dM=.c2618eec-b91d-4a13-8f3c-ea2bd1aa2d79@github.com>

On Tue, 14 Feb 2023 14:20:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The changes in the updates look good. I think the main thing to decide on is whether JavaThread:: _is_bound_vthread is needed or not. If GetCurrentThreadCpuTime is changed to allow an implementation support this function then it looks like the additional field would not be needed.
>
Great, thanks for looking at this Alan. I'll remove _is_bound_vthread if we change the specs for GetCurrentThreadCpuTime then.

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

PR: https://git.openjdk.org/jdk/pull/12512

From pchilanomate at openjdk.org  Wed Feb 15 01:22:37 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 15 Feb 2023 01:22:37 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v2]
In-Reply-To: <TdISPWXMZrdFNTLHAEdpERr1gF-_omNuk0eed7Dv8Zg=.1bf41126-f5b8-4865-97cb-53cb947866c6@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <WiEiO1ZIvhcSkZYtVPdi8jiC6_cyGWaE0FYKvg8ZQwA=.8b387305-0b2a-4e9d-ad10-43abb4a415e6@github.com>
 <TdISPWXMZrdFNTLHAEdpERr1gF-_omNuk0eed7Dv8Zg=.1bf41126-f5b8-4865-97cb-53cb947866c6@github.com>
Message-ID: <foywdExLel2InYYVm64LDiqzVen91wJI1KSMTU7ZJUk=.30888dc8-1a1b-4be1-bc95-cfd5690ccec2@github.com>

On Tue, 14 Feb 2023 22:31:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> I've left one comment. Otherwise test changes looks good to me.
>
Thanks for the review Leonid!

> test/hotspot/jtreg/serviceability/jvmti/vthread/BoundVThreadTest/BoundVThreadTest.java line 27:
> 
>> 25:  * @test
>> 26:  * @summary Verifies correct JVMTI behavior for BoundVirtualThreads.
>> 27:  * @compile --enable-preview -source ${jdk.version} BoundVThreadTest.java
> 
> You could use @enablePreview instead.

Changed.

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

PR: https://git.openjdk.org/jdk/pull/12512

From sspitsyn at openjdk.org  Wed Feb 15 05:01:43 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Feb 2023 05:01:43 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v3]
In-Reply-To: <PXNLfQ0zN-PVmukV4zfJ1Vx1YoQTQ2sH5SaztW2pBpQ=.0bc3e63b-158a-4e9e-a591-71c3eec40bac@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <PXNLfQ0zN-PVmukV4zfJ1Vx1YoQTQ2sH5SaztW2pBpQ=.0bc3e63b-158a-4e9e-a591-71c3eec40bac@github.com>
Message-ID: <RuDYjbbsSQhQOS8Z-QwhOboQqzCFIZp4Q1wPTStv-rw=.e6e92c04-3aa5-48c4-87ab-0e000a11a35a@github.com>

On Wed, 15 Feb 2023 01:22:33 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
>> 
>> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
>> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
>> 
>> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
>> 
>> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
>> 
>> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use @enablePreview instead

src/hotspot/share/prims/jvmtiEnv.cpp line 1045:

> 1043:             JvmtiEnvBase::is_vthread_alive(vt_oop) &&
> 1044:             !JvmtiVTSuspender::is_vthread_suspended(vt_oop)) ||
> 1045:             java_thread->is_bound_vthread()) &&

This condition does not look correct.
I'd expect it to be:
 ```
         ((java_lang_VirtualThread::is_instance(vt_oop) &&
           JvmtiEnvBase::is_vthread_alive(vt_oop)) ||
          java_thread->is_bound_vthread()) &&
          !JvmtiVTSuspender::is_vthread_suspended(vt_oop) &&

It is important to check for `!JvmtiVTSuspender::is_vthread_suspended(vt_oop)` for `bound_vthread` as well.
The same issue is in the `JvmtiEnv::ResumeAllVirtualThreads`.

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

PR: https://git.openjdk.org/jdk/pull/12512

From sspitsyn at openjdk.org  Wed Feb 15 05:06:46 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Feb 2023 05:06:46 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v3]
In-Reply-To: <PXNLfQ0zN-PVmukV4zfJ1Vx1YoQTQ2sH5SaztW2pBpQ=.0bc3e63b-158a-4e9e-a591-71c3eec40bac@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <PXNLfQ0zN-PVmukV4zfJ1Vx1YoQTQ2sH5SaztW2pBpQ=.0bc3e63b-158a-4e9e-a591-71c3eec40bac@github.com>
Message-ID: <Au35V60A-SAAkmrLAoi6MSqdtgh6E1rphGgJzyVxwU0=.c740d207-d820-476a-9436-40d0ac751207@github.com>

On Wed, 15 Feb 2023 01:22:33 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
>> 
>> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
>> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
>> 
>> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
>> 
>> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
>> 
>> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use @enablePreview instead

Patricio,
The fix looks pretty solid to me.
I've already posted one comment and will post a couple of formatting nits.
I agree with Alan, it'd be nice to get rid of `is_bound_vthread` if possible.
I will make one more pass after your update.
Also, I'd address the JVMTI spec issue (mentioned by Alan) in a separate CR that needs to go with a CSR.
I'll file an RFE or spec bug on it.
Thanks,
Serguei

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

PR: https://git.openjdk.org/jdk/pull/12512

From sspitsyn at openjdk.org  Wed Feb 15 05:09:46 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Feb 2023 05:09:46 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v3]
In-Reply-To: <PXNLfQ0zN-PVmukV4zfJ1Vx1YoQTQ2sH5SaztW2pBpQ=.0bc3e63b-158a-4e9e-a591-71c3eec40bac@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <PXNLfQ0zN-PVmukV4zfJ1Vx1YoQTQ2sH5SaztW2pBpQ=.0bc3e63b-158a-4e9e-a591-71c3eec40bac@github.com>
Message-ID: <P7wnzkt_J9g3iMMdxG6L6TGJ81XNKVhyR3FO6gn6K4E=.647e3fa7-f800-4d52-8960-aca3601a2cfe@github.com>

On Wed, 15 Feb 2023 01:22:33 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
>> 
>> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
>> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
>> 
>> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
>> 
>> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
>> 
>> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use @enablePreview instead

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1587:

> 1585:   if (!is_passive_cthread) {
> 1586:     assert(thread_h() != nullptr, "sanity check");
> 1587:     assert(single_suspend || thread_h()->is_a(vmClasses::BaseVirtualThread_klass()), "SuspendAllVirtualThreads should never suspend non-virtual threads");

Nit: It is better to split this line by placing assert message on a separate line.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1648:

> 1646:   if (!is_passive_cthread) {
> 1647:     assert(thread_h() != nullptr, "sanity check");
> 1648:     assert(single_resume || thread_h()->is_a(vmClasses::BaseVirtualThread_klass()), "ResumeAllVirtualThreads should never resume non-virtual threads");

Nit: It is better to split this line by placing assert message on a separate line.

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

PR: https://git.openjdk.org/jdk/pull/12512

From dholmes at openjdk.org  Wed Feb 15 05:20:42 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Feb 2023 05:20:42 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
 <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
Message-ID: <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>

On Tue, 14 Feb 2023 09:22:00 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> The original assumption does not always hold anymore and should therefore relaxed.
>
> I think `unextended_sp < sp` is possible on x86 when interpreter entries generated by `MethodHandles::generate_method_handle_interpreter_entry()` are executed. They modify `sp` ([here for example](https://github.com/openjdk/jdk/blob/7f71a1040d9c03f72d082e329ccaf2c4a3c060a6/src/hotspot/cpu/x86/methodHandles_x86.cpp#L310-L314)) but not `sender_sp` (`InterpreterMacroAssembler ::_bcp_register`).

>From `frame_x86.hpp`:

  // The interpreter and adapters will extend the frame of the caller.
  // Since oopMaps are based on the sp of the caller before extension
  // we need to know that value. However in order to compute the address
  // of the return address we need the real "raw" sp. By convention we
  // use sp() to mean "raw" sp and unextended_sp() to mean the caller's
  // original sp.

by that definition `unextended_sp` is always > `sp`. If something has violated that definition/convention then we may have bigger problems!

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

PR: https://git.openjdk.org/jdk/pull/12535

From dholmes at openjdk.org  Wed Feb 15 05:51:40 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Feb 2023 05:51:40 GMT
Subject: RFR: JDK-8302455: VM.classloader_stats memory size values are
 wrong
In-Reply-To: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>
References: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>
Message-ID: <-3GSwkZxW1Xr6LLmg-yuxtfzOYPmXUFIcNNRqxgB-eg=.8c9d3510-4335-48a6-95c3-0cad592f7452@github.com>

On Tue, 14 Feb 2023 13:40:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> VM.classloader_stats shows metaspace consumption in words, but should show bytes. 
> 
> Patch fixes that, and adjusts the associated jtreg test to catch regressions like this.
> 
> I manually tested the test with the unpatched hotspot to see if the regression shows up, it does.
> 
> Tested the patch on x64 (fastdebug, release) and x86.
> 
> Note: "calculate_jfr_stats" is misnamed, actually only ever used by this dcmd, not by jfr. I will clear this up in a separate RFE.

So in addition to the poor name, the declaration is wrong:

 void calculate_jfr_stats(size_t* p_used_bytes, size_t* p_capacity_bytes) const;

as it refers to bytes not words. Perhaps better to clean this up completely in this issue rather than a separate RFE?

That said, given:

// This only exists for JFR and jcmd VM.classloader_stats. We may want to
//  change this. Capacity as a stat is of questionable use since it may
//  contain committed and uncommitted areas. For now we do this to maintain
//  backward compatibility with JFR.

and the fact this is not used by JFR then maybe it should all just be removed?

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

PR: https://git.openjdk.org/jdk/pull/12556

From stuefe at openjdk.org  Wed Feb 15 06:36:40 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 15 Feb 2023 06:36:40 GMT
Subject: RFR: JDK-8302455: VM.classloader_stats memory size values are
 wrong
In-Reply-To: <-3GSwkZxW1Xr6LLmg-yuxtfzOYPmXUFIcNNRqxgB-eg=.8c9d3510-4335-48a6-95c3-0cad592f7452@github.com>
References: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>
 <-3GSwkZxW1Xr6LLmg-yuxtfzOYPmXUFIcNNRqxgB-eg=.8c9d3510-4335-48a6-95c3-0cad592f7452@github.com>
Message-ID: <6D3GHH9i4DpNsW7juBhGAc-Kuf7znGh7ZIHhX12h9d8=.e05c476d-630d-4257-a6cc-f2ba6fbdc115@github.com>

On Wed, 15 Feb 2023 05:49:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> That said, given:
> 
> ```
> // This only exists for JFR and jcmd VM.classloader_stats. We may want to
> //  change this. Capacity as a stat is of questionable use since it may
> //  contain committed and uncommitted areas. For now we do this to maintain
> //  backward compatibility with JFR.
> ```
> 
> and the fact this is not used by JFR then maybe it should all just be removed?

That's my plan, but I'd like to do this in a follow-up RFE. The patch I'd like to keep minimal for easy downport. I'd like to keep cleanups separate.

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

PR: https://git.openjdk.org/jdk/pull/12556

From yyang at openjdk.org  Wed Feb 15 06:45:46 2023
From: yyang at openjdk.org (Yi Yang)
Date: Wed, 15 Feb 2023 06:45:46 GMT
Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different
 platforms [v6]
In-Reply-To: <Exftkn6hAHTDhuhy2OkPasZUKbzA_Wb8QwgAaOx080s=.2e479e24-6e3a-4690-abd0-d01a7dbb21c0@github.com>
References: <caqEOVOGSxIglZBVTs7nNyjOWDzjblUURwIQhzi_8Lk=.2552d17b-d72f-4ebf-ae46-acdece170507@github.com>
 <27esMViORNgCNjS04-6IJfCHcva5NmbCZ3p6yYP2OjQ=.2e294967-6467-4a07-b9b7-004545a9584b@github.com>
 <Exftkn6hAHTDhuhy2OkPasZUKbzA_Wb8QwgAaOx080s=.2e479e24-6e3a-4690-abd0-d01a7dbb21c0@github.com>
Message-ID: <NpBBXEJTrg33Hm35qcqw-flnKQOfwe-gmZlSXK5zkgU=.2513e20f-c017-4cf1-bc2c-87f6de09eafe@github.com>

On Wed, 11 Jan 2023 19:13:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - format
>>  - Merge branch 'jdk_virtualmachienimpl' of github.com:y1yang0/jdk into jdk_virtualmachienimpl
>>  - -1 to vmid
>
> src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 455:
> 
>> 453:             if (fd != -1) {
>> 454:                 close(fd);
>> 455:             }
> 
> There used to be logic to set `fd` (previously called `s`) to -1 during the close operation. Is that no longer needed?

Hi @plummercj , sorry for late reply. 

I don't see why we need it because this method is protected by synchronized. fd is only set by ctor.

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

PR: https://git.openjdk.org/jdk/pull/11823

From duke at openjdk.org  Wed Feb 15 07:13:44 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Wed, 15 Feb 2023 07:13:44 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
 <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
 <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>
Message-ID: <4kKR1KP5iJ7G1_lvNKt4jOgRcCIyzDvlLDfO4rtxm2w=.c6fab761-d1ed-405b-b3b5-001a8e19f5db@github.com>

On Wed, 15 Feb 2023 05:17:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I think `unextended_sp < sp` is possible on x86 when interpreter entries generated by `MethodHandles::generate_method_handle_interpreter_entry()` are executed. They modify `sp` ([here for example](https://github.com/openjdk/jdk/blob/7f71a1040d9c03f72d082e329ccaf2c4a3c060a6/src/hotspot/cpu/x86/methodHandles_x86.cpp#L310-L314)) but not `sender_sp` (`InterpreterMacroAssembler ::_bcp_register`).
>
> From `frame_x86.hpp`:
> 
>   // The interpreter and adapters will extend the frame of the caller.
>   // Since oopMaps are based on the sp of the caller before extension
>   // we need to know that value. However in order to compute the address
>   // of the return address we need the real "raw" sp. By convention we
>   // use sp() to mean "raw" sp and unextended_sp() to mean the caller's
>   // original sp.
> 
> by that definition `unextended_sp` is always > `sp`. If something has violated that definition/convention then we may have bigger problems!

I get the following values for `sp` and `unextended_sp` when running this test case:


int sp = 0x7f9f1ec614e0, unextended sp = 0x7f9f1ec614e0
int sp = 0x7f9f1ec61538, unextended sp = 0x7f9f1ec61548
int sp = 0x7f9f1ec615a0, unextended sp = 0x7f9f1ec61598 // the assumption fails here
int sp = 0x7f9f1ec61600, unextended sp = 0x7f9f1ec61608
int sp = 0x7f9f1ec61670, unextended sp = 0x7f9f1ec61688
...

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

PR: https://git.openjdk.org/jdk/pull/12535

From dholmes at openjdk.org  Wed Feb 15 07:48:40 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Feb 2023 07:48:40 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <4kKR1KP5iJ7G1_lvNKt4jOgRcCIyzDvlLDfO4rtxm2w=.c6fab761-d1ed-405b-b3b5-001a8e19f5db@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
 <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
 <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>
 <4kKR1KP5iJ7G1_lvNKt4jOgRcCIyzDvlLDfO4rtxm2w=.c6fab761-d1ed-405b-b3b5-001a8e19f5db@github.com>
Message-ID: <az34yLx_KXPTfsMkisg1iz29rHRSON_cRDAUiFa3YCI=.595c997f-444c-4e17-aa03-ff81b6406e71@github.com>

On Wed, 15 Feb 2023 07:10:29 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> From `frame_x86.hpp`:
>> 
>>   // The interpreter and adapters will extend the frame of the caller.
>>   // Since oopMaps are based on the sp of the caller before extension
>>   // we need to know that value. However in order to compute the address
>>   // of the return address we need the real "raw" sp. By convention we
>>   // use sp() to mean "raw" sp and unextended_sp() to mean the caller's
>>   // original sp.
>> 
>> by that definition `unextended_sp` is always > `sp`. If something has violated that definition/convention then we may have bigger problems!
>
> I get the following values for `sp` and `unextended_sp` when running this test case:
> 
> 
> int sp = 0x7f9f1ec614e0, unextended sp = 0x7f9f1ec614e0
> int sp = 0x7f9f1ec61538, unextended sp = 0x7f9f1ec61548
> int sp = 0x7f9f1ec615a0, unextended sp = 0x7f9f1ec61598 // the assumption fails here
> int sp = 0x7f9f1ec61600, unextended sp = 0x7f9f1ec61608
> int sp = 0x7f9f1ec61670, unextended sp = 0x7f9f1ec61688
> ...

What is the test case? Is it sending signals and then using AGCT? If so then maybe a signal hits when a call is made but before the code has a chance to update unextended_sp?

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

PR: https://git.openjdk.org/jdk/pull/12535

From dholmes at openjdk.org  Wed Feb 15 07:51:41 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Feb 2023 07:51:41 GMT
Subject: RFR: JDK-8302455: VM.classloader_stats memory size values are
 wrong
In-Reply-To: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>
References: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>
Message-ID: <0fGdM8N6ytuMVR1pccKciS1sf6kU4Fhg2d1mv_fhcvY=.a88e0c05-7ff0-4614-9343-857317bbc8d1@github.com>

On Tue, 14 Feb 2023 13:40:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> VM.classloader_stats shows metaspace consumption in words, but should show bytes. 
> 
> Patch fixes that, and adjusts the associated jtreg test to catch regressions like this.
> 
> I manually tested the test with the unpatched hotspot to see if the regression shows up, it does.
> 
> Tested the patch on x64 (fastdebug, release) and x86.
> 
> Note: "calculate_jfr_stats" is misnamed, actually only ever used by this dcmd, not by jfr. I will clear this up in a separate RFE.

Given the reason this bug likely arose is the fact the parameters to `calculate_jfr_stats` say they are "bytes" then fixing that is not a mere cleanup IMO. Can we at least fix that in this PR?

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

PR: https://git.openjdk.org/jdk/pull/12556

From duke at openjdk.org  Wed Feb 15 07:53:40 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Wed, 15 Feb 2023 07:53:40 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <az34yLx_KXPTfsMkisg1iz29rHRSON_cRDAUiFa3YCI=.595c997f-444c-4e17-aa03-ff81b6406e71@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
 <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
 <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>
 <4kKR1KP5iJ7G1_lvNKt4jOgRcCIyzDvlLDfO4rtxm2w=.c6fab761-d1ed-405b-b3b5-001a8e19f5db@github.com>
 <az34yLx_KXPTfsMkisg1iz29rHRSON_cRDAUiFa3YCI=.595c997f-444c-4e17-aa03-ff81b6406e71@github.com>
Message-ID: <N0UvyYW8APmGD_RLtPCAqzpAyFUr11Nb7xn6d0wZd9E=.48a0fa88-8d79-4a0e-81eb-62a11f0d2e6f@github.com>

On Wed, 15 Feb 2023 07:46:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> What is the test case?

The sanity test I amended with more checks.

> Is it sending signals and then using AGCT?

No. Just calling ASGCT directly in a native method which is called directly in the main method of a JTREG test.

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

PR: https://git.openjdk.org/jdk/pull/12535

From dholmes at openjdk.org  Wed Feb 15 09:04:49 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Feb 2023 09:04:49 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <N0UvyYW8APmGD_RLtPCAqzpAyFUr11Nb7xn6d0wZd9E=.48a0fa88-8d79-4a0e-81eb-62a11f0d2e6f@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
 <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
 <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>
 <4kKR1KP5iJ7G1_lvNKt4jOgRcCIyzDvlLDfO4rtxm2w=.c6fab761-d1ed-405b-b3b5-001a8e19f5db@github.com>
 <az34yLx_KXPTfsMkisg1iz29rHRSON_cRDAUiFa3YCI=.595c997f-444c-4e17-aa03-ff81b6406e71@github.com>
 <N0UvyYW8APmGD_RLtPCAqzpAyFUr11Nb7xn6d0wZd9E=.48a0fa88-8d79-4a0e-81eb-62a11f0d2e6f@github.com>
Message-ID: <3T7nJ7BvnPjezFb-EzwCNkjq-zRjjsK-LrZTdRgZmzY=.c9ad8912-fbab-4b96-a9c1-9fe104cc904d@github.com>

On Wed, 15 Feb 2023 07:50:56 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> What is the test case? Is it sending signals and then using AGCT? If so then maybe a signal hits when a call is made but before the code has a chance to update unextended_sp?
>
>> What is the test case?
> 
> The sanity test I amended with more checks.
> 
>> Is it sending signals and then using AGCT?
> 
> No. Just calling ASGCT directly in a native method which is called directly in the main method of a JTREG test.

Are you referring to the test in test/hotspot/jtreg/serviceability/AsyncGetCallTrace/ ?

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

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Wed Feb 15 09:04:51 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Wed, 15 Feb 2023 09:04:51 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <3T7nJ7BvnPjezFb-EzwCNkjq-zRjjsK-LrZTdRgZmzY=.c9ad8912-fbab-4b96-a9c1-9fe104cc904d@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
 <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
 <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>
 <4kKR1KP5iJ7G1_lvNKt4jOgRcCIyzDvlLDfO4rtxm2w=.c6fab761-d1ed-405b-b3b5-001a8e19f5db@github.com>
 <az34yLx_KXPTfsMkisg1iz29rHRSON_cRDAUiFa3YCI=.595c997f-444c-4e17-aa03-ff81b6406e71@github.com>
 <N0UvyYW8APmGD_RLtPCAqzpAyFUr11Nb7xn6d0wZd9E=.48a0fa88-8d79-4a0e-81eb-62a11f0d2e6f@github.com>
 <3T7nJ7BvnPjezFb-EzwCNkjq-zRjjsK-LrZTdRgZmzY=.c9ad8912-fbab-4b96-a9c1-9fe104cc904d@github.com>
Message-ID: <Dit5d8mZV36XF32tzyZrbiuYM4M5xKXyYsiI2LR5F7A=.edcc8f71-75bd-4c4d-a062-7ac56f71b643@github.com>

On Wed, 15 Feb 2023 09:00:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> What is the test case?
>> 
>> The sanity test I amended with more checks.
>> 
>>> Is it sending signals and then using AGCT?
>> 
>> No. Just calling ASGCT directly in a native method which is called directly in the main method of a JTREG test.
>
> Are you referring to the test in test/hotspot/jtreg/serviceability/AsyncGetCallTrace/ ?

Yes.

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

PR: https://git.openjdk.org/jdk/pull/12535

From stuefe at openjdk.org  Wed Feb 15 10:40:13 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 15 Feb 2023 10:40:13 GMT
Subject: RFR: JDK-8302455: VM.classloader_stats memory size values are
 wrong
In-Reply-To: <0fGdM8N6ytuMVR1pccKciS1sf6kU4Fhg2d1mv_fhcvY=.a88e0c05-7ff0-4614-9343-857317bbc8d1@github.com>
References: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>
 <0fGdM8N6ytuMVR1pccKciS1sf6kU4Fhg2d1mv_fhcvY=.a88e0c05-7ff0-4614-9343-857317bbc8d1@github.com>
Message-ID: <VNjFDzeFciutJ-rT05l-N72qN0_aBKW9_eA8fO0iXus=.5017e473-fa93-4caa-b435-77eacac38f8d@github.com>

On Wed, 15 Feb 2023 07:49:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Given the reason this bug likely arose is the fact the parameters to `calculate_jfr_stats` say they are "bytes" then fixing that is not a mere cleanup IMO. Can we at least fix that in this PR?

Hi David, I reformed the ill-named function and renamed it to "usage_numbers", because that name and prototype is used in other places in Metaspace as well (e.g. MetaspaceArena), so its a uniform scheme.

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

PR: https://git.openjdk.org/jdk/pull/12556

From stuefe at openjdk.org  Wed Feb 15 10:40:13 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 15 Feb 2023 10:40:13 GMT
Subject: RFR: JDK-8302455: VM.classloader_stats memory size values are
 wrong [v2]
In-Reply-To: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>
References: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>
Message-ID: <tnMDCPaZEqKdJ4gdLZlqWjp0Ae86bXHe6EwMgKUjSvQ=.18bac6f2-67f4-45b6-90c8-69bf1960a035@github.com>

> VM.classloader_stats shows metaspace consumption in words, but should show bytes. 
> 
> Patch fixes that, and adjusts the associated jtreg test to catch regressions like this.
> 
> I manually tested the test with the unpatched hotspot to see if the regression shows up, it does.
> 
> Tested the patch on x64 (fastdebug, release) and x86.
> 
> Note: "calculate_jfr_stats" is misnamed, actually only ever used by this dcmd, not by jfr. I will clear this up in a separate RFE.

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

  Request David

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12556/files
  - new: https://git.openjdk.org/jdk/pull/12556/files/2be3a810..0bbbcc15

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12556&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12556&range=00-01

  Stats: 33 lines in 3 files changed: 9 ins; 2 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/12556.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12556/head:pull/12556

PR: https://git.openjdk.org/jdk/pull/12556

From stuefe at openjdk.org  Wed Feb 15 10:50:11 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 15 Feb 2023 10:50:11 GMT
Subject: RFR: JDK-8302455: VM.classloader_stats memory size values are
 wrong [v3]
In-Reply-To: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>
References: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>
Message-ID: <R-bIZ_fWCJ8occDbFp5bkqL34JmfkmC3jtRR_6YO4zE=.9f2cb45a-177c-496c-977a-3d77c3615aba@github.com>

> VM.classloader_stats shows metaspace consumption in words, but should show bytes. 
> 
> Patch fixes that, and adjusts the associated jtreg test to catch regressions like this.
> 
> I manually tested the test with the unpatched hotspot to see if the regression shows up, it does.
> 
> Tested the patch on x64 (fastdebug, release) and x86.
> 
> Note: "calculate_jfr_stats" is misnamed, actually only ever used by this dcmd, not by jfr. I will clear this up in a separate RFE.

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

  Fix -UseCCP and add regression test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12556/files
  - new: https://git.openjdk.org/jdk/pull/12556/files/0bbbcc15..7ed3951a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12556&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12556&range=01-02

  Stats: 15 lines in 2 files changed: 13 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12556.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12556/head:pull/12556

PR: https://git.openjdk.org/jdk/pull/12556

From abakhtin at openjdk.org  Wed Feb 15 13:48:46 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Wed, 15 Feb 2023 13:48:46 GMT
Subject: RFR: 8299234: JMX Repository.query performance [v5]
In-Reply-To: <YH-y2lwy0IU4s9Ri6vuNwwgpZpJzFIQW_ttuE8KkFFs=.ccabc1f9-d27d-469a-847b-69c4e882d7e6@github.com>
References: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
 <YH-y2lwy0IU4s9Ri6vuNwwgpZpJzFIQW_ttuE8KkFFs=.ccabc1f9-d27d-469a-847b-69c4e882d7e6@github.com>
Message-ID: <ttteH4Me8c4A04N0JP7VYKVGAGq1mHbPXUbTxn2Nk50=.1fed8806-a0eb-4049-b4ce-8d94178af15d@github.com>

On Thu, 2 Feb 2023 13:42:51 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please find a patch to improve JMX Repository.query performance
>> 
>> Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles:
>> Before:
>> 
>> $ java test 1000000 1000000
>> Test PASSED in 8943169791 ns.
>> GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118
>> 
>> 
>> After:
>> 
>> $ java test 1000000 1000000
>> Test PASSED in 4808213917 ns.
>> GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53
>> 
>> Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation.
>> 
>> All javax/management jtreg tests passed successfully.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize ObjectName.matchDomains

@AlanBateman, Could you please take a look at the proposed performance improvement? It is required to reduce high CPU utilization caused by unnecessary HashTable cloning in the [ObjectName::getKeyPropertyList()](https://github.com/openjdk/jdk/blob/master/src/java.management/share/classes/javax/management/ObjectName.java#L1685). I also would like to backport it to 17, 11 and 8 if the changes are acceptable.
Thank you in advance

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

PR: https://git.openjdk.org/jdk/pull/11758

From jvernee at openjdk.org  Wed Feb 15 20:28:58 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 15 Feb 2023 20:28:58 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <Dit5d8mZV36XF32tzyZrbiuYM4M5xKXyYsiI2LR5F7A=.edcc8f71-75bd-4c4d-a062-7ac56f71b643@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
 <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
 <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>
 <4kKR1KP5iJ7G1_lvNKt4jOgRcCIyzDvlLDfO4rtxm2w=.c6fab761-d1ed-405b-b3b5-001a8e19f5db@github.com>
 <az34yLx_KXPTfsMkisg1iz29rHRSON_cRDAUiFa3YCI=.595c997f-444c-4e17-aa03-ff81b6406e71@github.com>
 <N0UvyYW8APmGD_RLtPCAqzpAyFUr11Nb7xn6d0wZd9E=.48a0fa88-8d79-4a0e-81eb-62a11f0d2e6f@github.com>
 <3T7nJ7BvnPjezFb-EzwCNkjq-zRjjsK-LrZTdRgZmzY=.c9ad8912-fbab-4b96-a9c1-9fe104cc904d@github.com>
 <Dit5d8mZV36XF32tzyZrbiuYM4M5xKXyYsi
 I2LR5F7A=.edcc8f71-75bd-4c4d-a062-7ac56f71b643@github.com>
Message-ID: <T5MrQlsBXNe4YW3SJYkohSeatamAgSsfcOpwCcApkRI=.f14c783f-5ecb-4456-8c01-6a1cd961e791@github.com>

On Wed, 15 Feb 2023 09:01:29 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Are you referring to the test in test/hotspot/jtreg/serviceability/AsyncGetCallTrace/ ?
>
> Yes.

> I think `unextended_sp < sp` is possible on x86 when interpreter entries generated by `MethodHandles::generate_method_handle_interpreter_entry()` are executed. They modify `sp` ([here for example](https://github.com/openjdk/jdk/blob/7f71a1040d9c03f72d082e329ccaf2c4a3c060a6/src/hotspot/cpu/x86/methodHandles_x86.cpp#L310-L314)) but not `sender_sp` (`InterpreterMacroAssembler ::_bcp_register`).

I think we're talking about a case where an interpreted caller calls an interpreted callee through a MethodHandle. If my understanding is correct, in that case there are 2 sender sps, one that is computed based on the frame pointer of the callee. This just adds 2 words (skipping the return address), and the other is the sp which is saved into `r13` before e.g. a c2i adapter extends the stack [here](https://github.com/openjdk/jdk/blob/50dcc2aec5b16c0826e27d58e49a7f55a5f5ad38/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L631) Which then seems to be saved in the interpreted callee's frame as well (I'm not super familiar with interpreter frame layouts though...).

I think your conclusion is correct wrt `unextended_sp < sp` in that case. For certain MH linker calls, an additional `MemberName` 'appendix' is passed as the last argument. The MH adapter/trampoline stub pops the appendix argument from the stack for an interpreted caller, and uses it to find out the actual callee. But that means that, the sp saved into `r13` will be one slot too large. In other words, the MethodHandle adapter for interpreted callers 'consumes' the appendix argument, but doesn't adjust `r13`. I think this could be done though, i.e. just add:


 __ subptr(r13, Interpreter::stackElementSize);   // adjust unexteded_sp for callee, for proper stack walking


In the linked code in `MethodHandles::generate_method_handle_interpreter_entry` to make this work.

(note that we can not just leave the appendix on the stack, since the callee doesn't expect it, so we would break argument oop GC if we left it there)

I think doing that would be preferable to adjusting `safe_for_sender`. That seems like it would uphold the `sp <= unextended_sp` invariant as well (maybe an assert to that effect in the constructor of `frame` wouldn't be a bad idea as well).

It seems like PPC is not modifying the stack in this case (?):


    Register R19_member = R19_method;  // MemberName ptr; incoming method ptr is dead now
    __ ld(R19_member, RegisterOrConstant((intptr_t)8), R15_argbase);
    __ addi(R15_argbase, R15_argbase, Interpreter::stackElementSize);
    generate_method_handle_dispatch(_masm, iid, tmp_recv, R19_member, not_for_compiler_entry);

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

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Wed Feb 15 20:42:34 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Wed, 15 Feb 2023 20:42:34 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <T5MrQlsBXNe4YW3SJYkohSeatamAgSsfcOpwCcApkRI=.f14c783f-5ecb-4456-8c01-6a1cd961e791@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
 <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
 <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>
 <4kKR1KP5iJ7G1_lvNKt4jOgRcCIyzDvlLDfO4rtxm2w=.c6fab761-d1ed-405b-b3b5-001a8e19f5db@github.com>
 <az34yLx_KXPTfsMkisg1iz29rHRSON_cRDAUiFa3YCI=.595c997f-444c-4e17-aa03-ff81b6406e71@github.com>
 <N0UvyYW8APmGD_RLtPCAqzpAyFUr11Nb7xn6d0wZd9E=.48a0fa88-8d79-4a0e-81eb-62a11f0d2e6f@github.com>
 <3T7nJ7BvnPjezFb-EzwCNkjq-zRjjsK-LrZTdRgZmzY=.c9ad8912-fbab-4b96-a9c1-9fe104cc904d@github.com>
 <Dit5d8mZV36XF32tzyZrbiuYM4M5xKXyYsi
 I2LR5F7A=.edcc8f71-75bd-4c4d-a062-7ac56f71b643@github.com>
 <T5MrQlsBXNe4YW3SJYkohSeatamAgSsfcOpwCcApkRI=.f14c783f-5ecb-4456-8c01-6a1cd961e791@github.com>
Message-ID: <f_9hdtzQUxypVHl53oAzKTPBLHiPobmsVeZvfEoPFzE=.9a6e3ab7-32b6-4c66-8498-08d19f04757e@github.com>

On Wed, 15 Feb 2023 20:24:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Yes.
>
>> I think `unextended_sp < sp` is possible on x86 when interpreter entries generated by `MethodHandles::generate_method_handle_interpreter_entry()` are executed. They modify `sp` ([here for example](https://github.com/openjdk/jdk/blob/7f71a1040d9c03f72d082e329ccaf2c4a3c060a6/src/hotspot/cpu/x86/methodHandles_x86.cpp#L310-L314)) but not `sender_sp` (`InterpreterMacroAssembler ::_bcp_register`).
> 
> I think we're talking about a case where an interpreted caller calls an interpreted callee through a MethodHandle. If my understanding is correct (looking at `frame::sender_for_interpreter_frame`), in that case there are 2 sender sps, one that is computed based on the frame pointer of the callee. This just adds 2 words (skipping the return address), and the other is the sp which is saved into `r13` before e.g. a c2i adapter extends the stack [here](https://github.com/openjdk/jdk/blob/50dcc2aec5b16c0826e27d58e49a7f55a5f5ad38/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L631) Which then seems to be saved in the interpreted callee's frame as well (I'm not super familiar with interpreter frame layouts though...). The latter being what ends up as `unextended_sp`.
> 
> I think your conclusion is correct wrt `unextended_sp < sp` in that case. For certain MH linker calls, an additional `MemberName` 'appendix' is passed as the last argument. The MH adapter/trampoline stub pops the appendix argument from the stack for an interpreted caller, and uses it to find out the actual callee. But that means that, the sp saved into `r13` will be one slot too 'large' (small? accounting for one too many arguments). In other words, the MethodHandle adapter for interpreted callers 'consumes' the appendix argument, but doesn't adjust `r13`. I think this could be done though, i.e. just add:
> 
> 
>  __ addptr(r13, Interpreter::stackElementSize);   // adjust unexteded_sp for callee, for proper stack walking
> 
> 
> In the linked code in `MethodHandles::generate_method_handle_interpreter_entry` to make this work.
> 
> (note that we can not just leave the appendix on the stack, since the callee doesn't expect it, so we would break argument oop GC if we left it there)
> 
> If that works, I think doing that would be preferable to adjusting `safe_for_sender`. That seems like it would uphold the `sp <= unextended_sp` invariant as well (maybe an assert to that effect in the constructor of `frame` wouldn't be a bad idea as well).
> 
> It seems like PPC is not modifying the stack in this case (?):
> 
> 
>     Register R19_member = R19_method;  // MemberName ptr; incoming method ptr is dead now
>     __ ld(R19_member, RegisterOrConstant((intptr_t)8), R15_argbase);
>     __ addi(R15_argbase, R15_argbase, Interpreter::stackElementSize);
>     generate_method_handle_dispatch(_masm, iid, tmp_recv, R19_member, not_for_compiler_entry);

This is an interesting insight, I'm going to test your fix idea tomorrow.

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

PR: https://git.openjdk.org/jdk/pull/12535

From pchilanomate at openjdk.org  Wed Feb 15 20:59:06 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 15 Feb 2023 20:59:06 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v4]
In-Reply-To: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
Message-ID: <q4uA2ioVEoSG2-Yhxzpbr01bzVtFz-cKmCOmeyXIsK8=.63963d45-d1af-4814-82d7-83c53b540560@github.com>

> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
> 
> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
> 
> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
> 
> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
> 
> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  split assert message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12512/files
  - new: https://git.openjdk.org/jdk/pull/12512/files/f7f9553e..7872f94c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12512&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12512&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/12512

From pchilanomate at openjdk.org  Wed Feb 15 20:59:10 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 15 Feb 2023 20:59:10 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v3]
In-Reply-To: <Au35V60A-SAAkmrLAoi6MSqdtgh6E1rphGgJzyVxwU0=.c740d207-d820-476a-9436-40d0ac751207@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <PXNLfQ0zN-PVmukV4zfJ1Vx1YoQTQ2sH5SaztW2pBpQ=.0bc3e63b-158a-4e9e-a591-71c3eec40bac@github.com>
 <Au35V60A-SAAkmrLAoi6MSqdtgh6E1rphGgJzyVxwU0=.c740d207-d820-476a-9436-40d0ac751207@github.com>
Message-ID: <R4cj_O8kYS8lbSnINj6Z8UXHZVI2aVwF1z24B0oAUgA=.6cdff6f7-cee4-4ecc-a104-7ac95781f12e@github.com>

On Wed, 15 Feb 2023 05:04:21 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Patricio, The fix looks pretty solid to me. I've already posted one comment and will post a couple of formatting nits. I agree with Alan, it'd be nice to get rid of `is_bound_vthread` if possible. I will make one more pass after your update. Also, I'd address the JVMTI spec issue (mentioned by Alan) in a separate CR that needs to go with a CSR. I'll file an RFE or spec bug on it. Thanks, Serguei
>
Thanks for looking at this Serguei.

> src/hotspot/share/prims/jvmtiEnv.cpp line 1045:
> 
>> 1043:             JvmtiEnvBase::is_vthread_alive(vt_oop) &&
>> 1044:             !JvmtiVTSuspender::is_vthread_suspended(vt_oop)) ||
>> 1045:             java_thread->is_bound_vthread()) &&
> 
> This condition does not look correct.
> I'd expect it to be:
>  ```
>          ((java_lang_VirtualThread::is_instance(vt_oop) &&
>            JvmtiEnvBase::is_vthread_alive(vt_oop)) ||
>           java_thread->is_bound_vthread()) &&
>           !JvmtiVTSuspender::is_vthread_suspended(vt_oop) &&
> 
> It is important to check for `!JvmtiVTSuspender::is_vthread_suspended(vt_oop)` for `bound_vthread` as well.
> The same issue is in the `JvmtiEnv::ResumeAllVirtualThreads`.

The thing is that JvmtiVTSuspender::is_vthread_suspended() checks _suspended_list/not_suspended_list which are not set with single suspend/resume functions(SuspendThread/SuspendThreadList/ResumeThread/ResumeThreadList) on a BoundVirtualThread. For single suspend/resume on a BoundVirtualThread we go through the same path as for platform threads. In any case, the suspend_thread() call will just return JVMTI_ERROR_THREAD_SUSPENDED if a thread is already suspended, but if you want to avoid the call altogether I can add the equivalent check which would be !java_thread->is_suspended().

Now, I realized that although single-suspends will not change _suspended_list/not_suspended_list for a BoundVirtualThread, SuspendAllVirtualThreads/ResumeAllVirtualThreads can if a BoundVirtualThread is part of the exception list. In the SuspendAllVirtualThreads case for example, when restoring the resume state, the call to JvmtiVTSuspender::is_vthread_suspended() would return true (we are already in SR_all mode and the BoundVirtualThread will not be in _not_suspended_list), meaning the BoundVirtualThread will be added to the not_suspended_list. 
So we have to decide if we want to keep track of BoundVirtualThreads on these lists or not. Given that I see JvmtiVTSuspender::is_vthread_suspended() is always called on a VirtualThread the easiest thing would be to not track them, and just add a check in SuspendAllVirtualThreads/ResumeAllVirtualThreads where the elist is populated so only VirtualThreads are added. What do you think?

> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1587:
> 
>> 1585:   if (!is_passive_cthread) {
>> 1586:     assert(thread_h() != nullptr, "sanity check");
>> 1587:     assert(single_suspend || thread_h()->is_a(vmClasses::BaseVirtualThread_klass()), "SuspendAllVirtualThreads should never suspend non-virtual threads");
> 
> Nit: It is better to split this line by placing assert message on a separate line.

Fixed.

> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1648:
> 
>> 1646:   if (!is_passive_cthread) {
>> 1647:     assert(thread_h() != nullptr, "sanity check");
>> 1648:     assert(single_resume || thread_h()->is_a(vmClasses::BaseVirtualThread_klass()), "ResumeAllVirtualThreads should never resume non-virtual threads");
> 
> Nit: It is better to split this line by placing assert message on a separate line.

Fixed.

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

PR: https://git.openjdk.org/jdk/pull/12512

From rrich at openjdk.org  Wed Feb 15 21:07:53 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 15 Feb 2023 21:07:53 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <f_9hdtzQUxypVHl53oAzKTPBLHiPobmsVeZvfEoPFzE=.9a6e3ab7-32b6-4c66-8498-08d19f04757e@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
 <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
 <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>
 <4kKR1KP5iJ7G1_lvNKt4jOgRcCIyzDvlLDfO4rtxm2w=.c6fab761-d1ed-405b-b3b5-001a8e19f5db@github.com>
 <az34yLx_KXPTfsMkisg1iz29rHRSON_cRDAUiFa3YCI=.595c997f-444c-4e17-aa03-ff81b6406e71@github.com>
 <N0UvyYW8APmGD_RLtPCAqzpAyFUr11Nb7xn6d0wZd9E=.48a0fa88-8d79-4a0e-81eb-62a11f0d2e6f@github.com>
 <3T7nJ7BvnPjezFb-EzwCNkjq-zRjjsK-LrZTdRgZmzY=.c9ad8912-fbab-4b96-a9c1-9fe104cc904d@github.com>
 <Dit5d8mZV36XF32tzyZrbiuYM4M5xKXyYsi
 I2LR5F7A=.edcc8f71-75bd-4c4d-a062-7ac56f71b643@github.com>
 <T5MrQlsBXNe4YW3SJYkohSeatamAgSsfcOpwCcApkRI=.f14c783f-5ecb-4456-8c01-6a1cd961e791@github.com>
 <f_9hdtzQUxypVHl53oAzKTPBLHiPobmsVeZvfEoPFzE=.9a6e3ab7-32b6-4c66-8498-08d19f04757e@github.com>
Message-ID: <y8hTn1ytvssUM96lapnB3PWX-tSaWduWQ51r314p4mw=.a72f2fd8-fbe5-4047-bb14-1a5ca5d80f7f@github.com>

On Wed, 15 Feb 2023 20:38:04 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>>> I think `unextended_sp < sp` is possible on x86 when interpreter entries generated by `MethodHandles::generate_method_handle_interpreter_entry()` are executed. They modify `sp` ([here for example](https://github.com/openjdk/jdk/blob/7f71a1040d9c03f72d082e329ccaf2c4a3c060a6/src/hotspot/cpu/x86/methodHandles_x86.cpp#L310-L314)) but not `sender_sp` (`InterpreterMacroAssembler ::_bcp_register`).
>> 
>> I think we're talking about a case where an interpreted caller calls an interpreted callee through a MethodHandle. If my understanding is correct (looking at `frame::sender_for_interpreter_frame`), in that case there are 2 sender sps, one that is computed based on the frame pointer of the callee. This just adds 2 words (skipping the return address), and the other is the sp which is saved into `r13` in `InterpreterMacroAssembler::prepare_to_jump_from_interpreted`, and before e.g. a c2i adapter extends the stack [here](https://github.com/openjdk/jdk/blob/50dcc2aec5b16c0826e27d58e49a7f55a5f5ad38/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L631) Which then seems to be saved in the interpreted callee's frame as well (I'm not super familiar with interpreter frame layouts though...). The latter being what ends up as `unextended_sp`.
>> 
>> I think @reinrich's conclusion is correct wrt `unextended_sp < sp` in that case. For certain MH linker calls, an additional `MemberName` 'appendix' is passed as the last argument. The MH adapter/trampoline stub pops the appendix argument from the stack for an interpreted caller, and uses it to find out the actual callee. But that means that, the sp saved into `r13` will be one slot too 'large' (small? accounting for one too many arguments). In other words, the MethodHandle adapter for interpreted callers 'consumes' the appendix argument, but doesn't adjust `r13`. I think this could be done though, i.e. just add:
>> 
>> 
>>  __ addptr(r13, Interpreter::stackElementSize);   // adjust unexteded_sp for callee, for proper stack walking
>> 
>> 
>> In the linked code in `MethodHandles::generate_method_handle_interpreter_entry` to make this work.
>> 
>> (note that we can not just leave the appendix on the stack, since the callee doesn't expect it, so we would break argument oop GC if we left it there)
>> 
>> If that works, I think doing that would be preferable to adjusting `safe_for_sender`. That seems like it would uphold the `sp <= unextended_sp` invariant as well (maybe an assert to that effect in the constructor of `frame` wouldn't be a bad idea as well).
>> 
>> It seems like PPC is not modifying the stack in this case (?):
>> 
>> 
>>     Register R19_member = R19_method;  // MemberName ptr; incoming method ptr is dead now
>>     __ ld(R19_member, RegisterOrConstant((intptr_t)8), R15_argbase);
>>     __ addi(R15_argbase, R15_argbase, Interpreter::stackElementSize);
>>     generate_method_handle_dispatch(_masm, iid, tmp_recv, R19_member, not_for_compiler_entry);
>
> This is an interesting insight, I'm going to test your fix idea tomorrow.

> I think your conclusion is correct wrt `unextended_sp < sp` in that case. For certain MH linker calls, an additional `MemberName` 'appendix' is passed as the last argument. The MH adapter/trampoline stub pops the appendix argument from the stack for an interpreted caller, and uses it to find out the actual callee. But that means that, the sp saved into `r13` will be one slot too 'large' (small? accounting for one too many arguments). In other words, the MethodHandle adapter for interpreted callers 'consumes' the appendix argument, but doesn't adjust `r13`. I think this could be done though, i.e. just add:
> 
> ```
>  __ addptr(r13, Interpreter::stackElementSize);   // adjust unexteded_sp for callee, for proper stack walking
> ```

I don't think you can do that. Modifying the unextended_sp would break accesses to compiled frames (gc, locals). The original unextended_sp is also needed to undo the c2i extension.

> In the linked code in `MethodHandles::generate_method_handle_interpreter_entry` to make this work.
> 
> (note that we can not just leave the appendix on the stack, since the callee doesn't expect it, so we would break argument oop GC if we left it there)
> 
> If that works, I think doing that would be preferable to adjusting `safe_for_sender`. That seems like it would uphold the `sp <= unextended_sp` invariant as well (maybe an assert to that effect in the constructor of `frame` wouldn't be a bad idea as well).
> 
> It seems like PPC is not modifying the stack in this case (?):
> 
> ```
>     Register R19_member = R19_method;  // MemberName ptr; incoming method ptr is dead now
>     __ ld(R19_member, RegisterOrConstant((intptr_t)8), R15_argbase);
>     __ addi(R15_argbase, R15_argbase, Interpreter::stackElementSize);
>     generate_method_handle_dispatch(_masm, iid, tmp_recv, R19_member, not_for_compiler_entry);
> ```

Only the expression stack pointer (R15) is modified but not the sp (R1).

unextended_sp < sp is possible on PPC because the expression stack is allocated with its maximum size and it's trimmed to the used part when making a call. The sender sp is the original sp.

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

PR: https://git.openjdk.org/jdk/pull/12535

From jvernee at openjdk.org  Wed Feb 15 21:15:03 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 15 Feb 2023 21:15:03 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <y8hTn1ytvssUM96lapnB3PWX-tSaWduWQ51r314p4mw=.a72f2fd8-fbe5-4047-bb14-1a5ca5d80f7f@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
 <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
 <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>
 <4kKR1KP5iJ7G1_lvNKt4jOgRcCIyzDvlLDfO4rtxm2w=.c6fab761-d1ed-405b-b3b5-001a8e19f5db@github.com>
 <az34yLx_KXPTfsMkisg1iz29rHRSON_cRDAUiFa3YCI=.595c997f-444c-4e17-aa03-ff81b6406e71@github.com>
 <N0UvyYW8APmGD_RLtPCAqzpAyFUr11Nb7xn6d0wZd9E=.48a0fa88-8d79-4a0e-81eb-62a11f0d2e6f@github.com>
 <3T7nJ7BvnPjezFb-EzwCNkjq-zRjjsK-LrZTdRgZmzY=.c9ad8912-fbab-4b96-a9c1-9fe104cc904d@github.com>
 <Dit5d8mZV36XF32tzyZrbiuYM4M5xKXyYsi
 I2LR5F7A=.edcc8f71-75bd-4c4d-a062-7ac56f71b643@github.com>
 <T5MrQlsBXNe4YW3SJYkohSeatamAgSsfcOpwCcApkRI=.f14c783f-5ecb-4456-8c01-6a1cd961e791@github.com>
 <f_9hdtzQUxypVHl53oAzKTPBLHiPobmsVeZvfEoPFzE=.9a6e3ab7-32b6-4c66-8498-08d19f04757e@github.com>
 <y8hTn1ytvssUM96lapnB3PWX-tSaWduWQ51r314p4mw=.a72f2fd8-fbe5-4047-bb14-1a5ca5d80f7f@github.com>
Message-ID: <YQyWI6gXjvXn-F6ueluwtkMITq1bHcw2zXq7DCbHNmo=.bab16ae4-e866-4af1-9710-8460e60adfb2@github.com>

On Wed, 15 Feb 2023 21:05:07 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> I don't think you can do that. Modifying the unextended_sp would break accesses to compiled frames (gc, locals).

This is for interpreter entries, so the caller is definitely interpreted. If the callee is compiled, it shouldn't care about the contents of `r13` right? And if the callee is interpreted, it will get the correct `r13`.

>  The original unextended_sp is also needed to undo the c2i extension.

Can you explain this? We shouldn't have a c2i adapters in this case. since the caller is interpreted.

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

PR: https://git.openjdk.org/jdk/pull/12535

From rkennke at openjdk.org  Wed Feb 15 21:15:54 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 15 Feb 2023 21:15:54 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v12]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <dVjCB5qGZkEvwKrVN8841Gi3Ngz0t6ATPwC61ze0Ng4=.5dc3192a-d6a9-4751-aaa7-856509e16717@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock.
> 
> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking.
> 
> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread.
> 
> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it.
> 
> This change enables to simplify (and speed-up!) a lot of code:
> 
> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header.
> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Renaissance
> 
> 
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

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

  Fix merge error (move done label into correct places)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/8bdeda39..ed611b0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=10-11

  Stats: 12 lines in 2 files changed: 6 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From rrich at openjdk.org  Wed Feb 15 21:25:27 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 15 Feb 2023 21:25:27 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <YQyWI6gXjvXn-F6ueluwtkMITq1bHcw2zXq7DCbHNmo=.bab16ae4-e866-4af1-9710-8460e60adfb2@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
 <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
 <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>
 <4kKR1KP5iJ7G1_lvNKt4jOgRcCIyzDvlLDfO4rtxm2w=.c6fab761-d1ed-405b-b3b5-001a8e19f5db@github.com>
 <az34yLx_KXPTfsMkisg1iz29rHRSON_cRDAUiFa3YCI=.595c997f-444c-4e17-aa03-ff81b6406e71@github.com>
 <N0UvyYW8APmGD_RLtPCAqzpAyFUr11Nb7xn6d0wZd9E=.48a0fa88-8d79-4a0e-81eb-62a11f0d2e6f@github.com>
 <3T7nJ7BvnPjezFb-EzwCNkjq-zRjjsK-LrZTdRgZmzY=.c9ad8912-fbab-4b96-a9c1-9fe104cc904d@github.com>
 <Dit5d8mZV36XF32tzyZrbiuYM4M5xKXyYsi
 I2LR5F7A=.edcc8f71-75bd-4c4d-a062-7ac56f71b643@github.com>
 <T5MrQlsBXNe4YW3SJYkohSeatamAgSsfcOpwCcApkRI=.f14c783f-5ecb-4456-8c01-6a1cd961e791@github.com>
 <f_9hdtzQUxypVHl53oAzKTPBLHiPobmsVeZvfEoPFzE=.9a6e3ab7-32b6-4c66-8498-08d19f04757e@github.com>
 <y8hTn1ytvssUM96lapnB3PWX-tSaWduWQ51r314p4mw=.a72f2fd8-fbe5-4047-bb14-1a5ca5d80f7f@github.com>
 <YQyWI6gXjvXn-F6ueluwtkMITq1bHcw2zXq7DCbHNmo=.bab16ae4-e866-4af1-9710-8460e60adfb2@github.com>
Message-ID: <Y7GZDVpsOy9MrmAXFKyFOv8NY2-OTAthXM6tUzOeOso=.12f21f2d-5c4a-4345-aad3-f664e02f4b17@github.com>

On Wed, 15 Feb 2023 21:12:19 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>>> I think your conclusion is correct wrt `unextended_sp < sp` in that case. For certain MH linker calls, an additional `MemberName` 'appendix' is passed as the last argument. The MH adapter/trampoline stub pops the appendix argument from the stack for an interpreted caller, and uses it to find out the actual callee. But that means that, the sp saved into `r13` will be one slot too 'large' (small? accounting for one too many arguments). In other words, the MethodHandle adapter for interpreted callers 'consumes' the appendix argument, but doesn't adjust `r13`. I think this could be done though, i.e. just add:
>>> 
>>> ```
>>>  __ addptr(r13, Interpreter::stackElementSize);   // adjust unexteded_sp for callee, for proper stack walking
>>> ```
>> 
>> I don't think you can do that. Modifying the unextended_sp would break accesses to compiled frames (gc, locals). The original unextended_sp is also needed to undo the c2i extension.
>> 
>>> In the linked code in `MethodHandles::generate_method_handle_interpreter_entry` to make this work.
>>> 
>>> (note that we can not just leave the appendix on the stack, since the callee doesn't expect it, so we would break argument oop GC if we left it there)
>>> 
>>> If that works, I think doing that would be preferable to adjusting `safe_for_sender`. That seems like it would uphold the `sp <= unextended_sp` invariant as well (maybe an assert to that effect in the constructor of `frame` wouldn't be a bad idea as well).
>>> 
>>> It seems like PPC is not modifying the stack in this case (?):
>>> 
>>> ```
>>>     Register R19_member = R19_method;  // MemberName ptr; incoming method ptr is dead now
>>>     __ ld(R19_member, RegisterOrConstant((intptr_t)8), R15_argbase);
>>>     __ addi(R15_argbase, R15_argbase, Interpreter::stackElementSize);
>>>     generate_method_handle_dispatch(_masm, iid, tmp_recv, R19_member, not_for_compiler_entry);
>>> ```
>> 
>> Only the expression stack pointer (R15) is modified but not the sp (R1).
>> 
>> unextended_sp < sp is possible on PPC because the expression stack is allocated with its maximum size and it's trimmed to the used part when making a call. The sender sp is the original sp.
>
>> I don't think you can do that. Modifying the unextended_sp would break accesses to compiled frames (gc, locals).
> 
> This is for interpreter entries, so the caller is definitely interpreted. If the callee is compiled, it shouldn't care about the contents of `r13` right? And if the callee is interpreted, it will get the correct `r13`.
> 
>>  The original unextended_sp is also needed to undo the c2i extension.
> 
> Can you explain this? We shouldn't have a c2i adapters in this case. since the caller is interpreted. ~If the callee is compiled, we will go through a c2i adapter for that, but in that case the adapter overwrites `r13` again.~

It's to long since I was working on low level MH stuff.
If an ordinary interpreter entry is used for a call this means the callee will be interpreted. The caller is not necessarily interpreted. It can be compiled.
Is this different here?

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

PR: https://git.openjdk.org/jdk/pull/12535

From jvernee at openjdk.org  Wed Feb 15 21:43:17 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 15 Feb 2023 21:43:17 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <Y7GZDVpsOy9MrmAXFKyFOv8NY2-OTAthXM6tUzOeOso=.12f21f2d-5c4a-4345-aad3-f664e02f4b17@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
 <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
 <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>
 <4kKR1KP5iJ7G1_lvNKt4jOgRcCIyzDvlLDfO4rtxm2w=.c6fab761-d1ed-405b-b3b5-001a8e19f5db@github.com>
 <az34yLx_KXPTfsMkisg1iz29rHRSON_cRDAUiFa3YCI=.595c997f-444c-4e17-aa03-ff81b6406e71@github.com>
 <N0UvyYW8APmGD_RLtPCAqzpAyFUr11Nb7xn6d0wZd9E=.48a0fa88-8d79-4a0e-81eb-62a11f0d2e6f@github.com>
 <3T7nJ7BvnPjezFb-EzwCNkjq-zRjjsK-LrZTdRgZmzY=.c9ad8912-fbab-4b96-a9c1-9fe104cc904d@github.com>
 <Dit5d8mZV36XF32tzyZrbiuYM4M5xKXyYsi
 I2LR5F7A=.edcc8f71-75bd-4c4d-a062-7ac56f71b643@github.com>
 <T5MrQlsBXNe4YW3SJYkohSeatamAgSsfcOpwCcApkRI=.f14c783f-5ecb-4456-8c01-6a1cd961e791@github.com>
 <f_9hdtzQUxypVHl53oAzKTPBLHiPobmsVeZvfEoPFzE=.9a6e3ab7-32b6-4c66-8498-08d19f04757e@github.com>
 <y8hTn1ytvssUM96lapnB3PWX-tSaWduWQ51r314p4mw=.a72f2fd8-fbe5-4047-bb14-1a5ca5d80f7f@github.com>
 <YQyWI6gXjvXn-F6ueluwtkMITq1bHcw2zXq7DCbHNmo=.bab16ae4-e866-4af1-9710-8460e60adfb2@github.com>
 <Y7GZDVpsOy9MrmAXFKyFOv8NY2-OTAthXM6tUzOeOso=.12f21f2d-5c4a-4345-aad3-f664e02f4b17@github.com>
Message-ID: <W1eFOcDW_inlLwcpn88obFJIhFuYdD69tXGZDsaYYl8=.055adff8-3096-4010-ba14-17d865673e23@github.com>

On Wed, 15 Feb 2023 21:22:48 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> If an ordinary interpreter entry is used for a call this means the callee will be interpreted

Maybe we're not talking about the same thing?

`Method` has a `from_interpreted_entry` and a `from_compiled_entry`, but which one is used depends on the caller, and which calling convention they are using. The callee can be either interpreted or compiled (and if there's a mismatch, we go through an adapter). The entry generated by `generate_method_handle_interpreter_entry` is essentially the `from_interpreted_entry`, AFAIU.

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

PR: https://git.openjdk.org/jdk/pull/12535

From rrich at openjdk.org  Wed Feb 15 23:23:10 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 15 Feb 2023 23:23:10 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <W1eFOcDW_inlLwcpn88obFJIhFuYdD69tXGZDsaYYl8=.055adff8-3096-4010-ba14-17d865673e23@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
 <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
 <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>
 <4kKR1KP5iJ7G1_lvNKt4jOgRcCIyzDvlLDfO4rtxm2w=.c6fab761-d1ed-405b-b3b5-001a8e19f5db@github.com>
 <az34yLx_KXPTfsMkisg1iz29rHRSON_cRDAUiFa3YCI=.595c997f-444c-4e17-aa03-ff81b6406e71@github.com>
 <N0UvyYW8APmGD_RLtPCAqzpAyFUr11Nb7xn6d0wZd9E=.48a0fa88-8d79-4a0e-81eb-62a11f0d2e6f@github.com>
 <3T7nJ7BvnPjezFb-EzwCNkjq-zRjjsK-LrZTdRgZmzY=.c9ad8912-fbab-4b96-a9c1-9fe104cc904d@github.com>
 <Dit5d8mZV36XF32tzyZrbiuYM4M5xKXyYsi
 I2LR5F7A=.edcc8f71-75bd-4c4d-a062-7ac56f71b643@github.com>
 <T5MrQlsBXNe4YW3SJYkohSeatamAgSsfcOpwCcApkRI=.f14c783f-5ecb-4456-8c01-6a1cd961e791@github.com>
 <f_9hdtzQUxypVHl53oAzKTPBLHiPobmsVeZvfEoPFzE=.9a6e3ab7-32b6-4c66-8498-08d19f04757e@github.com>
 <y8hTn1ytvssUM96lapnB3PWX-tSaWduWQ51r314p4mw=.a72f2fd8-fbe5-4047-bb14-1a5ca5d80f7f@github.com>
 <YQyWI6gXjvXn-F6ueluwtkMITq1bHcw2zXq7DCbHNmo=.bab16ae4-e866-4af1-9710-8460e60adfb2@github.com>
 <Y7GZDVpsOy9MrmAXFKyFOv8NY2-OTAthXM6tUzOeOso=.12f21f2d-5c4a-4345-aad3-f664e02f4b17@github.com>
 <W1eFOcDW_inlLwcpn88obFJIhFuYdD69tXGZDsaYYl8=.055adff8-3096-4010-ba14-17d865673e23@github.com>
Message-ID: <RaVblIRnK57MYiz3rGhS9raVxF51EVc5aIeOwKrUMpM=.94181f7e-4cb5-4c55-896a-2f866ee03cdd@github.com>

On Wed, 15 Feb 2023 21:39:52 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> The entry generated by generate_method_handle_interpreter_entry is essentially the from_interpreted_entry, AFAIU.

But it is also stored in `Method::_i2i_entry` which is [used by c2i adapters](https://github.com/openjdk/jdk/blob/3ba156082b73c4a8e9d890a57a42fb68df2bf98f/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L748-L750).

(Maybe too) long version:

The interpreter has entries depending on the `MethodKind`. See `AbstractInterpreter::entry_for_kind()`. The entries are stored in `AbstractInterpreter::_entry_table`. In `MethodHandlesAdapterGenerator::generate()` the interpreter entries for method handle intrinsics MethodKinds are generated using the generator `MethodHandles::generate_method_handle_interpreter_entry()`.

In `Method::link_method()` the entry points are set depending on the `MethodKind`. The interpreter entry (see above) for the method's `MethodKind` is looked up and stored in `Method::_i2i_entry` which is also [used by c2i adapters](https://github.com/openjdk/jdk/blob/3ba156082b73c4a8e9d890a57a42fb68df2bf98f/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L748-L750).

So to me it looks as if the entry generated by `generate_method_handle_interpreter_entry()` can be reached coming from a compiled caller. The generator for ordinary methods is `TemplateInterpreterGenerator::generate_normal_entry()`. The entries it generates are surely reached by compiled callers. I might be missing something in the case of MH intrinsics but right now it looks to me as if the caller can be compiled too.

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

PR: https://git.openjdk.org/jdk/pull/12535

From jvernee at openjdk.org  Thu Feb 16 00:44:01 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 16 Feb 2023 00:44:01 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <RaVblIRnK57MYiz3rGhS9raVxF51EVc5aIeOwKrUMpM=.94181f7e-4cb5-4c55-896a-2f866ee03cdd@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
 <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
 <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>
 <4kKR1KP5iJ7G1_lvNKt4jOgRcCIyzDvlLDfO4rtxm2w=.c6fab761-d1ed-405b-b3b5-001a8e19f5db@github.com>
 <az34yLx_KXPTfsMkisg1iz29rHRSON_cRDAUiFa3YCI=.595c997f-444c-4e17-aa03-ff81b6406e71@github.com>
 <N0UvyYW8APmGD_RLtPCAqzpAyFUr11Nb7xn6d0wZd9E=.48a0fa88-8d79-4a0e-81eb-62a11f0d2e6f@github.com>
 <3T7nJ7BvnPjezFb-EzwCNkjq-zRjjsK-LrZTdRgZmzY=.c9ad8912-fbab-4b96-a9c1-9fe104cc904d@github.com>
 <Dit5d8mZV36XF32tzyZrbiuYM4M5xKXyYsi
 I2LR5F7A=.edcc8f71-75bd-4c4d-a062-7ac56f71b643@github.com>
 <T5MrQlsBXNe4YW3SJYkohSeatamAgSsfcOpwCcApkRI=.f14c783f-5ecb-4456-8c01-6a1cd961e791@github.com>
 <f_9hdtzQUxypVHl53oAzKTPBLHiPobmsVeZvfEoPFzE=.9a6e3ab7-32b6-4c66-8498-08d19f04757e@github.com>
 <y8hTn1ytvssUM96lapnB3PWX-tSaWduWQ51r314p4mw=.a72f2fd8-fbe5-4047-bb14-1a5ca5d80f7f@github.com>
 <YQyWI6gXjvXn-F6ueluwtkMITq1bHcw2zXq7DCbHNmo=.bab16ae4-e866-4af1-9710-8460e60adfb2@github.com>
 <Y7GZDVpsOy9MrmAXFKyFOv8NY2-OTAthXM6tUzOeOso=.12f21f2d-5c4a-4345-aad3-f664e02f4b17@github.com>
 <W1eFOcDW_inlLwcpn88obFJIhFuYdD69tXGZDsaYYl8=.055adff8-3096-4010-ba14-17d865673e23@github.com>
 <RaVblIRnK57MYiz3rGhS9raVxF51EVc5aIeOwKrUMpM=.94181f7e-4cb5-4c55-896a-2f866ee03cdd@github.com>
Message-ID: <bUw-tcnXehysQcGF2v5gJQtqGrpjgrWs1GrPorYBTks=.ab3f744e-65d3-4609-9d18-0b1f5d67dfc5@github.com>

On Wed, 15 Feb 2023 23:20:00 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> (Maybe too) long version:

Not at all :) I don't know much about the interpreter, so this is pretty helpful.

Ok. I think the main point is that a MH linker method doesn't have a c2i adapter, it instead has separate versions for interpreted and compiled callers altogether (except `linkToNative` which doesn't have an interpreter version atm)

Longer version:

I think there are 4 theoretical cases (are there more?):
1. interpreted -> MH interpreter entry -> interpreted (the case we want to fix, I think)
2.  interpreted -> MH interpreter entry -> i2c -> compiled
3. compiled -> c2i -> MH interpreter entry -> interpreted
4. compiled -> c2i -> MH interpreter entry -> i2c -> compiled

So... my understanding is that a c2i adapter is used when a callee is interpreted, so its `from_compiled_entry` points to the c2i adapter. A compiled caller calls the `from_compiled_entry`, so it ends up going through the `c2i` adapter of an interpreted callee. However, for method handle linkers, the `from_compiled_entry` never points to a c2i adapter, but to the MH linker compiler entry generated in `gen_special_dispatch` in e.g `sharedRuntime_x86_64`. So, in other words, the 3. and 4. scenarios above are not possible, AFAICS. An MH linker's interpreted/compiled entries simply replace the regular `i2c` and `c2i` adapters for a MH linker method. Though, the actual target method can be either compiled or interpreted, so we can go into either a `c2i` adapter from a MH linker  compiler entry, or a `i2c` adapter from a MH linker interpreter entry (which is scenario 2.).

For scenario 1.: caller sets `r13` before jumping to callee (MH linker), we end up in the MH adapter, pop the last argument, and adjust `r13` for the actual callee. The MH interpreter entry uses `from_interpreted_entry` of the target method, so we don't go through any adapter.

For scenario 2.: mostly the same as 1., but we go through an `i2c` adapter, and the compiled callee doesn't care about what's in `r13` any ways. (there's a comment in the ic2 adapter code about preserving `r13` for the case that we might go back into a c2i adapter if we lose a race where the callee is made non-entrant, but `r13` is also used as a scratch register later in the i2c code, and the c2i code overwrites `r13` any ways. So, I think that is an outdated comment...)

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

PR: https://git.openjdk.org/jdk/pull/12535

From dholmes at openjdk.org  Thu Feb 16 01:29:42 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Feb 2023 01:29:42 GMT
Subject: RFR: JDK-8302455: VM.classloader_stats memory size values are
 wrong [v3]
In-Reply-To: <R-bIZ_fWCJ8occDbFp5bkqL34JmfkmC3jtRR_6YO4zE=.9f2cb45a-177c-496c-977a-3d77c3615aba@github.com>
References: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>
 <R-bIZ_fWCJ8occDbFp5bkqL34JmfkmC3jtRR_6YO4zE=.9f2cb45a-177c-496c-977a-3d77c3615aba@github.com>
Message-ID: <emWRjeAD50f8k6MJmvXAUmGErpC8wiOUQfRiqdkfm0w=.968285ec-7465-4906-a126-a4cc34d1e416@github.com>

On Wed, 15 Feb 2023 10:50:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> VM.classloader_stats shows metaspace consumption in words, but should show bytes. 
>> 
>> Patch fixes that, and adjusts the associated jtreg test to catch regressions like this.
>> 
>> I manually tested the test with the unpatched hotspot to see if the regression shows up, it does.
>> 
>> Tested the patch on x64 (fastdebug, release) and x86.
>> 
>> Note: "calculate_jfr_stats" is misnamed, actually only ever used by this dcmd, not by jfr. I will clear this up in a separate RFE.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix -UseCCP and add regression test

Looks good. The `usage_numbers` changes were a bit more involved then I had expected but they seem fine.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12556

From stuefe at openjdk.org  Thu Feb 16 06:59:36 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Feb 2023 06:59:36 GMT
Subject: RFR: JDK-8302455: VM.classloader_stats memory size values are
 wrong [v3]
In-Reply-To: <R-bIZ_fWCJ8occDbFp5bkqL34JmfkmC3jtRR_6YO4zE=.9f2cb45a-177c-496c-977a-3d77c3615aba@github.com>
References: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>
 <R-bIZ_fWCJ8occDbFp5bkqL34JmfkmC3jtRR_6YO4zE=.9f2cb45a-177c-496c-977a-3d77c3615aba@github.com>
Message-ID: <0Vu9SlsaWfwWl7PvzxfiUZlw2peF-5h76mbyE_gdavE=.a150cab8-9e85-47ab-be4f-7cc0aef72780@github.com>

On Wed, 15 Feb 2023 10:50:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> VM.classloader_stats shows metaspace consumption in words, but should show bytes. 
>> 
>> Patch fixes that, and adjusts the associated jtreg test to catch regressions like this.
>> 
>> I manually tested the test with the unpatched hotspot to see if the regression shows up, it does.
>> 
>> Tested the patch on x64 (fastdebug, release) and x86.
>> 
>> Note: "calculate_jfr_stats" is misnamed, actually only ever used by this dcmd, not by jfr. I will clear this up in a separate RFE.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix -UseCCP and add regression test

Thanks David!

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

PR: https://git.openjdk.org/jdk/pull/12556

From stuefe at openjdk.org  Thu Feb 16 06:59:38 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Feb 2023 06:59:38 GMT
Subject: Integrated: JDK-8302455: VM.classloader_stats memory size values are
 wrong
In-Reply-To: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>
References: <kf-h6smMIUgFRs1SSAxPFOkBia2FmBFZfDOBE2JHijA=.4c28a969-9f97-424b-a648-3ba3e7f09418@github.com>
Message-ID: <VacCpcepijEh_cTJSXuvYGSdGvs2cYn8444KqwbAotQ=.e075d032-6c2f-47cb-b0d0-63ecb922503f@github.com>

On Tue, 14 Feb 2023 13:40:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> VM.classloader_stats shows metaspace consumption in words, but should show bytes. 
> 
> Patch fixes that, and adjusts the associated jtreg test to catch regressions like this.
> 
> I manually tested the test with the unpatched hotspot to see if the regression shows up, it does.
> 
> Tested the patch on x64 (fastdebug, release) and x86.
> 
> Note: "calculate_jfr_stats" is misnamed, actually only ever used by this dcmd, not by jfr. I will clear this up in a separate RFE.

This pull request has now been integrated.

Changeset: 6e2d3c6c
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6e2d3c6c45ded862d818e30dd03d023980bf0ec2
Stats:     63 lines in 4 files changed: 37 ins; 2 del; 24 mod

8302455: VM.classloader_stats memory size values are wrong

Reviewed-by: coleenp, dholmes

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

PR: https://git.openjdk.org/jdk/pull/12556

From sspitsyn at openjdk.org  Thu Feb 16 07:54:28 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Feb 2023 07:54:28 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v3]
In-Reply-To: <R4cj_O8kYS8lbSnINj6Z8UXHZVI2aVwF1z24B0oAUgA=.6cdff6f7-cee4-4ecc-a104-7ac95781f12e@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <PXNLfQ0zN-PVmukV4zfJ1Vx1YoQTQ2sH5SaztW2pBpQ=.0bc3e63b-158a-4e9e-a591-71c3eec40bac@github.com>
 <Au35V60A-SAAkmrLAoi6MSqdtgh6E1rphGgJzyVxwU0=.c740d207-d820-476a-9436-40d0ac751207@github.com>
 <R4cj_O8kYS8lbSnINj6Z8UXHZVI2aVwF1z24B0oAUgA=.6cdff6f7-cee4-4ecc-a104-7ac95781f12e@github.com>
Message-ID: <SkRp2Wyh5PCsEHLBY11NOomx055Rw96U_GRcayV1jM8=.97d01412-d14b-4db3-9b05-3d0b6053a612@github.com>

On Wed, 15 Feb 2023 20:53:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnv.cpp line 1045:
>> 
>>> 1043:             JvmtiEnvBase::is_vthread_alive(vt_oop) &&
>>> 1044:             !JvmtiVTSuspender::is_vthread_suspended(vt_oop)) ||
>>> 1045:             java_thread->is_bound_vthread()) &&
>> 
>> This condition does not look correct.
>> I'd expect it to be:
>>  ```
>>          ((java_lang_VirtualThread::is_instance(vt_oop) &&
>>            JvmtiEnvBase::is_vthread_alive(vt_oop)) ||
>>           java_thread->is_bound_vthread()) &&
>>           !JvmtiVTSuspender::is_vthread_suspended(vt_oop) &&
>> 
>> It is important to check for `!JvmtiVTSuspender::is_vthread_suspended(vt_oop)` for `bound_vthread` as well.
>> The same issue is in the `JvmtiEnv::ResumeAllVirtualThreads`.
>
> The thing is that JvmtiVTSuspender::is_vthread_suspended() checks _suspended_list/not_suspended_list which are not set with single suspend/resume functions(SuspendThread/SuspendThreadList/ResumeThread/ResumeThreadList) on a BoundVirtualThread. For single suspend/resume on a BoundVirtualThread we go through the same path as for platform threads. In any case, the suspend_thread() call will just return JVMTI_ERROR_THREAD_SUSPENDED if a thread is already suspended, but if you want to avoid the call altogether I can add the equivalent check which would be !java_thread->is_suspended().
> 
> Now, I realized that although single-suspends will not change _suspended_list/not_suspended_list for a BoundVirtualThread, SuspendAllVirtualThreads/ResumeAllVirtualThreads can if a BoundVirtualThread is part of the exception list. In the SuspendAllVirtualThreads case for example, when restoring the resume state, the call to JvmtiVTSuspender::is_vthread_suspended() would return true (we are already in SR_all mode and the BoundVirtualThread will not be in _not_suspended_list), meaning the BoundVirtualThread will be added to the not_suspended_list. 
> So we have to decide if we want to keep track of BoundVirtualThreads on these lists or not. Given that I see JvmtiVTSuspender::is_vthread_suspended() is always called on a VirtualThread the easiest thing would be to not track them, and just add a check in SuspendAllVirtualThreads/ResumeAllVirtualThreads where the elist is populated so only VirtualThreads are added. What do you think?

The `SuspendAllVirtualThreads` spec has this statement:

  Suspend all virtual threads except those in the exception list.
  Virtual threads that are currently suspended do not change state.

And the `ResumeAllVirtualThreads` spec has this statement:

  Resume all virtual threads except those in the exception list.
  Virtual threads that are currently resumed do not change state

So that, `SuspendAllVirtualThreads` should do nothing with the already suspended virtual threads.
And `ResumeAllVirtualThreads` should do nothing with the already resumed virtual threads.
It does not depend on the except_list.
It is better to avoid suspending already suspended threads and resuming already resumed.
So, at least a check for `!java_thread->is_suspended()` is needed.
Did you observe any JVMTI or JDI suspend/resume tests failing?

> Now, I realized that although single-suspends will not change _suspended_list/not_suspended_list for a BoundVirtualThread, SuspendAllVirtualThreads/ResumeAllVirtualThreads can if a BoundVirtualThread is part of the exception list. In the SuspendAllVirtualThreads case for example, when restoring the resume state, the call to JvmtiVTSuspender::is_vthread_suspended() would return true (we are already in SR_all mode and the BoundVirtualThread will not be in _not_suspended_list), meaning the BoundVirtualThread will be added to the not_suspended_list.
> So we have to decide if we want to keep track of BoundVirtualThreads on these lists or not. Given that I see JvmtiVTSuspender::is_vthread_suspended() is always called on a VirtualThread the easiest thing would be to not track them, and just add a check in SuspendAllVirtualThreads/ResumeAllVirtualThreads where the elist is populated so only VirtualThreads are added. What do you think?

I feel that following the VirtualThread's implementation code path would be more consistent, unified and free of surprises. But I also see that following the platform threads code path looks pretty simple. So, it can be okay.
So, for this approach, I think, the code fragments which collect and restore resumed/suspended state for virtual threads need to be bypassed by the BoundVirtualThreads implementation. Please, let me know if it does not work by any reason. We also will have to rely on the testing here.

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

PR: https://git.openjdk.org/jdk/pull/12512

From sspitsyn at openjdk.org  Thu Feb 16 08:22:28 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Feb 2023 08:22:28 GMT
Subject: RFR: 8299234: JMX Repository.query performance [v5]
In-Reply-To: <YH-y2lwy0IU4s9Ri6vuNwwgpZpJzFIQW_ttuE8KkFFs=.ccabc1f9-d27d-469a-847b-69c4e882d7e6@github.com>
References: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
 <YH-y2lwy0IU4s9Ri6vuNwwgpZpJzFIQW_ttuE8KkFFs=.ccabc1f9-d27d-469a-847b-69c4e882d7e6@github.com>
Message-ID: <jSmgemoFNv5fyEkTEnW4q9MbjroLdr4dknBgQ3mNUJA=.20c98680-1765-45fe-a141-0d3d244c3bfa@github.com>

On Thu, 2 Feb 2023 13:42:51 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please find a patch to improve JMX Repository.query performance
>> 
>> Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles:
>> Before:
>> 
>> $ java test 1000000 1000000
>> Test PASSED in 8943169791 ns.
>> GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118
>> 
>> 
>> After:
>> 
>> $ java test 1000000 1000000
>> Test PASSED in 4808213917 ns.
>> GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53
>> 
>> Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation.
>> 
>> All javax/management jtreg tests passed successfully.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize ObjectName.matchDomains

Hi Alexey,
I hope, Kevin will have a chance to review your PR. I'll check with him.

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

PR: https://git.openjdk.org/jdk/pull/11758

From abakhtin at openjdk.org  Thu Feb 16 08:22:28 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 16 Feb 2023 08:22:28 GMT
Subject: RFR: 8299234: JMX Repository.query performance [v5]
In-Reply-To: <jSmgemoFNv5fyEkTEnW4q9MbjroLdr4dknBgQ3mNUJA=.20c98680-1765-45fe-a141-0d3d244c3bfa@github.com>
References: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
 <YH-y2lwy0IU4s9Ri6vuNwwgpZpJzFIQW_ttuE8KkFFs=.ccabc1f9-d27d-469a-847b-69c4e882d7e6@github.com>
 <jSmgemoFNv5fyEkTEnW4q9MbjroLdr4dknBgQ3mNUJA=.20c98680-1765-45fe-a141-0d3d244c3bfa@github.com>
Message-ID: <6avdQlbEjK8O1YhaUKBv8iJc024JTTayGI3_6lO6mYM=.3c76d215-f43e-4122-9737-302ba670f6a6@github.com>

On Thu, 16 Feb 2023 08:16:40 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Hi Alexey, I hope, Kevin will have a chance to review your PR. I'll check with him.

Thank you!

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

PR: https://git.openjdk.org/jdk/pull/11758

From rrich at openjdk.org  Thu Feb 16 11:03:28 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 16 Feb 2023 11:03:28 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <bUw-tcnXehysQcGF2v5gJQtqGrpjgrWs1GrPorYBTks=.ab3f744e-65d3-4609-9d18-0b1f5d67dfc5@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
 <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
 <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>
 <4kKR1KP5iJ7G1_lvNKt4jOgRcCIyzDvlLDfO4rtxm2w=.c6fab761-d1ed-405b-b3b5-001a8e19f5db@github.com>
 <az34yLx_KXPTfsMkisg1iz29rHRSON_cRDAUiFa3YCI=.595c997f-444c-4e17-aa03-ff81b6406e71@github.com>
 <N0UvyYW8APmGD_RLtPCAqzpAyFUr11Nb7xn6d0wZd9E=.48a0fa88-8d79-4a0e-81eb-62a11f0d2e6f@github.com>
 <3T7nJ7BvnPjezFb-EzwCNkjq-zRjjsK-LrZTdRgZmzY=.c9ad8912-fbab-4b96-a9c1-9fe104cc904d@github.com>
 <Dit5d8mZV36XF32tzyZrbiuYM4M5xKXyYsi
 I2LR5F7A=.edcc8f71-75bd-4c4d-a062-7ac56f71b643@github.com>
 <T5MrQlsBXNe4YW3SJYkohSeatamAgSsfcOpwCcApkRI=.f14c783f-5ecb-4456-8c01-6a1cd961e791@github.com>
 <f_9hdtzQUxypVHl53oAzKTPBLHiPobmsVeZvfEoPFzE=.9a6e3ab7-32b6-4c66-8498-08d19f04757e@github.com>
 <y8hTn1ytvssUM96lapnB3PWX-tSaWduWQ51r314p4mw=.a72f2fd8-fbe5-4047-bb14-1a5ca5d80f7f@github.com>
 <YQyWI6gXjvXn-F6ueluwtkMITq1bHcw2zXq7DCbHNmo=.bab16ae4-e866-4af1-9710-8460e60adfb2@github.com>
 <Y7GZDVpsOy9MrmAXFKyFOv8NY2-OTAthXM6tUzOeOso=.12f21f2d-5c4a-4345-aad3-f664e02f4b17@github.com>
 <W1eFOcDW_inlLwcpn88obFJIhFuYdD69tXGZDsaYYl8=.055adff8-3096-4010-ba14-17d865673e23@github.com>
 <RaVblIRnK57MYiz3rGhS9raVxF51EVc5aIeOwKrUMpM=.94181f7e-4cb5-4c55-896a-2f866ee03cdd@github.com>
 <bUw-tcnXehysQcGF2v5gJQtqGrpjgrWs1GrPorYBTks=.ab3f744e-65d3-4609-9d18-0b1f5d67dfc5@github.com>
Message-ID: <aI3cv_keI-VBfkwG8OWx5AH1h1JemvhTkz24hSIGVYo=.3707f7bc-ca6e-4b4d-bc18-0357839aa30d@github.com>

On Thu, 16 Feb 2023 00:36:03 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> So... my understanding is that a c2i adapter is used when a callee is
> interpreted, so its `from_compiled_entry` points to the c2i adapter. A
> compiled caller calls the `from_compiled_entry`, so it ends up going through
> the `c2i` adapter of an interpreted callee. However, for method handle
> linkers, the `from_compiled_entry` never points to a c2i adapter, but to the
> MH linker compiler entry generated in `gen_special_dispatch` in e.g
> `sharedRuntime_x86_64`. So, in other words, the 3. and 4. scenarios above are
> not possible, AFAICS.

I see. Thanks! That's what I've been missing. It's implemented in `SystemDictionary::find_method_handle_intrinsic()` I think.

I agree that it will be ok to modify r13 as you suggested. Maybe explaining why we never reach here coming from a c2i adapter: because native wrappers are generated eagerly in `SystemDictionary::find_method_handle_intrinsic()` unless -Xint is given but then the caller cannot be compiled.

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

PR: https://git.openjdk.org/jdk/pull/12535

From rehn at openjdk.org  Thu Feb 16 12:51:24 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 16 Feb 2023 12:51:24 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms
Message-ID: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>

Hi all, please consider.

The original issue was when thread 1 asked to deopt nmethod set X and thread 2 asked for the same or a subset of X.
All method will already be marked, but the actual deoptimizing, not entrant, patching PC on stacks and patching post call nops, was not done yet. Which meant thread 2 could 'pass' thread 1.
Most places did deopt under Compile_lock, thus this is not an issue, but WB and clearCallSiteContext do not.

Since a handshakes may take long before completion and Compile_lock is used for so much more than deopts,
the fix in https://bugs.openjdk.org/browse/JDK-8299074 instead always emitted a handshake even when everything was already marked.

This turnout to be problematic in the startup, for example the number of deopt handshakes in jetty dry run startup went from 5 to 39 handshakes.

This fix first adds a barrier for which you do not pass until the requested deopts have happened and it coalesces the handshakes.
Secondly it moves handshakes part out of the Compile_lock where it is possible.

Which means we fix the performance bug and we reduce the contention on Compile_lock, meaning higher throughput in compiler and things such as class-loading.

It passes t1-t7 with flying colours! t8 still not completed and I'm redoing some testing due to last minute simplifications.

Thanks, Robbin

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

Commit messages:
 - Fixed WS
 - Deopt scopes

Changes: https://git.openjdk.org/jdk/pull/12585/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12585&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300926
  Stats: 380 lines in 24 files changed: 192 ins; 91 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/12585.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12585/head:pull/12585

PR: https://git.openjdk.org/jdk/pull/12585

From stuefe at openjdk.org  Thu Feb 16 13:00:37 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Feb 2023 13:00:37 GMT
Subject: RFR: JDK-8301983: Refactor MEMFLAGS and AllocFailStrategy [v5]
In-Reply-To: <XahRZnW-vie-MLr50q9_HfjQ2Yvvif55W2IYbQUIIP4=.8f4225c1-8479-4515-86e2-27d3766775a9@github.com>
References: <Zax7qGPN54d5tr6cV55-ojZUYzOsn4Fpt5XXKdM3_Qo=.649b4f2a-96f2-494a-bebe-6919abd06086@github.com>
 <60XHlRRmnr8C-BcA_pRbLwIs7P5lqv5cayfc4ifBHeE=.12ed00cf-afc1-410a-b415-4425769be62b@github.com>
 <XahRZnW-vie-MLr50q9_HfjQ2Yvvif55W2IYbQUIIP4=.8f4225c1-8479-4515-86e2-27d3766775a9@github.com>
Message-ID: <Ku0OMAJAwbXZ2Ngrb3ynJ2Q2kfTXWgV4x4uNHtkaWBc=.8c33a271-e131-434b-9056-47f1383fa7fa@github.com>

On Tue, 14 Feb 2023 08:57:38 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> FWIW, I strongly dislike the uppercase MEMFLAGS name. I wouldn't mind this rename at all.

Thinking this through again, I somewhat regret my strong opposition. Reeks too much of resisting change for resisting's sake, and we don't want that.

While I still think the change is much too big, I never have liked MEMFLAGS myself either. In comments and code, it has been named "nmt category" in places, which I like more.

I think simple renaming change MEMFLAGS->xx, with xx being something like "NMTCategory" or "NMTTags" or similar, would be okay. If other refactorings are omitted, such an isolated change could be backported more easily to older releases.

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

PR: https://git.openjdk.org/jdk/pull/12454

From duke at openjdk.org  Thu Feb 16 14:25:15 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Thu, 16 Feb 2023 14:25:15 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v2]
In-Reply-To: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
Message-ID: <n_pH4nVpPaKxt1lDeCQ93MkRAItgJvBZSN8sy4eitrY=.85bde83e-c59f-41a2-844a-a61da45545dc@github.com>

> Fixes the issue by applying a fix that is already implemented in PPC.

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

  Implement addptr suggestion by @JohnVernee and @reinrich

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12535/files
  - new: https://git.openjdk.org/jdk/pull/12535/files/b32cf7c0..e63ab44a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12535&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12535&range=00-01

  Stats: 7 lines in 3 files changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12535.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12535/head:pull/12535

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Thu Feb 16 14:25:18 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Thu, 16 Feb 2023 14:25:18 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v2]
In-Reply-To: <aI3cv_keI-VBfkwG8OWx5AH1h1JemvhTkz24hSIGVYo=.3707f7bc-ca6e-4b4d-bc18-0357839aa30d@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <PvuGREfDM9KjqW-j1mFEhHlz8Pi7ycuLAJ-M-xDJ3P4=.f995420a-44a3-4ac7-9710-3c94baa6b4a0@github.com>
 <2oXvjl1UFJq6x70IUcUgLKUVQgnjLC9U7YsB3XQg7BQ=.d651fdb1-df5c-40bc-9adc-4921045014a0@github.com>
 <ojqhXMXHiLkoJz_86chDvXRqvgvb07wabxTJX2feeho=.387c18d0-8eb2-4086-ab71-1930bb39985d@github.com>
 <u3oBOhMUiP4QOMC8-DxbRKdxVPtOyxVfPSs0OueLqak=.c1b15160-9486-45e9-833d-d1fd980d36ca@github.com>
 <lqdjdSFIbSczrcTMu3PBfbFRRumZW_cGXKOrS7iNpzk=.d88dac7e-ce1d-4566-9036-ba0ba65f521e@github.com>
 <4kKR1KP5iJ7G1_lvNKt4jOgRcCIyzDvlLDfO4rtxm2w=.c6fab761-d1ed-405b-b3b5-001a8e19f5db@github.com>
 <az34yLx_KXPTfsMkisg1iz29rHRSON_cRDAUiFa3YCI=.595c997f-444c-4e17-aa03-ff81b6406e71@github.com>
 <N0UvyYW8APmGD_RLtPCAqzpAyFUr11Nb7xn6d0wZd9E=.48a0fa88-8d79-4a0e-81eb-62a11f0d2e6f@github.com>
 <3T7nJ7BvnPjezFb-EzwCNkjq-zRjjsK-LrZTdRgZmzY=.c9ad8912-fbab-4b96-a9c1-9fe104cc904d@github.com>
 <Dit5d8mZV36XF32tzyZrbiuYM4M5xKXyYsi
 I2LR5F7A=.edcc8f71-75bd-4c4d-a062-7ac56f71b643@github.com>
 <T5MrQlsBXNe4YW3SJYkohSeatamAgSsfcOpwCcApkRI=.f14c783f-5ecb-4456-8c01-6a1cd961e791@github.com>
 <f_9hdtzQUxypVHl53oAzKTPBLHiPobmsVeZvfEoPFzE=.9a6e3ab7-32b6-4c66-8498-08d19f04757e@github.com>
 <y8hTn1ytvssUM96lapnB3PWX-tSaWduWQ51r314p4mw=.a72f2fd8-fbe5-4047-bb14-1a5ca5d80f7f@github.com>
 <YQyWI6gXjvXn-F6ueluwtkMITq1bHcw2zXq7DCbHNmo=.bab16ae4-e866-4af1-9710-8460e60adfb2@github.com>
 <Y7GZDVpsOy9MrmAXFKyFOv8NY2-OTAthXM6tUzOeOso=.12f21f2d-5c4a-4345-aad3-f664e02f4b17@github.com>
 <W1eFOcDW_inlLwcpn88obFJIhFuYdD69tXGZDsaYYl8=.055adff8-3096-4010-ba14-17d865673e23@github.com>
 <RaVblIRnK57MYiz3rGhS9raVxF51EVc5aIeOwKrUMpM=.94181f7e-4cb5-4c55-896a-2f866ee03cdd@github.com>
 <bUw-tcnXehysQcGF2v5gJQtqGrpjgrWs1GrPorYBTks=.ab3f744e-65d3-4609-9d18-0b1f5d67dfc5@github.com>
 <aI3cv_keI-VBfkwG8OWx5AH1h1JemvhTkz24hSIGVYo=.3707f7bc-ca6e-4b4d-bc18-0357839aa30d@github.com>
Message-ID: <3z3oBmOCLdwQRnBfeei0LU7RFQ3J-0IyAk0C8BUwGvU=.5c45065f-6600-4c0d-8aca-201c96239bb6@github.com>

On Thu, 16 Feb 2023 11:00:14 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>>> (Maybe too) long version:
>> 
>> Not at all :) I don't know much about the interpreter, so this is pretty helpful.
>> 
>> Ok. I think the main point is that a MH linker method doesn't ~have~ use a c2i adapter, it instead has separate versions for interpreted and compiled callers altogether (except `linkToNative` which doesn't have an interpreter version atm)
>> 
>> Longer version:
>> 
>> I think there are 4 theoretical cases (are there more?):
>> 1. interpreted -> MH interpreter entry -> interpreted (the case we want to fix, I think)
>> 2.  interpreted -> MH interpreter entry -> i2c -> compiled
>> 3. compiled -> c2i -> MH interpreter entry -> interpreted
>> 4. compiled -> c2i -> MH interpreter entry -> i2c -> compiled
>> 
>> So... my understanding is that a c2i adapter is used when a callee is interpreted, so its `from_compiled_entry` points to the c2i adapter. A compiled caller calls the `from_compiled_entry`, so it ends up going through the `c2i` adapter of an interpreted callee. However, for method handle linkers, the `from_compiled_entry` never points to a c2i adapter, but to the MH linker compiler entry generated in `gen_special_dispatch` in e.g `sharedRuntime_x86_64`. So, in other words, the 3. and 4. scenarios above are not possible, AFAICS. An MH linker's interpreted/compiled entries simply replace the regular `i2c` and `c2i` adapters for a MH linker method. Though, the actual target method can be either compiled or interpreted, so we can go into either a `c2i` adapter from a MH linker  compiler entry, or a `i2c` adapter from a MH linker interpreter entry (which is scenario 2.).
>> 
>> For scenario 1.: caller sets `r13` before jumping to callee (MH linker), we end up in the MH adapter, pop the last argument, and adjust `r13` for the actual callee. The MH interpreter entry uses `from_interpreted_entry` of the target method, so we don't go through any adapter.
>> 
>> For scenario 2.: mostly the same as 1., but we go through an `i2c` adapter, and the compiled callee doesn't care about what's in `r13` any ways. (there's a comment in the ic2 adapter code about preserving `r13` for the case that we might go back into a c2i adapter if we lose a race where the callee is made non-entrant, but `r13` is also used as a scratch register later in the i2c code, and the c2i code overwrites `r13` any ways. So, I think that is an outdated comment...)
>
>> So... my understanding is that a c2i adapter is used when a callee is
>> interpreted, so its `from_compiled_entry` points to the c2i adapter. A
>> compiled caller calls the `from_compiled_entry`, so it ends up going through
>> the `c2i` adapter of an interpreted callee. However, for method handle
>> linkers, the `from_compiled_entry` never points to a c2i adapter, but to the
>> MH linker compiler entry generated in `gen_special_dispatch` in e.g
>> `sharedRuntime_x86_64`. So, in other words, the 3. and 4. scenarios above are
>> not possible, AFAICS.
> 
> I see. Thanks! That's what I've been missing. It's implemented in `SystemDictionary::find_method_handle_intrinsic()` I think.
> 
> I agree that it will be ok to modify r13 as you suggested. Maybe explaining why we never reach here coming from a c2i adapter: because native wrappers are generated eagerly in `SystemDictionary::find_method_handle_intrinsic()` unless -Xint is given but then the caller cannot be compiled.

I integrated your suggestion, it seems to work now. I'm hopeful that our internal queue does not find a test error.

I'm happy for any commenting suggestions.

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

PR: https://git.openjdk.org/jdk/pull/12535

From eosterlund at openjdk.org  Thu Feb 16 16:07:30 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 16 Feb 2023 16:07:30 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms
In-Reply-To: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
Message-ID: <XdD303NdaxoMXJJZ68-Zi4_YsZ32cnfxUrS2HcjrdW4=.7612be31-44da-46c0-8ff8-4b6869a5c3bb@github.com>

On Thu, 16 Feb 2023 08:38:42 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi all, please consider.
> 
> The original issue was when thread 1 asked to deopt nmethod set X and thread 2 asked for the same or a subset of X.
> All method will already be marked, but the actual deoptimizing, not entrant, patching PC on stacks and patching post call nops, was not done yet. Which meant thread 2 could 'pass' thread 1.
> Most places did deopt under Compile_lock, thus this is not an issue, but WB and clearCallSiteContext do not.
> 
> Since a handshakes may take long before completion and Compile_lock is used for so much more than deopts.
> The fix in https://bugs.openjdk.org/browse/JDK-8299074 instead always emitted a handshake even when everything was already marked. (instead of adding Compile_lock to all places)
> 
> This turnout to be problematic in the startup, for example the number of deopt handshakes in jetty dry run startup went from 5 to 39 handshakes.
> 
> This fix first adds a barrier for which you do not pass until the requested deopts have happened and it coalesces the handshakes.
> Secondly it moves handshakes part out of the Compile_lock where it is possible.
> 
> Which means we fix the performance bug and we reduce the contention on Compile_lock, meaning higher throughput in compiler and things such as class-loading.
> 
> It passes t1-t7 with flying colours! t8 still not completed and I'm redoing some testing due to last minute simplifications.
> 
> Thanks, Robbin

Changes requested by eosterlund (Reviewer).

src/hotspot/share/runtime/deoptimization.cpp line 110:

> 108:   MutexLocker ml(CompiledMethod_lock, Mutex::_no_safepoint_check_flag);
> 109:   // If there is nothing to deopt _gen is the same as comitted.
> 110:   _gen = DeoptimizationScope::_committed_deopt_gen;

Could we find a better name for the "_gen" member? If I'm reading this right, it's some kind of _required_gen, right? As in we need to have committed up until this number, or it isn't safe to continue.

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

PR: https://git.openjdk.org/jdk/pull/12585

From pchilanomate at openjdk.org  Thu Feb 16 16:59:05 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 16 Feb 2023 16:59:05 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v5]
In-Reply-To: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
Message-ID: <AL1KW4Ax4BTYz8y7Wr8edbqabLTg73yJP_NZEQQcGbs=.70dba054-6dda-43f5-b138-c3494d955956@github.com>

> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
> 
> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
> 
> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
> 
> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
> 
> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - restore state should be only for VirtualThreads
 - add suspend check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12512/files
  - new: https://git.openjdk.org/jdk/pull/12512/files/7872f94c..3cb32734

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12512&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12512&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/12512

From pchilanomate at openjdk.org  Thu Feb 16 17:06:30 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 16 Feb 2023 17:06:30 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v3]
In-Reply-To: <SkRp2Wyh5PCsEHLBY11NOomx055Rw96U_GRcayV1jM8=.97d01412-d14b-4db3-9b05-3d0b6053a612@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <PXNLfQ0zN-PVmukV4zfJ1Vx1YoQTQ2sH5SaztW2pBpQ=.0bc3e63b-158a-4e9e-a591-71c3eec40bac@github.com>
 <Au35V60A-SAAkmrLAoi6MSqdtgh6E1rphGgJzyVxwU0=.c740d207-d820-476a-9436-40d0ac751207@github.com>
 <R4cj_O8kYS8lbSnINj6Z8UXHZVI2aVwF1z24B0oAUgA=.6cdff6f7-cee4-4ecc-a104-7ac95781f12e@github.com>
 <SkRp2Wyh5PCsEHLBY11NOomx055Rw96U_GRcayV1jM8=.97d01412-d14b-4db3-9b05-3d0b6053a612@github.com>
Message-ID: <gTowVxgiuUQt6wlJnvkNXKKfoIXLJcOVm_1oD9US4Qk=.f72e971c-1c3d-4173-a631-efb1167ff167@github.com>

On Thu, 16 Feb 2023 07:48:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The `SuspendAllVirtualThreads` spec has this statement:
> 
> ```
>   Suspend all virtual threads except those in the exception list.
>   Virtual threads that are currently suspended do not change state.
> ```
> 
> And the `ResumeAllVirtualThreads` spec has this statement:
> 
> ```
>   Resume all virtual threads except those in the exception list.
>   Virtual threads that are currently resumed do not change state
> ```
> 
> So that, `SuspendAllVirtualThreads` should do nothing with the already suspended virtual threads. And `ResumeAllVirtualThreads` should do nothing with the already resumed virtual threads. It does not depend on the except_list. It is better to avoid suspending already suspended threads and resuming already resumed. So, at least a check for `!java_thread->is_suspended()` is needed. 
>
Yes, the elist comment was related to the other issue. The reason why I didn't explicitly added this check is because it will we done in the suspend/resume call already (while holding the handshake lock which serializes the suspend/resume requests). So inside the suspend handshake for example either the target is suspended, so nothing is done, or the target is not suspended and we suspend it. Is there an actual issue I'm missing or is this to make a fast check and avoid the call? In any case I added the check. Also I see the specs for the single suspend/resume functions say the same thing about not changing the state and, for example, in SuspendThreadList we are also not making an explicit check before the call to suspend_thread(). So if there is an actual issue here, don't we need to add that check for them too?

>Did you observe any JVMTI or JDI suspend/resume tests failing?
>
No. I'll retest the patch again though once I resolve all comments.
 
> > Now, I realized that although single-suspends will not change _suspended_list/not_suspended_list for a BoundVirtualThread, SuspendAllVirtualThreads/ResumeAllVirtualThreads can if a BoundVirtualThread is part of the exception list. In the SuspendAllVirtualThreads case for example, when restoring the resume state, the call to JvmtiVTSuspender::is_vthread_suspended() would return true (we are already in SR_all mode and the BoundVirtualThread will not be in _not_suspended_list), meaning the BoundVirtualThread will be added to the not_suspended_list.
> > So we have to decide if we want to keep track of BoundVirtualThreads on these lists or not. Given that I see JvmtiVTSuspender::is_vthread_suspended() is always called on a VirtualThread the easiest thing would be to not track them, and just add a check in SuspendAllVirtualThreads/ResumeAllVirtualThreads where the elist is populated so only VirtualThreads are added. What do you think?
> 
> I feel that following the VirtualThread's implementation code path would be more consistent, unified and free of surprises. But I also see that following the platform threads code path looks pretty simple. So, it can be okay. So, for this approach, I think, the code fragments which collect and restore resumed/suspended state for virtual threads need to be bypassed by the BoundVirtualThreads implementation, so the `_suspended_list`/`not_suspended_list` won't be impacted. Please, let me know if it does not work by any reason. We also will have to rely on the testing here.
>
Sounds good. Yes, just following the platform thread code path is easier. Plus the other functions that are supported on virtual threads already have a branch for platform thread vs virtual thread, and the BoundVirtualThread already takes the platform thread path. Last commit is a fix for this issue in SuspendAllVirtualThreads/ResumeAllVirtualThreads, please take a look.

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

PR: https://git.openjdk.org/jdk/pull/12512

From sspitsyn at openjdk.org  Thu Feb 16 18:14:13 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Feb 2023 18:14:13 GMT
Subject: RFR: 8302615: make JVMTI thread cpu time functions optional for
 virtual threads
Message-ID: <N8X4H8wU3Yu8FFzwl9wSxTj6J8P8fM9JfutH1lh6uD0=.9983bb99-b5dc-4d08-8af5-7863a9c2bda1@github.com>

This is a minor JVM TI spec update for two timer functions `GetCurrentThreadCpuTime` and `GetThreadCpuTime` to allow implementations to support virtual threads.

The CSR is:
[JDK-8302616](https://bugs.openjdk.org/browse/JDK-8302616): make JVMTI thread cpu time functions optional for virtual threads

No testing is needed.

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

Commit messages:
 - 8302615: make JVMTI thread cpu time functions optional for virtual threads

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

PR: https://git.openjdk.org/jdk/pull/12604

From alanb at openjdk.org  Thu Feb 16 19:40:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Feb 2023 19:40:27 GMT
Subject: RFR: 8302615: make JVMTI thread cpu time functions optional for
 virtual threads
In-Reply-To: <N8X4H8wU3Yu8FFzwl9wSxTj6J8P8fM9JfutH1lh6uD0=.9983bb99-b5dc-4d08-8af5-7863a9c2bda1@github.com>
References: <N8X4H8wU3Yu8FFzwl9wSxTj6J8P8fM9JfutH1lh6uD0=.9983bb99-b5dc-4d08-8af5-7863a9c2bda1@github.com>
Message-ID: <GwZqWVngU1DsrKe_WPnGcgYCI61t_tx0fobg_df7q_Q=.b48f42e2-d068-4b58-9b02-b4b9bf0ace5b@github.com>

On Thu, 16 Feb 2023 18:05:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a minor JVM TI spec update for two timer functions `GetCurrentThreadCpuTime` and `GetThreadCpuTime` to allow implementations to support virtual threads.
> 
> The CSR is:
> [JDK-8302616](https://bugs.openjdk.org/browse/JDK-8302616): make JVMTI thread cpu time functions optional for virtual threads
> 
> No testing is needed.

Marked as reviewed by alanb (Reviewer).

I assume we'll rev the JVMTI version at some point in 21.

The change looks fine. It might be that we'll need to add a new capacity or add a field to jvmtiTimerInfo to say whether the implementation supports CPU time for virtual threads, but what we have now is okay.

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

PR: https://git.openjdk.org/jdk/pull/12604

From sspitsyn at openjdk.org  Thu Feb 16 23:28:30 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Feb 2023 23:28:30 GMT
Subject: RFR: 8302615: make JVMTI thread cpu time functions optional for
 virtual threads
In-Reply-To: <N8X4H8wU3Yu8FFzwl9wSxTj6J8P8fM9JfutH1lh6uD0=.9983bb99-b5dc-4d08-8af5-7863a9c2bda1@github.com>
References: <N8X4H8wU3Yu8FFzwl9wSxTj6J8P8fM9JfutH1lh6uD0=.9983bb99-b5dc-4d08-8af5-7863a9c2bda1@github.com>
Message-ID: <ROTKVUv89FQ3cKkWX7zBwsYOZ3SiaoUkpUcpHBTCAsk=.79992b8a-b7cd-414b-b70a-1621c342bd32@github.com>

On Thu, 16 Feb 2023 18:05:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a minor JVM TI spec update for two timer functions `GetCurrentThreadCpuTime` and `GetThreadCpuTime` to allow implementations to support virtual threads.
> 
> The CSR is:
> [JDK-8302616](https://bugs.openjdk.org/browse/JDK-8302616): make JVMTI thread cpu time functions optional for virtual threads
> 
> No testing is needed.

Thank you for review, Alan.

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

PR: https://git.openjdk.org/jdk/pull/12604

From dholmes at openjdk.org  Fri Feb 17 03:10:27 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Feb 2023 03:10:27 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v2]
In-Reply-To: <n_pH4nVpPaKxt1lDeCQ93MkRAItgJvBZSN8sy4eitrY=.85bde83e-c59f-41a2-844a-a61da45545dc@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <n_pH4nVpPaKxt1lDeCQ93MkRAItgJvBZSN8sy4eitrY=.85bde83e-c59f-41a2-844a-a61da45545dc@github.com>
Message-ID: <x1LwjWwRBiDRxE0vpIAcCx_Qkm9iIQjfFl7Sc2j4Kq0=.0ab64165-841f-436b-a1e2-495c8ba50673@github.com>

On Thu, 16 Feb 2023 14:25:15 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Extends the existing AsyncGetCallTrace test case and fixes the issue by modifying `MethodHandles` code.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement addptr suggestion by @JohnVernee and @reinrich

There are crashes in stack walking with this change. Try e.g.

vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (c:\sb\prod\1676562544\workspace\open\src\hotspot\share\code/codeCache.inline.hpp:49), pid=55852, tid=36120
#  assert(cb != nullptr) failed: must be

Stack: [0x0000001077100000,0x0000001077200000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xbf7311]  os::win32::platform_print_native_stack+0xf1  (os_windows_x86.cpp:236)
V  [jvm.dll+0xe705d0]  VMError::report+0x10c0  (vmError.cpp:813)
V  [jvm.dll+0xe7220e]  VMError::report_and_die+0x6ce  (vmError.cpp:1593)
V  [jvm.dll+0xe72954]  VMError::report_and_die+0x64  (vmError.cpp:1352)
V  [jvm.dll+0x576ef6]  report_vm_error+0x96  (debug.cpp:181)
V  [jvm.dll+0x3fb595]  frame::sender_for_compiled_frame+0x515  (frame_x86.inline.hpp:441)
V  [jvm.dll+0x3fb85d]  frame::sender_raw+0x1dd  (frame_x86.inline.hpp:386)
V  [jvm.dll+0x524f4f]  vframeStreamCommon::next+0x52f  (vframe.inline.hpp:103)
V  [jvm.dll+0x7d7350]  java_lang_Throwable::fill_in_stack_trace+0x810  (javaClasses.cpp:2589)
V  [jvm.dll+0x7d6b16]  java_lang_Throwable::fill_in_stack_trace+0x86  (javaClasses.cpp:2649)
V  [jvm.dll+0x8b723d]  JVM_FillInStackTrace+0x1ad  (jvm.cpp:505)
C  [java.dll+0x7162]

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

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Fri Feb 17 03:15:56 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 17 Feb 2023 03:15:56 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v5]
In-Reply-To: <ybE2QYYZQ6GU7o67rW5rpgA3JGxULHDGlTUTi-2cky8=.488673b2-40fe-49d3-9076-ac4c2b10efe0@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <ybE2QYYZQ6GU7o67rW5rpgA3JGxULHDGlTUTi-2cky8=.488673b2-40fe-49d3-9076-ac4c2b10efe0@github.com>
Message-ID: <vx8i_CIWT4jzEeeaayICiQ31DbtvF76qnu5_ttCyXg8=.c09d6ef0-d343-49b0-b0fb-92a50f8d2f0f@github.com>

On Thu, 24 Mar 2022 07:01:43 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
>> 
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
>> 
>> [1] https://openjdk.java.net/jeps/422
>
> Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8276799
>  - Fix copyright header
>  - Address review comments
>  - Merge remote-tracking branch 'upstream/master' into JDK-8276799
>  - 8276799: Implementation of JEP 422: Linux/RISC-V Port

src/hotspot/cpu/riscv/riscv.ad line 8758:

> 8756: %{
> 8757:   // Same match rule as `far_cmpU_loop'.
> 8758:   match(CountedLoopEnd cmp (CmpU op1 op2));

Which testcases can test this instruct and the following instructs?
match(CountedLoopEnd cmp (CmpP op1 op2));
match(CountedLoopEnd cmp (CmpN op1 op2));
match(CountedLoopEnd cmp (CmpF op1 op2));
match(CountedLoopEnd cmp (CmpD op1 op2));

 I suspect this instruction is useless.

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

PR: https://git.openjdk.org/jdk/pull/6294

From sspitsyn at openjdk.org  Fri Feb 17 04:43:30 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Feb 2023 04:43:30 GMT
Subject: RFR: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint
In-Reply-To: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
References: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
Message-ID: <YnVK09wMmg6IxGd3Skh2TS1lWc189yF3p3FksGEuuIo=.39403c9e-7c8a-4248-a1f9-85625f913529@github.com>

On Tue, 14 Feb 2023 05:37:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The rank of JvmtiVTMSTransition_lock is better to be safepoint instead of nosafepoint.
> The fix includes removal of the function `check_vthread_and_suspend_at_safepoint` which is not needed anymore.
> 
> Testing:
> mach5 jobs are in progress:
>  Kitchensink, tiers1-6 (all JVMTI, JDWP, JDI and JDB tests have to be included)

PING! This is relatively simple update.
The testing is clean and has not found any regressions.

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

PR: https://git.openjdk.org/jdk/pull/12550

From dholmes at openjdk.org  Fri Feb 17 05:14:59 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Feb 2023 05:14:59 GMT
Subject: RFR: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint
In-Reply-To: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
References: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
Message-ID: <gFGpHzd_o6pcpIkiQCVx8uO52pyMPh_7JahYqbYyBQ4=.14aba3b6-380a-4ed0-96b8-1ea2e5daa402@github.com>

On Tue, 14 Feb 2023 05:37:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The rank of JvmtiVTMSTransition_lock is better to be safepoint instead of nosafepoint.
> The fix includes removal of the function `check_vthread_and_suspend_at_safepoint` which is not needed anymore.
> 
> Testing:
> mach5 jobs are in progress:
>  Kitchensink, tiers1-6 (all JVMTI, JDWP, JDI and JDB tests have to be included)

This looks a lot cleaner have the `JvmtiVTMSTransition_lock` be a normal safepoint-honouring monitor, but that said, it means there are now many places that can block for safepoints that previously wouldn't and it is very to hard to tell if that is okay or not.

src/hotspot/share/prims/jvmtiEnv.cpp line 952:

> 950:     }
> 951:     // protect thread_oop as a safepoint can be reached in disabler destructor
> 952:     self_tobj = Handle(current, thread_oop);

If you move this after line 953 then you can delete line 932 and just have:

Handle self_tobj = Handle(current, thread_oop);

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

PR: https://git.openjdk.org/jdk/pull/12550

From duke at openjdk.org  Fri Feb 17 07:55:19 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Fri, 17 Feb 2023 07:55:19 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v2]
In-Reply-To: <n_pH4nVpPaKxt1lDeCQ93MkRAItgJvBZSN8sy4eitrY=.85bde83e-c59f-41a2-844a-a61da45545dc@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <n_pH4nVpPaKxt1lDeCQ93MkRAItgJvBZSN8sy4eitrY=.85bde83e-c59f-41a2-844a-a61da45545dc@github.com>
Message-ID: <sxv-8uW8iBNmmrWaY657K8b3LTYX2ChTAZeTHj1yy90=.0abf8ccb-f04c-4f1c-a6ce-3b0d2bf161b7@github.com>

On Thu, 16 Feb 2023 14:25:15 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Extends the existing AsyncGetCallTrace test case and fixes the issue by modifying `MethodHandles` code.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement addptr suggestion by @JohnVernee and @reinrich

There also errors on Linux, e.g. `vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java`:


- stepBreakPopReturn.cpp, 57: Setting debuggee class name to Lvm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test;
- stepBreakPopReturn.cpp, 86: Entering method: Lvm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test;.setDebuggeeMethodName
- stepBreakPopReturn.cpp, 51: Setting debuggee method name to target
### TRACE 0: Call site 1
- stepBreakPopReturn.cpp, 86: Entering method: Lvm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test;.bootstrap
### TRACE 0: Lookup vm.mlvm.indy.func.jvmti.stepBreakPopReturn.INDIFY_Test; method name = greet; method type = (Object,String,int)int
- stepBreakPopReturn.cpp, 86: Entering method: Lvm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test;.target
- stepBreakPopReturn.cpp, 115: Single step event: Lvm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test; .target :1
- stepBreakPopReturn.cpp, 128: Pop a frame
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000000000315, pid=41551, tid=41572
#
# JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-adhoc.openjdk.jdk-dev)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-adhoc.openjdk.jdk-dev, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  0x00000000e755a950
#
# Core dump will be written. Default location: /priv/jvmtests/output_openjdk21_dev_dbgU_linuxx86_64/jtreg_hotspot_tier4_work/JTwork/scratch/0
#
# An error report file with more information is saved as:
# /priv/jvmtests/output_openjdk21_dev_dbgU_linuxx86_64/jtreg_hotspot_tier4_work/JTwork/scratch/hs_err_pid41551.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#


So back to my original suggestion which is simple and worked (ran it through our internal test queue and found no errors)?

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

PR: https://git.openjdk.org/jdk/pull/12535

From rrich at openjdk.org  Fri Feb 17 08:21:17 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 17 Feb 2023 08:21:17 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v2]
In-Reply-To: <n_pH4nVpPaKxt1lDeCQ93MkRAItgJvBZSN8sy4eitrY=.85bde83e-c59f-41a2-844a-a61da45545dc@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <n_pH4nVpPaKxt1lDeCQ93MkRAItgJvBZSN8sy4eitrY=.85bde83e-c59f-41a2-844a-a61da45545dc@github.com>
Message-ID: <5xO0svcjCbnRvfhW7LCQMYJHaIioUptiuBgrld_DPYE=.a975b1e5-45b8-42ed-975b-64b474955f80@github.com>

On Thu, 16 Feb 2023 14:25:15 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Extends the existing AsyncGetCallTrace test case and fixes the issue by modifying `MethodHandles` code.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement addptr suggestion by @JohnVernee and @reinrich

Java stack


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000000000315, pid=41551, tid=41572
#
# JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-adhoc.openjdk.jdk-dev)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-adhoc.openjdk.jdk-dev, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  0x00000000e755a950
#
# Core dump will be written. Default location: .../jtreg_hotspot_tier4_work/JTwork/scratch/0
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -Dtest.vm.opts=-Xmx768m -Djava.awt.headless=true -Djava.util.prefs.userRoot=.../jtreg_hotspot_tier4_work/tmp -Djava.io.tmpdir=.../jtreg_hotspot_tier4_work/tmp -Dtest.getfreeport.max.tries=40 -ea -esa -Dtest.tool.vm.opts=-J-Xmx768m -J-Djava.awt.headless=true -J-Djava.util.prefs.userRoot=.../jtreg_hotspot_tier4_work/tmp -J-Djava.io.tmpdir=.../jtreg_hotspot_tier4_work/tmp -J-Dtest.getfreeport.max.tries=40 -J-ea -J-esa -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=.../sapjvm_21 -Dcompile.jdk=.../sapjvm_21 -Dtest.timeout.factor=6.0 -Dtest.nativepath=.../grmpf/testdata/jtreg/jtreg_test_21/test/hotspot/jtreg/native -Dtest.root=.../grmpf/testdata/jtreg/jtreg_test_21/test/hotspot/jtreg -Dtest.name=vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java -Dtest.file=.../grmpf/testdata/jtreg/jtreg_test_21/test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java -Dtest.src=.../grmpf/testdata/jtreg/jtreg_test_21/test/hotspot/jtreg/
 vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn -Dtest.src.path=.../grmpf/testdata/jtreg/jtreg_test_21/test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn:.../grmpf/testdata/jtreg/jtreg_test_21/test/hotspot/jtreg/vmTestbase:.../grmpf/testdata/jtreg/jtreg_test_21/test/lib -Dtest.classes=.../jtreg_hotspot_tier4_work/JTwork/classes/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.d -Dtest.class.path=.../jtreg_hotspot_tier4_work/JTwork/classes/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.d:.../jtreg_hotspot_tier4_work/JTwork/classes/vmTestbase:.../jtreg_hotspot_tier4_work/JTwork/classes/test/lib -Dtest.class.path.prefix=.../jtreg_hotspot_tier4_work/JTwork/classes/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.d:.../grmpf/testdata/jtreg/jtreg_test_21/test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn:.../jtreg_hotspot_tier4_work/JTwork/classes/vmTestbase:.../jtreg_hotspot_tier4_work/
 JTwork/classes/test/lib -Xmx768m -Djava.awt.headless=true -Djava.util.prefs.userRoot=.../jtreg_hotspot_tier4_work/tmp -Djava.io.tmpdir=.../jtreg_hotspot_tier4_work/tmp -Dtest.getfreeport.max.tries=40 -ea -esa -Djava.library.path=.../grmpf/testdata/jtreg/jtreg_test_21/test/hotspot/jtreg/native -agentlib:stepBreakPopReturn=verbose= com.sun.javatest.regtest.agent.MainWrapper .../jtreg_hotspot_tier4_work/JTwork/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.d/main.0.jta

Host: ..., Intel(R) Xeon(R) Platinum 8260M CPU @ 2.40GHz, 8 cores, 23G, SUSE Linux Enterprise Server 15 SP3
Time: Fri Feb 17 01:34:06 2023 CET elapsed time: 2.781186 seconds (0d 0h 0m 2s)

---------------  T H R E A D  ---------------

Current thread (0x00007fbc94422600):  JavaThread "MainThread" [_thread_in_Java, id=41572, stack(0x00007fbc6af26000,0x00007fbc6b027000)]

Stack: [0x00007fbc6af26000,0x00007fbc6b027000],  sp=0x00007fbc6b025118,  free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x00000000e755a950
j  java.lang.invoke.LambdaForm$MH+0x0000000801018400.linkToTargetMethod(Ljava/lang/Object;Ljava/lang/Object;ILjava/lang/Object;)I+7 java.base at 21-internal
j  vm.mlvm.indy.func.jvmti.stepBreakPopReturn.INDIFY_Test.run()Z+52
j  vm.mlvm.share.MlvmTestExecutor.runMlvmTestInstance(Lvm/mlvm/share/MlvmTest;)Z+82
j  vm.mlvm.share.MlvmTestExecutor.runMlvmTest(Ljava/lang/Class;[Ljava/lang/Object;)Z+21
j  vm.mlvm.share.MlvmTestExecutor.launch(Ljava/lang/Class;[Ljava/lang/Object;)V+28
j  vm.mlvm.share.MlvmTestExecutor.launch([Ljava/lang/Object;)V+20
j  vm.mlvm.share.MlvmTestExecutor.launch([Ljava/lang/String;[Ljava/lang/Object;)V+5
j  vm.mlvm.share.MlvmTest.launch([Ljava/lang/String;)V+2
j  vm.mlvm.indy.func.jvmti.stepBreakPopReturn.INDIFY_Test.main([Ljava/lang/String;)V+1
j  java.lang.invoke.LambdaForm$DMH+0x0000000801001800.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base at 21-internal
j  java.lang.invoke.LambdaForm$MH+0x0000000801002c00.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base at 21-internal
j  java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base at 21-internal
j  jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base at 21-internal
j  jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base at 21-internal
j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base at 21-internal
j  com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+134
j  java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base at 21-internal
j  java.lang.Thread.run()V+19 java.base at 21-internal
v  ~StubRoutines::call_stub 0x00007fbc8417fd21
V  [libjvm.so+0xeec41a]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4da  (javaCalls.cpp:415)
V  [libjvm.so+0xeeca90]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x290  (javaCalls.cpp:329)

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

PR: https://git.openjdk.org/jdk/pull/12535

From sspitsyn at openjdk.org  Fri Feb 17 08:26:20 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Feb 2023 08:26:20 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v5]
In-Reply-To: <AL1KW4Ax4BTYz8y7Wr8edbqabLTg73yJP_NZEQQcGbs=.70dba054-6dda-43f5-b138-c3494d955956@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <AL1KW4Ax4BTYz8y7Wr8edbqabLTg73yJP_NZEQQcGbs=.70dba054-6dda-43f5-b138-c3494d955956@github.com>
Message-ID: <IbrY9gPbGoBbNU-3AMzerK4MznWf4MSuPNWvpZKp_58=.b08b9538-103a-4b08-893c-20682dc20f20@github.com>

On Thu, 16 Feb 2023 16:59:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
>> 
>> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
>> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
>> 
>> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
>> 
>> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
>> 
>> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - restore state should be only for VirtualThreads
>  - add suspend check

test/hotspot/jtreg/serviceability/jvmti/vthread/BoundVThreadTest/libBoundVThreadTest.cpp line 35:

> 33: static int vthread_start_count = 0;
> 34: static int vthread_end_count = 0;
> 35: static bool passed = JNI_TRUE;

Nit: It is better to rename: passed => status.

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

PR: https://git.openjdk.org/jdk/pull/12512

From sspitsyn at openjdk.org  Fri Feb 17 08:32:18 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Feb 2023 08:32:18 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v5]
In-Reply-To: <AL1KW4Ax4BTYz8y7Wr8edbqabLTg73yJP_NZEQQcGbs=.70dba054-6dda-43f5-b138-c3494d955956@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <AL1KW4Ax4BTYz8y7Wr8edbqabLTg73yJP_NZEQQcGbs=.70dba054-6dda-43f5-b138-c3494d955956@github.com>
Message-ID: <9wwOk3VkUENUkmqGVBeprYDaaFs_I1Ofv21DvwwWQms=.c79c56dc-f373-499f-ab63-c1959ff039ee@github.com>

On Thu, 16 Feb 2023 16:59:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
>> 
>> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
>> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
>> 
>> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
>> 
>> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
>> 
>> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - restore state should be only for VirtualThreads
>  - add suspend check

The fix looks good to me. Thank you for the update.
I'm not sure if you wanted to get rid of `is_bound_vthread` though.
Just want to know you intention.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12512

From sspitsyn at openjdk.org  Fri Feb 17 08:47:27 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Feb 2023 08:47:27 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v3]
In-Reply-To: <gTowVxgiuUQt6wlJnvkNXKKfoIXLJcOVm_1oD9US4Qk=.f72e971c-1c3d-4173-a631-efb1167ff167@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <PXNLfQ0zN-PVmukV4zfJ1Vx1YoQTQ2sH5SaztW2pBpQ=.0bc3e63b-158a-4e9e-a591-71c3eec40bac@github.com>
 <Au35V60A-SAAkmrLAoi6MSqdtgh6E1rphGgJzyVxwU0=.c740d207-d820-476a-9436-40d0ac751207@github.com>
 <R4cj_O8kYS8lbSnINj6Z8UXHZVI2aVwF1z24B0oAUgA=.6cdff6f7-cee4-4ecc-a104-7ac95781f12e@github.com>
 <SkRp2Wyh5PCsEHLBY11NOomx055Rw96U_GRcayV1jM8=.97d01412-d14b-4db3-9b05-3d0b6053a612@github.com>
 <gTowVxgiuUQt6wlJnvkNXKKfoIXLJcOVm_1oD9US4Qk=.f72e971c-1c3d-4173-a631-efb1167ff167@github.com>
Message-ID: <YaLyafQxjECyIOm_oaUVVkeEBe-hEnRG5XofEOP_tHk=.bfd9fe41-2bb6-4a77-9518-1ceadb851953@github.com>

On Thu, 16 Feb 2023 17:03:32 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Yes, the elist comment was related to the other issue. The reason why I didn't explicitly added this check is because it will we done in the suspend/resume call already (while holding the handshake lock which serializes the suspend/resume requests). So inside the suspend handshake for example either the target is suspended, so nothing is done, or the target is not suspended and we suspend it. Is there an actual issue I'm missing or is this to make a fast check and avoid the call? In any case I added the check. Also I see the specs for the single suspend/resume functions say the same thing about not changing the state and, for example, in SuspendThreadList we are also not making an explicit check before the call to suspend_thread(). So if there is an actual issue here, don't we need to add that check for them too?

I agree with your analysis. And you are right on the `SuspendThreadList` as well.
The `SuspendThreadList` also return an error code of each suspend in the result array.
It'd be nice to add a check there as well to make it consistent but I'd suggest to be conservative here and leave it as it is now.

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

PR: https://git.openjdk.org/jdk/pull/12512

From jvernee at openjdk.org  Fri Feb 17 14:18:50 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 17 Feb 2023 14:18:50 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v2]
In-Reply-To: <n_pH4nVpPaKxt1lDeCQ93MkRAItgJvBZSN8sy4eitrY=.85bde83e-c59f-41a2-844a-a61da45545dc@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <n_pH4nVpPaKxt1lDeCQ93MkRAItgJvBZSN8sy4eitrY=.85bde83e-c59f-41a2-844a-a61da45545dc@github.com>
Message-ID: <iGNuSoBr5vl1T8dn5reN9lsW1hhl3ScpN4GD1bnxBDA=.0402c11b-bd82-4071-b5d6-247baa47fce6@github.com>

On Thu, 16 Feb 2023 14:25:15 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Extends the existing AsyncGetCallTrace test case and fixes the issue by modifying `MethodHandles` code.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement addptr suggestion by @JohnVernee and @reinrich

Thanks for trying it out! I ran tier 1-4 here as well, and all failing tests are in `vmTestbase/vm/mlvm/indy/func/jvmti`. They all seem to be using `PopFrame` before a crash happens, so I think that might be where the problem is. I don't think it's impossible that there is other code out there that has it's own workaround for the incorrect unextended_sp.

Also, I later realized that interpreter frames also save the sp before before making a call (`interpreter_frame_last_sp_offset`), and I can find at least some code that seems to assume `caller.unextended_sp() == (intptr_t*)caller.at(frame::interpreter_frame_last_sp_offset)`, so we'd just be breaking another invariant with my "fix".

There's probably a bit of tech debt here (filed: https://bugs.openjdk.org/browse/JDK-8302745).

I had a closer look at the original fix, and it looks like the `unextended_sp` is only used to check the size of the caller frame for interpreter -> interpreter calls.  So, I think it's okay to relax the `unextende_sp >= sp` check (the invariant it tests turns out not to hold for otherwise valid stacks any way). But, in that case, please leave a comment that explains why we can have `sp > unextended_sp`.

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

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Fri Feb 17 14:29:30 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Fri, 17 Feb 2023 14:29:30 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v2]
In-Reply-To: <iGNuSoBr5vl1T8dn5reN9lsW1hhl3ScpN4GD1bnxBDA=.0402c11b-bd82-4071-b5d6-247baa47fce6@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <n_pH4nVpPaKxt1lDeCQ93MkRAItgJvBZSN8sy4eitrY=.85bde83e-c59f-41a2-844a-a61da45545dc@github.com>
 <iGNuSoBr5vl1T8dn5reN9lsW1hhl3ScpN4GD1bnxBDA=.0402c11b-bd82-4071-b5d6-247baa47fce6@github.com>
Message-ID: <Lda1XzlcEzjAJvcIsJr8OMcNJXFzJLE1vYbjU9LnYfw=.0c55d18f-a077-487d-b5ae-37ad0c9ebc53@github.com>

On Fri, 17 Feb 2023 14:00:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> But, in that case, please leave a comment that explains why we can have sp > unextended_sp.

Could you be so kind to synthesize a comment for me? I'm slightly overwhelmed by the discussion.

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

PR: https://git.openjdk.org/jdk/pull/12535

From jvernee at openjdk.org  Fri Feb 17 14:29:31 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 17 Feb 2023 14:29:31 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v2]
In-Reply-To: <Lda1XzlcEzjAJvcIsJr8OMcNJXFzJLE1vYbjU9LnYfw=.0c55d18f-a077-487d-b5ae-37ad0c9ebc53@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <n_pH4nVpPaKxt1lDeCQ93MkRAItgJvBZSN8sy4eitrY=.85bde83e-c59f-41a2-844a-a61da45545dc@github.com>
 <iGNuSoBr5vl1T8dn5reN9lsW1hhl3ScpN4GD1bnxBDA=.0402c11b-bd82-4071-b5d6-247baa47fce6@github.com>
 <Lda1XzlcEzjAJvcIsJr8OMcNJXFzJLE1vYbjU9LnYfw=.0c55d18f-a077-487d-b5ae-37ad0c9ebc53@github.com>
Message-ID: <cKJissZlR0IFP5mRhi8Y5kwsyptwrRdAynBIzekq-Ks=.87cc887d-00f7-4ce0-8c0c-37035804f111@github.com>

On Fri, 17 Feb 2023 14:13:04 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

> Could you be so kind to synthesize a comment for me? I'm slightly overwhelmed by the discussion.

Something like:


// Note: sp can be greater than unextended_sp in the case of
// interpreted -> interpreted calls that go through a method handle linker,
// since those pop the last argument (the appendix) from the stack.

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

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Fri Feb 17 14:47:56 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Fri, 17 Feb 2023 14:47:56 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v3]
In-Reply-To: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
Message-ID: <ywdTEjngAhYV4gNTy0LyshW3TBVgmr2-j9gwQZcNjP0=.42d25a37-f574-46a8-99b8-971b01da9dcf@github.com>

> Extends the existing AsyncGetCallTrace test case and fixes the issue.

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

  Revert previous change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12535/files
  - new: https://git.openjdk.org/jdk/pull/12535/files/e63ab44a..da706d3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12535&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12535&range=01-02

  Stats: 9 lines in 2 files changed: 3 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12535.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12535/head:pull/12535

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Fri Feb 17 14:47:57 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Fri, 17 Feb 2023 14:47:57 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v2]
In-Reply-To: <n_pH4nVpPaKxt1lDeCQ93MkRAItgJvBZSN8sy4eitrY=.85bde83e-c59f-41a2-844a-a61da45545dc@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <n_pH4nVpPaKxt1lDeCQ93MkRAItgJvBZSN8sy4eitrY=.85bde83e-c59f-41a2-844a-a61da45545dc@github.com>
Message-ID: <QInl9hiDEevEm4YwcM356__641LvYUUKJWZHPuvuCMs=.9f4c4a0b-f8d6-434b-8ebd-dc158fffe25b@github.com>

On Thu, 16 Feb 2023 14:25:15 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Extends the existing AsyncGetCallTrace test case and fixes the issue.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement addptr suggestion by @JohnVernee and @reinrich

Thanks, I modified my PR accordingly.

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

PR: https://git.openjdk.org/jdk/pull/12535

From pchilanomate at openjdk.org  Fri Feb 17 15:30:51 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 17 Feb 2023 15:30:51 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v6]
In-Reply-To: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
Message-ID: <ZfRmxtSvrJm2GjC4hlZuRzV0sVYJTC6Ke1L3pGp35v8=.2ad033cf-dc54-4b39-bf2e-c7094660e256@github.com>

> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
> 
> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
> 
> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
> 
> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
> 
> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  remove _is_bound_vthread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12512/files
  - new: https://git.openjdk.org/jdk/pull/12512/files/3cb32734..d8f52713

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12512&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12512&range=04-05

  Stats: 28 lines in 6 files changed: 0 ins; 20 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12512.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12512/head:pull/12512

PR: https://git.openjdk.org/jdk/pull/12512

From pchilanomate at openjdk.org  Fri Feb 17 15:36:25 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 17 Feb 2023 15:36:25 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v5]
In-Reply-To: <9wwOk3VkUENUkmqGVBeprYDaaFs_I1Ofv21DvwwWQms=.c79c56dc-f373-499f-ab63-c1959ff039ee@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <AL1KW4Ax4BTYz8y7Wr8edbqabLTg73yJP_NZEQQcGbs=.70dba054-6dda-43f5-b138-c3494d955956@github.com>
 <9wwOk3VkUENUkmqGVBeprYDaaFs_I1Ofv21DvwwWQms=.c79c56dc-f373-499f-ab63-c1959ff039ee@github.com>
Message-ID: <ynlcfE-ti0ZNM09nZz-zT076koDOKv-i97vmuLhTKqM=.50bad149-b739-4e75-be25-ce96d5305ff3@github.com>

On Fri, 17 Feb 2023 08:29:53 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The fix looks good to me. Thank you for the update. I'm not sure if you wanted to get rid of `is_bound_vthread` though. Just want to know you intention. Thanks, Serguei
>
Great. Yes, I just removed is_bound_vthread, please take a look when you have time. I'll also re-run all testing again before integration. 
Thanks for the review Serguei!

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

PR: https://git.openjdk.org/jdk/pull/12512

From pchilanomate at openjdk.org  Fri Feb 17 15:48:02 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 17 Feb 2023 15:48:02 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v5]
In-Reply-To: <IbrY9gPbGoBbNU-3AMzerK4MznWf4MSuPNWvpZKp_58=.b08b9538-103a-4b08-893c-20682dc20f20@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <AL1KW4Ax4BTYz8y7Wr8edbqabLTg73yJP_NZEQQcGbs=.70dba054-6dda-43f5-b138-c3494d955956@github.com>
 <IbrY9gPbGoBbNU-3AMzerK4MznWf4MSuPNWvpZKp_58=.b08b9538-103a-4b08-893c-20682dc20f20@github.com>
Message-ID: <vMrLKi29KlWOpLeaCosbvhkrRvVFaAe6spWfwId6wdQ=.bd1a79d1-26c0-4274-be6b-98443f09c3d1@github.com>

On Fri, 17 Feb 2023 08:23:13 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - restore state should be only for VirtualThreads
>>  - add suspend check
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/BoundVThreadTest/libBoundVThreadTest.cpp line 35:
> 
>> 33: static int vthread_start_count = 0;
>> 34: static int vthread_end_count = 0;
>> 35: static bool passed = JNI_TRUE;
> 
> Nit: It is better to rename: passed => status.

Fixed.

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

PR: https://git.openjdk.org/jdk/pull/12512

From pchilanomate at openjdk.org  Fri Feb 17 16:07:50 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 17 Feb 2023 16:07:50 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v7]
In-Reply-To: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
Message-ID: <TNrb8vxGZPuUTAEkOXiXdqMcEqIfLzFdOafFetj4hNw=.a76c17fa-13a7-49e3-b748-d6c75f0fbecb@github.com>

> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
> 
> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
> 
> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
> 
> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
> 
> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  s/passed/status

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12512/files
  - new: https://git.openjdk.org/jdk/pull/12512/files/d8f52713..6b3ec24e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12512&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12512&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/12512

From abakhtin at openjdk.org  Fri Feb 17 18:25:10 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 17 Feb 2023 18:25:10 GMT
Subject: RFR: 8299234: JMX Repository.query performance [v6]
In-Reply-To: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
References: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
Message-ID: <4tZW46OQSXdhDi_wQj134cV2c7uKEaxDdYMzv1NeRv8=.f3db00c4-2d8d-4bb0-8cf6-f528b0e85626@github.com>

> Please find a patch to improve JMX Repository.query performance
> 
> Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles:
> Before:
> 
> $ java test 1000000 1000000
> Test PASSED in 8943169791 ns.
> GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118
> 
> 
> After:
> 
> $ java test 1000000 1000000
> Test PASSED in 4808213917 ns.
> GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53
> 
> Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation.
> 
> All javax/management jtreg tests passed successfully.

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

  Add braces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11758/files
  - new: https://git.openjdk.org/jdk/pull/11758/files/0bdbbcb5..32259a1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11758&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11758&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/11758

From abakhtin at openjdk.org  Fri Feb 17 18:25:13 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 17 Feb 2023 18:25:13 GMT
Subject: RFR: 8299234: JMX Repository.query performance [v5]
In-Reply-To: <6KYOyyel303sWsfKV1grdPn8L-4nD9apUPsxr3MKIxM=.9a1a54c3-1477-4b82-88ea-c8bbd7e4dccd@github.com>
References: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
 <YH-y2lwy0IU4s9Ri6vuNwwgpZpJzFIQW_ttuE8KkFFs=.ccabc1f9-d27d-469a-847b-69c4e882d7e6@github.com>
 <6KYOyyel303sWsfKV1grdPn8L-4nD9apUPsxr3MKIxM=.9a1a54c3-1477-4b82-88ea-c8bbd7e4dccd@github.com>
Message-ID: <xCUuqJFycvKYK1FO3wKXF3K6gVK_a3oJtQ9X19pD9UM=.ae4b91e5-6d53-47d5-bd20-48e013369769@github.com>

On Fri, 17 Feb 2023 17:34:53 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> 2026 and 2031 I was referring to with the nit about if and { }

Hi @kevinjwalls ! Thank you for review.
The braces are added

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

PR: https://git.openjdk.org/jdk/pull/11758

From kevinw at openjdk.org  Fri Feb 17 18:47:14 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 Feb 2023 18:47:14 GMT
Subject: RFR: 8299234: JMX Repository.query performance [v6]
In-Reply-To: <4tZW46OQSXdhDi_wQj134cV2c7uKEaxDdYMzv1NeRv8=.f3db00c4-2d8d-4bb0-8cf6-f528b0e85626@github.com>
References: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
 <4tZW46OQSXdhDi_wQj134cV2c7uKEaxDdYMzv1NeRv8=.f3db00c4-2d8d-4bb0-8cf6-f528b0e85626@github.com>
Message-ID: <sBRpW67WYQRii6E1ukgkxNP_ynGEJ_5rxvr9hxS2bLE=.4c70f215-bcb8-4c74-9838-c3ebddf22a9f@github.com>

On Fri, 17 Feb 2023 18:25:10 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please find a patch to improve JMX Repository.query performance
>> 
>> Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles:
>> Before:
>> 
>> $ java test 1000000 1000000
>> Test PASSED in 8943169791 ns.
>> GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118
>> 
>> 
>> After:
>> 
>> $ java test 1000000 1000000
>> Test PASSED in 4808213917 ns.
>> GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53
>> 
>> Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation.
>> 
>> All javax/management jtreg tests passed successfully.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add braces

Marked as reviewed by kevinw (Committer).

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

PR: https://git.openjdk.org/jdk/pull/11758

From kevinw at openjdk.org  Fri Feb 17 18:47:18 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 Feb 2023 18:47:18 GMT
Subject: RFR: 8299234: JMX Repository.query performance [v5]
In-Reply-To: <xCUuqJFycvKYK1FO3wKXF3K6gVK_a3oJtQ9X19pD9UM=.ae4b91e5-6d53-47d5-bd20-48e013369769@github.com>
References: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
 <YH-y2lwy0IU4s9Ri6vuNwwgpZpJzFIQW_ttuE8KkFFs=.ccabc1f9-d27d-469a-847b-69c4e882d7e6@github.com>
 <6KYOyyel303sWsfKV1grdPn8L-4nD9apUPsxr3MKIxM=.9a1a54c3-1477-4b82-88ea-c8bbd7e4dccd@github.com>
 <xCUuqJFycvKYK1FO3wKXF3K6gVK_a3oJtQ9X19pD9UM=.ae4b91e5-6d53-47d5-bd20-48e013369769@github.com>
Message-ID: <uKsS7nGlaS63yytQaxrkrNvvtWrjAd8ZoOSW3d-5oXE=.c8328024-dad0-45ad-9184-c9ca917cb6a6@github.com>

On Fri, 17 Feb 2023 18:20:32 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> src/java.management/share/classes/javax/management/ObjectName.java line 2026:
>> 
>>> 2024:             // This ObjectName is the pattern
>>> 2025:             // The other ObjectName is the string.
>>> 2026:             if (useOptimized)
>> 
>> 2026 and 2031 I was referring to with the nit about if and { }
>
>> 2026 and 2031 I was referring to with the nit about if and { }
> 
> Hi @kevinjwalls ! Thank you for review.
> The braces are added

Thanks!

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

PR: https://git.openjdk.org/jdk/pull/11758

From pchilanomate at openjdk.org  Fri Feb 17 19:56:56 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 17 Feb 2023 19:56:56 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v7]
In-Reply-To: <VPSC0DZKmvFOhqNMZZCqrUQQit2MeWrdRUTcMhrXmeo=.709e6b36-14cf-4462-9c66-3b24c1ab47b2@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <TNrb8vxGZPuUTAEkOXiXdqMcEqIfLzFdOafFetj4hNw=.a76c17fa-13a7-49e3-b748-d6c75f0fbecb@github.com>
 <VPSC0DZKmvFOhqNMZZCqrUQQit2MeWrdRUTcMhrXmeo=.709e6b36-14cf-4462-9c66-3b24c1ab47b2@github.com>
Message-ID: <Wep2mJvQiqmJcjGVpeqajK6bBOdpFK_4uvpiYLJwUoc=.ed71368a-55d0-4a7c-8d71-02465ec4aedf@github.com>

On Fri, 17 Feb 2023 17:28:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thanks for dropping is_bound_vthread, I think it's much better now. What would you think about changing it to test the thread type is_a vmClasses::BaseVirtualThread_klass() so the VM doesn't need to know about ThreadBuilders$BoundVirtualThread.
>
Yes, we could do that. Although I think that checking for BoundVirtualThread_klass is more descriptive of what we are trying to do and will be less confusing when reading the code. How about checking for `(!VMContinuations && x->is_a(vmClasses::BaseVirtualThread_klass()))`?

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

PR: https://git.openjdk.org/jdk/pull/12512

From sspitsyn at openjdk.org  Fri Feb 17 21:48:32 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Feb 2023 21:48:32 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v7]
In-Reply-To: <TNrb8vxGZPuUTAEkOXiXdqMcEqIfLzFdOafFetj4hNw=.a76c17fa-13a7-49e3-b748-d6c75f0fbecb@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <TNrb8vxGZPuUTAEkOXiXdqMcEqIfLzFdOafFetj4hNw=.a76c17fa-13a7-49e3-b748-d6c75f0fbecb@github.com>
Message-ID: <uDW8FER0O7hj4vRA8rYkHt-evB7PVV0GorGS1FNqW58=.ceac502f-de09-46e9-bb23-4c28209e240a@github.com>

On Fri, 17 Feb 2023 16:07:50 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
>> 
>> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
>> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
>> 
>> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
>> 
>> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
>> 
>> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   s/passed/status

Updates look good to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12512

From sspitsyn at openjdk.org  Fri Feb 17 21:52:33 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Feb 2023 21:52:33 GMT
Subject: RFR: 8302615: make JVMTI thread cpu time functions optional for
 virtual threads
In-Reply-To: <N8X4H8wU3Yu8FFzwl9wSxTj6J8P8fM9JfutH1lh6uD0=.9983bb99-b5dc-4d08-8af5-7863a9c2bda1@github.com>
References: <N8X4H8wU3Yu8FFzwl9wSxTj6J8P8fM9JfutH1lh6uD0=.9983bb99-b5dc-4d08-8af5-7863a9c2bda1@github.com>
Message-ID: <U8ANDOYiVkR-4N8CE2vph5tJoZxIWWrFaN83MxdZNt4=.a216e075-77ad-48ad-9331-1246b6012a0f@github.com>

On Thu, 16 Feb 2023 18:05:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a minor JVM TI spec update for two timer functions `GetCurrentThreadCpuTime` and `GetThreadCpuTime` to allow implementations to support virtual threads.
> 
> The CSR is:
> [JDK-8302616](https://bugs.openjdk.org/browse/JDK-8302616): make JVMTI thread cpu time functions optional for virtual threads
> 
> No testing is needed.

I will integrate this as a trivial fix.

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

PR: https://git.openjdk.org/jdk/pull/12604

From sspitsyn at openjdk.org  Fri Feb 17 21:52:34 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Feb 2023 21:52:34 GMT
Subject: Integrated: 8302615: make JVMTI thread cpu time functions optional for
 virtual threads
In-Reply-To: <N8X4H8wU3Yu8FFzwl9wSxTj6J8P8fM9JfutH1lh6uD0=.9983bb99-b5dc-4d08-8af5-7863a9c2bda1@github.com>
References: <N8X4H8wU3Yu8FFzwl9wSxTj6J8P8fM9JfutH1lh6uD0=.9983bb99-b5dc-4d08-8af5-7863a9c2bda1@github.com>
Message-ID: <BhiXy3JI7VUwalRvPRSklaDL0ppheQAxPnZQNQGGnis=.39c8e180-cee5-4eac-81b7-1e8664309867@github.com>

On Thu, 16 Feb 2023 18:05:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a minor JVM TI spec update for two timer functions `GetCurrentThreadCpuTime` and `GetThreadCpuTime` to allow implementations to support virtual threads.
> 
> The CSR is:
> [JDK-8302616](https://bugs.openjdk.org/browse/JDK-8302616): make JVMTI thread cpu time functions optional for virtual threads
> 
> No testing is needed.

This pull request has now been integrated.

Changeset: 6b082fb3
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6b082fb3c658524905a9a7b33dcb58e375c95c1b
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8302615: make JVMTI thread cpu time functions optional for virtual threads

Reviewed-by: alanb

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

PR: https://git.openjdk.org/jdk/pull/12604

From sspitsyn at openjdk.org  Sat Feb 18 01:36:24 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 18 Feb 2023 01:36:24 GMT
Subject: RFR: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint
In-Reply-To: <gFGpHzd_o6pcpIkiQCVx8uO52pyMPh_7JahYqbYyBQ4=.14aba3b6-380a-4ed0-96b8-1ea2e5daa402@github.com>
References: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
 <gFGpHzd_o6pcpIkiQCVx8uO52pyMPh_7JahYqbYyBQ4=.14aba3b6-380a-4ed0-96b8-1ea2e5daa402@github.com>
Message-ID: <VDeE-82YtUFuxO4b2Ox2ccoeYubS4Ht64cuZV5j9_eY=.23bbabc2-3c40-49d4-bb94-670d725d9c92@github.com>

On Fri, 17 Feb 2023 05:09:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The rank of JvmtiVTMSTransition_lock is better to be safepoint instead of nosafepoint.
>> The fix includes removal of the function `check_vthread_and_suspend_at_safepoint` which is not needed anymore.
>> 
>> Testing:
>> mach5 jobs are in progress:
>>  Kitchensink, tiers1-6 (all JVMTI, JDWP, JDI and JDB tests have to be included)
>
> src/hotspot/share/prims/jvmtiEnv.cpp line 952:
> 
>> 950:     }
>> 951:     // protect thread_oop as a safepoint can be reached in disabler destructor
>> 952:     self_tobj = Handle(current, thread_oop);
> 
> If you move this after line 953 then you can delete line 932 and just have:
> 
> Handle self_tobj = Handle(current, thread_oop);

Thank you for looking at this PR, David!
Please, note a disabler at L938. A safepont can be reached in its destructor.
Also, see the comment at L952:

 937   {
 938     JvmtiVTMSTransitionDisabler disabler(true);
 939     ThreadsListHandle tlh(current);
 940 
 941     err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
 942     if (err != JVMTI_ERROR_NONE) {
 943       return err;
 944     }
 945 
 946     // Do not use JvmtiVTMSTransitionDisabler in context of self suspend to avoid deadlocks.
 947     if (java_thread != current) {
 948       err = suspend_thread(thread_oop, java_thread, /* single_suspend */ true, nullptr);
 949       return err;
 950     }
 951     // protect thread_oop as a safepoint can be reached in disabler destructor
 952     self_tobj = Handle(current, thread_oop);
 953   }

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

PR: https://git.openjdk.org/jdk/pull/12550

From sspitsyn at openjdk.org  Sat Feb 18 01:36:25 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 18 Feb 2023 01:36:25 GMT
Subject: RFR: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint
In-Reply-To: <VDeE-82YtUFuxO4b2Ox2ccoeYubS4Ht64cuZV5j9_eY=.23bbabc2-3c40-49d4-bb94-670d725d9c92@github.com>
References: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
 <gFGpHzd_o6pcpIkiQCVx8uO52pyMPh_7JahYqbYyBQ4=.14aba3b6-380a-4ed0-96b8-1ea2e5daa402@github.com>
 <VDeE-82YtUFuxO4b2Ox2ccoeYubS4Ht64cuZV5j9_eY=.23bbabc2-3c40-49d4-bb94-670d725d9c92@github.com>
Message-ID: <jzO_AvIiw-vnay97MBaYCvoFZBlzYu6fUUhfv8OIYPw=.0dffd1f2-7187-42b8-9b9d-881babdf74da@github.com>

On Sat, 18 Feb 2023 01:30:27 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnv.cpp line 952:
>> 
>>> 950:     }
>>> 951:     // protect thread_oop as a safepoint can be reached in disabler destructor
>>> 952:     self_tobj = Handle(current, thread_oop);
>> 
>> If you move this after line 953 then you can delete line 932 and just have:
>> 
>> Handle self_tobj = Handle(current, thread_oop);
>
> Thank you for looking at this PR, David!
> Please, note a disabler at L938. A safepont can be reached in its destructor.
> Also, see the comment at L952:
> 
>  937   {
>  938     JvmtiVTMSTransitionDisabler disabler(true);
>  939     ThreadsListHandle tlh(current);
>  940 
>  941     err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
>  942     if (err != JVMTI_ERROR_NONE) {
>  943       return err;
>  944     }
>  945 
>  946     // Do not use JvmtiVTMSTransitionDisabler in context of self suspend to avoid deadlocks.
>  947     if (java_thread != current) {
>  948       err = suspend_thread(thread_oop, java_thread, /* single_suspend */ true, nullptr);
>  949       return err;
>  950     }
>  951     // protect thread_oop as a safepoint can be reached in disabler destructor
>  952     self_tobj = Handle(current, thread_oop);
>  953   }

> it means there are now many places that can block for safepoints that previously wouldn't and it is very to hard to tell if that is okay or not.

We partially rely on testing and good test coverage here.

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

PR: https://git.openjdk.org/jdk/pull/12550

From stuefe at openjdk.org  Sat Feb 18 06:53:09 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 18 Feb 2023 06:53:09 GMT
Subject: RFR: JDK-8302812: JDK-8302455 broke ClassLoaderStatsTest on 32-bit
Message-ID: <oj9nAfqTtexfBp56kSdn3X32zQMGYQkK9bdysm3GmnI=.416f0294-b61b-43a1-981d-73de8f7156eb@github.com>

Trivial fix for a trivial problem. CCS=off variant of test needs to be excluded on 32-bit.

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

Commit messages:
 - JDK-8302812-JDK-8302455-broke-ClassLoaderStatsTest-on-32-bit

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

PR: https://git.openjdk.org/jdk/pull/12631

From alanb at openjdk.org  Sat Feb 18 07:59:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 18 Feb 2023 07:59:26 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v7]
In-Reply-To: <TNrb8vxGZPuUTAEkOXiXdqMcEqIfLzFdOafFetj4hNw=.a76c17fa-13a7-49e3-b748-d6c75f0fbecb@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <TNrb8vxGZPuUTAEkOXiXdqMcEqIfLzFdOafFetj4hNw=.a76c17fa-13a7-49e3-b748-d6c75f0fbecb@github.com>
Message-ID: <RCyEios5MyjMM_IFm8wdh4ihlzMlkUKv0HkkwjZLNvU=.12bff31b-6f50-4a48-821f-4f0577fb3e5b@github.com>

On Fri, 17 Feb 2023 16:07:50 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
>> 
>> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
>> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
>> 
>> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
>> 
>> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
>> 
>> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   s/passed/status

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12512

From alanb at openjdk.org  Sat Feb 18 07:59:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 18 Feb 2023 07:59:29 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v7]
In-Reply-To: <Wep2mJvQiqmJcjGVpeqajK6bBOdpFK_4uvpiYLJwUoc=.ed71368a-55d0-4a7c-8d71-02465ec4aedf@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <TNrb8vxGZPuUTAEkOXiXdqMcEqIfLzFdOafFetj4hNw=.a76c17fa-13a7-49e3-b748-d6c75f0fbecb@github.com>
 <VPSC0DZKmvFOhqNMZZCqrUQQit2MeWrdRUTcMhrXmeo=.709e6b36-14cf-4462-9c66-3b24c1ab47b2@github.com>
 <Wep2mJvQiqmJcjGVpeqajK6bBOdpFK_4uvpiYLJwUoc=.ed71368a-55d0-4a7c-8d71-02465ec4aedf@github.com>
Message-ID: <ak-STJeftz-SOTB6AJ_-yaZhHYsUAPMZRmx3c-HEc2s=.a77cab50-a0af-4123-bc0d-1fda1ddbdb8e@github.com>

On Fri, 17 Feb 2023 19:54:08 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Yes, we could do that. Although I think that checking for BoundVirtualThread_klass is more descriptive of what we are trying to do and will be less confusing when reading the code. How about checking for `(!VMContinuations && x->is_a(vmClasses::BaseVirtualThread_klass()))`?

We can go with what you have for now and re-visit again if it becomes an issue. The main thing I had hoped is that the VM won't get too coupled to BoundVirtualThread as that may move or be refactored soon.

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

PR: https://git.openjdk.org/jdk/pull/12512

From dcubed at openjdk.org  Sat Feb 18 14:26:23 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 18 Feb 2023 14:26:23 GMT
Subject: RFR: JDK-8302812: JDK-8302455 broke ClassLoaderStatsTest on 32-bit
In-Reply-To: <oj9nAfqTtexfBp56kSdn3X32zQMGYQkK9bdysm3GmnI=.416f0294-b61b-43a1-981d-73de8f7156eb@github.com>
References: <oj9nAfqTtexfBp56kSdn3X32zQMGYQkK9bdysm3GmnI=.416f0294-b61b-43a1-981d-73de8f7156eb@github.com>
Message-ID: <At3N-TVrHjghgX2kAHsRnhNpZpJwzufsEkz38q6s_T4=.d4c9b92a-0795-4be7-b368-b91f660ecd38@github.com>

On Sat, 18 Feb 2023 06:46:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial fix for a trivial problem. CCS=off variant of test needs to be excluded on 32-bit.

Thumbs up. I agree this is a trivial fix.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12631

From stuefe at openjdk.org  Sat Feb 18 14:54:30 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 18 Feb 2023 14:54:30 GMT
Subject: RFR: JDK-8302812: JDK-8302455 broke ClassLoaderStatsTest on 32-bit
In-Reply-To: <At3N-TVrHjghgX2kAHsRnhNpZpJwzufsEkz38q6s_T4=.d4c9b92a-0795-4be7-b368-b91f660ecd38@github.com>
References: <oj9nAfqTtexfBp56kSdn3X32zQMGYQkK9bdysm3GmnI=.416f0294-b61b-43a1-981d-73de8f7156eb@github.com>
 <At3N-TVrHjghgX2kAHsRnhNpZpJwzufsEkz38q6s_T4=.d4c9b92a-0795-4be7-b368-b91f660ecd38@github.com>
Message-ID: <7tsgEqAWV2UE5CyK3fAx_djAwuUflzirhPynfZ5eZwU=.a20834ec-1c17-40d8-8e5b-d3f6c40d289b@github.com>

On Sat, 18 Feb 2023 14:23:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Thumbs up. I agree this is a trivial fix.

Thanks Daniel.

s390 cross compile GHA error seems unrelated.

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

PR: https://git.openjdk.org/jdk/pull/12631

From stuefe at openjdk.org  Sat Feb 18 14:57:30 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 18 Feb 2023 14:57:30 GMT
Subject: Integrated: JDK-8302812: JDK-8302455 broke ClassLoaderStatsTest on
 32-bit
In-Reply-To: <oj9nAfqTtexfBp56kSdn3X32zQMGYQkK9bdysm3GmnI=.416f0294-b61b-43a1-981d-73de8f7156eb@github.com>
References: <oj9nAfqTtexfBp56kSdn3X32zQMGYQkK9bdysm3GmnI=.416f0294-b61b-43a1-981d-73de8f7156eb@github.com>
Message-ID: <l60M9wLfcdRAu6cHNiwcq12pnPcS4rraCTPaZdmDy-U=.34e01822-5411-404b-8408-269834883d05@github.com>

On Sat, 18 Feb 2023 06:46:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial fix for a trivial problem. CCS=off variant of test needs to be excluded on 32-bit.

This pull request has now been integrated.

Changeset: 53be5dc4
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/53be5dc48604397fb26fd6e448679982aee19fee
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8302812: JDK-8302455 broke ClassLoaderStatsTest on 32-bit

Reviewed-by: dcubed

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

PR: https://git.openjdk.org/jdk/pull/12631

From duke at openjdk.org  Sun Feb 19 08:55:35 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Sun, 19 Feb 2023 08:55:35 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v3]
In-Reply-To: <ywdTEjngAhYV4gNTy0LyshW3TBVgmr2-j9gwQZcNjP0=.42d25a37-f574-46a8-99b8-971b01da9dcf@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <ywdTEjngAhYV4gNTy0LyshW3TBVgmr2-j9gwQZcNjP0=.42d25a37-f574-46a8-99b8-971b01da9dcf@github.com>
Message-ID: <9bvykV6KIxtCVdRfWa7l1gnKKw758542V6Oqe3Xs3uA=.60ddff5f-a561-4cca-884b-235ff4d2006f@github.com>

On Fri, 17 Feb 2023 14:47:56 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Extends the existing AsyncGetCallTrace test case and fixes the issue.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert previous change

Is this PR then ready?

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

PR: https://git.openjdk.org/jdk/pull/12535

From dholmes at openjdk.org  Sun Feb 19 22:10:25 2023
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 19 Feb 2023 22:10:25 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v3]
In-Reply-To: <ywdTEjngAhYV4gNTy0LyshW3TBVgmr2-j9gwQZcNjP0=.42d25a37-f574-46a8-99b8-971b01da9dcf@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <ywdTEjngAhYV4gNTy0LyshW3TBVgmr2-j9gwQZcNjP0=.42d25a37-f574-46a8-99b8-971b01da9dcf@github.com>
Message-ID: <JDxtV4W6FmVUT6FjoUru1kq1VdYRtLnrxHfWmhNwSgA=.a0fd3b2a-d792-46b2-93bc-d6e004a9b84e@github.com>

On Fri, 17 Feb 2023 14:47:56 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Extends the existing AsyncGetCallTrace test case and fixes the issue.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert previous change

I'm somewhat concerned that the code doesn't seem to have a clear notion of exactly how `unextended_sp` relates to `sp` in general. I would still be concerned that the relaxation may cause a bad value to be considered safe and so lead to a crash. But I guess we will just have to address that if it arises.
Thanks for all the due-diligence on this one.

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

PR: https://git.openjdk.org/jdk/pull/12535

From abakhtin at openjdk.org  Mon Feb 20 08:13:27 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Mon, 20 Feb 2023 08:13:27 GMT
Subject: RFR: 8299234: JMX Repository.query performance [v5]
In-Reply-To: <6KYOyyel303sWsfKV1grdPn8L-4nD9apUPsxr3MKIxM=.9a1a54c3-1477-4b82-88ea-c8bbd7e4dccd@github.com>
References: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
 <YH-y2lwy0IU4s9Ri6vuNwwgpZpJzFIQW_ttuE8KkFFs=.ccabc1f9-d27d-469a-847b-69c4e882d7e6@github.com>
 <6KYOyyel303sWsfKV1grdPn8L-4nD9apUPsxr3MKIxM=.9a1a54c3-1477-4b82-88ea-c8bbd7e4dccd@github.com>
Message-ID: <jTq3FnMa-mWlynveRvP50l24iA4HwMMF6Pfdi0tE_Ko=.cbe8ce57-ef4b-4fc5-9858-dd354871ce0c@github.com>

On Fri, 17 Feb 2023 17:33:19 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimize ObjectName.matchDomains
>
> Yes, I think it looks good.
> I looked a while ago but it was somewhat unfamiliar so was glad of Daniel's input.
> 
> It's a bit of a style nit but our ifs always use brackets, so I miss that in ObjectName.matchDomains(), particularly as the statements are multi-line.
> 
> I tested the change with test/jdk/javax/management/ and everything still passes.
> The repo is somewhat behind, but these changes have no merge problems with the latest. I took these changes into a latest jdk repo to build and test.

@kevinjwalls, Thank you very much for reviewing.
@sspitsyn, the patch is approved by Kevin but unfortunately, he is not a reviewer in JDK project. Could you please approve it or ask somebody from the serviceability group? Thank you in advance.

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

PR: https://git.openjdk.org/jdk/pull/11758

From rrich at openjdk.org  Mon Feb 20 08:49:27 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 20 Feb 2023 08:49:27 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v3]
In-Reply-To: <ywdTEjngAhYV4gNTy0LyshW3TBVgmr2-j9gwQZcNjP0=.42d25a37-f574-46a8-99b8-971b01da9dcf@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <ywdTEjngAhYV4gNTy0LyshW3TBVgmr2-j9gwQZcNjP0=.42d25a37-f574-46a8-99b8-971b01da9dcf@github.com>
Message-ID: <8kW6oyPa9PkTAOKsU71YmN4zmMi5VSrHlOAE1frAazQ=.cce2850f-4ef3-44c9-85f8-b056fe632e56@github.com>

On Fri, 17 Feb 2023 14:47:56 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Extends the existing AsyncGetCallTrace test case and fixes the issue.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert previous change

src/hotspot/cpu/x86/frame_x86.cpp line 75:

> 73:   // interpreted -> interpreted calls that go through a method handle linker,
> 74:   // since those pop the last argument (the appendix) from the stack.
> 75:   if (!thread->is_in_full_stack_checked(unextended_sp)) {

The condition can remain stricter. The following should work too. Could you please check?
Suggestion:

  if (!thread->is_in_stack_range_incl(unextended_sp + Interpreter::stackElementSize, sp)) {

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

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Mon Feb 20 09:03:29 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Mon, 20 Feb 2023 09:03:29 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v3]
In-Reply-To: <8kW6oyPa9PkTAOKsU71YmN4zmMi5VSrHlOAE1frAazQ=.cce2850f-4ef3-44c9-85f8-b056fe632e56@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <ywdTEjngAhYV4gNTy0LyshW3TBVgmr2-j9gwQZcNjP0=.42d25a37-f574-46a8-99b8-971b01da9dcf@github.com>
 <8kW6oyPa9PkTAOKsU71YmN4zmMi5VSrHlOAE1frAazQ=.cce2850f-4ef3-44c9-85f8-b056fe632e56@github.com>
Message-ID: <zD139IMZT_swoVqQEVK_8Aqh09NEFFFWxsD1c5lpxYQ=.287f5589-4364-4ae2-8cd7-ce6b14604ae9@github.com>

On Mon, 20 Feb 2023 08:46:43 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert previous change
>
> src/hotspot/cpu/x86/frame_x86.cpp line 75:
> 
>> 73:   // interpreted -> interpreted calls that go through a method handle linker,
>> 74:   // since those pop the last argument (the appendix) from the stack.
>> 75:   if (!thread->is_in_full_stack_checked(unextended_sp)) {
> 
> The condition can remain stricter. The following should work too. Could you please check?
> Suggestion:
> 
>   if (!thread->is_in_stack_range_incl(unextended_sp + Interpreter::stackElementSize, sp)) {

The sanity test worked :)

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

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Mon Feb 20 09:09:48 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Mon, 20 Feb 2023 09:09:48 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v4]
In-Reply-To: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
Message-ID: <guZT9D_9Gjij2h7QtXvLqczjsVget5CpoSrgzNbARu8=.1b235537-3f1e-4eb6-b9f3-b4568cc2cac7@github.com>

> Extends the existing AsyncGetCallTrace test case and fixes the issue.

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

  Improve condition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12535/files
  - new: https://git.openjdk.org/jdk/pull/12535/files/da706d3b..b652c2e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12535&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12535&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Mon Feb 20 09:09:49 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Mon, 20 Feb 2023 09:09:49 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v3]
In-Reply-To: <zD139IMZT_swoVqQEVK_8Aqh09NEFFFWxsD1c5lpxYQ=.287f5589-4364-4ae2-8cd7-ce6b14604ae9@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <ywdTEjngAhYV4gNTy0LyshW3TBVgmr2-j9gwQZcNjP0=.42d25a37-f574-46a8-99b8-971b01da9dcf@github.com>
 <8kW6oyPa9PkTAOKsU71YmN4zmMi5VSrHlOAE1frAazQ=.cce2850f-4ef3-44c9-85f8-b056fe632e56@github.com>
 <zD139IMZT_swoVqQEVK_8Aqh09NEFFFWxsD1c5lpxYQ=.287f5589-4364-4ae2-8cd7-ce6b14604ae9@github.com>
Message-ID: <0OC5hKoRVRzWFcZ0vrcJyxKWfEqAueAGREA2YLuG9wM=.08b446fe-88f7-42c9-8406-2403f4835c6a@github.com>

On Mon, 20 Feb 2023 09:00:28 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/frame_x86.cpp line 75:
>> 
>>> 73:   // interpreted -> interpreted calls that go through a method handle linker,
>>> 74:   // since those pop the last argument (the appendix) from the stack.
>>> 75:   if (!thread->is_in_full_stack_checked(unextended_sp)) {
>> 
>> The condition can remain stricter. The following should work too. Could you please check?
>> Suggestion:
>> 
>>   if (!thread->is_in_stack_range_incl(unextended_sp + Interpreter::stackElementSize, sp)) {
>
> The sanity test worked :)

... and no regression in the other serviceability tests.

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

PR: https://git.openjdk.org/jdk/pull/12535

From rrich at openjdk.org  Mon Feb 20 09:11:27 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 20 Feb 2023 09:11:27 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v3]
In-Reply-To: <0OC5hKoRVRzWFcZ0vrcJyxKWfEqAueAGREA2YLuG9wM=.08b446fe-88f7-42c9-8406-2403f4835c6a@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <ywdTEjngAhYV4gNTy0LyshW3TBVgmr2-j9gwQZcNjP0=.42d25a37-f574-46a8-99b8-971b01da9dcf@github.com>
 <8kW6oyPa9PkTAOKsU71YmN4zmMi5VSrHlOAE1frAazQ=.cce2850f-4ef3-44c9-85f8-b056fe632e56@github.com>
 <zD139IMZT_swoVqQEVK_8Aqh09NEFFFWxsD1c5lpxYQ=.287f5589-4364-4ae2-8cd7-ce6b14604ae9@github.com>
 <0OC5hKoRVRzWFcZ0vrcJyxKWfEqAueAGREA2YLuG9wM=.08b446fe-88f7-42c9-8406-2403f4835c6a@github.com>
Message-ID: <14-X_O88AjbgcUUxbfIXODXbmDDjFPZYABHVn4aq_vs=.866e2f92-dda3-421d-aad3-30831c51c748@github.com>

On Mon, 20 Feb 2023 09:04:39 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> The sanity test worked :)
>
> ... and no regression in the other serviceability tests.

Probably it's better to adapt the limit though (sorry).
Problem with this version is that it allows `unextended_sp` outside the address range reserved for the stack. Let's see what other reviewers think.
Suggestion:

  if (!thread->is_in_stack_range_incl(unextended_sp, sp - Interpreter::stackElementSize)) {

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

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Mon Feb 20 09:14:25 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Mon, 20 Feb 2023 09:14:25 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v3]
In-Reply-To: <14-X_O88AjbgcUUxbfIXODXbmDDjFPZYABHVn4aq_vs=.866e2f92-dda3-421d-aad3-30831c51c748@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <ywdTEjngAhYV4gNTy0LyshW3TBVgmr2-j9gwQZcNjP0=.42d25a37-f574-46a8-99b8-971b01da9dcf@github.com>
 <8kW6oyPa9PkTAOKsU71YmN4zmMi5VSrHlOAE1frAazQ=.cce2850f-4ef3-44c9-85f8-b056fe632e56@github.com>
 <zD139IMZT_swoVqQEVK_8Aqh09NEFFFWxsD1c5lpxYQ=.287f5589-4364-4ae2-8cd7-ce6b14604ae9@github.com>
 <0OC5hKoRVRzWFcZ0vrcJyxKWfEqAueAGREA2YLuG9wM=.08b446fe-88f7-42c9-8406-2403f4835c6a@github.com>
 <14-X_O88AjbgcUUxbfIXODXbmDDjFPZYABHVn4aq_vs=.866e2f92-dda3-421d-aad3-30831c51c748@github.com>
Message-ID: <D6TJLDaKUxlOvBNqRRowh0RhZ_tzfvxdT7WhzA8fg8s=.4ba83fbb-61aa-4e85-a11f-5785ea152665@github.com>

On Mon, 20 Feb 2023 09:08:59 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> ... and no regression in the other serviceability tests.
>
> Probably it's better to adapt the limit though (sorry).
> Problem with this version is that it allows `unextended_sp` outside the address range reserved for the stack. Let's see what other reviewers think.
> Suggestion:
> 
>   if (!thread->is_in_stack_range_incl(unextended_sp, sp - Interpreter::stackElementSize)) {

Good point, you're right. I could have recognized this myself.

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

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Mon Feb 20 09:18:46 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Mon, 20 Feb 2023 09:18:46 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v5]
In-Reply-To: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
Message-ID: <0Q8kPIrJXF4qROlS6u3dwT0zzO6wpezV4XkG_aiQ1uc=.ec15567a-3e9a-459d-a8aa-0fe188111bd6@github.com>

> Extends the existing AsyncGetCallTrace test case and fixes the issue.

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

  Improve condition again

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12535/files
  - new: https://git.openjdk.org/jdk/pull/12535/files/b652c2e5..cd85c6a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12535&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12535&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Mon Feb 20 09:18:48 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Mon, 20 Feb 2023 09:18:48 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v3]
In-Reply-To: <D6TJLDaKUxlOvBNqRRowh0RhZ_tzfvxdT7WhzA8fg8s=.4ba83fbb-61aa-4e85-a11f-5785ea152665@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <ywdTEjngAhYV4gNTy0LyshW3TBVgmr2-j9gwQZcNjP0=.42d25a37-f574-46a8-99b8-971b01da9dcf@github.com>
 <8kW6oyPa9PkTAOKsU71YmN4zmMi5VSrHlOAE1frAazQ=.cce2850f-4ef3-44c9-85f8-b056fe632e56@github.com>
 <zD139IMZT_swoVqQEVK_8Aqh09NEFFFWxsD1c5lpxYQ=.287f5589-4364-4ae2-8cd7-ce6b14604ae9@github.com>
 <0OC5hKoRVRzWFcZ0vrcJyxKWfEqAueAGREA2YLuG9wM=.08b446fe-88f7-42c9-8406-2403f4835c6a@github.com>
 <14-X_O88AjbgcUUxbfIXODXbmDDjFPZYABHVn4aq_vs=.866e2f92-dda3-421d-aad3-30831c51c748@github.com>
 <D6TJLDaKUxlOvBNqRRowh0RhZ_tzfvxdT7WhzA8fg8s=.4ba83fbb-61aa-4e85-a11f-5785ea152665@github.com>
Message-ID: <OVwcNtHpwLTsYqHwk7kZStQUr6b8qResZCwNsUYcdnQ=.711efdb3-998c-4e43-98b0-7f8cb904df76@github.com>

On Mon, 20 Feb 2023 09:11:38 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Probably it's better to adapt the limit though (sorry).
>> Problem with this version is that it allows `unextended_sp` outside the address range reserved for the stack. Let's see what other reviewers think.
>> Suggestion:
>> 
>>   if (!thread->is_in_stack_range_incl(unextended_sp, sp - Interpreter::stackElementSize)) {
>
> Good point, you're right. I could have recognized this myself.

Tests work as expected.

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

PR: https://git.openjdk.org/jdk/pull/12535

From sspitsyn at openjdk.org  Mon Feb 20 10:39:27 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 Feb 2023 10:39:27 GMT
Subject: RFR: 8299234: JMX Repository.query performance [v5]
In-Reply-To: <6KYOyyel303sWsfKV1grdPn8L-4nD9apUPsxr3MKIxM=.9a1a54c3-1477-4b82-88ea-c8bbd7e4dccd@github.com>
References: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
 <YH-y2lwy0IU4s9Ri6vuNwwgpZpJzFIQW_ttuE8KkFFs=.ccabc1f9-d27d-469a-847b-69c4e882d7e6@github.com>
 <6KYOyyel303sWsfKV1grdPn8L-4nD9apUPsxr3MKIxM=.9a1a54c3-1477-4b82-88ea-c8bbd7e4dccd@github.com>
Message-ID: <VxFteABM0gc4-M5v2cCMq2QPj-Klamumqx1I_ePeKts=.cb270299-3304-4208-9781-0cf0f5bf10ab@github.com>

On Fri, 17 Feb 2023 17:33:19 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimize ObjectName.matchDomains
>
> Yes, I think it looks good.
> I looked a while ago but it was somewhat unfamiliar so was glad of Daniel's input.
> 
> It's a bit of a style nit but our ifs always use brackets, so I miss that in ObjectName.matchDomains(), particularly as the statements are multi-line.
> 
> I tested the change with test/jdk/javax/management/ and everything still passes.
> The repo is somewhat behind, but these changes have no merge problems with the latest. I took these changes into a latest jdk repo to build and test.

> @kevinjwalls, Thank you very much for reviewing. @sspitsyn, the patch is approved by Kevin but unfortunately, he is not a reviewer in JDK project. Could you please approve it or ask somebody from the serviceability group? Thank you in advance.

Alexey, two reviews are normally required before integration in the Serviceability area.
I guess, you need to wait for review from Daniel Fuchs (an expert in this area) or someone else.

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

PR: https://git.openjdk.org/jdk/pull/11758

From jvernee at openjdk.org  Mon Feb 20 14:13:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 20 Feb 2023 14:13:27 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v5]
In-Reply-To: <0Q8kPIrJXF4qROlS6u3dwT0zzO6wpezV4XkG_aiQ1uc=.ec15567a-3e9a-459d-a8aa-0fe188111bd6@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <0Q8kPIrJXF4qROlS6u3dwT0zzO6wpezV4XkG_aiQ1uc=.ec15567a-3e9a-459d-a8aa-0fe188111bd6@github.com>
Message-ID: <Pq2Nx_-sw8ZXg9_-w_KRLtyzGBd8a5v5VsEfrwXOwEY=.1d1b2b12-600c-4f0e-8937-d593dd7e755b@github.com>

On Mon, 20 Feb 2023 09:18:46 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Extends the existing AsyncGetCallTrace test case and fixes the issue.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve condition again

The new check looks good to me. I think the only potential issue is in cases where `unextended_sp == sp` and `sp - Interpreter::stackElementSize` is somehow outside of the stack. But, since this is looking at a sender, it would mean that the current frame would definitely be outside of the stack, so I think we're good.

I'll submit tier 1-4 on our CI, and give a check mark when it comes back green.

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

PR: https://git.openjdk.org/jdk/pull/12535

From kevinw at openjdk.org  Mon Feb 20 15:24:10 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 20 Feb 2023 15:24:10 GMT
Subject: RFR: 8302870: More information needed from failures in vmTestbase
 ThreadUtils.waitThreadState
Message-ID: <IYTo6akU-Bsww0XBuhz-eMuOeQRxqvuAYz8dvdhlmPo=.d0cfddee-800e-48a2-a9d6-325b58293ef4@github.com>

Test update to make failures such as JDK-8076494 more informative.

Waiting for a thread to change state: give more time (to distinguish a real deadlock from some other delay), and log the thread stackframes when the expected state change is not observed.

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

Commit messages:
 - import tweak
 - 8302870: More information needed from failures in vmTestbase ThreadUtils.waitThreadState

Changes: https://git.openjdk.org/jdk/pull/12661/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12661&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302870
  Stats: 28 lines in 1 file changed: 23 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12661.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12661/head:pull/12661

PR: https://git.openjdk.org/jdk/pull/12661

From dfuchs at openjdk.org  Mon Feb 20 17:17:30 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 20 Feb 2023 17:17:30 GMT
Subject: RFR: 8299234: JMX Repository.query performance [v6]
In-Reply-To: <4tZW46OQSXdhDi_wQj134cV2c7uKEaxDdYMzv1NeRv8=.f3db00c4-2d8d-4bb0-8cf6-f528b0e85626@github.com>
References: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
 <4tZW46OQSXdhDi_wQj134cV2c7uKEaxDdYMzv1NeRv8=.f3db00c4-2d8d-4bb0-8cf6-f528b0e85626@github.com>
Message-ID: <lUM3Fu_gUgKUAsVjAx16yqa8FQhUMClqsP57c2ma-9Q=.35f64791-5d0c-499a-8841-35105e3328b9@github.com>

On Fri, 17 Feb 2023 18:25:10 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please find a patch to improve JMX Repository.query performance
>> 
>> Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles:
>> Before:
>> 
>> $ java test 1000000 1000000
>> Test PASSED in 8943169791 ns.
>> GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118
>> 
>> 
>> After:
>> 
>> $ java test 1000000 1000000
>> Test PASSED in 4808213917 ns.
>> GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53
>> 
>> Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation.
>> 
>> All javax/management jtreg tests passed successfully.
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add braces

This last version LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11758

From abakhtin at openjdk.org  Mon Feb 20 17:56:36 2023
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Mon, 20 Feb 2023 17:56:36 GMT
Subject: Integrated: 8299234: JMX Repository.query performance
In-Reply-To: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
References: <EqRxlqWX3U3hkJ0j0jd5bGsNmSvHCwLGtri72WTbKKw=.dc750454-40ae-4ebe-ba7e-af9cbaa5f5e3@github.com>
Message-ID: <6FzcsI0_PnDz9U_4wPmdW_kjSOD8EqzCipfHFUrxKsc=.a3d577ad-57dc-493f-8a5c-8f0325287bc0@github.com>

On Wed, 21 Dec 2022 18:50:52 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please find a patch to improve JMX Repository.query performance
> 
> Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles:
> Before:
> 
> $ java test 1000000 1000000
> Test PASSED in 8943169791 ns.
> GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118
> 
> 
> After:
> 
> $ java test 1000000 1000000
> Test PASSED in 4808213917 ns.
> GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53
> 
> Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation.
> 
> All javax/management jtreg tests passed successfully.

This pull request has now been integrated.

Changeset: 9a797228
Author:    Alexey Bakhtin <abakhtin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a797228f3576720196d5e3bf4b204a5e3f87376
Stats:     147 lines in 4 files changed: 19 ins; 115 del; 13 mod

8299234: JMX Repository.query performance

Reviewed-by: dfuchs, kevinw

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

PR: https://git.openjdk.org/jdk/pull/11758

From dholmes at openjdk.org  Mon Feb 20 22:39:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Feb 2023 22:39:28 GMT
Subject: RFR: 8302870: More information needed from failures in vmTestbase
 ThreadUtils.waitThreadState
In-Reply-To: <IYTo6akU-Bsww0XBuhz-eMuOeQRxqvuAYz8dvdhlmPo=.d0cfddee-800e-48a2-a9d6-325b58293ef4@github.com>
References: <IYTo6akU-Bsww0XBuhz-eMuOeQRxqvuAYz8dvdhlmPo=.d0cfddee-800e-48a2-a9d6-325b58293ef4@github.com>
Message-ID: <UhPnT5N-jBYu5osRGMdY2c3u7NPB6XKEj2-gRmHzl6I=.1c221583-fd4b-4fc4-a6e1-dc39f50f57f6@github.com>

On Mon, 20 Feb 2023 12:54:06 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test update to make failures such as JDK-8076494 more informative.
> 
> Waiting for a thread to change state: give more time (to distinguish a real deadlock from some other delay), and log the thread stackframes when the expected state change is not observed.

Approach is fine in principle but a few minor nits.

Thanks.

test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/ThreadUtils.java line 232:

> 230: 
> 231:         // Most uses of waitThreadState usually succeed without retries.
> 232:         // Sleep time increased to help avoid spurious failures.

"increased" doesn't mean anything outside this PR as you can't tell the value has changed.

test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/ThreadUtils.java line 239:

> 237:                 int retries = 0;
> 238:                 long ctime = System.currentTimeMillis();
> 239:                 long ctime2 = 0;

So ctime -> startTime; ctime2 -> elapsedTime ?

test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/ThreadUtils.java line 242:

> 240:                 while (thread.getState() != state) {
> 241:                         if (retries++ > waitThreadStateRetries) {
> 242:                             // Failed to see desired state, give info to help diagnose the isuse.

This file is using an indent of 8. Looks odd to use 4 for the modified code only. Maybe you could fix all the indents before integration?

test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/ThreadUtils.java line 251:

> 249:                         }
> 250:                         try {
> 251:                             Thread.sleep(waitThreadStateSleepTime);

This file is using an indent of 8

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12661

From dholmes at openjdk.org  Mon Feb 20 22:39:30 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Feb 2023 22:39:30 GMT
Subject: RFR: 8302870: More information needed from failures in vmTestbase
 ThreadUtils.waitThreadState
In-Reply-To: <UhPnT5N-jBYu5osRGMdY2c3u7NPB6XKEj2-gRmHzl6I=.1c221583-fd4b-4fc4-a6e1-dc39f50f57f6@github.com>
References: <IYTo6akU-Bsww0XBuhz-eMuOeQRxqvuAYz8dvdhlmPo=.d0cfddee-800e-48a2-a9d6-325b58293ef4@github.com>
 <UhPnT5N-jBYu5osRGMdY2c3u7NPB6XKEj2-gRmHzl6I=.1c221583-fd4b-4fc4-a6e1-dc39f50f57f6@github.com>
Message-ID: <qFZ_c6SaC-KnAvuuMhjjpY4b51122FJroMFf3oHOp4o=.4ea8622c-0e1e-48ac-930d-0aa17a29e775@github.com>

On Mon, 20 Feb 2023 22:30:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Test update to make failures such as JDK-8076494 more informative.
>> 
>> Waiting for a thread to change state: give more time (to distinguish a real deadlock from some other delay), and log the thread stackframes when the expected state change is not observed.
>
> test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/ThreadUtils.java line 232:
> 
>> 230: 
>> 231:         // Most uses of waitThreadState usually succeed without retries.
>> 232:         // Sleep time increased to help avoid spurious failures.
> 
> "increased" doesn't mean anything outside this PR as you can't tell the value has changed.

Also any comment on sleep time belongs after line 233.

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

PR: https://git.openjdk.org/jdk/pull/12661

From dholmes at openjdk.org  Tue Feb 21 00:50:24 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Feb 2023 00:50:24 GMT
Subject: RFR: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint
In-Reply-To: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
References: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
Message-ID: <dRDy8N6ih06kb6MygUzoQLE3HMRE7cHM0tWpnWwa_CY=.f3779093-6755-45a7-9262-320e912bb440@github.com>

On Tue, 14 Feb 2023 05:37:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The rank of JvmtiVTMSTransition_lock is better to be safepoint instead of nosafepoint.
> The fix includes removal of the function `check_vthread_and_suspend_at_safepoint` which is not needed anymore.
> 
> Testing:
> mach5 jobs are in progress:
>  Kitchensink, tiers1-6 (all JVMTI, JDWP, JDI and JDB tests have to be included)

Seems quite reasonable.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12550

From dholmes at openjdk.org  Tue Feb 21 00:50:25 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Feb 2023 00:50:25 GMT
Subject: RFR: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint
In-Reply-To: <jzO_AvIiw-vnay97MBaYCvoFZBlzYu6fUUhfv8OIYPw=.0dffd1f2-7187-42b8-9b9d-881babdf74da@github.com>
References: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
 <gFGpHzd_o6pcpIkiQCVx8uO52pyMPh_7JahYqbYyBQ4=.14aba3b6-380a-4ed0-96b8-1ea2e5daa402@github.com>
 <VDeE-82YtUFuxO4b2Ox2ccoeYubS4Ht64cuZV5j9_eY=.23bbabc2-3c40-49d4-bb94-670d725d9c92@github.com>
 <jzO_AvIiw-vnay97MBaYCvoFZBlzYu6fUUhfv8OIYPw=.0dffd1f2-7187-42b8-9b9d-881babdf74da@github.com>
Message-ID: <ucWhjT4geUZeq59n_TFTuMh1dgkh6RCwk6q00rTkCHM=.fdf45490-8391-4d32-8745-9a45b34cfeac@github.com>

On Sat, 18 Feb 2023 01:33:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Thank you for looking at this PR, David!
>> Please, note a disabler at L938. A safepont can be reached in its destructor.
>> Also, see the comment at L952:
>> 
>>  937   {
>>  938     JvmtiVTMSTransitionDisabler disabler(true);
>>  939     ThreadsListHandle tlh(current);
>>  940 
>>  941     err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
>>  942     if (err != JVMTI_ERROR_NONE) {
>>  943       return err;
>>  944     }
>>  945 
>>  946     // Do not use JvmtiVTMSTransitionDisabler in context of self suspend to avoid deadlocks.
>>  947     if (java_thread != current) {
>>  948       err = suspend_thread(thread_oop, java_thread, /* single_suspend */ true, nullptr);
>>  949       return err;
>>  950     }
>>  951     // protect thread_oop as a safepoint can be reached in disabler destructor
>>  952     self_tobj = Handle(current, thread_oop);
>>  953   }
>
>> it means there are now many places that can block for safepoints that previously wouldn't and it is very to hard to tell if that is okay or not.
> 
> We partially rely on testing and good test coverage here.

Okay we can see how this goes.

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

PR: https://git.openjdk.org/jdk/pull/12550

From dholmes at openjdk.org  Tue Feb 21 01:20:27 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Feb 2023 01:20:27 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v5]
In-Reply-To: <0Q8kPIrJXF4qROlS6u3dwT0zzO6wpezV4XkG_aiQ1uc=.ec15567a-3e9a-459d-a8aa-0fe188111bd6@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <0Q8kPIrJXF4qROlS6u3dwT0zzO6wpezV4XkG_aiQ1uc=.ec15567a-3e9a-459d-a8aa-0fe188111bd6@github.com>
Message-ID: <XbFPiVU3-37IFzrVmudhE7omMRLjFWhyG9wsNJdzqgk=.1bcf4df8-75b5-4a08-980c-167fed2ef0ba@github.com>

On Mon, 20 Feb 2023 09:18:46 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Extends the existing AsyncGetCallTrace test case and fixes the issue.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve condition again

The latest version seems a more conservative constraint, so as long as that fixes things it seems good to me. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12535

From rrich at openjdk.org  Tue Feb 21 07:15:28 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 21 Feb 2023 07:15:28 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v5]
In-Reply-To: <0Q8kPIrJXF4qROlS6u3dwT0zzO6wpezV4XkG_aiQ1uc=.ec15567a-3e9a-459d-a8aa-0fe188111bd6@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <0Q8kPIrJXF4qROlS6u3dwT0zzO6wpezV4XkG_aiQ1uc=.ec15567a-3e9a-459d-a8aa-0fe188111bd6@github.com>
Message-ID: <S6GcPDMr4qenG3umYc68QcPVRdhoDmlE6F_7SihFbfc=.5c32a59b-7c9c-4e71-85a0-be4dc49dcd14@github.com>

On Mon, 20 Feb 2023 09:18:46 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Extends the existing AsyncGetCallTrace test case and fixes the issue.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve condition again

Looks good to me.
Richard.

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

Marked as reviewed by rrich (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Tue Feb 21 08:58:50 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Tue, 21 Feb 2023 08:58:50 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v6]
In-Reply-To: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
Message-ID: <ZExSIuGxZu1gYcEmsVBLweVtBIfLerE0hJYQ985ersc=.a59975fc-ce00-41d3-b05c-24b8e646bb41@github.com>

> Extends the existing AsyncGetCallTrace test case and fixes the issue.

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

  Update full name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12535/files
  - new: https://git.openjdk.org/jdk/pull/12535/files/cd85c6a9..42bdfd8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12535&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12535&range=04-05

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12535.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12535/head:pull/12535

PR: https://git.openjdk.org/jdk/pull/12535

From kevinw at openjdk.org  Tue Feb 21 09:09:43 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 21 Feb 2023 09:09:43 GMT
Subject: RFR: 8302870: More information needed from failures in vmTestbase
 ThreadUtils.waitThreadState [v2]
In-Reply-To: <IYTo6akU-Bsww0XBuhz-eMuOeQRxqvuAYz8dvdhlmPo=.d0cfddee-800e-48a2-a9d6-325b58293ef4@github.com>
References: <IYTo6akU-Bsww0XBuhz-eMuOeQRxqvuAYz8dvdhlmPo=.d0cfddee-800e-48a2-a9d6-325b58293ef4@github.com>
Message-ID: <d5No9g4MVR8yemimu0TwtYSK0tt2uqKh88jjerkAGo0=.12d72e59-f5af-4057-903a-9eb7807e56f9@github.com>

> Test update to make failures such as JDK-8076494 more informative.
> 
> Waiting for a thread to change state: give more time (to distinguish a real deadlock from some other delay), and log the thread stackframes when the expected state change is not observed.

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

  nits

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12661/files
  - new: https://git.openjdk.org/jdk/pull/12661/files/6e930abf..7e45ff0e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12661&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12661&range=00-01

  Stats: 18 lines in 1 file changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/12661.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12661/head:pull/12661

PR: https://git.openjdk.org/jdk/pull/12661

From kevinw at openjdk.org  Tue Feb 21 09:17:26 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 21 Feb 2023 09:17:26 GMT
Subject: RFR: 8302870: More information needed from failures in vmTestbase
 ThreadUtils.waitThreadState [v2]
In-Reply-To: <d5No9g4MVR8yemimu0TwtYSK0tt2uqKh88jjerkAGo0=.12d72e59-f5af-4057-903a-9eb7807e56f9@github.com>
References: <IYTo6akU-Bsww0XBuhz-eMuOeQRxqvuAYz8dvdhlmPo=.d0cfddee-800e-48a2-a9d6-325b58293ef4@github.com>
 <d5No9g4MVR8yemimu0TwtYSK0tt2uqKh88jjerkAGo0=.12d72e59-f5af-4057-903a-9eb7807e56f9@github.com>
Message-ID: <SRiV9Qndat7TI9lBUmkpq672c1mi3GXLdtaZ2BB6bSM=.231754c9-3b7f-4c5a-b7b2-44c84600f0f3@github.com>

On Tue, 21 Feb 2023 09:09:43 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Test update to make failures such as JDK-8076494 more informative.
>> 
>> Waiting for a thread to change state: give more time (to distinguish a real deadlock from some other delay), and log the thread stackframes when the expected state change is not observed.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nits

OK thanks David, nits taken care of I think.  (I'm not falling for the trap of changing all the indenting so nobody can see from the diff what I'm changing here, so I suppressed my instincts and used 8 spaces.)

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

PR: https://git.openjdk.org/jdk/pull/12661

From sspitsyn at openjdk.org  Tue Feb 21 09:31:26 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Feb 2023 09:31:26 GMT
Subject: RFR: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint
In-Reply-To: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
References: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
Message-ID: <IcmOKOwLGmU9SQhruhsvPLq81yYbb6aj960p-EOXn_U=.d90f0b85-768a-46bb-9626-974a9eabb915@github.com>

On Tue, 14 Feb 2023 05:37:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The rank of JvmtiVTMSTransition_lock is better to be safepoint instead of nosafepoint.
> The fix includes removal of the function `check_vthread_and_suspend_at_safepoint` which is not needed anymore.
> 
> Testing:
> mach5 jobs are in progress:
>  Kitchensink, tiers1-6 (all JVMTI, JDWP, JDI and JDB tests have to be included)

David, thank you for review!

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

PR: https://git.openjdk.org/jdk/pull/12550

From jvernee at openjdk.org  Tue Feb 21 12:58:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 21 Feb 2023 12:58:27 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v6]
In-Reply-To: <ZExSIuGxZu1gYcEmsVBLweVtBIfLerE0hJYQ985ersc=.a59975fc-ce00-41d3-b05c-24b8e646bb41@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <ZExSIuGxZu1gYcEmsVBLweVtBIfLerE0hJYQ985ersc=.a59975fc-ce00-41d3-b05c-24b8e646bb41@github.com>
Message-ID: <bk_UjpZSXfkQM01hQWsQ_ZMq4nBzWz7YTln0PQWjhqU=.74aee4dd-e407-4407-b755-b4c24675ec76@github.com>

On Tue, 21 Feb 2023 08:58:50 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Extends the existing AsyncGetCallTrace test case and fixes the issue.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

Testing looks good

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

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12535

From duke at openjdk.org  Tue Feb 21 14:36:47 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Tue, 21 Feb 2023 14:36:47 GMT
Subject: Integrated: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test
In-Reply-To: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
Message-ID: <vuvXJ7emp5R1Fnd3EVf1k7iWVNOap1PTBUvzLcCDT0w=.0f97ba08-9999-48f8-93ef-ae7cc9a18460@github.com>

On Mon, 13 Feb 2023 14:39:00 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

> Extends the existing AsyncGetCallTrace test case and fixes the issue.

This pull request has now been integrated.

Changeset: db483a38
Author:    Johannes Bechberger <johannes.bechberger at sap.com>
Committer: Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db483a38a815f85bd9668749674b5f0f6e4b27b4
Stats:     39 lines in 2 files changed: 36 ins; 0 del; 3 mod

8302320: AsyncGetCallTrace obtains too few frames in sanity test

Reviewed-by: jvernee, dholmes, rrich

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

PR: https://git.openjdk.org/jdk/pull/12535

From coleenp at openjdk.org  Tue Feb 21 14:48:28 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Feb 2023 14:48:28 GMT
Subject: RFR: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint
In-Reply-To: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
References: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
Message-ID: <VqFRh_W1vZ431qxTtUBZxVAzFKGnlteyNjQtiMUiz3M=.fa74d40c-7668-4d25-b404-6d147361c1cb@github.com>

On Tue, 14 Feb 2023 05:37:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The rank of JvmtiVTMSTransition_lock is better to be safepoint instead of nosafepoint.
> The fix includes removal of the function `check_vthread_and_suspend_at_safepoint` which is not needed anymore.
> 
> Testing:
> mach5 jobs are in progress:
>  Kitchensink, tiers1-6 (all JVMTI, JDWP, JDI and JDB tests have to be included)

I had a couple of nits but otherwise this looks like a good change.

src/hotspot/share/prims/jvmtiEnv.cpp line 932:

> 930:   JavaThread* current = JavaThread::current();
> 931:   HandleMark hm(current);
> 932:   Handle self_tobj = Handle(current, nullptr);

This doesn't have to have the assignment, which the compiler will optimize away anyway.

Handle self_tobj;

does the same thing.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12550

From coleenp at openjdk.org  Tue Feb 21 14:48:29 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Feb 2023 14:48:29 GMT
Subject: RFR: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint
In-Reply-To: <VqFRh_W1vZ431qxTtUBZxVAzFKGnlteyNjQtiMUiz3M=.fa74d40c-7668-4d25-b404-6d147361c1cb@github.com>
References: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
 <VqFRh_W1vZ431qxTtUBZxVAzFKGnlteyNjQtiMUiz3M=.fa74d40c-7668-4d25-b404-6d147361c1cb@github.com>
Message-ID: <NrGjR9FZAiWwkQLZNRLgiB-aFVeZ0RzbCeruTpMUYhk=.ffd055e7-385f-4f17-8b0e-4eef26e74d27@github.com>

On Tue, 21 Feb 2023 14:38:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The rank of JvmtiVTMSTransition_lock is better to be safepoint instead of nosafepoint.
>> The fix includes removal of the function `check_vthread_and_suspend_at_safepoint` which is not needed anymore.
>> 
>> Testing:
>> mach5 jobs are in progress:
>>  Kitchensink, tiers1-6 (all JVMTI, JDWP, JDI and JDB tests have to be included)
>
> src/hotspot/share/prims/jvmtiEnv.cpp line 932:
> 
>> 930:   JavaThread* current = JavaThread::current();
>> 931:   HandleMark hm(current);
>> 932:   Handle self_tobj = Handle(current, nullptr);
> 
> This doesn't have to have the assignment, which the compiler will optimize away anyway.
> 
> Handle self_tobj;
> 
> does the same thing.

Both local variables java_thread and thread_oop should be declared before line 939 so we don't have to worry about the oop being unhandled and java_thread is only used locally.

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

PR: https://git.openjdk.org/jdk/pull/12550

From pchilanomate at openjdk.org  Tue Feb 21 18:02:26 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 21 Feb 2023 18:02:26 GMT
Subject: RFR: 8300575: JVMTI support when using alternative virtual thread
 implementation [v7]
In-Reply-To: <ak-STJeftz-SOTB6AJ_-yaZhHYsUAPMZRmx3c-HEc2s=.a77cab50-a0af-4123-bc0d-1fda1ddbdb8e@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
 <TNrb8vxGZPuUTAEkOXiXdqMcEqIfLzFdOafFetj4hNw=.a76c17fa-13a7-49e3-b748-d6c75f0fbecb@github.com>
 <VPSC0DZKmvFOhqNMZZCqrUQQit2MeWrdRUTcMhrXmeo=.709e6b36-14cf-4462-9c66-3b24c1ab47b2@github.com>
 <Wep2mJvQiqmJcjGVpeqajK6bBOdpFK_4uvpiYLJwUoc=.ed71368a-55d0-4a7c-8d71-02465ec4aedf@github.com>
 <ak-STJeftz-SOTB6AJ_-yaZhHYsUAPMZRmx3c-HEc2s=.a77cab50-a0af-4123-bc0d-1fda1ddbdb8e@github.com>
Message-ID: <44LBvvPOCCF4QAbRg6ZPbjAy8aQg-PL7sYQ-xTWmQgo=.f4424e4a-c9fd-4599-8e07-211d0ed23581@github.com>

On Sat, 18 Feb 2023 07:56:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Thanks for dropping is_bound_vthread, I think it's much better now. What would you think about changing it to test the thread type is_a vmClasses::BaseVirtualThread_klass() so the VM doesn't need to know about ThreadBuilders$BoundVirtualThread.
>>>
>> Yes, we could do that. Although I think that checking for BoundVirtualThread_klass is more descriptive of what we are trying to do and will be less confusing when reading the code. How about checking for `(!VMContinuations && x->is_a(vmClasses::BaseVirtualThread_klass()))`?
>
>> Yes, we could do that. Although I think that checking for BoundVirtualThread_klass is more descriptive of what we are trying to do and will be less confusing when reading the code. How about checking for `(!VMContinuations && x->is_a(vmClasses::BaseVirtualThread_klass()))`?
> 
> We can go with what you have for now and re-visit again if it becomes an issue. The main thing I had hoped is that the VM won't get too coupled to BoundVirtualThread as that may move or be refactored soon.

Thanks for the reviews @AlanBateman, @lmesnik and @sspitsyn!

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

PR: https://git.openjdk.org/jdk/pull/12512

From pchilanomate at openjdk.org  Tue Feb 21 18:15:26 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 21 Feb 2023 18:15:26 GMT
Subject: RFR: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint
In-Reply-To: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
References: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
Message-ID: <HvJ9-E-OS1MhZuCJ0RPHEIcY1zO9r5CX0R4eKXfgCkQ=.aaf067d0-6086-4d60-8aa5-b47dbf8fb6ae@github.com>

On Tue, 14 Feb 2023 05:37:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The rank of JvmtiVTMSTransition_lock is better to be safepoint instead of nosafepoint.
> The fix includes removal of the function `check_vthread_and_suspend_at_safepoint` which is not needed anymore.
> 
> Testing:
> mach5 jobs are in progress:
>  Kitchensink, tiers1-6 (all JVMTI, JDWP, JDI and JDB tests have to be included)

Looks good to me!

src/hotspot/share/prims/jvmtiThreadState.cpp line 301:

> 299:   }
> 300:   MonitorLocker ml(JvmtiVTMSTransition_lock);
> 301: 

Ah, before we were accessing the vthread oop fields while being blocked so this change actually fixes that.

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

Marked as reviewed by pchilanomate (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12550

From sspitsyn at openjdk.org  Tue Feb 21 19:49:26 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Feb 2023 19:49:26 GMT
Subject: RFR: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint
In-Reply-To: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
References: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
Message-ID: <a4_YxEKsKIkqY5e9y8zebJXJwD7N9xSniAkFaZAYKd4=.223765ff-22e1-42d0-8a71-e02a710be077@github.com>

On Tue, 14 Feb 2023 05:37:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The rank of JvmtiVTMSTransition_lock is better to be safepoint instead of nosafepoint.
> The fix includes removal of the function `check_vthread_and_suspend_at_safepoint` which is not needed anymore.
> 
> Testing:
> mach5 jobs are in progress:
>  Kitchensink, tiers1-6 (all JVMTI, JDWP, JDI and JDB tests have to be included)

Coleen and Patricio, thank you for review!

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

PR: https://git.openjdk.org/jdk/pull/12550

From sspitsyn at openjdk.org  Tue Feb 21 19:49:29 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Feb 2023 19:49:29 GMT
Subject: RFR: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint
In-Reply-To: <NrGjR9FZAiWwkQLZNRLgiB-aFVeZ0RzbCeruTpMUYhk=.ffd055e7-385f-4f17-8b0e-4eef26e74d27@github.com>
References: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
 <VqFRh_W1vZ431qxTtUBZxVAzFKGnlteyNjQtiMUiz3M=.fa74d40c-7668-4d25-b404-6d147361c1cb@github.com>
 <NrGjR9FZAiWwkQLZNRLgiB-aFVeZ0RzbCeruTpMUYhk=.ffd055e7-385f-4f17-8b0e-4eef26e74d27@github.com>
Message-ID: <MqL9NMDMtbHXxNgU5AgvpFNwtV5C1txfIAkTRxP0PYo=.328a92f5-68ed-48ab-b033-f9cb84546db5@github.com>

On Tue, 21 Feb 2023 14:45:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnv.cpp line 932:
>> 
>>> 930:   JavaThread* current = JavaThread::current();
>>> 931:   HandleMark hm(current);
>>> 932:   Handle self_tobj = Handle(current, nullptr);
>> 
>> This doesn't have to have the assignment, which the compiler will optimize away anyway.
>> 
>> Handle self_tobj;
>> 
>> does the same thing.
>
> Both local variables java_thread and thread_oop should be declared before line 939 so we don't have to worry about the oop being unhandled and java_thread is only used locally.

Thank you, Coleen. Fixed now.

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

PR: https://git.openjdk.org/jdk/pull/12550

From sspitsyn at openjdk.org  Tue Feb 21 19:49:30 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Feb 2023 19:49:30 GMT
Subject: RFR: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint
In-Reply-To: <HvJ9-E-OS1MhZuCJ0RPHEIcY1zO9r5CX0R4eKXfgCkQ=.aaf067d0-6086-4d60-8aa5-b47dbf8fb6ae@github.com>
References: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
 <HvJ9-E-OS1MhZuCJ0RPHEIcY1zO9r5CX0R4eKXfgCkQ=.aaf067d0-6086-4d60-8aa5-b47dbf8fb6ae@github.com>
Message-ID: <Q_ehp2ddPdZARZz-xllKhA2Bb-u7o6PQRcdhjOe8Sic=.8f642530-bf71-4385-9e7a-b88d98905aa3@github.com>

On Tue, 21 Feb 2023 17:57:36 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> The rank of JvmtiVTMSTransition_lock is better to be safepoint instead of nosafepoint.
>> The fix includes removal of the function `check_vthread_and_suspend_at_safepoint` which is not needed anymore.
>> 
>> Testing:
>> mach5 jobs are in progress:
>>  Kitchensink, tiers1-6 (all JVMTI, JDWP, JDI and JDB tests have to be included)
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 301:
> 
>> 299:   }
>> 300:   MonitorLocker ml(JvmtiVTMSTransition_lock);
>> 301: 
> 
> Ah, before we were accessing the vthread oop fields while being blocked so this change actually fixes that.

Right. It is really hard to catch and track, so it is much better to avoid being blocked as it is dangerous.

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

PR: https://git.openjdk.org/jdk/pull/12550

From sspitsyn at openjdk.org  Tue Feb 21 21:01:42 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Feb 2023 21:01:42 GMT
Subject: RFR: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint
 [v2]
In-Reply-To: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
References: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
Message-ID: <sLrgVXgAkG9sewHWfEqSnapj0BmujnBc0BcS3gqy74s=.d5257f4c-6195-4d6d-abb8-f1503e75c1cd@github.com>

> The rank of JvmtiVTMSTransition_lock is better to be safepoint instead of nosafepoint.
> The fix includes removal of the function `check_vthread_and_suspend_at_safepoint` which is not needed anymore.
> 
> Testing:
> mach5 jobs are in progress:
>  Kitchensink, tiers1-6 (all JVMTI, JDWP, JDI and JDB tests have to be included)

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

  addressed review comments from Coleen

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12550/files
  - new: https://git.openjdk.org/jdk/pull/12550/files/e408826e..244836dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12550&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12550&range=00-01

  Stats: 7 lines in 1 file changed: 2 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12550.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12550/head:pull/12550

PR: https://git.openjdk.org/jdk/pull/12550

From sspitsyn at openjdk.org  Tue Feb 21 21:25:40 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Feb 2023 21:25:40 GMT
Subject: Integrated: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint
In-Reply-To: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
References: <m-Iq0H7uGfw6vRTS5ZAGdLWVzY6h7V0k1MsR_icn5CU=.a74cf9eb-8028-4ade-aeda-651ea0e3e62f@github.com>
Message-ID: <geVOGNDGf2wRDUi9D3X59hMdJGGhaaPiArrJ2_D5Rfo=.e0b99964-acea-48ac-bbd0-1baa84e687a4@github.com>

On Tue, 14 Feb 2023 05:37:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The rank of JvmtiVTMSTransition_lock is better to be safepoint instead of nosafepoint.
> The fix includes removal of the function `check_vthread_and_suspend_at_safepoint` which is not needed anymore.
> 
> Testing:
> mach5 jobs are in progress:
>  Kitchensink, tiers1-6 (all JVMTI, JDWP, JDI and JDB tests have to be included)

This pull request has now been integrated.

Changeset: 46f25250
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46f25250bd49702fe18f9903473dc3e1cbe70f84
Stats:     55 lines in 6 files changed: 10 ins; 32 del; 13 mod

8299240: rank of JvmtiVTMSTransition_lock can be safepoint

Reviewed-by: dholmes, coleenp, pchilanomate

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

PR: https://git.openjdk.org/jdk/pull/12550

From dholmes at openjdk.org  Tue Feb 21 23:55:26 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Feb 2023 23:55:26 GMT
Subject: RFR: 8302870: More information needed from failures in vmTestbase
 ThreadUtils.waitThreadState [v2]
In-Reply-To: <d5No9g4MVR8yemimu0TwtYSK0tt2uqKh88jjerkAGo0=.12d72e59-f5af-4057-903a-9eb7807e56f9@github.com>
References: <IYTo6akU-Bsww0XBuhz-eMuOeQRxqvuAYz8dvdhlmPo=.d0cfddee-800e-48a2-a9d6-325b58293ef4@github.com>
 <d5No9g4MVR8yemimu0TwtYSK0tt2uqKh88jjerkAGo0=.12d72e59-f5af-4057-903a-9eb7807e56f9@github.com>
Message-ID: <MDqRHoVXzzMHIER2Z3GXlrigK3mvrkNnBgCxQeNUg0M=.a85b4b22-20e4-4e75-8e30-ee5cf3efa105@github.com>

On Tue, 21 Feb 2023 09:09:43 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Test update to make failures such as JDK-8076494 more informative.
>> 
>> Waiting for a thread to change state: give more time (to distinguish a real deadlock from some other delay), and log the thread stackframes when the expected state change is not observed.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nits

Update looks good - thanks.

I have no issue if you change the file indents after the PR is approved and then integrate - as it is only whitespace change. :)

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12661

From sspitsyn at openjdk.org  Wed Feb 22 08:10:54 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Feb 2023 08:10:54 GMT
Subject: RFR: 8302870: More information needed from failures in vmTestbase
 ThreadUtils.waitThreadState [v2]
In-Reply-To: <d5No9g4MVR8yemimu0TwtYSK0tt2uqKh88jjerkAGo0=.12d72e59-f5af-4057-903a-9eb7807e56f9@github.com>
References: <IYTo6akU-Bsww0XBuhz-eMuOeQRxqvuAYz8dvdhlmPo=.d0cfddee-800e-48a2-a9d6-325b58293ef4@github.com>
 <d5No9g4MVR8yemimu0TwtYSK0tt2uqKh88jjerkAGo0=.12d72e59-f5af-4057-903a-9eb7807e56f9@github.com>
Message-ID: <l9LCMW473A5S_pnh_xdJuUCM9N1JhX7Wu1YsGy50XdY=.c0d53545-1bfd-423f-8827-b73c95e33a30@github.com>

On Tue, 21 Feb 2023 09:09:43 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Test update to make failures such as JDK-8076494 more informative.
>> 
>> Waiting for a thread to change state: give more time (to distinguish a real deadlock from some other delay), and log the thread stackframes when the expected state change is not observed.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nits

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12661

From kevinw at openjdk.org  Wed Feb 22 09:28:23 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 22 Feb 2023 09:28:23 GMT
Subject: RFR: 8302870: More information needed from failures in vmTestbase
 ThreadUtils.waitThreadState [v2]
In-Reply-To: <d5No9g4MVR8yemimu0TwtYSK0tt2uqKh88jjerkAGo0=.12d72e59-f5af-4057-903a-9eb7807e56f9@github.com>
References: <IYTo6akU-Bsww0XBuhz-eMuOeQRxqvuAYz8dvdhlmPo=.d0cfddee-800e-48a2-a9d6-325b58293ef4@github.com>
 <d5No9g4MVR8yemimu0TwtYSK0tt2uqKh88jjerkAGo0=.12d72e59-f5af-4057-903a-9eb7807e56f9@github.com>
Message-ID: <DHw5SNAH3pAdxPr_I_Acd5gSQo8ApUF6qHGYYgx7Ic8=.d674ac44-4775-4b18-9d73-7cdb32b3ac06@github.com>

On Tue, 21 Feb 2023 09:09:43 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Test update to make failures such as JDK-8076494 more informative.
>> 
>> Waiting for a thread to change state: give more time (to distinguish a real deadlock from some other delay), and log the thread stackframes when the expected state change is not observed.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nits

Thanks David and Serguei!
(leaving whitespace unification alone for now... 8-) )

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

PR: https://git.openjdk.org/jdk/pull/12661

From kevinw at openjdk.org  Wed Feb 22 09:34:12 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 22 Feb 2023 09:34:12 GMT
Subject: Integrated: 8302870: More information needed from failures in
 vmTestbase ThreadUtils.waitThreadState
In-Reply-To: <IYTo6akU-Bsww0XBuhz-eMuOeQRxqvuAYz8dvdhlmPo=.d0cfddee-800e-48a2-a9d6-325b58293ef4@github.com>
References: <IYTo6akU-Bsww0XBuhz-eMuOeQRxqvuAYz8dvdhlmPo=.d0cfddee-800e-48a2-a9d6-325b58293ef4@github.com>
Message-ID: <1-JnUgGZfHMtgneRKnZHvE0LUtCcsmT9bLHDnXwnZTQ=.f168ec7f-b0d7-4c17-b4b6-47efe5fe99c4@github.com>

On Mon, 20 Feb 2023 12:54:06 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test update to make failures such as JDK-8076494 more informative.
> 
> Waiting for a thread to change state: give more time (to distinguish a real deadlock from some other delay), and log the thread stackframes when the expected state change is not observed.

This pull request has now been integrated.

Changeset: 5e1d1b79
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e1d1b79409cdee7509c682a88fc2905719b2ddf
Stats:     28 lines in 1 file changed: 23 ins; 0 del; 5 mod

8302870: More information needed from failures in vmTestbase ThreadUtils.waitThreadState

Reviewed-by: dholmes, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/12661

From jcking at openjdk.org  Wed Feb 22 14:33:57 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 22 Feb 2023 14:33:57 GMT
Subject: RFR: JDK-8303071: Memory leaks in libjdwp
Message-ID: <PQ-Lb328M636iWe6m5UjFWbsIR0avAHcapu-ZSumJYU=.b3bc3a7e-a847-4086-a642-132843e65327@github.com>

Fix minor memory leaks in libjdwp.

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

Commit messages:
 - Memory leaks in libjdwp

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

PR: https://git.openjdk.org/jdk/pull/12716

From jcking at openjdk.org  Wed Feb 22 15:19:56 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 22 Feb 2023 15:19:56 GMT
Subject: RFR: JDK-8303071: Memory leaks in libjdwp [v2]
In-Reply-To: <PQ-Lb328M636iWe6m5UjFWbsIR0avAHcapu-ZSumJYU=.b3bc3a7e-a847-4086-a642-132843e65327@github.com>
References: <PQ-Lb328M636iWe6m5UjFWbsIR0avAHcapu-ZSumJYU=.b3bc3a7e-a847-4086-a642-132843e65327@github.com>
Message-ID: <WWrNq5TXYstPElrN1VqF-ybEdnODxK_Ru4SPgcG9NaU=.f97bdca6-eca7-4b3f-9c9a-f161c48e4409@github.com>

> Fix minor memory leaks in libjdwp.

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

  Use jvmtiDeallocate wrapper
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12716/files
  - new: https://git.openjdk.org/jdk/pull/12716/files/00c5140a..a2417376

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12716&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12716&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12716

From pchilanomate at openjdk.org  Wed Feb 22 15:46:41 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 22 Feb 2023 15:46:41 GMT
Subject: Integrated: 8300575: JVMTI support when using alternative virtual
 thread implementation
In-Reply-To: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
References: <7-glNqi3qp6zijEvorJSMii9pUji65gOYepL0epeQRE=.86023773-de72-4056-b6b1-a55adff14c52@github.com>
Message-ID: <n7GEbqTMxjWF87my9dHw9-6Qe1sw-ncnh1VjREPkL60=.14b164d2-0ad9-476a-b38c-a14dfd588cba@github.com>

On Fri, 10 Feb 2023 14:50:36 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following change. Some of the JVMTI functions had to be modified since they are not supported by the specs on virtual threads (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or shouldn't include virtual threads in the results (GetAllThreads, GetAllStackTraces, GetThreadGroupChildren). Others were modified because they should work on virtual thread but they weren't (SuspendAllVirtualThreads/ResumeAllVirtualThreads). Also support for VirtualThreadStart/VirtualThreadEnd events was added.
> 
> There were a total of 71 tests under serviceability/jvmti/ that had the vm.continuations requirement. Of those, 24 where under serviceability/jvmti/vthread/. I was able to remove that requirement from 50 tests. Most of those tests were already passing for the alternative vthread implementation just by removing the check in jni_GetEnv for VMContinuations.
> From the other 21 tests, 20 still fail with the changes either because they actually test continuations or because of different assumptions in the tests that don't hold true for the alternative vthread implementation. So for those I left the vm.continuations requirement untouched (from those 20 tests there are actually 4 tests from the thread/GetStackTrace/ family that are passing because of a bug in the test, but I can fix that in another RFE). The other remaining test is vthread/GetSetLocalTest/GetSetLocalTest.java which I see is problemlisted.
> 
> Regarding variable _is_bound_vthread, although it's handy as a cache to avoid repeating the check, I mainly added it to avoid transitioning for GetCurrentThreadCpuTime (we are native and cannot access oops).
> 
> I added new test BoundVThreadTest.java which just checks for the unsupported/supported behavior mentioned previously. For some extra basic coverage I also added a new run with -XX:-VMContinuations on tests inside the serviceability/jvmti/vthread/ directory that don't require vm.continuations anymore. I could also add that for all the other tests in serviceability/jvmti/ for which I removed the vm.continuations requirement.
> 
> I run the patch through mach5 tiers 1-6 plus some extra local runs on the relevant tests.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: 83bea26d
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83bea26df453282d46afff333e006e8f9b7fb201
Stats:     635 lines in 69 files changed: 514 ins; 77 del; 44 mod

8300575: JVMTI support when using alternative virtual thread implementation

Reviewed-by: lmesnik, sspitsyn, alanb

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

PR: https://git.openjdk.org/jdk/pull/12512

From sspitsyn at openjdk.org  Thu Feb 23 03:56:02 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 Feb 2023 03:56:02 GMT
Subject: RFR: JDK-8303071: Memory leaks in libjdwp [v2]
In-Reply-To: <WWrNq5TXYstPElrN1VqF-ybEdnODxK_Ru4SPgcG9NaU=.f97bdca6-eca7-4b3f-9c9a-f161c48e4409@github.com>
References: <PQ-Lb328M636iWe6m5UjFWbsIR0avAHcapu-ZSumJYU=.b3bc3a7e-a847-4086-a642-132843e65327@github.com>
 <WWrNq5TXYstPElrN1VqF-ybEdnODxK_Ru4SPgcG9NaU=.f97bdca6-eca7-4b3f-9c9a-f161c48e4409@github.com>
Message-ID: <tcfy1c4QUXYgjts4-PDdHLp5xruhpHG2X9nY8m3pkAA=.9ae461c7-3a69-403a-9884-445cd89ad070@github.com>

On Wed, 22 Feb 2023 15:19:56 GMT, Justin King <jcking at openjdk.org> wrote:

>> Fix minor memory leaks in libjdwp.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use jvmtiDeallocate wrapper
>   
>   Signed-off-by: Justin King <jcking at google.com>

It looks good.
Thank you for taking care about it.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12716

From serb at openjdk.org  Thu Feb 23 10:18:52 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Feb 2023 10:18:52 GMT
Subject: RFR: 8303102: jcmd: ManagementAgent.status truncates the text
 longer than O_BUFLEN
In-Reply-To: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
References: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
Message-ID: <oKWKdteAJI5Nbed-2O74cgYVHH_eZffBXu_oGlJKGbU=.dd5ebf5b-dc62-4e9a-8bac-a9c296803f22@github.com>

On Thu, 23 Feb 2023 05:16:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Implementation of the "ManagementAgent.status" indirectly depends on the size of "O_BUFLEN".
> 
> The root cause is usage of [print_cr()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L153) which may [truncate](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L101) the output.
> 
> The solution is similar to the [JDK-8263640](https://bugs.openjdk.org/browse/JDK-8263640). see discussion about that approach https://github.com/openjdk/jdk/pull/4616

One tier1 test failure is unrelated to this patch, it is filed https://bugs.openjdk.org/browse/JDK-8303105

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

PR: https://git.openjdk.org/jdk/pull/12724

From serb at openjdk.org  Thu Feb 23 10:18:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Feb 2023 10:18:50 GMT
Subject: RFR: 8303102: jcmd: ManagementAgent.status truncates the text longer
 than O_BUFLEN
Message-ID: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>

Implementation of the "ManagementAgent.status" indirectly depends on the size of "O_BUFLEN".

The root cause is usage of [print_cr()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L153) which may [truncate](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L101) the output.

The solution is similar to the [JDK-8263640](https://bugs.openjdk.org/browse/JDK-8263640). see discussion about that approach https://github.com/openjdk/jdk/pull/4616

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

Commit messages:
 - 8303102: jcmd: ManagementAgent.status truncates the text longer than O_BUFLEN

Changes: https://git.openjdk.org/jdk/pull/12724/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12724&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303102
  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12724.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12724/head:pull/12724

PR: https://git.openjdk.org/jdk/pull/12724

From dholmes at openjdk.org  Thu Feb 23 11:37:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Feb 2023 11:37:07 GMT
Subject: RFR: 8303102: jcmd: ManagementAgent.status truncates the text
 longer than O_BUFLEN
In-Reply-To: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
References: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
Message-ID: <LIegOV5E5t1y2i_JbULrUJ2C_mIW22SK5wVQJmFycaI=.45ef21dc-4030-42d2-b90e-c8aa45625942@github.com>

On Thu, 23 Feb 2023 05:16:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Implementation of the "ManagementAgent.status" indirectly depends on the size of "O_BUFLEN".
> 
> The root cause is usage of [print_cr()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L153) which may [truncate](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L101) the output.
> 
> The solution is similar to the [JDK-8263640](https://bugs.openjdk.org/browse/JDK-8263640). see discussion about that approach https://github.com/openjdk/jdk/pull/4616

Change seems reasonable. Can we get an actual regression test to verify this?

test/jdk/sun/management/jmxremote/startstop/JMXStatusTest.java line 36:

> 34: /**
> 35:  * @test
> 36:  * @bug 8023093 8138748 8142398 8303102

As this test doesn't explicitly test/check the issue in 8303102 I don't think it needs to belisted on the @bug line. (And if it does then the copyright year needs t be updated too).

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

PR: https://git.openjdk.org/jdk/pull/12724

From jcking at openjdk.org  Thu Feb 23 15:27:28 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 23 Feb 2023 15:27:28 GMT
Subject: RFR: JDK-8303071: Memory leaks in libjdwp [v2]
In-Reply-To: <WWrNq5TXYstPElrN1VqF-ybEdnODxK_Ru4SPgcG9NaU=.f97bdca6-eca7-4b3f-9c9a-f161c48e4409@github.com>
References: <PQ-Lb328M636iWe6m5UjFWbsIR0avAHcapu-ZSumJYU=.b3bc3a7e-a847-4086-a642-132843e65327@github.com>
 <WWrNq5TXYstPElrN1VqF-ybEdnODxK_Ru4SPgcG9NaU=.f97bdca6-eca7-4b3f-9c9a-f161c48e4409@github.com>
Message-ID: <NWq9Qhpf1rWzg9THAe1rpGu4AZWAinRqLl-sf79r6tI=.d3df10bf-5105-4f70-86f8-95c210308a7e@github.com>

On Wed, 22 Feb 2023 15:19:56 GMT, Justin King <jcking at openjdk.org> wrote:

>> Fix minor memory leaks in libjdwp.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use jvmtiDeallocate wrapper
>   
>   Signed-off-by: Justin King <jcking at google.com>

Tests look unrelated and seem to be failing in other PRs.

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

PR: https://git.openjdk.org/jdk/pull/12716

From jcking at openjdk.org  Thu Feb 23 15:27:30 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 23 Feb 2023 15:27:30 GMT
Subject: Integrated: JDK-8303071: Memory leaks in libjdwp
In-Reply-To: <PQ-Lb328M636iWe6m5UjFWbsIR0avAHcapu-ZSumJYU=.b3bc3a7e-a847-4086-a642-132843e65327@github.com>
References: <PQ-Lb328M636iWe6m5UjFWbsIR0avAHcapu-ZSumJYU=.b3bc3a7e-a847-4086-a642-132843e65327@github.com>
Message-ID: <f-Lgb9B8gQJvETS8fd6-gHPIrdk2Z6w3bCpJj7uGVXA=.8a2b338b-2322-4779-81f7-608316487088@github.com>

On Wed, 22 Feb 2023 14:26:08 GMT, Justin King <jcking at openjdk.org> wrote:

> Fix minor memory leaks in libjdwp.

This pull request has now been integrated.

Changeset: 2cf8b860
Author:    Justin King <jcking at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2cf8b8607dac961e1d63a905c6492daa54c944d5
Stats:     6 lines in 2 files changed: 5 ins; 0 del; 1 mod

8303071: Memory leaks in libjdwp

Reviewed-by: sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/12716

From serb at openjdk.org  Thu Feb 23 17:06:59 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Feb 2023 17:06:59 GMT
Subject: RFR: 8303102: jcmd: ManagementAgent.status truncates the text
 longer than O_BUFLEN [v2]
In-Reply-To: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
References: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
Message-ID: <dgdAK_yce5DgEamcWoiiDKJXn2pDRZ9jpTgmDfKaDxA=.c476d3c5-b782-44b8-8913-9940b86cf407@github.com>

> Implementation of the "ManagementAgent.status" indirectly depends on the size of "O_BUFLEN".
> 
> The root cause is usage of [print_cr()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L153) which may [truncate](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L101) the output.
> 
> The solution is similar to the [JDK-8263640](https://bugs.openjdk.org/browse/JDK-8263640). see discussion about that approach https://github.com/openjdk/jdk/pull/4616

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

  Update JMXStatusTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12724/files
  - new: https://git.openjdk.org/jdk/pull/12724/files/23422bc0..99aef33c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12724&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12724&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12724

From serb at openjdk.org  Thu Feb 23 17:07:02 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Feb 2023 17:07:02 GMT
Subject: RFR: 8303102: jcmd: ManagementAgent.status truncates the text
 longer than O_BUFLEN [v2]
In-Reply-To: <LIegOV5E5t1y2i_JbULrUJ2C_mIW22SK5wVQJmFycaI=.45ef21dc-4030-42d2-b90e-c8aa45625942@github.com>
References: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
 <LIegOV5E5t1y2i_JbULrUJ2C_mIW22SK5wVQJmFycaI=.45ef21dc-4030-42d2-b90e-c8aa45625942@github.com>
Message-ID: <TdzOEtbVMkYst-mV0IpCy1rGwA3vVND9clKw6_MUbAc=.029251af-536b-4191-8620-f7efcb868ab1@github.com>

On Thu, 23 Feb 2023 11:34:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update JMXStatusTest.java
>
> test/jdk/sun/management/jmxremote/startstop/JMXStatusTest.java line 36:
> 
>> 34: /**
>> 35:  * @test
>> 36:  * @bug 8023093 8138748 8142398 8303102
> 
> As this test doesn't explicitly test/check the issue in 8303102 I don't think it needs to belisted on the @bug line. (And if it does then the copyright year needs t be updated too).

I have found this issue by using this test on a host with long hostname, it does validate the output of the command and fails if it truncated.

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

PR: https://git.openjdk.org/jdk/pull/12724

From dcubed at openjdk.org  Thu Feb 23 17:11:51 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 23 Feb 2023 17:11:51 GMT
Subject: Integrated: 8303125: ProblemList
 vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java
Message-ID: <vHjsDtRH9Hg4KlnExj-tPUfsgxc_wS-Tygjwcm4nSow=.2cbb42ad-1090-48ce-b174-795ff5bb0faf@github.com>

A trivial fix to ProblemList
vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java
on all configs.

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

Commit messages:
 - 8303125: ProblemList vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java

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

PR: https://git.openjdk.org/jdk/pull/12731

From jdv at openjdk.org  Thu Feb 23 17:11:51 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 23 Feb 2023 17:11:51 GMT
Subject: Integrated: 8303125: ProblemList
 vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java
In-Reply-To: <vHjsDtRH9Hg4KlnExj-tPUfsgxc_wS-Tygjwcm4nSow=.2cbb42ad-1090-48ce-b174-795ff5bb0faf@github.com>
References: <vHjsDtRH9Hg4KlnExj-tPUfsgxc_wS-Tygjwcm4nSow=.2cbb42ad-1090-48ce-b174-795ff5bb0faf@github.com>
Message-ID: <3o6WJgH7AhQokUl_PhLeycYlPXf6pffpquu-UcLyCcg=.bd87dd83-dea4-4619-893d-b96ee8db9502@github.com>

On Thu, 23 Feb 2023 16:57:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList
> vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java
> on all configs.

Marked as reviewed by jdv (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12731

From dcubed at openjdk.org  Thu Feb 23 17:11:52 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 23 Feb 2023 17:11:52 GMT
Subject: Integrated: 8303125: ProblemList
 vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java
In-Reply-To: <3o6WJgH7AhQokUl_PhLeycYlPXf6pffpquu-UcLyCcg=.bd87dd83-dea4-4619-893d-b96ee8db9502@github.com>
References: <vHjsDtRH9Hg4KlnExj-tPUfsgxc_wS-Tygjwcm4nSow=.2cbb42ad-1090-48ce-b174-795ff5bb0faf@github.com>
 <3o6WJgH7AhQokUl_PhLeycYlPXf6pffpquu-UcLyCcg=.bd87dd83-dea4-4619-893d-b96ee8db9502@github.com>
Message-ID: <KDHqVqZrceTmooVgfb1cr2q8xoIeH7jlKi2UYXrH_po=.909247ef-75ed-439a-b0bb-cfc485f6afd0@github.com>

On Thu, 23 Feb 2023 17:04:34 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> A trivial fix to ProblemList
>> vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java
>> on all configs.
>
> Marked as reviewed by jdv (Reviewer).

@jayathirthrao - Thanks for the fast review!

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

PR: https://git.openjdk.org/jdk/pull/12731

From dcubed at openjdk.org  Thu Feb 23 17:11:53 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 23 Feb 2023 17:11:53 GMT
Subject: Integrated: 8303125: ProblemList
 vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java
In-Reply-To: <vHjsDtRH9Hg4KlnExj-tPUfsgxc_wS-Tygjwcm4nSow=.2cbb42ad-1090-48ce-b174-795ff5bb0faf@github.com>
References: <vHjsDtRH9Hg4KlnExj-tPUfsgxc_wS-Tygjwcm4nSow=.2cbb42ad-1090-48ce-b174-795ff5bb0faf@github.com>
Message-ID: <tQCaL-kl-NiheYXdO-FmNciqW_7It1U67SnFyTLhrXI=.0078e33e-08d8-4c9b-a874-761a305025b0@github.com>

On Thu, 23 Feb 2023 16:57:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList
> vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java
> on all configs.

This pull request has now been integrated.

Changeset: a2471b37
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a2471b37e358040049b616e1d2ce160539b9a2a2
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8303125: ProblemList vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java

Reviewed-by: jdv

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

PR: https://git.openjdk.org/jdk/pull/12731

From dholmes at openjdk.org  Thu Feb 23 22:29:15 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Feb 2023 22:29:15 GMT
Subject: RFR: JDK-8303071: Memory leaks in libjdwp [v2]
In-Reply-To: <WWrNq5TXYstPElrN1VqF-ybEdnODxK_Ru4SPgcG9NaU=.f97bdca6-eca7-4b3f-9c9a-f161c48e4409@github.com>
References: <PQ-Lb328M636iWe6m5UjFWbsIR0avAHcapu-ZSumJYU=.b3bc3a7e-a847-4086-a642-132843e65327@github.com>
 <WWrNq5TXYstPElrN1VqF-ybEdnODxK_Ru4SPgcG9NaU=.f97bdca6-eca7-4b3f-9c9a-f161c48e4409@github.com>
Message-ID: <tHeeh_7TpGuicgtRzhgxPEVR9yQqivcnzCpG1JurjFo=.bc65ece6-56e5-432e-8340-cd640ed39839@github.com>

On Wed, 22 Feb 2023 15:19:56 GMT, Justin King <jcking at openjdk.org> wrote:

>> Fix minor memory leaks in libjdwp.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use jvmtiDeallocate wrapper
>   
>   Signed-off-by: Justin King <jcking at google.com>

Just a sanity check here. That memory was allocated using `*callback->alloc` not `jvmtiAllocate` - is it correct to release with `jvmtiDeallocate`?

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

PR: https://git.openjdk.org/jdk/pull/12716

From jcking at openjdk.org  Thu Feb 23 22:56:12 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 23 Feb 2023 22:56:12 GMT
Subject: RFR: JDK-8303071: Memory leaks in libjdwp [v2]
In-Reply-To: <WWrNq5TXYstPElrN1VqF-ybEdnODxK_Ru4SPgcG9NaU=.f97bdca6-eca7-4b3f-9c9a-f161c48e4409@github.com>
References: <PQ-Lb328M636iWe6m5UjFWbsIR0avAHcapu-ZSumJYU=.b3bc3a7e-a847-4086-a642-132843e65327@github.com>
 <WWrNq5TXYstPElrN1VqF-ybEdnODxK_Ru4SPgcG9NaU=.f97bdca6-eca7-4b3f-9c9a-f161c48e4409@github.com>
Message-ID: <LJ_Tmzho761-rBiDhCfy4CcjwX7cUQ8F2yYkBsyaT3U=.5fb28703-bea5-4561-aed2-907ad31e6e8e@github.com>

On Wed, 22 Feb 2023 15:19:56 GMT, Justin King <jcking at openjdk.org> wrote:

>> Fix minor memory leaks in libjdwp.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use jvmtiDeallocate wrapper
>   
>   Signed-off-by: Justin King <jcking at google.com>

callback->alloc is jvmtiAllocate and callback->free is jvmtiDeallocate. It is setup in transport.c, which is also the one which frees. So it is fine in this case.

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

PR: https://git.openjdk.org/jdk/pull/12716

From dholmes at openjdk.org  Thu Feb 23 23:09:13 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Feb 2023 23:09:13 GMT
Subject: RFR: JDK-8303071: Memory leaks in libjdwp [v2]
In-Reply-To: <WWrNq5TXYstPElrN1VqF-ybEdnODxK_Ru4SPgcG9NaU=.f97bdca6-eca7-4b3f-9c9a-f161c48e4409@github.com>
References: <PQ-Lb328M636iWe6m5UjFWbsIR0avAHcapu-ZSumJYU=.b3bc3a7e-a847-4086-a642-132843e65327@github.com>
 <WWrNq5TXYstPElrN1VqF-ybEdnODxK_Ru4SPgcG9NaU=.f97bdca6-eca7-4b3f-9c9a-f161c48e4409@github.com>
Message-ID: <coe8N_qZJ4PmN_1IYnp54sjAxueRtSQH47VF2OpidO4=.47b16283-207b-4f62-bc13-20dbe1dfe4ae@github.com>

On Wed, 22 Feb 2023 15:19:56 GMT, Justin King <jcking at openjdk.org> wrote:

>> Fix minor memory leaks in libjdwp.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use jvmtiDeallocate wrapper
>   
>   Signed-off-by: Justin King <jcking at google.com>

Thanks! Now I can join the dots there.

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

PR: https://git.openjdk.org/jdk/pull/12716

From jwaters at openjdk.org  Fri Feb 24 15:47:08 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 24 Feb 2023 15:47:08 GMT
Subject: RFR: 8303169: Remove Windows specific workaround from libdt
Message-ID: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>

We no longer need to define PrId64 ourselves since the Visual C++ compiler supports inttypes.h on the only versions we support, so we can just replace it with an include to the standard header instead

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

Commit messages:
 - Remove Windows specific workaround from libdt

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

PR: https://git.openjdk.org/jdk/pull/12744

From cjplummer at openjdk.org  Fri Feb 24 20:16:21 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Feb 2023 20:16:21 GMT
Subject: RFR: JDK-8303071: Memory leaks in libjdwp [v2]
In-Reply-To: <WWrNq5TXYstPElrN1VqF-ybEdnODxK_Ru4SPgcG9NaU=.f97bdca6-eca7-4b3f-9c9a-f161c48e4409@github.com>
References: <PQ-Lb328M636iWe6m5UjFWbsIR0avAHcapu-ZSumJYU=.b3bc3a7e-a847-4086-a642-132843e65327@github.com>
 <WWrNq5TXYstPElrN1VqF-ybEdnODxK_Ru4SPgcG9NaU=.f97bdca6-eca7-4b3f-9c9a-f161c48e4409@github.com>
Message-ID: <hp4z3_-gCQxBw21M-Nm5MgAs1M2L8Aix2YU254cRNjQ=.610ee5fc-8e6a-41da-b71c-6473fd18946f@github.com>

On Wed, 22 Feb 2023 15:19:56 GMT, Justin King <jcking at openjdk.org> wrote:

>> Fix minor memory leaks in libjdwp.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use jvmtiDeallocate wrapper
>   
>   Signed-off-by: Justin King <jcking at google.com>

Approved.

@jcking In the future please wait for a second review before pushing any hotspot related changes unless the reviewer agrees that the changes are trivial. thanks.

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

PR: https://git.openjdk.org/jdk/pull/12716

From cjplummer at openjdk.org  Fri Feb 24 20:28:02 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Feb 2023 20:28:02 GMT
Subject: RFR: 8303169: Remove Windows specific workaround from libdt
In-Reply-To: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
References: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
Message-ID: <zZUM5gnPBGewmAd4A850mxKFfgp0njq5oLBfhHNpTLM=.d9e96997-92bb-4db4-bb8b-9b1fc67b5542@github.com>

On Fri, 24 Feb 2023 15:36:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> We no longer need to define PrId64 ourselves since the Visual C++ compiler supports inttypes.h on the only versions we support, so we can just replace it with an include to the standard header instead

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12744

From dcubed at openjdk.org  Fri Feb 24 21:23:14 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 24 Feb 2023 21:23:14 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v12]
In-Reply-To: <dVjCB5qGZkEvwKrVN8841Gi3Ngz0t6ATPwC61ze0Ng4=.5dc3192a-d6a9-4751-aaa7-856509e16717@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <dVjCB5qGZkEvwKrVN8841Gi3Ngz0t6ATPwC61ze0Ng4=.5dc3192a-d6a9-4751-aaa7-856509e16717@github.com>
Message-ID: <wz9WND-HKV59yoZxavxiHaFyxy--8QcE4b2x9TUt7uY=.97fe152c-10d1-4523-82fb-92c761194cfa@github.com>

On Wed, 15 Feb 2023 21:15:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock.
>> 
>> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking.
>> 
>> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread.
>> 
>> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it.
>> 
>> This change enables to simplify (and speed-up!) a lot of code:
>> 
>> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header.
>> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge error (move done label into correct places)

This project is currently baselined on jdk-21+10-761.

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

PR: https://git.openjdk.org/jdk/pull/10907

From sspitsyn at openjdk.org  Fri Feb 24 23:44:09 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 24 Feb 2023 23:44:09 GMT
Subject: RFR: 8303169: Remove Windows specific workaround from libdt
In-Reply-To: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
References: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
Message-ID: <29jM-gCnLvpqNUeDRyli0MGCOYkBEEEmV-QJatxuu5s=.8aee221e-c0e6-4a53-a3bb-7dfcbe0aeb5c@github.com>

On Fri, 24 Feb 2023 15:36:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> We no longer need to define PrId64 ourselves since the Visual C++ compiler supports inttypes.h on the only versions we support, so we can just replace it with an include to the standard header instead

Looks okay to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12744

From cjplummer at openjdk.org  Sat Feb 25 00:14:54 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 25 Feb 2023 00:14:54 GMT
Subject: RFR: 8302516: Do some cleanup of nsk/share/jdi/EventHandler.java
Message-ID: <DZnbDYLa4-v0cuGjNyJV29sVefskU_03o_J5tY0nPPA=.ef68496c-54cd-422d-bfb4-50b09df562ea@github.com>

While working on [JDK-8289765](https://bugs.openjdk.org/browse/JDK-8289765), I ended up doing a lot of cleanup of nsk/share/jdi/EventHandler.java, so much so that the changes distract from the actual bug fix, so I decided it would be best to first push them with a separate CR. Changes include:

- The main change is merging waitForRequestedEvent() and waitForRequestedEventSet(). These methods are quite big and almost identical. I had to add some more code to them for [JDK-8289765](https://bugs.openjdk.org/browse/JDK-8289765), and decided it was best to merge them first rather than making this code cloning situation even worse.
- Remove EventFilter.filtered() call when dealing with an uncaught exception event. These events are never filtered.
- Add complain() method. We already have a display() method so you can just call display() instead of log.display(), and it also adds the "EventHandler> " prefix to the output, so I though it would be good to do the same for log.complain() uses, especially since some of the uses also were adding the same prefix.
- Added a new EventListener that simply logs the event.

The remaining changes are just minor local edits whose purpose should be obvious.

If you need a bit of background on this code, read on. EventHandler has  run() method that continually queries the event queue for more JDI events. When they come in, the registered EventListeners all get various callbacks. First eventSetReceived() is called for each. Then eventReceived() is called for each listener for each Event in the EventSet.  If any eventReceived() returns true, that means the event was handled an no more listeners should be called. Finally, eventSetComplete() is called for each listener.

There are a number of default listeners registered that are always in place. See createDefaultListeners(). They aren't really of concern with this PR. The waitForRequestedEvent() and waitForRequestedEventSet() methods (now combined into waitForRequestedEventSetCommon()) also register listeners, with the main one being used to check for the specific event that has been requested. These listeners are pre-pended to the default list. Listeners are always called in reverse of the order added.

After setting up the listeners, waitForRequestedEventSetCommon() will block until a matching event has arrived. This is detected by the setting of en.set (and en.event). The listener will set them when the event matches, and this is done async from the thread that is running the run() method (remember, the run() method calls listener.eventSetRecieved()).

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

Commit messages:
 - Don't call EventFilters.filtered() for uncaught exception event.
 - EventHandler cleanup.

Changes: https://git.openjdk.org/jdk/pull/12568/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12568&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302516
  Stats: 140 lines in 1 file changed: 46 ins; 68 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/12568.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12568/head:pull/12568

PR: https://git.openjdk.org/jdk/pull/12568

From amenkov at openjdk.org  Sat Feb 25 02:24:05 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 25 Feb 2023 02:24:05 GMT
Subject: RFR: 8302516: Do some cleanup of nsk/share/jdi/EventHandler.java
In-Reply-To: <DZnbDYLa4-v0cuGjNyJV29sVefskU_03o_J5tY0nPPA=.ef68496c-54cd-422d-bfb4-50b09df562ea@github.com>
References: <DZnbDYLa4-v0cuGjNyJV29sVefskU_03o_J5tY0nPPA=.ef68496c-54cd-422d-bfb4-50b09df562ea@github.com>
Message-ID: <C0IVklVWfkdJhvnqO9wGu_dRRupx_qXbh1VUhURWJ-8=.94d8fb0c-2df2-4ece-9370-ebf0a8101750@github.com>

On Wed, 15 Feb 2023 00:13:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> While working on [JDK-8289765](https://bugs.openjdk.org/browse/JDK-8289765), I ended up doing a lot of cleanup of nsk/share/jdi/EventHandler.java, so much so that the changes distract from the actual bug fix, so I decided it would be best to first push them with a separate CR. Changes include:
> 
> - The main change is merging waitForRequestedEvent() and waitForRequestedEventSet(). These methods are quite big and almost identical. I had to add some more code to them for [JDK-8289765](https://bugs.openjdk.org/browse/JDK-8289765), and decided it was best to merge them first rather than making this code cloning situation even worse.
> - Remove EventFilter.filtered() call when dealing with an uncaught exception event. These events are never filtered.
> - Add complain() method. We already have a display() method so you can just call display() instead of log.display(), and it also adds the "EventHandler> " prefix to the output, so I though it would be good to do the same for log.complain() uses, especially since some of the uses also were adding the same prefix.
> - Added a new EventListener that simply logs the event.
> 
> The remaining changes are just minor local edits whose purpose should be obvious.
> 
> If you need a bit of background on this code, read on. EventHandler has  run() method that continually queries the event queue for more JDI events. When they come in, the registered EventListeners all get various callbacks. First eventSetReceived() is called for each. Then eventReceived() is called for each listener for each Event in the EventSet.  If any eventReceived() returns true, that means the event was handled an no more listeners should be called. Finally, eventSetComplete() is called for each listener.
> 
> There are a number of default listeners registered that are always in place. See createDefaultListeners(). They aren't really of concern with this PR. The waitForRequestedEvent() and waitForRequestedEventSet() methods (now combined into waitForRequestedEventSetCommon()) also register listeners, with the main one being used to check for the specific event that has been requested. These listeners are pre-pended to the default list. Listeners are always called in reverse of the order added.
> 
> After setting up the listeners, waitForRequestedEventSetCommon() will block until a matching event has arrived. This is detected by the setting of en.set (and en.event). The listener will set them when the event matches, and this is done async from the thread that is running the run() method (remember, the run() method calls listener.eventSetRecieved()).

Marked as reviewed by amenkov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12568

From dholmes at openjdk.org  Sat Feb 25 03:11:10 2023
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 25 Feb 2023 03:11:10 GMT
Subject: RFR: 8303102: jcmd: ManagementAgent.status truncates the text
 longer than O_BUFLEN [v2]
In-Reply-To: <dgdAK_yce5DgEamcWoiiDKJXn2pDRZ9jpTgmDfKaDxA=.c476d3c5-b782-44b8-8913-9940b86cf407@github.com>
References: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
 <dgdAK_yce5DgEamcWoiiDKJXn2pDRZ9jpTgmDfKaDxA=.c476d3c5-b782-44b8-8913-9940b86cf407@github.com>
Message-ID: <SCVFc34vu-CJMM3SjYW5OXcbmeppgO4wJGzDAQ0N4do=.edc778ae-9f99-49e5-af80-7d68ad07c6fe@github.com>

On Thu, 23 Feb 2023 17:06:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Implementation of the "ManagementAgent.status" indirectly depends on the size of "O_BUFLEN".
>> 
>> The root cause is usage of [print_cr()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L153) which may [truncate](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L101) the output.
>> 
>> The solution is similar to the [JDK-8263640](https://bugs.openjdk.org/browse/JDK-8263640). see discussion about that approach https://github.com/openjdk/jdk/pull/4616
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update JMXStatusTest.java

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12724

From jwaters at openjdk.org  Sat Feb 25 15:32:03 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 25 Feb 2023 15:32:03 GMT
Subject: RFR: 8303169: Remove Windows specific workaround from libdt
In-Reply-To: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
References: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
Message-ID: <Kfsx8qQePY0jJnZBnXkV_j16xL4K0OLNw9bMAqVmZnQ=.b7b9b938-d753-4d46-b937-8c0fe9ad115a@github.com>

On Fri, 24 Feb 2023 15:36:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> We no longer need to define PrId64 ourselves since the Visual C++ compiler supports inttypes.h on the only versions we support, so we can just replace it with an include to the standard header instead

Little bit of a quick note from me before integration, I found it strange that for other platforms no inttypes.h include was needed for PRId64 to work properly, but after more in depth checking to see whether the inttypes.h include should go elsewhere to match where the other platforms have it, apparently this is a Windows only library, making it all the more strange that a Windows conditional define was here at all in the first place. Just to be extra safe, is there confirmation that this will always be Windows only, and the the shared native code is somehow a mistake or leftover from long ago?

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

PR: https://git.openjdk.org/jdk/pull/12744

From jwaters at openjdk.org  Sun Feb 26 15:13:10 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 26 Feb 2023 15:13:10 GMT
Subject: RFR: 8303169: Remove Windows specific workaround from libdt
In-Reply-To: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
References: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
Message-ID: <iNDPVCNNmMoDjIRg6C4odhsKI2FDgDU_moKKkX86-UY=.044fcee3-538d-45f7-8ccd-214617daa133@github.com>

On Fri, 24 Feb 2023 15:36:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> We no longer need to define PrId64 ourselves since the Visual C++ compiler supports inttypes.h on the only versions we support, so we can just replace it with an include to the standard header instead

@RealCLanger Sorry for the ping, just wanted to check since you're the original commit Author for the format string, is there someplace else where inttypes.h or stdint.h is included or should be included that I missed?

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

PR: https://git.openjdk.org/jdk/pull/12744

From clanger at openjdk.org  Sun Feb 26 21:05:04 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Sun, 26 Feb 2023 21:05:04 GMT
Subject: RFR: 8303169: Remove Windows specific workaround from libdt
In-Reply-To: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
References: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
Message-ID: <R2xIw165tCg0dt6ZjY9ROwf-z8_hMMRx5ECQt9WFeUA=.7ab58699-45a1-45b0-9c96-2f8209ef5334@github.com>

On Fri, 24 Feb 2023 15:36:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> We no longer need to define PrId64 ourselves since the Visual C++ compiler supports inttypes.h on the only versions we support, so we can just replace it with an include to the standard header instead

Marked as reviewed by clanger (Reviewer).

PS I guess you should update the copyright year before pushing.

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

PR: https://git.openjdk.org/jdk/pull/12744

From clanger at openjdk.org  Sun Feb 26 21:05:05 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Sun, 26 Feb 2023 21:05:05 GMT
Subject: RFR: 8303169: Remove Windows specific workaround from libdt
In-Reply-To: <iNDPVCNNmMoDjIRg6C4odhsKI2FDgDU_moKKkX86-UY=.044fcee3-538d-45f7-8ccd-214617daa133@github.com>
References: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
 <iNDPVCNNmMoDjIRg6C4odhsKI2FDgDU_moKKkX86-UY=.044fcee3-538d-45f7-8ccd-214617daa133@github.com>
Message-ID: <ZbASiFlfQQqY79ExaLlNQjDVltHsgLmugg2WLUEke8k=.1fd4ffa5-6dc0-4eeb-bf7a-142a30d48f57@github.com>

On Sun, 26 Feb 2023 15:10:08 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> @RealCLanger Sorry for the ping, just wanted to check since you're the original commit Author for the format string, is there someplace else where inttypes.h or stdint.h is included or should be included that I missed?

Hah, that was a long time ago. ? I think this change is fine - and I'm not aware of other places. But that doesn't mean a lot. ?

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

PR: https://git.openjdk.org/jdk/pull/12744

From serb at openjdk.org  Sun Feb 26 23:40:11 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 26 Feb 2023 23:40:11 GMT
Subject: Integrated: 8303102: jcmd: ManagementAgent.status truncates the text
 longer than O_BUFLEN
In-Reply-To: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
References: <n_Lo2CQw1S68JUjBypLTP5Ia5uJlf0KKfOU6ptMvrt8=.271ae232-9cf8-4d78-af9f-b4dd3bd16ea6@github.com>
Message-ID: <SEUQjc_XVWtbv2xDmQolMPlAw_Ad40DN5rkO1S_QJSU=.63ded5a6-b5fd-43e8-a21e-a5dbbdb34a92@github.com>

On Thu, 23 Feb 2023 05:16:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Implementation of the "ManagementAgent.status" indirectly depends on the size of "O_BUFLEN".
> 
> The root cause is usage of [print_cr()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L153) which may [truncate](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/ostream.cpp#L101) the output.
> 
> The solution is similar to the [JDK-8263640](https://bugs.openjdk.org/browse/JDK-8263640). see discussion about that approach https://github.com/openjdk/jdk/pull/4616

This pull request has now been integrated.

Changeset: a43931b7
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a43931b79cb25d218e8f9b4d4f3a106f59cb2d37
Stats:     4 lines in 2 files changed: 1 ins; 0 del; 3 mod

8303102: jcmd: ManagementAgent.status truncates the text longer than O_BUFLEN

Reviewed-by: dholmes

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

PR: https://git.openjdk.org/jdk/pull/12724

From yyang at openjdk.org  Mon Feb 27 06:20:06 2023
From: yyang at openjdk.org (Yi Yang)
Date: Mon, 27 Feb 2023 06:20:06 GMT
Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different
 platforms [v6]
In-Reply-To: <27esMViORNgCNjS04-6IJfCHcva5NmbCZ3p6yYP2OjQ=.2e294967-6467-4a07-b9b7-004545a9584b@github.com>
References: <caqEOVOGSxIglZBVTs7nNyjOWDzjblUURwIQhzi_8Lk=.2552d17b-d72f-4ebf-ae46-acdece170507@github.com>
 <27esMViORNgCNjS04-6IJfCHcva5NmbCZ3p6yYP2OjQ=.2e294967-6467-4a07-b9b7-004545a9584b@github.com>
Message-ID: <cGW8k-HKTY6OOhoUqN60qEzMA7bWx1MMWg2BLSa2sA0=.7b760203-be1c-403b-b522-bc518608573e@github.com>

On Tue, 10 Jan 2023 10:49:52 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> harmless refactor to share code across different platforms of VirtualMachineImpl:
>> 1. Shared code to process command response after requesting a command execution
>> 2. Read functionality in SocketInputStream can be reused
>
> Yi Yang has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - format
>  - Merge branch 'jdk_virtualmachienimpl' of github.com:y1yang0/jdk into jdk_virtualmachienimpl
>  - -1 to vmid

Can I have any review? Thanks.

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

PR: https://git.openjdk.org/jdk/pull/11823

From jwaters at openjdk.org  Mon Feb 27 07:50:04 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 27 Feb 2023 07:50:04 GMT
Subject: RFR: 8303169: Remove Windows specific workaround from libdt
In-Reply-To: <R2xIw165tCg0dt6ZjY9ROwf-z8_hMMRx5ECQt9WFeUA=.7ab58699-45a1-45b0-9c96-2f8209ef5334@github.com>
References: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
 <R2xIw165tCg0dt6ZjY9ROwf-z8_hMMRx5ECQt9WFeUA=.7ab58699-45a1-45b0-9c96-2f8209ef5334@github.com>
Message-ID: <zZUSbs-XUl04i-ocD0vwEGris5qibeRC5iY54h9qczk=.b6cfdcb9-697b-4daa-a6b5-3948bc2bd769@github.com>

On Sun, 26 Feb 2023 21:02:43 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> PS I guess you should update the copyright year before pushing.

Ah right, thanks for the reminder



> > @RealCLanger Sorry for the ping, just wanted to check since you're the original commit Author for the format string, is there someplace else where inttypes.h or stdint.h is included or should be included that I missed?
> 
> Hah, that was a long time ago. ? I think this change is fine - and I'm not aware of other places. But that doesn't mean a lot. ?

I see haha, I was just worried since that's what the ifdef implied. Strange that the check was a `#ifdef _WIN32` though since this is Windows only code (in fact I'm wondering why this file and the others in the same directory as it is in shared native code at all)

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

PR: https://git.openjdk.org/jdk/pull/12744

From jwaters at openjdk.org  Mon Feb 27 08:29:37 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 27 Feb 2023 08:29:37 GMT
Subject: RFR: 8303169: Remove Windows specific workaround from libdt [v2]
In-Reply-To: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
References: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
Message-ID: <QpRM9KcABWSxtp-ReJ8elDeUKQDLigMl8OzbiVm7J1w=.3e9bef82-10ba-4f13-ade9-cbed2f33dd6c@github.com>

> We no longer need to define PrId64 ourselves since the Visual C++ compiler supports inttypes.h on the only versions we support, so we can just replace it with an include to the standard header instead

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

 - Copyright
 - Merge branch 'openjdk:master' into patch-6
 - Remove Windows specific workaround from libdt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12744/files
  - new: https://git.openjdk.org/jdk/pull/12744/files/e6b8b2a4..ab48a347

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12744&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12744&range=00-01

  Stats: 1102 lines in 43 files changed: 426 ins; 452 del; 224 mod
  Patch: https://git.openjdk.org/jdk/pull/12744.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12744/head:pull/12744

PR: https://git.openjdk.org/jdk/pull/12744

From jwaters at openjdk.org  Mon Feb 27 13:26:27 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 27 Feb 2023 13:26:27 GMT
Subject: RFR: 8303169: Remove Windows specific workaround from libdt [v2]
In-Reply-To: <QpRM9KcABWSxtp-ReJ8elDeUKQDLigMl8OzbiVm7J1w=.3e9bef82-10ba-4f13-ade9-cbed2f33dd6c@github.com>
References: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
 <QpRM9KcABWSxtp-ReJ8elDeUKQDLigMl8OzbiVm7J1w=.3e9bef82-10ba-4f13-ade9-cbed2f33dd6c@github.com>
Message-ID: <v31szDCPLEo12xHXUTyVY-2qbtfZdm_2tB8KETRBb-8=.2985e4be-30c0-4533-9880-33e87ee16b45@github.com>

On Mon, 27 Feb 2023 08:29:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We no longer need to define PrId64 ourselves since the Visual C++ compiler supports inttypes.h on the only versions we support, so we can just replace it with an include to the standard header instead
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Copyright
>  - Merge branch 'openjdk:master' into patch-6
>  - Remove Windows specific workaround from libdt

Ah I see, was the initial commit made with the assumption that inttypes.h was already included? It's just a final confirmation before integration

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

PR: https://git.openjdk.org/jdk/pull/12744

From clanger at openjdk.org  Mon Feb 27 13:43:35 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 27 Feb 2023 13:43:35 GMT
Subject: RFR: 8303169: Remove Windows specific workaround from libdt [v2]
In-Reply-To: <v31szDCPLEo12xHXUTyVY-2qbtfZdm_2tB8KETRBb-8=.2985e4be-30c0-4533-9880-33e87ee16b45@github.com>
References: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
 <QpRM9KcABWSxtp-ReJ8elDeUKQDLigMl8OzbiVm7J1w=.3e9bef82-10ba-4f13-ade9-cbed2f33dd6c@github.com>
 <v31szDCPLEo12xHXUTyVY-2qbtfZdm_2tB8KETRBb-8=.2985e4be-30c0-4533-9880-33e87ee16b45@github.com>
Message-ID: <pN9KusujqlyQJ0V1tJBzY07v0URO7yOYpT7mPV6qoLs=.7f74c12b-e06a-46f2-a44d-d1f559c6f695@github.com>

On Mon, 27 Feb 2023 13:23:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Ah I see, was the initial commit made with the assumption that inttypes.h was already included? It's just a final confirmation before integration

Could be.

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

PR: https://git.openjdk.org/jdk/pull/12744

From jwaters at openjdk.org  Mon Feb 27 15:39:28 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 27 Feb 2023 15:39:28 GMT
Subject: Integrated: 8303169: Remove Windows specific workaround from libdt
In-Reply-To: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
References: <yattfvRCw806SkveUvN9K6xe-f_te1zvpGFkyi4IyE0=.39da0e85-0c93-439d-af6f-567a52a2699e@github.com>
Message-ID: <_-vpi1DXDouUeSST0avySem1_H4XNMIQMiEZYfTzblA=.f37fcb62-46fa-43af-8bbd-9712d61a5725@github.com>

On Fri, 24 Feb 2023 15:36:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> We no longer need to define PrId64 ourselves since the Visual C++ compiler supports inttypes.h on the only versions we support, so we can just replace it with an include to the standard header instead

This pull request has now been integrated.

Changeset: 2fe4e5f8
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2fe4e5f8d76e20e34d6022417589d521483c78be
Stats:     6 lines in 1 file changed: 1 ins; 4 del; 1 mod

8303169: Remove Windows specific workaround from libdt

Reviewed-by: cjplummer, sspitsyn, clanger

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

PR: https://git.openjdk.org/jdk/pull/12744

From cjplummer at openjdk.org  Mon Feb 27 17:51:10 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 27 Feb 2023 17:51:10 GMT
Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different
 platforms [v6]
In-Reply-To: <NpBBXEJTrg33Hm35qcqw-flnKQOfwe-gmZlSXK5zkgU=.2513e20f-c017-4cf1-bc2c-87f6de09eafe@github.com>
References: <caqEOVOGSxIglZBVTs7nNyjOWDzjblUURwIQhzi_8Lk=.2552d17b-d72f-4ebf-ae46-acdece170507@github.com>
 <27esMViORNgCNjS04-6IJfCHcva5NmbCZ3p6yYP2OjQ=.2e294967-6467-4a07-b9b7-004545a9584b@github.com>
 <Exftkn6hAHTDhuhy2OkPasZUKbzA_Wb8QwgAaOx080s=.2e479e24-6e3a-4690-abd0-d01a7dbb21c0@github.com>
 <NpBBXEJTrg33Hm35qcqw-flnKQOfwe-gmZlSXK5zkgU=.2513e20f-c017-4cf1-bc2c-87f6de09eafe@github.com>
Message-ID: <td5-bYeLKOXqdB885JvuzWFG4tmP74i5u3QBZ5gt0C4=.1dae252f-5568-4d5f-aff3-ea415affb429@github.com>

On Wed, 15 Feb 2023 06:41:17 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 455:
>> 
>>> 453:             if (fd != -1) {
>>> 454:                 close(fd);
>>> 455:             }
>> 
>> There used to be logic to set `fd` (previously called `s`) to -1 during the close operation. Is that no longer needed?
>
> Hi @plummercj , sorry for late reply. 
> 
> I don't see why we need it because this method is protected by synchronized. fd is only set by ctor.

You will end up leaving fd set even after the close completes.  A subsequent close (which I assume should never happen) would end up with an IOException. Previously close would end up not doing anything when called again, and simply return with no error. I'm not sure which is the best behavior in this case, but it is a change in behavior.

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

PR: https://git.openjdk.org/jdk/pull/11823

From aturbanov at openjdk.org  Mon Feb 27 21:00:19 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 27 Feb 2023 21:00:19 GMT
Subject: RFR: 8303267: Prefer ArrayList to LinkedList in ConcurrentLocksPrinter
Message-ID: <hNxZq6g3bqTawBA7U6QjJPqg7eqskAus2ykWURXZcRE=.7c2ac438-08cb-4c71-a658-feac3c818f86@github.com>

LinkedList is used as value in `sun.jvm.hotspot.runtime.ConcurrentLocksPrinter#locksMap` Map.
There is only add/iterator calls on this lists. No removes from the head or something like this. Not sure why LinkedList was used, but ArrayList should be preferred as more efficient and widely used collection.

Also I've done some related code cleaned:
1. Mark field `locksMap` as final
2. Use Map.computeIfAbsent
3. Use enhanced-for cycle instead of `for` with iterator

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

Commit messages:
 - [PATCH] Prefer ArrayList to LinkedList in ConcurrentLocksPrinter

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

PR: https://git.openjdk.org/jdk/pull/12763

From cjplummer at openjdk.org  Mon Feb 27 21:15:02 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 27 Feb 2023 21:15:02 GMT
Subject: RFR: 8302516: Do some cleanup of nsk/share/jdi/EventHandler.java
In-Reply-To: <DZnbDYLa4-v0cuGjNyJV29sVefskU_03o_J5tY0nPPA=.ef68496c-54cd-422d-bfb4-50b09df562ea@github.com>
References: <DZnbDYLa4-v0cuGjNyJV29sVefskU_03o_J5tY0nPPA=.ef68496c-54cd-422d-bfb4-50b09df562ea@github.com>
Message-ID: <z0SnRN-OM6fSAncj7u43SMBLuUVCisrI4RB6InaXnOE=.719d0111-dc42-4a58-b795-0e7410d9b3af@github.com>

On Wed, 15 Feb 2023 00:13:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> While working on [JDK-8289765](https://bugs.openjdk.org/browse/JDK-8289765), I ended up doing a lot of cleanup of nsk/share/jdi/EventHandler.java, so much so that the changes distract from the actual bug fix, so I decided it would be best to first push them with a separate CR. Changes include:
> 
> - The main change is merging waitForRequestedEvent() and waitForRequestedEventSet(). These methods are quite big and almost identical. I had to add some more code to them for [JDK-8289765](https://bugs.openjdk.org/browse/JDK-8289765), and decided it was best to merge them first rather than making this code cloning situation even worse.
> - Remove EventFilter.filtered() call when dealing with an uncaught exception event. These events are never filtered.
> - Add complain() method. We already have a display() method so you can just call display() instead of log.display(), and it also adds the "EventHandler> " prefix to the output, so I though it would be good to do the same for log.complain() uses, especially since some of the uses also were adding the same prefix.
> - Added a new EventListener that simply logs the event.
> 
> The remaining changes are just minor local edits whose purpose should be obvious.
> 
> If you need a bit of background on this code, read on. EventHandler has  run() method that continually queries the event queue for more JDI events. When they come in, the registered EventListeners all get various callbacks. First eventSetReceived() is called for each. Then eventReceived() is called for each listener for each Event in the EventSet.  If any eventReceived() returns true, that means the event was handled an no more listeners should be called. Finally, eventSetComplete() is called for each listener.
> 
> There are a number of default listeners registered that are always in place. See createDefaultListeners(). They aren't really of concern with this PR. The waitForRequestedEvent() and waitForRequestedEventSet() methods (now combined into waitForRequestedEventSetCommon()) also register listeners, with the main one being used to check for the specific event that has been requested. These listeners are pre-pended to the default list. Listeners are always called in reverse of the order added.
> 
> After setting up the listeners, waitForRequestedEventSetCommon() will block until a matching event has arrived. This is detected by the setting of en.set (and en.event). The listener will set them when the event matches, and this is done async from the thread that is running the run() method (remember, the run() method calls listener.eventSetRecieved()).

Thanks Alex!

Can I get one more review please?

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

PR: https://git.openjdk.org/jdk/pull/12568

From cjplummer at openjdk.org  Mon Feb 27 21:15:01 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 27 Feb 2023 21:15:01 GMT
Subject: RFR: 8303267: Prefer ArrayList to LinkedList in
 ConcurrentLocksPrinter
In-Reply-To: <hNxZq6g3bqTawBA7U6QjJPqg7eqskAus2ykWURXZcRE=.7c2ac438-08cb-4c71-a658-feac3c818f86@github.com>
References: <hNxZq6g3bqTawBA7U6QjJPqg7eqskAus2ykWURXZcRE=.7c2ac438-08cb-4c71-a658-feac3c818f86@github.com>
Message-ID: <SeVuMaCsUtLxFuLlRARKCNYGtuwNS_TI69HGgCioEpQ=.35cb0194-d675-4132-a2c3-facc009f365e@github.com>

On Mon, 27 Feb 2023 12:54:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> LinkedList is used as value in `sun.jvm.hotspot.runtime.ConcurrentLocksPrinter#locksMap` Map.
> There is only add/iterator calls on this lists. No removes from the head or something like this. Not sure why LinkedList was used, but ArrayList should be preferred as more efficient and widely used collection.
> 
> Also I've done some related code cleaned:
> 1. Mark field `locksMap` as final
> 2. Use Map.computeIfAbsent
> 3. Use enhanced-for cycle instead of `for` with iterator

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12763

From yyang at openjdk.org  Tue Feb 28 06:17:29 2023
From: yyang at openjdk.org (Yi Yang)
Date: Tue, 28 Feb 2023 06:17:29 GMT
Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different
 platforms [v7]
In-Reply-To: <caqEOVOGSxIglZBVTs7nNyjOWDzjblUURwIQhzi_8Lk=.2552d17b-d72f-4ebf-ae46-acdece170507@github.com>
References: <caqEOVOGSxIglZBVTs7nNyjOWDzjblUURwIQhzi_8Lk=.2552d17b-d72f-4ebf-ae46-acdece170507@github.com>
Message-ID: <O7XMSEQq6dXiW5-RLSXwrE6I3xELU_mYBDPak3_pt1g=.7c5e5c4d-0c7e-4e1d-a143-365581f65463@github.com>

> harmless refactor to share code across different platforms of VirtualMachineImpl:
> 1. Shared code to process command response after requesting a command execution
> 2. Read functionality in SocketInputStream can be reused

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

  fd set -1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11823/files
  - new: https://git.openjdk.org/jdk/pull/11823/files/6077ae5e..6033fcc4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11823&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11823&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/11823

From sspitsyn at openjdk.org  Tue Feb 28 07:00:01 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 28 Feb 2023 07:00:01 GMT
Subject: RFR: 8303267: Prefer ArrayList to LinkedList in
 ConcurrentLocksPrinter
In-Reply-To: <hNxZq6g3bqTawBA7U6QjJPqg7eqskAus2ykWURXZcRE=.7c2ac438-08cb-4c71-a658-feac3c818f86@github.com>
References: <hNxZq6g3bqTawBA7U6QjJPqg7eqskAus2ykWURXZcRE=.7c2ac438-08cb-4c71-a658-feac3c818f86@github.com>
Message-ID: <hhXQwVIleQS-kexyNqoh92theYiRnxUuJk8kGlSh0PY=.e6726dd0-821e-498a-af77-2b804d985cd8@github.com>

On Mon, 27 Feb 2023 12:54:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> LinkedList is used as value in `sun.jvm.hotspot.runtime.ConcurrentLocksPrinter#locksMap` Map.
> There is only add/iterator calls on this lists. No removes from the head or something like this. Not sure why LinkedList was used, but ArrayList should be preferred as more efficient and widely used collection.
> 
> Also I've done some related code cleaned:
> 1. Mark field `locksMap` as final
> 2. Use Map.computeIfAbsent
> 3. Use enhanced-for cycle instead of `for` with iterator

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12763

From alanb at openjdk.org  Tue Feb 28 10:37:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Feb 2023 10:37:59 GMT
Subject: RFR: 8303242: ThreadMXBean issues with virtual threads
Message-ID: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com>

This PR covers a number of issues with j.l.management.ThreadMXBean, and the JDK-specific extension c.s.management.ThreadMXBean, when there are virtual threads in use.

As background, ThreadMXBean was re-specified in Java 19 to support the monitoring and management of platform threads. It does not support virtual threads as their potential number, and the need to find a thread by id, does not make sense for this API. At the same time, JDK 19 introduced an alternative implementation of virtual threads for Zero and ports without continuations support in the VM. This alternative implementation of virtual threads means a JavaThread per virtual thread and so requires filtering to ensure that the API behaves as specified. For the initial implementation, the filtering was done in the ThreadMXBean implementation. That works for most functions but not for getThreadXXXTime(long[]) and getThreadAllocatedBytes(long[]) where the filtering needs to be pushed down to the management code.

The changes in this PR move the filtering to the management functions (jmm_XXX) so they only return information about platform threads. There are some minor adjustments to the API docs (see linked CSR). Test coverage is expanded as we didn't include tests for c.s.management.ThreadMXBean with virtual threads in JDK 19.

Testing tier1-3 (jdk_management test group is in test/jdk/:tier3), plus sanity checking that --with-jvm-variants=minimal builds as some of this code is not compiled in with minimal VM builds.

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

Commit messages:
 - Fix minimal build
 - Fix minimal build
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/12762/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12762&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303242
  Stats: 487 lines in 8 files changed: 285 ins; 131 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/12762.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12762/head:pull/12762

PR: https://git.openjdk.org/jdk/pull/12762

From alanb at openjdk.org  Tue Feb 28 14:31:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Feb 2023 14:31:22 GMT
Subject: RFR: 8302615: make JVMTI thread cpu time functions optional for
 virtual threads
In-Reply-To: <N8X4H8wU3Yu8FFzwl9wSxTj6J8P8fM9JfutH1lh6uD0=.9983bb99-b5dc-4d08-8af5-7863a9c2bda1@github.com>
References: <N8X4H8wU3Yu8FFzwl9wSxTj6J8P8fM9JfutH1lh6uD0=.9983bb99-b5dc-4d08-8af5-7863a9c2bda1@github.com>
Message-ID: <tp-aSuRBEfhDr6HyyCmbCetGjuXC7CdQl5eQw28IzoM=.9c99e973-3772-4077-8deb-09bb072ad535@github.com>

On Thu, 16 Feb 2023 18:05:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a minor JVM TI spec update for two timer functions `GetCurrentThreadCpuTime` and `GetThreadCpuTime` to allow implementations to support virtual threads.
> 
> The CSR is:
> [JDK-8302616](https://bugs.openjdk.org/browse/JDK-8302616): make JVMTI thread cpu time functions optional for virtual threads
> 
> No testing is needed.

I've just spotted that we missed some text:

GetCurrentThreadCpuTime has "The current thread may not be a virtual thread".

GetThreadCpuTime has "The thread may not be a virtual thread".

The changes that have been integrated allow these functions to support CPU time measurement so I think we will need to adjust both of these sentences in a follow up issue.

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

PR: https://git.openjdk.org/jdk/pull/12604

From cjplummer at openjdk.org  Tue Feb 28 19:20:12 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 28 Feb 2023 19:20:12 GMT
Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different
 platforms [v7]
In-Reply-To: <O7XMSEQq6dXiW5-RLSXwrE6I3xELU_mYBDPak3_pt1g=.7c5e5c4d-0c7e-4e1d-a143-365581f65463@github.com>
References: <caqEOVOGSxIglZBVTs7nNyjOWDzjblUURwIQhzi_8Lk=.2552d17b-d72f-4ebf-ae46-acdece170507@github.com>
 <O7XMSEQq6dXiW5-RLSXwrE6I3xELU_mYBDPak3_pt1g=.7c5e5c4d-0c7e-4e1d-a143-365581f65463@github.com>
Message-ID: <w9-4LgGDDeh--o0lYKmNj13FFG4elRPlyB-vZ3zLn5U=.069215fc-a24c-40d2-b896-912d077b2686@github.com>

On Tue, 28 Feb 2023 06:17:29 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> harmless refactor to share code across different platforms of VirtualMachineImpl:
>> 1. Shared code to process command response after requesting a command execution
>> 2. Read functionality in SocketInputStream can be reused
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fd set -1

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11823

From mchung at openjdk.org  Tue Feb 28 21:10:08 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 28 Feb 2023 21:10:08 GMT
Subject: RFR: 8303242: ThreadMXBean issues with virtual threads
In-Reply-To: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com>
References: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com>
Message-ID: <r2bT4hw4Tz4GrUCZFkwhkc-SBUK6-G5rcNrt-h-G1q4=.f6d1f0f6-a4a4-41b2-b63d-3ef958500c4b@github.com>

On Mon, 27 Feb 2023 12:23:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This PR covers a number of issues with j.l.management.ThreadMXBean, and the JDK-specific extension c.s.management.ThreadMXBean, when there are virtual threads in use.
> 
> As background, ThreadMXBean was re-specified in Java 19 to support the monitoring and management of platform threads. It does not support virtual threads as their potential number, and the need to find a thread by id, does not make sense for this API. At the same time, JDK 19 introduced an alternative implementation of virtual threads for Zero and ports without continuations support in the VM. This alternative implementation of virtual threads means a JavaThread per virtual thread and so requires filtering to ensure that the API behaves as specified. For the initial implementation, the filtering was done in the ThreadMXBean implementation. That works for most functions but not for getThreadXXXTime(long[]) and getThreadAllocatedBytes(long[]) where the filtering needs to be pushed down to the management code.
> 
> The changes in this PR move the filtering to the management functions (jmm_XXX) so they only return information about platform threads. There are some minor adjustments to the API docs (see linked CSR). Test coverage is expanded as we didn't include tests for c.s.management.ThreadMXBean with virtual threads in JDK 19.
> 
> Testing tier1-3 (jdk_management test group is in test/jdk/:tier3), plus sanity checking that --with-jvm-variants=minimal builds as some of this code is not compiled in with minimal VM builds.

The "Thread CPU time" section in the class spec of ThreadMXBean can also be clarified.

src/java.management/share/classes/java/lang/management/ThreadMXBean.java line 529:

> 527:     /**
> 528:      * Tests if the Java virtual machine implementation supports CPU time
> 529:      * measurement for any platform thread.

This change can also apply in `@return` (line 538)

test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 258:

> 256:             long tid = Thread.currentThread().threadId();
> 257:             long cpuTime = bean.getThreadCpuTime(tid);
> 258:             assertEquals(-1L, cpuTime);

Am I correct that `getThreadCpuTime(tid)` returns -1 for the current thread is a virtual thread whereas `getCurrentThreadCpuTime` throws UOE in the current implementation?

`getCurrentThreadCpuTime` is specified to be equivalent to calling `getThreadCpuTime(Thread.currentThread().threadId()`.

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

PR: https://git.openjdk.org/jdk/pull/12762

From manuel.alvarezalvarez at datadoghq.com  Tue Feb 14 11:14:54 2023
From: manuel.alvarezalvarez at datadoghq.com (=?UTF-8?B?TWFudWVsIMOBbHZhcmV6IMOBbHZhcmV6?=)
Date: Tue, 14 Feb 2023 11:14:54 -0000
Subject: Missing EnclosingMethod attribute in JvmtiClassFileReconstituter.cpp
Message-ID: <CAH4ghTNUTi0T-jqfBqEd71EVXvFm8LLfF09Y_czn6=xLL=E1+Q@mail.gmail.com>

Dear all,

When dealing with enclosed classes, frameworks like bytebuddy use the
EnclosingMethod attribute in order to discover generic type argument
bounds. When retransforming a class, the JvmtiClassFileReconstituter.cpp
omits the enclosing attributes (they are available in the java.lang.Class
object) so the bytes received by the transformer are missing the attribute
potentially causing issues downstream.

Are there any strong reasons why these attributes are not written by the
JvmtiClassFileReconstituter?

Kind regards and thank you in advance,

Manuel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20230214/e53678ab/attachment-0001.htm>