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

[Kim Barrett]

> 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.