About half of the SharedFunctionInfo created in Gmail are not compiled and not called.
By reducing size of uncompiled SharedFunctionInfos we can save up to 5MB in Gmail.
I think we can merge code, function-data and preparsed-scope-data as they aren't used at the same time.
ConstructStubOffset we can probably replace with a bitfield if there's still some place somewhere.
I don't think we need instance_class_name anymore since it's only used from function templates; and we can fetch class_name from the template if there is one.
I'm not sure we actually need function_literal_id on the SFI since it seems we only use it from literals which have the ID. Either we index with literal->id() into a list of SFI to find the matching SFI, or we store the created SFI for literal in that list. We might want to have it only in debugmode to verify we're finding the correct one.
I'm not sure about merging code and function-data -- e.g. code stores the InterpreterEntryTrampoline when function-data is the BytecodeArray, and we have quite a bit of code that assumes that you can jump to the shared function code. Probably a similar story for Asm->Wasm data.
We're also considering using function_literal_id as a SFI identifier if we were to do "incremental code caching" (one of our options for improving code cache behaviour, not our current main one but one that I'd prefer to keep open).
Comment 1 by verwa...@chromium.org
, Nov 11 2017