opcache.no_cache prototype: Opcode optimization without caching View as Markdown

Hi internals,

Currently, it isn't possible to enable optimizations without enabling caching.
They should be orthogonal features - it's already possible to cache without
optimization passes (opcache.optimization_level=0)

I have a prototype implementing this at https://github.com/php/php-src/pull/5504 .
Conceptually, this behaves like opcache.file_cache_only in that it optimizes and doesn't use any shared memory, but doesn't actually save or load files.
I wanted to measure interest in an RFC to add this to PHP, and on what form this should take.
(I've heard PR discussion is supposed to be for implementation details, so I'm also creating an email thread)

Being forced to either enable caching or file_cache_only causes these problems:

• For file_cache_only, users would be forced to manage the file cache,
  and users may not be confident in properly handling all potential edge cases.

  (Running out of disk space, need to clear stale entries, concerns about opcode
  corruption not being fixed after restarting a process, etc)

• The shared memory block uses up a lot of RAM when individual PHP processes
  are known to be long-lived and don't have a common memory address space.
  (e.g. multiple long-lived php scripts managed by something that is not
  a php script (e.g. supervisord, daemons, tools run in the background in
  IDEs, etc). Typical web server uses such as apache share a process space, and would not use no_cache)

  The opcodes are duplicated in shmem, which wastes memory in use cases
  where they're stored in the cache but never retrieved.

  The default for opcache.memory_consumption is 128M.
  Even when this isn't used, the virtual memory to track the shared
  memory(shmem) segment seems to add 2MB extra per independent php process in
  "shared memory" segments (depending on OS settings?), reducing the free RAM available for other processes.

  (starting a large number of php CLI scripts that sleep() in a loop,
  free (linux program to report free memory) reports that shared
  increases by 2MB per process without opcache.no_cache, but barely increases
  with opcache.no_cache=1

On an unrelated PR https://github.com/php/php-src/pull/5097#issuecomment-576421941
Dmitry Stogov mentioned that

Also, it would be great to move optimizer and JIT into core, to make them
available even without opcode caching.

On the PR itself, Nikita Popov wrote https://github.com/php/php-src/pull/5504#issuecomment-622295467

I like the idea of having optimization without caching,
but the way to go about this is definitely moving the optimizer into Zend
and making it available completely independently of the opcache extension.
This has been "planned" for a long time, but never actually happened.

• I think that creating a new setting along the lines of opcache.no_cache would have a use case before and after such a refactoring,
  providing the benefits I mentioned for the use cases in the PR description.
  This would continue to be have a use case even if the caching parts of opcache.so moved into php's core
  (e.g. if that was done, and the caching module were loaded in php.ini
  as zend_extension=opcache.so, there'd still be a use case for a configuration setting to override that default
  to disable caching for running individual programs)

  Users may strongly prefer for opcache.enable, opcache.enable_cli, and opcache.optimization_level to continue controlling whether optimizations are performed
  (so setting the combination of opcache.enable=1, opcache.enable_cli=1, and a setting such as opcache.no_cache=1 to optimize without caching would make sense there)

• If nobody's currently planning to work on moving the optimizer into Zend (i.e. into php's core),
  then it may be several minor releases before it's possible to have optimization without caching.

• There may be unforeseen objections to moving the optimizer into Zend from creators/users of profiling tools, debuggers, code coverage tools, etc.
  Hopefully not, but that'd depend on the proposed implementation details.

Thanks,

• Tyson