IndexedDB: Add memory dump reporting for SQLite backing store [chromium/src : main]

0 views
Skip to first unread message

Xiaohan Zhao (Gerrit)

unread,
May 18, 2026, 8:01:25 PM (3 days ago) May 18
to Abhishek Shanthkumar, Evan Stade, Steve Becker, Chromium LUCI CQ, android-bu...@system.gserviceaccount.com, chromium...@chromium.org, grt+...@chromium.org, dmurph+watching...@chromium.org, dmurph+wa...@chromium.org, edgesto...@microsoft.com, enne...@chromium.org, spang...@chromium.org, storage...@chromium.org, tracing...@chromium.org, wfh+...@chromium.org
Attention needed from Abhishek Shanthkumar, Evan Stade and Steve Becker

Xiaohan Zhao added 5 comments

Commit Message
Line 7, Patchset 2:Add memory dumping support for IndexedDB SQLite connections.
Abhishek Shanthkumar . resolved

Can we briefly describe the name and structure of the memory dumps being added?

Xiaohan Zhao

Done

Line 9, Patchset 2:Bug: 40253999
Evan Stade . resolved

can you file a more specific bug for this please?

Xiaohan Zhao

Done

File base/trace_event/memory_infra_background_allowlist.cc
Line 337, Patchset 2: "site_storage/index_db/db_0x?",
Evan Stade . resolved

nit: these should be indexed_db

Xiaohan Zhao

Done

Line 338, Patchset 2: "site_storage/index_db/memenv_0x?",
Evan Stade . resolved

memenv and db both seem unused? When did that become the case? Can we fix this?

Abhishek Shanthkumar

