RE: Mozilla 1.3 built on cygwin?

["Parker, Ron" <rdparker at butlermfg dot com>]

> 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/