Details
- Reviewers
v.g.vassilev vsk
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Support/DynamicLibrary.cpp | ||
---|---|---|
72 | I'd expect all initializations of OpenedHandles to be unnecessary after your change. | |
lib/Support/Windows/DynamicLibrary.inc | ||
12 | @marsupial do you think it'd be a good idea to fix up the Windows version of OpenedHandles here, or would you rather do it in your patch? |
Believe it is fixed in my patch: allocating into a std::unique_ptr which should auto-destruct the contents on exit.
The ManagedStatic docs seems to talk about startup time, but I find it hard to believe that allocating space for a single pointer would be slower than the three it allocates plus other internals.
I'd prefer to use it in the patch I have as that addresses a more severe problem and this causes conflict resolution on my end.
It's not only about the space the unique_ptr would occupy -- startup times are impacted by global constructors. The advantage of ManagedStatic is that you don't pay the construction cost until you need to.
I'd prefer to use it in the patch I have as that addresses a more severe problem and this causes conflict resolution on my end.
Ok, well it sounds like you'd like to take care of it, so this patch will lgtm once the OpenedHandles initialization issues are fixed.
I get what ManagedStatic is supposed to be doing, but versus using a std::unique_ptr the cost seems more with it (both in terms of size and startup time).
But I guess that conversation would add a bit of noise and doesn't have much to do with this patch.
I'm not so sure. First, the unique_ptr isn't very helpful, because it's destructor can't be called until the program terminates, at which point it just creates needless allocator traffic. Clang has -disable-free to work around this problem. This is why ManagedStatic allows compile servers to work: because llvm_shutdown() actually frees the memory held by ManagedStatics. Second, it looks like ManagedStatic has a trivial constructor, making it cheap in the case where you don't use this API.
But I guess that conversation would add a bit of noise and doesn't have much to do with this patch.
I suppose so, its use here won't be changed.
I'd expect all initializations of OpenedHandles to be unnecessary after your change.