On Apr 6, 2012, at 10:41 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote:
> Hi! > >> How is memory tracked with emalloc? From my observations anything >> created with emalloc, with or without a zval wrapper, is freed at the >> end of the request. Things created with pemalloc, which seems to be a >> wrapper of malloc, isn't thrown away. > > Zend Engine has its own memory manager, see zend_alloc.c. Unfortunately, > I'm not sure I'll be able to explain in short how it works, but TLDR > version of it is that it's like malloc, but private to Zend Engine, so > everything is freed at the end of the request. > >> From what I've seen this is because the zvals, the values inside, the >> object bucket, etc... is all created by emalloc. Correct me if I'm >> wrong, but even if i could persist the zval (wrapper) the value inside >> would be freed unless both the zval and the value were created with >> pemalloc (alias of malloc). It goes a step further with the objects >> because a zend_object is just a handle ID (pointing to a spot in the >> bucket) and a pointer to object handlers. > > This is correct, all internal memory allocations are done by emalloc. > zend_object, however, is not just a handle - this handle refers to > object structure, which has class pointer, properties, etc. > >> and not much better than serialization. I'd like to avoid copying >> memory if possible. A flag on the zval would be ideal. > > That's what I am trying to explain - flag on one zval would not help > you, since this zval uses dozens, if not hundreds (for bigger object) > other resources, including other zvals, hashtables, object structures, > class structures, function structures, etc. etc. > Add to that that if you allocated something in emalloc arena you can not > just mark it "do not free it" - that would create a huge fragmentation > problem if you had something non-freeable at the middle of freeable > region. So you can not just "flag" random variable as non-freeable > without messing up whole memory manager (btw, not advisable with malloc > either - fragmentation can inflate you memory usage very easily). Not > that it would work even if you could, see above. I think I understand what you're getting at. So to avoid fragmentation you would have to have two independent memory spaces. Making non persistent memory persistent would require copying from one space to another. Is that correct? How is this handled in other platforms where you have an application instance (with state, if that's the correct terminology)? Are there any other options for reliably persisting objects/variables (without having to recreate)? (Re-sending to the list) > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
