Hi Dmitry, > -----Original Message----- > From: Dmitry Stogov <dmi...@zend.com> > Sent: Friday, February 15, 2019 8:12 AM > To: Anatol Belski <a...@php.net>; Joe Watkins <krak...@gmail.com>; Bob > Weinand <bwo...@php.net>; Nikita Popov <ni...@php.net>; z...@php.net > Cc: PHP internals <internals@lists.php.net> > Subject: Re: ZTS improvement idea > > Hi Anatol, > > On 2/14/19 8:44 PM, Anatol Belski wrote: > > Hi Dmitry, > > > >> -----Original Message----- > >> From: Dmitry Stogov <dmi...@zend.com> > >> Sent: Wednesday, February 13, 2019 12:26 AM > >> To: Joe Watkins <krak...@gmail.com>; Bob Weinand > <bwo...@php.net>; > >> Nikita Popov <ni...@php.net>; Anatol Belski (a...@php.net) > >> <a...@php.net>; z...@php.net > >> Cc: PHP internals <internals@lists.php.net> > >> Subject: ZTS improvement idea > >> > >> Hi, > >> > >> > >> > >> > >> After JIT+ZTS related discussion with Joe and Bob, and some related > >> analyzes. > >> > >> I came to more or less formed design idea and described it at > >> https://wiki.php.net/zts-improvement > >> > > I thought about it as well. The reason for the additional dereference > > levels is probably ,that every globals structure has its own size. > > That way, it needs to go on the heap. > > Not necessary. In case all the structures are known at MINIT time, we may > realloc()-ate the whole flattened tsrm_tls_entry and then access data faster. > > It may be a problem with dl(), but it must already be problematic in ZTS > build.
I was doing some research on this. Depending on how far we want to go, with the current approach there seems to be an issue. The current flow is as follows - core allocate tsrm_tls_entry entry - core puts it into TLS - TSRMLS_CACHE pointer gets updated in the core - any shared ext updates TSRMLS_CACHE - any globals are accessed using that same TSRMLS_CACHE pointer, disregarding shared or static ext The TSRMLS_CACHE pointer is updated by a tsrm_get_ls_cache() call once in GINIt or alike. That's a real function, has to be, as TSRMLS_CACHE can't be exported. Exts not having ZEND_ENABLE_STATIC_TSRMLS_CACHE implemented would do that call on every global access. The actual issue, assumed we reallocate, the TSRMLS_CACHE pointer would change and we need to overwrite it in TLS. That's ok for all the static stuff, but for the dynamic modules will still have an old TSRMLS_CACHE. Dynamic modules would need to have a way to know, that the TLS pointer has changed. There might be a solution requiring a more extensive refactoring. For example, into the module entry a callback might be included so then the core would go through all the modules and update TSRMLS_CACHE automatically, once reallocation happens. That might work, but need to experiment more to have a proof. If we don't change the existing mechanics, the structure could still be flattened, but as TSRMLS_CACHE would have to stay same once allocated - the flat structure would exist within TSRMLS_CACHE (like say turn the current storage array into a contiguous memory chunk) and would need one additional indirection level to be accessed. Perhaps a more serious refactoring would be preferable. Perhaps I oversee something, please let me know. Regards Anatol
