RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods

[serguei.spitsyn at oracle.com]

Hi Volker,


On 3/28/19 03:15, David Holmes wrote:
> Hi Volker,
>
> On 28/03/2019 5:54 pm, Volker Simonis wrote:
>> Hi Serguei,
>>
>> can you please detail a little bit on the reasons why you finally
>> decided to change the implementation to conform to the spec instead of
>> just updating the spec to endorse a behavior which is there since
>> quite some time?
>
> The behaviour that has been there "quite some time" only actually 
> works for very limited usecases. In trying to legitimise the 
> capability and allow you to add/remove private methods we encountered 
> an ever increasing spiral of complexity in trying to establish 
> meaningful semantics. Is it physically possible to implement this? 
> Yes. It is worth the cost in complexity and maintenance? We concluded 
> not.
>
> We should try to produce a better summary of all the issues.

Thanks, David, for replying to this question.
I agree, we have to provide a better summary of all the issues we 
discovered.

Shortly, the capability to allow to add/remove private methods has 
non-local impact
on VM mechanisms such as nestmates, methods resolution, MethodHandle's 
and reflection.
The red flag is that we were looping in discovering more problems than 
were initially expected.
Yes, fixing those is doable but will introduce extra complexity and 
maintenance cost.
We concluded that it is not worth it.


> Cheers,
> David
>
>> I read trough the comment thread of "JDK-8192936" and it seems to me
>> that right until your last comment from today, the general conses has
>> been to change the specs rather than the implementation. I understand
>> from the various comments in that issue that changing the specs is not
>> trivial but still doable. Unfortunately, some of the referenced
>> material in that issue is not available outside Oracle (i.e.
>> wiki.se.oracle.com) - it would be nice if you could make these
>> information available in the OpenJDK wiki or somewhere else.
>>
>> I think that adding private methods is a feature widely used by a lot
>> of tools and removing it will break them. Deprecating this feature in
>> a non-LTS release and removing it after "a couple" of (non-LTS)
>> releases won't help a lot because many productive systems won't use
>> these releases anyway.

This is interesting point.
We may need to think a little bit more on this.


Thank you for your questions and concerns!
It is what we hoped for.

Thanks,
Serguei

>> Thank you and best regards,
>> Volker
>>
>> On Thu, Mar 28, 2019 at 1:57 AM serguei.spitsyn at oracle.com
>> <serguei.spitsyn at oracle.com> wrote:
>>>
>>> Hi All,
>>>
>>> This is request for comments and potentially reviews for the 
>>> following CSR:
>>>    https://bugs.openjdk.java.net/browse/JDK-8221528
>>>
>>>
>>> Problem
>>>
>>> Now, the implementation of JVMTI RedefineClasses and 
>>> RetransformClasses allows to
>>> add/delete private static and private final instance methods in the 
>>> new class versions.
>>>
>>> It means that current implementation does not follow the JVM TI spec 
>>> which explicitly states:
>>>
>>> "The redefinition must not add, remove or rename fields or methods, 
>>> change the signatures
>>>   of methods, change modifiers, or change inheritance."
>>>
>>> For details, please, see the spec:
>>>
>>> https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RedefineClasses 
>>>
>>> https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RetransformClasses 
>>>
>>>
>>> The decision was made to align the implementation with the spec.
>>> For reference, please, see the 
>>> https://bugs.openjdk.java.net/browse/JDK-8192936.
>>>
>>> This decision is going to cause some inconveniences to the customers.
>>>
>>>
>>> Solution
>>>
>>> The solution is to introduce a compatibility mode with new 
>>> command-line VM option:
>>>     -XX:{+|-}AllowRedefinitionToAddOrDeleteMethods
>>>
>>> New option will enable old behavior and allow the JVM TI 
>>> RedefineClasses and RetransformClasses
>>> to add/delete private static and private final instance methods in 
>>> the new class versions.
>>> Without this option the old behavior will be disabled.
>>>
>>> New option is deprecated right away.
>>> The plan is to keep it for a couple of releases to allow customers 
>>> (tool vendors)
>>> to remove dependency on old behavior from their tools.
>>>
>>> Thanks,
>>> Serguei