Chromium Blog
News and developments from the open source browser project
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
. Update May 20th: touch-action has been
delayed
until Chrome 36.
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
.
Update April 29th: Object.observe has been pushed back to Chrome 36.
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:
Scope their HTML markup, CSS, hiding the implementation details of complex components.
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 9, 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 3, 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 2, 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
Labels
accessibility
1
benchmarks
1
beta
1
blink
1
chrome apps
3
Chrome Frame
1
chrome web store
26
chromeframe
3
chromeos
3
chromium
3
cloud print
1
dart
8
devtools
11
extensions
23
gdd
1
googlechrome
12
html5
11
incognito
1
javascript
3
linux
2
mac
1
mobile
2
na
1
native client
8
New Features
5
octane
1
open web
2
releases
2
rlz
1
security
30
spdy
2
ssl
2
v8
5
web intents
1
webaudio
3
webgl
7
webkit
5
webp
5
webrtc
4
websockets
5
webtiming
1
Archive
2016
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2010
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2009
Dec
Nov
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2008
Dec
Nov
Oct
Sep
Feed
Follow @ChromiumDev
Give us feedback in our
Product Forums
.