This is an archive of the discontinued LLVM Phabricator instance.

LLD: Implement our own future and use that for FileArchive::preload().
ClosedPublic

Authored by ruiu on Mar 2 2015, 7:45 PM.

Details

Summary

std::promise and std::future in old version of libstdc++ are buggy.
I think that's the reason why LLD tests were flaky on Ubuntu 13
buildbots until we disabled file preloading.

In this patch, I implemented very simple future and used that in
FileArchive. Compared to std::promise and std::future, it lacks
many features, but should suffice for our purpose.

Diff Detail

Event Timeline

ruiu updated this revision to Diff 21075.Mar 2 2015, 7:45 PM
ruiu retitled this revision from to LLD: Implement our own future and use that for FileArchive::preload()..
ruiu updated this object.
ruiu edited the test plan for this revision. (Show Details)
ruiu added a project: lld.
ruiu updated this object.
ruiu added a subscriber: Unknown Object (MLST).

Is there a reason not to implement essentially the exact future/promise API from the standard in the 'llvm' namespace? We do this in ADT or Support for a lot of things that we'd like from the standard library but can't rely on (yet).

Maybe it makes more sense to start smaller here, but then I wonder if it would be useful to make the APIs at least be a subset to ease migration in the future? (ba-dum!)

Not a big deal either way, just a thought.

ruiu added a comment.Mar 2 2015, 8:17 PM

The reason why I didn't implement complete future and promise as specified in C++11 is because the amount of effort that would require. I implemented a future just in 30 lines here. On the other hand a complete implementation probably require 200+ lines. This is the only place we use future, so I thought that it just doesn't pay.

If we are going to use future in many places in LLVM projects, it worth implementing a "real" one. But I imagine it's unlikely -- the linker is probably exceptional in the sense that it gains a lot from multi-threading. If we are going to see more uses of future in LLVM, maybe we should think about that.

ruiu added a comment.Mar 2 2015, 8:20 PM

Oh, and speaking of the API, I don't actually understand why C++11 separates producer side (std::promise) and consumer side (std::future). My implementation is not compatible with that at all -- I just defined std::future and use that for both, just like future in java.util.concurrent. Seems working fine -- so I didn't go so far as to define one more class.

shankarke added inline comments.
include/lld/Core/Parallel.h
77

there is only one usage of Future with lld::File, Why do we want to make this a template ?

lib/ReaderWriter/FileArchive.cpp
63–69

The _preloaded map could get resized here ? Can we resize the map in advance since we know how many members are in the archive ?

261–262

looks like/most of the members are mutable, I think this needs to be made non-const.

269

llvm::DenseMap ?

This revision is now accepted and ready to land.Mar 3 2015, 1:41 PM
Eugene.Zelenko added a subscriber: Eugene.Zelenko.

Committed in r231153.