Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104176
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> <CAEPJdumoJWJtuziEFvRYEmu0Fk4eLzk+Yk9tnZ1KYrL5rYKPbA@mail.gmail.com>
 <88f08e26-f5e6-710d-4f0c-f8dbe179123c@zend.com>
In-Reply-To: <88f08e26-f5e6-710d-4f0c-f8dbe179123c@zend.com>
Date: Tue, 5 Feb 2019 12:24:31 +0100
Message-ID: <CAEPJdumaP7iQ3+N7tdybvCwu1vYzLppxT+LpnEcibX9USJmGJw@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000143d2e058123dbc4"
Subject: Re: [PHP-DEV] [RFC] JIT
From: kontakt@beberlei.de (Benjamin Eberlei)

--000000000000143d2e058123dbc4
Content-Type: text/plain; charset="UTF-8"

On Tue, Feb 5, 2019 at 11:45 AM Dmitry Stogov <dmitry@zend.com> wrote:

>
>
> On 2/5/19 12:40 PM, Benjamin Eberlei wrote:
> >
> >
> > On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov <dmitry@zend.com
> > <mailto: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>
> >      > <mailto: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>
> >      >     <mailto: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 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.
> >      >
> >
>

--000000000000143d2e058123dbc4--