Leak with per thread debug info?

[Caspole, Eric]

We are not blocked on this. We have been cosidering about whether to have a compile queue and compiler threads model for the offload because we have hit several of those "not enough profiling data" type problems in the last month or so. I knew we already had a leak in the Sumatra JDK part, and when I went to work on that I discovered this one. But it is not a problem for the time being.
Eric

________________________________________
From: Doug Simon [doug.simon at oracle.com]
Sent: Wednesday, June 25, 2014 2:44 PM
To: Caspole, Eric
Cc: graal-dev at openjdk.java.net
Subject: Re: Leak with per thread debug info?

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
>