Hi, > -----Original Message----- > From: Dmitry Stogov [mailto:dmi...@zend.com] > Sent: Thursday, October 1, 2015 12:20 PM > To: Matt Ficken <themattfic...@gmail.com> > Cc: 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 > > On Thu, Oct 1, 2015 at 11:54 AM, Matt Ficken <themattfic...@gmail.com> > 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 > > for just that process: see > > http://svn.php.net/viewvc/pecl/wincache/trunk/wincache_filemap.c?revis > > ion=336846&view=markup > > Line 1122. > > > > I'm not sure how WinCache works, but opcache already implements most > necessary functionality. Actually we should just: > 1) If process can't map SHM - lets map it into different address and disable > default SHM (ZCG(accel_directives.file_cache_only)=1) > 2) extended file_cache may look into improperly mapped segment before > reading it from file. > But ff course this is more difficult. > > > > > > Yes, ideally it would be position independent, maybe using based > > pointers for the structs in zend_smm_shared_globals, > > zend_accel_shared_globals, etc.... > > > > I agree my bugfix is suboptimal but its the least complex option to > > get it fixed for users in 7, so their requests get served. > > > > > > My bugfix would increase memory usage, but so does a 2nd WinCache(or 3rd). > > But at least if the 2nd OpCache is shared (the same procedure as if no > > OpCache existed) its less likely to create a 3rd OpCache. For me at > > least, often several processes in a row have this issue, so could have > > a 3rd or 4th OpCache or WinCache(even more memory), possibly very quickly. > > > > Your proposal is better than WinCache. > > > > > > Creating a 2nd OpCache, if its shared or per-process (like WinCache) > > seems to be the simpler workaround. The trade-off is memory(especially > > if per-process), time to recompile scripts, and sometimes breaking > > opcache_reset(), opcache_invalidate() and stat cache pages(shared or > > per-process OpCache). > > > > This may break application logic. In worst case different SHM may keep > different > versons of the same script... > > > > > > Using the file cache should be better(won't slow down to recompile > > scripts). But would still either require changing > > zend_shared_alloc_startup() and other places because create_segments() > > would still be returning ALLOC_FAILURE, OR creating a 2nd shared or > > per-process OpCache anyway. Is this likely to be done? That would be > > great, but it seems less likely because of the complexity. > > > > This may be changed in some way. > > > > > > Up to 6 OpCaches(5 backups) may be way too many (based off > > map_retries, 25 may be too many). My testing only ever gets a 2nd > > OpCache(never got a 3rd, etc...). > > > > 6 may be not enough anyway. If we have a limit it's going to be exceeded. > MS will improve their ASLR once again... :) > > > > There should be a workaround/suboptimal fix at least until someday > > when the optimal solution is done, so requests get served. > > > > In my experience, temporary incomplete solutions are almost never replaced > with general ones. > New and new incomplete fixes are added on top instead. > Anyway Anatol, if you have time, can you please play with patch and give your > opinion. > Yeah, I'll be testing that as well anyway, now that RC4 is out. I was intended also to do some synthetic tests, because seems some (especially 32-bit) environments are affected more than others. Namely, I'm trying hard to get this issue on 64-bit with no chance.
IMHO creating the sidestep caches looks not convincing. From the issues mentioned, like different cached script versions, but also indeed taking away the control over memory limit, etc. Even one would decide for that, the other mentioned parts would need to be fixed. Is that something achievable to fix in the current state? 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? Would the file cache be always required then? Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
