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).

The new Google AdSense user interface: built with AngularDart

AdSense is a free, simple way to earn money by placing ads on your website. The team just launched a completely new version of their app for publishers. Read all about it here. We asked Daniel White, the tech lead for the project, some questions because the new UI happens to be built with Dart and Angular2.


AdSense launched way back in 2003. How long is it since the last big redesign?
Last big redesign was called ‘AdSense 3’ and launched about 6 years ago. It was written in Google Web Toolkit (GWT) and the UI has evolved through several iterations - but this is the first ground-up redesign in 6 years. There are a number of long-standing UX issues that we’ve taken the opportunity to solve. A big shout-out to our UX team who’ve been 100% behind this project. We couldn’t have done it without them!

How many software engineers worked on the project?
Purely on the AdSense applications, we have a team of close to 100. Around 25% of them write Dart.

How many lines of code?
We have around 160K LO…

A stronger Dart for everyone

We are constantly asking ourselves:
How do we make developers even more productive when writing Dart apps? We believe that a critical part of the answer to this question is to make strongmode – a sound static type system for Dart – the standard for all Dart developers.

Teams that use Dart to build apps like Soundtrap, AdWords, AdSense, and Greentea say they really enjoy using strong mode features, such as early error detection. In fact, teams that have switched completely to strong mode cite not only early error detection but also better code readability and maintainability as major benefits. We hear this both from small teams and Рeven more so Рfrom large teams with hundreds of developers writing and maintaining millions of lines of Dart code. As Björn Sperber from Soundtrap says,
Strong mode and the smooth integration with IntelliJ is a joy to use and a huge improvement. If you’ve tried out Flutter, you’ve already used strong mode checks from the Dart analyzer.

Given the benefits …