Hi John,
- I see there are multiple versions of the VIS extension for SPARC, and
of the AVX extension for x86. Do you envisage encoding ISA versions into
the $CPU value? What taxonomy of ISAs is suggested by JNR?
- If precision is desirable, can I suggest preferring isa/$ISA to
cpu/$CPU throughout? First, because we don't want to sling CPU-ish terms
like "x86" when we mean ISA-ish terms like "x64-with-AVX2". Second,
because I think Java's heritage is more ISA than CPU (see JVMS section 1.2).
- With reference to mlib_v_ImageCopy_blk.s: it is OS-specific,
SPARCv9-with-VIS-specific code, right? So its path would be something like:
src/java.desktop/unix.sparc9vis/native/libawt/sun/...
Alex
On 9/4/2014 2:13 PM, 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
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
