[RFC] Preloading

On Fri, 19 Oct 2018 at 10:18, Dmitry Stogov <dmitry@zend.com> wrote:

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

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

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.

Thank you for everything you do. -Sara

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

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

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

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

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.

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

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:

This sounds great, but something about the last paragraph:

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