This would allow us to say that one stub routine requires another stub routine to be alive.
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.
<rdar://problem/128886060>
Pull request: https://github.com/WebKit/WebKit/pull/29187
Committed 279410@main (5dec07a85f6e): <https://commits.webkit.org/279410@main> Reviewed commits have been landed. Closing PR #29187 and removing active labels.