RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Tue May 21 06:19:14 UTC 2019


Hi guys,

I've found one more fragment in the IsModifiableClass spec which has to 
be fixed.


Updated webrev v2:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/


Specdiff:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/


Enhancement:
   https://bugs.openjdk.java.net/browse/JDK-8046018

Related CSR:
   https://bugs.openjdk.java.net/browse/JDK-8223915


Thanks,
Serguei


On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote:
> Hi David,
>
> Thank you for looking at this!
>
>
> On 5/20/19 20:53, David Holmes wrote:
>> Hi Serguei,
>>
>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote:
>>> Please, review a fix for enhancement:
>>> https://bugs.openjdk.java.net/browse/JDK-8046018
>>>
>>> Related CSR:
>>> https://bugs.openjdk.java.net/browse/JDK-8223915
>>
>> I have some comments on the CSR and about this change overall as to 
>> me it is not a simple clarification at all, but potentially a 
>> significant change in the meaning of the capability.
>
>
> I've answered your question in the CSR with my comment.
>
>>> Webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ 
>>>
>>
>> You introduced a typo: modifialble
>>
>> Assuming this proceeds a similar change is needed earlier:
>>
>> 7444         <capability id="can_redefine_any_class">
>> 7445           If possessed then all classes (except primitive, 
>> array, and some implementation defined
>> 7446           classes) are modifiable (redefine or retransform).
>
> Good catch, thanks!
> I've updated the webrev in place.
>
> Thanks,
> Serguei
>
>>
>> Thanks,
>> David
>> -----
>>
>>>
>>> Summary:
>>>
>>>    The fix is to make the JVMTI can_redefine_any_class capability 
>>> spec more inconsistent.
>>>    It is just about a couple of lines.
>>>
>>> Thanks,
>>> Serguei
>



More information about the serviceability-dev mailing list