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.

Bug 71932 - Huge memory consumption when switching between NB platform files
Summary: Huge memory consumption when switching between NB platform files
Status: RESOLVED DUPLICATE of bug 71931
Alias: None
Product: apisupport
Classification: Unclassified
Component: Project (show other bugs)
Version: 5.x
Hardware: All Linux
: P3 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2006-01-27 14:15 UTC by _ rkubacki
Modified: 2006-02-01 20:20 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description _ rkubacki 2006-01-27 14:15:17 UTC 
According to Vladimir Sizikov:

I've verified that with stock NB 5.0RC2, with java5 and java6, I see
the same behavior.

Here are the steps to reporduce:

1. Download NB 5.0RC2, install it into /opt/netbeans
1a.Update netbeans.conf to provide more memory:
    "-J-Xms256m -J-Xmx512m -J-Xverify:none"
2. Download NB 5.0RC2 sources, unpack into /opt/netbeans-src
3. Start NB, create a sample NB plugin project (just a simple action
   would do).
4. Attach NB sources in NB platform manager.
5. Restart (without restart, the newly attached NB classes are not
   available)
6. Open ExtKit.java and NbEditorUI.java via Alt-Shit-O.
7. Ctrl-Tab, Ctrl-Tab, ....
8. Sit back, relax, and watch that every Ctlr-Tab eats up to 50MB of
heap.

Eventually entire heap is consumed and GC resets it back to 50MB or
so, and you're ready for the next round.
------<<<<

50MB to switch the editor tabs are too much. I am not sure if this is the same
as issue #71931 but I think that there should be compiled version of NB platform
usualy so the parsing should not be so expensive. Or do the source version of
files take precendence for some reason?
Comment 1 Jesse Glick 2006-02-01 20:20:42 UTC 
Same issue. If your NB sources are not compiled (which would I guess be the
workaround), probably the background parser tries to compile them each time. Not
sure there's much to be done from apisupport's side. It does report sources
corresponding to the JARs in the platform, of course (else Alt-Shift-O would not
work), but it cannot report those JARs as part of the EXECUTE classpath for the
sources since it doesn't "own" the source tree and the nb.org projects in the
source tree already report their own classpaths according to the nb.org build
structure. javacore could in principle record that the sources were found due to
SFBQ on the platform JARs and use those to run the internal compiler against, if
the timestamps worked out.

*** This issue has been marked as a duplicate of 71931 ***