Re: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow [v3]

2024-01-27 Thread Chris Plummer
> I noticed that "clhsdb jstack" seemed to hang when I attached to process with > a somewhat large heap. It had taken over 10 minutes when I finally decided to > have a look at the SA process (using bin/jstack), which came up with the > following in the stack: > > > at > sun.jvm.hotspot.oops.

Re: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow [v2]

2024-01-27 Thread Andrey Turbanov
On Thu, 18 Jan 2024 16:19:38 GMT, Chris Plummer wrote: >> I noticed that "clhsdb jstack" seemed to hang when I attached to process >> with a somewhat large heap. It had taken over 10 minutes when I finally >> decided to have a look at the SA process (using bin/jstack), which came up >> with th

Re: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files [v4]

2024-01-27 Thread Coleen Phillimore
> This mechanically replaces NULL with nullptr in hpp/cpp native files in test > native code. This didn't attempt to change NULL in comments to say null > because nullptr is generally the right thing for the comment to say. It does > attempt to change NULL to "null" rather than "nullptr" in st

Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v11]

2024-01-27 Thread Suchismith Roy
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a f

Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v10]

2024-01-27 Thread Suchismith Roy
> J2SE agent does not start and throws error when it tries to find the shared > library ibm_16_am. > After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load > fails.It fails to identify the shared library ibm_16_am.a shared archive file > on AIX. > Hence we are providing a f

Re: RFR: 8324668: JDWP process management needs more efficient file descriptor handling [v2]

2024-01-27 Thread Jaikiran Pai
On Sat, 27 Jan 2024 13:06:59 GMT, Jaikiran Pai wrote: >> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 112: >> >>> 110: } >>> 111: >>> 112: closedir(dp); >> >> Should this be: >> >> `(void)close(fd);` >> >> and >> >> `(void)closedir(dp);` >> >> to show that we're ignoring

Re: RFR: 8324668: JDWP process management needs more efficient file descriptor handling [v2]

2024-01-27 Thread Jaikiran Pai
On Fri, 26 Jan 2024 17:33:39 GMT, Gerard Ziemski wrote: > Have you considered using `fcntl(d, F_SETFD, 1)` instead of the fancy > `closeDescriptors()`? > > I haven't tested it myself, but per the `man close` page: > > ``` > Most of the descriptors can be rearranged with dup2(2) or deleted with

Re: RFR: 8324668: JDWP process management needs more efficient file descriptor handling [v3]

2024-01-27 Thread Jaikiran Pai
> Can I please get a review of this change which proposes to address > https://bugs.openjdk.org/browse/JDK-8324668? > > This change proposes to fix the issue in jdwp where when launching a child > process (for the `launch=` option), it iterates over an extremely large > number of file descripto

Re: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files [v3]

2024-01-27 Thread Kevin Walls
On Fri, 26 Jan 2024 21:06:00 GMT, Coleen Phillimore wrote: >> This mechanically replaces NULL with nullptr in hpp/cpp native files in test >> native code. This didn't attempt to change NULL in comments to say null >> because nullptr is generally the right thing for the comment to say. It >>

Re: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files [v3]

2024-01-27 Thread Kevin Walls
On Fri, 26 Jan 2024 21:06:00 GMT, Coleen Phillimore wrote: >> This mechanically replaces NULL with nullptr in hpp/cpp native files in test >> native code. This didn't attempt to change NULL in comments to say null >> because nullptr is generally the right thing for the comment to say. It >>