Re: RFR: 8266967: debug.cpp utility find() should print Java Object fields. [v2]

2021-06-01 Thread Coleen Phillimore
On Thu, 13 May 2021 13:24:17 GMT, Kevin Walls wrote: >> This change enables debug.cpp's find() utility to print Java Objects with >> their fields. >> >> find() calls os::print_location, and Java heap objects are printed with >> instanceKlass oop_print_on. >> Removing the ifdef for defining oop

Re: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions properly

2021-06-01 Thread Leonid Mesnik
On Tue, 1 Jun 2021 21:54:27 GMT, Leonid Mesnik wrote: > 8266337: ThreadTimesClosure doesn't handle exceptions properly Serguei, Thanks for the suggestion. It is not exactly part of this bug but is really close. Updated to used strdup_check_oom instead of strdup. - PR: https://g

Re: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions properly [v2]

2021-06-01 Thread Leonid Mesnik
> 8266337: ThreadTimesClosure doesn't handle exceptions properly Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: strdup_check_oom is used instead of strdup. - Changes: - all: https://git.openjdk.java.net/jdk/pull/4292

Re: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions properly

2021-06-01 Thread Serguei Spitsyn
On Tue, 1 Jun 2021 21:54:27 GMT, Leonid Mesnik wrote: > 8266337: ThreadTimesClosure doesn't handle exceptions properly Hi Leonid, This looks good to me. One thing to consider is to use `os::strdup_check_oom` instead of `os::strdup`. The os::strdup can return NULL. Thanks, Serguei

Re: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions properly

2021-06-01 Thread David Holmes
On Tue, 1 Jun 2021 21:54:27 GMT, Leonid Mesnik wrote: > 8266337: ThreadTimesClosure doesn't handle exceptions properly Hi Leonid, This change looks good to me. Thanks, David src/hotspot/share/services/management.cpp line 1708: > 1706: Threads::threads_do(&ttc); > 1707: } > 1708: ttc.

Re: RFR: 8266957: SA has not followed JDK-8220587 and JDK-8224965

2021-06-01 Thread Yasumasa Suenaga
On Tue, 1 Jun 2021 17:51:24 GMT, Chris Plummer wrote: >> Following jtreg tests for SA would fail because SA has not followed >> [JDK-8220587](https://bugs.openjdk.java.net/browse/JDK-8220587) and >> [JDK-8224965](https://bugs.openjdk.java.net/browse/JDK-8224965). >> >> * serviceability/sa/Clhs

Re: RFR: 8237388: serviceability/dcmd/framework/VMVersionTest.java fails with connection refused error.

2021-06-01 Thread Alex Menkov
On Tue, 1 Jun 2021 17:56:10 GMT, Chris Plummer wrote: >> nsk test framework for testing jdi/jdwp assumes that the test launch >> debuggee first and then creates IOPipe to communicate with debuggee >> (debugger listens, debugee connects to the IOPipe socket). >> This makes possible failure when

RFR: 8266337: ThreadTimesClosure doesn't handle exceptions properly

2021-06-01 Thread Leonid Mesnik
8266337: ThreadTimesClosure doesn't handle exceptions properly - Commit messages: - 8266337: ThreadTimesClosure doesn't handle exceptions properly Changes: https://git.openjdk.java.net/jdk/pull/4292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4292&range=00 Issue:

Re: RFR: 8237388: serviceability/dcmd/framework/VMVersionTest.java fails with connection refused error.

2021-06-01 Thread Chris Plummer
On Thu, 27 May 2021 23:00:56 GMT, Alex Menkov wrote: > nsk test framework for testing jdi/jdwp assumes that the test launch debuggee > first and then creates IOPipe to communicate with debuggee (debugger listens, > debugee connects to the IOPipe socket). > This makes possible failure when debug

Re: RFR: 8266130: convert Thread-SMR stress tests from counter based to time based [v2]

2021-06-01 Thread Daniel D . Daugherty
> The Thread-SMR project added counter based tests for various APIs. > See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes". > > Time based tests are more appropriate for stress kits so I'm > updating the counter based tests to be time based instead. > > Two of the updated tests

Integrated: 8264800: cleanup Threads_lock comments in JVM/TI function headers

2021-06-01 Thread Daniel D . Daugherty
On Fri, 28 May 2021 19:40:00 GMT, Daniel D. Daugherty wrote: > A trivial fix to cleanup Threads_lock comments in JVM/TI function headers. > > Also remove errant text added by the jframeID XSL template code: > > > // java_thread - unchecked > // depth - pre-checked as non-negative > > > The

Re: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function headers

2021-06-01 Thread Daniel D . Daugherty
On Mon, 31 May 2021 06:41:29 GMT, Robbin Ehn wrote: >> A trivial fix to cleanup Threads_lock comments in JVM/TI function headers. >> >> Also remove errant text added by the jframeID XSL template code: >> >> >> // java_thread - unchecked >> // depth - pre-checked as non-negative >> >> >> The

Integrated: 8265148: StackWatermarkSet being updated during AsyncGetCallTrace

2021-06-01 Thread Leonid Mesnik
On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik wrote: > 8265148: StackWatermarkSet being updated during AsyncGetCallTrace This pull request has now been integrated. Changeset: 2b338355 Author:Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/2b3383557f71ede15d00bd87742a277

Re: RFR: 8266957: SA has not followed JDK-8220587 and JDK-8224965

2021-06-01 Thread Chris Plummer
On Mon, 17 May 2021 12:07:13 GMT, Yasumasa Suenaga wrote: > Following jtreg tests for SA would fail because SA has not followed > [JDK-8220587](https://bugs.openjdk.java.net/browse/JDK-8220587) and > [JDK-8224965](https://bugs.openjdk.java.net/browse/JDK-8224965). > > * serviceability/sa/Clhsd

Re: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function headers

2021-06-01 Thread Serguei Spitsyn
On Fri, 28 May 2021 19:40:00 GMT, Daniel D. Daugherty wrote: > A trivial fix to cleanup Threads_lock comments in JVM/TI function headers. > > Also remove errant text added by the jframeID XSL template code: > > > // java_thread - unchecked > // depth - pre-checked as non-negative > > > The

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8]

2021-06-01 Thread Joe Wang
On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. >> https://github.com/openjdk/jdk/commit/576161d15423f58281e384

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8]

2021-06-01 Thread Alan Bateman
On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. >> https://github.com/openjdk/jdk/commit/576161d15423f58281e384

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8]

2021-06-01 Thread Weijun Wang
> Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. > https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 > The essential change for this JEP, incl

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v7]

2021-06-01 Thread Weijun Wang
> Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. > https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 > The essential change for this JEP, incl

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6]

2021-06-01 Thread Alan Bateman
On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. >> https://github.com/openjdk/jdk/commit/576161d15423f58281e38