[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: JVMTI retransformation and addition of private methods
From:       David Holmes <david.holmes () oracle ! com>
Date:       2018-04-17 0:05:28
Message-ID: 03d6503c-e577-5695-05e2-2b121a9f9b9a () oracle ! com
[Download RAW message or body]

On 17/04/2018 4:36 AM, Robert Field wrote:
> Rather than reverse engineer the spec from the hotspot implementation...
> 
> Capabilities are the mechanism by which the level of functionality is 
> defined.   Capabilities say what can be done, not what can't.
> 
> The wording "The redefinition must not add, remove or rename fields or 
> methods, change the signatures of methods, change modifiers, or change 
> inheritance. These restrictions may be lifted in future versions." was 
> clearly left from an earlier version.   Probably should not have been 
> there in the first place but certainly should have updated/removed as 
> JVMTI evolved.
> 
> As written, it explicitly conflicts with the can_redefine_any_class 
> capability:
> 
>     can_redefine_any_class       Can modify (retransform or redefine) any 
> non-primitive non-array class. See IsModifiableClass.

I don't see any conflict there. can_redefine_any_class relates to the 
sets of classes amenable to redefinition, not to the set of changes that 
redefinition can make to a given class.

Arguably there could have been individual capabilities for each kind of 
change, but that seems somewhat extreme to me, unless there are good 
reasons why only subsets of changes would be reasonable to support. The 
existing "you can do anything except x, y, z" within the spec for 
redefineClass is coarse but not unreasonable. It is problematic because 
the exception list is incomplete but that's a different story.

> as well as conflicting with the implementation of 
> SetNativeMethodPrefixes et. al. and the RI in terms of 
> private/final/static.

So two clear cases where the spec should have been updated but wasn't.

> i would suggest removing the quoted text and adding to the text for the 
> can_redefine_classes capability.     Maybe something like:
> 
>           can_redefine_classes       Can redefine classes with RedefineClasses, 
> where the class is non-primitive and non-array and the redefinition does 
> not add, remove or rename fields or methods, change the signatures of 
> methods, change modifiers, or change inheritance.

Moving the text doesn't change the basic problem that the text and 
implementation are not in agreement.

David
-----

> -Robert
> 
[prev in list] [next in list] [prev in thread] [next in thread]