RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add implememtation for AIX

[Stuart Marks]

Hi Roger, Volker,

Glad to see you guys are receptive to this and that it can move forward. Let me 
know if you'd like me to help out, for example with reviews or something.

s'marks

On 7/31/15 9:55 AM, Roger Riggs wrote:
> Hi Volker,
>
> I agree that adding an Info.commandline() method would be a good way
> to make the command line available and be able to describe that it is
> OS dependent and may be truncated.
> And having it assemble the command and arguments when they are available makes
> sense.
> As an API addition it will need a clear spec and I can run it through CCC so it
> gets
> another review and compatibility tests.
>
> Thanks, Roger
>
>
>
>
> On 7/31/2015 5:03 AM, Volker Simonis wrote:
>> On Fri, Jul 31, 2015 at 2:51 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
>>>
>>> On 7/29/15 11:36 AM, Volker Simonis wrote:
>>>>> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
>>>>> truncated or incomplete
>>>>> values for the executable or arguments.
>>>>> Can anyone be a tie-breaker  (with a good rational and suggestion for how
>>>>> an
>>>>> application can use the data).
>>>>
>>>> As I wrote, I agree to hear other opinions here.
>>>>
>>>> All I want to say that this truncated data is actually what 'ps' is
>>>> reporting on Solaris since decades and people seem to be happy with
>>>> it. As use case I can imagine logging or monitoring (something like
>>>> 'top' in Java) where this data will be just good enough.
>>>>
>>>> We could specially mark possibly incomplete data by extending the Info
>>>> object with functions like commandIsExact() or argumentsIsPrecise().
>>>> But notice that we can not statically preset these values per
>>>> platform. For example on Solaris, the 'command()' would return a
>>>> precise value for processes with the same uid like the VM but only
>>>> inaccurate values for all other processes. The "arguments()" would be
>>>> always inaccurate on Solaris/AIX.
>>>
>>> It seems like there are cases where either exact or only approximate
>>> information is available. And as you observed, you might get one or the
>>> other on the same platform, depending on the UID. It also might depend on
>>> process state; I believe that some information becomes inaccessible when the
>>> process enters the zombie state.
>>>
>>> I don't think we should simply ignore one case or the other, but I also
>>> don't think we should try to cram the different information into the same
>>> API.
>>>
>>> The current ProcessHandle.Info api has
>>>
>>>      Optional<String> command()
>>>      Optional<String[]> arguments()
>>>
>>> It sounds to me like Roger wants these to contain only exact information.
>>> That seems reasonable, and this probably needs to be specified more clearly
>>> to contrast with what's below.
>>>
>>> On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a
>>> single string which appears to be the concatenation of the arguments (maybe
>>> including the command name). It's also truncated to fit PRARGSZ. It doesn't
>>> make sense to me to try to return this as a String[], as the zeroth element
>>> of that array, and certainly not parsed out into "words". So maybe instead
>>> we should have a different API that returns an imprecise command line as a
>>> single string:
>>>
>>>      Optional<String> cmdline()
>>>
>>> (Naming bikeshed TBS). The semantics would be that this is the process'
>>> command and arguments concatenated into a single string (thus potentially
>>> losing argument boundaries) and also possibly truncated based on platform
>>> (COUGHsolarisCOUGH) limitations. It's certainly useful for printing out in a
>>> ps, top, or Activity Monitor style application, for informational purposes.
>>>
>>> If this were implemented, then on Solaris, command() and arguments() would
>>> always return empty optionals.
>>>
>>> I'm not sure what this should be if the exact information is available. It
>>> would be inconvenient if something that just wanted to print out an
>>> approximate command line had to check several different APIs to get the
>>> information. Maybe cmdline() could assemble the information from exact data
>>> if it's is available, by concatenating the Strings from command() and
>>> arguments(), as a convenience to the caller. But I could go either way on
>>> this.
>>>
>>> Not sure this counts as a tie-breaker, but it might be a reasonable way
>>> forward.
>>>
>>> s'marks
>>>
>> Hi Stuart,
>>
>> thanks a lot for your comments - I like your proposal. For me this
>> sounds like a good compromise.
>>
>> @Roger: should I go and add a new field commandLine and the
>> corresponding getter to the Info class? As Stuart proposed, the getter
>> could check if 'command' and 'arguments' are available and assemble
>> the command line from them. Otherwise it could use the content of the
>> commandLine field if that is available.
>>
>> Regards,
>> Volker
>