Synchronous Messages

The other day I wrote an entry about using bind/trigger on a local variable and what can go wrong if you do this. But why would somebody want to do such a thing? Isn’t this just an obscure corner of the language with a curious behavior?

It turns out that this example came up in actual code, and it caused us quite a debugging headache.

Take a look at the HttpRequest class. It has a fairly complicated state machine. The current state of the object is visible both through state variables (started, connecting, doneConnect, etc.) and also through a series of callbacks (onDone, onConnecting, onDoneConnecting, etc.). Strictly speaking, these are redundant. An earlier version of this API didn’t have the callback interfaces. I’m not completely sure why, but I think that callbacks (like listeners) were viewed as a Java-like construct, and the designers of the API wanted an interface with more of a JavaFX-Script flavor. This is completely understandable; the shape of an API is intimately intertwined with the mechanisms and constructs available in the language.

In Java, writing a class with public fields is poor style. It allows uncontrolled writes to the field, and there is no way for anyone — neither the client nor the class’s implementation — to detect when such a field has been modified. Instead of exposing a field, you have to provide a getter and setter methods. If you want a client to be notified when your object’s state changes, you have to set up a listener of some sort. It’s very common to for classes to use listeners to notify clients of state changes. This has led to a proliferation of listener interfaces in the class library, which in turn has led to a proliferation of little listener methods in client code. Most listeners are very small. They usually just copy a value or call an update method. If you have a one-line listener, it requires half a dozen lines of inner class boilerplate and a fair number of confusing braces and parentheses. I think this has contributed quite a bit to Java’s reputation as a verbose language.

For example, in Java, if you have a Rectangle rect that you want always to be 50 pixels over and 100 pixels down relative to the location of otherRect, you’d do something like this. (This doesn’t correspond to any actual Java class, but you can see the point.)

otherRect.addStateChangeListener(
    new StateChangeListener() {
        public void stateChanged(Rectangle otherRect) {
            rect.setLocation(otherRect.getX() + 50, otherRect.getY() + 100);
        }
    }
);

By contrast, in JavaFX Script, an object’s variables can be made read-only to the general public using the public-read access modifier. Furthermore, clients can detect changes to another object’s variables by using the bind mechanism. This leads to style of object coupling where objects expose state via publicly-readable variables, and where clients bind to them in order to pick up state changes. Binding works great if your object’s state variables are updated as a function of some other object’s state variables. The rectangle location updating code would look like this in JavaFX Script:

var rect = Rectangle {
    x: bind otherRect.x + 50
    y: bind otherRect.y + 100
}

This is really cool. I think we’d all agree that the JavaFX Script example is much more concise, powerful, readable, and understandable. Great!

The problem is that, while bind works well when updating values as functions of other values, it doesn’t work so well when you want to take action (that is, perform a procedure) upon certain state changes. Let’s imagine that the HttpRequest object had no onInput callback (as was the case in the past). When the request body becomes available, the input field of the HttpRequest object is set to an InputStream from which the data can be read. In this style of API, instead of callbacks, clients of the HttpRequest class are expected to use bind to detect state changes. Let’s try to write some code that does this.

We want to bind to the request’s input field… but bind can only appear as the initializer of a variable declaration, or as the initializer within an object literal. So we’ll have to cook up another variable upon which to hang the bind:

var req = HttpRequest { ... };
var xyz = bind req.input;

This doesn’t do us much good; all it does is update the xyz variable when req.input changes from null to a valid InputStream. Recall that a bind expression causes re-evaluation of the portions of an expression that are affected by a change to a bound value, including function calls if a bound value is a parameter to a function. So we could try something like this:

var req = HttpRequest { ... };
var xyz = bind handleInput(req.input);

function handleInput(is: InputStream) {
    ...
}

This doesn’t really work, however. We have to return a value from the handleInput() function, and this has to match the type of the xyz variable. But this value is essentially unused and is merely a distraction:

var req = HttpRequest { ... };
var xyz: Boolean = bind handleInput(req.input);

function handleInput(is: InputStream): Boolean {
    ...
    return true;
}

You can leave off the Boolean type declarations on xyz and for the return value of handleInput(), because the compiler will infer the proper type. Still, it’s a bit clunky that you have to declare a useless variable and return a useless value from the handleInput() function.

Isn’t there a better way? There sure is. JavaFX Script has a trigger mechanism (which is spelled on replace) that allows some arbitrary code to be executed when a variable’s value changes. If we were to use a trigger, it would look something like this:

var req = HttpRequest { ... };
var input = bind req.input on replace {
    // read from input here
};

This is quite a bit better. We don’t have to cook up a function with a new name, and we don’t have to declare a useless variable and return a useless value from our function. The on-replace code is tied directly to the new variable, the one that’s bound to the variable we’re interested in. This is pretty concise and powerful.

I’m starting to see this idiom pop up in a lot of code. It’s useful under the following circumstances: a) you want to write code that’s triggered on a readable variable in another object, and b) that other object doesn’t provide a callback function or listener. Ideally, in some sense, you’d want to install a trigger on the variable in the other object. But you can’t do that: you can only install a trigger at the declaration of a new variable. So, you have to declare a new variable of your own, use bind to copy the value of the other object’s variable, and use an on replace trigger to have your code run when the other object’s variable is updated.

This technique reminds me of the Introduce Foreign Method refactoring, where you can’t add a method to another class, so you add it outside and treat it idiomatically as if it were a new method on that class. I’ll therefore call this technique the foreign trigger idiom.

This is all sort-of moot now, since my example is based on the older version of the HttpRequest API that didn’t have callbacks. As of 1.0, the HttpRequest has callbacks, so instead of using a foreign trigger you’d just supply a function as the value of the onInput variable of HttpRequest. But there’s still a need for foreign triggers in other parts of the API. Consider the Image class. This class allows images to be loaded in the background, by setting the backgroundLoading variable. How can you tell when the image is done loading? There’s no callback function, but the progress variable is updated and reaches 100 when the image is finished loading. So you could do something like this:

var img = Image {
    backgroundLoading: true
    ...
};
var progress = bind img.progress on replace {
    if (progress == 100) {
        // take action now that img is done loading
    }
};

You can see this idiom in use in various JavaFX samples, such as the one here.

All well and good. But what does this have to do with the stuff I was talking about earlier, regarding the lifetime of local variables?

If you’re writing a simple script, you typically tend to declare your variables at top level. These variables live as long as your script is running, and objects they refer to aren’t garbage collected for the lifetime of your application. So the foreign trigger idiom works perfectly well for these cases.

Now suppose you’re writing a program where HttpRequest operations are performed repeatedly. For example, you might want to fetch all the photos in a particular photo set, or you might want to fetch all the calendar entries for each day of the month. Clearly, you don’t want to declare separate variables for each of these requests. You’d want to wrap things up in a function, and have this function called repeatedly as often as necessary. The code would look something like this:

function getEntryForDate(date: Date) {
    var req = HttpRequest { ... };
    var input = bind req.input on replace {
        // process input and convert to a calendar entry
    }
}

BANG! Can you see the bug? If not, look again!

The problem is that the trigger was declared on a local variable, and this local variable is subject to garbage collection. This code sometimes works and sometimes doesn’t work. In fact, this is the most insidious kind of bug. You can take the code and isolate it into its own script (using script-level variables) and it will work perfectly. If you use the function as-is and call it from a simple test program, it will almost always work. That’s because in a simple test program, not much else is going on, and GC probably won’t occur. But put this into a big application, and call it 30 times to get all the appointments for a month. GC happens, and suddenly and randomly your triggers stop firing.

The consequences are fairly dire for HttpRequest, since it requires the InputStream to be closed to indicate that processing of the request has been completed. This processing is usually handled by a trigger, but if the trigger is GC’d, processing of the request never completes. The HttpRequest implementation has a limit on the number of outstanding requests. Eventually the pending request limit will be reached, no new requests will be issued, and the system will grind to a halt. We tore our hair out for about a week until we figured out what was going on.

Since the foreign trigger idiom is so common, and since it’s so easy and dangerous to use it on local variables, I’ve filed a bug (JFXC-2168) on this problem. The solution isn’t obvious. There’s some discussion about potential solutions in the bug report.

Moreover, the problem isn’t confined to local variables. If you use the foreign trigger idiom on an object’s variables, you have to make sure the object itself doesn’t get garbage collected. If you don’t keep a reference around to the object in question, it’s liable to get collected itself along with your trigger, and you end up with exactly the same problem. More on that later.

In my previous entry, I mentioned that binds and triggers could extend the lifetime of local variables. This is incorrect. I think what’s really happening is that local variables aren’t destroyed immediately when their defining scope exits; they can continue to live for an arbitrary period of time. In a language like Java, you cannot observe anything about a local variable after its scope has exited, since there’s no way to name it or to create a reference to it. So, you can’t tell whether the variable has been destroyed immediately or whether it sticks around. However, in JavaFX Script, you can observe a local variable after its scope has exited. Consider the following example.

var v = 0;
function f(p: Integer):Void {
    var localvar = bind p + v on replace old {
        println("localvar: {old} => {localvar}");
    }
}
f(17);
f(32);
println(">>> increment v");
v++;
println(">>> increment v again");
v++;
println(">>> done!");

If you compile and run this program, the output is:

