==== PHP 7 ZendEngine thoughts ====

Note:
  * Those are internal engine changes ideas. Nothing here is about PHP userland API, but engine API/ABI.
  * Do not break if it is not needed.
  * Think about global changes, BC breaking, that could possibly be kept for about 10 years (we don't know yet if when will happen the next major)
  * Design clever, for good, not evil

Initial factors to be taken care of:
  * number of contributors
  * timetable (2 years development)

  * Cleanup API and dead code
    * Clear namings
    * Clear conventions between macros and functions
    * Clear those

  * Update dependencies.
    * Notably support Bison 3.0+.

  * Define a true C/C++ API
    * Be able to export the engine in its own .so
    * Decouple the engine from PHP and SAPIs( https://wiki.php.net/rfc/php_native_interface - https://wiki.php.net/rfc/remove_zend_api)

  * Keep the extension-based build. Smaller pieces, better code maintaining
    * Merge SPL to the engine (at least, deep engine related stuff in SPL, such as the exception classes, the iterators and the functions like class_parents())
    * Rework Phar. Phar has too many engine hooks and voodoos, this must be rethought

  * Ehance extensions power
    * Keep distinction between zend extensions and php extensions ? https://wiki.php.net/internals/extensions
    * Use of other engine hooks ? other VM hooks ? (object store hooks, hashtable hooks ..? )
    * Remove old PHP4 support in ext code
    * Refactor error handler for extensions to be able to stack them like zend_execute

  * VM
    * Executor rewrite
      * JIT executor (http://llvm.org/devmtg/2008-08/Lopes_PHP-JIT-InTwoDays.pdf)
      * Threaded VM
         * IO threads ?
         * Do several things at the same time, stop blocking
      * Get rid of those patches applied for years to keep BC ( )
    * Compiler rewrite
      * reentrant
      * AST based
      * Hookable AST for optimizer passes
    * OPCache integration
    * OPcode binary data based compiler (phalanger, phpcompiler.org, bcompiler, roadsend)
    * Create a flag to prevent separation of arguments in function calls ?

  * Arrays/Objects struct data sharing
    * Use array_* functions with objects or arrays

  * MM rewrite
    * Different pool sizes
    * Different heap allocators ? (jmalloc ?)
    * GC thoughts

  * Improve debug
    * Improve DTrace usage
    * Give Linux process-probes a try (SystempTap, perf, OProfile)
    * Add more debug level (we already have bunch of macros, such as "AGRESSIVE_DEBUG")

  * See also
    * [[ideas/php6|Global PHP6 ideas]]
    * http://hg.python.org/cpython/file/
    * http://morepypy.blogspot.fr/2009/03/applying-tracing-jit-to-interpreter.html