RFR: 8274620: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out

This PR fix the issue of JDK-8274620 (resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out) The root cause is that `BufferedOutputStream` should be used when writting data to file. - Commit messages: - Undo problem list of the test case - 8274620: TestHeapDu

Re: Extend jcmd to java application level

Hi Denghui, I thought to add JMX client feature to jcmd in the past for similar purposes, but I didn't because JMX URL is too complex to type into console :) Your proposal is useful, but it means malicious users can inject arbitrary code. I think we need to consider security, and existing fram

Re: Extend jcmd to java application level

Hi Denghui, On 7/10/2021 11:58 pm, Denghui Dong wrote: Hi team, The `jcmd` command can be used to call some built-in diagnostic commands in vm. Can we consider extending it to the java layer like perf data, so that Java  developers can customize their diagnostic commands and then call them thro

Re: Extend jcmd to java application level

Hi Yasumasa, JVMTI.data_dump and DataDumpRequest can achieve the purpose of triggering. IIUC, DataDumpRequest does not seem to be able to pass parameters. And sometimes the action the user wants to trigger may not be a data dump. In fact, I think that commands such as JFR.start/stop are such a m

Re: RFR: 8274004: Change 'nonleaf' rank name [v2]

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

Re: Extend jcmd to java application level

Hi Denghui, I think you can do it with combination of JVMTI.data_dump dcmd and DataDumpRequest event in JVMTI. JVM(TM) Tool Interface 17.0.0 (oracle.com) Thanks, Yasumasa On 2021/10/07 22:58, Denghui Dong

Re: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string

On Thu, 7 Oct 2021 21:46:47 GMT, Alex Menkov wrote: > The fix adds "-XX:PerfMaxStringConstLength" argument running target app > (default is 1024, 8K should be enough for any environments) LGTM. Thanks, Serguei - Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.j

RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string

The fix adds "-XX:PerfMaxStringConstLength" argument running target app (default is 1024, 8K should be enough for any environments) - Commit messages: - JDK-8274930 Changes: https://git.openjdk.java.net/jdk/pull/5858/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5858

Integrated: 8273152: Refactor CDS FileMapHeader loading code

On Thu, 30 Sep 2021 05:43:40 GMT, Yumin Qi wrote: > Please review, > Refactor fundamental CDS FileMapHeader code for reliable reading of basic > info from shared archive. > With the change, it makes it possible to read an archive generated by > different version of hotspot. Also it is possi

Re: RFR: 8273152: Refactor CDS FileMapHeader loading code [v8]

On Thu, 7 Oct 2021 06:06:02 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add offset check for _generic_header in populate_header > > LGTM @iklam @calvinccheung Thanks for review! - PR: ht

Re: RFR: 8273152: Refactor CDS FileMapHeader loading code [v8]

On Thu, 7 Oct 2021 20:30:00 GMT, Calvin Cheung wrote: > I just have one minor comment. It's up to you if you want to change it. Thanks for review --- I will leave as it is now. - PR: https://git.openjdk.java.net/jdk/pull/5768

Re: RFR: 8273152: Refactor CDS FileMapHeader loading code [v8]

On Wed, 6 Oct 2021 21:53:30 GMT, Yumin Qi wrote: >> Please review, >> Refactor fundamental CDS FileMapHeader code for reliable reading of basic >> info from shared archive. >> With the change, it makes it possible to read an archive generated by >> different version of hotspot. Also it is p

Re: RFR: 8274004: Change 'nonleaf' rank name [v2]

On Thu, 7 Oct 2021 15:59:42 GMT, Patricio Chilano Mateo wrote: >> Coleen Phillimore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix overlap error message printing and add a test. > > LGTM! > > Thanks, > Patricio Thanks for the rev

Re: RFR: 8274004: Change 'nonleaf' rank name [v2]

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

Re: RFR: 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent

