Performance optimization in av::fixup - use buffered IO, not mapped file

[Ryan Johnson]

On 10/12/2012 10:51 PM, Daniel Colascione wrote:
> On 12/10/2012 6:32 PM, Ryan Johnson wrote:
>> On 10/12/2012 8:41 PM, Daniel Colascione wrote:
>>> On 12/10/2012 5:36 PM, Ryan Johnson wrote:
>>>> I never reported it because I figured there was no way cygwin could make Windows
>>>> decide what files to cache or not cache... but it would definitely be nice to
>>>> see the problem go away.
>>> This behavior is definitely surprising. It's sort of an evil-genie way to
>>> provide cache coherency, I suppose.
>>>
>>>>> Now, if we run emacs.exe from cmd, not bash, that's exactly what happens:
>>>> <snip>
>>>>> I came up with a simple test case that reproduces in cmd the behavior I see
>>>>> when
>>>>> I run Emacs from bash. I've reproduced the program below. Here, I've compiled
>>>>> a.exe with -DSLOW:
>>>> I tried to test on my machine (w7 x64), but I can't get it to compile
>>>> (GetFileSizeEx not found at link time):
>>>>
>>>> i686-pc-mingw32-gcc emacs-slow.c -DSLOW -lkernel32
>>> I just used i686-w64-mingw32-gcc. I didn't even need -lkernel32.
>> OK, that compiles, but I can't repro:
> I can't repro it with the stock emacs-nox or emacs-X11 either, even as
> administrator. But I can consistently repro it with any Emacs I build. More
> bizarrely, if I take an emacs binary I've build and hardlink it into /bin, I can
> repro the problem. If I _copy_ the binary instead of hardlinking it, I can't
> repro, even though the copy has the same hard link count and ACL as the
> hardlinked version.
>
> The key to generating a binary that repros the problem is to unexec emacs, then
> try to repro with that generated binary, not a copy of it. Maybe the process of
> modifying the binary during unexec borks the system's ASLR cache; I can't
> reproduce the problem with a simple testcase that copies and modifies the
> binary, but my test doesn't actually change the binary --- it just writes back
> to the destination binary exactly what we read from it.
That doesn't explain why gcc stage1/2 compilers (in ./xgcc) would have 
the problem. At least, I don't think gcc self-modifies when invoked from 
./configure...

But you're right. Once the compiler has been officially installed 
somewhere (not necessarily /usr/bin) it runs normally. Very weird.

Ryan