Protocol version of Attach API

[臧琳]

Dear All,
     Thanks for your suggestions.
     IMHO, the problem is that it seems the "AttachOperation::arg_count_max" limits the ability to extend the jcmd/jmap tools for new arguments. and it is hard for me to extend jmaps new functionality (WIP, tracked at JDK-8214535 ) without touching this arg_count_max.
     So the problem for me is how to make the compatibility works.  I will also try to investigate the issue and seeking chance for fix it.
     And Thanks Chris and David point out the problem of Windows for 8215622, I will investigate it too.


Thanks,
Lin

________________________________________
From: serviceability-dev <serviceability-dev-bounces at openjdk.java.net> on behalf of David Holmes <david.holmes at oracle.com>
Sent: Wednesday, February 27, 2019 10:35:34 AM
To: Alex Menkov; Chris Plummer; Erik Gahlin; serviceability-dev at openjdk.java.net
Subject: Re: Protocol version of Attach API

On 27/02/2019 8:48 am, Alex Menkov wrote:
>
> On 02/26/2019 13:58, David Holmes wrote:
>> On 27/02/2019 7:50 am, Chris Plummer wrote:
>>>>> Also want to point out that this issue might be two-way: 8 can't
>>>>> attach to 13 and 13 may have issues attaching to 8 (what happens
>>>>> with the extra argument that is sent?).
>>>>
>>>> You can't expect an old release to accept new and unknown args. That
>>>> is perfectly fine.
>>>
>>> But we should expect that you can attach from 13 to 8. If unknown
>>> args are sent, we would need for them to be quietly ignored.
>>
>> That depends on how well the code was written in 8, but I think it
>> perfectly fine to get an error if you try to send a command that 8
>> doesn't (fully) understand.
>
> Looks like AttachOperation::arg_count_max is used not just as max arg
> count, but also to calculate packet size which needs to be read from the
> socket on unix systems (it's expected to be the same for all
> operations). So it cannot be easily fixed.

Yes that is the problem as I have now stated many times - it should be
prpeared to read a variable sized packet, but instead expects a fixed
size on. However it should be easily fixable. I'm testing Yasumasa's fix
now.

> BTW as far as I got Windows if not affected. Looking into the code
> (src/hotspot/os/windows/attachListener_windows.cpp) I suppose the
> feature implemented by JDK-8215622 does not work at Windows as
> Win32AttachListener still support only 3 args.

There were changes on Windows for JDK-8215622 in the Java code, but you
are right that Win32AttachListener::enqueue only accepts and passes on
three args! Yet the updated BasicJmapTest passes on windows ... or
appears to, the log information for those specific tests is missing due
to the "output overflow" problem.

I'm also double-checking Solaris.

> In my opinion it would be better to revert fix for JDK-8215622 and
> rethink how to implement it without changing AttachOperation::arg_count_max

Let's see how Yasumasa's fix works out.

Thanks,
David

> --alex
>
>
>>
>> David
>>
>>
>>>
>>> Chris
>>>
>>>>
>>>> David
>>>> -----
>>>>
>>>>> Chris
>>>>>
>>>>>>
>>>>>>>
>>>>>>> ..Thomas
>>>>>>
>>>>>
>>>
>>>