On Mon, Oct 5, 2015 at 10:29 AM, Anatol Belski <anatol....@belski.net> wrote:
> Hi Dmitry, > > > -----Original Message----- > > From: Dmitry Stogov [mailto:dmi...@zend.com] > > Sent: Friday, October 2, 2015 9:34 AM > > To: Anatol Belski <anatol....@belski.net> > > Cc: Matt Ficken <themattfic...@gmail.com>; Pierre Joye > > <pierre....@gmail.com>; Anatoliy Belsky <a...@php.net>; Laruence > > <larue...@php.net>; PHP Internals <internals@lists.php.net>; > dmi...@php.net > > Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix > > > > > 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 for the advice. I was playing with this over these days. There are > two usual cases where it possibly fails when reattaching ATM > > - > https://github.com/php/php-src/blob/PHP-7.0/ext/opcache/shared_alloc_win32.c#L151 > - the saved address is available but is not suitable > - > https://github.com/php/php-src/blob/PHP-7.0/ext/opcache/shared_alloc_win32.c#L159 > - the actual MapViewOfFileEx case > > An unrelated plain C test shows, that MapViewOfFileEx can possibly fail > when called second time, too. Even with NULL or with another address as > base. But even if it could map at a different base - the internal > structures will probably have invalid addresses. right. we might need different code for zend_accle_hash access or convert corresponding structures to PIC. For opcdeos "invalid address" don't matter because we will copy them into process memory and fix (like in file-cache). > So it looks like there's indeed no profit to do any retry once the actualy > base address needed was failed to reattach to. > > IMHO the scenario that were usable - in case it fails to reattach to the > exact address, it has to switch to heap. Just for one request, it should > get a heap allocated segment and then invalidate all the cache. That way we > fulfill the following > > - the request is served for sure > - the scripts are not cached indeed, so no divergence with the actual real > cache > > A heap fallback memory handler would be probably quite easy to implement. > What do you think? > > Apropos with the heap - it also looks like when PHP is used as module > under mpm_winnt, all the cache could use heap instead of SHM. In that case, > there is only one Apache process serving with many threads. Except one > would want to share that cache outside Apache, using heap there could be a > much simpler solution. > Heap based cache makes the same problems. It increase the memory usage and doesn't provide cache consistency. Just fall-back to file-cache may be better. Actually, when I implemented file-cache I had a though about different storage back-ends (e.g. sqlite or memcache). This abstraction might make support for "improperly mapped SHM" quite easy. Thanks. Dmitry. > > Regards > > Anatol > > > >
