|Summary:||[ftlopt] Factor out how CallLinkStatus uses exit site data|
|Product:||WebKit||Reporter:||Filip Pizlo <fpizlo>|
|Severity:||Normal||CC:||barraclough, ggaren, mark.lam, mhahnenberg, msaboff, oliver, sam|
|Version:||528+ (Nightly build)|
|Bug Depends on:|
Description Filip Pizlo 2014-05-17 22:47:27 PDT
We need to query exit site data while holding a different lock then when we query all of the other data. Currently, CallLinkStatus knows what to query but it does so behind an opaque API that assumes that it's querying the CallLinkInfo for a op_call/op_construct instruction. This would make it difficult to integrate with a different Status class that wants to use a CallLinkInfo that is embedded inside a stub, like GetByIdStatus or PutByIdStatus - those will only see that there is a CallLinkInfo for which to compute status while they are already holding the "wrong" lock for computing exit site data. We should refactor things so that: - You can ask CallLinkStatus to compute exit site data - essentially an opaque data token - without giving it the CallLinkInfo. - You can pass the exit site data and the CallLinkInfo and get a complete CallLinkStatus. - Do what you do now - i.e. we shouldn't change the existing API that just does all of this for you.