Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:88726 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 93754 invoked from network); 9 Oct 2015 20:54:21 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Oct 2015 20:54:21 -0000 Authentication-Results: pb1.pair.com header.from=dmitry@zend.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=dmitry@zend.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.53 as permitted sender) X-PHP-List-Original-Sender: dmitry@zend.com X-Host-Fingerprint: 209.85.213.53 mail-vk0-f53.google.com Received: from [209.85.213.53] ([209.85.213.53:34717] helo=mail-vk0-f53.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C5/C6-57614-C7928165 for ; Fri, 09 Oct 2015 16:54:21 -0400 Received: by vkat63 with SMTP id t63so58748600vka.1 for ; Fri, 09 Oct 2015 13:54:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YObqdXorO+mV85CjKUkZFGEm/idXmdwX7gxipEUB7Es=; b=ijDxz2HOX9X34uaraSYUIrI+KDUTjrgvAQu7ci6N9P5AornBpf9gSigV5Vl6cKQr98 it4AkbncBlzfDU/woPvvc0HyGdrGpzJdpRbXLCBSEEPqjmIBjGSRLUyv59KkJhWxGlgN 3qL7KQHrPB2+WKHH/cS7/aSVjsUr7ggzi/nW11aN1o+j2I446TIFSMxJOHoY1O8vIlJ1 q6+ThOSkbzfi/JsqgLgOh0m9dUivbhc3ZD5OROoY4tC0fLBpGa53Y7lhdLY6OCriRyp4 vPlA+GZ87d0djwmFSqkmiSPMLY6/P4ZudidSc6NT19NQdQXsDxtjyg2dzbF/BouXkfvT GTAg== X-Gm-Message-State: ALoCoQl15O6y6PLecvA/HL2UBu0SCbt/bL0jTTZjfbo9rs5IzkjnY4vQqVNUBJcMn40Qeq38DM/jJFqgMx5MqEQHD8dt5cClCYQYqoJRjc3jadXWPZP2SCF0jSonXp1IJEv8f+GNPwIRKEyYQXg6UKHmEMsP1Vwtd/ys1lxGUAgozn/8cEycc+o= MIME-Version: 1.0 X-Received: by 10.31.108.91 with SMTP id h88mr3842183vkc.57.1444293953231; Thu, 08 Oct 2015 01:45:53 -0700 (PDT) Received: by 10.103.24.5 with HTTP; Thu, 8 Oct 2015 01:45:53 -0700 (PDT) In-Reply-To: References: <024e01d0fc89$31005990$93010cb0$@belski.net> <01e101d0ff3f$8cc0c310$a6424930$@belski.net> <029301d0ff6c$a1cc8370$e5658a50$@belski.net> <020701d1004a$216370c0$642a5240$@belski.net> <036a01d100f4$df598060$9e0c8120$@belski.net> Date: Thu, 8 Oct 2015 11:45:53 +0300 Message-ID: To: Matt Ficken Cc: Anatol Belski , Pierre Joye , Laruence , PHP Internals , "dmitry@php.net" Content-Type: multipart/alternative; boundary=001a11478f4408bdeb052193e45b Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix From: dmitry@zend.com (Dmitry Stogov) --001a11478f4408bdeb052193e45b Content-Type: text/plain; charset=UTF-8 On Thu, Oct 8, 2015 at 9:47 AM, Matt Ficken 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 > wrote: > >> Hi Matt, >> >> > -----Original Message----- >> > From: Matt Ficken [mailto:themattficken@gmail.com] >> > Sent: Wednesday, October 7, 2015 12:18 PM >> > To: Anatol Belski >> > Cc: Dmitry Stogov ; Pierre Joye > >; >> > Laruence ; PHP Internals ; >> > dmitry@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 >> >> > --001a11478f4408bdeb052193e45b--