On Mon, 13 Jun 2022 17:02:44 GMT, Coleen Phillimore wrote:
> Use a native JVM monitor and state for mutual exclusion for class linking and
> initialization. See CR for more details.
> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on
> linux-x64-debug. There isn't any pl
On Mon, 13 Jun 2022 17:02:44 GMT, Coleen Phillimore wrote:
> Use a native JVM monitor and state for mutual exclusion for class linking and
> initialization. See CR for more details.
> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on
> linux-x64-debug. There isn't any pl
On Mon, 13 Jun 2022 17:02:44 GMT, Coleen Phillimore wrote:
> Use a native JVM monitor and state for mutual exclusion for class linking and
> initialization. See CR for more details.
> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on
> linux-x64-debug. There isn't any pl
On Tue, 14 Jun 2022 11:54:40 GMT, Erik Joelsson wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix exitTransportWithError signature
>
> make/autoconf/flags-ldflags.m4 line 132:
>
>> 130:
>> 131: if test
On Sat, 11 Jun 2022 15:42:34 GMT, Alan Bateman wrote:
> JNI is updated in Java 19 so we need to define JNI_VERSION_19 and change
> GetVersion to return this version.
>
> test/hotspot/jtreg/native_sanity/JniVersion.java is updated to check that
> JNI_VERSION_19 is returned. The native library i
On Tue, 14 Jun 2022 10:09:37 GMT, Magnus Ihse Bursie wrote:
>> When we started introducing some possibly more intrusive compiler flags and
>> functionality for reproducible builds, we also introduced a flag to turn
>> this off out of an abundance of caution. But we have been been using this
>
On Tue, 14 Jun 2022 10:09:37 GMT, Magnus Ihse Bursie wrote:
>> When we started introducing some possibly more intrusive compiler flags and
>> functionality for reproducible builds, we also introduced a flag to turn
>> this off out of an abundance of caution. But we have been been using this
>
> When we started introducing some possibly more intrusive compiler flags and
> functionality for reproducible builds, we also introduced a flag to turn this
> off out of an abundance of caution. But we have been been using this
> configuration for a year or so internally within Oracle, with no
On Tue, 14 Jun 2022 09:48:25 GMT, Magnus Ihse Bursie wrote:
> When we started introducing some possibly more intrusive compiler flags and
> functionality for reproducible builds, we also introduced a flag to turn this
> off out of an abundance of caution. But we have been been using this
> co
When we started introducing some possibly more intrusive compiler flags and
functionality for reproducible builds, we also introduced a flag to turn this
off out of an abundance of caution. But we have been been using this
configuration for a year or so internally within Oracle, with no issues.
On Tue, 14 Jun 2022 07:42:08 GMT, David Holmes wrote:
> I'm confused by the comments above. The code failed to initialize the `_env`
> member but then makes calls via this uninitialized pointer! Surely we should
> have crashed?
JvmtiEnvBase::get_frame_count is static and I think
`((JvmtiEnvBa
On Mon, 13 Jun 2022 18:14:56 GMT, Aleksey Shipilev wrote:
> SonarCloud reports a few uninitialized fields in new VM_Virtual* ops. Those
> fields are used, and therefore this is a serious bug. These ops seem to be
> used only from a few corner cases, which is probably why this was never
> actua
On Mon, 13 Jun 2022 18:04:34 GMT, Alan Bateman wrote:
>> This test connects to http://openjdk.java.net/ so it's not reliable if the
>> host name can't be resolved or a HTTP connection cannot be established. I've
>> changed the test to use a local HTTP server so the original test works as
>> be
On Tue, 14 Jun 2022 07:01:33 GMT, Serguei Spitsyn wrote:
>> SonarCloud reports a few uninitialized fields in new VM_Virtual* ops. Those
>> fields are used, and therefore this is a serious bug. These ops seem to be
>> used only from a few corner cases, which is probably why this was never
>> ac
On Mon, 13 Jun 2022 18:14:56 GMT, Aleksey Shipilev wrote:
> SonarCloud reports a few uninitialized fields in new VM_Virtual* ops. Those
> fields are used, and therefore this is a serious bug. These ops seem to be
> used only from a few corner cases, which is probably why this was never
> actua
On Mon, 13 Jun 2022 18:14:56 GMT, Aleksey Shipilev wrote:
> SonarCloud reports a few uninitialized fields in new VM_Virtual* ops. Those
> fields are used, and therefore this is a serious bug. These ops seem to be
> used only from a few corner cases, which is probably why this was never
> actua
On Mon, 13 Jun 2022 11:42:43 GMT, David Holmes wrote:
> Maybe we actually need to backtrack and restore an invariant that there is
> always a TLH even for the current thread and fix the JVMTI code that did
> things differently?
This will make JVMTI code unnecessarily ugly in a couple of spots.
On Sat, 11 Jun 2022 08:11:34 GMT, Alan Bateman wrote:
> This test connects to http://openjdk.java.net/ so it's not reliable if the
> host name can't be resolved or a HTTP connection cannot be established. I've
> changed the test to use a local HTTP server so the original test works as
> before
JNI is updated in Java 19 so we need to define JNI_VERSION_19 and change
GetVersion to return this version.
test/hotspot/jtreg/native_sanity/JniVersion.java is updated to check that
JNI_VERSION_19 is returned. The native library in the JMX agent, and several
tests, define JNI_OnLoad that return
On Mon, 13 Jun 2022 07:45:41 GMT, Robbin Ehn wrote:
>> Johan Sjölén has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move assert up and remove other assert, remove unused var
>
> The only way to become an active handshaker is to handshake
On Wed, 8 Jun 2022 12:09:27 GMT, Severin Gehwolf wrote:
>> Please review this cleanup change in the cgroup subsystem which used to use
>> hard-coded stack allocated
>> buffers for concatenating strings in memory. We can use `stringStream`
>> instead which doesn't have the issue
>> of hard-codin
On Tue, 7 Jun 2022 12:42:05 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 i
On Wed, 8 Jun 2022 12:09:27 GMT, Severin Gehwolf wrote:
>> Please review this cleanup change in the cgroup subsystem which used to use
>> hard-coded stack allocated
>> buffers for concatenating strings in memory. We can use `stringStream`
>> instead which doesn't have the issue
>> of hard-codin
On Sat, 11 Jun 2022 08:11:34 GMT, Alan Bateman wrote:
> This test connects to http://openjdk.java.net/ so it's not reliable if the
> host name can't be resolved or a HTTP connection cannot be established. I've
> changed the test to use a local HTTP server so the original test works as
> before
This test connects to http://openjdk.java.net/ so it's not reliable if the host
name can't be resolved or a HTTP connection cannot be established. I've changed
the test to use a local HTTP server so the original test works as before, it's
just a local rather than remote HTTP connection.
I did a
On Fri, 10 Jun 2022 15:30:41 GMT, Ioi Lam wrote:
>> A trivial fix to ProblemList
>> serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java.
>
> Marked as reviewed by iklam (Reviewer).
@iklam - Thanks for the fast review.
I have got to learn to type!
On Fri, 10 Jun 2022 15:27:09 GMT, Alan Bateman wrote:
>> A trivial fix to ProblemList
>> serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java.
>
> Marked as reviewed by alanb (Reviewer).
@AlanBateman - Thanks for the fast review!
-
PR: https://git.
On Fri, 10 Jun 2022 15:21:34 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList
> serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java.
Marked as reviewed by iklam (Reviewer).
-
PR: https://git.openjdk.org/jdk19/pull/4
On Fri, 10 Jun 2022 15:21:34 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList
> serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java.
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.org/jdk19/pull/4
A trivial fix to ProblemList
serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java.
-
Commit messages:
- 8288222: ProblemList
serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java
Changes: https://git.openjdk.org/jdk1
On Sat, 4 Jun 2022 17:28:33 GMT, Andrey Turbanov wrote:
> No need to separately perform HashMap.containsKey before HashMap.remove call.
> If key is present - it will be removed anyway. If it's not present, nothing
> will be deleted.
> https://github.com/openjdk/jdk/blob/a6fc485a22484b70daf170e9
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +
On Sat, 4 Jun 2022 17:28:33 GMT, Andrey Turbanov wrote:
> No need to separately perform HashMap.containsKey before HashMap.remove call.
> If key is present - it will be removed anyway. If it's not present, nothing
> will be deleted.
> https://github.com/openjdk/jdk/blob/a6fc485a22484b70daf170e9
On Thu, 28 Apr 2022 16:33:48 GMT, XenoAmess wrote:
>> I'm getting a bit tired of seeing these JDK wide changes with lots of files
>> touched.
>> Delete all changes in desktop from this PR and re-submit them as a separate
>> PR.
>>
>> Also do not change J2DBench. We deliberately avoid using new
On Fri, 3 Jun 2022 17:02:44 GMT, Daniel D. Daugherty wrote:
> A trivial fix that deletes an errant `debugee.resume()` call that causes a
> race
> between the debugger and debuggee. I've also corrected incorrect line number
> values mentioned in comments.
>
> This fix has been tested with the up
On Wed, 8 Jun 2022 08:25:21 GMT, Severin Gehwolf wrote:
>> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 54:
>>
>>> 52: } else {
>>> 53: char *p = strstr(cgroup_path, _root);
>>> 54: if (p != NULL && p == cgroup_path) {
>>
>> I think this change should be done in a
> Please review this cleanup change in the cgroup subsystem which used to use
> hard-coded stack allocated
> buffers for concatenating strings in memory. We can use `stringStream`
> instead which doesn't have the issue
> of hard-coding maximum lengths (and related checks) and makes the code, thus
On Tue, 7 Jun 2022 19:57:48 GMT, Alexey Pavlyutkin
wrote:
> Hi!
>
> Here is a fix to jdk.jdi that fixes reproducible build for Windows. The idea
> of the fix is to re-use value of --with-hotspot-build-time option to generate
> deterministic timestamp exactly like it's done to hotspot componen
On Tue, 7 Jun 2022 19:57:48 GMT, Alexey Pavlyutkin
wrote:
> Hi!
>
> Here is a fix to jdk.jdi that fixes reproducible build for Windows. The idea
> of the fix is to re-use value of --with-hotspot-build-time option to generate
> deterministic timestamp exactly like it's done to hotspot componen
On Wed, 8 Jun 2022 07:13:30 GMT, Ioi Lam wrote:
>> Severin Gehwolf 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 six additional
>> commits sin
On Tue, 7 Jun 2022 12:42:26 GMT, Severin Gehwolf wrote:
>> Please review this cleanup change in the cgroup subsystem which used to use
>> hard-coded stack allocated
>> buffers for concatenating strings in memory. We can use `stringStream`
>> instead which doesn't have the issue
>> of hard-codin
On Tue, 7 Jun 2022 10:07:08 GMT, Yi Yang wrote:
>> It seems that calculation of
>> MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
>>
>> Currently,
>> `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
>>
>> ==> CodeHeap
Hi!
Here is a fix to jdk.jdi that fixes reproducible build for Windows. The idea of
the fix is to re-use value of --with-hotspot-build-time option to generate
deterministic timestamp exactly like it's done to hotspot component.
Verification (Windows-10/MSVS-2019): ```bash ./configure
--with-bo
No need to separately perform HashMap.containsKey before HashMap.remove call.
If key is present - it will be removed anyway. If it's not present, nothing
will be deleted.
https://github.com/openjdk/jdk/blob/a6fc485a22484b70daf170e981432c0856b9d93d/src/java.management/share/classes/com/sun/jmx/rem
> Please review following fix which exclude failing test.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
fixed merge
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/9050/files
- new: https://git.openjdk.jav
> Please review following fix which exclude failing test.
Leonid Mesnik 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' of https://github.com/openjdk/jdk into 8287877
- Merge branch 'master' of
On Tue, 31 May 2022 18:14:51 GMT, Chris Plummer wrote:
>> As part of the loom integration, jdb added `-trackvthreads` and the debug
>> agent added `enumeratevthreads`. These options are being renamed to
>> `-trackallthreads` and `includevirtualthreads` (the shorthand `vthreads`
>> should not h
On Tue, 7 Jun 2022 00:49:29 GMT, Leonid Mesnik wrote:
> Please review following fix which exclude failing test.
Marked as reviewed by sspitsyn (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/9050
On Tue, 7 Jun 2022 00:49:29 GMT, Leonid Mesnik wrote:
> Please review following fix which exclude failing test.
Thumbs up. This is a trivial change.
-
Marked as reviewed by dcubed (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/9050
On Tue, 7 Jun 2022 12:42:05 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 i
> Please review this cleanup change in the cgroup subsystem which used to use
> hard-coded stack allocated
> buffers for concatenating strings in memory. We can use `stringStream`
> instead which doesn't have the issue
> of hard-coding maximum lengths (and related checks) and makes the code, thus
> 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_thread()` body
> be inlined instead? We can do this i
On Mon, 6 Jun 2022 16:36:01 GMT, Daniel D. Daugherty wrote:
>> We also no longer need L358 as `current` is now unused.
>
> JavaThread *target = state->get_thread();
> Thread *current = Thread::current();
>
> assert(state != NULL, "sanity check");
>
> The `assert()` on L360 is in the wrong p
On Tue, 7 Jun 2022 09:58:11 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 i
> It seems that calculation of
> MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
>
> Currently,
> `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
>
> ==> CodeHeap 'non-nmethods' 1532544 (Used)
> ==> CodeHeap 'profiled nm
> It seems that calculation of
> MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
>
> Currently,
> `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
>
> ==> CodeHeap 'non-nmethods' 1532544 (Used)
> ==> CodeHeap 'profiled nm
> 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_thread()` body
> be inlined instead? We can do this i
On Mon, 6 Jun 2022 07:15:45 GMT, David Holmes wrote:
>> Johan Sjölén has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - do_thread(target) not self
>> - Remove checks for is_handshake_for, instead call Handshake::execute
>> - Switch or
On Wed, 1 Jun 2022 09:18:38 GMT, Severin Gehwolf wrote:
> Please review this cleanup change in the cgroup subsystem which used to use
> hard-coded stack allocated
> buffers for concatenating strings in memory. We can use `stringStream`
> instead which doesn't have the issue
> of hard-coding max
On Tue, 7 Jun 2022 04:17:44 GMT, Ioi Lam wrote:
> > We should try to consolidate these test cases to improve maintainability.
>
> I filed [JDK-8287185](https://bugs.openjdk.org/browse/JDK-8287185)
Agreed. Thanks for the review @iklam
-
PR: https://git.openjdk.java.net/jdk/pull/899
On Mon, 9 May 2022 21:26:50 GMT, Alex Menkov wrote:
> isThreadExpected function checks only some known JFR/Graal threads.
> This approach requires to keep this function up to date (add other internal
> threads like usage tracker, loom, etc).
>
> To avoid this updated all tests which use it, now
On Mon, 6 Jun 2022 23:07:06 GMT, Ioi Lam wrote:
> We should try to consolidate these test cases to improve maintainability.
I filed [JDK-8287185](https://bugs.openjdk.org/browse/JDK-8287185)
-
PR: https://git.openjdk.java.net/jdk/pull/8993
Please review following fix which exclude failing test.
-
Commit messages:
- 8287877: Exclude
vmTestbase/nsk/jvmti/AttachOnDemand/attach022/TestDescription.java until
JDK-8277573 is fixed
Changes: https://git.openjdk.java.net/jdk/pull/9050/files
Webrev: https://webrevs.openjdk.ja
On Mon, 6 Jun 2022 20:57:49 GMT, Alex Menkov wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Don't capitalize "virtual threads"
>
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources.java
> li
On Thu, 2 Jun 2022 14:32:28 GMT, Severin Gehwolf wrote:
> This adds a regression test for a recent fix (JDK-8287073). I've restructured
> the linux specific JDK code to call a separate static function to enable this
> test. It'll help future tests too.
>
> Testing:
> - [x] Container tests cont
On Thu, 2 Jun 2022 14:32:28 GMT, Severin Gehwolf wrote:
> This adds a regression test for a recent fix (JDK-8287073). I've restructured
> the linux specific JDK code to call a separate static function to enable this
> test. It'll help future tests too.
>
> Testing:
> - [x] Container tests cont
On Tue, 31 May 2022 18:14:51 GMT, Chris Plummer wrote:
>> As part of the loom integration, jdb added `-trackvthreads` and the debug
>> agent added `enumeratevthreads`. These options are being renamed to
>> `-trackallthreads` and `includevirtualthreads` (the shorthand `vthreads`
>> should not h
On Thu, 19 May 2022 00:51:29 GMT, Alex Menkov wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Don't capitalize "virtual threads"
>
> Marked as reviewed by amenkov (Reviewer).
Thanks Alan. Can I get one more revie
On Mon, 6 Jun 2022 07:20:10 GMT, David Holmes wrote:
>> src/hotspot/share/prims/jvmtiEventController.cpp line 370:
>>
>>> 368: }
>>> 369: EnterInterpOnlyModeClosure hs;
>>> 370: assert(state->get_thread() != NULL, "sanity check");
>>
>> Existing: We have already performed this check. We s
On Mon, 6 Jun 2022 07:17:15 GMT, David Holmes wrote:
>> Johan Sjölén has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - do_thread(target) not self
>> - Remove checks for is_handshake_for, instead call Handshake::execute
>> - Switch or
On Fri, 3 Jun 2022 09:45:31 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 i
On Fri, 3 Jun 2022 09:45:31 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 i
On Mon, 6 Jun 2022 07:19:06 GMT, David Holmes wrote:
>> Johan Sjölén has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - do_thread(target) not self
>> - Remove checks for is_handshake_for, instead call Handshake::execute
>> - Switch or
On Fri, 3 Jun 2022 09:45:31 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 i
On Fri, 3 Jun 2022 22:08:50 GMT, Chris Plummer wrote:
>> Marked as reviewed by cjplummer (Reviewer).
>
>> @plummercj - Thanks for the review!
>>
>> Do you agree that this is a trivial change?
>
> Yes
@plummercj - Thanks!
-
PR: https://git.openjdk.java.net/jdk/pull/9020
On Fri, 3 Jun 2022 21:43:02 GMT, Chris Plummer wrote:
>> A trivial fix that deletes an errant `debugee.resume()` call that causes a
>> race
>> between the debugger and debuggee. I've also corrected incorrect line number
>> values mentioned in comments.
>>
>> This fix has been tested with the up
On Fri, 3 Jun 2022 21:43:02 GMT, Chris Plummer wrote:
>> A trivial fix that deletes an errant `debugee.resume()` call that causes a
>> race
>> between the debugger and debuggee. I've also corrected incorrect line number
>> values mentioned in comments.
>>
>> This fix has been tested with the up
On Fri, 3 Jun 2022 17:02:44 GMT, Daniel D. Daugherty wrote:
> A trivial fix that deletes an errant `debugee.resume()` call that causes a
> race
> between the debugger and debuggee. I've also corrected incorrect line number
> values mentioned in comments.
>
> This fix has been tested with the up
On Fri, 3 Jun 2022 17:02:44 GMT, Daniel D. Daugherty wrote:
> A trivial fix that deletes an errant `debugee.resume()` call that causes a
> race
> between the debugger and debuggee. I've also corrected incorrect line number
> values mentioned in comments.
>
> This fix has been tested with the up
A trivial fix that deletes an errant `debugee.resume()` call that causes a race
between the debugger and debuggee. I've also corrected incorrect line number
values mentioned in comments.
This fix has been tested with the updated failing test both with and without the
debug code that makes the fail
On Fri, 3 Jun 2022 17:02:44 GMT, Daniel D. Daugherty wrote:
> A trivial fix that deletes an errant `debugee.resume()` call that causes a
> race
> between the debugger and debuggee. I've also corrected incorrect line number
> values mentioned in comments.
>
> This fix has been tested with the up
On Fri, 3 Jun 2022 09:45:31 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 i
On Fri, 3 Jun 2022 09:45:31 GMT, Johan Sjölén wrote:
>> Please review this PR for fixing JDK-8287281.
>>
>> I chose a different solution than the one suggested. Looking at all callers
>> of `Handshake::execute`, it seems that only one depends on `target ==
>> current`. The rest special case th
> Please review this PR for fixing JDK-8287281.
>
> I chose a different solution than the one suggested. Looking at all callers
> of `Handshake::execute`, it seems that only one depends on `target ==
> current`. The rest special case that by calling `is_handshake_safe_for` and
> `do_thread` dir
> Please review this PR for fixing JDK-8287281.
>
> I chose a different solution than the one suggested. Looking at all callers
> of `Handshake::execute`, it seems that only one depends on `target ==
> current`. The rest special case that by calling `is_handshake_safe_for` and
> `do_thread` dir
On Thu, 2 Jun 2022 13:47:23 GMT, Johan Sjölén wrote:
> Please review this PR for fixing JDK-8287281.
>
> I chose a different solution than the one suggested. Looking at all callers
> of `Handshake::execute`, it seems that only one depends on `target ==
> current`. The rest special case that by
> Please review this PR for fixing JDK-8287281.
>
> I chose a different solution than the one suggested. Looking at all callers
> of `Handshake::execute`, it seems that only one depends on `target ==
> current`. The rest special case that by calling `is_handshake_safe_for` and
> `do_thread` dir
On Tue, 31 May 2022 18:14:51 GMT, Chris Plummer wrote:
>> As part of the loom integration, jdb added `-trackvthreads` and the debug
>> agent added `enumeratevthreads`. These options are being renamed to
>> `-trackallthreads` and `includevirtualthreads` (the shorthand `vthreads`
>> should not h
On Tue, 31 May 2022 18:14:51 GMT, Chris Plummer wrote:
>> As part of the loom integration, jdb added `-trackvthreads` and the debug
>> agent added `enumeratevthreads`. These options are being renamed to
>> `-trackallthreads` and `includevirtualthreads` (the shorthand `vthreads`
>> should not h
On Wed, 1 Jun 2022 07:52:50 GMT, Andrey Turbanov wrote:
> `String.contains` was introduced in Java 5.
> Some code in jdk.hotspot.agent still uses old approach with `String.indexOf`
> to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easie
On Thu, 2 Jun 2022 09:57:10 GMT, Andrey Turbanov wrote:
> > Please make sure you run the SA tests.
>
> This one, `test/hotspot/jtreg/serviceability` right?
You can just do the `test/hotspot/jtreg/serviceability/sa` subdirectory, but
there is also `test/jdk/sun/tools/jhsdb`
-
PR:
On Thu, 2 Jun 2022 09:54:31 GMT, Aleksey Shipilev wrote:
> [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought the
> alternative Loom implementation that can be used by ports as the fallback.
> That fallback does not support JVMTI entirely, so lots of tests fail. Some
> JVM
On Thu, 2 Jun 2022 14:32:28 GMT, Severin Gehwolf wrote:
> This adds a regression test for a recent fix (JDK-8287073). I've restructured
> the linux specific JDK code to call a separate static function to enable this
> test. It'll help future tests too.
>
> Testing:
> - [x] Container tests cont
On Thu, 2 Jun 2022 14:38:31 GMT, Aleksey Shipilev wrote:
> Trivial, or? I would like to have this integrated sooner to clean up our
> testing.
Ship it under trivial, thanks.
-
PR: https://git.openjdk.java.net/jdk/pull/8990
On Thu, 2 Jun 2022 09:54:31 GMT, Aleksey Shipilev wrote:
> [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought the
> alternative Loom implementation that can be used by ports as the fallback.
> That fallback does not support JVMTI entirely, so lots of tests fail. Some
> JVM
On Thu, 2 Jun 2022 09:54:31 GMT, Aleksey Shipilev wrote:
> [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought the
> alternative Loom implementation that can be used by ports as the fallback.
> That fallback does not support JVMTI entirely, so lots of tests fail. Some
> JVM
This adds a regression test for a recent fix (JDK-8287073). I've restructured
the linux specific JDK code to call a separate static function to enable this
test. It'll help future tests too.
Testing:
- [x] Container tests continue to pass + GHA
- [x] New regression test fails prior the code fix
Please review this PR for fixing JDK-8287281.
I chose a different solution than the one suggested. Looking at all callers of
`Handshake::execute`, it seems that only one depends on `target == current`.
The rest special case that by calling `is_handshake_safe_for` and `do_thread`
directly. I co
On Thu, 2 Jun 2022 13:47:23 GMT, Johan Sjölén wrote:
> Please review this PR for fixing JDK-8287281.
>
> I chose a different solution than the one suggested. Looking at all callers
> of `Handshake::execute`, it seems that only one depends on `target ==
> current`. The rest special case that by
On Thu, 2 Jun 2022 09:54:31 GMT, Aleksey Shipilev wrote:
> [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought the
> alternative Loom implementation that can be used by ports as the fallback.
> That fallback does not support JVMTI entirely, so lots of tests fail. Some
> JVM
1 - 100 of 26349 matches
Mail list logo
