A Concurrent Affair

I’m visiting my friend Luke at Purdue after SIGCSE, and we arranged for me to give a talk to the CS department.

If you have the chance, come grill me on Monday, March 15, 2010 at 3:30 PM.

Computer Science Colloquia
Mint: A Multi-stage Extension of Java
Mr. Mathias Ricken
Rice University
LWSN 3102 A/B
Monday, March 15, 2010
3:30 p.m. – 4:30 p.m.

Complete Description:
Abstract:
Multi-stage programming (MSP) provides a safe way of generating code at run-time. In mostly-functional languages like MetaOCaml, this has been used to reduce the performance penalties of abstractions such as loops, recursion or interpretation. The main advantage of MSP compared to other techniques, such as string or LISP quotations, is that MSP guarantees type safety for the generated code statically, at the time the program is compiled.

Unfortunately, MSP is difficult to combine with imperative features found in most mainstream languages like Java. The central problem is “scope extrusion”, which may accidentally move variables outside the scopes in which they are bound, leading to run-time errors in the generated code. This problem can be prevented if code in escapes (or “anti-quotes”) is “weakly separable”, i.e. the computational effects occurring inside an escape that are visible from the outside do not involve code.

We have formalized a type system, based on Lightweight Java, that uses weak separability to prevent scope extrusion, and we have proved that the type system is sound. We have also developed an implementation called Mint to demonstrate the expressivity of the type system and the performance benefits MSP can provide in an imperative setting. Since our implementation extends the Java language, our work is accessible to mainstream programmers.

This talk is based on work will be presented at the Conference on Programming Language Design and Implementation (PLDI 2010). More information is available at http://mint.concutest.org/

Bio:
Mathias Ricken is a doctoral candidate in the Programming Languages Team at Rice University and one of the principal developers of the DrJava integrated development environment. His research interests include concurrent programming, extending the Java language, and computer science education. He is the developer of the Concutest concurrent unit testing framework and has created various experimental extensions of Java to address, for instance, programming with meta-data. Currently, Mathias is contributing to Mint, a multi-stage
extension of Java that allows safe and expressive statically typed program generation and specialization in an imperative language setting.

Faculty and students wishing to speak privately with Mr. Ricken should contact Jan Vitek at jv@cs.purdue.edu.

I’m a bit relieved that the sentence “He also has a weakness for Lady Gaga videos.” was left out of the bio.

I just created a new release of Mint and DrJava with Mint: February 17, 2010 (r15116). The release is available from the Mint implementation page:

• JavaMint-r15116.tar.gz
• JavaMint-r15116-binaries.zip
• drjava-r5178-mint-r15116.jar

There were some small changes in the approximation of weak separability to make the implementation match improvements in the paper more closely. It also disallows stitching in a Code as a statement, because we can’t statically know if we have to discard the result in a statement context or not.

(Re-posted from The Java Mint Blog.)

A few days ago, I changed the Mint compiler to allow non-void code objects to be spliced in where statement form is required:

Code x = <| 1 |>;
Code c = <| { `x } |>;

This essentially generates the code below, which allows the 1 to be discarded:

<| { { Object temp = 1; } } |>;

Eddy pointed out that there is still a problem: Since I do a static type check on the type argument of Code<T>, the proper form cannot be determined if there is a wildcard Code<?>. We can check at run-time whether a code object is in statement form or whether it is an expression whose result needs to be discarded, but we cannot simply write an if-statement, because one of the alternatives would always be syntactically incorrect:

<| { if (c.isStat) { `c; // already in statement form } else { Object temp = `c; // expression, discard result } } |>;

If c.isStat is true, then the else-branch is syntactically incorrect; if c.isStat is false, then there is a syntax error in the then-branch. Eddy pointed out that we can handle the Code<?> case, though, because the two branches are in future-stage code. That is, we can turn

<| { `(c); } |>

into

if (c.isStat) {
<| { `(c); } |>
} else {
<| Object temp = `c; |>
}

Unfortunately, this gets more complicated if there is more than one Code<?> being escaped in. We would have cases, where is the number of Code<?> objects being stitched in:

<| { `(c); `(d); } |>

would have to be turned into

if (c.isStat && d.isStat) {
<| { `(c); `(d); } |>
} else if (c.isStat && !d.isStat) {
<| { `(c); { Object temp = `d; } } |>
} else if (!c.isStat && d.isStat) {
<| { { Object temp = `c; } `(d); } |>
} else {
<| { Object temp = `c; } { Object temp = `d; } |>
}

I think for now I will change the compiler so that escaping a Code<?> in as a statement generates a compiler error. It seems like this is an unimportant corner case, and I don’t want to spend my time on something that is rarely beneficial. Again, this only happens for Code<?>, and only when escaping into bracket with a code block where statement form is required by Java rules.