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

[coleen.phillimore at oracle.com]

Thanks for looking at this.

On 7/24/20 1:01 AM, David Holmes wrote:
> Hi Coleen,
>
> On 24/07/2020 2: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
>
> src/hotspot/cpu/*/*.ad
>
> These still refer to "method oop" and method_oop in a number of places.

Yes, I only replaced method_oop in the shared code and not in the AD 
code.  method_oop can be the name of a parameter and using "sed" to 
change it to "method" doesn't work.   Somebody who understands this code 
and looks at it will have to make the rest of the changes.

What I did was replace "method oop" with "method" and "methodOop" with 
"method" in all the sources.  I replaced "method_oop" with "method" or 
"checked_method" in the shared sources.

>
> src/hotspot/share/adlc/adlparse.cpp
>
> +  frame->_interpreter_method_oop_reg = parse_one_arg("method reg 
> entry");
>
> I guess I'm not understanding the scope of this renaming - why is 
> _interpreter_method_oop_reg not renamed as well? Should this (and 
> other uses) be parsed as method-(oop-reg) rather than (method-oop)-reg?

I don't know this code, so I'd rather not change any more of it. The 
comment makes sense changed, even though the variable name still refers 
to method_oop.

Thanks,
Coleen
>
> Otherwise all okay.
>
> Thanks,
> David
>
>> Thanks,
>> Coleen