[PATCH] D27295: Remove existing file in a separate thread asynchronously.

Sean Silva via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 30 23:55:24 PST 2016


silvas added reviewers: joerg, emaste.
silvas added a comment.

Why are we unlinking at all? Hopefully we can just resize the file and ideally reuse most of the pages the kernel already has allocated. Doing so loses the atomicity of the replacement, but so does asynchronously unlinking like you do in this patch (although this patch would manifest the non-atomicity in a more benign way).

If we slightly overallocate the file (no problem since ELF doesn't mind having some extra zeros at the end), then most of the time re-links will avoid doing any kind of memory allocation from the kernel whatsoever. (edit-relink cycle may cause more or less bytes due to local code modifications from the edits, but the changes are unlikely to be very large).

I'm not sure if users expect atomic replacement of the destination file as the behavior from the linker. If they do, then there's not much we can do to speed this up unfortunately. Joerg, Ed? Any ideas on whether we need atomic replacement?


https://reviews.llvm.org/D27295





More information about the llvm-commits mailing list