>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.
