On Wed, Oct 7, 2015 at 2:39 PM, Anatol Belski <anatol....@belski.net> wrote:
> Hi Matt, > > > -----Original Message----- > > From: Matt Ficken [mailto:themattfic...@gmail.com] > > Sent: Wednesday, October 7, 2015 12:18 PM > > To: Anatol Belski <anatol....@belski.net> > > Cc: Dmitry Stogov <dmi...@zend.com>; Pierre Joye <pierre....@gmail.com>; > > Laruence <larue...@php.net>; PHP Internals <internals@lists.php.net>; > > dmi...@php.net > > Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix > > > > I have a patch for the IPC mechanism we talked about (to avoid > consistency > > problems) and to allocate the side-step OpCache on process's private > heap. > > I've done some quick tests of this on Windows 8.1. > > > > See: > > https://github.com/mattficken/php- > > src/commit/e11b6f010be7d48ed4e29f3a758dffc9acf586fd > > > > I added the ZEND_WIN32_SIDESTEP_TEST macro to shared_alloc_win32.c to > > force using a side-step cache instead of the normal reattach procedure, > for > > testing. > > > > Anatol, this would then fit with your file cache work. > > > > Dmitry, see if my separate of accel_shared_globals and shared_segments > makes > > sense, ~line 250 of shared_alloc_win32.c For safety, I tried to limit > the view of > > memfile to only accel_shared_globals. > > > > > I guess you mean this diff > https://github.com/php/php-src/compare/master...mattficken:master > (otherwise there are quite some remains from your older patches). > > Yeah, some similar idea. I had a similar exercise, but then gave up on it > as discussed with Dmitry. There are at least two issues to falling back to > heap - MapViewOfFile() can fail as well. Then we're in the same situation. > MapViewOfFile() can specifically fail if the requested size is big, as > especially on 32-bit system has to find a contiguous chunk of memory. > I hope this is a theoretical problem. Have you ever seen this? > > But that is also something that can enormously increase memory usage. Say > a user would assign 1Gb to opcache, then every process using sidestep heap > would have to allocate 1Gb ... here we're pretty much at the boundary > again. But even we would do it - it should be the system heap (HeapAlloc, > VirtualAlloc or even malloc). Using ZMM is a wrong strategy at this place. > > For these reasons I was suggesting using a separate shared memory of a > couple of bytes - that is unlikely to fail to reattach. Maybe it could be > even expedient to separate the actual SHM from the adminitstartive items > (like counters, etc) in the future. Doing so would give more flexibility in > such situation where the actual cache is unavailable (like failed to > reattach). > Instead of allocating additional SHM at run-time, we may remap only regular SHM header with opcache shared globals (when the whole SHM can't be map). Thanks. Dmitry. > For mpm_winnt or similar SAPIs using heap only could be expedient. > Something for the future it could be. Right now all the cache is global, > but forcing it to be heap only would prevent users to share it outside > Apcahe. Even though, less bugs of such art would be expected. > > Regards > > Anatol > >
