[HARMONY-7] Compliance of system calls with POSIX standards and native Windows standards

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Component/s: VM
• Environment: All platforms, in particular Solaris 9, Windows XP, Windows (CygWin),; and Mac OS-X at this time.
• Assignee: Daniel Lydick
• Reporter: Bootstrap JVM (Daniel Lydick)
• Created: 11/Oct/05 01:53
• Updated: 19/Jul/06 14:39

Description

The original development was done on a Solaris 9 platform and
there was a significant attempt to write all code in a way that would
be easy to set up on any platform that could compile ANSI 'C'. However,
in the interest of getting the first cut out the door, certain shortcuts
were taken just to get it working on the original platform.

One of these was the use of the Solaris yield(2) system call as
found in 'bootJVM/jvm/src/timeslice.c'. Geir Magnusson has
annotated this issue here and stubbed out yield(2) for the
Windows platform so he could complete his initial compilation
for CygWin. Someone needs to check and see if yield(2) is a
POSIX call. If not, the POSIX equivalent should be substituted.
(Notice that this source file has numerous library calls not found
in your typical application program, including signal(3), setitimer(3),
pthread_create(3) and the like).

Since the GCC compiler for CygWin has a number of libraries
which certainly include POSIX system calls, it might be worth
the while to see if that reference could be applied to both the
original Solaris implementation and the CygWin compile
that he did. It might also then be a good idea to see if either
this or a native Windows equivalent might be available for the
native Windows compilation, and what native Windows library
calls should be used for the other uncommon library functions
found in this source file. ('timeslice.c' is probably the most
OS-dependent source file in the whole program.)

Another item: Someone should take Geir's CygWin compilation
(done on Windows XP) and compile it in a native Windows
environment to see if any more adjustments needed to get it to
compile there as opposed to CygWin. The main reasons are
described in the preceding paragraph. (Remember, though,
that I am still working on some crucial parts of the runtime and
not all virtual opcodes are implemented, although this will
certainly change in the near future.)