Overview

Squawk is an open source research virtual machine for the Java language that examines better ways of building virtual machines.  Most commercial virtual machines are written in low level languages such as C and assembler.  We believe that virtual machines can be simplified by writing them in in higher level languages, and further simplified by implementing the VM in the language that the VM is implementing.

Squawk has been open sourced and is hosted at http://squawk.dev.java.net, where you can get access to all of the source code and the community and forums focused on the Squawk Project.

The main goal of the Squawk project is to write as much of the virtual machine as possible in Java, for portability, ease of debugging, and maintainability. Squawk aims at a small footprint, it is Java compliant, and is CLDC 1.1-compatible.  Squawk is meant to be used in small, resource constrained devices.

At present, there are two different embedded deployments of the Squawk VM, namely, the very small footprint Java Card market and the wireless sensor and actuator device Sun(TM) SPOT:

• Squawk for Sun SPOT (2004-present)
• Squawk for Java Card 3.0 (2002-2003)

In addition, the Squawk VM runs on Solaris (SPARC & x86), Windows, Mac OS X (PPC & x86), and linux systems.

Architecture

The architecture of the Squawk VM was inspired in part by the Squeak and Klein VM architectures. In particular, it is (mostly) implemented in the language that it executes (Java).

Features of the Squawk architecture include:

• A compact bytecode instruction set

  • Smaller than standard bytecode (35% - 45% size of equivalent J2ME class files)
  • Fixed up/pre linked
  • Immutable ==> execute in place
  • Simplified garbage collection:
    • local variables are partitioned into pointers and primitives ==> only one pointer map per method
    • there is nothing on evaluation stack at operations that may result in an invocation ==> no need to statically interpret methods during GC

• Suites

  A suite is a collection of classes. Each class in a suite only refers to other classes in the suite or to a class in a parent suite. That is, a chain of suites is a transitive closure of classes as shown below:

  

  The representation of classes in a suite is very compact as they are all prelinked to each other. On average, suites are one third of the size of class files.

• Split VM

  Squawk supports using a split VM architecture in order to save memory on-device.

  

  The host machine verifies, optimizes, and transforms the the application classes into Squawk's internal object representation, which is then saved into a suite. Suites are then loaded into the embedded device and are interpreted by the VM on-device.  This allows for a smaller VM to be stored in the embedded device, as well as faster start-up time for the embedded application.

• Isolates

  An isolate is a mechanism by which an application is represented as an object. In Squawk, one or more applications can run in the single JVM. Conceptually, each application is completely isolated from all other applications. Given the immutability of suites, the isolate implementation in Squawk shares common suites between applications. This can significantly reduce the memory footprint of each application, which is particularly important in the embedded device space.

  Squawk supports most features of the JSR 121 Isolate standard. The major ommisions are related to inter-isolate communications - Squawk uses a simpler, less restrictive model than the standard Links API.

  In addition to the standard semantics of isolates, Squawk implements isolate migration. That is, an isolate running on one Squawk VM instance can be paused, serialized to a file or over a network connection and restarted in another Squawk VM instance. This feature is a direct result of certain architectural choices made in Squawk such as using a green threaded model, representing all VM structures (including thread stacks) as objects and not implementing a general native code interface such as the JNI.

• VM Components

  The VM components include:

  • The class loader/bytecode translator
  • The ahead-of-time bytecode optimizer
  • The threading system (green threads)
  • The garbage collectors (selected at build time):
    • Simple two space Cheney collector
    • Mark/compact "Lisp2" collector
    • Generational mark/compact "Lisp2" collector

  Squawk's design includes a compiler that can be used to:

  • compile the core VM components ahead-of-time
  • compile an interpreter written in Java ahead-of-time
  • compile other Java components ahead-of-time
  • compile bytecodes just-in-time (JIT compilation)

  The general Squawk compiler is not complete, but limited ahead-of-time compilation of Java components such as the garbage collector is supported.

Current Plans

• Implement Real-Time support in Squawk, starting with a sub-set of the RTSJ (Real-Time Specification for Java).
• Implement technology transfer plan, including:
  • Open Source.
    • Done! See https://squawk.dev.java.net/
  • Business licensing.
• Execution Engine enhancements, which may include interpreter rewrite, AOT-compilation, and byte-code optimizations (inlining, etc).
• Continue SPOT support, fixing critical bugs
• New SPOT-requested features.

Publications/Presentations

• Squawk: Enabling Java(TM) on Small Devices, Eric Arseneau, Sun Labs Open House, 2007 (slides)
• Java(TM) on the Bare Metal of Wireless Sensor Devices -- The Squawk Java Virtual Machine, Doug Simon, Cristina Cifuentes, Dave Cleal, John Daniels and Derek White, VEE, Ottawa, July 2006
• Simplified Development of Wireless Sensor and Actuator Applications Using Java(TM) Technology, Cristina Cifuentes, Eric Arseneau, Derek White, David Simmons, Slides for the JavaOne 2006 Hands-on Lab 7160, San Francisco, May 2006 (slides)
• Squawk: A Java(TM) VM for Wireless Sensor and Actuator Devices, Cristina Cifuentes, Derek White and Eric Arseneau, JavaOne 2006 Technical Session 1598, San Francisco, May 2006 (slides)
• The Squawk Virtual Machine: Java(TM) on the Bare Metal, Doug Simon and Cristina Cifuentes, Extended abstract, OOPSLA, San Diego, October 2005
• The Squawk Java(TM) Virtual Machine: Java on the Bare Metal, Doug Simon and Cristina Cifuentes, OOPSLA Poster, San Diego, October 2005
• Java(TM) on Sensors, John Nolan and Cristina Cifuentes, Slides for the Sun Labs Open House, April 2005
• Squawk - A Java VM for Small (and Larger) Devices, Cristina Cifuentes, Slides for the IFIP WG 2.4 Meeting, Jan 2005.

Collaborations

• The Sun SPOT project
• Writing Solaris Device Drivers in Java, Hiroshi Yamauchi and Mario Wolczko. Technical Report #156, June 2006.

History

Past members of the Squawk team include Nik Shaylor, Doug Simon, Cristina Cifuentes, Bill Bush, John Nolan, John Daniels, Dave Cleal, Duncan Pierce, Alex Garthwaite, Rachel Davies, John Wilcox, Ivan Moore

Past interns: Jean-Francois Im, Martin Morissette, David Liu, Simon Long, Erica Glynn, Andrew Crouch.