... Bytecode¹

This research is partly supported by FCAR, NSERC, and Hydro-Québec.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... bytecode²

In this document, the term Java means: the Java programming language.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... more.³

There exist static compilers that directly compile Java programs to machine code (e.g. [2,3,7]). The constraints of static and dynamic environments are quite different. Our research focuses on dynamic Java execution environments.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... interpreter⁴

SableVM depends on the open-source GNU Classpath[1] class library for providing standard library services.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... entirely⁵

Exceptions: We assume a POSIX system library, we use label as values (see Figure 2(b)), and there is a single line of assembly code (compare-and-swap).

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... memory⁶

On some processors, this technique requires one line of assembly code to synchronize the instruction and data caches.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... tables⁷

See section 6.2.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... index⁸

In reality, we use a decreasing index, starting at at -1, to allow direct indexing in the interface virtual table.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... header⁹

Only 24 bits of that word are used for locking on 32 bit systems. 8 bits remain free for other uses.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... object¹⁰

Unlike Agesen's recent meta-lock algorithm[9] which requires an atomic operation for unlocking objects.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... threads¹¹

This is a simplified description. Please refer to the original paper[26] for details.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... lock¹²

The contention lock is a simple non-recursive mutex.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... inflated¹³

Notice that thread $y_t$ necessarily owns the lock of object $z_o$, as a only one lock (on object $b_o$) has been released by thread $y_t$ since it last cleared its contention bit and emptied its tuple list.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.