Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104445 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 69373 invoked from network); 16 Feb 2019 14:29:04 -0000 Received: from unknown (HELO mail-it1-f170.google.com) (209.85.166.170) by pb1.pair.com with SMTP; 16 Feb 2019 14:29:04 -0000 Received: by mail-it1-f170.google.com with SMTP id z131so19884602itf.5 for ; Sat, 16 Feb 2019 03:12:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j2ObKpkIcTaiMRWiGI03rBlo1SUlwm2m9JRNQ9xAe9g=; b=eG6OLLQ6voX/Jj1IbdxPE4AQ2XDzKjbfSJXB3EixMVI2IZqUUJHtqyh66uC0BjSdZg 5iWbf1q8aHGNm0cypWVCP4CQaILFA0zVYw2Ja3lgHBljpbEHhKJTHGtohZOgji5jE4g0 A5Zv+iPLaqIwFJhRPYh38uPFGDclVZJE1vt+Ci1y54116QOgTHTVQsWwmFf2geJpGlXs x8CUH18l/KAdKXrkN3+tMouRfrAo4Lc248zpitkS7gwL0vR3g5aPIatjl4bA3BAB8qvd FVpqW9Bs7l2M0hOA1NTOhF3NJeRW2IuJAZ3tjQ7clX9EO5OydQiIhbpE7peYsE4Oclg+ Cz6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j2ObKpkIcTaiMRWiGI03rBlo1SUlwm2m9JRNQ9xAe9g=; b=BJFb7kY7m5N70X/Dq5/b/Zcf49dix5DZv0aHlwBW86W92w+V8BdFwRkdgG23jCHGou hvCB9d47RxqFoOC21KpxEReF5SJMZ4FF+Xg33FdUZeIe5tf3guuLmMeotG5k8MHFICSk PGCTe5cA06EmzIEsj813iultruQh7LIsazpSbXnxL0r9GwcSfkRlq+AknuFB6FJDEzuw IVo0Fd/GBcroPL6s04A3YX4MbfSxElOhoTpEFzDJBE4vSUcFFU19dRO/NlrVVZYbRP0d Bzmnv+rS8jw90ldV4sFQ33PtfBB5ybymb/9Dy92dk+VMTlhJF6UQr4fY17XGn81bYxIL YwHQ== X-Gm-Message-State: AHQUAuYhOD8MdAikvdy2XkCy4lSfEo4zV3vFEh6l0xaqp+6nriLwu4di 72mMuynxm7E9oiWhKMsfViG95p/SkEGKyV8wmgc= X-Google-Smtp-Source: AHgI3IZiLYDRZdnn/rFIwRPuzhXlNP9/MVAzYS0qAEjDaoigQUBjlsIk639W8GksU1k3f/VcXCAXNaDEq3dt2LxBO/s= X-Received: by 2002:a5d:91d3:: with SMTP id k19mr8357938ior.258.1550315575953; Sat, 16 Feb 2019 03:12:55 -0800 (PST) MIME-Version: 1.0 References: <01ae563a-96c4-d544-835c-85ab91a6acea@zend.com> In-Reply-To: Date: Sat, 16 Feb 2019 12:12:38 +0100 Message-ID: To: Anatol Belski Cc: Dmitry Stogov , Joe Watkins , Bob Weinand , Nikita Popov , "zeev@php.net" , PHP internals Content-Type: multipart/alternative; boundary="00000000000031cc2a058200f991" Subject: Re: ZTS improvement idea From: nikita.ppv@gmail.com (Nikita Popov) --00000000000031cc2a058200f991 Content-Type: text/plain; charset="UTF-8" On Sat, Feb 16, 2019 at 7:51 AM Anatol Belski 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 --00000000000031cc2a058200f991--