Testing Chromium: ThreadSanitizer v2, a next-gen data race detector

Monday, April 21, 2014

In 2009, we developed ThreadSanitizer (aka TSan), a runtime data race detector based on binary translation. The tool helped find thousands of threading errors in various projects, including almost 180 bugs in Chromium. In 2010, we started experimenting with compiler-based instrumentation instead of binary translation, and once the approach had proven itself, our team redesigned ThreadSanitizer from scratch, focusing on compile-time instrumentation for greater speed and accuracy.

The new tool, ThreadSanitizer v2, is now part of both LLVM and GCC. Not only is it able to detect data races in C++ and Go code, but it is also able to report synchronization issues like deadlocks, unjoined threads, destroying locked mutexes, use of async-signal unsafe code in signal handlers, and others.

ThreadSanitizer v2 recognizes atomic operations, so it produces far more accurate reports and can also find bugs in lock-free algorithms, which are hard to detect otherwise. For example, it has helped us find incorrect synchronization in LazyInstance, incorrect lock-free queue implementation, and issues with concurrent sweeping in V8.

The new version is up to 20 times faster than the old ThreadSanitizer, which makes it possible to use it for heavyweight browser tests. Thanks to this, we’ve found several bugs in code that wasn’t covered by smaller unit tests, like races on the WebKit strings, garbage collection in Blink, a use-after-free in Blink, a handful of reports in WebRTC and many more. This has also improved bug reproducibility: the more times the test is repeated, the higher the chance to reproduce a flaky bug.

Over the last half-year almost 100 bugs were detected by the new tool, and we’re actively working on more. Our future plans include extensive use of TSan on ClusterFuzz and adding regular testing for various Chromium subprojects to catch new regressions quickly.

The ThreadSanitizer page contains all of the information necessary to start using the tool in your project. The tool is easy to use and can be integrated with any buildsystem: just add a single compile-time flag and run the program to see the error reports. For Chromium developers there’s a special page with instructions on dev.chromium.org.

Posted by Alexander Potapenko, Software Engineer and Synchronization Lookout

Chrome 35 Beta: More developer control over touch input, new JavaScript features, and unprefixed Shadow DOM

Thursday, April 10, 2014

Today’s Chrome Beta channel release includes a slew of new developer features to help you make richer, more compelling web content and apps, especially for mobile devices. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux, and Chrome OS.

More developer control over touch and zoom input

The touch-action CSS property offers developers a declarative mechanism to selectively disable touch scrolling, pinch-zooming, or double-tap-zooming on parts of their web content. Use cases include precise control over the dreaded 300ms click delay on mobile, reliable side-swipe UIs, and high-fidelity polyfills of Pointer Events. It’s also a prerequisite for future optimizations to enable scrolling and zooming that never block on the main thread.

Also new in this release, web content on desktop computers will now receive mouse scroll wheel events with the ctrlKey modifier set. There are many sites that want to do something more appropriate for the user than trigger browser zoom. For example, when a user holds control and scrolls over a map in Google Maps, they almost certainly want to zoom in on the map, not invoke browser zoom to zoom the page. This change will enable such a use case.

New JavaScript functionality

Chrome 35 includes support for a number of new JavaScript features defined in the ECMAScript 6 standard. Together, they will help JavaScript developers write application logic that is easier to read, more powerful, and more memory efficient.

A Promise represents a value that may not be available yet but will be known at some point in future. With Promises, you can write cleaner asynchronous code. WeakMaps and WeakSets allow you to create efficient, garbage-collected data structures. In both, references to objects are held weakly: if there is no other reference to an object stored in the WeakSet, it can be garbage collected. This helps avoid memory leaks.

Object.observe lets you observe changes to JavaScript objects. Your callback can observe multiple objects and will receive all changes to any objects in a single asynchronous call. This is especially useful for framework authors implementing data-binding.

Unprefixed Shadow DOM

Shadow DOM is one of several new API primitives landing under the Web Components umbrella. It brings reliable composition of user interface elements to the web platform and allow developers to:

  1. Scope their HTML markup, CSS, hiding the implementation details of complex components.
  2. Build their own first-class elements and APIs just like the <video> or <audio>, when combined with Custom Elements

With Shadow DOM, web frameworks can stop worrying about their widgets inadvertently breaking pages by using conflicting CSS selectors, class or id names, and start relying on DOM as the interoperable way of building components.

Numerous improvements and changes have been made to the specification since the days of the prefixed implementation of Shadow DOM made available in Chrome 25, so if you were already using the prefixed Shadow DOM API please take a look at the latest documentation as well as the up-to-date HTML5 Rocks articles and look for deprecation warnings.

