<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 14, 2013 at 10:11 AM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>On Thu, Nov 14, 2013 at 5:19 AM, Rafael Espíndola<br>


<<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:<br>
>> Letting the module own MDNodes may not be a win for gold since it is going<br>
>> to create multiple copies of MDNodes that could be shared with Context<br>
>> owning MDNodes.<br>
>><br>
>> For example, with debug info type uniquing, the type nodes can be shared<br>
>> across modules, but with module owning MDNodes, each module will create its<br>
>> own copy of the type nodes. The advantage is that the MDNodes can be deleted<br>
>> easily by deleting the module. It is not clearly a win to me.<br>
><br>
> But gold has at most 2 objects loaded at any time.<br>
><br>
<br>
</div></div>Agreed. Dave and I were chatting about this some and from my<br>
perspective the only disadvantage to this is the time to copy metadata<br>
from one place to the other. Peak memory usage will still go down<br>
since you could then free up each module as you added. The "uniquing"<br>
works basically the same way as adding the same node 400 times to the<br>
folding set - it just returns the same one each time.<br></blockquote><div><br></div><div>Let's clear up a few things first, I believe Chandler was proposing moving the folding set from LLVMContext to Module.</div>
<div><div>The "uniquing" happens only within the module. It is not "just returning the same one each time", I would like to rephrase it as creating the same thing for each module.</div></div><div><br>
</div>
<div>With that proposal, we will have:</div><div>1> more MDNodes will be created.</div><div>     This can be a big issue because it means we are going to recreate the types for each module.</div><div>2> it is easier to free up the MDNodes, it happens when we delete the source modules.</div>
<div><br></div><div>My proposal earlier was to implement an interface to "garbage-collect" the MDNodes (and maybe other things  LLVMContext, as pointed out by Chris).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I guess I'm confused at where this 40% overhead of MDNodes is coming<br>
from though? Do we know what they are?<br></blockquote><div><br></div><div>The overhead is the MDNodes that are only used by the source modules. I gave a few examples earlier in another thread:</div><div><br></div><div><div>
<div style="font-family:arial,sans-serif;font-size:13px">There are a few cases where we generate MDNodes when linking modules:</div><div style="font-family:arial,sans-serif;font-size:13px">1> when a MDNode points to a value that is different from the source module such as Function*.</div>
<div style="font-family:arial,sans-serif;font-size:13px">2> when we have a cycle in the MDNode graph, all nodes in the cycle will be created for the destination module.</div></div></div><div><br></div><div>When the linked module generates different MDNodes, the MDNodes in the source module become garbage once the source module is deleted.</div>
<div><br></div><div>Cheers,</div><div>Manman</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<span><font color="#888888"><br>
-eric<br>
</font></span></blockquote></div><br></div></div>