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 14:06] – typo 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.
  
Line 40: Line 40:
 == 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.1242309978.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools