Re: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code [v3]

2022-06-12 Thread Ioi Lam
On Wed, 8 Jun 2022 12:09:27 GMT, Severin Gehwolf wrote: >> Please review this cleanup change in the cgroup subsystem which used to use >> hard-coded stack allocated >> buffers for concatenating strings in memory. We can use `stringStream` >> instead which doesn't have the issue >> of

Re: RFR: 8288222: ProblemList serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java

2022-06-10 Thread Ioi Lam
On Fri, 10 Jun 2022 15:21:34 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList > serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java. Marked as reviewed by iklam (Reviewer). - PR: https://git.openjdk.org/jdk19/pull/4

Re: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code [v2]

2022-06-08 Thread Ioi Lam
On Tue, 7 Jun 2022 12:42:26 GMT, Severin Gehwolf wrote: >> Please review this cleanup change in the cgroup subsystem which used to use >> hard-coded stack allocated >> buffers for concatenating strings in memory. We can use `stringStream` >> instead which doesn't have the issue >> of

Re: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v3]

2022-06-08 Thread Ioi Lam
On Tue, 7 Jun 2022 10:07:08 GMT, Yi Yang wrote: >> It seems that calculation of >> MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. >> >> Currently, >> `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)` >> >> ==> CodeHeap

Re: RFR: 8287663 Add a regression test for JDK-8287073

2022-06-06 Thread Ioi Lam
On Mon, 6 Jun 2022 23:07:06 GMT, Ioi Lam wrote: > We should try to consolidate these test cases to improve maintainability. I filed [JDK-8287185](https://bugs.openjdk.org/browse/JDK-8287185) - PR: https://git.openjdk.java.net/jdk/pull/8993

Re: RFR: 8287663 Add a regression test for JDK-8287073

2022-06-06 Thread Ioi Lam
On Thu, 2 Jun 2022 14:32:28 GMT, Severin Gehwolf wrote: > This adds a regression test for a recent fix (JDK-8287073). I've restructured > the linux specific JDK code to call a separate static function to enable this > test. It'll help future tests too. > > Testing: > - [x] Container tests

Re: RFR: 8287663 Add a regression test for JDK-8287073

2022-06-06 Thread Ioi Lam
On Thu, 2 Jun 2022 14:32:28 GMT, Severin Gehwolf wrote: > This adds a regression test for a recent fix (JDK-8287073). I've restructured > the linux specific JDK code to call a separate static function to enable this > test. It'll help future tests too. > > Testing: > - [x] Container tests

Re: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong

2022-05-27 Thread Ioi Lam
On Fri, 27 May 2022 07:22:11 GMT, Thomas Stuefe wrote: > > If we remove `CompressedClassSpace`, we can only > > `getMemoryPool("Metaspace")`. Although metaspace is not baked in the > > specification, IMHO it's easier for developers to understand what is > > `metaspace` compared to the

Re: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong

2022-05-27 Thread Ioi Lam
On Fri, 27 May 2022 05:31:24 GMT, David Holmes wrote: > The basic problem is that we have two non-heap pools: > > * `MetaspacePool` > > * consists of `ClassType` and `NonClassType` parts > * `CompressedKlassSpacePool` > > but the `CompressedKlassSpacePool` is actually the "ClassType" part

Re: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong

2022-05-25 Thread Ioi Lam
On Mon, 23 May 2022 07:28:41 GMT, Yi Yang wrote: > It seems that calculation of > MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. > > Currently, > `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)` > > ==> CodeHeap

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3]

2022-05-19 Thread Ioi Lam
On Thu, 19 May 2022 19:59:18 GMT, Ioi Lam wrote: >>> What happens if cgroup_path is "/foo/bar" and _root is "/fo"? >> >> With a mount path of `/bar` this ends up being `/bar/o/bar`. Pretty strange, >> but then again it's a bit of a contrived examp

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3]

2022-05-19 Thread Ioi Lam
On Thu, 19 May 2022 09:06:18 GMT, Severin Gehwolf wrote: >> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 63: >> >>> 61: } else { >>> 62: char *p = strstr(cgroup_path, _root); >>> 63: if (p != NULL && p == cgroup_path) { >> >> What happens if cgroup_path is

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3]

2022-05-19 Thread Ioi Lam
On Wed, 18 May 2022 18:14:52 GMT, Severin Gehwolf wrote: >> Please review this change to the cgroup v1 subsystem which makes it more >> resilient on some of the stranger systems. Unfortunately, I wasn't able to >> re-create a similar system as the reporter. The idea of using the longest >>

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2]

2022-05-17 Thread Ioi Lam
On Thu, 12 May 2022 18:09:40 GMT, Severin Gehwolf wrote: >> Please review this change to the cgroup v1 subsystem which makes it more >> resilient on some of the stranger systems. Unfortunately, I wasn't able to >> re-create a similar system as the reporter. The idea of using the longest >>

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2]

2022-05-16 Thread Ioi Lam
On Thu, 12 May 2022 18:09:40 GMT, Severin Gehwolf wrote: >> Please review this change to the cgroup v1 subsystem which makes it more >> resilient on some of the stranger systems. Unfortunately, I wasn't able to >> re-create a similar system as the reporter. The idea of using the longest >>

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems

2022-05-12 Thread Ioi Lam
On Tue, 10 May 2022 12:29:10 GMT, Severin Gehwolf wrote: > Please review this change to the cgroup v1 subsystem which makes it more > resilient on some of the stranger systems. Unfortunately, I wasn't able to > re-create a similar system as the reporter. The idea of using the longest >

Integrated: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach()

2022-05-11 Thread Ioi Lam
On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam wrote: > The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never > supported the value `"rw"` since the source code was imported to the openjdk > repo more than 15 years ago. In fact HotSpot throws > `IllegalA

Re: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach()

2022-05-11 Thread Ioi Lam
On Tue, 10 May 2022 20:03:45 GMT, Alan Bateman wrote: >> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never >> supported the value `"rw"` since the source code was imported to the openjdk >> repo more than 15 years ago. In fact HotSpot throws >> `IllegalArgumentException`

Re: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach()

2022-05-10 Thread Ioi Lam
On Tue, 10 May 2022 20:03:45 GMT, Alan Bateman wrote: > I skimmed through the changes and I think they look okay. In the distant past > there were tools outside of the JDK that used the jvmstat API directly. It's > possible that VisualVM still does but it would only compile/run if >

Re: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() [v2]

2022-05-10 Thread Ioi Lam
On Tue, 10 May 2022 19:59:41 GMT, Alan Bateman wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> review comments > > src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/pro

Re: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() [v2]

2022-05-10 Thread Ioi Lam
On Tue, 10 May 2022 21:43:44 GMT, Claes Redestad wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> review comments > > src/hotspot/os/windows/perfMemory_windows.cpp line 1781: > &

Re: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() [v2]

2022-05-10 Thread Ioi Lam
t; It's unlikely such a mode will be required for future enhancements. Support > for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` > is the only supported mode. > > I also cleaned up related code in the JDK and HotSpot. > &

RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach()

2022-05-09 Thread Ioi Lam
The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified. It's unlikely such a mode will be

Re: RFR: 8284616: Implement workaround for CODETOOLS-7901986 in serviceability/jvmti/RedefineClasses

2022-04-11 Thread Ioi Lam
On Mon, 11 Apr 2022 07:52:34 GMT, Alan Bateman wrote: > > @AlanBateman adding the explicit compile commands to add `--enable-preview` > > is exactly what causes the problem. By compiling that individual file first > > it also compiled some testlib dependencies but puts the classes in a > >

Re: RFR: 8284330: jcmd may not be able to find processes in the container [v3]

2022-04-08 Thread Ioi Lam
On Fri, 8 Apr 2022 08:34:24 GMT, Yasumasa Suenaga wrote: >> jcmd uses >> src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java >> to scan temporary directories to find out processes in the container. It >> checks inode to ensure the temp directory is not conflicted.

Re: RFR: 8284330: jcmd may not be able to find processes in the container [v2]

2022-04-07 Thread Ioi Lam
On Wed, 6 Apr 2022 12:44:35 GMT, Yasumasa Suenaga wrote: >> jcmd uses >> src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java >> to scan temporary directories to find out processes in the container. It >> checks inode to ensure the temp directory is not conflicted.

Integrated: 8207025: JvmtiEnv::SetSystemProperty() does not handle OOM

2022-03-29 Thread Ioi Lam
On Mon, 28 Mar 2022 04:14:32 GMT, Ioi Lam wrote: > `JvmtiEnv::SetSystemProperty` eventually calls `PathString::set_value` in > arguments.cpp, which aborts the VM when it fails to allocate a string copy of > the property value. > > > bool PathString::set_value

Re: RFR: 8207025: JvmtiEnv::SetSystemProperty() does not handle OOM

2022-03-29 Thread Ioi Lam
On Mon, 28 Mar 2022 06:19:39 GMT, David Holmes wrote: >> `JvmtiEnv::SetSystemProperty` eventually calls `PathString::set_value` in >> arguments.cpp, which aborts the VM when it fails to allocate a string copy >> of the property value. >> >> >> bool PathString::set_value(const char *value) {

Re: RFR: 8207025: JvmtiEnv::SetSystemProperty() does not handle OOM [v4]

2022-03-29 Thread Ioi Lam
ystemProperty` can return > `JVMTI_ERROR_OUT_OF_MEMORY` in case of OOM. See > https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#SetSystemProperty Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrela

Re: RFR: 8207025: JvmtiEnv::SetSystemProperty() does not handle OOM [v3]

2022-03-28 Thread Ioi Lam
On Tue, 29 Mar 2022 04:58:32 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> @dholmes-ora comments: simplify the changes > > src/hotspot/share/runtime/arguments.h

Re: RFR: 8207025: JvmtiEnv::SetSystemProperty() does not handle OOM [v3]

2022-03-28 Thread Ioi Lam
ystemProperty` can return > `JVMTI_ERROR_OUT_OF_MEMORY` in case of OOM. See > https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#SetSystemProperty Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @dholmes-ora comments:

Re: RFR: 8207025: JvmtiEnv::SetSystemProperty() does not handle OOM

2022-03-28 Thread Ioi Lam
On Mon, 28 Mar 2022 06:19:39 GMT, David Holmes wrote: >> `JvmtiEnv::SetSystemProperty` eventually calls `PathString::set_value` in >> arguments.cpp, which aborts the VM when it fails to allocate a string copy >> of the property value. >> >> >> bool PathString::set_value(const char *value) {

Re: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v10]

2022-03-05 Thread Ioi Lam
On Fri, 4 Mar 2022 09:05:36 GMT, Yi Yang wrote: >> Add VM.classes to print details of all classes, output looks like: >> >> 1. jcmd VM.classes >> >> KlassAddr Size State Flags LoaderName ClassName >> 0x000800c0b400 62 inited W bootstrap >> java.lang.invoke.LambdaForm$MH/0x000800c0b400

Re: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v6]

2022-03-04 Thread Ioi Lam
On Fri, 4 Mar 2022 07:24:51 GMT, Yi Yang wrote: >> You should change it to `%4d`. Otherwise, when the numbers are changed in >> the future (e.g., to 3 or 4 digits) they will be misaligned: >> >> >> KlassAddr Size State FlagsClassName >> 0x000800df8400 62

Re: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v6]

2022-03-03 Thread Ioi Lam
On Fri, 4 Mar 2022 02:47:28 GMT, Yi Yang wrote: >> This issue seem still outstanding. > > Current: > > $./jcmd 83908 VM.classes|head -10 > 83908: > KlassAddr Size State FlagsClassName > 0x000800df8400 62fully_initialized W >

Integrated: 8280543: Update the "java" and "jcmd" tool specification for CDS

2022-01-31 Thread Ioi Lam
On Fri, 28 Jan 2022 01:53:09 GMT, Ioi Lam wrote: > The discussion of CDS in the man pages need to be cleaned up and updated to > match the latest functionalities and intended usage. > > For java.md: > > - Reorganized the flow of the doc: Overview -> How to

Re: RFR: 8280543: Update the "java" and "jcmd" tool specification for CDS [v2]

2022-01-31 Thread Ioi Lam
On Mon, 31 Jan 2022 14:56:27 GMT, Harold Seigel wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fixed copyright year for jcmd.1 > > LGTM. The copyright in jcmd.1 needs updating. >

Re: RFR: 8280543: Update the "java" and "jcmd" tool specification for CDS [v2]

2022-01-31 Thread Ioi Lam
> - Added some more details about default file name and output directory. > > For ease of reviewing, please see the pre-rendered HTML pages: > > http://cr.openjdk.java.net/~iklam/jdk19/8280543-update-java-and-jcmd-manpage-for-cds2/specs/man/ Ioi Lam has updated the pull request in

RFR: 8280543: Update the "java" and "jcmd" tool specification for CDS

2022-01-27 Thread Ioi Lam
The discussion of CDS in the man pages need to be cleaned up and updated to match the latest functionalities and intended usage. For java.md: - Reorganized the flow of the doc: Overview -> How to use -> How to create -> Restrictions and notes. I think this will be easier to read. - Added

Re: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v6]

2022-01-27 Thread Ioi Lam
On Thu, 27 Jan 2022 09:17:09 GMT, Yi Yang wrote: >> Add VM.classes to print details of all classes, output looks like: >> >> 1. jcmd VM.classes >> >> KlassAddr Size State Flags LoaderName ClassName >> 0x000800c0b400 62 inited W bootstrap >>

Re: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp where possible [v3]

2022-01-24 Thread Ioi Lam
On Mon, 24 Jan 2022 07:41:44 GMT, Thomas Stuefe wrote: >> JDK-8249944 moved AllStatic to its own header. We should use that one >> instead of allocation.hpp where possible to reduce header dependencies. >> >> This patch: >> - replaces includes of allocation.hpp with allstatic.hpp where

Re: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp where possible [v2]

2022-01-23 Thread Ioi Lam
On Mon, 24 Jan 2022 05:44:50 GMT, Thomas Stuefe wrote: >> JDK-8249944 moved AllStatic to its own header. We should use that one >> instead of allocation.hpp where possible to reduce header dependencies. >> >> This patch: >> - replaces includes of allocation.hpp with allstatic.hpp where

Re: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp where possible

2022-01-23 Thread Ioi Lam
On Mon, 24 Jan 2022 04:18:48 GMT, Ioi Lam wrote: > I am running a mach5 job for tier1 + builds-tier5. That should cover most of > the builds done by the Oracle CI. I'll post the results when they are ready. Unfortunately I am seeing failures on macos and windows: macos: src/hotspot/os/

Re: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp where possible

2022-01-23 Thread Ioi Lam
On Sat, 22 Jan 2022 13:33:24 GMT, Thomas Stuefe wrote: > JDK-8249944 moved AllStatic to its own header. We should use that one instead > of allocation.hpp where possible to reduce header dependencies. > > This patch: > - replaces includes of allocation.hpp with allstatic.hpp where appropiate >

Re: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp where possible

2022-01-23 Thread Ioi Lam
On Sat, 22 Jan 2022 13:33:24 GMT, Thomas Stuefe wrote: > JDK-8249944 moved AllStatic to its own header. We should use that one instead > of allocation.hpp where possible to reduce header dependencies. > > This patch: > - replaces includes of allocation.hpp with allstatic.hpp where appropiate >

Re: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v5]

2022-01-23 Thread Ioi Lam
On Thu, 20 Jan 2022 09:47:31 GMT, Yi Yang wrote: >> Add VM.classes to print details of all classes, output looks like: >> >> 1. jcmd VM.classes >> >> KlassAddr Size State Flags LoaderName ClassName >> 0x000800c0b400 62 inited W bootstrap >>

Re: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v2]

2022-01-19 Thread Ioi Lam
On Wed, 19 Jan 2022 08:39:34 GMT, Xin Liu wrote: > > How about this: > > ``` > > jcmd VM.classes -verbose classname classname ... > > ``` > > > > -verbose is optional > > more than one classnames can be specified. > > if no classnames are specified, all classes are printed > > If the class

Re: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v2]

2022-01-18 Thread Ioi Lam
On Wed, 19 Jan 2022 02:50:16 GMT, Chris Plummer wrote: > > > It seems it would be useful to support the verbose output with just a > > > single class that is specified, although that would suggest that the dcmd > > > name should then be something other than `VM.classes`. > > > > > > This is

Re: RFR: 8277481: Obsolete seldom used CDS flags

2021-12-10 Thread Ioi Lam
On Fri, 10 Dec 2021 15:01:29 GMT, Harold Seigel wrote: > Please review this change to obsolete deprecated CDS options UseSharedSpaces, > RequireSharedSpaces, DynamicDumpSharedSpaces, and DumpSharedSpaces. The > change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows > and

Re: RFR: JDK-8276983: Small fixes to DumpAllocStat::print_stats

2021-11-14 Thread Ioi Lam
On Thu, 11 Nov 2021 06:15:32 GMT, Thomas Stuefe wrote: > When looking at CDS code in the context of Lilliput, I had to spend some time > in DumpAllocStat::print(). I noticed two small things which can be fixed > independently: > > - the divide-by-zero check at lines 45ff is not needed, since

Re: RFR: 8275259: Add support for Java level DCmd

2021-11-09 Thread Ioi Lam
On 11/9/21 2:07 PM, Chris Plummer wrote: On 10/14/21 12:38 AM, David Holmes wrote: On 14/10/2021 5:14 pm, Denghui Dong wrote: On Thu, 14 Oct 2021 06:43:20 GMT, David Holmes wrote: I'm not sure exactly where this API would need to go. IIUC jcmd doesn't exist at the Java level it is just

Re: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager [v2]

2021-11-06 Thread Ioi Lam
On Sat, 6 Nov 2021 12:16:10 GMT, Serguei Spitsyn wrote: > Hi Ioi, > Sorry for being late here. > Just to complete this... > Thank you for your answers! I'm okay with them. Thanks Serguei! - PR: https://git.openjdk.java.net/jdk/pull/5923

Integrated: 8275185: Remove dead code and clean up jvmstat LocalVmManager

2021-11-04 Thread Ioi Lam
On Wed, 13 Oct 2021 04:17:25 GMT, Ioi Lam wrote: > LocalVmManager and PerfDataFile have APIs that are supposed to look for VMs > owned by a specific user. No one uses these APIs, and they don't work anyway. > > The current code is very confusing to look at. Since we're likely to ch

Re: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager [v2]

2021-11-04 Thread Ioi Lam
On Thu, 4 Nov 2021 03:44:43 GMT, Chris Plummer wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes the unrelated changes brought >> in by the merge/rebase. The pull request contains three

Re: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager [v2]

2021-11-03 Thread Ioi Lam
On Tue, 19 Oct 2021 22:02:58 GMT, Chris Plummer wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes the unrelated changes brought >> in by the merge/rebase. The pull request contains three

Re: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager

2021-11-03 Thread Ioi Lam
On Tue, 26 Oct 2021 07:48:05 GMT, Kevin Walls wrote: > Nice cleanup - although was it not better for PerfDataFile.java to "own" the > definitions of what a perfdata filename looks like? That might be what Chris > was hinting at. There isn't really that _much_ flipping between two files. 8-)

Re: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager

2021-11-03 Thread Ioi Lam
On Wed, 20 Oct 2021 02:23:25 GMT, Serguei Spitsyn wrote: > Hi Ioi, It looks good to me except the line 105 commented by Chris. I wonder > how should this be tested to make sure there are no regressions. Do we really > care about pre 1.4.2 formats? If so, what is the way to test it? We have a

Re: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager [v2]

2021-11-03 Thread Ioi Lam
ith Oracle CI: tiers1-4, plus hs-tier5-rt (which tests containers > and have extensive use of the management tools). Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

Re: RFR: 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" [v2]

2021-11-02 Thread Ioi Lam
On Tue, 2 Nov 2021 01:07:30 GMT, Jakob Cornell wrote: >> This will fix a few issues with the tests added in #5290: >> >> - [x] intermittent failures >> - [x] tests should use `failure` method to report problems rather than >> throwing `AssertionError` > > Jakob Cornell has updated the pull

Re: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v8]

2021-10-26 Thread Ioi Lam
On Mon, 25 Oct 2021 22:21:54 GMT, Jakob Cornell wrote: >> This has been under discussion on and off for the past month or so on >> serviceability-dev, and I think a CSR request is required, so this may be a >> work in progress. >> >> Notes on the patch: >> >> - The `list` command previously

Re: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5]

2021-10-19 Thread Ioi Lam
On Tue, 19 Oct 2021 21:26:11 GMT, Chris Plummer wrote: > > Hi Jacob, this is not your fault, but the "zz help text" in the Chinese and > > Japanese versions are in a single huge line. This makes it impossible to > > see what you have changed in the GitHub diffs, and impossible to tell > >

Re: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager

2021-10-19 Thread Ioi Lam
On Tue, 19 Oct 2021 21:17:57 GMT, Chris Plummer wrote: >> LocalVmManager and PerfDataFile have APIs that are supposed to look for VMs >> owned by a specific user. No one uses these APIs, and they don't work anyway. >> >> The current code is very confusing to look at. Since we're likely to

Re: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5]

2021-10-19 Thread Ioi Lam
On Thu, 23 Sep 2021 15:24:47 GMT, Jakob Cornell wrote: >> This has been under discussion on and off for the past month or so on >> serviceability-dev, and I think a CSR request is required, so this may be a >> work in progress. >> >> Notes on the patch: >> >> - The `list` command previously

RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager

2021-10-12 Thread Ioi Lam
LocalVmManager and PerfDataFile have APIs that are supposed to look for VMs owned by a specific user. No one uses these APIs, and they don't work anyway. The current code is very confusing to look at. Since we're likely to change code in this area for further container support, it's better to

Re: Extend jcmd to java application level

2021-10-08 Thread Ioi Lam
On 10/7/21 6:25 PM, David Holmes wrote: 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 

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

2021-10-07 Thread Ioi Lam
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

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

2021-10-06 Thread Ioi Lam
On Wed, 6 Oct 2021 16:44:25 GMT, Yumin Qi wrote: >> src/hotspot/share/cds/filemap.cpp line 1205: >> >>> 1203: } >>> 1204: >>> 1205: _header = (FileMapHeader*)os::malloc(gen_header->_header_size, >>> mtInternal); >> >> There's no need to allocate and read the header again. It's already in

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

2021-10-06 Thread Ioi Lam
On Wed, 6 Oct 2021 17:01:31 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

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

2021-10-05 Thread Ioi Lam
On Tue, 5 Oct 2021 22:32: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

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

2021-10-04 Thread Ioi Lam
On Mon, 4 Oct 2021 17:50:27 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

Re: RFR: 8273915: Create 'nosafepoint' rank [v3]

2021-09-20 Thread Ioi Lam
On Mon, 20 Sep 2021 20:16:03 GMT, Coleen Phillimore wrote: >> Partition safepoint checking and nonchecking lock ranks. The nonchecking >> locks are always lower ranked than the safepoint checking locks because they >> cannot block. >> >> This moves some leaf locks to 'nosafepoint' rank and

Re: RFR: 8273915: Create 'nosafepoint' rank [v2]

2021-09-20 Thread Ioi Lam
On Mon, 20 Sep 2021 13:35:29 GMT, Coleen Phillimore wrote: >> Partition safepoint checking and nonchecking lock ranks. The nonchecking >> locks are always lower ranked than the safepoint checking locks because they >> cannot block. >> >> This moves some leaf locks to 'nosafepoint' rank and

Re: RFR: 8269537: memset() is called after operator new

2021-09-07 Thread Ioi Lam
On Tue, 7 Sep 2021 12:25:54 GMT, Leo Korinth wrote: > The basic problem is that we are relying on undefined behaviour, as > documented in the code: > > // This whole business of passing information from ResourceObj::operator new > // to the ResourceObj constructor via fields in the "object" is

Re: RFR: 8269962: SA has unused Hashtable, Dictionary classes

2021-07-07 Thread Ioi Lam
On Wed, 7 Jul 2021 13:27:49 GMT, Coleen Phillimore wrote: > See bug for more details. This code is unused and is soon going to be not in > hotspot. > I left in logBytesPerWord() from my previous change because it might be > useful in the SA. I could remove it if opinion warrants. > Ran

Re: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments [v3]

2021-05-13 Thread Ioi Lam
On Thu, 13 May 2021 04:59:11 GMT, David Holmes wrote: >> Our code is littered with API's that take, or manifest, a Thread* and then >> assert/guarantee that it must be a JavaThread, rather than >> taking/manifesting a JavaThread in the first place. The main reason for this >> is that the

Re: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]

