Efficient And Safe Allocations Everywhere!

Monday, April 12, 2021

In our constant work to improve performance, our engineers sometimes have to seek optimizations in places that most software developers don’t venture. In this post in our series, The Fast and The Curious, a team of senior engineers showed how they approached replacing the system-level memory allocator with an optimized version, yielding significant memory savings -- up to 22% on Windows.
PartitionAlloc is Chromium’s memory allocator, designed for lower fragmentation, higher speed, and stronger security and has been used extensively within Blink (Chromium’s rendering engine). In Chrome 89 the entire Chromium codebase transitioned to using PartitionAlloc everywhere (by intercepting and replacing malloc() and new) on Windows 64-bit and Android. Data from the field demonstrates up to 22% memory savings, and up to 9% improvement in responsiveness and scroll latency of Chrome.

Here's a closer look at memory usage in the browser process for Windows as the M89 release began rolling out in early March:

Background

Chrome is a multi-platform, multi-process, multi-threaded application, serving a wide range of needs, from small embedded WebViews on Android to spacecraft. Performance and memory footprint are of critical importance, requiring a tight integration between Chrome and its memory allocator. But heterogeneity across platforms can be prohibitive with each platform having a different implementation such as tcmalloc on Linux and Chrome OS, jemalloc or scudo on Android, and LFH on Windows.

When we started this project, our goals were to: 1) unify memory allocation across platforms, 2) target the lowest memory footprint without compromising security and performance, and 3) tailor the allocator to optimize the performance of Chrome. Thus we made the decision to use Chromium’s cross-platform allocator, to optimize memory usage for client rather than server workloads and to focus on meaningful end user activities, not micro-benchmarks that wouldn’t really matter in real world usage.

Allocator Security

PartitionAlloc was designed to support multiple independent partitions, i.e. non-overlapping regions of memory. We use these partitions throughout Blink to thwart some forms of type confusion attacks, such as ensuring strings are separated from layout objects. However, this approach only avoids collisions between types that are allocated from different partitions. Furthermore, PartitionAlloc buckets allocations by their sizes, to help avoid type confusion when potentially-colliding objects are of dissimilar size. These techniques work because PartitionAlloc doesn’t re-use address space. Once PartitionAlloc dedicates a region of address space to a certain partition and size bucket, it will always belong to that partition and size bucket.

Additionally, PartitionAlloc protects some of its metadata with guard pages (inaccessible ranges) around memory regions. Not all metadata is equal, however: free-list entries are stored within previously allocated regions, and thus surrounded by other allocations. To detect corrupted free-list entries and off-by-one overflows from client code, we encode and shadow them.
Finally, having our own allocator enables advanced security features like MiraclePtr and *Scan.

Architecture Details

Each partition in PartitionAlloc uses a single, central, slab-based allocator to conserve memory, with a minimal per-thread cache in front for scaling to multi-threaded workloads. This simplicity also pays performance dividends: we’ve extensively profiled and aggressively trimmed the allocator’s fast path, improving thread-local storage access, locks, reducing cache line fetches, and removing branches.

PartitionAlloc pre-reserves slabs of virtual address space. They are gradually backed by physical memory, as allocation requests arrive. Small and medium-sized allocations are grouped in geometrically-spaced, size-segregated buckets, e.g. [241; 256], [257; 288]. Each slab is split into regions (called “slot spans”) that satisfy allocations (“slots”) from only one particular bucket, thereby increasing cache locality while lowering fragmentation. Conversely, larger allocations don’t go through the bucket logic and are fulfilled using the operating system’s primitives directly (mmap() on POSIX systems, and VirtualAlloc() on Windows).

This central allocator is protected by a single per-partition lock. To mitigate the scalability problem arising from contention, we add a small, per-thread cache of small slots in front, yielding a three-tiered architecture:

The first layer (Per-thread cache) holds a small amount of slots belonging to smaller and more commonly used buckets. Because these slots are stored per-thread, they can be allocated without a lock and only requiring a faster thread-local storage lookup, improving cache locality in the process. The per-thread cache has been tailored to satisfy the majority of requests by allocating from and releasing memory to the second layer in batches, amortizing lock acquisition, and further improving locality while not trapping excess memory.

The second layer (Slot span free-lists) is invoked upon a per-thread cache miss. For each bucket size, PartitionAlloc knows a slot span with free slots associated with that size, and captures a slot from the free-list of that span. This is still a fast path, but slower than per-thread cache as it requires taking a lock. However, this section is only hit for larger allocations not supported by per-thread cache, or as a batch to fill the per-thread cache.

Finally, if there are no free slots in the bucket, the third layer (Slot span management) either carves out space from a slab for a new slot span, or allocates an entirely new slab from the operating system, which is a slow but very infrequent operation.

The overall performance and space-efficiency of the allocator hinges on the many tradeoffs across its layers such as how much to cache, how many buckets, and memory reclaiming policy. Please refer to PartitionAlloc to learn more about the design.

All in all, we hope you will enjoy the additional memory savings and performance improvements brought by PartitionAlloc, ensuring a safer, leaner, and faster Chrome for users on Earth and in outer space alike. Stay tuned for further improvements, and support of more platforms coming in the near future.

Posted by Benoît Lizé and Bartek Nowierski, Chrome Software Engineers

Data source for all statistics: Real-world data anonymously aggregated from Chrome clients.
*The core metric measures jank -- delay handling user input -- every 30 seconds.

Don’t Copy That Surface

Monday, April 5, 2021

This post is part of a new series The Fast and The Curious we're bringing you of deeper dives into the careful trade-offs and complex engineering that goes into making Chrome fast and reliable. This debugging adventure by Chrome developer and blogger Bruce Dawson reduced CPU usage by about 3% when using a webcam - a real help for those of us relying on video calls.
Video conferencing took on elevated importance in 2020. I’m not on the Google Meet team but I do work on Chrome, so I fired up my favorite profiler during one of my daily meetings to see if I could find anything useful.

There is a lot going on during video conferencing, spread across multiple processes. With my usual dozens of tabs open there were 37 Chrome processes, with six of them actively participating in the video conference. In addition there were over 200 other processes running (87 copies of svchost.exe, for instance), with four of those involved in video conferencing. You may well wonder why it takes 10 processes to connect two people, so here is a list of the processes and their roles:

audiodg.exe - Windows Audio Device Graph Isolation, audio output
dwm.exe - Windows Desktop Window Manager, showing video
svchost.exe - Windows Camera Frame Server (webcam capture)
System - Windows system process, does miscellaneous tasks on behalf of processes
chrome.exe - browser process, the master control program
chrome.exe - renderer process, the Meet tab
chrome.exe - GPU process, in charge of rendering pages
chrome.exe - NetworkService utility process, talking to the network
chrome.exe - VideoCaptureService, talking to the Windows Camera Frame Server
chrome.exe - AudioService, controls audio input and output

These tasks are spread across different processes for security and stability. If one of them crashes it can be restarted without taking everything down. If one of them is compromised due to a security bug then it is isolated from the rest of the system and the damage may be contained.

This all makes good sense, but having this many processes involved can make performance-profiling challenging. It can be challenging to look through all of these processes to find areas of potential improvement. It is made more difficult by the fact that I know little about the Meet architecture.

Analyzing a profile

Video conferencing is CPU intensive - you have to record, compress, transmit, receive, decompress, and display both audio and video. The data below shows CPU samples recorded by Microsoft’s Event Tracing for Windows (ETW). This sampling profiler works by interrupting every running thread about 1,000 times a second and recording a call stack. I used Windows Performance Analyzer (WPA) to display the results. In the screenshot below I am looking at a 10-second period and over 16,000 samples (representing about 16 seconds of CPU time) were recorded across the 10 processes involved in video conferencing:

That’s a lot of samples to look through, but the call stacks are collated so that you can drill down on the busiest stacks. I didn’t find anything in the first Chrome process, but in the second one I did:

