Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104164
MIME-Version: 1.0
References: <DM6PR02MB59326E10841277F34E4EFF75BF910@DM6PR02MB5932.namprd02.prod.outlook.com>
 <CAEPJduk8zCuVotRKjU54R_hT806hvzrsUs9AguG4G=s7gSwo9w@mail.gmail.com>
 <CAEPJdu=XKfAJ_YeeGs21pubeu3CAt6gBzuqHH67g9R+gROsJfQ@mail.gmail.com> <24d0544c-1852-2a72-477d-e6b364dff953@zend.com>
In-Reply-To: <24d0544c-1852-2a72-477d-e6b364dff953@zend.com>
Date: Tue, 5 Feb 2019 10:40:29 +0100
Message-ID: <CAEPJdumoJWJtuziEFvRYEmu0Fk4eLzk+Yk9tnZ1KYrL5rYKPbA@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000018020e058122679e"
Subject: Re: [PHP-DEV] [RFC] JIT
From: kontakt@beberlei.de (Benjamin Eberlei)

--00000000000018020e058122679e
Content-Type: text/plain; charset="UTF-8"

On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov <dmitry@zend.com> wrote:

>
>
> On 2/5/19 1:48 AM, Benjamin Eberlei wrote:
> >
> >
> > On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei <kontakt@beberlei.de
> > <mailto:kontakt@beberlei.de>> wrote:
> >
> >
> >
> >     On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov <dmitry@zend.com
> >     <mailto:dmitry@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.
> >
>

--00000000000018020e058122679e--