New Solution for memory leak in tblgen

[David Blaikie]

On Mon, Nov 10, 2014 at 11:36 PM, wuhui1973 <wuhui1973 at 163.com> wrote:

> Hope I can explain it clear enough :-)
>
> > MemReclaimer has two containers to hold pointers of TreePatternNode &
> TreePattern which are allocated from heap.
> > Only one global instance of MemReclaimer  is declared -- memReclaimer.
> > operator new & operator delete are defined for TreePatternNode &
> TreePattern
>           new:    push the new allocated object (pointer) into containers
> in memReclaimer.
>           delete: remove the pointer from the containers in memReclaimer.
>
>           So we can guarantee that objects allocated from heap can always
> be recorded by memReclaimer.
>           And no double free may incur, as some places in the source
> delete some pointers manually (maybe we can remove these lines).
> > So memReclaimer only keeps the objects that are leaked in current design.
> > the author of CodeGenDAGPattern  create nodes, but destroy part of them
> (for TreePattern, the nodes destroyed manually account for more than 30%,
>

Could you provide stack traces/explanation for these case where the
TreePatterns are destroyed?


>           for some target even over 50%; while for TreePatternNode  only
> around 1%
>

And for the TreePatternNodes?

If they're mostly just on special case construction paths, perhaps we could
special case their removal from the list we could add to CodeGenDAGPattern
- or, if they're close enough to construction time, we might be able to
avoid adding them to such a list in the first place?


> ) and make the rest leaked deliberately.
> > dtor of CodeGenDAGPattern now is the place to destroy all not freed
> objects
> > move the functionality of MemReclaimer into CodeGenDAGPattern  is
> definitely feasible I think.
>

> Regards
> Hui Wu
>
>
> At 2014-11-11 14:20:25, "David Blaikie" <dblaikie at gmail.com> wrote:
>
> Could you describe the high level design here?
>
> It looks like there's a static pool (CodeGenDAGPatterns.cpp::memReclaimer)
> of instances that's used as some kind of last-chance cleanup? Instances of
> TreePatternNode mostly manage their own lifetime but then if any haven't
> been destroyed by the time the CodeGenDAGPatterns dtor runs, the remaining
> elements are destroyed. This is to handle cycles, I take it?
>
> It still seems like a bit of a GC-esque workaround to handle this case
> when there might be something better... but I don't know much about
> tablegen, perhaps there isn't.
>
> How often are nodes destroyed by themselves? Should we just give up owning
> these anywhere else & move all ownership into CodeGenDAGPatterns and clean
> them up in CodeGenDAGPatterns' dtor? (just have a vector of unique_ptrs
> (maybe even a list or deque of nodes directly owned, rather than via
> unique_ptr), only create nodes, never destroy them, then destroy them all
> at the end)
>
> On Mon, Nov 10, 2014 at 9:58 PM, wuhui1973 <wuhui1973 at 163.com> wrote:
>
>> Hi Andrew, David and Hal:
>>
>> I have made a new solution for this memory leak issue, which is much
>> simpler than previous one.
>>
>> I have tested it, it works well!
>>
>> Please have a look, and appreciate any comment.
>>
>> Thanks & Regards
>>
>> Hui Wu
>>
>>
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141111/98ba58a0/attachment.html>