Bug 148914

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.