Google

Resources: Tracking internal VM data structures

Introduction

The virtual machine maintains many internal data structures which may or may not need to be shared among the teams. For example, memory is a global resource that needs to be controlled in order to prevent code from overstepping its limits. Therefore, memory has been turned into a `Resource' and is managed on a per-team basis accordingly. Our resource abstraction is general: although resources such as namespaces are not quantifiable like memory, we fit them under the same general `resource' abstraction. The internal representation of a resource is just a simple structure and a set of functions to handle common requests on the resource. Ideally this representation is flexible enough to support whatever "resource" a JanosVM-hosted environment needs to control.

Specifications

A resource specification, or just `spec', is used to describe a team's requirements for a specific resource. Each resource defines its own structure based on what it provides and what the requester is allowed to specify. This spec is then passed to the resource which determines whether or not it can fulfill the request. If the resource decides to grant access then a resource client object is returned, which is used to access the resource's services. Since the spec isn't referenced by the client object, the spec can then be destroyed or used to make additional requests on the resource.

Client

The client object of a resource is used as a proxy to make requests on a specific resource. This allows us to track usage and be able to cut any links to the resource if the team is terminated. For example, when requesting more memory from the system, a team's GC must first make a request on its memory client, which decides if this allocation will put it over the maximum allowable usage.

Supported Resources

JanosVM currently supports four types of resources, outlined below. There are several obvious resources which are not currently supported at the JanosVM level: CPU time, network bandwidth, and filesystem space. Adding support for these resources, or any other environment-specific resource, should be straightforward (see Adding Resources, below). The javadoc-generated documentation contains an Overview of the JanosVM resources.

Memory

The memory resource is split between memResource in janosvm and the garbage collector. Each team gets a separate garbage collector which handles the brunt of the work, only consulting the memory resource when a new page is needed from the system.

For more details on the Java-level API, see the javadoc documentation for edu.utah.janosvm.resources.MemoryResource and edu.utah.janosvm.resources.MemorySpec.

Class path

The class path for the VM is maintained by the classPathResource which tracks all entries currently available to the VM. Each team is then given access to a subset of these entries in any search order they wish. This makes it possible to determine where the root class loader for each team can get its classes.

For more details see the javadoc documentation for edu.utah.janosvm.resources.ClassPathResource and edu.utah.janosvm.resources.ClassPathSpec.

Name space

The name space resource manages the root Java name space for a team, behaving pretty much like the root name space of a regular JVM, with a few exceptions. First, since the internal data structures for tracking names are separate it makes cleaning up easier since we don't have to worry about removing our team's elements from some global data structure. Second, we allow classes to be mapped from one name space to another, thereby sharing their common data and making it easier to communicate between teams.

For more details see the javadoc documentation for edu.utah.janosvm.resources.NameSpaceResource and edu.utah.janosvm.resources.NameSpaceSpec.

Standard I/O

The standard I/O streams for a team are managed by the stdioResource which allow the team to direct their output to the VM's stdio or to C stdio managed files. Unfortunately, this implementation is basically a kluge to help with debugging and testing, a real implementation would most likely make use of a file system implemented on top of the VM.

For more details see the javadoc documentation for edu.utah.janosvm.resources.StdioSpec.

Adding Resources

JanosVM doesn't support CPU controls or network bandwidth controls simply because in Janos our underlying infrastructure (Moab/OSKit) provides CPU usage and network bandwidth controls. However, adding such support (especially CPU usage control) to the JanosVM could be very useful.

To add a new resource, follow the template provided by an existing resource (the memoryResource is the easiest to follow). Use the "external resource" APIs to add per-team resources in a native support library.

Related Files

Return to the main documentation page.
Copyright (c) 2000, 2001 The University of Utah and the Flux Group.
All rights reserved.

Permission to use, copy, modify, distribute, and sell this documentation for any purpose is hereby granted without fee, provided that the above copyright notice(s) appear in all copies.