[Openmp-commits] [PATCH] D81054: [OpenMP] Introduce target memory manager

[Manoel Roemmer via Phabricator via Openmp-commits]

manorom added inline comments.


================
Comment at: openmp/libomptarget/src/MemoryManager.cpp:88
+
+MemoryManagerTy::~MemoryManagerTy() {
+  // TODO: There is a little issue that target plugin is destroyed before this
----------------
protze.joachim wrote:
> protze.joachim wrote:
> > JonChesterfield wrote:
> > > This "little issue" of calling into the target plugin after it has been destroyed is a contender for this patch not working on amdgpu.
> > > 
> > > I still think the target plugin, if it wishes to use this allocator, should hold the state itself. That means the allocator can be used internally, e.g. for call frames or the parallel region malloc, as well making destruction order straightforward and correct.
> > @tianshilei1992 Any plan to fix this? 
> > This does not only break for AMD, but also for a plugin our group is working on.
> > 
> > Without understanding all the details, I think, the destructor of DeviceTy should delete the MemoryManager?
> > Would this solve the issue? I.e. is the DeviceTy destroyed before the target plugin is unloaded?
> Nevermind, the unique_ptr should take care of the release. So, why is the device not destroyed before the plugin is unloaded?
> Nevermind, the unique_ptr should take care of the release. So, why is the device not destroyed before the plugin is unloaded?

Hope I'm not too late to the party, but:

* If I tracked this down correctly, plugins don't really get unloaded explicitly but only when the host program terminates and the program and its libraries get unloaded by OS. 
* Plugins keep ther state in global objects so their destructor is called when the plugin library is unloaded (at least thats when the VE plugin cleans up its resources, including its target memory).
* The MemoryManager is (ultimately) owned by the PluginManger which gets constructed explicitly by `__attribute__((constructor))` and `__attribute__((destructor))` functions in `rtl.cpp`

So what I guess happens is, that the host program terminates, and then all global destructors are exeuted including those in libomptarget and the plugin libraries (before any library actually unloads). And the destructor which is called first happens to be the destrutor for the plugin library and the destructor function which deletes the PluginManger gets called later.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81054/new/

https://reviews.llvm.org/D81054