WP 3 DSM Runtime System

The major goal of this workpackage is to develop the CloudDSM runtime system, which is responsible for implementing the low level behavior of the shared memory abstraction. It manages the shared data, and controls access to it. To accomplish this, it tracks the access rights granted to units of work (IE tasks or threads) that reside on particular machines. When work requests rights to a given region of shared addresses, the runtime controls the granting of those rights. It may suspend the work, wait for a different work unit to give up ownership, then move the updates to the machine where the requesting work unit resides. Thus, the DSM runtime manages granting and tracking of ownership of regions of addresses, moving updates to the address regions between machines, and manages suspend of work until movement completes.

WP 2, the CloudDSM portal, will interact with the DSM runtime. The portal sends commands to the runtime to start work on behalf of applications. The runtime sends back updates to the portal regarding machine usage consumed by the commands. The portal also tells the Cloud stack when to suspend particular VMs, due to the DSM runtime inside the VM being in a busy-wait loop. This happens when a particular VM is waiting for results to be completed inside a different VM, and so is only in a busy-wait loop constantly polling for completion of the other VM.

WP 5, the transform tools, insert calls to the DSM API, as part of the transforms that they perform. In this way, the end developer, as in WP 7, uses a highly productive set of annotations/DSL, which are then transformed by WP 5 tools, into calls to WP 3's DSM runtime system.

  • Task1: participate in rapid prototyping process, together with members of WP 2 -- portal, WP 4 -- low level annotations, WP 5 -- transform tools, and WP 7 -- end application, to together get a minimum viable system up and running. This will create a high degree of communication between partners early in the project, to uncover hidden assumptions, develop shared ideas about approach, define clean interfaces and interactions between partners, workpackages, and deliverable pieces, and increase the smoothness and pace of progress for the rest of the project.
  • Task2: Architecture of hierarchical DSM runtime system. Delivered runtime will be a federation. On each virtual machine, or in some cases physical machine, an individual runtime system will be in operation. Each of these individual runtime systems will interact with the others to form a collective, cooperative, overall runtime system, which presents a single address space abstraction. This task will define the architecture, interfaces, and protocols for this overall runtime system. Then for each class of hardware an individual task will implement the interfaces and protocols for that particular kind of hardware, as described below.

-- Sean leads task, partners for 2 through 6, plus Imperial, plus INRIA, plus XLAB participate on aspects that involve their individual piece. INRIA will advise on how the architecture choices impact the toolchain design and implementation. Imperial will advise on how the choices impact the algorithms for runtime work division and deployment. XLAB will advise on how the architecture impacts the portal. Sean and IBM will provide input on how the architecture impacts the individual runtime system they are implementing. 

  * Milestone   M3.: Month 9 -- architecture and API of DSM runtime delivered, based on experience gained in the rapid prototype development done in WP 2 and WP 6
  * Deliverable D3.: Month 9 -- deliver document detailing architecture and API of DSM runtime  
  * Milestone   M3.: Month 24 -- 
  * Deliverable D3.: Month 24 --  
  * Milestone   M3.: Month 36 -- 
  * Deliverable D3.: Month 36 --
  • Task3: DSM runtime system on a shared memory x86 based Cloud server instance -- Sean with involvement by XLAB and Gigas
    • Milesttone M2.: Month 12 --
    • Deliverable D2.: Month 12 -- simple, first prototype working inside rapid prototype created in WP 2.
    • Milestone M2.: Month 24 --
    • Deliverable D2.: Month 24 --
    • Milestone M2.: Month 36 --
    • Deliverable D2.: Month 36 --
  • Task4: DSM runtime system on a shared memory Power based Cloud server instance -- IBM plus Sean with involvement by XLAB and Gigas
    • Milestone M2.: Month 12 --
    • Deliverable D2.: Month 12 --
    • Milestone M2.: Month 24 --
    • Deliverable D2.: Month 24 --
    • Milestone M2.: Month 36 --
    • Deliverable D2.: Month 36 --
  • Task5: Integration testing. Deploy the various individual runtime systems on specific machines. Write test cases whose purpose is to expose performance issues and bugs. Execute the test cases, record the performance, report to the partners who developed the individual runtimes in tasks 2 through 6. Work with the partners to determine the reasons for particular performance anomalies, perhaps writing and running specific tests interactively. The partners for 2 through 6 will use the results to modify their individual runtime system implementations. -- Gigas leads -- partners for 2 through 6, plus XLAB are involved.
    • Milestone M2.: Month 12 --
    • Deliverable D2.: Month 12 --
    • Milestone M2.: Month 24 --
    • Deliverable D2.: Month 24 --
    • Milestone M2.: Month 36 --
    • Deliverable D2.: Month 36 --
  • Question: "Is the runtime going to be virtualized itself? Why not use standard bytecodes?" A: There won't be any bytecodes. CloudDSM is focused on high performance, and so the DSM runtime for many of the machines will be based on proto-runtime, due to its high performance and productivity benefits. Proto-runtime creates the equivalent of user-level "threads", which are called virtual processors because they capture a CPU context, and a CPU context virtualizes the bare processor pipeline. One of these VPs consists of its own stack, plus a data structure that holds a saved stack pointer, frame pointer, and program-counter contents. That set of state equals a point within the CPU's computation, and it can be used to switch the CPU around among different computation timelines. Each of those timelines behaves like its own, virtual, CPU processor pipeline.. hence, the name "virtual processor". But it's the lowest level, most bare bones "virtualization" possible.. there is no bytecode, no translation between ISAs, nothing but multiple CPU contexts.