It doesn’t look like much, but I recognized immediately that the 124 samples in KiPageFault were worth investigating. Most of the CPU-intensive work in this trace was important and unavoidable work but I had a hunch that these samples represented avoidable work - something that I could fix. And, even though they represented just 0.75% of the samples I suspected that they indicated a somewhat greater cost.

I recognized their importance immediately because this is something that I have seen before. KiPageFault means that the processor touched some memory that had been allocated, but was not currently in the process. This could mean that the pages had been removed from the process to save memory, but in an active process on a machine with lots of memory, that didn’t make sense. What was more likely was that this represented recently allocated memory.

When a program allocates a small amount of memory, the local memory manager (sometimes called the “heap”) will usually have some available that it can give to the program. But if it doesn’t have an appropriate block of memory then it will ask the operating system (OS) for some. If a program allocates a large amount of memory (greater than a MB or so) then the heap will definitely ask for more memory. This is, in itself, a relatively cheap operation. The heap asks the OS for some memory, the OS says “sure”, then the OS makes note of the fact that it promised this memory, and that’s it. The OS does not, at that time, actually give the program any memory. This is the way of the world on Windows, Linux, Android and it is good but it can be confusing and surprising. If the process never touches the memory then the memory is never added to the process, but if the process does touch the memory then individual pages of zeroed memory are brought into the process. These are called demand-zero page faults because zeroed pages are “faulted” into the process on demand.

In other words, allocating a large block of memory is quite cheap, but doesn’t actually set up the promised memory. Then, when the program tries to use the memory and the CPU discovers that there is no memory at that address it triggers an exception, which wakes up the OS. The OS checks its records and realizes that it did in fact promise to put memory at that address so it then puts some there and restarts the program. This happens so quickly that if you’re not paying attention you will miss it, but it shows up when profiling as samples hitting in KiPageFault.

This bizarre dance happens again for every 4-KiB block in the allocation - 4 KiB is the size of the pages that the CPU and the OS work on.

The cost is small. Across this 10-second period only 124 samples - representing about 124 ms or 0.124 seconds - hit inside of KiPageFault. The total cost of the enclosing CopyImage_SSE4_1 function was about 240 ms, so the page faults accounted for more than half of this function, but barely a quarter of the cost of the OnSample function on line 15.

The total costs of these page faults is modest but they hint at many other costs:

If this memory is being allocated repeatedly (presumably every frame) then it must also be freed every frame. On line 26 we can see that the Release function which frees the memory uses another 64 samples.
When the pages are freed the operating system has to zero them (for security reasons) so that they are ready to be reused. This is done in the Windows System process - an almost entirely hidden cost. Sure enough when I looked in the System process I saw 138 samples in the MiZeroPageThread. I found that 87% of the KiPageFault samples in the entire system were in the CopyImage_SSE4_1 call so presumably 87% of the 138 samples in the MiZeroPageThread were due to this pattern.

I analyzed these hidden costs of memory allocation in a 2014 blog post. The basic memory architecture of Windows hasn’t changed since then so the hidden costs remain about the same.

In addition to CPU samples my ETW trace contained call stacks for every call to VirtualAlloc. This WPA screenshot shows a 10-second period where the OnSample function does 298 allocations that are each 1.320 MB, roughly 30 per second:

At this point we can estimate that the cost of these repeated allocations is 124 (faulting in) plus 64 (freeing) plus 124 (87% of the zeroing samples) for a total of 312 samples. This gets us up to 1.9% of the total CPU cost of video conferencing. Fixing this is not going to change the world, but this is a change worth doing.

But wait, there’s more!

We are locking this buffer so that we can look at the contents, but it turns out we don’t actually want the lock call to copy the buffer at all. We just want the lock call to describe the buffer to us so that we can look at it in place. Therefore the entire cost of the MFCopyImage call is waste! That’s another 116 samples. In addition, in the CMF2DMediaBuffer::Unlock call on line 26 there is another call to CMF2DMediaBuffer::ContiguousCopyFrom. That’s because the Unlock call assumes that we might have modified the copy of the buffer, so it copies it back. So the 101 samples there are all waste as well!

