Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:88681 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 53354 invoked from network); 5 Oct 2015 12:52:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Oct 2015 12:52:12 -0000 Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error) X-PHP-List-Original-Sender: anatol.php@belski.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:33594] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 69/B0-49113-A7272165 for ; Mon, 05 Oct 2015 08:52:10 -0400 Received: by h1123647.serverkompetenz.net (Postfix, from userid 1006) id 681E06D2004; Mon, 5 Oct 2015 14:52:06 +0200 (CEST) Received: from w530phpdev (p579F3C74.dip0.t-ipconnect.de [87.159.60.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by h1123647.serverkompetenz.net (Postfix) with ESMTPSA id C034C6D2002; Mon, 5 Oct 2015 14:52:02 +0200 (CEST) To: "'Dmitry Stogov'" Cc: "'Matt Ficken'" , "'Pierre Joye'" , "'Laruence'" , "'PHP Internals'" , References: <024e01d0fc89$31005990$93010cb0$@belski.net> <01e101d0ff3f$8cc0c310$a6424930$@belski.net> In-Reply-To: Date: Mon, 5 Oct 2015 14:51:59 +0200 Message-ID: <029301d0ff6c$a1cc8370$e5658a50$@belski.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-index: AQHEZydHUDlzPZMYkUAa9TBZ2Cu8iQH1cSltAgxS6RICvBKMXgJg6u78Alds+IoBNSLbHgFWewTNAfDhgDUDBDbNGgG2fzgSAhjymcEBqWuthwI65uQHnaCw8kA= Content-Language: en-us Subject: RE: [PHP-DEV] Re: Windows OpCache bug fix From: anatol.php@belski.net ("Anatol Belski") > -----Original Message----- > From: Dmitry Stogov [mailto:dmitry@zend.com] > Sent: Monday, October 5, 2015 1:08 PM > To: Anatol Belski > Cc: Matt Ficken ; Pierre Joye > ; Laruence ; PHP Internals > ; dmitry@php.net > Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix >=20 > On Mon, Oct 5, 2015 at 10:29 AM, Anatol Belski > wrote: >=20 > > Hi Dmitry, > > > > > -----Original Message----- > > > From: Dmitry Stogov [mailto:dmitry@zend.com] > > > Sent: Friday, October 2, 2015 9:34 AM > > > To: Anatol Belski > > > Cc: Matt Ficken ; Pierre Joye > > > ; Anatoliy Belsky ; Laruence > > > ; PHP Internals ; > > dmitry@php.net > > > Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix > > > > > > > Dmitry, I'd have a question to this > > > > > Also. if we can't map SHM into desired address space, we may = map > > > > > it in > > > > any > > > > > other address and copy data into the process memory similar to > > > > file-cache. > > > > In randomized memory layout, even the base were available and > > > > OpenFileMapping were worky, some parts of that memory were = already > > > taken. > > > > How exactly it could be done, could you please give a couple of > > > > pointers to this? > > > > > > > > > If MapViewOfFileEx(..., wanted_mapping_base) fails, we do > > > MapViewOfFileEx(..., NULL). > > > > > > > > > > Would the file cache be always required then? > > > > > > > > > > This is not necessary, but depends on implementation of course. > > > > > Thanks for the advice. I was playing with this over these days. = There > > are two usual cases where it possibly fails when reattaching ATM > > > > - > > = https://github.com/php/php-src/blob/PHP-7.0/ext/opcache/shared_alloc_w > > in32.c#L151 > > - the saved address is available but is not suitable > > - > > = https://github.com/php/php-src/blob/PHP-7.0/ext/opcache/shared_alloc_w > > in32.c#L159 > > - the actual MapViewOfFileEx case > > > > An unrelated plain C test shows, that MapViewOfFileEx can possibly > > fail when called second time, too. Even with NULL or with another > > address as base. But even if it could map at a different base - the > > internal structures will probably have invalid addresses. >=20 >=20 > right. we might need different code for zend_accle_hash access or = convert > corresponding structures to PIC. > For opcdeos "invalid address" don't matter because we will copy them = into > process memory and fix (like in file-cache). >=20 Ah, I have to study the file cache code then. But generally it sounds = not like something that can be done offhand. I've also thought about = other things like interned strings (maybe something else), not sure = they're stored with the cache. >=20 > > So it looks like there's indeed no profit to do any retry once the > > actualy base address needed was failed to reattach to. > > > > IMHO the scenario that were usable - in case it fails to reattach to > > the exact address, it has to switch to heap. Just for one request, = it > > should get a heap allocated segment and then invalidate all the = cache. > > That way we fulfill the following > > > > - the request is served for sure > > - the scripts are not cached indeed, so no divergence with the = actual > > real cache > > > > A heap fallback memory handler would be probably quite easy to = implement. > > What do you think? > > > > Apropos with the heap - it also looks like when PHP is used as = module > > under mpm_winnt, all the cache could use heap instead of SHM. In = that > > case, there is only one Apache process serving with many threads. > > Except one would want to share that cache outside Apache, using heap > > there could be a much simpler solution. > > >=20 > Heap based cache makes the same problems. It increase the memory usage = and > doesn't provide cache consistency. > Just fall-back to file-cache may be better. Do you think something like this would suffice as file cache fallback = https://gist.github.com/weltling/224001a468f04de13693 ? Though it'd = still diverge from the "main" cache. Actually in such case all the processes should switch to file cache? = Just not sure how they all would negotiate that when no SHM is available = (probably through files, or a separate shared chunk). >=20 > Actually, when I implemented file-cache I had a though about different = storage > back-ends (e.g. sqlite or memcache). > This abstraction might make support for "improperly mapped SHM" quite = easy. >=20 Yeah, that could be useful. Maybe also module based so one could even = supply them separately, then an arbitrary storage mechanism could be = provided. Fe like I've mentioned for mpm_winnt -if there's no intention = to share the cache outside Apache, just one heap for all could be much = simpler to avoid all that reattach mechanics. Thanks. Anatol