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: 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow [v2]

2024-01-24 Thread Chris Plummer
On Wed, 24 Jan 2024 10:15:52 GMT, Kevin Walls wrote: >> Chris Plummer has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - update clhsdb docs >> - update clhsdb docs > > test/hotspot/jtreg/serviceability/sa/ClhsdbJstackWithConcurrentLock.j

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

2024-01-24 Thread Kevin Walls
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: 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow [v2]

2024-01-24 Thread Kevin Walls
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: 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow [v2]

2024-01-22 Thread Chris Plummer
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: 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow [v2]

2024-01-18 Thread Chris Plummer
On Fri, 19 Jan 2024 05:40:02 GMT, David Holmes wrote: > I also wonder if we should be looking at a different way to track j.u.c lock > usage, as searching the full heap does not seem at all reasonable. Good question. It looks like bin/jstack does the same, but there is much less cost to doing

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

2024-01-18 Thread David Holmes
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: 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow [v2]

2024-01-18 Thread Chris Plummer
On Fri, 19 Jan 2024 02:59:19 GMT, David Holmes wrote: >> Chris Plummer has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - update clhsdb docs >> - update clhsdb docs > > This seems to be a change that will impact the end user of these too

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

2024-01-18 Thread David Holmes
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: 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow [v2]

2024-01-18 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.