i have noticed two bugs that cause a segfault. both it appears with php5 + mmcache.
one is with objects. it seems to cache the object after the first load and not execute it again (until the file is changed and forced to be recached) - even unset($object) wouldn't work (even though object persistence shouldn't be an issue since the object is killed after every request)
the other is using arrays in list() -
list($foo,$bar,$array['item']) = $something;
that $array['item'] causes a segfault. you can't put arrays in a list() anymore with php5+mmcache.
it could be a good thing or bad; but either way it's different behavior from php4. i had to change a bunch of code when i upgraded to php5 so it would stop segfaulting.
By the way, I don't know if I have enough rights to let anybody join the project. Probably you should contact Dmitry, or we can discuss things about the code, if you think!
Thats great news, really looking forward to it. Just a suggestion, consider a revamp of the code, its been a long time since i touched C, but everytime i looked at the mmCache code it kinda made my head spin :)
i agree partially.
the first time i saw this code, i thought that it's really nice spagetti code. because every code is in mmcache.c file.
but, now i think it's really nice code.
mmcache's job is intercepting original compiler, and if not cached call zend_compile_file() and cache output. other cases it assembles as same output as zend_compile_file() output from shared memory or file. so, this interceping logic resides on mmcache_compile_file(). it's like C's main() function on mmcache.
zend_compile_file returns pointer of zend_op_array.
this is byte code(zendop) of php code outside of function or classes.
and function tables and class tables are stored in global variable called by compiler global. we can access CG() macro to that.
so, mmcache's main job is
1) emulate return variable of zend_compile_file()
current op array
2) changed in CG()
function and class tables.
store_xxx() / restore_xxx() functions are doing this jobs. for example store_class_entry() stores classes except function, store_op_array() stores function/method.
and another important function is calc_xxx() series functions. this function calculate amount of memory need to store current file to cache before real storing jobs. when we call calc_size() with current op_array, function hash table, class hash table, it calculate exact size need. calc_xxx() is called only by calc_size() i think.
mmcache_store() / mmcache_restore() function is main function of store/restore. store_xxx() function is only called by mmcache_store(), and same to restore_xxx() cases.
and mmcache has global variables. MMCG(...) is that. these are configuration variables. (defined on mmcache.h 127-187 on 2.4.7)
most importang thing i know is that MMCG(mem).
it used in two ways.
first one is set "MMCG(mem) = NULL;"
and calculate memory size. you can easily find code such as "MMCG(mem) += sizeof(zval)". this is done by calc_xxx() functions.
and second is allocate shared memory "MMCG(mem) = mmcache_malloc(size)", and whenever you need memory, use such as "ht = MMCG(mem); MMCG(mem) += sizeof(HashTable)". this is done by store_xxx() functions.
so, it is important that we should not allocate more than size returned by calc_size() call.
with this mechnism, every file store in single chunk of shared memory block and managed by hash(not zend hash table) , see the struct _mm_cache_entry definition, hash_xxx() functions.
and there is MMCG(strings) hash tables. every strings should be stored for next execution, register this hash table. real string is reside on MMCG(mem), but, use this hash not to allocate same string more than twice.
MMCG(class_entry) is pointer to zend_class_entry which is currently caching.
this is what i found in a week of analysis of this code.
mmcache is technically,
transformation of data between mmcache_entry and return zend_op_array,compiler globals.
i too waste my time reading the source because there's no comment or document
i don't think "because every code is in mmcache.c file" is nice
although many php/ext is in 1 source file, they're just simple wrapper
e.g. ext/mysql -> libmysql
mmcache, imho is more complex than most ext in php.
and apc, is splited into modules(not meant to plugable), is more clear than mmcache
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.