<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 14, 2013 at 5:19 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> 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>
</div>But gold has at most 2 objects loaded at any time.<br></blockquote><div><br></div><div>The problem is not how many objects co-exist, the problem is how many copies of the type nodes we create.</div><div><br></div><div>
We will create a new copy of the type nodes each time we load in a source module, even though the type nodes exist in the destination module.</div><div>So if we have 700 source modules, assuming a type is shared across all 700 modules, the type nodes will be created 701 times.</div>
<div><br></div><div>Cheers,</div><div>Manman</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>