Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: From: "Parker, Ron" To: cygwin AT cygwin DOT com Subject: RE: Mozilla 1.3 built on cygwin? Date: Mon, 31 Mar 2003 19:01:08 -0600 MIME-Version: 1.0 Content-Type: text/plain > Noone has explained, however, *why* the copy-on-write > implementation was > slower. Perhaps we have just been using the wrong tests. Does > copy-on-write > actually perform slower in "real world" tests? I don't know, > because I only While I never posted anything about it to the list. I tried out a few things with copy-on-write, COW, about the time cgf took over around here. I never posted anything because, as others have noted COW actually loses in terms of performance. This is accessing deep memory for me, so it may be inaccurate. But, IIRC the copy-on-write support in NT-based systems is half-documented and half-implemented at the user level. There are things that can be done at the OS level and in the POSIX subsystem with COW that are not exposed in the Win32 subsystem. (Perhaps with a Shared-Source license, but not with just the SDK.) Also given the file format of executables on Windows, there are some other problems. Many of which are introduced by the prevalence of DLLs in the system. As an example, if you have two programs that link to the same DLL and one of them can load the DLL at its base address, but the other has to move it to a different memory location, you will effectively wind up with two copies of the DLL in memory. Each page of the DLL that needs a fixup can no longer be backed by the DLL file itself. Rather, it has to be hauled in to memory, fixed up and then if it gets paged out, it goes to the swap file. This is why rebase'ing an application or properly setting the base addresses of DLLs can so dramatically improve the startup performance of an application. The DLLs don't have to be read into memory the page-table entries, PTEs, just have to be set up. Even if you have two instances of a program running, but they LoadLibrary the same two overlapping DLLs in a different order, you will wind up with two copies of the DLLs in memory. And if the EXE patches itself up, as the code generated some language compilers has been known to do to avoid the extra IVT call for each DLL function, you wind up with two copies of the EXE in memory too. I also seem to recall that there was no guarantee of the OS allocating memory at the address that you request with some of the memory functions. CGF comments in this thread that, "It was almost like Microsoft was purposely twarting[sic] what seems like a reasonable use of memory mapping." That was the same conclusion that I came too. This part may be completely incorrect, but IIRC you don't even have access to be able to setup LDT selectors in an attempt to manage some virtual memory yourself. In the 98/ME DDK there is at least some support for LDT/GDT manipulation. I suppose it might be possible from an NT/2K/XP driver as well, but I never investigated that. I did just a little digging and found that the really funny thing is Knowledge Base Article Q101779 says, "Most 386/486-based memory managers expect to manage page tables; Windows NT cannot allow this for security reasons. "NOTE: Some 286-based memory managers can work on RISC-based computers because VDMs (virtual DOS machines) act as complete 286 machines and applications can control the local and global descriptor tables. " Heh, "cannot allow this for security reasons." Okay, I won't go off on that tangent too far. Anyway, feel free to poke holes in this and bash me about the head and shoulders if it is completely inaccurate I just thought I'd offer what the dust-bunnies were sitting on in my attic and see how it matched up with what others came across. By now, that last paragraph tells me that I need sleep. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/