Skip to content

[ObjC] Store Objective-C metadata in the database instead of regenerating it on load - #8411

Open
bdash wants to merge 1 commit into
test_metadata_flagsfrom
test_objc_metadata
Open

[ObjC] Store Objective-C metadata in the database instead of regenerating it on load#8411
bdash wants to merge 1 commit into
test_metadata_flagsfrom
test_objc_metadata

Conversation

@bdash

@bdash bdash commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

Processed Obj-C metadata was stored ephemerally on the view and not serialized to the .bndb. On reopen the Obj-C processor had to be re-run on every loaded image to regenerate the metadata, which caused many functions to be reanalyzed due to types and symbols being reapplied. Commit 1bb0012 tried to suppress that from inside DefineObjCSymbol but ended up skipping method type application on fresh shared-cache loads. As a result, methods whose names were already in the symbol table (some methods in macOS shared caches) did not have argument types applied.

We now save the Objective-C metadata to the .bndb and only process Objective-C data in the binary if the metadata is absent or out of date. Additionally, each ProcessObjCData call now merges its output into any existing metadata so multiple shared cache images accumulate metadata into a single unified object instead of clobbering each other.

An "Objective-C Literals" metadata key is added with its own version, so future changes to Obj-C literal processing can force reprocessing on existing databases without touching the main Obj-C metadata version.

The changes made to ObjCProcessor in 1bb0012 are reverted as they were incorrect and are no longer needed with this new approach.

Fixes #8087.

…ting it on load

Processed Obj-C metadata was stored ephemerally on the view and not
serialized to the .bndb. On reopen the Obj-C processor had to be re-run
on every loaded image to regenerate the metadata, which caused many
functions to be reanalyzed due to types and symbols being reapplied.
Commit 1bb0012 tried to suppress that from inside
`DefineObjCSymbol` but ended up skipping method type application on
fresh shared-cache loads. As a result, methods whose names were already
in the symbol table (some methods in macOS shared caches) did not have
argument types applied.

We now save the Objective-C metadata to the .bndb and only process
Objective-C data in the binary if the metadata is absent or out of date.
Additionally, each `ProcessObjCData` call now merges its output into any
existing metadata so multiple shared cache images accumulate metadata
into a single unified object instead of clobbering each other.

An "Objective-C Literals" metadata key is added with its own version, so
future changes to Obj-C literal processing can force reprocessing on
existing databases without touching the main Obj-C metadata version.

The changes made to `ObjCProcessor` in 1bb0012 are reverted as they
were incorrect and are no longer needed with this new approach.

Fixes #8087.
Comment thread objectivec/objc.cpp
{
QualifiedName classTypeName = cls.name;
std::string classTypeId = Type::GenerateAutoTypeId("objc", classTypeName);
if (m_data->GetTypeById(classTypeId))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What was the purpose of moving this and removing the check, I assume this means that there is never any duplicate class type names?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This specific code comes from 1bb0012, and was part of trying to make processing Obj-C runtime metadata twice a no-op.

This new approach uses metadata stored on the view to know that it should entirely skip doing Obj-C processing when loading from a database, rather than trying (and failing) to make it into a no-op to process Obj-C runtime metadata twice.

@bdash
bdash requested a review from emesare August 14, 2026 14:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants