Skip to main content

New site for Dart news and articles

For the latest Dart news, visit our new blog at  https://medium.com/dartlang .

dart2js now only Dart to JavaScript compiler in Editor and SDK

Posted by Seth Ladd

Today, Kasper Lund, one of Dart engineers, submitted a patch that makes dart2js the only Dart to JavaScript compiler accessible to developers. The old frog compiler will be around just a little bit longer for some legacy integrations, but it is no longer accessible via the Editor or the SDK.

In an email to the public Dart discussion list, Kasper writes:


The code that is generated by dart2js is looking better and better, but it is still a
bit too big for our liking. We're working on a few things to make it
smaller:

  * better code for logical operations
  * simpler, less nested code for switches
  * smaller code for throws
  * better bailout code

The bailout code might be of interest to some of you and I'll try to
illustrate what it is and how we plan on improving it with an example.
Given the following Dart code:

----------
  main() {
    var list = makeList();
    var sum = 0;
    for (var i = 0; i < list.length; i++) {
      sum += list[i];
    }
    print(sum);
  }


  makeList() {
    var result = new List(100);
    for (var i = 0; i < result.length; i++) {
      result[i] = i;
    }
    return result;
  }
----------

we currently generate the following JavaScript code:

----------
  $.main = function() {
    var list = $.makeList();
    if (typeof list !== 'string' &&
        (typeof list !== 'object'||list.constructor !== Array))
      return $.main$bailout(1, list);
    for (var sum = 0, i = 0; i < list.length; ) {
      var t1 = list.length;
      if (i < 0 || i >= t1) throw $.ioore(i);
      sum = $.add(sum, list[i]);
      i = i + 1;
    }
    $.print(sum);
  };


  $.makeList = function() {
    var result = $.List(100);
    for (var i = 0; i < result.length; ) {
      var t1 = result.length;
      if (i < 0 || i >= t1) throw $.ioore(i);
      result[i] = i;
      i = i + 1;
    }
    return result;
  };
----------

The code in main is a bit more involved than the code in makeList.
Inside makeList, we're sure that the list allocated is a JavaScript
array so we can use its length property and access its elements using
the [] notation. In main, we have to check that makeList actually
returned a JavaScript array (or a string) before we're sure that those
operations have the right semantics. If makeList ever returns
something that isn't a JavaScript array, we probably have to call a
user-defined length getter and operator[] for accessing the elements.
This is where the "bailout" version comes into play.

The bailout version of a method is essentially an unoptimized version
that we can jump to from the optimized version of the method. It
doesn't assume anything about its inputs and uses only generic
operations on them. We only need bailout versions for methods where we
do speculative optimizations that aren't guaranteed to be valid. The
actual code for the bailout version of main is a bit hairy:

----------
  $.main$bailout = function(state, env0) {
    switch (state) {
      case 1:
        list = env0;
        break;
    }
    switch (state) {
      case 0:
        var list = $.makeList();
      case 1:
        state = 0;
        var sum = 0;
        var i = 0;
        L0: while (true) {
          if (!$.ltB(i, $.get$length(list))) break L0;
          sum = $.add(sum, $.index(list, i));
          i = i + 1;
        }
        $.print(sum);
    }
  };
----------

Instead of using list.length and list[i], we're now calling
get$length(list) and index(list, i). The reason why the control flow
in the bailout code is so complex is that we've designed it so it is
possibly to jump into it from various parts in the optimized code.
Right now, we're not recognizing that in this case we're only
branching into it from one place (state is always one) but we plan to
make use of that to get rid of the switch and the dead code in the
unused cases.

Even though we're working on improving our support for speculative
optimizations, we're also looking into inferring concrete type
information. This would allow us to recognize the fact that makeList
always returns a JavaScript array thus eliminating the need for the
bailout version altogether. Smaller and faster code for the win.

We expect to move quickly on all of these issues -- and as always
we'll do our best to keep you guys informed about our progress!