RFR (T) 8250042: Clean up methodOop and method_oop names from the code

[Chris Plummer]

On 7/23/20 4:17 PM, coleen.phillimore at oracle.com wrote:
>
>
> On 7/23/20 6:29 PM, Chris Plummer wrote:
>> Hi Coleen,
>>
>> The JVMTI changes look fine, although I wonder why in jvmtiEnter.xsl 
>> you did the rename to "checked_method" instead of just "method". Was 
>> there a conflict in some cases?
>
> Yes it was quite painful.  The jvmti.xml spec has jmethodID parameters 
> to be named "method" and I didn't want to change that.
>
>         <param id="method">
>           <jmethodID class="klass"/>
>             <description>
>               The method in which to set the breakpoint
>             </description>
>
> I picked checked_method because you get it by calling this below and 
> the alternative "m" I think was used somewhere else (or not 
> descriptive at all).
>
> +  <xsl:text>  Method* checked_method = 
> Method::checked_resolve_jmethod_id(</xsl:text>
>
Ah, so this is the case of having to deal with a jmethodID and a Method* 
in the same scope. I think this is fine, although it would be nice if 
Serguei also gave his blessing.

thanks,

Chris
> Thanks,
> Coleen
>>
>> thanks,
>>
>> Chris
>>
>> On 7/23/20 9:58 AM, coleen.phillimore at oracle.com wrote:
>>> See bug for more details.  I've been running into these names a lot 
>>> lately.   Many of these names are in JVMTI.
>>>
>>> Tested with tier1 on all Oracle platforms and built on non-Oracle 
>>> platforms.
>>>
>>> open webrev at 
>>> http://cr.openjdk.java.net/~coleenp/2020/8250042.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8250042
>>>
>>> Thanks,
>>> Coleen
>>
>>
>