Quick Startup/Footprint,
> SPECjbb2015-Tuned-G1, SPECjbb2015-Tuned-ParGC, Volano)
> - a few minor regressions (<= -0.24%)
> - Volano is 6.8% better
>
> Eric C. has also done promotion perf runs on these bits and says "the results
> look fine".
Daniel D. Daughe
On Tue, 10 Nov 2020 14:53:34 GMT, Daniel D. Daugherty
wrote:
>> Looks very good! Thanks for picking this up and taking it all the way!
>
> @fisk - Thanks for the sanity check review. And thanks for prototyping
> this work and showing that this crazy idea could work! :-)
@coleenp
On Tue, 10 Nov 2020 15:02:31 GMT, Daniel D. Daugherty
wrote:
>> I'd rather see ThreadBlockInVM as the convention of allowing the thread to
>> block if a safepoint is requested. The calls like process_if_requested are
>> becoming alphabet soup and keep changing, so ha
On Tue, 10 Nov 2020 19:41:23 GMT, Robbin Ehn wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> coleenp CR - refactor common ThreadBlockInVM code block into
>> ObjectSynchronizer
On Tue, 10 Nov 2020 20:34:12 GMT, Robbin Ehn wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> coleenp CR - refactor common ThreadBlockInVM code block into
>> ObjectSynchronize
On Tue, 10 Nov 2020 20:52:15 GMT, Robbin Ehn wrote:
>> We may still decide to do this fix (even though the _object field is now
>> weak):
>>
>> JDK-8249638 Re-instate idle monitor deflation as part of System.gc()
>> https://bugs.openjdk.java.net/browse/JDK-8249638
>>
>> and if we do, t
On Tue, 10 Nov 2020 16:41:49 GMT, Coleen Phillimore wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> dholmes-ora - convert inner while loop to do-while loop in
>> unlink_def
On Tue, 10 Nov 2020 20:55:17 GMT, Robbin Ehn wrote:
>> @fisk said we should not release the oopStorage during a safepoint
>> because that's not safe or will not be safe. I can't remember which.
>
> Yes that's why I said you can release it during deflation instead.
>
> (not saying you should do t
On Tue, 10 Nov 2020 16:46:10 GMT, Coleen Phillimore wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> dholmes-ora - convert inner while loop to do-while loop in
>> unlink_def
On Tue, 10 Nov 2020 17:05:16 GMT, Coleen Phillimore wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> dholmes-ora - convert inner while loop to do-while loop in
>> unlink_def
On Tue, 10 Nov 2020 17:32:56 GMT, Coleen Phillimore wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> dholmes-ora - convert inner while loop to do-while loop in
>> unlink_def
On Tue, 10 Nov 2020 20:57:48 GMT, Coleen Phillimore wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> dholmes-ora - convert inner while loop to do-while loop in
>> unlink_def
On Tue, 10 Nov 2020 21:16:33 GMT, Robbin Ehn wrote:
>> So if I narrow the scope around the ThreadBlockInVM, then it would be fine?
>>
>> {
>> // Honor block request.
>> ThreadBlockInVM tbivm(self);
>> }
>>
>> I can make that change before I integrate...
>
> Yes that avoids it!
Done. I also
On Tue, 10 Nov 2020 22:08:10 GMT, Coleen Phillimore wrote:
>> Done. I also did the one in
>> ObjectSynchronizer::request_deflate_idle_monitors().
>
> I like it but can you do one thing for me? Can you s/chk/check/ in the name?
I'd rather not. It is a function with six freaking parameters so
I
On Tue, 10 Nov 2020 22:27:06 GMT, Coleen Phillimore wrote:
>> No it is not a ref_count. We got rid of the accurate ref_count field
>> because maintaining it was too slow.
>>
>> contentions just tells you how many threads have blocked on the
>> slow-path trying to enter the monitor. The fast-path
On Tue, 10 Nov 2020 20:34:12 GMT, Robbin Ehn wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> coleenp CR - refactor common ThreadBlockInVM code block into
>> ObjectSynchronize
Quick Startup/Footprint,
> SPECjbb2015-Tuned-G1, SPECjbb2015-Tuned-ParGC, Volano)
> - a few minor regressions (<= -0.24%)
> - Volano is 6.8% better
>
> Eric C. has also done promotion perf runs on these bits and says "the results
> look fine".
Daniel D. Daughe
On Tue, 10 Nov 2020 23:27:52 GMT, Daniel D. Daugherty
wrote:
>> Well since it controls async deflation, it should probably get a mention
>> since this comment on its own is not true:
>>
>> // Keep track of contention for JVM/TI and M&M queries and control async
&g
On Tue, 10 Nov 2020 23:15:15 GMT, Coleen Phillimore wrote:
>> Ahhh... I think I understand your confusion. This line:
>>
>> L550: // Deferred decrement for the JT EnterI() that cancelled the async
>> deflation.
>> L551: add_to_contentions(-1);
>>
>> doesn't match up with this line:
>>
>> L36
On Wed, 11 Nov 2020 04:50:52 GMT, David Holmes wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> resolve more robehn and coleenp comments.
>
> src/hotspot/share/runtime/synchr
On Wed, 11 Nov 2020 08:26:14 GMT, Robbin Ehn wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> resolve more robehn and coleenp comments.
>
> src/hotspot/share/runtime/synchron
On Wed, 11 Nov 2020 13:50:08 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/runtime/synchronizer.cpp line 246:
>>
>>> 244: //
>>> 245: // Start the ceiling with the estimate for one thread:
>>> 246: jint _in_use_list_ceiling = AvgMonitorsPerThreadEstimate;
>>
>> Why is this a jint when you
On Wed, 11 Nov 2020 05:12:21 GMT, David Holmes wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> resolve more robehn and coleenp comments.
>
> One change requested in relation to
On Wed, 11 Nov 2020 13:50:08 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/runtime/synchronizer.cpp line 246:
>>
>>> 244: //
>>> 245: // Start the ceiling with the estimate for one thread:
>>> 246: jint _in_use_list_ceiling = AvgMonitorsPerThreadEstimate;
>>
>> Why is this a jint when you
Quick Startup/Footprint,
> SPECjbb2015-Tuned-G1, SPECjbb2015-Tuned-ParGC, Volano)
> - a few minor regressions (<= -0.24%)
> - Volano is 6.8% better
>
> Eric C. has also done promotion perf runs on these bits and says "the results
> look fine".
Daniel D. Daugherty has
On Tue, 13 Oct 2020 20:31:44 GMT, Daniel D. Daugherty
wrote:
> Changes from @fisk and @dcubed-ojdk to:
>
> - simplify ObjectMonitor list management
> - get rid of Type-Stable Memory (TSM)
>
> This change has been tested with Mach5 Tier[1-3],4,5,6,7,8; no new
> regression
On Wed, 11 Nov 2020 16:18:41 GMT, Robbin Ehn wrote:
>> Daniel D. Daugherty has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains ten commits:
>>
>> - @dholmes-ora, @robehn and @coleenp CR - a few more minor tw
On Wed, 11 Nov 2020 05:12:21 GMT, David Holmes wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> resolve more robehn and coleenp comments.
>
> One change requested in relation to
On Wed, 11 Nov 2020 16:16:19 GMT, Erik Österlund wrote:
>> @coleenp - Nice catch on the missing 'static'.
>
> I typically use size_t for entities that can scale with the size of the
> machine's memory, so I don't have to think about whether there are enough
> bits. Could AvgMonitorsPerThreadEst
On Wed, 11 Nov 2020 22:33:57 GMT, Patricio Chilano Mateo
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/..,
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 Thu, 12 Nov 2020 08:11:10 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 bein
On Tue, 10 Nov 2020 21:16:20 GMT, Robbin Ehn wrote:
>> Sorry my preference is for Monitors instead of semaphores. Let's
>> take that discussion off this PR and you can explain why you dislike
>> the Monitor so much and think the local semaphore is the way to go.
>
> Yes
Filed the following new R
On Tue, 10 Nov 2020 21:37:40 GMT, Daniel D. Daugherty
wrote:
>> If you only need to free CHeap memory, you can do:
>>size_t deleted_count = 0;
>>ThreadBlockInVM tbivm(self);
>> for (ObjectMonitor* monitor: delete_list) {
>> delete m
On Tue, 10 Nov 2020 20:57:00 GMT, Robbin Ehn wrote:
>> We've removed enough padding with this work already. If we
>> want to do more padding removal, then we need to use a
>> different RFE.
>
> Sure, this was more a FYI.
Filed this new RFE:
JDK-8256303 revisit ObjectMonitor padding between f
On Tue, 10 Nov 2020 21:08:53 GMT, Daniel D. Daugherty
wrote:
>> src/hotspot/share/runtime/globals.hpp line 750:
>>
>>> 748: product(intx, MonitorUsedDeflationThreshold, 90, EXPERIMENTAL,
>>> \
>>> 749: "Percentage of used mon
On Tue, 10 Nov 2020 22:28:12 GMT, Coleen Phillimore wrote:
>> It can be a future RFE, but it won't be at the top of my list of
>> things to do. There may already be an RFE for that.
>
> No, I assume it's not high priority. I'll file an RFE because someday I want
> these to be cleaned up as a pe
On Wed, 11 Nov 2020 16:35:50 GMT, Daniel D. Daugherty
wrote:
>> I typically use size_t for entities that can scale with the size of the
>> machine's memory, so I don't have to think about whether there are enough
>> bits. Could AvgMonitorsPerThreadEstimate be uin
On Tue, 1 Dec 2020 12:47:04 GMT, Coleen Phillimore wrote:
> Test passed tier1-3 with no failures.
Tier5 and Tier6 have more JPDA testing (JVM/TI, JDWP, JDI, ...)
-
PR: https://git.openjdk.java.net/jdk/pull/1539
On Wed, 2 Dec 2020 19:13:50 GMT, Leonid Mesnik wrote:
> The test is manual and shouldn't use the timeout
Thumbs up.
This is a trivial change and does not need to wait 24 hours.
-
Marked as reviewed by dcubed (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/1573
On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote:
> See bug for details. Tested:
>
> $ java -XX:+StressLdcRewrite -version
> Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via
> -XX:+UnlockDiagnosticVMOptions.
> Error: The unlock option must precede 'StressLdcRe
ProblemList three jstatd tests on Win* to reduce the noise in the JDK16 CI.
-
Commit messages:
- 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and
TestJstatdServer.java
Changes: https://git.openjdk.java.net/jdk16/pull/57/files
Webrev: https://webrevs.openjd
On Mon, 21 Dec 2020 22:09:33 GMT, Daniel D. Daugherty
wrote:
> ProblemList three jstatd tests on Win* to reduce the noise in the JDK16 CI.
Links to the JDK16 CI failures for each of the three tests are in the bug
report.
-
PR: https://git.openjdk.java.net/jdk16/pull/57
On Mon, 21 Dec 2020 22:44:51 GMT, Alex Menkov wrote:
>> ProblemList three jstatd tests on Win* to reduce the noise in the JDK16 CI.
>
> Marked as reviewed by amenkov (Reviewer).
@alexmenkov and @plummercj - Thanks for the fast reviews.
-
PR: https://git.openjdk.java.net/jdk16/pull/
On Mon, 21 Dec 2020 22:09:33 GMT, Daniel D. Daugherty
wrote:
> ProblemList three jstatd tests on Win* to reduce the noise in the JDK16 CI.
This pull request has now been integrated.
Changeset: 88dd6a94
Author: Daniel D. Daugherty
URL: https://git.openjdk.java.net/jdk16/com
ProblemList two java/rmi/Naming tests on Windows in order to reduce the
noise in the JDK16 CI. This is a trivial fix.
-
Commit messages:
- 8258827: ProblemList Naming/DefaultRegistryPort.java and
Naming/legalRegistryNames/LegalRegistryNames.java on Windows
Changes: https://git.open
On Tue, 22 Dec 2020 17:14:24 GMT, Phil Race wrote:
>> ProblemList two java/rmi/Naming tests on Windows in order to reduce the
>> noise in the JDK16 CI. This is a trivial fix.
>
> overdue
Thanks for the fast reviews!
-
PR: https://git.openjdk.java.net/jdk16/pull/58
On Tue, 22 Dec 2020 16:56:33 GMT, Daniel D. Daugherty
wrote:
> ProblemList two java/rmi/Naming tests on Windows in order to reduce the
> noise in the JDK16 CI. This is a trivial fix.
This pull request has now been integrated.
Changeset: eabc9030
Author:Daniel D. Daughert
This is a trivial fix to ProblemList com/sun/jdi/AfterThreadDeathTest.java on
Linux-X64.
-
Commit messages:
- 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64
Changes: https://git.openjdk.java.net/jdk16/pull/59/files
Webrev: https://webrevs.openjdk.java.net/
On Tue, 22 Dec 2020 17:42:49 GMT, Daniel D. Daugherty
wrote:
> This is a trivial fix to ProblemList com/sun/jdi/AfterThreadDeathTest.java on
> Linux-X64.
This pull request has now been integrated.
Changeset: 61e5e393
Author:Daniel D. Daugherty
URL: https://git.openjdk.ja
On Tue, 22 Dec 2020 18:00:29 GMT, Alex Menkov wrote:
>> This is a trivial fix to ProblemList com/sun/jdi/AfterThreadDeathTest.java
>> on Linux-X64.
>
> Marked as reviewed by amenkov (Reviewer).
Thanks for the fast reviews!
-
PR: https://git.openjdk.java.net/jdk16/pull/59
This is a trivial fix to ProblemList
serviceability/attach/RemovingUnixDomainSocketTest.java
on Linux-X64.
The test has been failing fairly frequently in the JDK17 CI when it is run with
the
"-XX:NativeMemoryTracking=detail" option. We currently only specify that
configuration
on linux-x64 so I
On Wed, 23 Dec 2020 20:21:12 GMT, Daniel D. Daugherty
wrote:
> This is a trivial fix to ProblemList
> serviceability/attach/RemovingUnixDomainSocketTest.java
> on Linux-X64.
>
> The test has been failing fairly frequently in the JDK17 CI when it is run
> with the
> &quo
On Wed, 23 Dec 2020 20:27:11 GMT, Alex Menkov wrote:
>> Marked as reviewed by amenkov (Reviewer).
>
> Agreed that this is trivial fix
@alexmenkov - Thanks for the fast review!
-
PR: https://git.openjdk.java.net/jdk/pull/1884
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
acquired (depends on JDK-8256383). Uses a ThreadsListHandle to make
the cu
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_l
On Thu, 24 Dec 2020 22:01:38 GMT, Erik Österlund 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
>> acqu
On Thu, 24 Dec 2020 22:14:43 GMT, Erik Österlund wrote:
>> Looks good. We have something similar in the precious GC log code during
>> error reporting.
>
>> @fisk - Thanks for the review! And Merry Christmas Eve!!
>
> Merry Christmas to you too Dan!
Ping! I could use a second review here...
-
On Mon, 4 Jan 2021 16:28:42 GMT, Coleen Phillimore 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 Mon, 4 Jan 2021 18:42:54 GMT, Patricio Chilano Mateo
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
On Tue, 5 Jan 2021 09:44:19 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/runtime/threadSMR.cpp line 1148:
>>
>>> 1146: }
>>> 1147: }
>>> 1148: if (!EnableThreadSMRStatistics) {
>>
>> You could switch to "if(EnableThreadSMRStatistics)" instead and put this
>> code at the end to avoi
On Tue, 5 Jan 2021 09:48:11 GMT, Serguei Spitsyn 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
>> acqu
On Tue, 5 Jan 2021 21:45:19 GMT, Daniel D. Daugherty wrote:
>> Hi Dan,
>>
>> It looks good modulo a couple of suggestions from Patricio.
>>
>> Thanks,
>> Serguei
>
> Made copyright changes based on comments from coleenp,
> code changes based on co
the use of a ThreadsListHandle
> in ThreadsSMRSupport::print_info_on(). Mach5 Tier[1-6] testing has no
> regressions.
Daniel D. Daugherty has updated the pull request incrementally with one
additional commit since the last revision:
Address comments from coleenp and pchilano.
--
On Wed, 6 Jan 2021 00:29:10 GMT, Patricio Chilano Mateo
wrote:
>> LGTM!
>
> Looks good, thanks Dan!
sspitsyn, coleenp, and pchilano - Thanks for the re-reviews!
My local Linux-X64 build and test went fine. My Mach5 Tier1 passed
without failures. Mach5 Tier[23] are still running.
-
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_l
On Tue, 5 Jan 2021 14:48:13 GMT, Coleen Phillimore wrote:
>> This change allows JRT_LEAF functions to create Handles because it doesn't
>> need them but some code inside the VM needs Handles. There's a
>> NoSafepointVerifier in JRT_LEAF functions.
>> The JNI_LEAF and JVM_LEAF functions have No
On Tue, 5 Jan 2021 14:37:53 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 353:
>>
>>> 351: #define VM_LEAF_BASE(result_type, header)\
>>> 352: TRACE_CALL(result_type, header)\
>>> 353:
On Thu, 7 Jan 2021 16:04:28 GMT, Coleen Phillimore wrote:
> This is a trivial change to remove the comments and the ResetNoHandleMark
> from jvmti functions. They're called by JNI_ENTRY so they don't have a
> NoHandleMark that needs to be reset. It may not have always been the case.
> Tested
Redirecting to the serviceability-dev@... alias since JVM/TI is maintained
by the Serviceability team...
Dan
On 1/10/21 6:09 PM, Mikael Vidstedt wrote:
Just a control question: Are you *sure* asserts are actually enabled? Having
actual application logic in an assert is normally a bad idea beca
On Thu, 21 Jan 2021 18:36:00 GMT, Gerard Ziemski wrote:
>> Thanks @dholmes-ora for the comment and review!
>> I fixed them in new commit.
>>
>> I wait the review from @dcubed-ojdk .
>
> Hi Yasumasa,
>
> Just to let you know, I'm taking a look at your fix...
I'm taking a look now... We should a
On Tue, 19 Jan 2021 08:58:10 GMT, Yasumasa Suenaga wrote:
>> I saw the exception as following when I chose "Monitor Cache Dump" menu on
>> HSDB:
>>
>> Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError
>> at
>> jdk.hotspot.agent/sun.jvm.hotspot.ui.MonitorCache
I'm reducing the noise in the JDK17 CI by ProblemListing this new test
on Win* with ZGC.
-
Commit messages:
- 8260381: ProblemList
com/sun/management/DiagnosticCommandMBean/DcmdMBeanTestCheckJni.java on Win
with ZGC
Changes: https://git.openjdk.java.net/jdk/pull/2225/files
Webrev
On Mon, 25 Jan 2021 17:09:17 GMT, Daniel D. Daugherty
wrote:
> I'm reducing the noise in the JDK17 CI by ProblemListing this new test
> on Win* with ZGC.
This pull request has now been integrated.
Changeset: 5b0b24b5
Author: Daniel D. Daugherty
URL: https://git.openjdk.j
On Mon, 25 Jan 2021 17:27:51 GMT, Serguei Spitsyn wrote:
>> I'm reducing the noise in the JDK17 CI by ProblemListing this new test
>> on Win* with ZGC.
>
> Hi Dan,
> It looks good and trivial.
> Thanks,
> Serguei
@sspitsyn - Thanks for the fast review! And thanks for calling it trivial.
I forgot
On Mon, 25 Jan 2021 21:59:38 GMT, Daniel D. Daugherty
wrote:
>> Yasumasa Suenaga has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Update copyright year
>> - Remove unused code
>
> Thumbs up.
@ssp
On Sat, 23 Jan 2021 03:23:58 GMT, Yasumasa Suenaga wrote:
>> I saw the exception as following when I chose "Monitor Cache Dump" menu on
>> HSDB:
>>
>> Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError
>> at
>> jdk.hotspot.agent/sun.jvm.hotspot.ui.MonitorCache
On Mon, 25 Jan 2021 22:28:08 GMT, Chris Plummer wrote:
>> Yasumasa Suenaga has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Update copyright year
>> - Remove unused code
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/O
On Tue, 26 Jan 2021 08:29:03 GMT, Yasumasa Suenaga wrote:
>> I saw the exception as following when I chose "Monitor Cache Dump" menu on
>> HSDB:
>>
>> Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError
>> at
>> jdk.hotspot.agent/sun.jvm.hotspot.ui.MonitorCache
On Sat, 23 Jan 2021 03:25:49 GMT, Yasumasa Suenaga wrote:
>> test/hotspot/jtreg/serviceability/sa/TestObjectMonitorIterate.java line 78:
>>
>>> 76: SATestUtils.addPrivilegesIfNeeded(processBuilder);
>>> 77: OutputAnalyzer SAOutput =
>>> ProcessTools.executeProcess(processBuilder
On Tue, 26 Jan 2021 11:33:37 GMT, Severin Gehwolf wrote:
> I propose to add additional context to the string which must not match after
> [JDK-8258836](https://bugs.openjdk.java.net/browse/JDK-8258836). This then
> passes the test for a fixed JDK (including JDKs with JDK-8187450 *not* fixed).
>
On Wed, 27 Jan 2021 00:59:59 GMT, Yasumasa Suenaga wrote:
>> I saw the exception as following when I chose "Monitor Cache Dump" menu on
>> HSDB:
>>
>> Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError
>> at
>> jdk.hotspot.agent/sun.jvm.hotspot.ui.MonitorCache
On Wed, 27 Jan 2021 05:41:47 GMT, Yasumasa Suenaga wrote:
>> Hi Yasumasa,
>>
>> I thought the comments regarding the test were to use an if statement to
>> check iter.hasNext() and return after seeing one Monitor, rather than
>> keeping the while-loop and reporting every single Monitor found.
On Wed, 27 Jan 2021 14:17:22 GMT, Daniel D. Daugherty
wrote:
>>> I thought the comments regarding the test were to use an if statement to
>>> check iter.hasNext() and return after seeing one Monitor, rather than
>>> keeping the while-loop and reporting every singl
On Tue, 2 Feb 2021 12:00:00 GMT, Thomas Stuefe wrote:
>> Hi,
>>
>> may I please have reviews for this trivial fix.
>>
>> We see timeouts with this test on slow large (memory wise) AIX machines, as
>> well as large core files.
>>
>> This test is a negative test which tests that the VM corectly
On Tue, 2 Feb 2021 14:52:50 GMT, Daniel D. Daugherty wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary CreateCoredumpOnCrash
>
> Thumbs up! Thanks for taking ca
On Tue, 2 Feb 2021 11:59:08 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Fri, 5 Feb 2021 21:09:37 GMT, Alex Menkov wrote:
> JDK-8258917 fixed non-java launchers ("wrong launcher" VM warning for tools).
> The fix un-problemlists RemovingUnixDomainSocketTest and changes
> serviceability tests to use
> OutputAnalyzer.stderrShouldBeEmptyIgnoreDeprecatedWarnings inste
A minor fix to add a new function:
bool Thread::is_JavaThread_protected(const JavaThread* p)
that returns true when the target JavaThread* is protected and false
otherwise. Update JavaThread::get_thread_name() to create a
ThreadsListHandle and use the new is_JavaThread_protected(). Also
updat
On Thu, 11 Feb 2021 22:04:53 GMT, Daniel D. Daugherty
wrote:
> A minor fix to add a new function:
>
> bool Thread::is_JavaThread_protected(const JavaThread* p)
>
> that returns true when the target JavaThread* is protected and false
> otherwise. Update JavaThread::ge
On Thu, 11 Feb 2021 22:07:22 GMT, Daniel D. Daugherty
wrote:
>> A minor fix to add a new function:
>>
>> bool Thread::is_JavaThread_protected(const JavaThread* p)
>>
>> that returns true when the target JavaThread* is protected and false
>> otherwise
On Fri, 12 Feb 2021 07:36:06 GMT, Robbin Ehn wrote:
>> A minor fix to add a new function:
>>
>> bool Thread::is_JavaThread_protected(const JavaThread* p)
>>
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
On Fri, 12 Feb 2021 22:02:18 GMT, Coleen Phillimore wrote:
>> A minor fix to add a new function:
>>
>> bool Thread::is_JavaThread_protected(const JavaThread* p)
>>
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to c
On Fri, 12 Feb 2021 23:37:40 GMT, Coleen Phillimore wrote:
>> JavaThread::get_thread_name() also calls is_JavaThread_protected().
>>
>> The "friend" is so that JvmtiTrace can call get_thread_name_string()
>> and we can get rid of the JvmtiTrace version of the logic. I kept the
>> "" rather than
On Sat, 13 Feb 2021 04:30:48 GMT, Daniel D. Daugherty
wrote:
>> So Thread::is_JavaThread_protected() should be "protected" then, not public.
>> yes, I was suggesting adding a default last parameter like
>> JavaThread::get_thread_name(char* default = Thread::
On Sat, 13 Feb 2021 15:24:33 GMT, Coleen Phillimore wrote:
>> The name "default" is reserved so I went with "def_name".
>> You can't call Thread::name() from the declaration:
>> ./open/src/hotspot/share/runtime/thread.hpp:1690:62: error: call to
>> non-static member function without an object ar
On Sat, 13 Feb 2021 15:25:16 GMT, Daniel D. Daugherty
wrote:
>> default_name, it's not long enough to abbreviate... but yes. thanks!
>
> And it looks like making is_JavaThread_protected() a protected function
> doesn't work either since `JavaThread::get_thr
andle and use the new is_JavaThread_protected(). Also
> update JvmtiTrace::safe_get_thread_name() to use the new
> is_JavaThread_protected().
>
> This fix is tested via a Mach5 Tier[1-8] run.
Daniel D. Daugherty has updated the pull request incrementally with one
additional commit since the last revision
On Sat, 13 Feb 2021 03:36:32 GMT, Serguei Spitsyn wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address coleenp CR0 comments.
>
> Hi Dan,
> It looks good to me modulo yo
On Tue, 16 Feb 2021 12:35:28 GMT, Coleen Phillimore wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address coleenp CR0 comments.
>
> Thanks!
@coleenp and @sspits
901 - 1000 of 1805 matches
Mail list logo
