1541575 - Ensure we're properly prefetching OSX shared libs with ReadAheadLib

Status: NEW

(Toolkit :: Startup and Profile System, task, P3)

Description

[Alex Thayer [:alexical] (she/her)]

I'm seeing very promising results with rewriting the Windows side of ReadAheadLib in bug 1538279. I suspect that we have a similar problem on OSX (and maybe Linux). To do our readahead, we make a ScopedMMap, which under the hood calls mmap with PROT_READ. I believe this is incorrect, and we need to mmap with PROT_EXEC, otherwise it's not going to be cached when we try to load it (which mmap's with PROT_EXEC under the hood as I understand). I'm not positive of this, but the reason why it would be the case is that, say you mmap something with PROT_READ and then immediately mmap the same thing with PROT_READ - I believe the file will be loaded into a place in physical memory described by the Global Descriptor Table as readable but not executable. Then when you map the file with PROT_EXEC, it will have to load the file into a place in physical memory described as executable. This matches what I was seeing on Windows, and I suspect we have the same problem on all OSes.

This means any benefit we see from prefetching the library files was likely just due to hardware effects.

Comment 1

[Alex Thayer [:alexical] (she/her)]

Hmm, unfortunately it doesn't seem to be that simple. What we have today does seem to not work as intended. A simple test app that times how long it takes to load XUL is not affected by prefetching the file in the way we do it right now, but it is strongly affected by having actually loaded XUL as a library on the system already. However, simply changing the mmap to PROT_EXEC does not magically fix this problem. I've tried a few more things and none of them have had any effect. In the mean time I'm taking a look at what talos looks like when we just disable the readahead, but a proper readahead solution would be ideal.