Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88735
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.195 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: Wed, 7 Oct 2015 23:47:38 -0700
Message-ID: <CAMbn9ZF+WgYKiTMFoHzza=rT1RsT+UrG4MbeB-+ALqz4T9SowQ@mail.gmail.com>
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
Content-Type: multipart/alternative; boundary=047d7b3434022e07950521923dd4
Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix
From: themattficken@gmail.com (Matt Ficken)

--047d7b3434022e07950521923dd4
Content-Type: text/plain; charset=UTF-8

Yes, earlier I was advocating a side-step SHM area for the side-step
OpCache because it'll probably use less memory. Sounded like I lost that
argument, so I switched to in-process heap (which is more complicated too).

New commit using side-step SHM(not heap):
https://github.com/php/php-src/commit/92e568270957a63c8b0d1545d9dc0495a851b5c0


On Wed, Oct 7, 2015 at 4:39 AM, 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.
>
> 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).
>
> 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
>
>

--047d7b3434022e07950521923dd4--