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.
ParsingSupport posts its parsing requests into default (multithreaded, limit of 50 concurent threads) RequestProcessor, which causes parallel parsing and allocation of big number of threads during opening Java files. (e.g. during startup) Steps to reproduce: Select several java files and open them at once. After few seconds do a thread dump and watch for Inactive RP's (which reveal their last client in the thread name). Possible fix: AFAIK the parser is singlethreaded anyway, so create a private instance of single threaded RP and post the requests into it instead of RP.getDefault
ParsingSupport posts parsing requests not into the default RP but into own RP "Java source parsing". That RP is single threaded so I do not think here is the problem. Flood of threads seems to be created by the event model. Each parser event notification is scheduled into the default RP. So I will introduce new RP "Java Parser Event Queue" handling these events.
fixed in /cvs/java/src/org/netbeans/modules/java/parser/ParsingSupport.java,v1.41
There are one or two Inactive RP threads of ParsingSupport a few seconds after opening files. All of them are removed after GC. Is this right behaviour?
This is right. They are private to java (i.e. they are not annotated as 'Default RP') and they are single-threaded, so no thread flooding and parallel parsing occurs. Verifying.