RFR(M): 8233787: Break cycle in vm_version* includes

[Schmidt, Lutz]

Hi Coleen, 

I feel flattered. I could actually imagine diving into this. BUT: there are some other open work items I have promised to push forward. A few of them are not even started yet. As it is my intention to keep promises, I can't give another promise at this time. And there are those other tasks my company pays me money for...

Lutz


On 15.11.19, 16:14, "hotspot-dev on behalf of coleen.phillimore at oracle.com" <hotspot-dev-bounces at openjdk.java.net on behalf of coleen.phillimore at oracle.com> wrote:

    
    
    On 11/11/19 11:56 AM, Schmidt, Lutz wrote:
    > Oh, oh,
    > looks like I stepped into a beehive... Found JDK-8202579 and JDK-8145956 talking about the unwanted use of Abstract_VM_Version.
    >
    > My intended change would not tackle that "mess", as you call it.
    
    That's too bad.  Are you sure you don't want to tackle it?  Please ... ?
    
    Coleen
    
    > But it would make potential future cleanups a little bit easier by ensuring all of hotspot code only includes vm_version.hpp. I'm in the process of modifying my initial change to reflect Kim's suggestions. I'll send it out Tuesday (hopefully), Wednesday the latest.
    >
    > Regards,
    > Lutz
    >
    > On 11.11.19, 11:54, "David Holmes" <david.holmes at oracle.com> wrote:
    >
    >      Also note we have an open RFE to try and fix the VM_Version vs
    >      Abstract_VM_version mess. But it's such a mess it keeps getting deferred.
    >      
    >      David
    >      
    >      On 9/11/2019 11:58 am, Kim Barrett wrote:
    >      >> On Nov 7, 2019, at 10:59 AM, Schmidt, Lutz <lutz.schmidt at sap.com> wrote:
    >      >>
    >      >> Dear all,
    >      >>
    >      >> may I please request reviews for this cleanup? It's a lot of files with just some #include statement changes. That makes the review process tedious and not very challenging intellectually.
    >      >>
    >      >> Anyway, your effort is very much appreciated!
    >      >>
    >      >> jdk/submit results pending.
    >      >>
    >      >> Bug:    https://bugs.openjdk.java.net/browse/JDK-8233787
    >      >> Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8233787.00/
    >      >>
    >      >> Thank you!
    >      >> Lutz
    >      >
    >      > I don't think this is the right approach.  It makes all the
    >      > vm_version_<cpu>.hpp files not be stand alone, which I think is not a
    >      > good idea.
    >      >
    >      > I thik the real problem is that Abstract_VM_Version is declared in
    >      > vm_version.hpp.  I think that file should be split into
    >      > abstract_vm_version.hpp (with most of what's currently in
    >      > vm_version.hpp), with vm_version.hpp being just (untested)
    >      >
    >      > <code>
    >      > #ifndef SHARE_RUNTIME_VM_VERSION_HPP
    >      > #define SHARE_RUNTIME_VM_VERSION_HPP
    >      >
    >      > #include "utilities/macros.hpp"
    >      > #include CPU_HEADER(vm_version)
    >      >
    >      > #endif // SHARE_RUNTIME_VM_VERSION_HPP
    >      > </code>
    >      >
    >      > Change all the vm_version_<cpu>.hpp files #include
    >      > abstract_vm_version.hpp rather than vm_version.hpp.
    >      >
    >      > Other than in vm_version_<cpu>.hpp files, always #include
    >      > vm_version.hpp.
    >      >
    >      
    >