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.
While looking at the heap dump from bug #206074, we have seen a lot of JCCompilationUnits, which represent whole parsed files. This seems to be partially caused by org.netbeans.modules.websvc.rest.model.impl.Utils.checkForJsr311Bootstrap, which invokes Trees.getTree on a lot of Elements. As this call will try to find the source file and parse it, this is a quite expensive call and will keep the parsed tree in the memory until the current instance of javac is GCed. I would like to ask you to: -let checkForJsr311Bootstrap perform the cheapest tests first. In this case, all the checks in the second "if" seem cheaper to me than detecting whether there is a source for an Element. -using org.netbeans.api.java.source.SourceUtils.getFile instead of Trees.getTree should be much cheaper - at least in cases Trees.getTree would actually parse a source. Please try to use it if at all possible. (Although not even this method is really cheap - please call it as few times as possible.) Thanks.
web-main#46c1dec939f1
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/46c1dec939f1 User: Denis Anisimov <ads@netbeans.org> Log: Fix for BZ#206274 - org.netbeans.modules.websvc.rest.model.impl.Utils.checkForJsr311Bootstrap invokes Trees.getTree and some CDI analysis exension (warnings).
The patch in: websvc.restapi/src/org/netbeans/modules/websvc/rest/model/impl/Utils.java seem fine to me - should ensure that the sources are not parsed in the given context.
Verified in repository. http://hg.netbeans.org/releases/rev/36666d7c643e