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
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
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
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
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 cha
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&#x
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&#x
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
> 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
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
ne 357:
> 355: if (target->is_handshake_safe_for(self)) {
> 356: hs_cl->do_thread(target);
> 357: return;
I like the idea of doing this, but I can't quite convince myself that it will
always be safe when the target is not the current thread. ??
src/hotspot/share/runt
ng: We have already performed this check. We set `target` above and
> returned if it was `NULL`.
We also no longer need L358 as `current` is now unused.
> src/hotspot/share/runtime/handshake.cpp line 360:
>
>> 358: }
>> 359:
>> 360: HandshakeOperation op
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
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
ndshake_for, instead call Handshake::execute
> - Switch order of handshake check
Thanks for the update, looks good.
Remember to re-run the tests!
-
Marked as reviewed by rehn (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/8992
> 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
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
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 11:05:30 GMT, Alan Bateman wrote:
> I expect you can unexclude the runtime/* tests from this section too. Also
> the same section in test/jdk/ProblemList.txt that excludes the tests on
> x86_32 can be cleaned up too, maybe a separate PR.
Yes, in separate PR. In this PR, I wa
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 Wed, 1 Jun 2022 20:59:41 GMT, Chris Plummer wrote:
> Please make sure you run the SA tests.
This one, `test/hotspot/jtreg/serviceability` right?
-
PR: https://git.openjdk.java.net/jdk/pull/8966
t;> and so needs JVM TI)
>>
>> The VM option "VMContinuations" is added as an experimental option so it can
>> be used by tests. A number of tests are changed to re-run with
>> -XX:-VMContinuations. A new jtreg property is added so that tests that need
>>
On Wed, 1 Jun 2022 06:26:23 GMT, David Holmes wrote:
>> Alan Bateman has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 11 commits:
>>
>> - Fixed another typo in comment
>> - Merge
>> - Fix typos in comments
>> - Allowing linking
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 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 +
*From:* Volker Simonis
*Sent:* Saturday, May 21, 2022 12:49 AM
*To:* Kemper, William
*Cc:* serviceability-dev
*Subject:* RE: [EXTERNAL]Concurrent heap monitoring
*CAUTION*: This email originated from outside of the organization. Do
not click
t;> and so needs JVM TI)
>>
>> The VM option "VMContinuations" is added as an experimental option so it can
>> be used by tests. A number of tests are changed to re-run with
>> -XX:-VMContinuations. A new jtreg property is added so that tests that need
>>
1 - 100 of 27503 matches
Mail list logo
