JDK-8242127: reorganize ABI-dependent layout constants #97
There are two main problems with the way in which ABI-dependent constants are dealt with:
This patch rearranges things a bit. First, it removes the SystemABI.Type abstraction, and associated SystemABI::layoutFor method. Then, it moves all ABI layout constants from MemoryLayouts to SystemABI. Instead of using the enum value as a classification value for the ABI, each ABI constant holder defines its own classification constants. So there is a SystemABI.Win64.ArgumentClass, and a SystemABI.SysV.ArgumentClass and so on and so forth. A notable fact is that the set of classification values that are required by the ABI is much, much smaller than the set of "interesting" C types.
I then adjusted the implementation code not to no longer depend on the SystemABI.Type enum; while doing so I realized (suggestion from Jorn) that the public ArgumentClass enums would actually, both in Windows and AArch be enough to also implement the internal classification system. On SysV, since the classification is quite convoluted, there is a number of 'synthetic' classification classes that are only introduced when classifying struct (e.g. SSE_UP) which would be bad to expose outside - but we need these classes to keep the classification algorithm going. So, I moved ArgumentClassImpl under the sysv folder and kept the code as it was.
The resulting code is, I think more direct, and more scalable. We can keep adding layouts to SystemABI - both platform-independent and platform-dependent ones - they are just different sets of constants.
@mcimadamore This change now passes all automated pre-integration checks, type
JDK-8242127: reorganize ABI-dependent layout constants
Reviewed-by: jvernee, sundar