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: | OutOfMemoryError: Java heap space | ||
|---|---|---|---|
| Product: | platform | Reporter: | Jesse Glick <jglick> |
| Component: | Filesystems | Assignee: | Jaroslav Havlin <jhavlin> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | Bazilio, deff, julianolandim, leewilson86 |
| Priority: | P3 | ||
| Version: | 7.4 | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | 204372 |
| Attachments: | stacktrace | ||
|
Description
Jesse Glick
2013-10-04 16:49:16 UTC
Created attachment 140811 [details]
stacktrace
From the exception ... there is nothing we can do about it ;( Size of the queue org.openide.filesystems.FCLSUpport.q is over 19 millions (!). This huge size caused the OOME. The thread dump shows that "Async FileEvent dispatcher" thread responsible for removing items from the queue is blocked. This can explain why the size of the queue is so huge. It should be investigated, why "Async FileEvent dispatcher" thread is blocked and if there is a way not to block it for a long period of time. Reassigning to filesystems for further investigation. Jesse, what type of magic did you do? Is it possible that it caused 19 million file changes? (I guess it isn't.) If you were working with some open source project, can you please provide link to the repository? (I'm not able to reproduce the bug with Mercurial and NetBeans sources, size of FCLSUpport.q hardly reaches 1000 items). Thank you. This was several weeks ago so I cannot remember exactly what I was doing at the time (probably some git-mv operations, maybe git-checkout etc.), but from the log file it looks like I was working on Jenkins core, which is sort of big but not that big (currently ~11k files). I was able to reproduce the bug with the Jenkins Core sources. Shortly after invoking "git mv src src2", size of FCLSupport.q was 1.3 million items. The main problem was creation of DispatchEventWrapper for each pair of FileEvent and filesystem-level FileChangeListener. I created a DispatchEventWrapper that can hold a list of listeners instead of a single listener. The good thing is that a list of listeners can be shared by multiple wrappers. After this change, the size of the queue reached only 22,000 items (1.7% of the original size). Thank you, Jesse, for reporting and your comments, and Tomas for help with evaluation. http://hg.netbeans.org/core-main/rev/57d4ac5ab367 Integrated into 'main-silver', will be available in build *201311290002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/57d4ac5ab367 User: Jaroslav Havlin <jhavlin@netbeans.org> Log: #236773: Out of memory - Too many items in FCLSupport.q *** Bug 239299 has been marked as a duplicate of this bug. *** *** Bug 239541 has been marked as a duplicate of this bug. *** *** Bug 241051 has been marked as a duplicate of this bug. *** *** Bug 245387 has been marked as a duplicate of this bug. *** |