localvar: 0 => 17
localvar: 0 => 32
>>> increment v
localvar: 17 => 18
localvar: 32 => 33
>>> increment v again
localvar: 18 => 19
localvar: 33 => 34
>>> done!

(Note that the trigger fires the first time, when the variable is initialized from its default value of zero to the value of the expression in its initializer.)

Like the previous example, this shows that there are two distinct local variables named localvar that have been created by the two calls to function f. Normally after f returns, there’s no way to observe localvar. However, since it’s been initialized to a bind-expression that uses an external variable (v in this case), we can change its value by manipulating that external variable. Furthermore, we can observe changes to the value by attaching a trigger (“on replace”) expression that has the side effect of printing a message. Pretty cool, eh?

Well, maybe. The problem is that although we can observe localvar by placing a trigger on it, there is nothing external that references it. This seems pretty fragile, since things that don’t have references to them are subject to being garbage collected. Let’s test this by allocating a bunch of memory to force GC. Just before “increment v again” insert the following code:

var seq: String[];
for (i in [1..50000]) {
    insert "{i}" into seq;
}

(Your mileage may vary. On my system, a loop of 50,000 causes GC every time.) If you run the program again, the output is as follows:

localvar: 0 => 17
localvar: 0 => 32
>>> increment v
localvar: 17 => 18
localvar: 32 => 33
>>> increment v again
>>> done!

What just happened? This is quite odd. In Java, the only way to observe anything about an object is to have a reference to it, and having a reference will prevent it from being collected. In JavaFX Script, we can place a trigger on a local variable in order to observe changes to its value, and we can change its value by virtue of having initialized it with a bind-expression. But we don’t actually have any references to it, so the variable, the bind-expression, and the trigger are all subject to garbage collection!

This is admittedly a pretty obscure corner of the language. Why would anybody want to put a bind and a trigger on a local variable? In my next blog post, I’ll explain why this construct has come up repeatedly in real programs, how the GC issue has caused problems, and what to do about it.

UPDATE: followup post is here.

By “extent” I mean, how long do local variables exist?

In languages such as C, C++, and Java, local variables are destroyed as soon as you leave the scope in which they’re declared. If a function or method has a local variable, each time you call it, you get a different variable with the same name each time. In C and C++ you can try to do stuff like reusing the variable without initializing it, or returning its address, but the results of doing so are undefined and give incorrect programs.

C++ provides for somewhat stronger behavior for local variables that are objects, in that the object’s constructor is called when the scope is entered and the destructor is called when the scope is exited.

Java has similar rules, but the abstraction is much stronger. You can’t take the address of a local variable, nor can you attempt to use a local variable before initializing it — it’s a compiler error. You can try to “hang on” to a local variable by using it within an anonymous class, but the language requires that such locals be declared final. (I’m not entirely sure why; I think it allows the implementation to copy the value somewhere else so that all the locals in the method scope can be destroyed.)

In JavaFX, local variables can hang around for an arbitrary length of time. One way of doing this is by creating an inner function that references the outer function’s local variable. This creates a “closure,” that is, a closed environment that contains the local variables that are in scope at the time of the inner function’s creation. JavaFX has had closures for quite some time; Jim Weaver wrote a nice article about this over a year ago. Here’s a denser example:

function f(p: Integer): function(): Integer {
    var localvar = p;
    function(): Integer {
        ++localvar;
    }
}

What the heck does this do? First, f is a function that takes an integer and returns a function-that-returns-an-integer. This inner function (which has no name) increments the local variable and returns its new value. (Note that I had to copy the parameter into a local, since in JavaFX function parameters cannot be modified.) Now let’s call f a couple times, and then call each of the returned functions a couple times.

var g = f(17);
var h = f(32);

println("g() => {g()}");
println("h() => {h()}");
println("g() => {g()}");
println("h() => {h()}");

The output is:

g() => 18
h() => 33
g() => 19
h() => 34

(Astute readers will find this discussion reminiscent of the first chapter of Abelson & Sussman.) What’s going on here is that the first call to f created a local variable and a function that captured it, and returned this new function. This function was stored in g. The second call to f created a different local variable and a different function and returned it, and this was stored in h.

It’s not clear whether the functions “really” are different. The compiler might generate and use the same code for them, but they definitely use different environments. If you compare g and h you’ll find that they are not equal. Indeed, calling them gives different results. As you can see from the output, they clearly contain different instances of the local variable localvar. What’s more, these two instances of localvar exist long after f has returned. And they’ll continue to exist for as long as you hold onto g and h.

But inner functions aren’t the only way that local variables can continue to exist after their enclosing function exits. The bind and trigger (“on replace”) language constructs can also extend the lifetime of local variables. More on that in my next post.

Update: next post is here.