Closed dktapps closed 1 day ago
Thinking about it, I suppose the reason this has never been done is because it would essentially involve integrating OPcache as a non-removable part of the PHP core, and I guess there's a reason that's never been done.
That being said, if it wasn't for it not being able to be statically compiled, I'd happily make it a hard dependency for my extension. Is there a specific technical reason why it can't be statically compiled?
See #15074.
Description
I maintain a threading extension ext-pmmpthread.
One of the biggest maintenance issues is the need to copy classes, functions & constants from thread A to thread B when a new thread is started.
If OPcache is enabled, this becomes vastly easier & faster, since the extension doesn't need to copy classes & op_arrays with
ZEND_ACC_IMMUTABLE
at all. Constants are still an issue right now because OPcache doesn't persist those as far as I'm aware.However, we still have to account for the case when OPcache is not used (e.g. on platforms where dynamic loading isn't available since OPcache can't be statically compiled, or disabled due to bugs). This means that:
zend_persist.c
which does a pretty similar thing.zend_persist.c
to fix various new issues that come up. Often these issues are not detectable during initial testing.For completeness, I'll mention that I have considered implementing copying at the point of loading a script (exactly like OPcache does) to avoid some of these issues. However this would involve basically identical logic to
zend_persist.c
being copied to the extension, which I don't feel makes a lot of sense.For PHP's own sake it doesn't make a ton of sense to me to have two different modes of class & function existence either. I feel like it would simplify a bunch of things for everyone if the OPcache way was the default.