Protocol version of Attach API

[臧琳]

Dear Paul,
     That sounds reasonable to me.
     I suggest to try it (and I will) later if reduce arg_count_max to 3 works fine at present, so we can reduce the affect from 8215622 ASAP. Then I will consider it when refining the patch for adding more options (such as "incremental" for jmap histo , described in 8215623).
     what do you think?

BRs,
Lin
________________________________________
From: Hohensee, Paul <hohensee at amazon.com>
Sent: Thursday, February 28, 2019 7:48:06 PM
To: 臧琳; David Holmes; Yasumasa Suenaga
Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net
Subject: Re: Protocol version of Attach API

I'd like to propose an alternative approach, namely, we could add another argument parsing feature on top of the old functionality intact and leave the latter intact. We currently have just a single constant AttachOperation::arg_count_max, which the patch changed from 3 to 4. We could leave it at 3 and add another constant, call it extra_arg_count, and set extra_arg_count to 1 for now. The required number of attachListener args stays at 3, and we add code that checks for up to extra_arg_count arguments. As part of the new code, add a sentinel argument value (all 1s?) to signal end of extra arguments, rather than overloading the null string, since a null string is a valid argument. Opinion(s)?

Thanks,

Paul