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.
Product Version: NetBeans IDE 7.3 (Build 201302132200) Java: 1.7.0_21; Java HotSpot(TM) 64-Bit Server VM 23.21-b01 Runtime: Java(TM) SE Runtime Environment 1.7.0_21-b11 System: Windows 7 version 6.1 running on amd64; Cp1252; en_CA (nb) User directory: C:\Users\Gili\AppData\Roaming\NetBeans\7.3 Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\7.3 1. Generate code-coverage data by adding the following to a Maven project: <plugin> <groupId>org.jacoco</groupId> <artifactId>jacoco-maven-plugin</artifactId> <version>0.6.3-SNAPSHOT</version> <executions> <execution> <goals> <goal>prepare-agent</goal> </goals> </execution> <execution> <id>report</id> <phase>prepare-package</phase> <goals> <goal>report</goal> </goals> </execution> </executions> </plugin> 2. Right click on the project -> Code Coverage -> Show Report 3. Using -Xmx800m Netbeans will throw OutOfMemoryError. 4. Using -Xmx3g allows the report screen to come up but memory usage remains at 2.5gb and eventually runs out of memory. 5. It is worth noting my project is not huge, but it is commercial so I can't share the actual source-code. I suspect a huge memory leak is at play. I will attach a memory dump I generated for -Xmx400m. Please let me know if this is sufficient. Otherwise, I can upload a dump for -Xmx2g but the file will be considerably bigger...
The bug tracker won't let me upload the heap dump, so I've hosted it here instead: http://bbs.darktech.org/netbeans230250.zip (71MB) Please let me know when I can delete this off my server.
Created attachment 134888 [details] jacoco.xml The jacoco authors helped me figure out that my configuration was missing a <include> directive and so the code coverage report contained a large number of unrelated classes (classes belonging to dependencies of my project). 1. Maybe what's going on here isn't a memory leak but rather a performance problem. jacoco.xml is 60MB yet Netbeans uses over 2GB to process its contents. 2. I am asking Netbeans to display a report for com.foo.** (which is a tiny subset of all data) yet it seems to expand all structures into memory before searching for com.foo.**. If it only expanded data related to com.foo.** the loading process would use much less memory and would load much faster.
(In reply to comment #1) > The bug tracker won't let me upload the heap dump, so I've hosted it here > instead: http://bbs.darktech.org/netbeans230250.zip (71MB) Next time, you can use this page <http://deadlock.netbeans.org/hudson/job/upload/build?delay=0sec> to upload the heap dump.
I do not see any memory leak in the heap dump. com.sun.org.apache.xerces.internal.parsers.DOMParser#5 consumes 299M and this is probably caused by parsing huge XML file. Maybe the heap dump from run with Xmx 2G will help. Closing as invalid for now. If you can upload requested heap dump, please reopen.
Thomas, Can you please try loading the jacoco.xml which I uploaded? It should allow you to reproduce the issue on your end without us needing to exchange heap dumps. Just make sure to pass -Xmx2g to Netbeans. I agree that a 299MB DOMParser for a 60MB xml is okay. I just wonder why I'm getting OutOfMemoryError if I use a heap smaller than 2GB.
the user is warned about opening such a big xml file, so it should be done with caution. Nonetheless Svato can you please take a look whether something can be done about opening of BIG xml files?
On a side-note, I found Netbeans' warning message silly/unexpected. I don't understand why a 60MB is "big". As a user I expect Netbeans to consume *at most* 10x more memory than the file I am opening. So, warning users is one thing, but fixing what seems like unrealistic memory usage is another thing :)
Gili, 60MB of text file is a big file. How long will it take you to read it? The text editor is designed to help edit human readable files (source code or similar). I page in a book is roughly 10kb so you are talking about editing 6000 pages book here. There are some features that can consume a way more memory than you think. We were considering disabling these features (e.g. stop re-parsing the file) for big files. So we might have three levels of functionality: plain text without even simple colouring, lexer based features (simple coloring) and parser based features (code folds, code completion etc.). For the first category we should be able to open the file. You can try it yourself - just rename the file to jacoco.txt and try to open it in the editor. That should work - if not we have some serious bug somewhere.
David, I think the new subject line is misleading. I am not talking about the opening a 60MB XML file in the editor. I am talking about opening a code-coverage report based on a 60MB XML file. I expect opening a file in the editor to be far more expensive than parsing it to produce a report on a tiny subset of the data. In the latter case, you only need to keep a tiny subset of the information in memory.
Aha, I see. I thought we were talking about the editor here. We should re-assign the bug report to the code coverage module - any idea what category (and owner) should that be?
Not sure, actually. Worse-case scenario reassign to ide.