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. > 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). 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. > > >
