[HttpKernel][DI] allow bundles to declare classes that should be preloaded

[nicolas-grekas]

Q	A
Branch?	4.4
Bug fix?	no
New feature?	no
Deprecations?	no
Tickets	#29105 #35759
License	MIT
Doc PR	-

This adds new methods to allow apps and bundles to declare classes that should be preloaded (when using PHP 7.4's opcache.preload).

Since #32032, the DI component is already able to generate a preloading script, based on services with the container.hot_path tag. Yet, based on my local experiments, not all classes can be discovered using this strategy. Also, it appears that while preloading all classes in vendor/ is said to be a bad idea by Dmitry itself, not preloading a class has a measurable impact.

Thus we should seek to preload all actually used classes. A bit more than that amount is better than a bit less.

As such, this PR now preloads all service classes and adds the infrastructure needed to list more classes when appropriate.

Listing more classes is done either via:

• Kernel::getClassesToPreload(), which by default loads everything in the namespace of the app's kernel (usually the App\ namespace) + all bundle classes
• Extension::addClassesToPreload(), so that each bundle's DI extension can add to the list. FrameworkBundle, SecurityBundle, and TwigBundle already contain the core they need.

This works nice on a skeleton app but segfaults on a website-skeleton for now, so I won't give numbers.

This is nonetheless ready (merging would actually help php-internal to reproduce the segfault.)

PS: this requires dumping the autoloader, i.e. composer install -o

[nicolas-grekas]

The var/cache/ folder contains additional files to preload - especially twig/ and validation.php, maybe others. We might need an extensibility mechanism to preload them too.

[stof]

We also need a way to force some classes to stay out of preloading IMO.
We had this issue in the past with Swiftmailer doing some magic during autoloading to load the swiftmailer initialization code, where hot-loading the file i the compiled container would break things by skipping the autoloader. SwiftmailerBundle could fix that by forcing to remove the hot tag on all its services after the DI component marked services as hot (as marking services as hot is separate from performing optimization for the). But here, I don't see an opt-out system.

[stof]

Aren't these discovered thanks to services already ?

[stof]

what about RequestEvent and ResponseEvent ?

[stof]

shouldn't it be added by FrameworkBundle when defining the stopwatch service instead ? Thus, I don't think we use it in prod code.

[stof]

Note that preloading hot services rather than all services would already provide such opt-out.

[rvanlaak]

As preloading might have some overlap with the already existing addAnnotatedClassesToCompile method, it might be good to document the similarities / differences.

Will compiled classes get preloaded as well?

[nicolas-grekas]

I'm closing there because I found a better approach in #36103: inline class_exists() calls.

We could add support for <tag name="container.preload" class="Foo" /> if we want to get more fine grained control.