Print
Send LinkPlatform Independent Run-time Environment
The PalCom Runtime Environment (RTE) acts as both a platform for realizing and deploying PalCom components and provides an execution environment for PalCom Runtime Components, Services and Assemblies. It is therefore necessary that at least one instance of the PalCom Runtime Environment is physically located and available on each PalCom Node. In addition, the PalCom Runtime Environment is the only element of the PalCom architecture that explicitly relies on the existence of a network and the capability of PalCom Nodes to join and leave this network when needed.
The specification of the PalCom Runtime Environment contains a specification of the communication model (see Open Communication Protocols for more info) and the component model. The component model defines the hosting of PalCom Components as well as the execution of PalCom Runtime Components, Services and PalCom Assemblies. The PalCom Runtime Environment may, in addition to its main services, contain a virtual machine. The presence of a virtual machine as part of a Runtime Environment in a specific implementation is optional according to the specification. Besides some device-specific hardware microprocessor, the device platform may consist of an operating system. The specification does, however, not mandate the presence of an operating system, and if one is present, it does not mandate a specific operating system. The PalCom Runtime Environment should be implementable on most modern operating systems.
Reference Implementation
Parts of the PalCom Toolbox have been realized in a reference implementation of the PalCom Open Architecture. The diagram below sketches the software Toolbox elements provided as part of this reference implementation. As sketched, the structure is more or less layered, and this figure is sometimes referred to as the “PalCom Stack”, even though it is not, strictly speaking, a stack:
The Runtime Environment can be found in the middle part of this diagram. The part-elements of this is presented below.
Runtime Engine
In the reference implementation, the PalCom Runtime Engine consists of a Virtual Machine and supporting libraries, all based on Object-oriented programming. As depicted in the diagram above, the engine consists of either the pal-vm or a standard Java VM.
For the purposes of comparison, the current performance of the pal-vm and supporting libraries and tools is around 50% of that of the Sun JVM related libraries and tools and runs on devices with as little as 2Mb memory.
Each Virtual Machine has different advantages with respect to the PalCom Challenges, some of these are highlighted in the sections below. This two-string execution model allows for a programming model, where you rapidly construct your Services and Assemblies on your Desktop machine, in a familiar programming environment like Eclipse. From within Eclipse you can execute and debug your system using the built-in JVM engine. Later you can then – still on the Desktop machine – try out the pal-vm, and start utilizing some of the special features, it provides. Finally you can deploy your components to specific devices, that you want to take part in the PalCom system you are constructing.
Language Interoperability
One of the PalCom Challenges address is about Heterogeneity vs. Coherence. The pal-vm address this one one way by supporting several programming languages including Smalltalk, Java and BETA. Although not yet fully implemented, transparent language interoperability can be achieved with an externally defined common type system.
Current multi-language support is achieved by:
- Providing dynamic typing which allows direct mapping for both dynamically typed languages such as Smalltalk and object-oriented languages such as Java;
- Requiring much less conformance with high-level languages than, for example, the .NET Common Language Specification. E.g., pal-vm languages are not required to support method overloading;
- Leaving static type checking and handling of constructs such as method overloading to the high-level language compilers.
At runtime, PalCom components may be composed of classes written in either of the supported languages, and the classes may inherit from and call classes written in other supported languages. Furthermore a declarative interface to methods written in procedural languages like C is provided, allowing for easy integration with third-party software.
Exception Handling
One of the ways the pal-vm address the PalCom Challenge of Change and Stability is by supporting throwing and catching of language independent runtime exceptions via a generic and highly flexible exception mechanism.
The mechanism allows any object to be thrown as an exception. On top of the support provided by the runtime environment, it is possible to build abstractions in library code which extend the exception mechanism to satisfy the requirements of specific languages.
This mechanism can be used by the higher level Contingency Handling to trigger contingency events.
Resource Awareness
The pal-vm is augmented with low-level support for resource management and migration.
Resource Awareness supports handling of a number of the PalCom Challenges, e.g., it provides a means for the system to give visibility of available resources.
In particular, the primitives and system library code provides:
- A measure of the amount of memory that has been allocated on a system. By measuring this before and after an operation, device resource management can remain aware of the memory usage of that operation. Note that this measure includes memory that has been allocated but no longer in use (i.e., it could be reused after a garbage collection);
- The ability to signal to a scheduler that is triggered when a certain amount of memory has been allocated. The signal is resettable by the scheduler. This allows device resource management to limit the memory allocated by a process when performing an operation;
- The above measure and signal based on the number of bytecodes executed rather than the number of bytes allocated.
Reflection
Reflection is a well-known mechanism for supporting inspectability, thereby addressing the PalCom Challenge of Visibility and Invisibility. Traditional VM-based object-oriented reflection as in Java and .NET is based on the existence of full metadata for all methods, parameters, etc. in the compiled deployment units. The pal-vm does not carry full metadata in components.
Although some metadata is available on methods and fields, the types of fields and method parameter types are not included. In the case of Smalltalk components this is natural since the types are dynamic and therefore cannot be determined by the compiler or VM ahead of time.
The actual objects that are used when the program is executed are of course all marked with their types (classes and interfaces). Thus, the lack of type annotations cannot lead to unpredictable behaviour as an exception will be thrown if the type assumptions of the programmer fail to hold at run time.
The advantages of not storing type annotation are twofold. Firstly, it saves considerable space which can be at a premium in palpable devices. Secondly, it makes it considerably simpler to load and update code on a device; since there are no type annotations on methods and classes, they cannot become inconsistent when related classes and methods are changed.
A Two-Part VM
The pal-vm is being redesigned to support a split-mode operation, as illustrated in the diagram below. This is inspired by the OSVM system.
In a variation on the OSVM approach, the open proposal is to move some of the support for reflective operations to a separate program that is closely coupled to the VM. In effect, the VM would be divided into two parts, the execution part and the reflective part. These two parts would be tightly coupled in terms of execution time (they are started and stopped together) and in terms of communication (they have extensive implicit and explicit knowledge about each others internal state).
On medium sized PalCom devices (PDAs, stationary devices, in-vehicle devices with large amounts of memory (eg. 16Mbytes) the reflective and execution parts could run together on the same device. On small devices like sensors or battery-powered sub-PDA devices where space is at a premium it might be possible to move the reflective part of the VM to some other hardware that was nearby. The communication between the two parts of the VM might be intermittent, so the execution part would have to be able to perform all normal operations without contact to the reflective part. However, if an external user or service required access to the reflective interface that would presuppose that some form of network connection existed. This network connection could also be used to contact the reflective part of the VM. Thus the separation of the VM would be transparent to the users.
Finally, a HMAPs can be used to expose the internal state of components, either by adding a HMAP datastructure on top of the virtual machine, or by adding HMAP support directly in the virtual machine, the latter approach allowing exposure of VM internal structures, such as methods, parameters, etc. Currently, the pal-vm implements HMAPs in the core libraries, but with limitations on the scope of the metadata available (through the HMAPs), due to the size-specific constraints imposed by support for small devices. In a future redesign of the pal-vm access to the subtrees of HMAPS containing reflective data about the VM will be limited to the reflective part of the VM. By transparently forwarding HMAP requests from the execution part of the VM to the reflection part of the VM this change can be made transparent when the two parts of the VM are in contact with one another. On larger devices such as PDAs this would be all the time.
Process and Thread
The pal-vm executes one or more concurrently running processes. Each process is isolated from other processes meaning that the object graph of one process shares only immutable objects with other processes.
The pal-vm will execute one or more concurrently running processes, which in turn schedule one or more threads, each implemented using a coroutine.
The pal-vm scheduling mechanisms allow both cooperative scheduling and preemptive scheduling.
Process migration is possible by pausing a process, serializing process HMAPs , sending them to another node, deserializing them, and then restarting the process. To restart the process, the same components would be needed as had been used on the first node, but since the component files are device independent there will be no difficulties with compatibility. If PalCom Services are implemented using processes, this naturally implies that PalCom Services can also be migrated.