rfc:remove_zend_api:scratchpad

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:remove_zend_api:scratchpad [2009/05/13 22:44] – nicholsrrfc:remove_zend_api:scratchpad [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== VM extension API Scratchpad ====== ====== VM extension API Scratchpad ======
  
-This is an area where a number of us are brainstorming and developing ideas around the proposal for an improved interface between the PHP Virtual Machine and its extensions.   +This is an area where a number of us are brainstorming and developing ideas around the proposal for an improved interface between the PHP Virtual Machine and its extensions. Some of us have worked on the ProjectZero implementation of PHP so we refer to our experiences there. 
  
 ===== Assumptions ===== ===== Assumptions =====
Line 8: Line 7:
    * We assume that the extensions may exist in in a different address space to the VM. The extensions must not assume that they can read or write VM memory.     * We assume that the extensions may exist in in a different address space to the VM. The extensions must not assume that they can read or write VM memory. 
    * We assume that the extensions cannot use any extension interfaces other than those documented in the interface.    * We assume that the extensions cannot use any extension interfaces other than those documented in the interface.
-   * We assume that whilst there will be (are) many VMs implementing PHP, there should only be one set of extensions which run unchanged on all VMs.+   * We assume that whilst there will be (are) many VMs implementing PHP, there should only be one set of extensions which run unchanged on all VMs. What we'd like to do is arrive at an interface that facilitates this.
  
  
Line 21: Line 20:
 This is the most pernicious problem of all. This is the most pernicious problem of all.
  
-The zend engine recognizes two types of memory. There is memory that is allocated "permanently"  that is to say it can  persist from request to request and does not participate in reference counting and there is memory that is temporarily allocated and participates in the engine garbage collection.  If you think about the interaction with an extension there are actually really three cases.   +The zend engine recognizes two types of memory. There is memory that is allocated "persistently" (pemalloc) that is to say it can  persist from request to request and there non persistently allocated (emalloc).  Typically this memory is associated with a zval which participates in the engine garbage collection (a reference counting scheme).  If you think about the interaction with an extension there are actually really three cases:   
- +  - Memory that is used only during  a single extension function call. At the end of the call the extension retains no references to the memory. Anything that must persist beyond the function call has been stored away inside the VM.  
-1. Memory that is used only during  a single extension function call. At the end of the call the extension retains no references to the memory.  +  - Memory that is allocated from the temporary heap on one extension function call but accessed on a later call, e.g the extension caches a pointer to the memory across requests in extension global storage or a resource. 
-2. Memory that is allocated from the temporary heap on one extension function call but accessed on a later call without a reference explicitly being passed back to the extension on the subsequent call. (the extension caches a pointer to the memory) +  - Persistent memory that persists from request to request.
-3. Permanent memory that persists from request to request.+
  
 Case 2 causes a problem if we assume that we do not want the extensions to participate in the VM garbage collection scheme.  Case 2 causes a problem if we assume that we do not want the extensions to participate in the VM garbage collection scheme. 
 +There is an example of this in the XML extension function xml_set_object
 +
 + ALLOC_ZVAL(parser->object);
 + *parser->object = **mythis;
 + zval_copy_ctor(parser->object);
 + INIT_PZVAL(parser->object);
 +
 +The above code creates a new zval and sets a reference to it in an XML parser resource which is passed across requests.
 +
 +
 +
  
 == Solution used in Project Zero == == Solution used in Project Zero ==
  
-ProjectZero  had to modify the extension code to cater for it.  There is an example of this in the XML extension (need reference.)+Projectzero assumes case 1 for all function calls. i.e all non-persistent memory is freed.  
 +ProjectZero  had to modify the extension code specifically to remove instances of case 2. 
  
  
rfc/remove_zend_api/scratchpad.1242254695.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools