Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88634
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <024e01d0fc89$31005990$93010cb0$@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>
Date: Fri, 2 Oct 2015 10:34:20 +0300
Message-ID: <CA+9eiLuM6ozhVMU_=YoVDnm=5EbW=VDEUJ8=acffWu_-BQfg+w@mail.gmail.com>
To: Anatol Belski <anatol.php@belski.net>
Cc: Matt Ficken <themattficken@gmail.com>, Pierre Joye <pierre.php@gmail.com>, 
	Anatoliy Belsky <ab@php.net>, Laruence <laruence@php.net>, PHP Internals <internals@lists.php.net>, 
	"dmitry@php.net" <dmitry@php.net>
Content-Type: multipart/alternative; boundary=001a11426c201f95eb05211a31b8
Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix
From: dmitry@zend.com (Dmitry Stogov)

--001a11426c201f95eb05211a31b8
Content-Type: text/plain; charset=UTF-8

Hi,

On Thu, Oct 1, 2015 at 11:38 PM, Anatol Belski <anatol.php@belski.net>
wrote:

> Hi,
>
> > -----Original Message-----
> > From: Dmitry Stogov [mailto:dmitry@zend.com]
> > Sent: Thursday, October 1, 2015 12:20 PM
> > To: Matt Ficken <themattficken@gmail.com>
> > Cc: Pierre Joye <pierre.php@gmail.com>; Anatoliy Belsky <ab@php.net>;
> > Laruence <laruence@php.net>; PHP Internals <internals@lists.php.net>;
> > dmitry@php.net
> > Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix
> >
> > On Thu, Oct 1, 2015 at 11:54 AM, Matt Ficken <themattficken@gmail.com>
> > wrote:
> >
> > >
> > >> And what wincache does. It is slower but the request is served.
> > >>
> > >>
> > >> WinCache (file cache) if it can't reattach, creates a new shared mem
> > >> file
> > > for just that process: see
> > > http://svn.php.net/viewvc/pecl/wincache/trunk/wincache_filemap.c?revis
> > > ion=336846&view=markup
> > > Line 1122.
> > >
> >
> > I'm not sure how WinCache works, but opcache already implements most
> > necessary functionality. Actually we should just:
> > 1) If process can't map SHM - lets map it into different address and
> disable
> > default SHM (ZCG(accel_directives.file_cache_only)=1)
> > 2) extended file_cache may look into improperly mapped segment before
> > reading it from file.
> > But ff course this is more difficult.
> >
> >
> > >
> > > Yes, ideally it would be position independent, maybe using based
> > > pointers for the structs in zend_smm_shared_globals,
> > > zend_accel_shared_globals, etc....
> > >
> > > I agree my bugfix is suboptimal but its the least complex option to
> > > get it fixed for users in 7, so their requests get served.
> > >
> > >
> > > My bugfix would increase memory usage, but so does a 2nd WinCache(or
> 3rd).
> > > But at least if the 2nd OpCache is shared (the same procedure as if no
> > > OpCache existed) its less likely to create a 3rd OpCache. For me at
> > > least, often several processes in a row have this issue, so could have
> > > a 3rd or 4th OpCache or WinCache(even more memory), possibly very
> quickly.
> > >
> >
> > Your proposal is better than WinCache.
> >
> >
> > >
> > > Creating a 2nd OpCache, if its shared or per-process (like WinCache)
> > > seems to be the simpler workaround. The trade-off is memory(especially
> > > if per-process), time to recompile scripts, and sometimes breaking
> > > opcache_reset(), opcache_invalidate() and stat cache pages(shared or
> > > per-process OpCache).
> > >
> >
> > This may break application logic. In worst case different SHM may keep
> different
> > versons of the same script...
> >
> >
> > >
> > > Using the file cache should be better(won't slow down to recompile
> > > scripts). But would still either require changing
> > > zend_shared_alloc_startup() and other places because create_segments()
> > > would still be returning ALLOC_FAILURE, OR creating a 2nd shared or
> > > per-process OpCache anyway. Is this likely to be done? That would be
> > > great, but it seems less likely because of the complexity.
> > >
> >
> > This may be changed in some way.
> >
> >
> > >
> > > Up to 6 OpCaches(5 backups) may be way too many (based off
> > > map_retries, 25 may be too many). My testing only ever gets a 2nd
> > > OpCache(never got a 3rd, etc...).
> > >
> >
> > 6 may be not enough anyway. If we have a limit it's going to be exceeded.
> > MS will improve their ASLR once again... :)
> >
> >
> > > There should be a workaround/suboptimal fix at least until someday
> > > when the optimal solution is done, so requests get served.
> > >
> >
> > In my experience, temporary incomplete solutions are almost never
> replaced
> > with general ones.
> > New and new incomplete fixes are added on top instead.
> > Anyway Anatol, if you have time, can you please play with patch and give
> your
> > opinion.
> >
> Yeah, I'll be testing that as well anyway, now that RC4 is out. I was
> intended also to do some synthetic tests, because seems some (especially
> 32-bit) environments are affected more than others. Namely, I'm trying hard
> to get this issue on 64-bit with no chance.
>
> IMHO creating the sidestep caches looks not convincing. From the issues
> mentioned, like different cached script versions, but also indeed taking
> away the control over memory limit, etc. Even one would decide for that,
> the other mentioned parts would need to be fixed. Is that something
> achievable to fix in the current state?
>
> 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. Dmitry.


>
> Regards
>
> Anatol
>
>
>
>

--001a11426c201f95eb05211a31b8--