Nucleaus from ATI, but other RTOSes (OS9, for example) already have JVMs available. What's so special about JSCP? And how does it differ from PERC?
First, JSCP is more than a JVM. The reason it's more has to do with its target environment: an embedded real-time system. While that's the same target that PERC is aimed at, PERC's approach is more rigorous. PERC provides hard real-time (i.e., deterministic) performance, and it does so at the expense of adding nonstandard syntax to the Java language (which is why it's called PERC, and not "Java-something"). JSCP does not provide hard real-time performance. Instead, it provides a well-isolated JVM that runs as its own process within the parent RTOS.
This isolation of
the JVM to its own process has an unexpected benefit, which becomes apparent if you consider the alternative: a JVM that's integrated into the RTOS. Such a JVM might, for example, use the RTOS's thread support for managing Java threads. Consider, however, what it would mean to debug such a heterogeneous thing. You would be dealing with the application itself, the bytecode interpreter, and the JVM-to-RTOS interface. NSI maintains that implementing the JVM as its own process (with well-defined communications between RTOS tasks and JVM applications) makes for an easier-to-debug solution.
JSCP's other strength is its configurability. For example, you can set an external memory-limit parameter to set the memory-size limit that JSCP will use. JSCP regulates its memory consumption automatically. Similarly, you can set the maximum processor time slice given over to the JSCP. (Remember, JSCP is running as one of a number of tasks that share RTOS resources.) Constraining system resources -- memory and
processor utilization -- is critical in a real-time system.
A JVM for Embedded Real-Time Apps
