> The JVMTI SetLocalXXX requires the target virtual thread suspended at a
> breakpoint or single step event.
>
> This is the relevant statement from the "Local Variable" section:
>
> `The SetLocalXXX functions may be used to set the value of a local variable
> in the topmost frame of a virtual
On Wed, 22 Jun 2022 16:57:34 GMT, Serguei Spitsyn wrote:
>> test/hotspot/jtreg/serviceability/jvmti/vthread/GetSetLocalTest/GetSetLocalTest.java
>> line 103:
>>
>>> 101: GetSetLocalTest obj = new GetSetLocalTest();
>>> 102:
>>> 103: for (int i = 0; i < 1000; i++) {
>>
>> Does
> 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 Thu, 23 Jun 2022 07:09:38 GMT, Serguei Spitsyn wrote:
>> The JVMTI SetLocalXXX requires the target virtual thread suspended at a
>> breakpoint or single step event.
>>
>> This is the relevant statement from the "Local Variable" section:
>>
>> `The SetLocalXXX functions may be used to set th
On Thu, 23 Jun 2022 07:09:38 GMT, Serguei Spitsyn wrote:
>> The JVMTI SetLocalXXX requires the target virtual thread suspended at a
>> breakpoint or single step event.
>>
>> This is the relevant statement from the "Local Variable" section:
>>
>> `The SetLocalXXX functions may be used to set th
On Tue, 21 Jun 2022 19:22:43 GMT, Johan Sjölén wrote:
>> Please review this PR for fixing JDK-8287281.
>>
>> If a thread is handshake safe we immediately execute the closure, instead of
>> going through the regular Handshake process.
>>
>> Finally: Should `VirtualThreadGetThreadClosure` and
> The JVMTI SetLocalXXX requires the target virtual thread suspended at a
> breakpoint or single step event.
>
> This is the relevant statement from the "Local Variable" section:
>
> `The SetLocalXXX functions may be used to set the value of a local variable
> in the topmost frame of a virtual
On Thu, 23 Jun 2022 15:34:11 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains four additional
>> com
On Thu, 23 Jun 2022 16:13:58 GMT, Serguei Spitsyn wrote:
>> The JVMTI SetLocalXXX requires the target virtual thread suspended at a
>> breakpoint or single step event.
>>
>> This is the relevant statement from the "Local Variable" section:
>>
>> `The SetLocalXXX functions may be used to set th
On Wed, 22 Jun 2022 14:08:41 GMT, Jayashree Huttanagoudar
wrote:
>> This PR is to address :
>> https://bugs.openjdk.org/browse/JDK-8135292?jql=labels%20%3D%20starter-bug
>> Verified the build before and after the patch. Also below tests are run:
>> Before Patch:
>>
>> $ make test TEST="jtreg:t
On Wed, 22 Jun 2022 16:48:33 GMT, Severin Gehwolf wrote:
>> Jayashree Huttanagoudar has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8135291: Removed duplicate code in Address.java and related files in SA
>> -After asLongValue() added t
On Sat, 18 Jun 2022 03:59:44 GMT, Serguei Spitsyn wrote:
> The JVMTI SetLocalXXX requires the target virtual thread suspended at a
> breakpoint or single step event.
>
> This is the relevant statement from the "Local Variable" section:
>
> `The SetLocalXXX functions may be used to set the valu
On Thu, 23 Jun 2022 16:16:00 GMT, Jayashree Huttanagoudar
wrote:
> > > ```
> > > $ git add
> > > $ git commit --amend --no-edit
> > > ```
> >
> >
> > The `git commit --amend` changes the current commit. Don't use `--amend`
> > and it should be fine.
>
> Ok thank you.
I tried just :
# git
> This PR is to address :
> https://bugs.openjdk.org/browse/JDK-8135292?jql=labels%20%3D%20starter-bug
> Verified the build before and after the patch. Also below tests are run:
> Before Patch:
>
> $ make test TEST="jtreg:test/hotspot/jtreg/serviceability"
> ==
>
On Wed, 22 Jun 2022 16:46:54 GMT, Severin Gehwolf wrote:
>> Oops! previously I was not know that I should not force push and should not
>> edit commit message so this time I took care of those points. But, rebase is
>> also not suggested :(
>> I did so because after making suggested review chan
On Thu, 23 Jun 2022 16:13:58 GMT, Serguei Spitsyn wrote:
>> The JVMTI SetLocalXXX requires the target virtual thread suspended at a
>> breakpoint or single step event.
>>
>> This is the relevant statement from the "Local Variable" section:
>>
>> `The SetLocalXXX functions may be used to set th
On Thu, 23 Jun 2022 16:48:33 GMT, Jayashree Huttanagoudar
wrote:
>> This PR is to address :
>> https://bugs.openjdk.org/browse/JDK-8135292?jql=labels%20%3D%20starter-bug
>> Verified the build before and after the patch. Also below tests are run:
>> Before Patch:
>>
>> $ make test TEST="jtreg:t
The fix remove JCK-like run, NSK variables and LoadLibrary exception handling
-
Commit messages:
- revert AddModuleExportsAndOpensTest changes
- LoadLibrary fixed
- NSK removed
- PrintStream cleanup
- NSK removed
- JCK-like tests fixed
Changes: https://git.openjdk.org/jdk/pull/
On Fri, 29 Apr 2022 11:39:39 GMT, Albert Mingkun Yang wrote:
>> The `_reference_type` used to be initialized correctly in most cases, but
>> needed fixing up for a few cases during bootstrapping. With this change it is
>> *never* initialized correctly for Reference subtypes and always needs an
>>
On Thu, 23 Jun 2022 12:34:59 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 Thu, 23 Jun 2022 12:34:59 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 Thu, 2 Jun 2022 13:47:23 GMT, Johan Sjölén wrote:
> Please review this PR for fixing JDK-8287281.
>
> If a thread is handshake safe we immediately execute the closure, instead of
> going through the regular Handshake process.
>
> Finally: Should `VirtualThreadGetThreadClosure` and its `do
22 matches
Mail list logo
