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 Dev (Build 201010300000) Operating System = Linux version 2.6.35-22-generic running on amd64 Java; VM; Vendor = 1.6.0_22 Runtime = Java HotSpot(TM) 64-Bit Server VM 17.1-b03 I got messy 3000 lines long HTML file needed to be formatted and correct problems. I can work for around 15 minutes. Entire allowed memory is used, IDE becomes slow and eventually crash.
Created attachment 102728 [details] snapshot
Created attachment 102729 [details] message log
Looks like out of memory problem, everything runs extremely slow, nothing suspicious in the snapshot. Would you mind attaching the file to the issue or send it directly to me? Thanks
I've received the problematic file by email, it cannot be made public. I'm going to play with it a bit to see if the described problems happen.
There seem to be a serious memory leak in the org.netbeans.modules.parsing.impl.SourceCache class. Its field Map<Embedding,SourceCache> embeddingToCache indirectly holds all embedded parser results created during a Source object lifecycle. After taking several heapdumps in a row, editing a huge html file with many javascript and css embedded code and running GC between the dumps I realized that the number of embedded parser results for all embedded languages (JS and CSS) is increasing and these results are never GCed, since held by the SourceCache, at least until the file is opened. After several edits of the big file I ended up with +30MB of memory not being able to GC. Each parser results holds quite extensive chunk of objects, mainly the AST nodes and references to the tokens. Please address this issue ASAP since it really makes the IDE unusable for editing of bigger files with some embedded code. BTW, the old html parser results (for .html files) are GCed correctly, the problem happens only for the embedded parser results. There are several complains about the web editors performance which I believe are caused mainly by this issue. I consider this issue to be at least P2.
Not sure with the evaluation as the class has no relevant change for 1/2y.
Please attach (send) the file causing this issue. The embeddingToCache is cleaned by updateEmbeddings. >There are several complains about the web editors performance which I believe are caused mainly by this issue. Not sure as I have several snapshots where html parser takes order of minutes.
I've look into it. There is a memory leak but not so big as you describe. It's affected only by PM.parse(). This leak seems to be there from the beginning of parsing api. I am working on it.
Fixed jet-main 38bef69a6168 Anyway I doubt it the root case of slow HTML support (the mem leak was there from beginning).
Thanks for fixing Tome! As for the cause... sure, it is definitively not the only problem, but for big files with lots of js a css inside this used to be a real problem. After a while of editing you ended up with many parser results holding extensive trees of objects. I believe this particular problem with OOM is caused by this issue. I do not understand what's exactly ment by "It's affected only by PM.parse()".
>Not sure as I have several snapshots where html parser takes order of minutes. Just the parsing? Can you attach here the snapshots? I'm really curious...
I confirm that the memory leak in SourceCache is now fixed.
Thanks Marku
Integrated into 'main-golden', will be available in build *201011240001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/38bef69a6168 User: Tomas Zezula <tzezula@netbeans.org> Log: #191497:[70cat]IDE becomes slow when editing large HTML file
I was editing HTML used when reporting the bug for 20 minutes without a problem.
*** Bug 187008 has been marked as a duplicate of this bug. ***