PartitionAlloc は Chromium のメモリ アロケータで、断片化が起こりにくく、高速で強固なセキュリティを持つように設計されています。この機能は、Blink（Chromium のレンダリング エンジン）で広く活用されています。Windows 64 ビット版と Android 版の Chrome 89 では、Chromium 全体のコードベースがあらゆる場所で PartitionAlloc を使うように移行されました（malloc() と new をインターセプトして置換しました）。実地でのデータによると、最大 22% の Chrome のメモリが節約され、応答速度とスクロールのレイテンシが最大 9% 改善されています。
3 月上旬に M89 リリースのロールアウトが開始された時点で、Windows のブラウザ プロセスのメモリ使用量を詳しく調査したものを示します。
Chrome は、マルチプラットフォーム、マルチプロセス、マルチスレッドのアプリケーションで、Android の小さな埋め込み WebView から宇宙船まで、実に幅広いニーズに対応しています。パフォーマンスとメモリのフットプリントは特に重要で、Chrome とメモリ アロケータには密接な統合が求められます。しかし、それぞれのプラットフォームには Linux と Chrome OS の tcmalloc、Android の jemalloc や scudo、Windows の LFH などの異なる実装があり、プラットフォームの違いを超えるのは難しい可能性もあります。このプロジェクトに着手したときの目標は、1）プラットフォーム間でメモリ割り当てを統一すること、2）セキュリティやパフォーマンスを損なうことなく最小メモリ フットプリントを実現すること、3）Chrome のパフォーマンスの最適化にふさわしいアロケータを実現することでした。そこで、Chromium のクロスプラットフォームなアロケータを使う決定をしました。これは、サーバーのワークロードではなくクライアントのメモリ使用量を最適化するため、そして実際の使用例を意識しないマイクロベンチマークではなく有意義なエンドユーザーの活動に注目するためです。
PartitionAlloc は、独立した複数のパーティション（重複しないメモリ領域）をサポートするように設計されました。Blink では、文字列とレイアウト オブジェクトを確実に分離するなど、一部の形態の型混同攻撃を阻むために、全体にわたってこのパーティションを活用しています。しかし、このアプローチでは、別のパーティションで割り当てられた型同士の衝突しか避けることはできません。さらに、衝突する可能性があるオブジェクトのサイズが異なる場合、型の混同を避けるため、PartitionAlloc バケットはサイズを使って割り当てをします。この手法が動作するのは、PartitionAlloc がアドレス空間を再利用しないからです。PartitionAlloc がアドレス空間のある領域を特定のパーティションとサイズのバケットに割り当てる場合、その領域は常にそのパーティションとサイズのバケットに所属することになります。
さらに、PartitionAlloc は、メモリ領域周辺のガードページ（アクセスできない範囲）によって一部のメタデータを保護します。しかし、すべてのメタデータが同じとは限りません。以前に割り当てられた領域内には、フリーリストのエントリが格納されるので、他の割り当てに囲まれることになります。破損したフリーリストのエントリと off-by-one オーバーフローをクライアントのコードから検知するため、これをコード化して隠蔽します。さらに、独自のアロケータが MiraclePtr や *Scan などの高度なセキュリティ機能を実現します。
PartitionAlloc の各パーティションは、メモリを節約するため、1 つの集中管理型のスラブベース アロケータを使用します。また、フロントでのスレッド単位のキャッシュは最低限にとどめ、マルチスレッドなワークロードにスケーリングできるようにしています。このシンプルな処理には、パフォーマンス面でのメリットもあります。Google は幅広いプロファイリングをし、アロケータの高速パスを徹底的に切り詰めました。これにより、スレッドローカルなストレージへのアクセスやロックが改善し、キャッシュ ラインの取得数は減少し、ブランチも削除できるようになっています。
PartitionAlloc は、仮想アドレス空間であらかじめスラブを予約します。割り当てリクエストが到着するにつれて、そこに物理メモリが徐々に割り当てられていきます。少量または中程度の割り当ては、[241; 256]、[257; 288] など、幾何学的に間隔を空けたサイズごとのバケットにグループ化されます。各スラブは、1 つの特定のバケットからのみ配分され、割り当て（「スロット」と呼ばれます）を満たす複数の領域（「スロットスパン」）に分割されます。そのため、キャッシュのローカル性は向上し、断片化は起こりにくくなります。逆に、大量の割り当てはバケットのロジックを通さず、直接オペレーティング システムのプリミティブ（POSIX システムでは mmap()、Windows では VirtualAlloc()）を利用して実現します。
この集中管理型アロケータは、パーティション単位の 1 つのロックによって保護されます。競合によるスケーラビリティの問題を緩和するため、スレッド単位の小さなスロットのキャッシュをフロントに追加し、3 層型アーキテクチャを実現しています。
最初のレイヤー（スレッド単位のキャッシュ）は、頻繁に利用される小さなバケットに属する少量のスロットを保持します。これらのスロットはスレッドごとに保存されるため、ロックなしに割り当てることができ、必要になるのは高速なスレッドローカル ストレージの検索のみです。そのため、プロセスでのキャッシュのローカル性が向上します。このスレッドごとのキャッシュは、2 つ目のレイヤーのメモリをまとめて割り当てと解放をすることで、大半のリクエストを満たせるように最適化されています。そのため、過度なメモリを確保することなく、ロックの取得頻度を下げ、ローカル性をさらに向上することができます。
この 2 つ目のレイヤー（スロットスパンのフリーリスト）は、スレッドごとのキャッシュでキャッシュミスが発生した場合に呼び出されます。PartitionAlloc は、それぞれのバケットのサイズについて、そのサイズに関連付けられた空きスロットがあるスロットスパンを把握しています。そのため、そのスパンのフリーリストからスロットを取得します。この処理もまだ高速パス上にありますが、ロックの取得が必要なので、スレッドごとのキャッシュよりは遅くなります。しかし、このセクションにアクセスされるのは、スレッドごとのキャッシュでは対応できない大きな割り当てがされる場合や、スレッドごとのキャッシュを埋めるバッチとして実行される場合のみです。
最後に、バケットに空きスロットがない場合は、3 つ目のレイヤー（スロットスパン管理）が新しいスロットスパン用にスラブから領域を切り出すか、オペレーティング システムからまったく新しいスラブを割り当てます。これは遅い処理ですが、まれにしか起こらないオペレーションです。このアロケータの全体的なパフォーマンスと領域の効率性は、キャッシュの量、バケットの数、メモリ再利用ポリシーなど、レイヤー間のさまざまなトレードオフ次第です。設計の詳細については、PartitionAlloc をご覧ください。全体として、PartitionAlloc が実現するさらなるメモリ節約とパフォーマンスの向上によって、安全、軽量、高速な Chrome が実現し、それを地球上や宇宙空間のユーザーに利用していただけることを期待しています。今後の改善や、近いうちにされるその他のプラットフォームのサポートにもご期待ください。
すべての統計情報の出典 : Chrome クライアントから匿名で集計した実データ。* 中心となる指標として、30 秒ごとにジャンク（ユーザーの入力を処理する際の遅延）を測定。
変更前 : 458 ミリ秒（そのうち 432 ミリ秒が Lock/Unlock/KiPageFault）変更後 : 27 ミリ秒
変更前 : 1 秒あたり 1.32 MB の割り当てが 30 回（30 fps のフレーム 1 つにつき 1 回。さらに高いフレームレートでは割り当てがさらに多くなる）、10 秒間で合計 396 MB変更後 : 0 回
変更前 : 36 ミリ秒変更後 : 0 ミリ秒
Chrome は、新しいパスワードを生成したり、保存されたパスワードの自動入力や同期をしたり、侵害されたパスワードについてユーザーに警告したりすることができます。つまり、ユーザーは自分でパスワードを管理する必要がなくなります。しかし、複数のドメインで同じアカウント管理バックエンドを利用している場合（たとえば、https://www.example.com と https://www.example.co.uk のような複数のトップレベル ドメイン）、Chrome はドメインをまたいで自動入力をしてくれません。その結果、異なるドメインに対して同じパスワードのエントリが 2 つできることになり、同期がとれなくなることもあります。
バージョン 91 以降の Chrome では、Digital Asset Links（DAL）で関連付けられたドメイン間で、保存したパスワードの自動入力が提案されます。DAL は、Android アプリとウェブサイトを関連付けるために、2015 年から利用されています。Chrome 91 では、サイト間で DAL を設定すると、Chrome がサイトをまたいでユーザーのログインをアシストしてくれます。DAL の関連付けをするには、両方のドメインの /.well-known/assetlinks.json に DAL 構文に従った JSON ファイルを配置する必要があります。
DAL の関連付けの詳しい設定方法については、すべての連携サイトで Chrome がログイン認証情報を共有できるようにするをご覧ください。
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 4 月 22 日の時点で Chrome 91 はベータ版です。
このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジントライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジントライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルをしています。詳細については、Microsoft Edge オリジントライアル デベロッパー コンソールをご覧ください。
新しいウェブアプリ マニフェストのメンバーとして、capture_links が追加されます。これを使うと、ユーザーがインストール済みのウェブアプリのスコープ内でページを移動したときの動作をコントロールできます。ユーザーがアプリへのリンクをクリックしたときに自動的に新しい PWA ウィンドウを開いたり、モバイルアプリのようなシングル ウィンドウ モードにしたりすることが可能です。オリジン トライアルに登録すると、オリジントライアル ダッシュボードで詳細を確認できます。
capture_links
WebTransport は、ウェブのセキュリティ モデルの制約を受けるクライアントがリモート サーバーと通信する際に、安全な多重化転送をできるようにするプロトコル フレームワークです。
現在、ウェブ アプリケーション デベロッパーがリモート サーバーと双方向通信をする場合、WebSockets と RTCDataChannel という 2 つの API を使うことができます。WebSockets は TCP ベースなので、すべての TCP の欠点（ヘッドオブライン ブロッキング、信頼できないデータ転送の未サポート）を引き継ぐことになり、レイテンシが重要なアプリケーションには適しません。RTCDataChannel は Stream Control Transmission Protocol（SCTP）ベースなので、そのような欠点はありません。しかし、ピアツーピアで使うことを念頭に置いて設計されているので、クライアント サーバー設定で使われることはほとんどありません。WebTransport は、信頼できないデータと信頼できるデータの両方の双方向通信をサポートするクライアント サーバー API で、UDP 的なデータグラムによるキャンセル可能なストリームを利用します。WebTransport の呼び出しは DevTools の [Network] パネルで確認できます。[Type] 列を見ると、このプロトコルが使われていることがわかります。
WebSockets
RTCDataChannel
WebTransport
詳しくは、WebTransport の試験運用をご覧ください。オリジン トライアルに登録すると、オリジントライアル ダッシュボードで詳細を確認できます。
WebXR アプリケーションで、ユーザーの環境内の平面についてのデータを取得できるようになります。これにより、低い処理能力でも高いユーザー エクスペリエンスを実現できます。この機能なしに平面検出をするには、MediaDevices.getUserMedia() のデータを利用してカスタムのコンピュータ ビジョン アルゴリズムを実行する必要があります。通常、このようなソリューションは、AR エクスペリエンスに求められる質や精度を満たせず、ワールドのスケールもサポートされません。オリジン トライアルに登録すると、ダッシュボードで詳細を確認できます。
MediaDevices.getUserMedia()
Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。
サイトがユーザー エージェントに対し、ページよりもユーザー エージェントのほうが得意とする方法で電池寿命を節約し、CPU の利用を最適化することを推奨できるようになります。たとえば、フレームレートを落とすことを許可したり、スクリプトの速度を下げることを許可したりできます。詳しくは、解説をご覧ください。
ユーザーがページ内検索をし、ある要素で一致するテキストが見つかると、beforematch イベントが発行されます。これまでは、content-visiblity が hidden に設定されていた場合、このイベントは発行されませんでした。content-visibility: hidden-matchable CSS プロパティは、content-visibility: hidden と同じように動作しますが、ページ内検索で非表示テキストを検索でき、beforematch イベントも発行されます。beforematch イベントと content-visibiliy: hidden-matchable を組み合わせて使うと、ページ内検索に反応して非表示コンテンツを展開するウェブサイトを実現できます。詳しくは、解説をご覧ください。
beforematch
content-visiblity
hidden
content-visibility: hidden-matchable
content-visibility: hidden
content-visibiliy: hidden-matchable
WebAssembly SIMD は、プラットフォームに依存しない方法でハードウェア SIMD 命令を WebAssembly アプリケーションに公開します。これにより、さまざまな種類の圧縮データを表す新しい 128 ビット型や、圧縮データを扱ういくつかのベクトル演算を導入できます。SIMD は、データレベルの並列化を利用してパフォーマンスを大きく向上できることに加え、ネイティブ コードを WebAssembly にコンパイルする場合にも役立ちます。詳しくは、WebAssembly SIMD の V8 機能の解説をご覧ください。
サイト分離の有無に基づいた performance.now() と関連するタイムスタンプの精度を下げる処理が、プラットフォーム間で一貫した動作になりました。これにより、デスクトップ版の分離されていないコンテキストでは、解像度が 5 マイクロ秒から 100 マイクロ秒に下がります。また、Android 版でクロスオリジン分離されているコンテキストでは、解像度が 100 マイクロ秒から 5 マイクロ秒に上がります。
performance.now()
デスクトップ版で、アプリがクリップボードからファイルを読み取ることができるようになります（ただし、クリップボードにファイルを書き込むことはできません）。アプリは、クリップボードのファイルに読み取り専用でアクセスします。
async function onPaste(e) { let file = e.clipboardData.files[0]; let contents = await file.text(); }
リストマーカーや CSS カウンターで CSS の @counter-style ルールを使うと、ウェブ制作者がカスタムのカウンター スタイルを指定できます。これは国際化に役立ちます。この変更は、以下を除くすべての CSS Counter Styles Level 3 機能で実装されます。
@counter-style
speak-as
symbols()
:host() と :host-context() 疑似クラスが、<compound-selector-list> に加えて単一の <compound-selector> を受け取れるようになります。
:host()
:host-context()
<compound-selector-list>
<compound-selector>
フォーム コントロールの外観が刷新され、ユーザー補助機能とタッチのサポートが向上します。これは Microsoft と Google の共同作業です。詳しい情報は、以前の CDS トークや Microsoft のブログ投稿をご覧ください。
今回のリリースでは、すでに他のプラットフォームでリリースしたものと同じフォーム コントロール UX を Android 版にも提供します。新しいフォーム コントロールには、ダークモードでフォーム コントロールやスクロールバーが自動的に暗い色になる機能が含まれています。
ダークモードは、ウェブ制作者がウェブページをダークモードで表示できるようにするユーザー補助機能です。これを有効にすると、ユーザーは Android デバイスでダークモード設定を切り替えることにより、サポートされているウェブサイトをダークモードで表示できます。ダークモードは低光量環境で目にやさしく、電池の消費も少なくなります。
GravitySensor インターフェースは、重力の 3 軸読み取り値を提供します。これまでも、Accelerometer の読み取り値から LinerAccelerometer の読み取り値を除くことで、このインターフェースで提供される値に近い値を算出することができました。
GravitySensor
Accelerometer
LinerAccelerometer
ウェブアプリで File System Access API を使う場合、作成または読み込みをするファイルやディレクトリの名前と場所を提案できるようになります。これにより、ユーザー エクスペリエンスが向上し、ウェブアプリの動作がシステムアプリに近づきます。File System Access API の詳細については、File System Access API: ローカル ファイルへのアクセスを簡単にするをご覧ください。
パーミッション ポリシーで許可されている場合、WebOTP API をクロスオリジン iframe で利用できるようになります。WebOTP API を使うと、プログラムによってそのオリジンが宛先となった特別な形式の SMS メッセージからワンタイム コードを読み取り、ユーザーの手間を減らすことができます。認証を扱う iframe は、多くのサイトに埋め込まれています。
Chrome は、Chromium の WebSockets over HTTP/2（RFC 8441 で規定）をサポートします。これは、すでに HTTP/2 で接続しており、サーバーが仕様で規定されている HTTP/2 の SETTINGS パラメータによって WebSockets over HTTP/2 のサポートをアドバタイズしていて、安全な WebSockets リクエストが行われた場合のみ利用されます。
2015 年より、デベロッパーは Digital Asset Links（DAL）を使って Android アプリとウェブサイトを関連付け、ユーザーのログインをアシストしています。複数のドメインで同じアカウント管理バックエンドを共有している場合は、それらを相互に関連付けることで、Chrome のパスワード マネージャーがすべての連携するウェブサイトで保存した認証情報を提案するようになります。詳しくは、すべての連携サイトで Chrome がログイン認証情報を共有できるようにするをご覧ください。
このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 9.1 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。
JavaScript が Service Worker でモジュールをサポートします。コンストラクタの type 属性に 'module' タイプを設定すると、ワーカーのスクリプトが ES モジュールとして読み込まれ、ワーカーのコンテキストで import 文が利用できるようになります。この機能を使うと、組み合わせ可能なプログラムを簡単に書けるようになり、ページやワーカー間でプログラムを共有しやすくなります。
'module'
import
#foo in obj 構文により、オブジェクトでプライベート フィールドの存在チェックをできるようになります。
#foo in obj
このバージョンの Chrome では、デベロッパーに関連するサポートの終了や機能の削除はありません。以前の機能の削除リストは、ChromeStatus.com をご覧ください。
Google Open Source Live イベントシリーズを開催いたします。
第 8 回目の今回のイベントは「Open data lake day」です。
Google に在籍するデータ アナリティクスのエキスパートが、オープンテーブル フォーマットや、イノベーションとクラウドのバリアの克服方法などについてお話しします。
セッション中には質問を投稿できるフォーラムが立ち上がります。Google 社員に直接質問ができるチャンスとなりますのでぜひ、ご活用ください。
また、セッション終了後に Google Meet にてアフターパーティーを開催いたします。他の参加者の方達と交流したり、Google オリジナルグッズが当たるクイズゲームなどをご用意しておりますのでぜひ、ご参加ください。
日本語版のイベントでは、日本語での MC、日本語の字幕付きセッション、そして日本語開催のアフターパーティーとなります。
英語版をご希望の方は太平洋時間の 9:00 am PST、日本語版をご希望の方は日本時間の 9:00 am JST にご参加ください。
事前お申込み受付中 : http://goo.gle/OpenDataLakeDayJP
名 称 『Open data lake day』
日 程 日本語版 : 5 月 7 日（金）9:00 am - 11:00 am JST （日本時間）
英 語 版 : 5 月 6 日（木）9:00 am - 11:00 am PST （太平洋時間）
対 象 開発エンジニア、インフラ エンジニア、運用エンジニア
参加費 無料（事前登録制）
登 録 http://goo.gle/OpenDataLakeDayJP
オープンソースによってイノベーションとクラウドの壁を取り除く
アマー・アワダラ
クラウド・デベロッパー・リレーションズ 担当 副社長 (Google)
バージョン 90 より、Chrome のアドレスバーで https:// がデフォルトとして使われるようになります。これによってプライバシーが向上し、HTTPS をサポートするウェブサイトにアクセスしたときの読み込み速度も上がります。Chrome ユーザーが手動で URL を入力してウェブサイトを開くとき、多くの場合は “http://” や “https://” を含めません。たとえば、アドレスバーに “https://example.com” ではなく “example.com” と入力することがよくあります。このとき、ユーザーが初めてそのウェブサイトを訪れる場合は、これまでの Chrome の動作ではデフォルトのプロトコルとして http:// が選択されていました 1。これは、ウェブの多くが HTTPS をサポートしていなかった過去においては、現実的なデフォルトでした。
今後は、プロトコルを指定せずに入力されたほとんどのナビゲーションで、Chrome のデフォルトが HTTPS になります 2。HTTPS は、安全性が向上しているだけでなく、すべての主要プラットフォームの Chrome で最も広く使われているスキームです。この変更により、セキュリティとプライバシーが明らかに向上することに加え、HTTPS をサポートするサイトの初回読み込み速度も上がります。Chrome が HTTPS エンドポイントに直接接続し、http:// から https:// にリダイレクトする必要がなくなるからです。まだ HTTPS をサポートしていないサイトでは、HTTPS による試行が失敗した後、HTTP にフォールバックします（名前の不一致、信頼できない自己署名証明書などの証明書エラーや、DNS の解決失敗などの接続エラーが発生した場合も含みます）。この変更は、まずバージョン 90 の Chrome デスクトップ版と Android 版にロールアウトされ、その後近いうちに iOS 版の Chrome にもリリースされます。
HTTPS では、ユーザーがウェブサイトに入力した機密情報が攻撃者や盗聴者によって傍受または改ざんされないように、ネットワークに送られるトラフィックを暗号化してユーザーを保護します。Chrome では、HTTPS をウェブのデフォルトのプロトコルにするための取り組みが行われています。今回の変更で、デフォルトで常に安全な接続を使うことに一歩近づきます。
1 主な例外の 1 つは、HSTS プリロード リストに含まれるサイトです。これらのサイトでは、常にデフォルトが HTTPS になります。 2 IP アドレス、シングルラベル ドメイン、test/ や localhost/ などの予約されているホスト名では、引き続き HTTP がデフォルトになります。