They are both set by [TransactionalLevelDBDatabase::OnMemoryDump](https://source.chromium.org/chromium/chromium/src/+/main:components/services/storage/indexed_db/transactional_leveldb/transactional_leveldb_database.cc?q=site_storage%2Findex_db&ss=chromium).

Xiaohan Zhao

Done

File content/browser/indexed_db/instance/bucket_context.cc
Line 1116, Patchset 2: static_cast<sqlite::BackingStoreImpl*>(backing_store())
Evan Stade . resolved

all interaction with the backing store (except construction) should go through the backing store interface, meaning this cast should not be necessary.

Abhishek Shanthkumar

Adding to this, I believe we need to redefine what memory dumps IndexedDB makes in the SQLite world. Currently, with LevelDB:
1. `BucketContext::OnMemoryDump` dumps in-flight memory.
2. `TransactionalLevelDBDatabase::OnMemoryDump` dumps db memory size + leveldb file name.

Both of the above emit to the same identifier presumably so that in-flight memory can be mapped to the origin (gleanable from the levelDB file name that appears against the db memory entry).

In the SQLite case, the existing `DatabaseMemoryDumpProvider::OnMemoryDump` dumps useful sizes under the "IndexedDB_connection" component, with the tag being the address of the specific instance.

It would be good to:

  • Sum and report all those individual db sizes under the `site_storage/index_db` component (similar to (2) for LevelDB above) per origin (BucketContext instance), and
  • Continue providing some attribution from opaque identifiers to the origin, similar to (1) for LevelDB above.
Xiaohan Zhao

Thanks @abhishek.s...@microsoft.com! I want to make sure I implement the intended dump shape.

For SQLite, do you want a single bucket-scoped total dump like `site_storage/indexed_db/sqlite_0x<bucket>` whose size is the sum of all open SQLite connections for that `BucketContext`, plus per-connection child dumps linked/suballocated to the existing `sqlite/IndexedDB_connection/0x...` dumps for attribution?

Also, when you say "per origin (BucketContext instance)", should this be scoped per `BucketContext` rather than adding up all buckets for the same origin?

Abhishek Shanthkumar

Yep, that sounds right structure-wise, thanks! We can iterate on the names (it kind of makes sense not to have "sqlite" in the name under indexed_db, but keeping it "db" to match LevelDB is also misleading) subsequently.

Also, when you say "per origin (BucketContext instance)", should this be scoped per BucketContext rather than adding up all buckets for the same origin?

`BucketContext` is one per origin (with the potential exception of special cases such as third-party origin embeddings), but yes, I do specifically mean one entry per `BucketContext`.

Xiaohan Zhao

Thanks for verifying this! The structure I'm seeing locally in chrome://tracing looks like these.

// site_storage/indexed_db/
// sqlite_0x<bucket> (total, + file_name for origin)
// connection_0x<conn> (per-connection, suballoc → sqlite/IndexedDB_connection/0x?)

I also uploaded the screenshots to the related [bug](https://issues.chromium.org/512908976#attachment76932310).
Please let me know if I should adjust anything. Thanks!

Open in Gerrit

Related details

Attention is currently required from:
  • Abhishek Shanthkumar
  • Evan Stade
  • Steve Becker
Submit Requirements:
  • requirement satisfiedCode-Coverage
  • requirement is not satisfiedCode-Owners
  • requirement is not satisfiedCode-Review
  • requirement is not satisfiedReview-Enforcement
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
Gerrit-MessageType: comment
Gerrit-Project: chromium/src
Gerrit-Branch: main
Gerrit-Change-Id: Iaf253a9bb32ad3a4a07868d5e92878a33c3e32c6
Gerrit-Change-Number: 7807951
Gerrit-PatchSet: 4
Gerrit-Owner: Xiaohan Zhao <xiaoh...@microsoft.com>
Gerrit-Reviewer: Abhishek Shanthkumar <abhishek.s...@microsoft.com>
Gerrit-Reviewer: Steve Becker <ste...@microsoft.com>
Gerrit-Reviewer: Xiaohan Zhao <xiaoh...@microsoft.com>
Gerrit-CC: Evan Stade <evan...@microsoft.com>
Gerrit-Attention: Evan Stade <evan...@microsoft.com>
Gerrit-Attention: Abhishek Shanthkumar <abhishek.s...@microsoft.com>
Gerrit-Attention: Steve Becker <ste...@microsoft.com>
Gerrit-Comment-Date: Tue, 19 May 2026 00:01:16 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Xiaohan Zhao <xiaoh...@microsoft.com>
Comment-In-Reply-To: Evan Stade <evan...@microsoft.com>
Comment-In-Reply-To: Abhishek Shanthkumar <abhishek.s...@microsoft.com>
satisfied_requirement
unsatisfied_requirement
open
diffy

Abhishek Shanthkumar (Gerrit)

unread,
May 20, 2026, 10:46:22 AM (yesterday) May 20
to Xiaohan Zhao, Evan Stade, Steve Becker, Chromium LUCI CQ, android-bu...@system.gserviceaccount.com, chromium...@chromium.org, grt+...@chromium.org, dmurph+watching...@chromium.org, dmurph+wa...@chromium.org, edgesto...@microsoft.com, enne...@chromium.org, spang...@chromium.org, storage...@chromium.org, tracing...@chromium.org, wfh+...@chromium.org
Attention needed from Steve Becker and Xiaohan Zhao

Abhishek Shanthkumar added 8 comments

Patchset-level comments
File-level comment, Patchset 4 (Latest):
Abhishek Shanthkumar . resolved

Thanks! Some feedback on the high-level approach below.

Commit Message
Line 12, Patchset 4 (Latest):- `sqlite_0x<bucket>`: total SQLite memory across all open connections for the bucket. Includes a file_name attribute (non-background) for origin
Abhishek Shanthkumar . unresolved

nit: limit each line to 72 chars (you can just use the Format option while editing the commit message in Gerrit).

Line 19, Patchset 4 (Latest):`sql::Database::ReportMemoryUsage()` is restored to power the
Abhishek Shanthkumar . unresolved

Right, the [code comment on `DatabaseMemoryDumpProvider::ReportMemoryUsage`](https://source.chromium.org/chromium/chromium/src/+/main:sql/database_memory_dump_provider.h;l=44;bpv=1;bpt=1) refers to a call by `sql::Database` that does not exist currently. Were we able to find the commit that removed the call, just in case it has additional context that would be interesting to know?

File base/trace_event/memory_infra_background_allowlist.cc
Line 354, Patchset 4 (Latest): "sqlite/IndexedDB_connection/0x?",
Abhishek Shanthkumar . unresolved

The comment at the top of the file says "... providers can be added here only if the background mode dump has very little processor and memory overhead." Do we know that this sqlite trace has low overhead? If we're unsure, we should probably exclude considering that no other sqlite traces have been allowlisted currently.

File content/browser/indexed_db/instance/backing_store.h
Line 313, Patchset 4 (Latest): const std::string& dump_name) {}
Abhishek Shanthkumar . unresolved

We should make this pure virtual (`= 0`) and add a comment with empty body in the leveldb backing store explaining why it doesn't implement this.

File content/browser/indexed_db/instance/sqlite/backing_store_impl.cc
Line 262, Patchset 4 (Latest): total_size += connection->ReportMemoryUsage(
pmd, base::StringPrintf("%s/connection_0x%" PRIXPTR, dump_name.c_str(),
reinterpret_cast<uintptr_t>(connection.get())));
Abhishek Shanthkumar . unresolved

I believe we also need to `AddOwnershipEdge`s from the `sqlite_0x` dump name to the individual `connection_0x` dumps, without which this size and the individual sizes will be counted twice in overall memory usage. Note how the LevelDB backing store does the same (in `TransactionalLevelDBDatabase::OnMemoryDump`).

Line 275, Patchset 4 (Latest): dump->AddString("file_name", "", directory_.AsUTF8Unsafe());
Abhishek Shanthkumar . unresolved

perhaps we can just log the base name of the directory. But I wonder if we can somehow log the sanitized origin itself (if available with BucketContext) instead of this directory name. Is there precedence in other dump providers to log the origin?

File sql/database.h
Line 557, Patchset 4 (Latest): // Reports memory usage into provided memory dump with the given name.
Abhishek Shanthkumar . unresolved
vnit
```suggestion
// Reports memory usage into the provided memory dump with the given name.
```
Open in Gerrit

Related details

Attention is currently required from:
  • Steve Becker
  • Xiaohan Zhao
Submit Requirements:
    • requirement satisfiedCode-Coverage
    • requirement is not satisfiedCode-Owners
    • requirement is not satisfiedCode-Review
    • requirement is not satisfiedNo-Unresolved-Comments
    • requirement is not satisfiedReview-Enforcement
    Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
    Gerrit-MessageType: comment
    Gerrit-Project: chromium/src
    Gerrit-Branch: main
    Gerrit-Change-Id: Iaf253a9bb32ad3a4a07868d5e92878a33c3e32c6
    Gerrit-Change-Number: 7807951
    Gerrit-PatchSet: 4
    Gerrit-Owner: Xiaohan Zhao <xiaoh...@microsoft.com>
    Gerrit-Reviewer: Abhishek Shanthkumar <abhishek.s...@microsoft.com>
    Gerrit-Reviewer: Steve Becker <ste...@microsoft.com>
    Gerrit-Reviewer: Xiaohan Zhao <xiaoh...@microsoft.com>
    Gerrit-CC: Evan Stade <evan...@microsoft.com>
    Gerrit-Attention: Xiaohan Zhao <xiaoh...@microsoft.com>
    Gerrit-Attention: Steve Becker <ste...@microsoft.com>
    Gerrit-Comment-Date: Wed, 20 May 2026 14:46:12 +0000
    Gerrit-HasComments: Yes
    Gerrit-Has-Labels: No
    satisfied_requirement
    unsatisfied_requirement
    open
    diffy
    Reply all
    Reply to author
    Forward
    0 new messages