On Sat, 25 Sep 2021 11:15:35 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method > directly. Marked as reviewed by cjplummer (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5697

Re: RFR: 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent

On Sat, 25 Sep 2021 11:15:35 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method > directly. Andrey, Nice simplification. It looks good to me. Thanks, Serguei - Marked as reviewed by sspitsyn (Reviewer). PR: https://git.ope

Re: RFR: 8274004: Change 'nonleaf' rank name [v2]

> 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 => safepoint. The second change is to add the enum class > Rank whi

Re: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules

On Thu, 9 Sep 2021 06:53:13 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. StringBuilder is a direct > replacement to StringBuffer which generally have better performance Marked as reviewed by sspitsyn (Reviewer). - PR: https://git.openjdk.java.net/jdk

RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend

This change fixes deadlocks described in the JBS-bug by: * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` * Notifying on `threadLock` in `threadControl_reset()` Also the actions in handleAppResumeBreakpoint() are moved/deferred until doPendingTasks() runs.

Extend jcmd to java application level

Hi team, The `jcmd` command can be used to call some built-in diagnostic commands in vm. Can we consider extending it to the java layer like perf data, so that Java developers can customize their diagnostic commands and then call them through `jcmd`? One application scenario I can think of for t

RFR: 8274903: Zero: Support AsyncGetCallTrace

This is a Zero infrastructure improvement that makes Zero VM work with AsyncGetCallTrace, and by extension, async-profiler. Zero is quite odd in stack management. The "real" stack actually contains the C++ Interpreter and the rest of VM code. The Java stack is reported through the usual "frame"

Re: RFR: 8274004: Change 'nonleaf' rank name

On Wed, 6 Oct 2021 23:27:17 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 => safepo

Re: RFR: 8274004: Change 'nonleaf' rank name

On Wed, 6 Oct 2021 23:27:17 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 => safepo

Integrated: 8273929: Remove GzipRandomAccess in heap dump test

On Fri, 17 Sep 2021 08:24:54 GMT, Lin Zang wrote: > The class `GzipRandomAccess` is used to parse heap dump file generated from > `jcmd`/`jmap` tools when testing. > It has the limitation that only gzip file which has "blocksize" header field > could be sucessfully parsed. > We think this class

Re: RFR: 8273929: Remove GzipRandomAccess in heap dump test

On Fri, 17 Sep 2021 08:24:54 GMT, Lin Zang wrote: > The class `GzipRandomAccess` is used to parse heap dump file generated from > `jcmd`/`jmap` tools when testing. > It has the limitation that only gzip file which has "blocksize" header field > could be sucessfully parsed. > We think this class

RFR: 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent

Collections.sort is just a wrapper, so it is better to use an instance method directly. - Commit messages: - 8272992: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent Changes: https://git.openjdk.java.net/jdk/pull/5697/files Webrev: https://webrevs.open

RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules

StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance - Commit messages: - [PATCH] Cleanup usages of StringBuffer in jdk tools modules Changes: https://git.openjdk.java.net/jdk/pull/5433/files Web

Integrated: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi

On Sat, 18 Sep 2021 21:35:41 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to > iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle > instead: it's less verbose, makes code easier to read

Integrated: 8274716: JDWP Spec: the description for the Dispose command confuses suspend with resume.

On Mon, 4 Oct 2021 13:44:44 GMT, Richard Reingruber wrote: > The following sentence in the JDWP Specification describing the Dispose > command confuses resume with suspend [1]: > > All threads suspended by the thread-level **resume** command or the VM-level > **resume** command are resumed

Re: RFR: 8274716: JDWP Spec: the description for the Dispose command confuses suspend with resume. [v2]

On Tue, 5 Oct 2021 07:38:28 GMT, Richard Reingruber wrote: >> The following sentence in the JDWP Specification describing the Dispose >> command confuses resume with suspend [1]: >> >> All threads suspended by the thread-level **resume** command or the >> VM-level >> **resume** command are