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;
>>
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 22:33:32 GMT, Chris Plummer wrote:
> > > I didn't see any response to my suggested improvements to the test. Can
> > > you please comment on them and update the test if you agree? Thanks.
> >
> >
> > I am still learning JDI and not quite sure how it works. But I think it is
On Wed, 29 Jun 2022 08:55:22 GMT, Alan Bateman wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix indentation
>
> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 418:
>
>> 416: // Thre
> 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 Wed, 29 Jun 2022 19:14:39 GMT, Zhengyu Gu wrote:
>> 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,
On Wed, 29 Jun 2022 12:40:42 GMT, Zhengyu Gu wrote:
> > I didn't see any response to my suggested improvements to the test. Can you
> > please comment on them and update the test if you agree? Thanks.
>
> I am still learning JDI and not quite sure how it works. But I think it is
> unrelated to
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
> 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 Mon, 27 Jun 2022 19:13:40 GMT, Ioi Lam wrote:
> This is a follow up to
> [JDK-8288623](https://bugs.openjdk.org/browse/JDK-8288623).
> `java_lang_VirtualThread` is part of loom and should be move to
> continuationJavaClasses.hpp, which contains the accessors for the other java
> classes us
On Mon, 27 Jun 2022 19:13:40 GMT, Ioi Lam wrote:
> This is a follow up to
> [JDK-8288623](https://bugs.openjdk.org/browse/JDK-8288623).
> `java_lang_VirtualThread` is part of loom and should be move to
> continuationJavaClasses.hpp, which contains the accessors for the other java
> classes us
> 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 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 Tue, 28 Jun 2022 23:51:20 GMT, Chris Plummer wrote:
> It looks like TestClassUnloadEvents is failing on Windows-x64:
> https://github.com/openjdk/jdk/pull/9168/checks?check_run_id=7102500258
Thanks for pointing out. I could not reproduce locally so far, but continue
debugging it.
-
> 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 Sat, 25 Jun 2022 13:08:30 GMT, Ryan Ernst wrote:
>> Applied required casts in jdk.hotspot.agent for the upcoming warning.
>> Verified by cherry-picking @asotona's patch.
>
> Ryan Ernst has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev exc
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
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_threads`. This is not correct as both capabilities are
required.
On Thu, 21 Apr 2022 10:48:06 GMT, Albert Mingkun Yang wrote:
> Simple rename and some comments update.
>
> Test: build
This pull request has now been integrated.
Changeset: 2961b7ee
Author:Albert Mingkun Yang
URL:
https://git.openjdk.org/jdk/commit/2961b7eede7205f8d67427bdf020de796
On Tue, 28 Jun 2022 19:43:33 GMT, Albert Mingkun Yang wrote:
>> Simple rename and some comments update.
>>
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with four
> additional commits since the last revision:
>
> - arg rename
> - default arg
> - revert
>
> 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 23:54:20 GMT, Chris Plummer wrote:
> I didn't see any response to my suggested improvements to the test. Can you
> please comment on them and update the test if you agree? Thanks.
I am still learning JDI and not quite sure how it works. But I think it is
unrelated to this C
On Tue, 28 Jun 2022 19:43:33 GMT, Albert Mingkun Yang wrote:
>> Simple rename and some comments update.
>>
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with four
> additional commits since the last revision:
>
> - arg rename
> - default arg
> - revert
>
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 as failing is really
important!
-
Commit messages:
On Tue, 28 Jun 2022 22:33:07 GMT, Chris Plummer wrote:
> 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 virtu
Make the redefine timer statistics more accurate
-
Commit messages:
- 8289436: Make the redefine timer statistics more accurate
Changes: https://git.openjdk.org/jdk/pull/9322/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9322&range=00
Issue: https://bugs.openjdk.org/brow
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
28 matches
Mail list logo
