On Thu, Oct 8, 2015 at 9:47 AM, Matt Ficken <themattfic...@gmail.com> wrote:
> Yes, earlier I was advocating a side-step SHM area for the side-step > OpCache because it'll probably use less memory. Sounded like I lost that > argument, so I switched to in-process heap (which is more complicated too). > > New commit using side-step SHM(not heap): > > https://github.com/php/php-src/commit/92e568270957a63c8b0d1545d9dc0495a851b5c0 > Will opcache_reset() clear only one SHM and keep the side-step one? Thanks. Dmitry. > > > > On Wed, Oct 7, 2015 at 4:39 AM, 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. >> >> 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). >> >> 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 >> >> >
