This is an archive of the discontinued LLVM Phabricator instance.

[dsymutil] Reduce peak memory usage for the single threaded execution.
ClosedPublic

Authored by JDevlieghere on Sep 4 2018, 3:18 AM.

Details

Summary

Keeping the compile units in memory is expensive. For the single threaded case we allocate them in the analyze part and deallocate them again once we've finished cloning. This poses a problem in the single threaded case where we did all the analysis first followed by all the cloning. This meant we had all the link context in memory right after analyzing finished.

This patch changes the way we order work in the single threaded case. Instead of doing all the analysis and cloning in serial, we now interleave the two so we can deallocate the memory as soon as a file is processed. The result is binary identical and peak memory usage went down from 13.43GB to 5.73GB for a debug build of trunk clang.

Diff Detail

Event Timeline

JDevlieghere created this revision.Sep 4 2018, 3:18 AM

It would be good to document in the man page that -j >1 uses more memory.

llvm/tools/dsymutil/DwarfLinker.cpp
2486–2489

... so it is being run in parallel with emitting the previous compile unit.

2620

... analyze and clone are run sequentially, so the LinkContext may be freed.
where is this actually happening?

JDevlieghere marked 2 inline comments as done.
  • Address Adrian's feedback.
llvm/tools/dsymutil/DwarfLinker.cpp
2620

We clear the context in endDebugObject.

aprantl added inline comments.Sep 4 2018, 11:12 AM
llvm/tools/dsymutil/DwarfLinker.cpp
2620

The let's spell this out in the comment: ... analyze and clone are run sequentially, so the LinkContext is freed after processing each object in endDebugObject()..

Rephrase comment to Adrian's suggestion.

JDevlieghere marked 2 inline comments as done.Sep 5 2018, 2:40 AM
friss added inline comments.Sep 5 2018, 10:20 AM
llvm/tools/dsymutil/DwarfLinker.cpp
2554–2556

Is that just a reformatting? Can you remove it from the patch if so?

2620–2625

This loop doesn't have the LinkContext.Objectfile check which was in CloneLambda before and is in CloneAll. Would it be cleaner to pass a LinkContext to the lambdas and leave the logic there?

JDevlieghere marked 2 inline comments as done.Sep 5 2018, 11:04 AM
JDevlieghere added inline comments.
llvm/tools/dsymutil/DwarfLinker.cpp
2554–2556

This is the result of moving this code out of the loop and having one level less of indentation.

2620–2625

That check was moved into the AnalyzeLambda so it still happens, unless you're talking about something else?

friss added inline comments.Sep 5 2018, 2:30 PM
llvm/tools/dsymutil/DwarfLinker.cpp
2620–2625

Previously CloneLambda would return early if LinkContext.Objectfile was null. Now, in the single threaded case, it will process the object file. I'm not sure something bad can happen, but it's a logic change.

JDevlieghere marked 2 inline comments as done.

Move null-check into CloneLambda.

JDevlieghere marked 2 inline comments as done.Sep 6 2018, 1:06 AM
JDevlieghere added inline comments.
llvm/tools/dsymutil/DwarfLinker.cpp
2620–2625

Aha, I see, I moved it for analyzeLambda but not for the cloneLambda. Good catch, this would've segfaulted!

friss accepted this revision.Sep 6 2018, 9:23 AM

LGTM

This revision is now accepted and ready to land.Sep 6 2018, 9:23 AM
This revision was automatically updated to reflect the committed changes.
JDevlieghere marked an inline comment as done.