On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov <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>> wrote: > > > > > > > > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <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 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. 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. > 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. > > >
