On Tue, Feb 5, 2019 at 11:45 AM Dmitry Stogov <dmi...@zend.com> wrote:
> > > On 2/5/19 12:40 PM, Benjamin Eberlei wrote: > > > > > > On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov <dmi...@zend.com > > <mailto:dmi...@zend.com>> wrote: > > > > > > > > On 2/5/19 1:48 AM, Benjamin Eberlei wrote: > > > > > > > > > On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei > > <kont...@beberlei.de <mailto:kont...@beberlei.de> > > > <mailto:kont...@beberlei.de <mailto:kont...@beberlei.de>>> wrote: > > > > > > > > > > > > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov > > <dmi...@zend.com <mailto:dmi...@zend.com> > > > <mailto:dmi...@zend.com <mailto:dmi...@zend.com>>> wrote: > > > > > > Hi Internals, > > > > > > > > > I'm glad to finally propose including JIT into PHP. > > > > > > > > > https://wiki.php.net/rfc/jit > > > > > > > > > In the current state it may be included both into PHP-8, > > where > > > we are going to continue active improvement, and into > > PHP-7.4, > > > as an experimental feature. > > > > > > > > > Can you give some information on if there are pre-conditions > that > > > must hold for a function to be jitted, or quit conditions > > that force > > > the JIT to be reverted for a function? > > > > -dopcache.jit=1245 will lead to JIT only functions with @jit > > doc-comment > > tag. It's possible to extend this manual control. > > > > > > @jit works if I have full control over my code-base, but whenever I use > > libraries/frameworks this kind of configuration is too static, and puts > > a burden on open-source maintainers to figure out what they want to jit > > or not for users. > > > > This option will not be very useful from a distributed maintenance > > perspective, especially if you don't know if users pick 4 or 3, this is > > too much configuration details/micro-management in my opinion, > > especially given your argument that JIT is supposed to be as transparent > > and behind the scenes as possible for users. > > > > In my opinion 4 should not be available to users. > > In some cases it may help (similar to "inline" in C). > For better performance, I would recomend "hot counters trigger" - 3 or > everything - 0. > > > > > > > > In addition, it would be > > > helpful for testing if there was a way to find out if a > > function was > > > jitted, maybe through ReflectionMethod/Function or > > > opcache_get_status() ? > > > > yes. This makes sense. > > > > > > > > And as a follow up, the JIT seems to affect zend_execute_ex and > > > zend_execute_internal based profiling (tested with > > tideways_xhprof) in a > > > way that all Jitted functions are not called through those two > hooks > > > anymore, and don't appear in profiling data anymore. Is that a > > correct > > > description? The number of parent=>child call entries drops from > > 88 to > > > 12 in my sample code when jit is activated. > > > > > > Is that a desired side-effect? > > > > Yes. This is, at least expected. > > PHP profilers/debuggers may disable JIT and opcache for particular > > request, setting "opcache.enable=0" in RINIT. > > > > > > This may be acceptable for development profilers, but it is not for > > production profiling such as Blackfire and Tideways. I see that > > overwriting internal function pointers still works for hooks, so that > > doesn't need improvement, but PHP extensions need a way to control > > zend_execute_ex behavior, or get an alternative hook for jit based > > execution. > > JIT doesn't make a lot of sense if it doesn't optimize the overhead of > interpretation (nested calls to execute_ex, etc). It's clear, that it's > more difficult to debug optimized native code. Most implementations > fallback to interpretation when need debugging. Profiling of optimized > code is possible, but requires additional hooks. > I understand, but its not about preventing execute_ex for all calls, just for the 50ish that I am interested in, high level framework functions that are probably not efficently Jitted anyways. For Tideways as production profiler, I am obviously interested in users having great performance, but our users trust us to instrument what is necessary to find out what might be wrong. > > For Xhprof style profilers, a hook that gets the class + function name > > alone would be enough. > > > > For tracing profilers based on a whitelist of a few instrumented > > functions like tideways, NewRelic and probably all other APM vendor > > extensions, there needs to be a hook to selectively decide "don't JIT > > this function", that can be hooked into from 0 to many extensions. > > Example, Tideways hooks into the userland function Mage::logException(), > > to detect that Magento has thrown an exception that leads to a 500 page > > being rendered. It should be possible to make sure this function never > > gets jitted, so that I see its execution in zend_execute_ex. > > It's easily possible to disable JIT-ing by implementing @nojit (it's > pity, we didn't get attributes). > Sorry, but I can't add @nojit or @jit to third party frameworks or libraries. And this is what most Profiling/APM extensions are explicitly hooking into. A third party extension must control this somehow, without users having to have to change their code at all. ZEND_API extern int (*opcache_jit_accept_handler)(zend_string *class_name, zend_string *function_name); Then i can overwrite it in my own extension: int tideways_jit_accept_handler(zend_string *class_name, zend_string *function_name) { if (zend_hash_key_exists(TRG(callbacks), class_name)) { return DENY; } if (!class_name && zend_hash_key_exists(TRG(callbacks), function_name)) { return DENY; } return original_jit_accept_handler(class_name, function_name); } Problem with this hook would be that it needed to be available in Zend/ and not in ext-opcache so i can trust this global variable to exist in every compile such as zend_execute_ex. > > Thanks. Dmitry. > > > > > > > In addition, JIT-ed functions now may be tracked by Linux perf > > (oprofile > > and Intel VTune). > > > > $ perf record php -d opcache.huge_code_pages=0 -d > > opcache.jit_debug=0x10 > > bench.php > > $ perf report > > > > > > I think you overestimate PHP users savyness in Linux level profiling, > > maybe 1 in 100 knows how to use perf. In addition many PHP users don't > > have root on their servers (managed). And within Docker you don't even > > get there to start perfing. Profilers that put user experience first > > must be PHP extensions, so we need to make sure the basic level of > > hooking is possible even though we have a JIT. > > > > > > Thanks. Dmitry. > > > > > > > > > > > > > > > > > > Thanks. Dmitry. > > > > > >