Other new features in this release

  • CSS Font Loading can be used to dynamically load font resources. It gives developers more control over the user experience on pages that use Web Fonts. For instance, you can ask Chrome to start downloading the web fonts you'll need on demand and be notified when they become available.
  • The SVG 'paint-order' property offers a way to control the order in which fill, stroke and markers are painted.
  • The unprefixed version of the Web Audio API.

Removed features

Web platform feature deprecation and removal are important for the health of the web. Removing features allows browser vendors like Chromium to simplify our codebases, minimize security attack surfaces, and, most importantly, evolve the web API surface to address the needs of today’s users and developers.

Features removed in this release include HTMLVideoElement-specific prefixed fullscreen API, TextTrackCue constructor, <isindex>, Legacy Web Notifications, document.createAttributeNS, support for NPAPI on Linux, and Attr.isId, ownerElement, prefix setter. If you’d like to hear more about these changes or participant in discussions, please chime in our mailing list and look for "Intent to Remove" or “Intent to Deprecate” threads.

Recently deprecated features

The most prominent recently deprecated feature is window.showModalDialog, which will be removed in our next release, Chrome 36. Please read Opera’s explanation of the change to learn more. Other deprecated features include Element.setAttributeNodeNS, overflowchanged Event, HTMLSourceElement.media, MediaError.MEDIA_ERR_ENCRYPTED, Prefixed media source extensions, and webkitRequestAnimationFrame. Support for these features will be completely removed from Chrome in a future release.

As always, visit chromestatus.com/features for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates!

Posted by Rick Byers, Software Engineer and Touch API Tamer

Dart improves async and server-side performance

Wednesday, April 09, 2014

Today's release of the Dart SDK version 1.3 includes a 2x performance improvement for asynchronous Dart code combined with server-side I/O operations. This puts Dart in the same league as popular server-side runtimes and allows you to build high-performance server-side Dart VM apps.

We measured request-per-second improvements using three simple HTTP benchmarks: Hello, File, and JSON. Hello, which improved by 130%, provides a measure for how many basic connections an HTTP server can handle, by simply measuring an HTTP server responding with a fixed string. The File benchmark, which simulates the server accessing and serving static content, improved by nearly 30%. Finally, as a proxy for performance of REST apps, the JSON benchmark nearly doubled in throughput. In addition to great performance, another benefit of using Dart on the server is that it allows you to use the same language and libraries on both the client and server, reducing mental context switches and improving code reuse.

The data for the chart above was collected on a Ubuntu 12.04.4 LTS machine with 8GB RAM and a Intel(R) Core(TM) i5-2400 CPU, running a single-isolate server on Dart VM version 1.1.3, 1.2.0 and 1.3.0-dev.7.5. The source for the benchmarks is available.

We are excited about these initial results, and we anticipate continued improvements for server-side Dart VM apps. If you're interested in learning how to build a web server with Dart, check out the new Write HTTP Clients and Servers tutorial and explore the programmer's guide to command-line apps with Dart. We hope to see what you build in our Dartisans G+ community.

Written by Anders Johnsen, Speed Obsessed Software Engineer

Blink’s First Birthday

Thursday, April 03, 2014

Last April we introduced Blink as the new rendering engine for Chromium. Since then, the project has grown to include over 200 active contributors, and code complexity has been reduced significantly. We’ve also made encouraging progress on our top priority for 2014: mobile web performance.

A productive community emerged on our mailing list within Blink’s first few months. Each week, we now see on average 23 new discussion threads and 5 new “intents” to change the web API surface. We’re honored that 41% of our “intents” have come from folks outside of Google, and 33% of our active contributors are non-Googlers. We’re especially excited about recent contributions like Yoav Weiss’s implementation of the <picture> element, the Opera team’s prolific improvements and feature removals, Intel’s performance work, Adobe’s continued work on making the web awesome with CSS Shapes and other graphics and layout work, Samsung’s investment in mobile functionality, and more.

We also built the Chromium Feature Dashboard, a tool for staying up-to-date on Blink’s web API surface. It’s currently tracking implementation of 168 web platform features and anonymous usage statistics for 295 JavaScript APIs & HTML tags and 428 CSS properties. We use these usage statistics to see which features can be safely deprecated. In the offline world, last September we held our first bi-annual contributors’ conference with over 160 participants from 10+ organizations.

On the technical side, code size and complexity remains an ongoing challenge for Blink. Code complexity slows development and leads to bugs. Fortunately, we’ve been able to aggressively remove and simplify our code because Blink’s only supported port is Chromium. In aggregate, nearly half the codebase has been eliminated since work on Blink began last year. Notable simplification efforts include unifying CSS and SVG animations with the Web Animations engine, replacement of our WebIDL compiler, factoring of a blink_platform layer out of core code, and continued work on a C++ garbage collector.

2014 promises an even greater increase in mobile computing, thus we continue to focus Blink’s efforts there. Software performance is critical on mobile devices because of constrained hardware and high user expectations. To improve mobile web performance, we have projects to speed up rendering, minimize binary size, reduce input latency, preserve battery power, shrink memory consumption, and more.

