Skip to main content

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!

Popular posts from this blog

Dart in 2016: The fastest growing programming language at Google, 2nd fastest growing in TIOBE Index

Dart was the fastest growing programming language at Google in 2016 with millions of lines of code written. It also made it to TIOBE Index Top 20 this month (see TIOBE's methodology).

It takes time to build something as ambitious as Dart and, in some ways, Dart is still in its infancy. But we're glad the hard work is starting to pay off.

Many thanks to our amazing community!

We're going to celebrate by ... releasing 1.22 next week (as per our usual 6 week release schedule).

AngularDart is going all Dart

Until now, the multiple language flavors of Angular 2 were written as TypeScript source, and then automatically compiled to both JavaScript and Dart. We're happy to announce that we’re splitting the Angular 2 codebase into two flavors – a Dart version and a TypeScript/JavaScript version – and creating a dedicated AngularDart team.

This is amazing news for Dart developers because:

The framework will feel more like idiomatic Dart.It will make use of Dart features that couldn't work with the TypeScript flavor. It will be faster.
This is equally great news for our TypeScript and JavaScript developers, by the way. Cleaner API, performance gains, easier contributions. Read more on the Angular blog.

Angular 2 for Dart is used by many teams at Google. Most famously by the AdWords team, but many other Google teams build large, mobile-friendly web apps. Some of the top requests from these teams were: make the API feel like Dart, provide a faster edit-refresh cycle, and improve applicat…

The new AdWords UI uses Dart — we asked why

Google just announced a re-designed AdWords experience. In case you’re not familiar with AdWords: businesses use it to advertise on google.com and partner websites. Advertising makes up majority of Google’s revenue, so when Google decides to completely redo the customer-facing front end to it, it’s a big deal. The Dart team is proud to say that this new front end is built with Dart and Angular 2. Whenever you asked us whether Google is ‘even using Dart for anything,’ this is what we had in mind but couldn’t say aloud. Until now. We asked Joshy Joseph, the primary technical lead on the project, some questions. Joshy is focusing on things like infrastructure, application latency and development velocity, so he’s the right person to ask about Dart.Q: What exactly did we launch on Monday?It’s a complete redesign of the AdWords customer experience that is rolling out slowly as a test to a small initial set of advertisers. The most noticeable thing is probably the Material Design look and f…