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 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 Thu, 11 Nov 2021 13:58:06 GMT, Coleen Phillimore wrote:
>> JNI Local handles can only be created by JavaThread (there's an assert in
>> make_local) but the fields are added to Thread.
>> Move the fields to JavaThread and adding JavaThread* argument.
>> Also, the global freelist isn't very use
On Thu, 7 Oct 2021 15:28:31 GMT, Coleen Phillimore wrote:
>> Also fixes: 8273956: Add checking for rank values
>>
>> This change does 3 things. I could separate them but this has all been
>> tested together and most of the change is mechanical. The first is a simple
>> rename of nonleaf => s
On Tue, 28 Sep 2021 22:07:38 GMT, Patricio Chilano Mateo
wrote:
> Hi,
>
> Please review this simple fix. As pointed out by @dholmes-ora in the bug
> comments, the ThreadDeath exception could be delivered and thrown while the
> target JavaThread is still executing within th
On Wed, 29 Sep 2021 18:35:27 GMT, Chris Plummer wrote:
>> Hi,
>>
>> Please review this simple fix. As pointed out by @dholmes-ora in the bug
>> comments, the ThreadDeath exception could be delivered and thrown while the
>> target JavaThread is still executing within the Wicket.unlock call. To
On Wed, 29 Sep 2021 00:47:43 GMT, David Holmes wrote:
> Fix seems quite reasonable.
>
Thanks for the review David!
Patricio
-
PR: https://git.openjdk.java.net/jdk/pull/5742
Hi,
Please review this simple fix. As pointed out by @dholmes-ora in the bug
comments, the ThreadDeath exception could be delivered and thrown while the
target JavaThread is still executing within the Wicket.unlock call. To fix it I
moved the unlock call inside the try block. I was able to repr
On Tue, 21 Sep 2021 12:07:06 GMT, Coleen Phillimore wrote:
>> This change removes the special ranking and folds it into nosafepoint. You
>> have to look at commit #3 to see this actual part of the change that doesn't
>> include JDK-8273915.
>> This passes tier1-6 also.
>
> Coleen Phillimore ha
On Tue, 31 Aug 2021 21:52:12 GMT, Coleen Phillimore wrote:
>> I moved nonleaf ranked locks to be leaf (or leaf+something). Many of the
>> leaf locks are safepoint_check_never. Segregating this rank into safepoint
>> checking and non-safepoint checking is left for a future RFE.
>> Tested with
On Wed, 1 Sep 2021 01:40:17 GMT, Coleen Phillimore wrote:
> Make lock be declared as safepoint_check_never.
> Ran tier1-3 tests and test that uses this code:
> serviceability/dcmd/gc/ClassHistogramTest.java
LGTM.
Thanks,
Patricio
-
Marked as reviewed by pchilanomate (Committer).
On Wed, 30 Jun 2021 01:31:30 GMT, David Holmes wrote:
>> Please see the JBS issue for more details, but basically we have 8 different
>> kinds of internal VM JavaThreads (grouping the three types of CompilerThread
>> together) that all basically duplicated the logic for initializing
>> (prepar
On Wed, 26 May 2021 18:30:16 GMT, Robbin Ehn wrote:
>> Just for consistency, shouldn't we just use ThreadBlockInVMPreprocess in
>> mutex.cpp as we are using it in objectMonitor.cpp?
>
> You mean revert your change of having the monitor as a parameter to
> ThreadBlockInVM?
> And instead just pla
On Tue, 25 May 2021 07:06:58 GMT, Robbin Ehn wrote:
>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor
>> of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way
On Mon, 17 May 2021 07:43:06 GMT, Robbin Ehn wrote:
>> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 277:
>>
>>> 275: class ThreadBlockInVM {
>>> 276: InFlightMutexRelease _ifmr;
>>> 277: ThreadBlockInVMPreprocess _tbivmpp;
>>
>> Why delegate to the TBIVMPP instead of extending
On Tue, 20 Apr 2021 06:48:47 GMT, Robbin Ehn wrote:
>> A suspend request is done by handshaking thread target thread(s). When
>> executing the handshake operation we know the target mutator thread is in a
>> dormant state (as in safepoint safe state). We have a guarantee that it will
>> check
On Fri, 9 Apr 2021 15:25:16 GMT, Daniel D. Daugherty wrote:
>> If we process the async suspension handshake we can go to safepoint.
>> And before safepoint we must drop the tty lock.
>
> Is this worth a comment above the `break_tty_lock_for_safepoint()` call?
I also thought we could remove this
On Wed, 7 Apr 2021 14:33:00 GMT, Robbin Ehn wrote:
>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithCurrentThread/SuspendWithCurrentThread.java
>> line 132:
>>
>>> 130: ThreadToSuspend.setAllThreadsReady();
>>> 131:
>>> 132: while (!checkSuspendedStatus()) {
>>
>>
On Wed, 31 Mar 2021 08:27:35 GMT, Robbin Ehn wrote:
>> A suspend request is done by handshaking thread target thread(s). When
>> executing the handshake operation we know the target mutator thread is in a
>> dormant state (as in safepoint safe state). We have a guarantee that it will
>> check
On Tue, 6 Apr 2021 15:46:17 GMT, Richard Reingruber wrote:
>> (technically this will be ordered by the poll is since polls are only
>> disarmed by threads them selfs)
>> (meaning if you really promise to call should_process() after you have seen
>> "set_suspend(true);" you will see the async ha
On Mon, 5 Apr 2021 20:24:31 GMT, Harold Seigel wrote:
> Thanks Lois and Patricio for reviewing the change!
> I removed my bogus change to ObjectSynchronizer::jni_exit() which also made
> calls consistent in jfrJavaSupport.cpp.
> Harold
Thanks Harold! Fix looks good.
-
PR: https://g
On Mon, 5 Apr 2021 20:27:53 GMT, Harold Seigel wrote:
>> Please review this additional cleanup of use of TRAPS in hotspot runtime
>> code. The changes were tested with Mach5 tiers 1-2 on Linux, Mac OS, and
>> Windows and Mach5 tiers 3-5 on Linux x64.
>>
>> Thanks, Harold
>
> Harold Seigel has
On Mon, 5 Apr 2021 17:57:13 GMT, Harold Seigel wrote:
> Please review this additional cleanup of use of TRAPS in hotspot runtime
> code. The changes were tested with Mach5 tiers 1-2 on Linux, Mac OS, and
> Windows and Mach5 tiers 3-5 on Linux x64.
>
> Thanks, Harold
Hi Harold,
I looked at t
On Wed, 31 Mar 2021 06:32:40 GMT, David Holmes wrote:
>> Robbin Ehn 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' into SuspendInHandshake
>> - Merge branch 'master' into SuspendInHa
On Wed, 31 Mar 2021 08:27:35 GMT, Robbin Ehn wrote:
>> A suspend request is done by handshaking thread target thread(s). When
>> executing the handshake operation we know the target mutator thread is in a
>> dormant state (as in safepoint safe state). We have a guarantee that it will
>> check
On Tue, 30 Mar 2021 13:26:13 GMT, Richard Reingruber wrote:
>> Robbin Ehn has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains two commits:
>>
>> - Merge branch 'master' into SuspendInHandshake
>> - 8257831: Suspend with handshake (r
On Wed, 31 Mar 2021 08:27:35 GMT, Robbin Ehn wrote:
>> A suspend request is done by handshaking thread target thread(s). When
>> executing the handshake operation we know the target mutator thread is in a
>> dormant state (as in safepoint safe state). We have a guarantee that it will
>> check
On Wed, 3 Mar 2021 19:24:17 GMT, Patricio Chilano Mateo
wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> More pointer declaration style fixups
>
> Hi David,
>
> Changes look
On Wed, 3 Mar 2021 05:15:48 GMT, David Holmes wrote:
> ObjectMonitors can only be used by JavaThreads (modulo some interactions with
> hashcodes and deflation) but we use "Thread*" almost everywhere mainly due to
> use of TRAPS (and TRAPS will itself use JavaThread once JDK-8252685 is done).
>
On Tue, 5 Jan 2021 23:45:06 GMT, Coleen Phillimore wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address comments from coleenp and pchilano.
>
> LGTM!
Looks good, thanks Dan!
-
PR: https://g
On Thu, 24 Dec 2020 17:33:21 GMT, Daniel D. Daugherty
wrote:
> A small robustness fix in ThreadsSMRSupport::print_info_on() to reduce the
> likelihood of crashes during error reporting. Uses Threads_lock->try_lock()
> for safety and restricts some reporting to when the Threads_lock has been
> ac
On Fri, 11 Dec 2020 17:25:33 GMT, Patricio Chilano Mateo
wrote:
> Hi,
>
> Please review the following small fix for test
> RemovingUnixDomainSocketTest.java. As explained in the bug comments, the
> issue is due to having two different StreamPumper objects consuming from the
On Tue, 15 Dec 2020 20:52:36 GMT, Alex Menkov wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> include 'VM Warning' in stderr search
>
> Marked as reviewed by
On Wed, 16 Dec 2020 01:19:43 GMT, David Holmes wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> include 'VM Warning' in stderr search
>
> test/lib/jdk/test
entioned in 8248162
> we might not want to hide all warning messages.
>
> Without the patch I can consistently reproduce the issue. With the patch the
> test always passes.
>
> Thanks,
> Patricio
Patricio Chilano Mateo has updated the pull request incrementally with one
ad
test always passes.
>>
>> Thanks,
>> Patricio
>
> Changes requested by amenkov (Reviewer).
> _Mailing list message from [David Holmes](mailto:david.hol...@oracle.com) on
> [serviceability-dev](mailto:serviceability-dev@openjdk.java.net):_
>
> On 15/12/2020 10:0
On Fri, 11 Dec 2020 21:47:33 GMT, Patricio Chilano Mateo
wrote:
>>> Pumpers created by ProcessTools.startProcess() log the process
>>> stdout/stderr.
>>> It's quite useful for failure analysis.
>>
>> This was the type of thing I was hinting at
On Fri, 11 Dec 2020 20:48:23 GMT, Chris Plummer wrote:
>> From what I can tell (after a bit of possibly inaccurate grepping) this is
>> the only test that uses `PrcoessTools.startProcess()` in combination with
>> `out.stderrShouldBeEmtpyIgnoreWarnings()`, so I assume this issue of split
>> std
Hi,
Please review the following small fix for test
RemovingUnixDomainSocketTest.java. As explained in the bug comments, the issue
is due to having two different StreamPumper objects consuming from the same
stderr, one created by ProcessTools.startProcess() and another by
OutputAnalyzer(). In t
On Wed, 11 Nov 2020 20:33:15 GMT, Robbin Ehn wrote:
> As the stack trace in the bug shows, we cannot load classes, since we may
> take a monitor.
> Resulting in an unexpected result to GetCurrentContendedMonitor().
> Trying to use some decent primitive, e.g. Wicket/Semaphore/.., without being
>
On Wed, 11 Nov 2020 20:33:15 GMT, Robbin Ehn wrote:
> As the stack trace in the bug shows, we cannot load classes, since we may
> take a monitor.
> Resulting in an unexpected result to GetCurrentContendedMonitor().
> Trying to use some decent primitive, e.g. Wicket/Semaphore/.., without being
>
On Wed, 11 Nov 2020 20:33:15 GMT, Robbin Ehn wrote:
> As the stack trace in the bug shows, we cannot load classes, since we may
> take a monitor.
> Resulting in an unexpected result to GetCurrentContendedMonitor().
> Trying to use some decent primitive, e.g. Wicket/Semaphore/.., without being
>
On Tue, 22 Sep 2020 07:54:57 GMT, Robbin Ehn wrote:
>> This patch implements asynchronous handshake, which changes how handshakes
>> works by default. Asynchronous handshakes
>> are target only executed, which they may never be executed. (target may
>> block on socket for the rest of VM lifetim
On Thu, 17 Sep 2020 18:57:33 GMT, Patricio Chilano Mateo
wrote:
>> Robbin Ehn has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed double checks
>> Added NSV
>> ProcessResult t
On Thu, 17 Sep 2020 12:07:15 GMT, Robbin Ehn wrote:
>> This patch implements asynchronous handshake, which changes how handshakes
>> works by default. Asynchronous handshakes
>> are target only executed, which they may never be executed. (target may
>> block on socket for the rest of VM lifetim
Hi Robbin,
Changes look good to me! Some minor comments:
src/hotspot/share/prims/jvmtiThreadState.cpp
222: assert(current_thread == get_thread() ||
223: SafepointSynchronize::is_at_safepoint() ||
224: get_thread()->is_handshake_safe_for(current_thread),
225: "call by myself /
Hi Yasumasa,
On 8/27/20 10:18 PM, Yasumasa Suenaga wrote:
Hi Patricio,
On 2020/08/27 15:20, Patricio Chilano wrote:
Hi Yasumasa,
On 8/26/20 8:57 PM, Yasumasa Suenaga wrote:
Hi Patricio,
Thanks for your review, but webrev.00 has been rotten.
Can you review webrev.02?
webrev: http
safepoint?
Thanks,
Patricio
Thanks,
Yasumasa
On 2020/08/27 7:50, Patricio Chilano wrote:
Hi Yasumasa,
On 8/26/20 4:34 AM, Yasumasa Suenaga wrote:
Hi Patricio, David,
Thanks for your comment!
I updated webrev which includes the fix which is commented by
Patricio, and it passed submit repo. So
On 2020/08/26 10:13, Patricio Chilano wrote:
Hi Yasumasa,
On 8/23/20 11:40 PM, Yasumasa Suenaga wrote:
Hi all,
I want to hear your opinions about the change for JDK-8242427.
I'm trying to migrate following operations to direct handshake.
- VM_UpdateForPopTopFrame
- VM_SetFra
Hi Yasumasa,
On 8/23/20 11:40 PM, Yasumasa Suenaga wrote:
Hi all,
I want to hear your opinions about the change for JDK-8242427.
I'm trying to migrate following operations to direct handshake.
- VM_UpdateForPopTopFrame
- VM_SetFramePop
- VM_GetCurrentLocation
Some operations (VM_
http://hg.openjdk.java.net/jdk/submit/file/45f52142db9d/test/hotspot/jtreg/serviceability/jvmti/GetThreadListStackTraces/libOneGetThreadListStackTraces.cpp
On 2020/07/10 2:18, Patricio Chilano wrote:
On 7/9/20 12:00 PM, Patricio Chilano wrote:
Hi Yasumasa,
On 7/9/20 9:30 AM, Yasumasa Suenaga wrote:
On 2020/
On 7/9/20 12:00 PM, Patricio Chilano wrote:
Hi Yasumasa,
On 7/9/20 9:30 AM, Yasumasa Suenaga wrote:
On 2020/07/09 17:58, David Holmes wrote:
Hi Yasumasa,
On 9/07/2020 10:25 am, Yasumasa Suenaga wrote:
Hi Dan,
Thanks for your comment!
I uploaded new webrev:
http://cr.openjdk.java.net
Hi Yasumasa,
On 7/9/20 9:30 AM, Yasumasa Suenaga wrote:
On 2020/07/09 17:58, David Holmes wrote:
Hi Yasumasa,
On 9/07/2020 10:25 am, Yasumasa Suenaga wrote:
Hi Dan,
Thanks for your comment!
I uploaded new webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8242428/webrev.09/
Diff from pr
change in the middle of the handshake actually changed.
Thanks,
Patricio
I'll look a bit more at the updated patch but at first glance looks good.
Thanks,
Richard.
-Original Message-
From: Patricio Chilano
Sent: Freitag, 24. April 2020 19:14
To: Reingruber, Richard ; Yasumasa
s://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301763&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301763
-Original Message-
From: Yasumasa Suenaga
Sent: Freitag, 24. April 2020 17:23
To: Reingruber, Richard ; Patricio Chilan
No comments.
Thumbs up.
Thanks for looking at this Dan!
Patricio
Dan
On 3/19/20 2:18 AM, Patricio Chilano wrote:
Hi David,
On 3/18/20 8:10 PM, David Holmes wrote:
Hi Patricio,
On 19/03/2020 6:44 am, Patricio Chilano wrote:
Hi David,
On 3/18/20 4:27 AM, David Holmes wrote:
Hi Pat
Thanks David!
Patricio
On 3/19/20 4:50 AM, David Holmes wrote:
Hi Patricio,
Incremental changes look good.
Thanks,
David
On 19/03/2020 4:18 pm, Patricio Chilano wrote:
Hi David,
On 3/18/20 8:10 PM, David Holmes wrote:
Hi Patricio,
On 19/03/2020 6:44 am, Patricio Chilano wrote:
Hi David
Hi David,
On 3/18/20 8:10 PM, David Holmes wrote:
Hi Patricio,
On 19/03/2020 6:44 am, Patricio Chilano wrote:
Hi David,
On 3/18/20 4:27 AM, David Holmes wrote:
Hi Patricio,
On 18/03/2020 6:14 am, Patricio Chilano wrote:
Hi all,
Please review the following patch:
Bug: https
vePacket_internal(connection, packet);
1234 LEAVE_CONNECTION(connection);
1235 return rc;
1236 }
Done. Fix all those.
Some other nits were already commented by David and Dan.
I'd suggest to test with tier-5 as well for more safety.
Thanks for looking at this Serguei! I'll give it a
Hi Dan,
On 3/18/20 5:30 PM, Daniel D. Daugherty wrote:
On 3/17/20 4:14 PM, Patricio Chilano wrote:
Hi all,
Please review the following patch:
Bug: https://bugs.openjdk.java.net/browse/JDK-8240902
Webrev: http://cr.openjdk.java.net/~pchilanomate/8240902/v1/webrev/
src/jdk.jdi/share/native
Hi David,
On 3/18/20 4:27 AM, David Holmes wrote:
Hi Patricio,
On 18/03/2020 6:14 am, Patricio Chilano wrote:
Hi all,
Please review the following patch:
Bug: https://bugs.openjdk.java.net/browse/JDK-8240902
Webrev: http://cr.openjdk.java.net/~pchilanomate/8240902/v1/webrev/
Calling
Hi all,
Please review the following patch:
Bug: https://bugs.openjdk.java.net/browse/JDK-8240902
Webrev: http://cr.openjdk.java.net/~pchilanomate/8240902/v1/webrev/
Calling closeConnection() on an already created/opened connection
includes calls to CloseHandle() on objects that can still be us
rther
encouraged to do it with a handshake :)
Ah! I think you can still do it with a handshake with the
Deoptimization::deoptimize_all_marked() like solution. I can change the
if-else statement with just the Handshake::execute() call in 8239084.
But up to you. : )
Thanks,
Patricio
Thanks again,
Richar
Hi Richard,
I’m only commenting on the handshake changes.
I see that operation VM_EnterInterpOnlyMode can be called inside
operation VM_SetFramePop which also allows nested operations. Here is a
comment in VM_SetFramePop definition:
// Nested operation must be allowed for the VM_EnterInterpOn
Hi David,
On 12/8/18 6:21 PM, David Holmes wrote:
Hi Patricio,
On 9/12/2018 9:04 am, Patricio Chilano wrote:
Hi,
Could you review this small fix for test
serviceability/tmtools/jstack/WaitNotifyThreadTest.java ?
After change 8214148 the test fails if the flag -Xcomp is used as
explained in
Hi,
Could you review this small fix for test
serviceability/tmtools/jstack/WaitNotifyThreadTest.java ?
After change 8214148 the test fails if the flag -Xcomp is used as
explained in the bug details. The proposed change is to identified this
special case and set the monitor address to match the
Thanks David!
Patricio
On 12/3/18 11:30 PM, David Holmes wrote:
Looks good!
Thanks,
David
On 4/12/2018 2:48 am, Patricio Chilano wrote:
Hi David,
On 12/3/18 2:14 AM, David Holmes wrote:
Hi Patricio,
On 1/12/2018 2:31 am, Patricio Chilano wrote:
Hi David,
On 11/29/18 8:05 PM, David
Hi David,
On 12/3/18 2:14 AM, David Holmes wrote:
Hi Patricio,
On 1/12/2018 2:31 am, Patricio Chilano wrote:
Hi David,
On 11/29/18 8:05 PM, David Holmes wrote:
Hi Patricio,
This seems very complicated and I'm not quite seeing how it all goes
together. The check for waiting to re-loc
fyAll();
<= take stack dump here =>
}
Cheers,
David
On 30/11/2018 5:52 am, Daniel D. Daugherty wrote:
Adding serviceability-dev@... since the 'tmtools' including 'jstack'
are owned by the Serviceability team.
Dan
On 11/28/18 4:21 PM, Patricio Chilano wrote:
Hi all,
69 matches
Mail list logo