2021-05-11 Thread Ioi Lam
On Tue, 11 May 2021 14:13:49 GMT, Harold Seigel wrote: >> Please review this large change to remove Unsafe::defineAnonymousClass(). >> The change removes dAC relevant code and changes a lot of tests. Many of >> the changed tests need renaming. I hope to do this in a follow up RFE. >> Some

Re: RFR: 8266497: Remove unnecessary EMCP liveness indication

2021-05-04 Thread Ioi Lam
On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore wrote: > Marking running_emcp for Method* is unnecessary. We can set/clear > breakpoints in all old emcp methods because they're not deallocated until > none are running. See longer explanation in the CR. > > Tested with tier1-6, tiers 7,8

Re: RFR: 8259070: Add jcmd option to dump CDS [v11]

2021-04-13 Thread Ioi Lam
On Tue, 13 Apr 2021 23:04:24 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Added jcmd option for dumping CDS archive during application runtime. >> Before this change, user has to dump shared archive in two steps: first run >> application with >> `java -XX:DumpLoadedClassList= `

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

2021-04-10 Thread Ioi Lam
On Fri, 9 Apr 2021 16:54:51 GMT, Ioi Lam wrote: >> Vladimir Kozlov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > LGTM. Just a small nit. > @iklam

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

2021-04-09 Thread Ioi Lam
On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related >> to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module — the `jaotc` tool >> - `src/hotspot/share/aot` — loads AoT compiled code into VM for

Integrated: 8264285: Clean the modification of ccstr JVM flags

2021-04-01 Thread Ioi Lam
On Mon, 29 Mar 2021 21:35:52 GMT, Ioi Lam wrote: > There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags > of the ccstr type (i.e., strings). > > - One version requires the caller to free the old value, but some callers > don't do that (wri

Re: RFR: 8264285: Clean the modification of ccstr JVM flags [v2]

2021-04-01 Thread Ioi Lam
On Thu, 1 Apr 2021 00:25:59 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> relax flag attributions (ala JDK-7123237) > > Marked as reviewed by coleenp (Reviewer).

Re: RFR: 8264285: Clean the modification of ccstr JVM flags [v4]

2021-04-01 Thread Ioi Lam
es. The old value should be freed automatically, > because typically the caller isn't interested in the old value. > > Note that the FLAG_SET_XXX macros do not return the old value. Requiring the > caller of FLAG_SET_XXX to free the old value would be tedious and error prone. Ioi Lam has up

Re: RFR: 8264150: CDS dumping code calls TRAPS functions in VM thread

2021-04-01 Thread Ioi Lam
On Tue, 30 Mar 2021 22:25:06 GMT, Coleen Phillimore wrote: > This change initializes the vtables/itables without checking constraints. > After initializing but before the class is visible in the SystemDictionary, > constraints are checked in a separate loop. > > Tested with tier1-6 which

Re: RFR: 8264285: Clean the modification of ccstr JVM flags [v2]

2021-04-01 Thread Ioi Lam
On 3/31/21 10:47 PM, David Holmes wrote: On 1/04/2021 3:29 pm, Ioi Lam wrote: On 3/31/21 10:22 PM, David Holmes wrote: On 1/04/2021 5:05 am, Ioi Lam wrote: On Wed, 31 Mar 2021 12:58:50 GMT, Coleen Phillimore wrote: 36: // have any MANAGEABLE flags of the ccstr type, but we really

Re: RFR: 8264285: Clean the modification of ccstr JVM flags [v3]

2021-04-01 Thread Ioi Lam
es. The old value should be freed automatically, > because typically the caller isn't interested in the old value. > > Note that the FLAG_SET_XXX macros do not return the old value. Requiring the > caller of FLAG_SET_XXX to free the old value would be tedious and error prone. Ioi Lam has up

Re: RFR: 8264285: Clean the modification of ccstr JVM flags [v2]

2021-03-31 Thread Ioi Lam
On 3/31/21 10:22 PM, David Holmes wrote: On 1/04/2021 5:05 am, Ioi Lam wrote: On Wed, 31 Mar 2021 12:58:50 GMT, Coleen Phillimore wrote: 36: // have any MANAGEABLE flags of the ccstr type, but we really need to 37: // make sure the implementation is correct (in terms of memory

Re: RFR: 8259070: Add jcmd option to dump CDS [v8]

