Opportunistic CoW for platforms that support it

[jaybosamiya-ms]

This PR improves LiteBox performance by shaving off ~65% of our execution time by introducing opportunistic CoW:

 _____
< MOO >
 -----
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Concretely, this PR introduces a new platform interface to PageManagementProvider called try_allocate_cow_pages. This defaults to UnsupportedByPlatform, but any platform that has the ability to support copy-on-write page allocation can override this method in order to automatically obtain improved performance.

The improved performance itself comes from mmap in the Linux shim, where file-based mapping can be sped up.

This is not a trivial "pass through" since the files inside LiteBox need not correspond to files on the host (so even for Linux-on-Linux, there is work that must be done). This motivates the actual design of try_allocate_cow_pages that I've chosen, which is closer to a memcpy-like interface, rather than anything file-oriented. Platforms that have file-oriented support for it are welcome to keep those platform-specific details to themselves. What this means is that mmap on the shim actually first looks up the file, then it checks to get a backing store memory of it; if one exists, then a CoW is attempted, at which point the platform itself does the lookup of the file (on Linux platform) and decides to make a CoW map of the page.

Currently, the biggest gains for us come from the actual ELF load time, since that is all that I have set up as supporting CoW for now (it was our biggest bottleneck; thus the 65% savings in execution time). However, now that the core framework has been set up by this PR, future PRs should more easily be able to unlock performance wherever CoW might help.

There are some small bits I am not yet fully happy with the PR that I've marked with TODO(jb) etc., for example, it'd be good to store pre-loaded FDs rather than constantly opening/closing them. However, that can/will be handled in a future PR.

[github-actions]

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.

[wdcui]

I think @CvvT should review this PR.

[CvvT]

Thanks for the change! I have a few questions.

[CvvT]

Do we need to consider files in the tar file?

[jaybosamiya-ms]

The tar files don't actually easily support the type of mapping we want, so more work needs to be done there; I have explicitly left this to a future PR, since it is almost an orthogonal change to the key changes in this PR (and also needs further design effort).

[CvvT]

Why not check NoReplace? The flag is controlled by user?

[jaybosamiya-ms]

I'd left in this TODO for some reason, I don't fully recall what the particular constraint here was, I'll look at it again shortly, thanks for pointing it out!

[CvvT]

Potential race issue? Should we call try_allocate_cow_pages and register_existing_mapping in a single function that takes lock on PageManager::vmem so that other page allocation calls won't content on the same address?

[jaybosamiya-ms]

Hmm, I think you are correct in terms of technically there is the possibility of a race but I am struggling to think of a scenario where it can be relevant. As I understand it, it is only really relevant if two different threads try to race to set the fixed address with replacement, because otherwise the underlying host access will just either pick a diff address for us (if non-fixed) or will reject it (if non-replacing). And if a program is trying to race with replacement, then the program anyways will register the same mapping, right?

I will need to give a bit more thought on how to expose the relevant lock here, possibly some type of begin-attempt-commit type thing.

Thanks for noticing this!