Leak with per thread debug info?

[Doug Simon]

This is by design so that we get the debug info for all threads (of interest) during a VM execution, not just those alive when the VM is shutting down. Usually there is a bounded number of threads created DebugScopes (e.g. compiler threads) so this is ok. HSA deviates from this model whereby compilation is done in the same application thread triggering a HSA compilation. Is this causing out-of-memory errors in your case? I guess we could investigate the possibility for allowing a thread to remove its top level map when it is about to die...

-Doug

On Jun 25, 2014, at 8:09 PM, Caspole, Eric <Eric.Caspole at amd.com> wrote:

> I think I found a leak with the DebugValueMaps. I wrote a test where it was creating HSA kernels on short lived threads continuously. It ends up adding a new
> 
>    public static synchronized void registerTopLevel(DebugValueMap map) {
>        topLevelMaps.add(map);
>    }
> 
> from here:
> 
>    public static DebugScope getInstance() {
>        DebugScope result = instanceTL.get();
>        if (result == null) {
>            DebugScope topLevelDebugScope = new DebugScope(Thread.currentThread().getName(), "", null, false);
>            instanceTL.set(topLevelDebugScope);
>            DebugValueMap.registerTopLevel(topLevelDebugScope.getValueMap());
>            return topLevelDebugScope;
> 
> but since my threads are short lived this ends up being a leak in the topLevelMaps. I see this in Eclipse MAT from a heap dump.
> Let me know what you think,
> Thanks,
> Eric
>