This is an archive of the discontinued LLVM Phabricator instance.

[lldb][NFCI] Change type of UnwindPlan::m_source_name
AcceptedPublic

Authored by bulbazord on Jul 7 2023, 10:00 PM.

Details

Summary

m_source_name is currently a ConstString. Comparing the source names are
not a performance-critical operation, so that portion isn't really
necessary. It may benefit from deduplication (since there are only
a handful of possible values) but this means they will stick around
forever in the StringPool, even if they are never used again. As such, I
think it would be reasonable to change its type to std::string
instead.

Diff Detail

Event Timeline

bulbazord created this revision.Jul 7 2023, 10:00 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 7 2023, 10:00 PM
bulbazord requested review of this revision.Jul 7 2023, 10:00 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 7 2023, 10:00 PM
jasonmolenda accepted this revision.Jul 10 2023, 4:52 PM

I'm fine with this. It does increase the size of the UnwindPlan object, and there are a couple of them for every function that we see on a stack during a program execution, but I believe that won't be more than a few hundred. These are short strings so they won't expand to use heap, they will fit inline. Strictly I think it is more memory efficient to leave these half-dozen strings in the constant string pool than to have an extra 24 bytes in each UnwindPlan with them duplicated, but it's not enough memory use for me to be actually worried about it.

This revision is now accepted and ready to land.Jul 10 2023, 4:52 PM

(to say it more clearly: I'm fine if you'd like to reduce the places where ConstStrings are being used, but I don't think there's any good reason to remove this use of them. It will increase our memory footprint a bit.)

probably the real correct change is to have constant c-strings in as globals and have pointers to those. Then you're using the same space as a ConstString in each UnwindPlan (a pointer) but creation is cheaper. There's no dynamic aspect to the names when the UnwindPlans are created, each method creating them knows what the name will be.

I guess simplest is we can have all the UnwindPlan creators have a static g_unwindplan_name and save a pointer to that. Each one is unique, don't need anything fancier than that. There's the risk that someone will create a new UnwindPlan and forget to make it a static string, so unwind logging would try to print random memory, but it wouldn't break normal debugging.

I guess simplest is we can have all the UnwindPlan creators have a static g_unwindplan_name and save a pointer to that. Each one is unique, don't need anything fancier than that. There's the risk that someone will create a new UnwindPlan and forget to make it a static string, so unwind logging would try to print random memory, but it wouldn't break normal debugging.

I was thinking about this earlier, since we know what all the possible strings are going to be, we can create them all statically at compile time and just point to them. We can refactor a bit and then most of these source names just become static const char * or static constexpr llvm::StringLiteral or something like this.