[RFC] Preloading

I would like to start discussion on a Preloadng RFC https://wiki.php.net/rfc/preload

This sounds great!

If I understand correctly, this could also be included in Composer as
a new autoload type "preload" (which would be an array of files to
preload in a given package), so that Composer would generate
vendor/composer/preload.php as a list of includes to all the files in
every installed package that asked for preloading. Sounds like a
relatively easy addition that would let any library define their own
symbols. Obviously users can then choose to preload that file or not.

JIT-ing the sum of all preloaded classes/functions as once vs
function-level JIT also sounds like a very exciting prospect!

Best,
Jordi

I would like to start discussion on a Preloadng RFC https://wiki.php.net/rfc/preload

Overall, big +1.
A few questions:

1. "Only classes without unresolved parent, interfaces, traits and
   constant values may be preloaded." Is this determined at the moment of
   an individual opcache_compile_file()? Or can mis-ordered includes
   resolve themselves upon later compiles? e.g. I compile a.php with
   class A extends B {}, then subsequently compile b.php with class B {}. The engine has enough information to resolve this, even if it
   wasn't presented in an ideal order.

2. Will we raise warnings explaining why a given class is being
   deferred from pre-loading to help users understand how to use this
   correctly?

3. "Preloading may be used as systemlib in HHVM to define “standard”
   functions/classes in PHP" Presumably the internal APIs will be defined
   to handle this at the script level already. What stops us from simply
   ZENDAPIing the proto and letting extensions call it if they want?
   ((Simple conservatism is an adequate answer, but I'd like to know why
   it's out of scope)).

4. "In conjunction with ext/FFI (dangerous extension), we may allow
   FFI functionality only in preloaded PHP files, but not in regular
   ones." Is there any interest in something like HHVM's HNI interface?
   FFI always sounds nice in theory, but complex types mean that a little
   bit of glue code is often a plus.

I'll try to fix this in nearest week(s).

Thank you for everything you do.

-Sara

Hi Internals,

I would like to start discussion on a Preloadng RFC
https://wiki.php.net/rfc/preload

Nice!

Apology if I missed it in the RFC but can't find in which stage the
preloading is done (also haven't checked the patch so sorry if it's
obvious)? I'm mainly interested if it's done in MINIT which would mean
executing that script as a different user when starting FPM as root and
switching the user after fork. Basically what we discussed some time ago:
https://externals.io/message/102052#102065 .

Cheers

Jakub

Hi Internals,

I would like to start discussion on a Preloadng RFC
https://wiki.php.net/rfc/preload

This technology would allow loading some PHP files on server startup and
make all the defined classes and functions to be permanently available in
the context of future request (without any includes). Despite of
performance improvement, this technology is going to be used in conjunction
with ext/FFI and JIT.

The implementation is not 100% complete, it misses support for ZTS,
because of a error in ZTS interned strings implementation.

I'll try to fix this in nearest week(s).

Definitely cool.

I think it is going to make the file-cache more important as deploy
mechanisms are now going to be more likely to do a full cache reset on a
deploy so being able to quickly repopulate the shared memory cache from the
file cache might help lessen the perf hit of the cache reset.

-Rasmus

I would like to start discussion on a Preloadng RFC https://wiki.php.net/rfc/preload

This technology would allow loading some PHP files on server startup and make all the defined classes and functions to be permanently available in the context of future request (without any includes). Despite of performance improvement, this technology is going to be used in conjunction with ext/FFI and JIT.

The implementation is not 100% complete, it misses support for ZTS, because of a error in ZTS interned strings implementation.

What about classes with static members? I don't see "static" mentioned
anywhere. Is it supported? If so it should explicitly be mentioned
along with any caveats, if any.

I would like to start discussion on a Preloadng RFC
https://wiki.php.net/rfc/preload

I have been playing with this a bit this weekend.

It is tricky to tell if it is working. I think it would be helpful if the
opcache section on the phpinfo page, and/or opcache_get_status() would have
some way to see which scripts are preloaded.

-Rasmus

On Fri, Oct 19, 2018 at 10:17 AM, Dmitry Stogov dmitry@zend.com
wrote:

Hi Internals,

I would like to start discussion on a Preloadng RFC
https://wiki.php.net/rfc/preload

This sounds great, but something about the last paragraph:

And also, this approach will not be compatible with servers that host
multiple applications, or multiple versions of applications - that
would have different implementations for certain classes with the same
name - if such classes are preloaded from the codebase of one app, it
will conflict with loading the different class implementation from the
other app(s).

Please excuse my lack of knowledge about the opcache internals, but
can't this be remedied by some kind of namespacing? I don't know how
the lookup rules are, but I assume it's by file path - so if you're
preloading and serving preloading bundles, shouldn't this (at least as
a PoC) work with a random prefix, or even the app entry point?

This whole thing is basically tailored to people running their
own applications on their own stack - but if this restriction was
lifted this could be handy for shared hosting or even for people with
multiple application (stacks) on the same webserver.

Yes, I'm sure it's not that simple, but I don't really grasp why this
is different than the current opcache lookup rules.

Greetings,
Florian