Implementation principles

The MLC-OPcache fork contains two sets of changes: first, the addition of the MLC functionality; and second the addition of a layer of diagnostic instrumentation that enables both compile-time and runtime instrumentation of execution and timing (through the DEBUGn(), ENTER() and xxx_TIMER() macros). These two sets of changes are largely independent in that the MLC functionality does not require the diagnostics and v.v. It's just that my own practice of embedding instrumentation evolved back when I used to develop complex C application for process control. I find them invaluable and an important adjunct to the debugger for understand how the system is behaving and hunting down bugs.

In making these changes, my aim has been to do this through a sensible layering:

• This fork will provide a superset of OPcache functionality which can be enabled by setting the appropriate ./configure parameter (currently --enable-opcache-file-cache), and if this is not set, the code will conditionally compile back to baseline code.
• When enabled though the --enable-opcache-file-cache option, this fork should offer the ability to support persistent caching of CLI and GCI SAPI execution modes through the use of a file-based caching mechanism.
• For other SAPI modes OPcache should follow the same execution path and logic as the base version, whether or not the file-cache is enabled. This includes TSRM compliance / support.
• New code will follow the same general coding conventions and style as the OPcache base, and a triage coding / implementation policy will be adopted to achieve this:
  • Wherever practical, additional code specific to the file-based cache will be implemented in specific-to-fork code modules.
  • Wherever practical, existing source files will be left identical to the base OPcache.
  • When changes must be applied to base code they will either be done as #ifdef gated code blocks or by macros which generate null strings on non-enabled configurations.
• The goal is that for scripts executing from a cache with no compile updates, the runtime characteristics should show material improvement compared to the default (none-cached) case, both in terms of CPU and I/O load.
• The MLC-OPcache implementation should enable the execution of the full PHP test suite with the OPcache running in both cache-hit and cache-miss execution paths, with and without OPcache optimization enabled.
• The cache filename will normally be derived from the resolved request path, that is each requested script will have its own associated cache, but with OPcache INI options providing a regexp based substitution mechanism to map the caches to a separate R/W directory, etc..
• Any writes to the cache should be lazy and atomic; that is the cache will normally only be written to on creation and only if material updates occur (e.g. where conditional logic on later execution paths includes additional source scripts to be cached); the write to cache must be done in such a way as to ensure that collision avoidance occurs where practical and that the cache is only written to by a single process. Collisions can be addressed by the colliding process aborting or subsequently overwriting the cache.
• Functionality will be introduced in a number of stages or waypoints, with the goal of each waypoint being a working github branch, albeit with known functional limitations and bugs, that can successfully execution the PHP test suite (initially just the PHP core, Zend and Standard extension elements) for the scenarios enumerated in the previous bullet.
• The initial build platform will be Linux-64bit (specifically Ubuntu 12.04 LTS and 13.04), but there should be nothing in the implementation which specifically prevents Windows or 32bit build variants.
• Wherever possible the current development will be kept in sync with OPcache progress by regularly merging OPcache updates.