Stop JIT hot spot counting #9343
Conversation
ext/opcache/jit/zend_jit_trace.c
Outdated
| op_array->opcodes[i].handler = jit_extension->trace_info[i].orig_handler; | ||
| SHM_PROTECT(); | ||
| } | ||
| zend_shared_alloc_unlock(); |
There was a problem hiding this comment.
Should this be outside the loop?
Yes, I will update
When max_root_trace is reached, JIT in tracing mode will not compile any new code for root trace and side trace, but counting hot code is still going on. This patch stops counting as soon as possible by replacing counter handler with original handler, which increases 1.5% performance. Signed-off-by: Wang, Xue <[email protected]>
fbfa5c0 to
11946e9
Compare
|
The idea looks great. I'll take a deeper look into implementation on next week, when return back from vacation. |
| } | ||
| if (jit_extension->trace_info[i].trace_flags & | ||
| (ZEND_JIT_TRACE_START_LOOP | ZEND_JIT_TRACE_START_ENTER | ZEND_JIT_TRACE_START_RETURN)) { | ||
| op_array->opcodes[i].handler = jit_extension->trace_info[i].orig_handler; |
| if (!func_info) { | ||
| return; | ||
| } |
Yeah in our workload, all hotspot codes have been jitted in the warmup phase and those counter of JIT tracing is not necessary anymore after warmup. Actually, The JIT tracing counter wrapper functions(hybrid_func_trace_counter, hybrid_ret_trace_counter and hybrid_loop_trace_counter) bring numerous branch mispredictions. The lazy blacklisting is still counting before becoming hot. So it is better to stop counting as soon as possible. |
Right. This is the key feature 👍 |
|
@dstogov Thanks Dmitry. We will keep investing energy and squeezing performance for PHP... |
When max_root_trace is reached, JIT in tracing mode will not
compile any new code for root trace and side trace, but
counting hot code is still going on. This patch stops counting
as soon as possible by replacing counter handler with
original handler, which increases 1.5% performance.
Signed-off-by: Wang, Xue [email protected]