RFR: 8317697: refactor-encapsulate x86 VM_Version::CpuidInfo [v2]

[Jan Kratochvil]

On Tue, 24 Oct 2023 10:02:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>     * the original  struct instance was explicitly zero-initialized.

It had to be zero-initialized by user of the struct. Which is error prone if you forget the zero-initialization during each use of the struct type.

>     * If we just made it a class there would not be any zero initialization

struct vs. class does not matter.

>     * If the class extends the struct then we (somehow) regain zero initialization
>       ??

zero-initialized:

echo 'struct A { long a; }; void f() { A a=A(); }'|g++ -c -o 1.o -Wall -x c++ -;objdump -dC 1.o

NOT zero-initialized:

echo 'struct A { long a; }; void f() { A a    ; }'|g++ -c -o 1.o -Wall -x c++ -;objdump -dC 1.o

It is important if one calls the default constructor or not. With one inheritance one can enforce the zero-initialization by explicitly calling the inner `_CpuidInfo` default-constructor from the outer class `CpuidInfo`.

> Maybe methods on a struct weren't so bad after all. I'd like to hear other views on this code change. (Just to be clear 2 reviews are needed for hotspot code changes anyway.)

struct vs. class does not matter here. I am just mixing two refactorizations together. I can remove the zero-initialization (I can submit it as a separate merge request but then I do not need that part myself).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16093#discussion_r1369961265