Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88727
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <036a01d100f4$df598060$9e0c8120$@belski.net>
References: <CAMbn9ZEHXT7SPCo1ai4FpVfjR7X+vPe+uEOKwY13VDdJR4g6+g@mail.gmail.com>
	<CA+9eiLsu2K9v-89w8RbHvyd=yH+Nu_tQLnzucRWhr1CzdhGciA@mail.gmail.com>
	<CAMbn9ZEKG0c=xaDiN5hzxC2H+rvL2pszUh3-+D+n+QXvopejbQ@mail.gmail.com>
	<CA+9eiLtHFFXFqOA18VJGKULgqHqjx=krPWQxBrSnb-V2MogQ1w@mail.gmail.com>
	<CA+9eiLt=qF8yy0rPYqUH3ZdrNRUvkCo94gbR685SB5NRD2wacQ@mail.gmail.com>
	<CAMbn9ZHcZ3FZHyGDKMwjAWBKW4Wum84q9ShUJ+ES8eqaK+Oyvw@mail.gmail.com>
	<CA+9eiLtwyayxzbTT+0Fi7JnB9WPc7SkUFH+r3vOW49bdjRCUJw@mail.gmail.com>
	<CAEZPtU5YKUOeNT0G3=8fyy3g0Fug1ZpMkSE_th35YKM9azamEA@mail.gmail.com>
	<CAMbn9ZGq0+VgSjfSsoozKat5WKjVLLUpN8LWSqS81Hym2LybVQ@mail.gmail.com>
	<CA+9eiLt=WZfvA=i+rCCs27LewBS+gCbvLAGbVHOFe_37=r+j_Q@mail.gmail.com>
	<024e01d0fc89$31005990$93010cb0$@belski.net>
	<CA+9eiLuM6ozhVMU_=YoVDnm=5EbW=VDEUJ8=acffWu_-BQfg+w@mail.gmail.com>
	<01e101d0ff3f$8cc0c310$a6424930$@belski.net>
	<CA+9eiLsL3+rBFap6xQXtPx3gvkEWB_mcRYk8cE7awHGK9gfBEg@mail.gmail.com>
	<029301d0ff6c$a1cc8370$e5658a50$@belski.net>
	<CA+9eiLs1S=Vm_g04eq9LLzsDB7T3LhpRWFXZThzC-_ziPPrQJA@mail.gmail.com>
	<020701d1004a$216370c0$642a5240$@belski.net>
	<CAMbn9ZFLJD4FAxf94h9cB+Vzx=x_3SAmu867PRpg=DWB7FvQHg@mail.gmail.com>
	<036a01d100f4$df598060$9e0c8120$@belski.net>
Date: Thu, 8 Oct 2015 11:41:07 +0300
Message-ID: <CA+9eiLuzJXV=g6f3Lxvk_OB=dGbGTb1Y1A_LaRDbADCOLmf=rg@mail.gmail.com>
To: Anatol Belski <anatol.php@belski.net>
Cc: Matt Ficken <themattficken@gmail.com>, Pierre Joye <pierre.php@gmail.com>, 
	Laruence <laruence@php.net>, PHP Internals <internals@lists.php.net>, 
	"dmitry@php.net" <dmitry@php.net>
Content-Type: multipart/alternative; boundary=001a11415a8eff5c52052193d22b
Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix
From: dmitry@zend.com (Dmitry Stogov)

--001a11415a8eff5c52052193d22b
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 7, 2015 at 2:39 PM, Anatol Belski <anatol.php@belski.net> wrote:

> Hi Matt,
>
> > -----Original Message-----
> > From: Matt Ficken [mailto:themattficken@gmail.com]
> > Sent: Wednesday, October 7, 2015 12:18 PM
> > To: Anatol Belski <anatol.php@belski.net>
> > Cc: Dmitry Stogov <dmitry@zend.com>; Pierre Joye <pierre.php@gmail.com>;
> > Laruence <laruence@php.net>; PHP Internals <internals@lists.php.net>;
> > dmitry@php.net
> > Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix
> >
> > I have a patch for the IPC mechanism we talked about (to avoid
> consistency
> > problems) and to allocate the side-step OpCache on process's private
> heap.
> > I've done some quick tests of this on Windows 8.1.
> >
> > See:
> > https://github.com/mattficken/php-
> > src/commit/e11b6f010be7d48ed4e29f3a758dffc9acf586fd
> >
> > I added the ZEND_WIN32_SIDESTEP_TEST macro to shared_alloc_win32.c to
> > force using a side-step cache instead of the normal reattach procedure,
> for
> > testing.
> >
> > Anatol, this would then fit with your file cache work.
> >
> > Dmitry, see if my separate of accel_shared_globals and shared_segments
> makes
> > sense, ~line 250 of shared_alloc_win32.c  For safety, I tried to limit
> the view of
> > memfile to only accel_shared_globals.
> >
> >
> I guess you mean this diff
> https://github.com/php/php-src/compare/master...mattficken:master
> (otherwise there are quite some remains from your older patches).
>
> Yeah, some similar idea. I had a similar exercise, but then gave up on it
> as discussed with Dmitry. There are at least two issues to falling back to
> heap - MapViewOfFile() can fail as well. Then we're in the same situation.
> MapViewOfFile() can specifically fail if the requested size is big, as
> especially on 32-bit system has to find a contiguous chunk of memory.
>

I hope this is a theoretical problem. Have you ever seen this?


>
> But that is also something that can enormously increase memory usage. Say
> a user would assign 1Gb to opcache, then every process using sidestep heap
> would have to allocate 1Gb ... here we're pretty much at the boundary
> again. But even we would do it - it should be the system heap (HeapAlloc,
> VirtualAlloc or even malloc). Using ZMM is a wrong strategy at this place.
>
> For these reasons I was suggesting using a separate shared memory of a
> couple of bytes - that is unlikely to fail to reattach. Maybe it could be
> even expedient to separate the actual SHM from the adminitstartive items
> (like counters, etc) in the future. Doing so would give more flexibility in
> such situation where the actual cache is unavailable (like failed to
> reattach).
>

Instead of allocating additional SHM at run-time, we may remap only regular
SHM header with opcache shared globals (when the whole SHM can't be map).

Thanks. Dmitry.


> For mpm_winnt or similar SAPIs using heap only could be expedient.
> Something for the future it could be. Right now all the cache is global,
> but forcing it to be heap only would prevent users to share it outside
> Apcahe. Even though, less bugs of such art would be expected.
>
> Regards
>
> Anatol
>
>

--001a11415a8eff5c52052193d22b--