Proposed changes to empty command handling in JDB
Chris Plummer
chris.plummer at oracle.com
Mon Aug 23 19:29:01 UTC 2021
It looks like we don't have anything similar in place already. I was
looking for an echo or verbose command to compare to, hoping it would
take an on/off parameter, but they don't exist. The following pairs are
the best examples I see:
stop/clear
enablegc/disablegc
watch/unwatch
trace/untrace
monitor/unmonitor
We also have "dbgtrace [flag]".
repeat/unrepeat doesn't quite work. repeat/nopeat is probably fine, but
maybe also "repeat on/off". You can also consider a command line option.
The only similar type option I currently see is "-dbgtrace [flags]". So
you could use "-repeat". Doing both a command and a command line option
is not necessarily required. Either one gets the job done, and you can
argue that if set on the command line, there would be no reason for the
user to turn it off once in jdb. On the other hand, if you forgot to set
it on the command line, you need to abort your session and relaunch to
get it enabled, so if only doing one, probably a command would be better.
Chris
On 8/23/21 11:41 AM, Jakob Cornell wrote:
> Hi Chris,
>
> Yeah, I think I agree with you, but I seem to recall a few people
> having the opposite opinion, so I've been a bit confused about how to
> proceed. However, given that we'll be keeping the empty command
> handling off by default I don't think it's possible for the change to
> disrupt anything. Unless anybody brings up any more concerns are we
> ready to start a CSR request for the change?
>
> Also, with regard to the feature flag, somebody mentioned implementing
> that as a new command pair (e.g. `repeat'/`norepeat') so that the
> default behavior can be controlled in a jdbrc file (and manually
> during a session), but there was never much discussion of this
> aspect. So I'm not sure whether we're looking at a pair of new
> commands or a command line flag or both, although both sounds most
> convenient to me. Can you advise on that? Once it's settled I can
> work on extending my existing patch.
>
> Jakob
More information about the serviceability-dev
mailing list