Protocol version of Attach API

David Holmes david.holmes at oracle.com
Tue Feb 26 21:30:48 UTC 2019


On 27/02/2019 5:52 am, Chris Plummer wrote:
> On 2/26/19 9:34 AM, Erik Gahlin wrote:
>> On 2019-02-26 07:47, Thomas Stüfe wrote:
>>> Hi David, Yasumasa,
>>>
>>>
>>>
>>>     > Do we support connection to later VMs from earlier JDK tools?
>>>
>>>     I could not find the spec about this.
>>>     So I asked to serviceability folks before filing this to JBS :-)
>>>
>>>
>>> Just to chime in on that, I do not know if it is specified but it is 
>>> certainly very handy in daily use. I often use old jcmd tools to 
>>> connect to newer VMs. I always thought that was a neat design.
>>
>> I agree.
>>
>> The tool was designed to be dumb, so it can connect to JVMs regardless 
>> of release. If something has changed so that is no longer true, it 
>> should be fixed (and backported if needed).
>>
>> Erik
> 
> So do we all agree that backporting is acceptable for fixing backwards 
> compatibility here? Just want to be clear on that. You would need to get 
> the latest 8u to interact with 13 and later, and 7 and earlier would not 
> work. I'd prefer to keep 8 (and earlier) working without any changes to 
> it if possible.

EEk No! You don't fix this by trying to change all the old versions! 
Simply impossible - only the latest updates in those trains would work. 
Logistical nightmare as well.

This is a very simple logic error in the attach logic on Linux (and 
possibly elsewhere)! We just need to fix that bug in 13. Yasumasa 
already suggested one fix that seems quite simple - it adjusts the 
expected amount of data to read if it encounters a logical "EOF". (I 
think it can be simplified further but the gist of it seems fine.)

> 
> 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.

David
-----

> Chris
> 
>>
>>>
>>> ..Thomas
>>
> 


More information about the serviceability-dev mailing list