Currently, once the type profiler starts asking for type information, it never stops until we stop viewing a JS file or encounter an error. We should make the annotators smarter at pinging for information only when we know that the information could have changed. I think a good way to approach this would be to send an inspector event when JS code executes after not executing. As Brian pointed out, on a run loop tick where JS executes. I think another good metric would be to send an event when we clear the type profiler log. Anybody have ideas on an effective way of accomplishing this?
<rdar://problem/19583678>
I think this is the current plan: Use events to drive UI updates. What would trigger an event: 1. JSC::TypeProfilerLog being cleared. - This happens on GC and when the log fills up 2. Some timer in the inspector goes off and JSC::TypeProfilerLog has data in it - This is to prevent situations where data is sitting in the log waiting to be processed, but no GC occurs and the log doesn't fill up. 3. JSC::ControlFlowProfiler will now incorporate a dirty bit. When we emit code for op_profile_control_flow, we can write to this dirty bit indicating that some code has executed. We can then have a timer in the inspector that checks for this dirty bit and issues events to signal when there is new data.
Created attachment 247098 [details] work in progress it begins!
Created attachment 247104 [details] work in progress events are actually being called now when the TypeProfilerLog clears its entries. TypeProfilerLog will need to be changed to support multiple listeners for this call back in case there is more than one inspector inspecting the VM.
Created attachment 247604 [details] work in progress Just want to upload work here so I can clear off local branch until we get timers into JSC.