We’ve seen some results already. For example, the tight relationship between Blink and Chromium has allowed us to improve the abstraction layer between Blink and Chromium’s compositor. We’re now much more careful to do work for Blink only just before Chrome draws to the screen, avoiding wasting CPU cycles generating results that will overwritten before the next frame is drawn anyway. Through tighter integration, we’ve also achieved 50% savings in compositing updates that change only CSS transforms. This is just the beginning of our performance work; we expect even further improvements from newer efforts like GPU rasterization and better scheduling.

As we enter our second year, we plan to continue to improve Blink on mobile devices, grow our community, and fight the good fight against complexity creep. Join us or follow along to stay in touch!

Posted by Eric Seidel, Software Engineer and Code Complexity Curtailer

Simplifying Cloud Messaging for app developers

Wednesday, April 02, 2014

Last year we released Google Cloud Messaging (GCM) for Chrome that enabled Chrome Apps and extensions to receive push messages from their server-side components. While it provided developers with powerful new capabilities, it was not compatible with Google Cloud Messaging for Android, which led to inconsistencies in the feature sets supported for both platforms. Today we are releasing a developer preview of the new chrome.gcm API. The API shares server-side infrastructure with GCM for Android, which means cloud messaging has to be implemented only once on the server side for both Android and Chrome Apps.

The chrome.gcm API brings new capabilities and improvements over the existing chrome.pushMessaging API. A major new capability is sending upstream messages from the app to the server while still enjoying the benefits of the cloud messaging infrastructure, such as reliable message queueing or sending the messages only when a network connection is available. The API enhances messages by making them more structured, larger (up to 4KB), and allowing them to expire when not delivered within a specified time-to-live. Unlike the chrome.pushMessaging API, chrome.gcm API does not impose quota restrictions.

The API is available now on Chrome Canary and the Dev Channel. You can learn more about writing GCM-enabled Chrome Apps from our documentation. For a quick start, you can check out the GCM sample available on GitHub.

Providing Chrome developers with access to a cloud messaging infrastructure shared between Android and Chrome is an important step to simplifying development of apps and services spanning both platforms. Although the new GCM API is currently in developer preview, over time it will become the default way for developers to enable messaging for their applications. Please give it a try, and send us your feedback at Stack Overflow, our G+ Developers page, or our developer forum.

Posted by Filip Gorski and Jian Li, Software Engineers and Server Simplifiers

WebP improves while rolling out across Google

Friday, March 21, 2014

The WebP team at Google focuses on making the web better through smaller, faster-loading images. We’ve seen that WebP compares favorably with other contemporary image formats, but our team has been hard at work to make WebP even faster and more capable. A few months ago, we added support for animated WebP images to Chrome, making WebP the first unified format that can address the key use cases of JPEG, PNG and GIF files. The recent release of libwebp 0.4.0, currently in Chrome’s Beta channel, is a culmination of numerous encoder and decoder optimizations that make encoding lossless images twice as fast, and decrease lossless decode time by 25%.

While the WebP team was delivering these improvements, other teams at Google have been busy deploying WebP in their own products. Google Play’s online store, redesigned mid-last year, replaced png images with lossless WebP, reducing image file sizes by nearly 35%. Another major WebP rollout is currently in progress: YouTube video thumbnails are starting to be served in WebP with initial results indicating up to a 10% reduction in page load time.

All the rollouts within Google combined have raised our aggregate data transfer savings tally to tens of terabytes every day. For users, this translates into faster page load times and fewer bytes counted against metered data plans. To speed up browsing on sites that don’t serve WebP yet, Chrome for Android and iOS can use Chrome’s Data Compression Proxy, which transcodes images to WebP on the fly in order to deliver image compression of over 60%.

To developers outside of Google, the data transfer savings and user benefits of WebP are within easy reach. Growing support from CDNs and accept content negotiation make it easier than ever to enable wide scale, seamless delivery of WebP images to Chrome users. To find out more, visit the WebP developer site or reach out to us using our public discussion group.

Posted by Husain Bengali, Product Manager and WebP Optimizer

Protecting user settings on Windows with the new Settings API

Tuesday, March 11, 2014

Browser settings hijacking continues to be a top issue for Chrome users, particularly on Windows. A user’s start page, home page and default search engine are critical parts of their Chrome experience, so we are creating an extension-based Settings API for Chrome on Windows to ensure all users have notice and control over any settings changes that take place in their browser. We expect to release this API to the Stable channel in May, after which it will be the only way for developers to make programmatic settings changes in Chrome on Windows. The API is available now on the Windows Dev channel.

If your software relies on making changes to user settings within Chrome as part of its feature set, make sure you begin moving your code to use this new API now and send us your feedback.

Posted by Erik Kay, Engineering Director