> 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
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
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
> 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
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
> 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
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
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
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
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
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
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'
> 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
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
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
> 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
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
> 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
> 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
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
>
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
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
>
On Wed, 29 Jun 2022 23:24:28 GMT, Chris Plummer wrote:
>> test/jdk/com/sun/jdi/SuspendAfterDeath.java line 62:
>>
>>> 60: public class SuspendAfterDeath extends TestScaffold {
>>> 61: private volatile ThreadReference thread;
>>> 62: private volatile boolean breakpointReached = false;
>>
27 matches
Mail list logo
