JVMTI retransformation and addition of private methods

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Mon Apr 16 18:44:35 UTC 2018


Added to the JDK-8192936.

Thanks,
Serguei


On 4/16/18 11:36, 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.
>
> as well as conflicting with the implementation of 
> SetNativeMethodPrefixes et. al. and the RI in terms of 
> private/final/static.
>
> 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.
>
> -Robert
>



More information about the serviceability-dev mailing list