Leak with per thread debug info?
Doug Simon
doug.simon at oracle.com
Wed Jun 25 18:44:48 UTC 2014
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
>
More information about the graal-dev
mailing list