RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow [v2]
Chris Plummer
cjplummer at openjdk.org
Fri Jan 19 05:10:25 UTC 2024
On Fri, 19 Jan 2024 02:59:19 GMT, David Holmes <dholmes at openjdk.org> 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 tools. Instead of disabling j.u.c.locks by default and proving an option to turn them on, you should provide an option to turn them off, and our tests can use that. What you proposed makes sense for an initial design of the tool, but not for a change after the fact.
@dholmes-ora I understand your point. There are pros and cons to both approaches, and I think that needs to be considered. One advantage of my approach is preventing users from accidentally stumbling into this is issue, and wondering why jstack won't complete. I think this is more likely than being confused by the change (expecting locks and not seeing them). Another advantage is consistency with bin/jstack and "jhsdb jstack" in that the locks are not included by default.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/17479#issuecomment-1899777777
More information about the serviceability-dev
mailing list