Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88690
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.68 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BN1PR03MB105DC68CC54338343F53AC7D0480@BN1PR03MB105.namprd03.prod.outlook.com>
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>
	<BN1PR03MB105DC68CC54338343F53AC7D0480@BN1PR03MB105.namprd03.prod.outlook.com>
Date: Mon, 5 Oct 2015 23:27:30 -0700
Message-ID: <CAMbn9ZEb8wX+sP9pnRmX3XdxshpHYnb79rBy9PYy-VuL+tTB6Q@mail.gmail.com>
To: Eric Stenson <ericsten@microsoft.com>
Cc: Dmitry Stogov <dmitry@zend.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=001a11c3ccaa790eaf052169b982
Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix
From: themattficken@gmail.com (Matt Ficken)

--001a11c3ccaa790eaf052169b982
Content-Type: text/plain; charset=UTF-8

Ultimately if the 2nd OpCache is shared in a new SHM, in-process in a new
SHM or in-process Heap, memory will increase, scripts have to be recompiled
and there are consistency issues. File-cache will avoid recompiling
scripts, but unless OpCache is disabled, there needs to be a 2nd OpCache
stored somewhere.

For the stat, reset and revalidate consistency issues, to build off
Anatol's idea:  If can't reattach to base address, then reattach to any
address and create a 2nd OpCache in Heap, BUT keep the SHM open so that the
stat fields(fe ZCSG(hits)) are still accessible. Those fields aren't
pointers so they should work from whatever base address MapViewOfFileEx()
provides, if not, could fork ZCSG into 2 structs (somehow reuse existing
stat fields on existing SHM).

opcache_get_status() in any/all processes would read those fields from SHM.


Since there would be 2+ processes with an OpCache (the original in SHM, and
sidestep OpCaches on the heaps of those processes), can't use a simple flag
(would be cleared by 2nd process, before 3rd got it).  Could add
ZCSG(opcache_count) field and increment every time an OpCache gets created
(and decrement on process exit). Simple, but not using
zend_shared_alloc_lock() avoids creating new locking issues.

Add a new ZCSG(opcache_revalidate_count) in that struct that is set to
ZCSG(opcache_count) anytime opcache_reset() or opcache_invalidate() called
or if persistent_compile_file() finds a changed script.

In process with side-step OpCache,  in persistent_compile_file()  (assuming
opcache.validate_timestamps && revalidate_freq>0) will check if
ZCSG(opcache_revalidate_count) > 0 and will then decrement the count and
reload scripts from file-cache (where it checks opcache.revalidate_freq).
And then wrap this all in some `#ifdef ZEND_WIN32`s


Would still have extra memory usage. When I have a process that can't
reattach I usually get several, so having an in-process OpCache(SHM or
Heap) may lead to more memory usage than a shared SHM, but having 2 SHMs in
a process would mess up the nice existing code.

Don't have to recompile scripts(quickly loads from file-cache) and fixes
the 3 consistency issues, and would keep serving up requests without
performance loss.

Yes, temporary incomplete solutions often get forgotten and not replaced
later with a better complete solution, but in this case we're motivated try
to fully fix this whole issue and if that doesn't work, at least build a
more complete solution, but that takes time (known issue for already a few
years), we should do something that works for now. This is more complex
than a bugfix that creates a 2nd SHM OpCache. Can we do this now? What is
still possible for 7.0? 7.0.1?



On Mon, Oct 5, 2015 at 11:49 AM, Eric Stenson <ericsten@microsoft.com>
wrote:

> >From: Dmitry Stogov [mailto:dmitry@zend.com]
> >
> >> On Thu, Oct 1, 2015 at 11:54 AM, Matt Ficken <themattficken@gmail.com>
> >> wrote:
> >>
> >>> Pierre Joy 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
> >
> > I'm not sure how WinCache works, but opcache already implements most
> > necessary functionality.
>
> Sorry for getting to the party late, but let me clarify what WinCache does:
>
> 1. For the opcode cache, if WinCache can't map to the same address, it
> falls back to using process-local (heap) memory for the opcode arrays.
> This is because the elements in the opcode arrays contain absolute
> pointers, and we don't want to spend cycles (a) converting all pointers to
> offsets when copying opcode arrays into shared memory, and then (b)
> converting all offsets back to absolute addresses when copying the opcode
> array back out of shared memory.  WinCache simply gets the pointer to the
> opcode array in shared memory and returns it, unmodified, to the PHP Core
> for execution.
>
> When WinCache falls back to process-local memory, it does NOT create a
> second memory mapped segment, and does not chew additional cross-process
> resources.
>
> 2. WinCache's file cache does not map to an identical address in all
> processes.  We simply map it to *any* address (using NULL for the suggested
> address to MapViewOfFileEx), and then use relative offsets in the cache
> structures for all entries in shared memory.
>
> 3. WinCache's user cache and session cache are similar to the file cache,
> and do not have to map to the same address in all processes. Cache entries
> use relative offsets to locate cache entries, and the values do not contain
> absolute addresses.
>
> Finally, For PHP7, WinCache has removed its opcode cache.  We assume that
> Windows consumers of PHP7 will use Zend Opcache for opcode caching.
>
> Thx!
>     --E.
>

--001a11c3ccaa790eaf052169b982--