Hi, On Thu, Oct 1, 2015 at 11:38 PM, Anatol Belski <anatol....@belski.net> wrote:
> 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? 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. Dmitry. > > Regards > > Anatol > > > >
