VM_Version_ext has some additional functionality but also not been actively maintained in years. There are probably a lot of cruft about old CPUs that are no longer relevant.
Investigate possibility of consolidation with VM_Version and take the opportunity to prune the VM_Version_ext code.
Update: Also the Abstract_VM_Version versus VM_Version split is awkward and results in the ability to "override" methods that should never be overridden. We should be able to generate a single VM_Version class that contains all of the shared and platform specific functions needed - similar to how the os class is created though preferably with a cleaner mechanism like namespaces.
Investigate possibility of consolidation with VM_Version and take the opportunity to prune the VM_Version_ext code.
Update: Also the Abstract_VM_Version versus VM_Version split is awkward and results in the ability to "override" methods that should never be overridden. We should be able to generate a single VM_Version class that contains all of the shared and platform specific functions needed - similar to how the os class is created though preferably with a cleaner mechanism like namespaces.
- duplicates
-
JDK-8233943 get_jvmti_interface directly references Abstract_VM_Version
- Closed
- relates to
-
JDK-7041262 VM_Version should be called instead of Abstract_VM_Version so that overriding works
- Resolved
-
JDK-8258004 Remove unnecessary inclusion of vm_version.hpp
- Resolved