<div dir="ltr"><div class="gmail_extra">What you say here is pretty scary ... before saying anything about this I think I will have a read in the source code.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
If somebody in the meantime has any extra information about this it would be useful :)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Marcello</div><div class="gmail_extra"><br><div class="gmail_quote">2014-06-24 17:17 GMT+01:00 Mathias Fröhlich <span dir="ltr"><<a href="mailto:Mathias.Froehlich@gmx.net" target="_blank">Mathias.Froehlich@gmx.net</a>></span>:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi,<br>
<div><br>
On Tuesday, June 24, 2014 15:18:51 Marcello Maggioni wrote:<br>
> I'm trying to develop a way to reliably clean the LLVMContext in order to<br>
> make it possible to use it multiple times.<br>
><br>
> LLVMContext itself is an almost empty object delegating almost all its<br>
> content to LLVMContextImpl.<br>
> This makes it very clean ideally, because clearing the LLVMContext would be<br>
> as easy as deleting the LLVMContextImpl and creating a new one.<br>
><br>
> The problem is that for some reason which I'm not aware of LLVMContextImpl<br>
> is actually exposed as a public pointer in the LLVMContext interface,making<br>
> it publicly available to objects that use it directly (this seems to happen<br>
> quite a lot in the codebase).<br>
><br>
> In LLVMContext the LLVMContextImpl is contained in a pImpl pointer that is<br>
> const (the pointer itself can't be changed) and I guess this is some kind<br>
> of protection against object replacing the LLVMContextImpl directly, which<br>
> stops us from just deleting it + getting a new one.<br>
> In addition to that, being pImpl public, there is no guarantee that objects<br>
> don't rely on pImpl remaining always the same pointer.<br>
><br>
> This makes it more difficult to clear LLVMContext.<br>
<br>
</div>I can't comment on your solution.<br>
But again the open source OpenGL driver stack is suffering from problems connected to<br>
LLVMContext.<br>
<br>
So our observation is, if we use several LLVMContexts within the program execution<br>
lifetime, LLVM accumulates memory that is only freed on destruction of the<br>
managed singletons. It turns out that in SDNode::getValueTypeList(EVT) the non simple<br>
value types are cached and keyed by a llvm::Type value which in the end refers to a<br>
LLVMContext reference value. Which in turn leads to the llvm library hogging memory<br>
in this EVT std::set for each new LLVMContext.<br>
For the OpenGL drivers using the global LLVMContext singleton leads to serious<br>
threadsafeness problems. One driver is just non OpenGL conformant<br>
non thread safe because of that, some others just tolerate LLVM hogging<br>
memory because of that. Even worse for the ones just tolerating hogging<br>
memory, I could potentially think of possible ABA like problems with a<br>
new LLVMContext or llvm::Type being malloced at the same address than a previous already deleted<br>
one but not knowing about the cached EVT's which appear to belong to this context.<br>
<br>
That said I think you need to be careful since some of the llvm static caches refer to<br>
LLVMContext pointers and at least the one I mentioned above is not cleared if either<br>
a whole LLVMContext is cleared nor it is cleared by what you want to achieve.<br>
<br>
Also for my interest:<br>
Does anybody know of other statically cached object instances that are tied to an<br>
LLVMContext but not cleaned up when the referring LLVMContext is destroyed?<br>
<br>
Greetings and thanks<br>
<span><font color="#888888"><br>
Mathias<br>
</font></span></blockquote></div><br></div></div>