rfc:opcache.no_cache

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
rfc:opcache.no_cache [2020/06/13 15:05]
tandre add note on opcache
rfc:opcache.no_cache [2020/06/13 17:45] (current)
tandre add feedback comment on moving optimizations into core
Line 153: Line 153:
 There are various ways the suggestion in [[https://wiki.php.net/rfc/opcache.no_cache#discussion|Discussion]] could be implemented. My ideas on a way that could be implemented are below (I'm not familiar enough with opcache to implement that or to be aware of any problems it would cause): There are various ways the suggestion in [[https://wiki.php.net/rfc/opcache.no_cache#discussion|Discussion]] could be implemented. My ideas on a way that could be implemented are below (I'm not familiar enough with opcache to implement that or to be aware of any problems it would cause):
  
-  * Move the optimizer into core (e.g. move code related to opcode optimizations from ''ext/opcache'' to a new folder ''ext/optimizer'' loaded before opcache). Keep all of the functionality related to caching in the zend_extension Zend Opcache (some build environments may not support or have a use case for any forms of shared memory caching).+  * Move the optimizer into core (e.g. move code related to opcode optimizations from ''ext/opcache'' to a new folder <del>''ext/optimizer''</del> such as ''Zend/optimizer''). Keep all of the functionality related to caching in the zend_extension Zend Opcache (some build environments may not support or have a use case for any forms of shared memory caching).
   * Continue optimizing according to ''opcache.enable'' and ''opcache.enable_cli'' when the opcode caching is enabled. \\ Add a new flag such as ''optimizer.always_optimize=1'' or ''opcache.always_optimize=1'' which will ignore that and unconditionally optimize using the optimization passes in ''opcache.optimization_level''. This would ensure that existing use cases work without modifying ''php.ini'' and won't suffer from high startup time for short-lived processes which don't have opcodes cached.   * Continue optimizing according to ''opcache.enable'' and ''opcache.enable_cli'' when the opcode caching is enabled. \\ Add a new flag such as ''optimizer.always_optimize=1'' or ''opcache.always_optimize=1'' which will ignore that and unconditionally optimize using the optimization passes in ''opcache.optimization_level''. This would ensure that existing use cases work without modifying ''php.ini'' and won't suffer from high startup time for short-lived processes which don't have opcodes cached.
   * Provide C function pointers to lock shared memory and acquire pointer locations so that the JIT can emit executable code without conflicting with other processes/threads, and make opcache override those function pointers. I'm not sure how protecting memory with opcache jit without the opcache extension managing shared memory would work with threaded php and no shared cache, but should be possible - I assume the JIT already works with ''opcache.file_cache_only''. I'm also unfamiliar with how those pointers/mutexes would get released if php crashed.   * Provide C function pointers to lock shared memory and acquire pointer locations so that the JIT can emit executable code without conflicting with other processes/threads, and make opcache override those function pointers. I'm not sure how protecting memory with opcache jit without the opcache extension managing shared memory would work with threaded php and no shared cache, but should be possible - I assume the JIT already works with ''opcache.file_cache_only''. I'm also unfamiliar with how those pointers/mutexes would get released if php crashed.
   * Limit ''opcache.preload'' to only be used when the opcode caching zend_extension is used.   * Limit ''opcache.preload'' to only be used when the opcode caching zend_extension is used.
 +
 +[[https://externals.io/message/110502#110503|Nikita Popov mentions that]]
 +<blockquote>
 +To be clear, "move into core" means moving optimizations into Zend/ and making them part of the compilation process (optionally). They shouldn't be in a separate ext/optimizer extension -- that would be not much better than having them in ext/opcache :)
 +</blockquote>
 +
  
 ===== References ===== ===== References =====
rfc/opcache.no_cache.1592060732.txt.gz · Last modified: 2020/06/13 15:05 by tandre