A Distributed, Persistent Architecture for JOS

by Ian Davis, 13 Nov 1997
Version 1.0 (Draft)

1. Introduction

1.1 Overview

This document describes a proposal for implementing a distributed, persistent architecture for JOS, a free Java Operating System. It proposes that the Java Virtual Machine is partitioned into Domains, which communicate through the use of RMI. The Distribution model proposed is only fairly granular in that only whole processes can migrate between Domains.

1.2 Goals

To create an architecture that will allow processes to be distributed amongst a network of workstations so as to fully utilise spare processing capacity.

1.3 Assumptions

The network is well connected.
The network is unreliable in that messages can be delayed for an arbitrary amount of time or even lost completely.
The network can convey messages to multiple recipients but these may arrive in any order.
Workstations on the network are heterogeneous in that they vary in processing and storage capabilities.
Workstations on the network are homogenous in that they all run JOS

1.4 Terminology

Process

A Process is created when a class's main() method is executed. Every Thread and ThreadGroup instatantiaed by the Process's main thread is considered to belong to that Process.

2. Proposed Architecture

2.1 Domains

A Domain is an environment within which Processes can execute. Domains serve to partition a Virtual Machine into separate process environments.

To enable complete partitioning of the Virtual Machine it is necessary to provide distinct copies of certain core Java classes to each Domain. These are:

java.lang.ClassLoader - each Domain may implement a different strategy for loading classes

java.lang.Runtime - each Domain may implement a separate garbage collector and memory manager.

java.lang.SecurityManager - each Domain may implement a separate Security model

java.lang.System - each Domain may redirect standard io to different streams

Multiple Domains may co-exist within the same Virtual Machine. Most of the time only a single Domain will ever exist for a given Virtual Machine. This scenario is functionaly identical to the standard Virtual Machine. However, at times there will be more than one Domain in existence within a single Virtual Machine. The first Domain to be instantiated in a Virtual Machine is known as the Primary Domain. All other Domains are known as Secondary Domains.

Each of these Domains could represent a different user's environment in a multi-user system or, since each Domain has control over it's own security policy, separate Domains could be set up to run trusted and untrusted classes.

On creation, each Domain is assigned a unique DomainIdentifier based on a GUID which remains that Domain's identifier for the lifetime of that Domain.

2.2 Inter-Domain Communication

Domains communicate with one another through the use of RMI. Each Domain instantiates a DomainPortal object that implements the java.rmi.UnicastRemoteObject interface. The DomainPortal object is that Domain's communication interface with other Domains. It may be used to send messages and objects between Domains.

Any Domain wishing to communicate with another Domain obtains a reference to the remote Domain's DomainPortal object through the use of the RMI registry service, providing a hostname and DomainIdentifier. Communication between Domains is strictly controlled via the DomainPortal methods.

2.3 Process Distribution

The proposed architecure allows for the migration of Processes between Processes and thus create a distributed network of Virtual Machines. Processes may be either migrated manually or automatically. A process may request that the Domain transfers that process to a specific remote Domain or the Domain itself can be left to decide when process should be shared.

A Domain is considered to be either a Process Sender or a Process Receiver. Domains will generally start in the Receiver state. Once a Domain specific utilisation threshold has been exceeded the Domain switches state to become a Sender of Processes. Once utilisation has fallen below a threshold the Domain's state switches back to Receiver.

Whenever a Domain changes its state it multicasts a message indicating the change. This will either be "I'm idle, send me something to do" or "I'm busy, who can take some of my work?". Any Domain in the Receiver state receiving a Busy message can respond directly to the busy Domain requesting a process. Any Domain, whether in the Sender state or not, can respond to an Idle message requesting that the Idle Domain take a process. A Domain is free to ignore or respond to any message as it sees fit. Domains may implement any appropriate strategy to select the process to send to a remote Domain.

Each Process has a Parent Domain and an Owner Domain. The Parent Domain is defined as the Domain in which the Process is currently executing. The Owner Domain is defined as the Domain that actually owns the Process. The Parent Domain and the Owner Domain may or may not be identical.

Local strategies can also be implemented to ensure that Process distribution utilises neighbouring Domains in preference to physically remote Domains, or Domains connected only by slow links.

2.4 Domain Managers

Each Domain has exactly one DomainManager. The DomainManager is responsible for managing that Domain's persistent store by removing the semantic distinction between accessing objects in memory and objects stored on disk. They are also responsible for maintaining a consistent and recoverable representation of the Domain. This can be achieved through the use of change logging.

At regular intervals, particularly before a system shutdown, the DomainManager will be required to stabilise the persistent store. This involves writing each object to non volatile storage and creating a descriptor that may be used to reconstruct the state of the processes within the Domain. Any owners of any processes not owned by the current Domain must be informed of the stabilisation request allowing the owning Domain a chance to recall the process.

2.5 Garbage Collection

Each Domain is responsible for garbage collecting the Processes it owns including those hosted by remote Domains.

Content of these pages are owned and copyrighted by the poster.
Hosted by: