Java Reference
In-Depth Information
needs to be ported to Symbian OS - which does not mean that the whole
VM needs to be written from scratch! The VM needs to be written in a
standard dialect of C or C++ that is compatible with the Symbian OS
toolchain. Additionally, the VM must define and use some porting layer
through which it receives basic services from the underlying platform.
Our reference VM, the CLDC-HI HotSpot, is written in standard C++
and has a minimal porting layer. Interested readers can examine the
implementation in the phoneME project repository.
5
(Just to remind you,
we are currently talking about the headless VM, not the full-blown Java
ME run-time environment which includes MIDP.)
Below you can find a few examples of some of the CLDC-HI HotSpot
porting layer interfaces that need to be implemented using the native
operating-system APIs:
// All VM output goes through this method
void JVMSPI_PrintRaw(const char* s);
// Returns the time as System.currentTimeMillis()
static jlong java_time_millis();
// Allocate a memory chunk for the Object heap that can expand or shrink
address OsMemory_allocate_chunk(size_t initial_size, size_t max_size,
size_t alignment);
// Flush the CPU instruction cache to ensure that the code generated by
// JIT is loaded from main memory when it is executed.
void OsMisc_flush_icache(address start, int size);
The first thing that is done when porting a VM is to build it on the
platform and run a headless application - a single class with a single static
main function that does not do much more than print to the console.
After successfully implementing the porting layer and building the VM,
we can run our first headless application. Cool. Now what's next? We
need to add the Profile on top of the VM. From here things accelerate
and it becomes more and more interesting.
As we said, the Java ME subsystem includes a Profile (e.g., MIDP 2.0)
implemented by Symbian which is VM-agnostic so that licensees can
use VMs from different VM vendors. We also mentioned an insulation
layer between the Profile and VM proprietary interfaces. Let's take a
look at this insulation layer, in relation to the CLDC-HI HotSpot VM:
CLDC-HI defines the KNI interface which is designed to be a logical
subset of JNI and provides functions for instance field access, to objects,
strings, arrays, classes, interface operations, and so on. One of the key
goals of KNI is to isolate the external code (e.g., Profile implementation
code) from the internal implementation details of the CLDC-HI VM.
However, while succeeding in doing that, the KNI is still VM-specific
and is not portable across VMs. For example, KNI uses a register-based
approach for retrieving method parameters from the stack frame. Use of
5
phoneme.dev.java.net/svn/phoneme/components/cldc/trunk/src/vm/os/
