From 131cca510319b99cf77b3d51074c50e92935e595 Mon Sep 17 00:00:00 2001 From: Ilija Tovilo Date: Sat, 27 Aug 2022 12:28:08 +0200 Subject: [PATCH] Consistent opcache casing --- Book/php5/build_system/building_extensions.rst | 2 +- Book/php7/extensions_design/hooks.rst | 6 +++--- Book/php7/extensions_design/zend_extensions.rst | 12 ++++++------ .../php7/internal_types/strings/zend_strings.rst | 16 ++++++++-------- Book/php7/zend_engine.rst | 2 +- Book/php7/zend_engine/zend_opcache.rst | 2 +- 6 files changed, 20 insertions(+), 20 deletions(-) diff --git a/Book/php5/build_system/building_extensions.rst b/Book/php5/build_system/building_extensions.rst index 7d23a26c..4571fa98 100644 --- a/Book/php5/build_system/building_extensions.rst +++ b/Book/php5/build_system/building_extensions.rst @@ -51,7 +51,7 @@ everything else. The reason is simply that building external extensions as share intrusive), as you will see in a moment. Another benefit is that you can update the extension without rebuilding PHP. .. [#] We'll explain the difference between a "normal" extension and a Zend extension later in the book. For now it - suffices to know that Zend extensions are more "low level" (e.g. opcache or xdebug) and hook into the workings of + suffices to know that Zend extensions are more "low level" (e.g. opcache or Xdebug) and hook into the workings of the Zend Engine itself. Installing extensions from PECL diff --git a/Book/php7/extensions_design/hooks.rst b/Book/php7/extensions_design/hooks.rst index fa2ebfdb..4e097d81 100644 --- a/Book/php7/extensions_design/hooks.rst +++ b/Book/php7/extensions_design/hooks.rst @@ -123,7 +123,7 @@ Modifying the Abstract Syntax Tree (AST) **************************************** When PHP 7 compiles PHP code it converts it into an abstract syntax tree (AST) -before finally generating Opcodes that are persisted in Opcache. The +before finally generating opcodes that are persisted in opcache. The ``zend_ast_process hook`` is called for every compiled script and allows you to modify the AST after it is parsed and created. @@ -170,10 +170,10 @@ and all PHP scripts compiled after the replacement will be handled by your implementation of the hook. It is very important to always call the original function pointer, otherwise -PHP cannot compile scripts anymore and Opcache will not work anymore. +PHP cannot compile scripts anymore and opcache will not work anymore. The extension overwriting order here is also important as you need to be aware -whether you want to register your hook before or after Opcache, because Opcache +whether you want to register your hook before or after opcache, because opcache does not call the original function pointer if it finds an opcode array entry in its shared memory cache. Opcache registers their hook as a post startup hook, which runs after the minit phase for extensions, so by default your hook diff --git a/Book/php7/extensions_design/zend_extensions.rst b/Book/php7/extensions_design/zend_extensions.rst index d08e7eb4..d414221a 100644 --- a/Book/php7/extensions_design/zend_extensions.rst +++ b/Book/php7/extensions_design/zend_extensions.rst @@ -103,7 +103,7 @@ Why need a Zend extension ? Let us warn you : until you have **very advanced** knowledge on PHP internal's Vritual Machine, and until you need to hook deep into it, you shouldn't need a Zend extension, but a PHP extension will be enough. -Today's most commonly known Zend extensions into PHP's world are OPCache, XDebug, phpdbg and Blackfire. But you know +Today's most commonly known Zend extensions into PHP's world are opcache, Xdebug, phpdbg and Blackfire. But you know dozens of PHP extensions next to that don't you ?! That's a clear sign that : * You should not need a Zend extension for a very big part of your problematics @@ -215,7 +215,7 @@ In *practice*, what we can say about it is that : Until some distributions (FreeBSD hear us) change that ... * Zend extensions are triggered **before** PHP extensions when a request shows in. That means they got a chance to modify - the engine about the current request to come, so that PHP extensions use that modified context. OPCache uses such a + the engine about the current request to come, so that PHP extensions use that modified context. Opcache uses such a trick so that it can perform its complex tasks before any extension had a chance to prevent it to. * Same for request shutdown : Zend extensions can assume every PHP extension has shut down the request. @@ -301,7 +301,7 @@ That's all for now. Let's fill-in those empty-body functions now:: Like said before, ``message_handler()`` is a special hook that Zend extensions may declare to be noticed when another Zend extension get loaded. But be careful of the order. You must register our "pib" Zend extension first, then -another Zend extension (like OPCache) after that, as the ``message_handler()`` is only called when a Zend extension is +another Zend extension (like opcache) after that, as the ``message_handler()`` is only called when a Zend extension is loaded you obviously need to be loaded before to declare it. Chicken and egg. Then we'll start to dive into the engine, with our ``op_array_handler`` hook:: @@ -479,10 +479,10 @@ How is that possible ? And what for ?. Well there are several answers to such a question : * To :doc:`register new PHP functions `, a PHP extension is better than a Zend extension, as it already - knows how to do and has been designed for that specific purpose first. That would be pity not to use it. OPCache + knows how to do and has been designed for that specific purpose first. That would be pity not to use it. Opcache does that. * If you need to register about all the hooks in the full lifecycle, you'll obviously need both sides -* If you need to master the order Zend extensions are loaded, f.e to get loaded after OPCache, you will need to be +* If you need to master the order Zend extensions are loaded, f.e to get loaded after opcache, you will need to be hybrid The trick is simple, choose between : @@ -656,7 +656,7 @@ Our PHP extension is effectively called "pib" and shows up, and our Zend extensi "pib-zend-extension" and shows up as well. We chose two different names for both parts, we could have chosen the same name. -.. note:: OPCache and Xdebug use such an hybrid model, they are Zend extensions, but they need to publish PHP +.. note:: Opcache and Xdebug use such an hybrid model, they are Zend extensions, but they need to publish PHP functions and thus they are also PHP extensions to do so. Hybrid PHP extension master, Zend extension slave diff --git a/Book/php7/internal_types/strings/zend_strings.rst b/Book/php7/internal_types/strings/zend_strings.rst index 2896581d..dbc7b8f3 100644 --- a/Book/php7/internal_types/strings/zend_strings.rst +++ b/Book/php7/internal_types/strings/zend_strings.rst @@ -250,9 +250,9 @@ Interned strings ---------------- Just a quick word here about `interned strings `_. You could -need such a concept in extension development. Interned strings also interact with OPCache extension. +need such a concept in extension development. Interned strings also interact with opcache extension. -Interned strings are deduplicated strings. When used with OPCache, they also get reused from request to request. +Interned strings are deduplicated strings. When used with opcache, they also get reused from request to request. Say you want to create the string "foo". What you tend to do is simply create a new string "foo":: @@ -322,17 +322,17 @@ This process is in fact a little bit more complex than this. If you make use of :doc:`request processing <../../extensions_design/php_lifecycle>`, that string will be interned for sure. However, if you make use of an interned string as PHP is treating a request, then this string will only get interned for the current request, and will get cleared after that. -All this is valid if you don't use the OPCache extension, something you shouldn't do : use it. +All this is valid if you don't use the opcache extension, something you shouldn't do : use it. -When using the OPCache extension, if you make use of an interned string out of a +When using the opcache extension, if you make use of an interned string out of a :doc:`request processing <../../extensions_design/php_lifecycle>`, that string will be interned for sure and will also be shared to every PHP process or thread that will be spawned by you parallelism layer. -Also, if you make use of an interned string as PHP is treating a request, this string will also get interned by OPCache +Also, if you make use of an interned string as PHP is treating a request, this string will also get interned by opcache itself, and shared to every PHP process or thread that will be spawned by you parallelism layer. -Interned strings mechanisms are then changed when OPCache extension fires in. OPCache not only allows to intern strings +Interned strings mechanisms are then changed when opcache extension fires in. Opcache not only allows to intern strings that come from a request, but it also allows to share them to every PHP process of the same pool. This is done using -shared memory. When saving an interned string, OPCache will also add the ``IS_STR_PERMANENT`` flag to its GC info. +shared memory. When saving an interned string, opcache will also add the ``IS_STR_PERMANENT`` flag to its GC info. That flag means the memory allocation used for the structure (``zend_string`` here) is permanent, it could be a shared read-only memory segment. @@ -340,7 +340,7 @@ Interned strings save memory, because the same string is never stored more than CPU time as it often needs to lookup the interned strings store, even if that process is well optimized yet. As an extension designer, here are global rules: -* If OPCache is used (it should be), and if you need to create read-only strings : use an interned string. +* If opcache is used (it should be), and if you need to create read-only strings : use an interned string. * If you need a string you know for sure PHP will have interned (a well-known-PHP-string, f.e "php" or "str_replace"), use an interned string. * If the string is not read-only and could/should be altered after its been created, do not use an interned string. diff --git a/Book/php7/zend_engine.rst b/Book/php7/zend_engine.rst index 5053f3c3..d3c03543 100644 --- a/Book/php7/zend_engine.rst +++ b/Book/php7/zend_engine.rst @@ -3,7 +3,7 @@ Zend engine The Zend engine is a set of components that make PHP what it is. The most important Zend engine component is the *Zend Virtual Machine*, which is composed of the *Zend Compiler* and the *Zend Executor* components. We could also add -the OPCache zend extension in such category. Those three components are the heart of PHP (or the brain, you choose), +the opcache zend extension in such category. Those three components are the heart of PHP (or the brain, you choose), they are critical and they are the most complex parts of all the PHP source code. In the current chapter, we'll try to open them and detail them. diff --git a/Book/php7/zend_engine/zend_opcache.rst b/Book/php7/zend_engine/zend_opcache.rst index 6331ceeb..ee63f353 100644 --- a/Book/php7/zend_engine/zend_opcache.rst +++ b/Book/php7/zend_engine/zend_opcache.rst @@ -1,2 +1,2 @@ -Zend OPCache +Zend opcache ============