On Tue, Oct 6, 2015 at 9:27 AM, Matt Ficken <themattfic...@gmail.com> wrote:
> 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. > This way work. Actually, it's even possible clean opcoache SHM completely or invalidate individual files with SHM mapped into different address. Of course it shpuld be implemented, and I don;t know all the problems yet. > > 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. > What extra memory? Do you mean in-process memory for op_arrays during request processing? > > 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? > If we understand each other properly, It looks like a more or less consistent solution now. This is going to be a self-contained change, so I don't see big problems releasing some fix for PHP-7.0 branch even after GA 7.0.0 release. Of course, we may make final decision only after complete implementation. Thanks. Dmitry. > > > > On Mon, Oct 5, 2015 at 11:49 AM, Eric Stenson <erics...@microsoft.com> > wrote: > >> >From: Dmitry Stogov [mailto:dmi...@zend.com] >> > >> >> On Thu, Oct 1, 2015 at 11:54 AM, Matt Ficken <themattfic...@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. >> > >
