Re: New Memory Manager

On 14/01/14 18:21, Julien Pauli wrote:

On Tue, Jan 14, 2014 at 5:45 PM, Dmitry Stogov <dmitry@zend.com> wrote:

Of course I tried to plug jemalloc and tcmalloc but they make slowdown instead of speedup, mainly because zend_alloc was especially designed for PHP and also because they suffer from multi-threading support overhead. On the other hand profiling PHP with oprofile I saw a lot of cache misses in zend_alloc.c, especially because of linked list handling. So I tried to combine the best from all approaches and then spend a couple of week tuning it. Thanks. Dmitry.

Yes, I was reading the great job you've done so far ! Looking forward in testing this myself and why not fix bugs or give some more ideas :-) Anyway, the different pool sizes is nice. We already got an idea like this in ZendMM with the "small free block" VS "free block" linked lists, but the implementation you've done so far is pretty nice evolution. I think we can improve stuff by studying more accurate caches for frequently used C-objects such as zvals or zend_object's structures. One of the most common macro uses for both emalloc and efree primitives is in the CTOR and DTOR of zval structures. This is HOT code, yet the code involved is split across three main modules totalling less that 10K lines. As a comparison zend_vm_execute.h is over 40K lines to allow the CC optimizer to optimize across the entire source code.

Wouldn't it make a lot more sense to combine zend_variables.c, zend_hash.c and zend_alloc.c into a single module (do it by #include directive as zend_execute.c incorporates zend_vm_execute.h) so that the CC optimizer can properly optimitise these CTORs and DTORs? The DTOR for a ZVAL which itself a simple ZVAL hierarchy such as a an array should be executed as a dense code sequence that can comfortably run out of the L1Instr cache, with minimal cache misses and BLT failure stalls. Regards Terry