If we can examine this buffer without the alloc/copy/copy/free dance then we can save 312 samples plus 116 samples (the rest of the copying cost) plus 101 samples (the copying-it-back cost) for a total saving of 3.2%. This is getting better all the time.

Note that sampled data is only statistically valid, and the actual percentages vary significantly depending on the computer and the exact workload. But, the point remains - it is a non-dramatic but worthwhile change to investigate.

Despite spending years in the video-game business my knowledge of these graphics-buffer locking and unlocking APIs is weak. I ended up relying on the wisdom of my Twitter followers to come to the conclusion that the copying was entirely avoidable, and to get a rough pattern for how it could be fixed. After filing an overly verbose bug I delegated the task of actually fixing it. The fix landed in M85 and was deemed important enough that it was then backported to M84.

You’d have to be paying very close attention to see the difference - spread across a Chrome process and the system process - but I hope that this helped some computers run a bit cooler and last longer on their batteries. And, while this inefficiency was found by profiling Google Meet, the improvement actually benefits any product that uses the webcam inside Chrome (and other Chromium-based browsers).

Verification

After the fix landed I compared two 10-second ETW traces from Chrome Canary before and after the change, each taken with no other programs running except a single Chrome tab running the Google Meet pre-meeting page. In both cases I looked at a 10-second period of time in the profiler. This showed:

CPU time in OnSample:

Before: 458 ms (432 ms of which were in Lock/Unlock/KiPageFault)
After: 27 ms

Allocations:

Before: 30 allocations per second of 1.32 MB (one per frame, running at 30 fps - a higher framerate would mean more allocations), totalling 396 MB over 10 seconds
After: 0 allocations

CPU time in the System process's MiZeroPageThread:

Before: 36 ms
After: 0 ms

These measurements showed - in three different ways - that the performance problem was fixed. The memory copying in OnSample was gone, the repeated allocations were gone, and the system process was doing less work. Mission accomplished, bug closed.

A safer default for navigation: HTTPS

Tuesday, March 23, 2021

Starting in version 90, Chrome’s address bar will use https:// by default, improving privacy and even loading speed for users visiting websites that support HTTPS. Chrome users who navigate to websites by manually typing a URL often don’t include “http://” or “https://”. For example, users often type “example.com” instead of “https://example.com” in the address bar. In this case, if it was a user’s first visit to a website, Chrome would previously choose http:// as the default protocol¹. This was a practical default in the past, when much of the web did not support HTTPS.Chrome will now default to HTTPS for most typed navigations that don’t specify a protocol². HTTPS is the more secure and most widely used scheme in Chrome on all major platforms. In addition to being a clear security and privacy improvement, this change improves the initial loading speed of sites that support HTTPS, since Chrome will connect directly to the HTTPS endpoint without needing to be redirected from http:// to https://. For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails (including when there are certificate errors, such as name mismatch or untrusted self-signed certificate, or connection errors, such as DNS resolution failure). This change is rolling out initially on Chrome Desktop and Chrome for Android in version 90, with a release for Chrome on iOS following soon after.

HTTPS protects users by encrypting traffic sent over the network, so that sensitive information users enter on websites cannot be intercepted or modified by attackers or eavesdroppers. Chrome is invested in ensuring that HTTPS is the default protocol for the web, and this change is one more step towards ensuring Chrome always uses secure connections by default. ¹ One notable exception to this is any site in the HSTS preload list, which Chrome will always default to HTTPS.
² IP addresses, single label domains, and reserved hostnames such as test/ or localhost/ will continue defaulting to HTTP. Posted by Shweta Panditrao and Mustafa Emre Acer, Chrome team

Mitigating Side-Channel Attacks

Friday, March 12, 2021

The web platform relies on the origin as a fundamental security boundary, and browsers do a pretty good job at preventing explicit leakage of data from one origin to another. Attacks like Spectre, however, show that we still have work to do to mitigate implicit data leakage. The side-channels exploited through these attacks prove that attackers can read any data which enters a process hosting that attackers' code. These attacks are quite practical today, and pose a real risk to users.Our goal must be to ensure that sensitive data doesn't unexpectedly enter an attacker's process. Browsers shoulder a large chunk of this responsibility: Chromium's Site Isolation can separate the sites you visit into distinct OS-level processes, cross-origin read blocking prevents attackers from loading a subset of otherwise-vulnerable cross-origin resources, and APIs that substantially increase attackers' bandwidth (like SharedArrayBuffer) are being locked to cross-origin isolated contexts. This last mechanism, however, points in the direction of work that browsers can't do on their own.Web developers know their applications intimately, and can make informed decisions about each page's and resource's risk of exposure. To defend users' data against exfiltration, web developers must step in, evaluate resources they host, and instruct browsers to isolate those resources accordingly. At a high-level, this defense consists of:

Deciding when to respond to requests by examining incoming headers, paying special attention to the Origin header on the one hand, and various Sec-Fetch- prefixed headers on the other.

Restricting attackers' ability to load resources as a subresource by setting a cross-origin resource policy of same-origin (opening up to same-site or cross-origin only when necessary).

Restricting attackers' ability to frame resources as a document by opting into framing protections via X-Frame-Options: SAMEORIGIN or CSP’s more granular frame-ancestors directive: for example, frame-ancestors 'self' https://trusted.embedder.

Restricting attackers' ability to reference your application's windows by setting a cross-origin opener policy. In the best case, you can default to a restrictive same-origin value, opening up to same-origin-allow-popups or unsafe-none only if necessary.

Preventing MIME-type confusion attacks and increasing the robustness of passive defenses like cross-origin read blocking by setting correct Content-Type headers, and globally asserting X-Content-Type-Options: nosniff.

Together, these various defenses help all browsers offer some degree of process-level protection for users' data, whether or not Site Isolation is available.To find out more about employing these defenses, check out Post-Spectre Web Development. It includes practical examples that explain in more detail how the security primitives discussed above apply to resources you might have on your sites.These are useful steps you can take today to protect your origin against implicit data leaks. Looking forward, we hope to help the web shift to safer defaults which protect users against these attacks without requiring developer action.Posted by Mike West, on behalf of Chrome's web platform security team

Chrome 90 Beta: AV1 Encoder for WebRTC, New Origin Trials, and More

Thursday, March 11, 2021

Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 90 is beta as of March 11, 2021.AV1 EncoderAn AV1 encoder is shipping in Chrome desktop that is specifically optimized for video conferencing with WebRTC integration. The benefits of AV1 include:

Better compression efficiency than other types of video encoding, reducing bandwidth consumption and improve visual quality

Enabling video for users on very low bandwidth networks (offering video at 30kbps and lower)

Significant screen sharing efficiency improvements over VP9 and other codecs.

This is an important addition to WebRTC especially since it recently became an official W3C and IETF standard.Origin TrialsThis version of Chrome introduces the origin trials described below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones described below, visit the Chrome Origin Trials dashboard. To learn more about origin trials in Chrome, visit the Origin Trials Guide for Web Developers. Microsoft Edge runs its own origin trials separate from Chrome. To learn more, see the Microsoft Edge Origin Trials Developer Console. New Origin TrialsgetCurrentBrowsingContextMedia()The mediaDevices.getCurrentBrowsingContextMedia() method allows capturing a MediaStream with the current tab's video (and potentially audio), similar to getDisplayMedia(). Unlike getDisplayMedia(), calling this new method will eventually present the user with a simple accept/reject dialog box. If the user accepts, the current tab is captured. However, this will require some additional security measures which are still being finalized. Until then, or if the call is made with these measures absent, a dialog is displayed to the user that allows the selection of any source, but highlights the option of the current tab (whereas normally getDisplayMedia highlights the option of entire-screen).MediaStreamTrack Insertable Streams (a.k.a. Breakout Box)An API for manipulating raw media carried by MediaStreamTracks such as the output of a camera, microphone, screen capture, or the decoder part of a codec and the input to the decoder part of a codec. It uses WebCodecs interfaces to represent raw media frames and exposes them using streams, similar to the way the WebRTC Insertable Streams API exposes encoded data from RTCPeerConnections. This is intended to support use cases such as:

Funny Hats: Refers to manipulation of media either before encoding and after decoding to provide effects such as background removal, funny hats, voice effects.

Machine Learning: Refers to applications such as real-time object identification/annotation.

This origin trial is expected to run through Chrome 92.Subresource Loading with Web BundlesSubresource loading with Web Bundles provides a new approach to loading a large number of resources efficiently using a format that allows multiple resources to be bundled., e.g. Web Bundles.The output of JavaScript bundlers (e.g. webpack) doesn't interact well with browsers. They are good tools but:

Their output can't interact with the HTTP cache at any finer grain than the bundle itself (not solved with this origin trial). This can make them incompatible with new requirements like dynamic bundling (e.g. small edit with tree shaking could invalidate everything).

They force compilation and execution to wait until all bytes have arrived. Ideally loading multiple subresources should be able to utilize full streaming and parallelization, but that's not possible if all resources are bundled as one javascript. (This origin trial allows compilation to proceed in parallel. For JavaScript modules, execution still needs to wait for the entire tree due to the current deterministic execution model).

They can require non-JS resources like stylesheets and images to be encoded as JS strings, which forces them to be parsed twice and can increase their size. This origin trial allows those resources to be loaded in their original form.

This origin trial also allows a bundle to include the source for an opaque-origin iframe as urn:uuid: resources. The scheme for these resources is expected to change in Chrome 91.This origin trial is expected to run through Chrome 92.WebAssembly Exception HandlingWebAssembly now provides exception handling support. Exception handling allows code to break control flow when an exception is thrown. The exception can be any that is known by the WebAssembly module, or it may be an unknown exception that was thrown by a called imported function. This origin trial is expected to run through Chrome 94.Completed Origin TrialsThe following features, previously in a Chrome origin trial, are now enabled by default.WebXR AR Lighting EstimationLighting estimation allows sites to query for estimates of the environmental lighting conditions within WebXR sessions. This exposes both spherical harmonics representing the ambient lighting, as well as a cubemap texture representing "reflections". Adding Lighting Estimation can make your models feel more natural and like they "fit" better with the user's environment.Other Features in this ReleaseCSSaspect-ratio InterpolationThe aspect-ratio property allows for automatically computing the other dimension if only one of width or height is specified on any element. This property was originally launched as non-interpolable (meaning that it would snap to the target value) when animated. This feature provides smooth interpolation from one aspect ratio to another.Custom State Pseudo ClassesCustom elements now expose their states via the state CSS pseudo class. Built-in elements have states that can change over time depending on user interaction and other factors, which are exposed to web authors through pseudo classes. For example, some form controls have the "invalid" state, which is exposed through the :invalid pseudo class. Since custom elements also have states it makes sense to expose their states in a manner similar to built-in elements.Implement 'auto' value for appearance and -webkit-appearanceThe default values of CSS property appearance and -webkit-appearance for the following form controls are changed to 'auto'.

<input type=color> and <select>

Android only: <input type=date>, <input type=datetime-local>, <input type=month>, <input type=time>, and <input type=week>

