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/14 13:56] – Fix formatting wharmbyrfc:remove_zend_api:scratchpad [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 21: Line 21:
  
 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:   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. Anythink that must persist beyond the function call has been stored away inside the VM.  +  - 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.  
-  - 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)+  - 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.
   - Persistent memory that persists from request to request.   - Persistent 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 (need reference.)+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 assumes case 1 for all function calls.+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.  ProjectZero  had to modify the extension code specifically to remove instances of case 2. 
  
rfc/remove_zend_api/scratchpad.1242309417.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools