Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:88673 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 26782 invoked from network); 5 Oct 2015 07:29:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Oct 2015 07:29:32 -0000 Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; 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:47872] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F7/00-25903-7D622165 for ; Mon, 05 Oct 2015 03:29:28 -0400 Received: by h1123647.serverkompetenz.net (Postfix, from userid 1006) id B39BF6D2002; Mon, 5 Oct 2015 09:29:23 +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 25CA36D2002; Mon, 5 Oct 2015 09:29:20 +0200 (CEST) To: "'Dmitry Stogov'" Cc: "'Matt Ficken'" , "'Pierre Joye'" , "'Laruence'" , "'PHP Internals'" , References: <024e01d0fc89$31005990$93010cb0$@belski.net> In-Reply-To: Date: Mon, 5 Oct 2015 09:29:17 +0200 Message-ID: <01e101d0ff3f$8cc0c310$a6424930$@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+IoBNSLbHgFWewTNAfDhgDUDBDbNGgG2fzgSAhjymcGdv3TmoA== Content-Language: en-us Subject: RE: [PHP-DEV] Re: Windows OpCache bug fix From: anatol.php@belski.net ("Anatol Belski") 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 >=20 > > 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? >=20 >=20 > If MapViewOfFileEx(..., wanted_mapping_base) fails, we do > MapViewOfFileEx(..., NULL). >=20 >=20 > > Would the file cache be always required then? > > >=20 > This is not necessary, but depends on implementation of course. >=20 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_win3= 2.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_win3= 2.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. 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. Regards Anatol