On Sat, Feb 16, 2019 at 7:51 AM Anatol Belski <a...@php.net> wrote: > Hi Dmitry, > > > > 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. > > > Perhaps an idea for this could be to generate a special function for every > extension to be exported, like get_module_globals_size(). It could be > probably seamlessly integrated into ZEND_DECLARE_MODULE_GLOBALS(), so > require no change to the existing code. Then on module load we could > realloc() the flattened structure on demand. Still it'd be on heap, but it > would be a contiguous chunk of memory. > > > > > What we indeed could do were handling some specific known structures a > > > different way. It'd be like EG and others, that belong to the very > > > core and are always available. Other globals, especially from > > > extensions that can be built shared, would be probably still handled > the old > > way. > > > Maybe it would be a good start to speedup the very core as first. I'd > > > wonder which particular data structures and mechanism you had in mind. > > > > In https://wiki.php.net/zts-improvement I proposed: > > > > - make "executor_globals_id" to be constant (it's quite easy to do). > > - make all "...globals_id" to keep offsets instead if indexes (this is > a bit more > > complex and require changes in TSRM implementation). > > > Yeah, gotcha. The very core globals should be easy to "prefill" for the > flattened structure as the sizes are known at the compile time. All the > others could be appended to them, perhaps the way I've suggested above or > another if a better one is found. >
I think we need to distinguish two cases: 1. Globals that are local to a DSO. The majority of globals in extensions is of this kind. While it is currently common to declare these globals in an exported header, they really shouldn't be. We should move these towards ZEND_TLS (__thread). This should be fine on all platforms, including Windows. In unusual cases where globals need to be accessed outside the extension, getters/setters can be provided (for parts of the structure, or if necessary the whole structure). Unfortunately some of our code is currently written around the assumption that TSRM globals are used, e.g. the STD_INI_ENTRY macros. 2. Globals that are accessed across DSOs. These are the core globals EG, CG, BG, etc. On platforms that support it (e.g. Linux) this should use ZEND_TLS as well. On platforms that don't, we can use the proposed mechanism. We can hardcode the supported globals here, as we don't need to support additional extension globals. It makes no sense to pay the DSO TLS overhead for the TSRM cache variable, and then add the TSRM indirection overhead on top of that, if we can avoid it. Nikita
