Java Reference
In-Depth Information
the KNI interfaces by the MIDP layer would create a direct dependency
on CLDC-HI HotSpot.
To allow replacement of the VM, Symbian OS defines the KJNI which
is a subset of the Java SE JNI. All native code that is required to perform
such operations uses only the KJNI. Porting a new VM to Symbian OS
requires implementing the KJNI in terms of the VM-specific interface. For
example, the implementation of the KJNI for CLDC-HI uses the KNI. As a
result, switching between VMs can be done almost seamlessly, from the
Profile perspective.
Figure 10.6 depicts both the porting layer and the KJNI layer in the
context of Symbian OS and the MIDP layer.
Profile
KJNI layer
VM
VM porting layer
Symbian OS
Figure 10.6
Porting and KJNI layers
VM technology requires quite a few tricks to create a hosted run-time
environment on top of a native platform. Enumerating the tricks would be
long; describing each of the mechanisms would require writing another
book. There are VMs for other languages that do similar operations, such
as interpreting instructions or managing memory, but Java technology
took the theory and optimized it to the maximum. There is an order
of a few magnitudes between the complexity of the Java VM and the
complexity of VMs for languages such as Python or Ruby. So we now
give a few examples of mechanisms in the VM.
10.4.1 VM Threading Model
The Java threading model can vary between different VM implementa-
tions. One model maps Java threads to native OS threads; another, the
lightweight threading (LWT) model, implements threads entirely inside
the VM. Each model has its own pros and cons. A native threading model
means that every Java thread is scheduled by the operating system kernel
with every running thread in the operating system. An LWT model implies
much easier synchronization and is easily portable to many platforms.
J9 uses a native threading model and CLDC-HI HotSpot uses an LWT
model. As an example, we take a quick look into the LWT model in
CLDC-HI.
