Displaying 3 results from an estimated 3 matches for "symbolstringpool".
2020 Oct 01
2
OrcV1 removal
...22B26: std::pair<llvm::StringMapIterator<std::atomic<unsigned long> >, bool> llvm::StringMap<std::atomic<unsigned long>, llvm::MallocAllocator>::try_emplace<int>(llvm::StringRef, int&&) (StringMap.h:322)
| | ->03.54% (97,812B) 0x831FD62: llvm::orc::SymbolStringPool::intern(llvm::StringRef) (SymbolStringPool.h:159)
| | ->03.54% (97,812B) 0x8320AF5: llvm::orc::ExecutionSession::intern(llvm::StringRef) (Core.h:1225)
| | ->03.53% (97,542B) 0x83EFBAE: llvm::orc::MangleAndInterner::operator()(llvm::StringRef) (Mangling.cpp:30)
| | | ->...
2020 Oct 02
2
OrcV1 removal
Hi Andres,
Ok -- I've added some API for this in 438db0719681: You can get the string
pool from the execution session
with LLVMOrcExecutionSessionGetSymbolStringPool, then clear that
with LLVMOrcSymbolStringPoolClearDeadEntries.
-- Lang.
On Thu, Oct 1, 2020 at 5:34 PM Lang Hames <lhames at gmail.com> wrote:
> Hi Andres,
>
> Oooh. I think I see. For various reasons the symbol names we generate
>> are unique over time. But the interned str...
2020 Oct 01
2
OrcV1 removal
Hi,
On 2020-09-30 21:31:33 -0700, Lang Hames wrote:
> I've taken a first shot at hooking RTDyldObjectLinkingLayer up to the
> ResourceTracker API in 7436b2ab2428. Could you let me know whether that
> fixes the leak you were seeing?
It did improve the situation significantly, thanks!
There's still a smaller leak, unfortunately. The function comments for
modules say that:
/**
*