This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Too many "Active Reference Queue Daemon" threads | ||
|---|---|---|---|
| Product: | platform | Reporter: | Jan Lahoda <jlahoda> |
| Component: | Filesystems | Assignee: | Jaroslav Havlin <jhavlin> |
| Status: | REOPENED --- | ||
| Severity: | normal | CC: | anebuzelsky, jtulach, thurka, tzezula |
| Priority: | P3 | ||
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | 245732 | ||
| Bug Blocks: | 86625 | ||
| Attachments: |
Thread dump.
thread dump with "Active Reference Queue Daemon" threads messages.log Quick and ugly fix |
||
I did some deadcode cleanup in core-main#15b6f8ac6c4a, but I am not sure how could the ~50 threads be created. Anyway the ping() and related code is provided by Jesse, so passing on. > related code is provided by Jesse, so passing on.
so reassigning to Jesse
I see only one such thread in my IDE. Any idea how to reproduce? -J-Dorg.openide.util.lookup.implspi.ActiveQueue.level=0 show anything interesting? I can't find any flaw in the logic from looking at it. No more info. Problem is caused by annotation processors, which are loaded by separate classloaders. Steps to reproduce: 1) start IDE with clean userdir and -J-Xmx2G 2) naviage to netbeans repository and open all top-level projects 3) wait for background scanning 4) take thread-dump Created attachment 155354 [details]
thread dump with "Active Reference Queue Daemon" threads
Created attachment 155355 [details]
messages.log
messages.log showing, who is loading ActiveQueue class.
Created attachment 155364 [details]
Quick and ugly fix
Attached is a ugly fix which always loads ActiveQueue via system classloader. It looks like that this patch works fine and there is only one
"Active Reference Queue Daemon" thread. In addition all org.netbeans.modules.java.source.parsing.CachingArchiveClassLoader instances are garbage-collected after the scanning is done.
Idea: If the only problem is org.netbeans.modules.openide.filesystems.declmime.MIMEResolverProcessor.generateInstanceResolver, it could tell the Impl not to attach any listeners at all. They are in the same package, so presumably it wouldn't even require an API change. Re. ugly fix: It's not that ugly. The activeReferenceQueue functionality would behave best if placed directly in the JDK's ReferenceQueue. If we don't have a capacity to make that happen (and I don't), always reusing our global activeReferenceQueue (if available) is the closest we can get. We tried with Tomas Hurka not to add the listener in MimeResolverImpl, unfortunately the ARQ is started later anyway. In an offline discussion TomasZ mentioned an option of dividing MIMEResolverImpl into two parts - (1) a model without listening, (2) listening on layers. However we do not have an easy quick solution for 8.1. Reassigning for future follow-up. |
Created attachment 97379 [details] Thread dump. See attached thread dump (not a full thread dump, as the top part did not fit into my scrollback). There are 51 util.lookup.implspi.ActiveQueue threads, although there should be only one, AFAIK.