On Thu, 30 Jun 2022 14:54:47 GMT, Zhengyu Gu wrote:
>> I just noticed the test is being added to a newly created
>> hotspot/jtreg/serviciability/jdi directory. It should be placed in one of
>> the existing jdi test locations, either nsk/jdi or jdk/com/sun/jdi. I think
>> the latter would be be
> This fixes a bug in the debug agent when there is a request to suspend a
> virtual thread that has already terminated. The issue was that unless the
> debug agent was currently under a "suspend all", it would not properly put
> the virtual thread on the `otherThreads` list, and instead added i
On Thu, 30 Jun 2022 23:50:57 GMT, Jesper Wilhelmsson
wrote:
> Forwardport JDK 19 -> JDK 20
This pull request has now been integrated.
Changeset: 918068a1
Author:Jesper Wilhelmsson
URL:
https://git.openjdk.org/jdk/commit/918068a115efee7d439084b6d743cab5193bd943
Stats: 4 lines in
On Thu, 30 Jun 2022 16:27:12 GMT, Alan Bateman wrote:
>> The @run suggestion doesn't work. There are two issues. First, it does not
>> trigger jtreg to use TestScaffold.main(), which is what normally happens
>> when you use TEST_VM_OPTS="-Dmain.wrapper=Virtual". So the end result is
>> that th
> This fixes a bug in the debug agent when there is a request to suspend a
> virtual thread that has already terminated. The issue was that unless the
> debug agent was currently under a "suspend all", it would not properly put
> the virtual thread on the `otherThreads` list, and instead added i
Forwardport JDK 19 -> JDK 20
-
Commit messages:
- Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
- 8289278: Suspend/ResumeAllVirtualThreads need both can_suspend and
can_support_virtual_threads
The merge commit only contains trivial merges, so no merge-specific webre
> Test has been problemlisted for a long time due to intermittent failures.
>
> This is a difficult test as it tries to monitor usage thresholds on Memory
> Pools which are outside its control.
> Not just Java heap pools, where the allocation it makes may or may not affect
> a particuclar pool,
On Wed, 29 Jun 2022 09:57:29 GMT, Kevin Walls wrote:
> More context in the bug, but there's no evidence that this test should still
> be problemlisted.
>
> Adding enableVerbose in the test itself should still keep this trivial:
> seeing what actually happened in a test that was once labelled a
On Tue, 28 Jun 2022 11:43:42 GMT, Kevin Walls wrote:
>> Test has been problemlisted for a long time due to intermittent failures.
>>
>> This is a difficult test as it tries to monitor usage thresholds on Memory
>> Pools which are outside its control.
>> Not just Java heap pools, where the alloc
On Wed, 29 Jun 2022 09:57:29 GMT, Kevin Walls wrote:
> More context in the bug, but there's no evidence that this test should still
> be problemlisted.
>
> Adding enableVerbose in the test itself should still keep this trivial:
> seeing what actually happened in a test that was once labelled a
On Thu, 30 Jun 2022 18:39:58 GMT, Harold Seigel wrote:
> Please review this small fix to change range constrained JVM runtime options
> from 64 bits to 32 bits. This fix was tested with Mach5 tiers 1-2 on Linux,
> Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
>
> Thanks, Harold
Look
On Wed, 29 Jun 2022 09:57:29 GMT, Kevin Walls wrote:
> More context in the bug, but there's no evidence that this test should still
> be problemlisted.
>
> Adding enableVerbose in the test itself should still keep this trivial:
> seeing what actually happened in a test that was once labelled a
On Tue, 28 Jun 2022 11:43:42 GMT, Kevin Walls wrote:
>> Test has been problemlisted for a long time due to intermittent failures.
>>
>> This is a difficult test as it tries to monitor usage thresholds on Memory
>> Pools which are outside its control.
>> Not just Java heap pools, where the alloc
Please review this small fix to change range constrained JVM runtime options
from 64 bits to 32 bits. This fix was tested with Mach5 tiers 1-2 on Linux,
Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
Thanks, Harold
-
Commit messages:
- 8289534: Change 'uncomplicated' hots
> This fixes a bug in the debug agent when there is a request to suspend a
> virtual thread that has already terminated. The issue was that unless the
> debug agent was currently under a "suspend all", it would not properly put
> the virtual thread on the `otherThreads` list, and instead added i
On Thu, 30 Jun 2022 16:06:52 GMT, Chris Plummer wrote:
>> The test uses a platform thread by default so it's not testing the issue in
>> JDK-8287847. The suggestion is to have it re-run with the system property
>> set, like this:
>>
>> @run main/othervm SuspendAfterDeath
>> @run main/othervm
On Thu, 30 Jun 2022 06:34:30 GMT, Alan Bateman wrote:
>> Yes, it requires `-Dmain.wrapper=Virtual`, and that was intentional. My
>> thinking was that we don't have any com/sun/jdi tests that do any virtual
>> thread testing unless run with `-Dmain.wrapper=Virtual`, so why should this
>> test b
On Thu, 30 Jun 2022 15:06:41 GMT, Chris Plummer wrote:
>> I'm just pointing out that initialising breakpointReached to false is
>> unnecessary as it's the default value.
>
> but do either of these fields need to be volatile?
I think both need to be volatile. The writer is in threadDied and
bre
> This fixes a bug in the debug agent when there is a request to suspend a
> virtual thread that has already terminated. The issue was that unless the
> debug agent was currently under a "suspend all", it would not properly put
> the virtual thread on the `otherThreads` list, and instead added i
On Thu, 30 Jun 2022 06:34:55 GMT, Alan Bateman wrote:
>> Actually I was a bit confused as to why thread was declared volatile, so I
>> just followed the pattern. Maybe you can explain since you wrote it.
>
> I'm just pointing out that initialising breakpointReached to false is
> unnecessary as
On Wed, 29 Jun 2022 22:46:30 GMT, Chris Plummer wrote:
> I just noticed the test is being added to a newly created
> hotspot/jtreg/serviciability/jdi directory. It should be placed in one of the
> existing jdi test locations, either nsk/jdi or jdk/com/sun/jdi. I think the
> latter would be bet
> Currently, jdi only check and process class unloading event when it detects a
> new GC cycle.
>
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting
> class events can overlap with GC finish event, that results, sometimes, it
> only captures partial or even empty unload
> Currently, jdi only check and process class unloading event when it detects a
> new GC cycle.
>
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting
> class events can overlap with GC finish event, that results, sometimes, it
> only captures partial or even empty unload
On Tue, 28 Jun 2022 09:02:59 GMT, Alan Bateman wrote:
> This is spec only change to the JVM TI spec. The `SuspendAllVirtualThreads`
> and `ResumeAllVirtualThreads` functions added in Java 19 currently specify
> that they require one of the capabilities `can_suspend` or
> `can_support_virtual_t
On Wed, 29 Jun 2022 09:57:29 GMT, Kevin Walls wrote:
> More context in the bug, but there's no evidence that this test should still
> be problemlisted.
>
> Adding enableVerbose in the test itself should still keep this trivial:
> seeing what actually happened in a test that was once labelled a
On Fri, 24 Jun 2022 14:59:04 GMT, Ryan Ernst wrote:
> Applied required casts in jdk.hotspot.agent for the upcoming warning.
> Verified by cherry-picking @asotona's patch.
This pull request has now been integrated.
Changeset: 7b5bd251
Author:Ryan Ernst
Committer: Chris Hegarty
URL:
On Tue, 28 Jun 2022 09:02:59 GMT, Alan Bateman wrote:
> This is spec only change to the JVM TI spec. The `SuspendAllVirtualThreads`
> and `ResumeAllVirtualThreads` functions added in Java 19 currently specify
> that they require one of the capabilities `can_suspend` or
> `can_support_virtual_t
27 matches
Mail list logo
