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

[David Holmes]

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.

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