2021-03-31 Thread Ioi Lam
On Wed, 31 Mar 2021 20:58:46 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Added jcmd option for dumping CDS archive during application runtime. >> Before this change, user has to dump shared archive in two steps: first run >> application with >> `java -XX:DumpLoadedClassList= `

Re: RFR: 8264285: Clean the modification of ccstr JVM flags [v2]

2021-03-31 Thread Ioi Lam
On Thu, 1 Apr 2021 00:25:53 GMT, Coleen Phillimore wrote: >> I had to use a `product` flag due to the following code, which should have >> been removed as part of >> [JDK-8243208](https://bugs.openjdk.java.net/browse/JDK-8243208), but I was >> afraid to do so because I didn't have a test

Re: RFR: 8259070: Add jcmd option to dump CDS [v8]

2021-03-31 Thread Ioi Lam
On Wed, 31 Mar 2021 20:58:46 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Added jcmd option for dumping CDS archive during application runtime. >> Before this change, user has to dump shared archive in two steps: first run >> application with >> `java -XX:DumpLoadedClassList= `

Re: RFR: 8264285: Clean the modification of ccstr JVM flags [v2]

2021-03-31 Thread Ioi Lam
On Tue, 30 Mar 2021 03:44:26 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> relax flag attributions (ala JDK-7123237) > > src/hotspot/share/services/writeableFlags.cpp

Re: RFR: 8264285: Clean the modification of ccstr JVM flags [v2]

2021-03-31 Thread Ioi Lam
On Wed, 31 Mar 2021 12:58:50 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> relax flag attributions (ala JDK-7123237) > > src/hotspot/share/runtime/flags/debug

Re: RFR: 8264285: Clean the modification of ccstr JVM flags [v2]

2021-03-31 Thread Ioi Lam
es. The old value should be freed automatically, > because typically the caller isn't interested in the old value. > > Note that the FLAG_SET_XXX macros do not return the old value. Requiring the > caller of FLAG_SET_XXX to free the old value would be tedious and error prone. Ioi Lam has up

Re: RFR: 8259070: Add jcmd option to dump CDS [v7]

2021-03-30 Thread Ioi Lam
On Tue, 30 Mar 2021 03:48:08 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Added jcmd option for dumping CDS archive during application runtime. >> Before this change, user has to dump shared archive in two steps: first run >> application with >> `java -XX:DumpLoadedClassList= `

RFR: 8264285: Clean the modification of ccstr JVM flags

2021-03-29 Thread Ioi Lam
There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings). - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp). - The other version frees the old value on behalf of the caller.

Re: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v5]

2021-03-23 Thread Ioi Lam
On Wed, 24 Mar 2021 02:10:53 GMT, Coleen Phillimore wrote: >> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in >> ConstantPool merging functions. >> Tested with vmTestbase/nsk/jvmti and tier1 (in progress). > > Coleen Phillimore has updated the pull request

Re: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v4]

2021-03-23 Thread Ioi Lam
On Tue, 23 Mar 2021 16:08:59 GMT, Coleen Phillimore wrote: >> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in >> ConstantPool merging functions. >> Tested with vmTestbase/nsk/jvmti and tier1 (in progress). > > Coleen Phillimore has updated the pull request

Re: RFR: 8264051: Remove unused TRAPS parameters from runtime functions

2021-03-23 Thread Ioi Lam
On Tue, 23 Mar 2021 16:40:44 GMT, Coleen Phillimore wrote: > This change removes the TRAPS parameter from compute_modifier_flags(), > lookup_instance_method_in_klasses and nest_host_error. > > There's a progressive effort to remove cases where the last parameter of a > function is THREAD, and

Re: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v2]

2021-03-22 Thread Ioi Lam
On Tue, 23 Mar 2021 01:22:56 GMT, Coleen Phillimore wrote: >> Removed the TRAPS in function declarations in jvmtiRedefineClasses and in >> ConstantPool merging functions. >> Tested with vmTestbase/nsk/jvmti and tier1 (in progress). > > Coleen Phillimore has updated the pull request

Re: RFR: 8264004: Don't use TRAPS if no exceptions are thrown [v2]

2021-03-22 Thread Ioi Lam
On Tue, 23 Mar 2021 04:59:10 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> missed THREAD that should be CHECK_false argument. > > src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 484:

  1   2   3   >