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

[David Holmes]

Hi John,

On 5/09/2014 7:13 AM, John Rose wrote:
> We have standard OpenJDK source locations for platform-specific code, as described in http://openjdk.java.net/jeps/201 .
>
> For example:
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.base/linux/classes/sun/nio/ch/LinuxAsynchronousChannelProvider.java
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.base/linux/native/libnio/fs/LinuxWatchService.c
>
> We have a place for both C and Java sources.  Amazingly, there is even one assembly source file:
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.desktop/unix/native/libawt/sun/awt/medialib/mlib_v_ImageCopy_blk.s
>
> But, there is no place at present for (a) ISA-dependent source files, or (b) ISA-and-platform-dependent source files.
>
> Definitions:  An ISA-dependent source file is coded portably (perhaps in Java, or C with ifdefs) but makes use of specific instructions, such as SPARC VIS or Intel AVX.  A ISA-and-platform-dependent source file is coded for a particular platform and ISA; a typical example would be an assembly file whose syntax is platform specific (like linux/x86).
>
> Context:  The JNR system we are importing to Project Panama will include both types of source files.
>
> Straw man proposal:  Allow the folder names "cpu.$CPU" and "$OS.$CPU" to occur as a sibling to "share" and $OS in source paths.
>
> Here's a BNF style description of JEP 201 source paths:
> path := 'src/' $MODULE '/' platform_scope '/' ( classes_path | native_path | conf_path )
> platform_scope := 'share' | $OS
> classes_path := 'classes/' $PACKAGE '/' *.java
> native_path := 'native/' ( 'include/' *.{h,hpp} | $LIBRARY '/' *.{c,cpp} )
> conf_path := 'conf/' *
>
> The change would be:
> platform_scope := 'share' | $OS | 'cpu.' $CPU | $OS '.' $CPU

As you know hotspot uses:

src/os/*
src/cpu/*
src/os_cpu/*

with subdirectories for each os/cpu/os-cpu combination. That seems 
cleaner to me than pulling each actual platform specific entity into the 
top directory of the module path. Which implies adding an extra /os/ to 
the existing linux/unix/solaris/windows paths.

I don't think either "cpu" or "isa" can ever always be accurate - and it 
is arguable what factors constitute cpu properties versus ISA 
properties. Maybe a completely generic hw so that we can then represent 
various expressions of the actual hardware capability?

My 2c.

Cheers,
David

> Observation 1:  This scheme does not entangle the type of source (native vs. classes) with the platform scope.  It thus allows for platform-specific assembly files, but encourages shared but ISA-specific code.
>
> Observation 2:  Less mangled patterns like "share/cpu/$CPU" might be cleaner, but they also perturb the existing pathname lengths, by adding optional pathname components.  Controlling pathname depth seems like a desirable goal.
>
> In cases where single output artifacts have to be built with support for multiple platforms, we would also add the cpu name somewhere in the $PACKAGE component, and/or the base name of the file (class name), as Graal does.
>
> (There is a possible followup question about deploying multiple ISAs and/or platforms in one artifact, kind of like a multi-JAR.  But I think we can tackle that later, and it may be that package-name hacking will allow multiple ISAs to co-exist when needed, as is the case with Project Sumatra.)
>
> Comments?  Does this look like a good starting point for organizing ISA-specific code for Panama?
>
> Thanks,
> — John
>
> P.S.  As a point of comparison, the hotspot repo uses this grammar, which supports only C and assembly code:
> path := 'src/' platform_scope '/vm/' $GROUP '/' *.{c,cpp,hpp}
> platform_scope := 'share' | 'cpu/' $CPU | 'os/' $OS | 'os_cpu/' $OS '_' $CPU
> where GROUP is something like 'code', 'asm', 'c1', 'classfile', etc., an informal grouping of source files in a language without packages.
> Also, the base name of the file repeats $OS and $CPU components, if present.
> Examples:
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/tip/src/cpu/x86/vm/macroAssembler_x86.hpp
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/tip/src/os/linux/vm/osThread_linux.hpp
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/tip/src/os_cpu/linux_x86/vm/thread_linux_x86.hpp
>