RESOLVED FIXED 228092
[JSC] StructureStubInfo's m_identifier should follow to the same protocol of inlineAccessBaseStructure
https://bugs.webkit.org/show_bug.cgi?id=228092
Summary [JSC] StructureStubInfo's m_identifier should follow to the same protocol of ...
Yusuke Suzuki
Reported 2021-07-19 15:59:19 PDT
[JSC] StructureStubInfo's m_identifier should follow to the same protocol of inlineAccessBaseStructure
Attachments
Patch (14.93 KB, patch)
2021-07-19 16:02 PDT, Yusuke Suzuki
saam: review+
Yusuke Suzuki
Comment 1 2021-07-19 16:02:08 PDT
Saam Barati
Comment 2 2021-07-19 16:13:56 PDT
Comment on attachment 433831 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=433831&action=review r=me > Source/JavaScriptCore/ChangeLog:10 > + m_identifier field too. This patch makes m_identifier follow to the same protocol of inlineAccessBaseStructure > + so that we fix this race issue too. I'd document just for completeness what we're doing specifically (so folks don't have to read r279813 change) > Source/JavaScriptCore/bytecode/StructureStubInfo.cpp:-422 > -void StructureStubInfo::setCacheType(const ConcurrentJSLockerBase&, CacheType newCacheType) I would keep this function. It's nice to document/enforce that we're holding the lock. See https://trac.webkit.org/changeset/264388/webkit
Mark Lam
Comment 3 2021-07-19 16:22:14 PDT
Comment on attachment 433831 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=433831&action=review >> Source/JavaScriptCore/bytecode/StructureStubInfo.cpp:-422 >> -void StructureStubInfo::setCacheType(const ConcurrentJSLockerBase&, CacheType newCacheType) > > I would keep this function. It's nice to document/enforce that we're holding the lock. See https://trac.webkit.org/changeset/264388/webkit Maybe make it inline since it's no-op function now?
Yusuke Suzuki
Comment 4 2021-07-19 16:26:59 PDT
Comment on attachment 433831 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=433831&action=review >>> Source/JavaScriptCore/bytecode/StructureStubInfo.cpp:-422 >>> -void StructureStubInfo::setCacheType(const ConcurrentJSLockerBase&, CacheType newCacheType) >> >> I would keep this function. It's nice to document/enforce that we're holding the lock. See https://trac.webkit.org/changeset/264388/webkit > > Maybe make it inline since it's no-op function now? For now, I'll just make it ALWAYS_INLINE void StructureStubInfo::setCacheType(const ConcurrentJSLockerBase&, CacheType newCacheType) { m_cacheType = newCacheType; } But personally, thread-safety-annotation would be better to me in this case since we already get Locker parameter in each function which modifies this field. (but currently, not sure how to annotate it via that if it depends on CodeBlock's lock.
Yusuke Suzuki
Comment 5 2021-07-19 18:30:07 PDT
Radar WebKit Bug Importer
Comment 6 2021-07-19 18:31:17 PDT
Note You need to log in before you can comment on or make changes to this bug.