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

2024-01-31 Thread Alex Menkov
On Wed, 31 Jan 2024 04:34:52 GMT, Chris Plummer wrote: >> test/hotspot/jtreg/serviceability/sa/ClhsdbJstackWithConcurrentLock.java >> line 65: >> >>> 63: for (String line : lines) { >>> 64: if (line.contains(key)) { >>> 65: String[] words =

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

2024-01-30 Thread Chris Plummer
On Wed, 31 Jan 2024 03:50:29 GMT, Alex Menkov wrote: >> Chris Plummer has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix spacing > > test/hotspot/jtreg/serviceability/sa/ClhsdbJstackWithConcurrentLock.java line > 65: > >> 63:

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

2024-01-30 Thread Alex Menkov
On Sun, 28 Jan 2024 01:20:53 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

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

2024-01-30 Thread Chris Plummer
On Sun, 28 Jan 2024 01:20:53 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

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 >