X10

X10 is what happens when a very large research budget is pointed at a very specific complaint. In the early 2000s, supercomputers were getting faster while the experience of programming them - Fortran or C, plus MPI, plus threads, plus a great deal of hand-managed data distribution - was getting worse. DARPA’s High Productivity Computing Systems programme funded three vendors to do something about it, and the three languages that came out of it were Cray’s Chapel, Sun’s Fortress, and IBM’s X10. The name is the goal: a ten-times productivity boost. (The project’s own FAQ, asked “Don’t you know that X10 is the name of an industry-standard communications protocol?”, answers: “Oops. C’est la vie. Next question, please.”)

The language that resulted looks, at first glance, like a slightly unfamiliar Java. What makes it X10 is a handful of keywords:

1
2
3
4

finish for (p in Place.places()) {
    at (p) async Console.OUT.println(here + " says hello");
}
Console.OUT.println("Goodbye");

That is a complete distributed program. at (p) moves execution to place p, async spawns a lightweight activity there, and finish waits for every activity spawned anywhere inside it - transitively, across the whole cluster - before the last line runs. Four constructs, orthogonal, arbitrarily nestable. IBM called the resulting model APGAS: the Asynchronous Partitioned Global Address Space.

History and Origins

February 2004

Work on X10 began in February 2004, at IBM’s Thomas J. Watson Research Center, as the language component of PERCS - Productive, Easy-to-use, Reliable Computing System. PERCS was IBM’s HPCS project, a hardware-software co-design effort that eventually produced the Power 775 supercomputer, and the OOPSLA'05 paper describes X10 as a “big bet” within it: the project’s stated aim was to deliver, by 2010, a tenfold improvement in development productivity for parallel applications, and the language was expected to carry a large share of that.

The first public appearance was an extended abstract - “X10: Programming for hierarchical parallelism and non-uniform data access”, by Kemal Ebcioğlu, Vijay Saraswat and Vivek Sarkar - at the Language Runtimes workshop co-located with OOPSLA 2004 in October. The surviving source repository opens on 25 September 2004. A draft language report was written early - the OOPSLA'05 paper records that the team had “defined the 0.41 version of the language (and written the Programmers’ Manual)” by then - and the paper is still explaining array typing rules by reference to “X10 v0.41”.

The Five Decisions

The 2005 paper is unusually candid about how the design was fixed, listing five decisions taken at the start of the project:

1. Introduce a new language, rather than a library or a set of directives.
2. Use Java as the starting point for the serial subset - explicitly for the ecosystem, and because a memory-safe, garbage-collected, statically typed base rules out entire classes of HPC bug by construction.
3. Introduce a partitioned global address space with locality reified as places.
4. Make dynamic, asynchronous activities - not processes, not SPMD threads - the foundation of concurrency.
5. Include a rich array sub-language for dense and sparse distributed multi-dimensional arrays.

Four goals sat behind them: safety, analyzability, scalability, and flexibility. The paper also records a methodological commitment - “Build early. Build often. Use what you build” - and admits that it forced the team to abandon an initial plan for a sophisticated static type system that would decide whether an activity was accessing local or remote data, in favour of dynamic checking under what X10 calls the Locality Rule.

The Productivity Study

The OOPSLA'05 paper backs the productivity claim with a measurement rather than an assertion, and it is worth stating with its context because the numbers are modest and specific. The authors took eight benchmarks from the Java Grande Forum Benchmark Suite, and measured code size - non-comment non-blank source lines (SLOC) and syntactic statement count (SSC) - across serial, parallel and distributed versions of each.

Parallelising the Java versions cost roughly 24% extra code for the multithreaded form and roughly 21-22% for the MPI form; since the two are orthogonal and the suite contains no combined version, the paper estimates the combined cost at around 45%, with a “change ratio” - the extent of code disturbed, not merely added - of roughly 73%. The equivalent multi-place multi-activity X10 versions grew by 4% to 7%, with a change ratio of roughly 15-23%. All the X10 versions were executed and validated on the reference implementation. The claim is narrow - it measures editing effort on one benchmark suite, not developer time or correctness - but it is the sort of claim that can be checked.