Note that the default rendering of these controls are not changed.overflow: clip PropertyThe clip value for overflow results in a box's content being clipped to the box's overflow clip edge. In addition, no scrolling interface is provided, and the content cannot be scrolled by the user or programmatically. Additionally the box is not considered a scroll container, and does not start a new formatting context. As a result, this value has better performance than overflow: hidden.overflow-clip-margin PropertyThe overflow-clip-margin property enables specifying how far outside the bounds an element is allowed to paint before being clipped. It also allows the developer to expand the clip border. This is particularly useful for cases where there is ink overflow that should be visible.Permissions-Policy HeaderThe Permissions-Policy HTTP header replaces the existing Feature-Policy header for controlling delegation of permissions and powerful features. The header allows sites to more tightly restrict which origins can be granted access to features.The Feature Policy API, introduced in Chrome 74, was recently renamed to "Permissions Policy", and the HTTP header has been renamed along with it. At the same time, the community has settled on a new syntax, based on structured field values for HTTP.Protect application/x-protobuffer via Cross-Origin-Read-Blocking Protect application/x-protobuffer from speculative execution attacks by adding it to the list of never sniffed MIME types used by Cross-Origin-Read-Blocking. application/x-protobuf is already protected as a never sniffed mime type. application/x-protobuffer is another commonly used MIME type that is defined as an "ALT_CONTENT_TYPE" by the protobuf library. Seeking Past the End of a File in the File System Access APIWhen data is passed to FileSystemWritableFileStream.write() that would extend past the end of the file, the file is now extended by writing 0x00 (NUL). This enables creating sparse files and greatly simplifies saving content to a file when the data to be written is received out of order.
Without this functionality, applications that receive file contents out of order (for example, BiTtorrent downloads) would have to manually resize the file either ahead of time or when needed during writing.StaticRange ConstructorCurrently, Range is the only constructible range type available to web authors. However, Range objects are "live" and maintaining them can be expensive. For every tree change, all affected Range objects need to be updated. The new StaticRange objects are not live and represent a lightweight range type that is not subject to the same maintenance cost as Range. Making StaticRange constructible allows web authors to use them for ranges that do not need to be updated on every DOM tree change.Support Specifying Width and Height on <source> Elements for <picture>The <source> element now supports width and height properties when used inside a <picture> element. This allows Chrome to compute an aspect ratio for <picture> elements. This matches similar behavior for <img>, <canvas> and <video> elements.WebAudio: OscillatorOptions.periodicWave is Not NullableIt is no longer possible to set periodicWave to null when creating a new OscillatorNode object. This value is set on the options object passed to the OscillatorNode() constructor. The WebAudio spec doesn't allow setting this value to null. Chrome now matches both the spec and Firefox. JavaScriptThis version of Chrome incorporates version 9.0 of the V8 JavaScript engine. It specifically includes the changes listed below. You can find a complete list of recent features in the V8 release notes.Relative Indexing Method for Array, String, and TypedArraysArray, String, and TypedArray now support the at() method, which supports relative indexing with negative numbers. For example, the code below returns the last item in the given array.let arr = [1,2,3,4]; arr.at(-1); Deprecations, and RemovalsThis version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.Remove Content Security Policy Directive 'plugin-types'The 'plugin-types' directive allows developers to restrict which types of plugin can be loaded via <embed> or <object> html elements. This allowed developers to block Flash in their pages. Since Flash support has been discontinued, there is no longer any need for this policy directive.Remove WebRTC RTP Data ChannelsChrome has removed support for the non-standard RTP data channels in WebRTC. Users should use the standard SCTP-based data channels instead.Return Empty for navigator.plugins and navigator.mimeTypesChrome now returns empty for navigator.plugins and navigator.mimeTypes. With the removal of Flash, there is no longer the need to return anything for these properties.

Advanced memory management and more performance improvements in M89

Thursday, March 11, 2021

Boosting performance while adding features, functionality, and improving security, requires deep and continuous investment. Today’s post is the first in a series this year that will go into more technical detail about Chrome's ongoing efforts around performance. In this release, we’ve dug deep into the core of Chrome, upgrading how we allocate and discard memory, and even how we build, package, and run Chrome, to make today’s Chrome even faster and more memory efficient.

