Created attachment 19010 [details]
IDE Log file showing memory exceptions

The problem has gotten worse as the code has gotten bigger.  Now,
within 15 minutes, the editor and my whole system slows down and
within 30 minutes, I get the Out Of Memory exception.  After the first
use of the editor provided list of object methods etc, java.exe starts
using 99% of the CPU time.  This usage continues until and after the
Out Of Memory exception (often during a compile).  On one occasion,
the slow down was so severe that I couldn't even get the XP task
manager up and had to reboot the system (and lost the changes that I
had made).

Try to the latest Netbeans 4.0 RC (RC 2 available at the end of this
week), some improvements were integrated. If you encounetered a
problem again, feel free to reopen the issue and attach relevant
information (steps, ide log). Thanks!

Created attachment 19149 [details]
Log file showing Out Of Memory Error in 4.1EA1

The out of memory problem re-occurred on the next version  of
netbeans.  The problem of stalling the computer was not experienced,
but the Out Of Memory occurred within half an hour of start of editing
of the long program.

Can you be more specific what activity causes the problem? To identify
the source we would need to know what part should be responsible -
editing (what files?), execution, debugging and so on. You can turn on
memory toolbar to track current heap usage.

For a large project you can tune memory settings as described in 
http://performance.netbeans.org/howto/jvmswitches/index.html

Also what is your hardware and OS?

The operating system is Windows XP SP2.  I was editing a file - adding
code to the function ForceButton6ActionPerformed().  The file is about
4100 lines long.  The main project contains another small file and
refences another project that interfaces with a C++ DLL library.  The
code runs and tests successfully to the extent that it is completed. 
Running the code does not seem to cause the problem, it appears that
after a variable number of edits the system slows down and shortly
afterwords, if I don't exit, the Out Of Memory occurs.  I can make the
projects available for testing/debugging if requested. 

Do you use form (GUI) editor?

The project was built using the GUI editor, but I have not made
changes to the GUI for a while.  It created 196 swing objects and
InitComponents() is 2059 lines long.

The computer has a 1,024 MB of memory, available after XP 655.61 and
virtual memory of 2.0 GB.  Using a demo version of TaskInfo2003, I
find that only about 296,000 bytes of memory are used when the system
slows down but the number of 'handles' of 1,873 is much larger than
anything else on my computer and the CPU usage is over 97%.

I suggest you to increase the limit for Java heap with -Xmx option as
desribed in linked document. This will improve overal performance on
your system.

I am reassigning the bug to form editor for further evaluation. It is
not clear yet if it is scalability problem (4100 lines is acceptable
for our Java editor but form can add significant additional overhead)
or wherther it is a leak. 

I doubt it has anything to do with form editor (the reporter
hasn't modified the GUI for a while). The following symptoms
point to java module => reassigning for evaluation.

> After the first use of the editor provided list of object
> methods etc, java.exe starts using 99% of the CPU time.
> This usage continues until and after the Out Of Memory
> exception (often during a compile).

Could you please verify this with the latest 4.0 RC build (rc2)? The
4.1ea1 is almost as old as 4.0beta2 - there have been some significant
improvement made in the memory usage in the rc2. How many classes do
you have (approximately) in your project? How many other project do
you have open in the IDE? Do you run out of memory even if you
increase the max. heap size (using -Xmx setting)?

THe new version, netbeans-4.0rc2, seems to have fixed the problem.

It is not fixed. There is still leak. NB trunk build from Dec 8, JDK
5.0u1-b06 and with reporter's form it retains more than megabyte after
form open, editing of source, close. I do not know if I need to edit,
maybe it does not depend on this.

Does this happen when editing a plain Java? Or only with forms? Does
the memory grow with opening and closing the file repeatedly, or the
increased usage of memory is a one-time thing and can be caused by the
fact that more classes get loaded when opening a form or that 2 ASTs
get cached when a file is open?

I will attach some interesting traces showing various ways how the
data can be held and fill more bugs to track them separately. To
briefly comment them:

1) there is a thread keeping all top level windows to clear them on
shutdown held by TopThreadGroup, number of these windows is growing in
time and they keep some resources (including FormDesigner through
pallete). I need to investigate.

2) cell renderers holding the panel -> TC -> FormDesigner, this is
known issues of JDK that can be workarounded

3) org.netbeans.modules.editor.NbToolTip$Request listening to
org.netbeans.modules.debugger.projects.ToolTipAnnotation

4) FindDialogSupport in editor holding editor pane -> TC -> FormDesigner

5) org.netbeans.modules.form.FormLAF.ideDefaults hold another instance
of FormDesigner

Created attachment 19237 [details]
traces to FormDesigner from roots

It seems that none of these issues have anything to do with java
module. Which module should I reassign this to?

Reassigning back to form, since this has nothing to do with java
module and one of the reference traces points to FormLAF.ideDefaults
(note there is a separate issue filed for the editor leak related to
this).

I also have problems with out of memory error. Strange is, that memory
meter shows 100/178MB free.

Yes, one of the reference traces points to FormLAF.ideDefaults,
but this field is a Map that points to the same objects as UIManager's
defaults map. So, the question is how something
(NbToggleLineNumbersAction?) that holds a reference
to FormEditorSupport$JavaEditorTopComponent has been inserted
into this map. There are also other traces ending in the editor
module => reassigning to editor for evaluation.

Re Honza Becicka: it can be OK. OOME can be thrown under various
circumstances. The most often one is lack of space on Java heap.
Another possibility is full permanent area or problems with parallel
GC. If there was really only 100 of 178 used than it can be very
likely permarea. What platform do you run on? We can track this
problem (perhaps in a separate issue).

re Honza Stola: it is not editor problem. The form module deeply
copies the content of map. Form maintainers should justify this. Why
form needs to keep this data?

I'm using windows xp.

According to the last Radim's note reassigning back to form for
evaluation.

We will check the suspicious traces in form as soon as possible,
together with issue 52287. These issues should be resolved for 4.1.

FormDesigner is no longer held in memory after fix of issue 52286 =>
closing.

verified