Design Philosophy: APGAS

Classical PGAS languages - Titanium, Unified Parallel C, Co-Array Fortran - give every processor a single global address space partitioned into local pieces, and run in SPMD style: every process starts executing the same program. X10 kept the partitioned address space and threw away the SPMD control flow. An X10 program begins with one activity, in the root place, and grows.

Places. A place is a collection of non-migrating mutable data plus the activities operating on it; in practice one operating-system process, typically one per cluster node. An activity may only directly touch memory in its own place. It can name a location in another place, and the runtime maintains the mapping, but it cannot silently dereference it.

That last restriction is the design’s sharpest edge, and the paper defends it directly. In other PGAS languages, given a reference p, you generally cannot tell by reading p.x whether the access will cross the network; the paper calls this “a productivity bottleneck for performance tuning”. In X10, every non-local access is syntactically visible, because it has to be wrapped in an at.

async. async S starts a new activity running S. Activities are designed to be far cheaper than OS threads and are executed by a work-stealing pool per place, whose initial size is set with X10_NTHREADS.

finish. finish S waits for every activity transitively spawned during S. Because a child can never wait on its parent, and joining always happens through finish, X10’s task graph has a structure that rules out large families of deadlock by construction. This is one of the clearest early statements of what is now called structured concurrency.

atomic and clocks. atomic S executes S as if in a single step, with respect to the current place only. The project’s FAQ is refreshingly blunt about the cost: “the X10 atomic keyword is an extremely heavy hammer: it grabs a lock that serializes all atomic operations in a Place. Usually, atomic should be used for prototyping, but it will probably not scale well in highly contended code.” For phased computation, X10 offers clocks - generalised barriers that need not be global, that a dynamically varying set of activities can register with, and whose usage restrictions were designed to let a compiler verify deadlock-freedom.

Two Backends

The compiler is built on the LPG parser generator, the Polyglot extensible compiler framework and the WALA analysis libraries, and it emits source, not machine code:

Much of the X10 runtime is itself written in X10. Official pre-built binaries over the 2.x era covered Linux on x86, x86-64 and Power; macOS on x86 and x86-64; AIX on PowerPC (earlier releases); Windows via Cygwin, with Managed X10 eventually running on Windows without it; and BlueGene/Q from 2.4.0, with BlueGene/P support dropped at 2.4.2. GPU support went through the native backend and the NVIDIA CUDA toolkit and was always built from source. The final 2.6.2 release publishes binaries for Linux/x86-64 and macOS/x86-64 only. An Eclipse-based IDE, X10DT, tracked the compiler throughout; a separate X10 debugger existed for 2.2 and was never updated past it.

Evolution

X10 revised itself continually, and not gently. The release notes read as a sequence of deliberate breakages in pursuit of a better language:

• 2.0 (2009) added structs - headerless inlined aggregates, so a Complex need not be an object - removed the older Value construct entirely, added static place type checking and unsigned integral types.
• 2.1 (2010) reworked the distributed object model to make single-place programming simpler without weakening multi-place programming, and folded the common cases of clock usage into finish/async.
• 2.2 (2011) deleted variance annotations on type parameters, method and operator functions, and the next/resume keywords, and closed 462 issues doing it.
• 2.3 (2012) removed the mandatory x10.lang.Object root class from the language, and brought back checked exceptions and throws clauses to align the hierarchy with Java’s.
• 2.4 (2013) is the one that broke the most code, and said so: arrays were redesigned and unqualified integer literals changed their default type from Int to Long, so that 64-bit addressing and Long-indexed data structures became the natural way to write X10 rather than an annotation burden.
• 2.4.1 through 2.5.4 (2013-2015) are the Resilient X10 era. Resilient X10 lets a program observe the failure of a place and carry on; Elastic X10 lets the set of places change during execution, which required deleting long-standing constants like Place.MAX_PLACES and PlaceGroup.WORLD from the standard library.
• 2.6 (2016) added user-defined control structures and trailing closures, and then the language stopped changing.

Petascale