Improving memory managementIn Chrome M89, we’re seeing significant memory savings on Windows--up to 22% in the browser process, 8% in the renderer, and 3% in the GPU. Even more than that, we’ve improved browser responsiveness by up to 9%. We’ve achieved this by using PartitionAlloc, our own advanced memory allocator, which is optimized for low allocation latency, space efficiency, and security. For some time now, PartitionAlloc has been used extensively within Blink, our renderer codebase. Starting in M89, we’ve upgraded Chrome on Android and 64-bit Windows to use PartitionAlloc everywhere (by intercepting malloc).
In addition to improving how we allocate memory, Chrome is now smarter about using (and discarding) memory. Chrome now reclaims up to 100MiB per tab, which is more than 20% on some popular sites, by discarding memory that the foreground tab is not actively using, such as big images you’ve scrolled off screen. Chrome is also shrinking its memory footprint in background tabs on macOS, something we’ve been doing on other platforms for a while. We’re seeing up to 8% memory savings, which is more than 1GiB in some cases!
Finally, with more data from the field on tab throttling, we’re seeing up to 65% improvement on Apple Energy Impact score for tabs in the background, keeping your Mac cooler and those fans quiet.

Build, packaging, and runtime improvementsFocusing on Chrome for Android, we have a uniquely challenging job of building a great browser for every single variant of Android device. In this release we’re taking advantage of some packaging and runtime optimizations to deliver better performance in the Chrome that is in your pocket.
Some new Play and Android capabilities allowed us to repackage Chrome on Android, and we’re seeing fewer crashes due to resource exhaustion, a 5% improvement in memory usage, 7.5% faster startup times, and up to 2% faster page loads. Android App Bundles allow the Play Store to generate optimized APKs for each user’s device configuration, and allows packaging code and resources in split APKs, which are installed alongside the base APK. And an Android O feature, isolatedSplits, allows these feature splits to be loaded on demand, reducing Chrome’s overall startup cost.
For those of you who picked up the latest Android devices (Android Q+ and 8GB+ of RAM), we’ve rebuilt Chrome as a 64-bit binary, giving you a more stable Chrome that is up to 8.5% faster to load pages and 28% smoother when it comes to scrolling and input latency.
Finally, we’ve built a way for Chrome on Android to start up 13% faster: Freeze-Dried Tabs. Chrome now saves a lightweight version of your tabs that are similar in size to a screenshot, but support scrolling, zooming, and tapping on links. We use these Freeze-Dried Tabs at startup while the actual tab loads in the background, getting you to your pages faster. See it in action below:

Our teams are always working hard to bring you the fastest and most powerful browser on every one of your devices. We’re very excited to bring you these performance improvements and have much more to come, so stay tuned.
Posted by Mark Chang, Chrome Product Manager
Data source for all statistics: Real-world data anonymously aggregated from Chrome clients.

Speeding up Chrome's release cycle

Thursday, March 4, 2021

For more than a decade, Chrome has shipped a new milestone every 6 weeks, delivering security, stability, speed and simplicity to our users and the web. As we have improved our testing and release processes for Chrome, and deployed bi-weekly security updates to improve our patch gap, it became clear that we could shorten our release cycle and deliver new features more quickly. Because of this, we are excited to announce that Chrome is planning to move to releasing a new milestone every 4 weeks, starting with Chrome 94 in Q3 of 2021.

Additionally, we will add a new Extended Stable option, with milestone updates every 8 weeks. Extended Stable will be available to enterprise administrators and Chromium embedders who need additional time to manage updates. Security updates on Extended Stable will be released every two weeks to fix important issues, but those updates won’t contain new features or all security fixes that the 4 week option will receive.

For users on Chrome OS, we also plan to support multiple stable release options. We’ll have more to share with Chrome OS administrators in the coming months about the choices you’ll have for milestone updates to your managed devices.

We have updated the documentation for our new release schedule, and we welcome feedback from Chromium contributors at branches@chromium.org. We’ve also published a preliminary update to our release calendar that we’ll keep up to date as we get closer to launching our new release schedule.

We’re excited to continue evolving Chrome, and providing the best in security, stability, speed and simplicity to our users, even more rapidly in the future!

Alex Mineer, Technical Program Manager, Chrome Operations

Chromium Blog