Skip to content

Higgs has Exceptions

December 18, 2012

I just finished implementing exceptions in the Higgs interpreter, complete with support for the finally block and optional catch clauses. The fact that Higgs is an interpreter and tracing JIT instead of a method-based compiler definitely made this process somewhat simpler. The interpreter uses a calling convention where all arguments are pushed on the stack and each stack frame has a fixed size, making stack unwinding very easy. The tracing JIT won’t have to do any special treatment of exceptions: it will simply fall back to the interpreter.

Unsurprisingly, one of the trickiest aspects of exception support is the finally block. This was difficult to implement because the semantics of JavaScript (and Java) say that every form of control flow leaving a try or catch block must execute the corresponding finally blocks (and there might be more than one). This means the throw, break, continue and return statements can each trigger the execution of finally blocks. You can hijack a return statement using a finally block and return a different value. Worse yet: exceptions crossing interprocedural boundaries can trigger the execution of finally blocks while unwinding the stack.

Since my interpreter uses an intermediate representation built on basic blocks and sequences of instructions, I had to compile finally blocks in-line at every point where they would be run, which meant handling a multitude of corner cases. I believe this complexity reveals that finally blocks are a fundamentally “unnatural” language feature. I say unnatural because the control flow involved is convoluted and unintuitive to programmers. Preventing a return statement from executing seems like the kind of black magic that simply shouldn’t be possible.

I’m quite happy to have exception support as I believe it will make debugging the Higgs runtime and standard libraries (both written in extended JS) much easier. Now that this is done, I will be moving towards one of the biggest pieces of the puzzle: implementing a garbage collector for Higgs. Since the focus of my research isn’t garbage collection, I will implement a simple and minimalist stop-the-world copying GC. Having previously implemented a similar GC for Tachyon, I anticipate that I should be able to complete this task within approximately two weeks. The task will be sped up by the automatic generation of code to visit heap-allocated objects.

In case anyone reading this blog is interested, I could use some help on various fronts, one of which is the completion of the math library. I’m missing functions such as Math.ceil, Math.log, Math.exp and full floating-point support in Math.pow. I’m also in need of code to parse and format floating-point values as strings. All of this code would be written in JavaScript. Lastly, I’m looking for a simple JavaScript FFT (fourier transform) benchmark.

2 Comments
  1. shanebdavis permalink

    Is finally really that bad? It is exactly the right semantics for cleanup code. In the case of hijacking “return”, the return statement itself is more of a problem because it is essentially a goto. This works well in languages like Ruby where you don’t need return statements (though you can use them).

    It sounds like you have other reasons for disliking finally. I’m curious what they are.

    (I feel for you on the complexity of the implementation, though.)

    • The complexity of the implementation and the unintuitive spaghetti control flow. Seems to me it’s just not all that useful, and I prefer a simpler, more minimalist language.

Leave a comment