RFR (S): 8214791: Rename vm_operations_g1* files to g1VMOperations*

[Per Liden]

Hi,

On 12/5/18 10:48 AM, Thomas Schatzl wrote:
> Hi,
> 
> On Tue, 2018-12-04 at 17:10 -0500, Kim Barrett wrote:
>>> On Dec 4, 2018, at 11:40 AM, Thomas Schatzl <
>>> thomas.schatzl at oracle.com> wrote:
>>>
>>> Hi all,
>>>
>>>   can I have reviews for this renaming of the vm_operations_g1*
>>> files
>>> to something more fitting? Other than that only includes and the
>>> #define has been fixed.
>>>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8214791
>>> Webrev:
>>> http://cr.openjdk.java.net/~tschatzl/8214791/webrev/
>>> Testing:
>>> local compilation
>>>
>>> Thanks,
>>>   Thomas
>>
>> Coleen and I talked about this, and neither of us wants yet another
>> naming convention for these files.
>> See her comment in the bug report for her
>> preference.  (vmG1Operations).  I don’t care that much
>> about the specifics, so long as there is consistency (which there
>> admittedly is not, at present, but
>> this proposed change just makes that worse).
>>
> 
> I could rename the other gc files too to make them consistent, e.g.
> cmsVMOperations :)
> 
> However I can be convinced to go with vmG1Operations although it does
> read backwards imho. At least it gets rid of the underscore.
> 
> New webrev with that latter change:
> http://cr.openjdk.java.net/~tschatzl/8214791/webrev.1

I don't know... I would suggest we have either a prefix or a suffix. The 
"midfix" (is that a word?) style is just strange. For example:

  runtime/vmOperations.hpp
  gc/shared/gcVMOperations.hpp
  gc/g1/g1VMOperations.hpp
  gc/parallel/psVMOperations.hpp
  gc/cms/cmsVMOperations.hpp

or maybe (to follow the vmStructs style):

  runtime/vmOperations.hpp
  gc/shared/vmOperations_gc.hpp
  gc/g1/vmOperations_g1.hpp
  gc/parallel/vmOperations_ps.hpp
  gc/cms/vmOperations_cms.hpp

But then I also don't think there is any real value in always having 
VM_Operation (or other things like OopClosure) classes declared in 
separate files, like we currently do. In some cases such classes have 
very little in common and are better place in the context they are used. 
For example, in ZGC the VM_ZOperation class is an internal part of the 
ZDriver, and not declared in a separate file.

Meh...

cheers,
Per