120 likes | 258 Vues
The Nemesis philosophy aims to expose real resources to applications, particularly those written in Java. This exploration includes the reconciliation of high-level JVM abstractions with actual resource needs, threading, and scheduling. A new thread scheduler dynamically prioritizes tasks based on defined periods and slices, accommodating varying workloads. With policies for runtime compilation and seamless interoperability, developers can manage object placements in a controlled, safe manner during execution. Additionally, extensible virtual machines provide flexible approaches to resource management and safety within the Java environment.
E N D
Problems supporting Java • Part of the ‘Nemesis philosophy’ is to expose real resources to applications • What should be done if the application is written in Java? • Why is Java different from C? • How can the desire to expose real resources be reconciled with the high-level abstractions provided by the JVM? • Even the CPU is virtualized in two ways: (i) processing time is shared between between tasks (ii) applications are written in Java bytecode rather than native code
New thread scheduler • New scheduler expresses CPU requirements as: • Period & slice • Extra time flag • Can accommodate a variety of tasks, eg: • 30% every 1ms ¾ interactive program • 5% every 100ms ¾ background task • extra time only ¾ unimportant task • Extra time is shared out according to priority hints
Run-time compilation • Provide mechanisms which allow the programmer to control the compiler and to implement their own policy. For example: • Compile quickly on first invocation • Compile with maximum optimization • Compile in the background • Never compile • Provide a selection of default policies
Interoperability • The aim is to be able to invoke operations on interfaces from the Nemesis environment without having to create native methods • Two components: • A new Java binding for the MIDDL interface definition language • Run-time support for allowing invocations
Extensible virtual machines • Policy decisions can often be separated (safely) from implementation mechanisms • Thread scheduling • Object representation • Primitive operations • Run-time code generation • One size does not fit all
Motivating example • Object placement in the heap • Safety requires the objects are stored in correctly-sized blocks of memory that are not already in use • May wish to control • Where instances of different classes are stored • Where instances allocated by different threads are stored • Which free block is chosen, if there is a choice • When the heap is expanded and when collection occurs
Prototype XVM design > > Machine A Machine B Interface Instance of code module Operations available to application < Machine C > > >
Ensuring safety • At a coarse level, the selection of implementation machines and pre-defined modules available can be limited • At a finer granularity, modules provide descriptions of their verification-time behavior in addition to their concrete implementation
Demonstrations Thread scheduler control interface Unmodified X-windows clients Telnet client
Contact details tim.harris@citrix.com http://www.cl.cam.ac.uk/~tlh20