need advice on module structure for ISA-specific sources and classes

[Magnus Ihse Bursie]

On 2014-09-04 23:13, John Rose wrote:
> Straw man proposal:  Allow the folder names "cpu.$CPU" and "$OS.$CPU" to occur as a sibling to "share" and $OS in source paths.

I think the basic idea of putting hardware-dependent code in directories 
as "siblings" to the share and $OS directories is sound.

In general, I'm a bit afraid of "over-engineering" in this kinds of 
issues. It is technically easy to make very strict hierarchies and 
structures, but in the real world it often turns out that:

a) we're talking about a very small subset of the code base that is involved

b) things get messy and do not nicely adhere to nice and strict 
categorizations. For instance, x86 code sometimes are shared between 32 
and 64 bits, and sometimes not. Should you have a x86-common, x86-32 and 
x86-64? Or just a single x86, and deal with the differences in address 
size as it happens?

I think it is worth remembering that any way to organize source code 
must be *helpful*, not just nicely categorized. And it must be helpful 
both to the engineers looking for code to modify, and to the build 
system to automatically figure out what should be included when compiling.

So, the answer to the question in b) above is "it depends" -- if there 
are a lot of shared code and just a few places where address size 
differ, putting it all in "x86" seems reasonable. On the other hand, if 
there is very little shared code, splitting it up might make more sense. 
And if it is just a few lines in a few files, just using #ifdefs might 
be simpler. And such situations might change over time, and if the 
change has been to radical, it might be better to reorganize.

I think the KISS-rule is a good guiding principle, and I think Johns 
proposal mostly follow that. The only thing I'd like to suggest instead 
is that we drop the "cpu." prefix. Sure, in theory we might get confused 
when someone releases the "x86 OS" or the "macosx CPU" :-) but in 
reality, there is no problem in telling the difference between windows 
and sparc. The only thing that is important is that we keep the same 
order of $OS and $CPU in the "combined" directories, so we do not mix 
"solaris.sparc" with "arm64.linux".

It is also worth noting in the existing solution that the $OS directory 
is not strictly just OS. It either "OS" (windows, linux or macosx) or 
"OS type" (unix). So we already have different kind of separators as 
siblings to share.

As for the build system, we find the source code to compile for a 
specific platform by combining the share directory with the directories 
matching the "OS" and the "OS type" (if they exist). It would be easy as 
pie to add $CPU and $OS.$CPU as well to that search path.

In the build system, we define two variables for each target platform, 
OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU, where the latter implies 
a specific address size as well. I would very much appreciate if the 
names used for the new directories match these variables (for example, 
the values for OPENJDK_TARGET_CPU_ARCH are: x86, arm, ppc, s390 and 
sparc), since that will allow us to keep consistency of the names in the 
build, and to do the directory matching without any name translations. 
(We've got too many of those already in legacy code :-/)

Finally my personal opinion is that a dash is a better separator than a 
dot, e.g. "solaris-sparc" is more readable than "solaris.sparc" (and 
aligns better with what we've already done in the makefiles), but that's 
not a big deal.

/Magnus