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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
