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
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 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 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
>
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 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
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
test always passes.
>>
>> Thanks,
>> Patricio
>
> Changes requested by amenkov (Reviewer).
> _Mailing list message from [David Holmes](mailto:[email protected]) on
> [serviceability-dev](mailto:[email protected]):_
>
> On 15/12/2020 10:0
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
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
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 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 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 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 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 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, 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, 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 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 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 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 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 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, 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 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 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 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 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 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, 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 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 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
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 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
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 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 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 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 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 <[[email protected]](mailto:[email protected])>
> Date: Mon Nov 8 14:45:04 2021 +
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
45 matches
Mail list logo