The most-cited performance result is the PPoPP'14 paper “X10 and APGAS at Petascale”. Eight application kernels were weak-scaled on an IBM Power 775 using up to 55,680 Power7 cores, a configuration with 1.7 Pflop/s of theoretical peak. For the four HPC Class 2 Challenge benchmarks, the paper reports achieving 41% to 87% of the system’s potential at scale, and claims the first implementation of Unbalanced Tree Search to scale to a petaflop system, alongside K-Means, Smith-Waterman and Betweenness Centrality. The numbers are weak-scaling numbers on one machine that no longer exists, and they measure a research runtime rather than a production one - but they are reported with their hardware, their benchmark set and their percentage-of-peak baseline, which is more than most language performance claims manage.

The visible high point came a little earlier. At SC'12 in November 2012, X10 won the HPC Challenge “Best Performance” award in the Class II competition - the class that judges elegance alongside speed - with Global HPL, Global RandomAccess, Global FFT and Unbalanced Tree Search running on the PERCS machine at 32,768 cores.

Current Relevance

X10 is dormant, and unambiguously so. The last release, 2.6.2, shipped in January 2019 and contained no new language features at all - only the work needed to keep the existing language compiling on Java 11 and running on then-current macOS. The last commits to the core repository are dated February 2020. The X10 Workshop series, which ran annually alongside PLDI from 2011, ended with X10'16 in Santa Barbara in June 2016. Commit volume tells the same story from the other end: 4,193 commits in 2010, 334 in 2016, seventeen in 2017.

Everything is still there. The compiler, runtime, class libraries, test suite, benchmarks and Global Matrix Library remain on GitHub under the Eclipse Public License; x10-lang.org is still online; 2.6.2 binaries for Linux and macOS are still published. What is gone is the funding and the people. DARPA’s HPCS programme ended, IBM’s Blue Waters contract was terminated in August 2011, the Power 775 had a short commercial life, and the researchers dispersed.

The ideas did better than the language. IBM extracted the model into a standalone APGAS library for Java (1.0.0, March 2015), with a Scala version alongside it (February 2016), so that async, finish and at could be used without adopting a new compiler. Habanero-Java, the Rice University effort led by X10 co-designer Vivek Sarkar, was derived directly from X10 v1.5 - its paper is subtitled “the New Adventures of Old X10” - and extended X10 clocks into phasers. And a restricted form of phasers landed in the Java standard library: the source of java.util.concurrent.Phaser describes itself as implementing “an extension of X10 ‘clocks’”, crediting Saraswat for the idea and Sarkar for extending it. Millions of Java programmers have a piece of X10 on their classpath without knowing it.

Why It Matters

Of the three HPCS languages, Fortress was discontinued, Chapel continues at HPE, and X10 sits between them: an implementation that has wound down around ideas that got out.

It named and popularised APGAS. Adding asynchrony to PGAS - lightweight tasks rather than one-thread-per-processor, spawned dynamically, joined structurally - is X10’s distinctive contribution, and the vocabulary has outlasted the compiler.

async/finish is structured concurrency, in 2004. The rule that a finish block does not complete until every task spawned inside it has completed, transitively, is now a mainstream idea with a mainstream name. X10 had it, formalised it, and built deadlock-freedom arguments on it, more than a decade before it became fashionable.

It made communication visible. Requiring at for every non-local access was unfashionable - it makes X10 programs wordier than their UPC equivalents - but it means a reader can find every network round-trip by grep. That trade, visible cost over transparent convenience, is one the distributed-systems world has since largely come around to.

It proved a high-level language could scale. The SC'12 award and the petascale paper demonstrated that a garbage-collected, statically typed, object-oriented language could run competitive benchmarks on tens of thousands of cores. The argument that HPC must mean hand-tuned C and MPI got measurably harder to make.

And it is a case study in how research languages end. Nothing about X10 failed technically. It simply outlived the hardware programme that paid for it, and a language whose reason to exist is one vendor’s supercomputer inherits that machine’s lifespan. The compiler still works; the cluster it was built for does not.

For the release where the language shed its Java skin and became recognisably itself, see the separate page on X10 1.7.