148914 2015-09-06 13:01:57 -0700 [JSC] Do not use disallowStubs 2024-05-28 16:31:05 -0700 1 1 1 Unclassified WebKit JavaScriptCore Other All All RESOLVED FIXED InRadar P2 Normal --- 148915 1 fpizlo ysuzuki webkit-bug-importer ysuzuki oldest_to_newest 1124030 0 fpizlo 2015-09-06 13:01:57 -0700 This would allow us to say that one stub routine requires another stub routine to be alive. 1124322 1 fpizlo 2015-09-08 11:29:42 -0700 This could also be addressed by having stub routines hold RefPtr's to each other. For example, in the case of a getter, we have the following objects: 1) PolymorphicAccess 2) AccessCase 3) CallLinkInfo 4) JITStubRoutine for PolymorphicAccess 5) JITStubRoutine for CallLinkInfo Currently we would have the following ownership/ref rules: (1) owns (2) (2) owns (3) (1) refs (4) (3) refs (5) Everything would be fine if we also added: (5) refs (4) This feels like it might be a bit ad-hoc and certainly not as flexible if these were GC cells. But, it would work! In particular: - If (5) gets deleted, then (3)->(5) must have been cleared first. - If (4) gets deleted, then (1)->(4) and (5)->(4) must have been cleared first. - If the owning stub gets destroyed, then everyone gets deleted. Basically, there is no case where things leak and there is no case where a dangling pointer is left behind. This could be implemented by giving CallLinkInfo a pointer to its owning JIT stub routine, or more generally, its "JIT owner". This would mean that we'd also have: (3) refs (4). Then, when the CallLinkInfo needs to spawn a stub routine, it can ensure that this new stub routine refs the stub that owned the CallLinkInfo. 2038260 2 webkit-bug-importer 2024-05-28 12:58:29 -0700 <rdar://problem/128886060> 2038261 3 ysuzuki 2024-05-28 13:01:44 -0700 Pull request: https://github.com/WebKit/WebKit/pull/29187 2038320 4 ews-feeder 2024-05-28 16:31:03 -0700 Committed 279410@main (5dec07a85f6e): <https://commits.webkit.org/279410@main> Reviewed commits have been landed. Closing PR #29187 and removing active labels.