Created attachment 7501 [details]
Graph of used memory

Besides the graph which is nice but almost useless :-) is it possible
that you would provide e.g. the output from hat about the counts of
objects with most of the instances?

Weel, I cannot provide your asked output, because I haven't it. We are
only looking for possible memory leaks - measn measure used memory and
trace increasing/decreasing memory footprint.

I have finished new measurement :
- opening Java file (ColorPreviewbeanInfo-2810B) : 100 iterations used
memory increased more than 500kB - means 1 opening Java file leak 5kB
memory

- opening Txt file (README-144B) : 100 iterations used memory
increased more than 400kB - means 1 opening Java file leak 4kB memory

Changing TASK -> DEFECT.

Please start to resolve performance issues, use some profiler tool on
looking for leaks, for more inforamtion call performance team.

If nobody objects I'll trace it down.

Marian, could you please attach your test?

I guess that NbEditorUI:278 is never deregistered. There are tons of
NbEditorUI.SystemActionUpdaters registered in TopComponent.Registry (a
pernament object).

Mila could you have a look, please?

Mato is right. NbEditorUI does not cause it.

I was confused by the fact that it in its contructor registers 3
listeners at TopComponent.Registry (my test counted them and I wrongly
assumed one listener per one editor).

So I'm going to trace it down once again...

Tried with disabled editor module and found a suspicious  
reference to DataEditorSupport$EnvListener. After opening a  
text file object and then closing it and closing explorer  
tree then there is suspicious reference subpath:  
  
GC root -> ..... ->  
org.netbeans.core.windows.WindowManagerImpl.updater  
(org.netbeans.core.windows.WindowManagerImpl)  
org.netbeans.core.windows.layers.WindowManagerData$InstanceCookieImpl.childrenCookies  
(org.netbeans.core.windows.layers.ICFolderImpl)  
org.netbeans.core.windows.layers.WorkspaceData$InstanceCookieImpl.childrenCookies  
(org.netbeans.core.windows.layers.ICFolderImpl)  
org.netbeans.core.windows.layers.ModeData$CookiesImpl.inst  
(org.netbeans.core.windows.layers.ICFolderImpl)  
org.netbeans.core.windows.ModeImpl.areas  
(org.netbeans.core.windows.ModeImpl)  
java.util.HashMap.table (java.util.HashMap)  
java.util.HashMap$Entry.value (java.util.HashMap.Entry)  
org.netbeans.core.windows.frames.TCCTabbedAreaImpl.selected  
(org.netbeans.core.windows.frames.TCCTabbedAreaImpl)  
org.openide.text.CloneableEditor.manager  
(org.openide.windows.TopComponent)  
org.netbeans.core.windows.WindowManagerImpl$TopComponentManager.nodes  
(org.netbeans.core.windows.WindowManagerImpl.TopComponentManager)  
org.netbeans.modules.text.TXTDataObject$TXTNode.obj  
(org.openide.loaders.DataNode)  
-> ... -> DataEditorSupport$EnvListener  
  
Field ModeImpl.areas is a map that seems to hold references 
to already closed TCs.  

.. at least in MDI mode. 

Petr, do you think this can cause the problem with *multiple* files
opening? I.e. new objects are created with each open and not freed...
I think closed TopComponents are not the case (at least not visible in
memory profiler).

According to my quick investigation (which might be not complete)
using memory profiler, the memory leaks appearing here are all related
to multiple registration of the same listeners - they are not created
newly but exist all the time, just added again and again on various
places. There seem to be no other "reasonable" objects growing in
population. So all the leaked memory seems to be used just in storing
the listeners in lists, or in wrapper classes, like WeakListener or
AWTEventMulticaster. See issue 28256 for an example, more will come.
Also issue 4768127 was filed on JDK/swing (ToolTipManager causes the
leaking AWTEventMulticaster).

Real seriousness of this particular case is IMO lower, as this is an
artificial test case, users would hardly open one files 1000 times.
But generally, the accumulating listeners could be the cause of the
gradual slowing of the IDE often complained about.

Created three more issues: 28270, 28271, 28272.

The leaking object seems to be NbEditorDocument. How to easily
reproduce it:

Open text file and invoke editor context menu. Leak appears after the 

JMenuItem item =((Presenter.Popup)action).getPopupPresenter();
in NbEditorKit.NbBuildPopupMenuAction.addAction method

CCing Petr for further investigation

See also issue 28662 - opening textfile of 27MB. I was able to open
that large file in NB editor. It takes some time, but the file opened
at the end. The problem is that after closing of file the memory was
not released. Opening file second time causes OutOfMemory. Once you
fix this issue, please test it with some very large document.

Should be fixed by fixing issue 30682

verified in NB 3.6

By using slightly modified test from Petr Kuzel, I'm still able to
reproduce moderate memory leak (~700 bytes per opening).
I'll attach test sources and more details.

Created attachment 14061 [details]
Testing app.

There are several leaked objects, mostly cleared WeakReferences
(~17 per open/close cycle) and Integers
Some WRs and Integers come from org.netbeans.editor.Registry:
docRefs and docAct.
But most of junk WRs are in editor's impl of WeakListenerList
and WeakProperyChangeSupport.

All these classes implement some way of on-demand cleanup,
but the cleanup triggers seem to be badly chosen (e.g. most users
never change editor settings during runtime, this is why so many junk
WRs are attached to Settings).

Moreover, after my experiments and findings, I tried to provoke
cleaning by setting someting in settings. It took about a minute to
first time toggle a boolean...

I'll keem the insane heap dump, so more info on demand.

I remember in my experimentation w/ AspectJ long time ago I saw a lot
of  PropertyChangeListeners attached to settings.  May be the same case

Although IMHO non-significant (1500 openings to leak 1MB is non-usual
even assuming debugging sessions etc.) we should be able to fix this
into promoD.

Milo, do you think you'll fix this in promo-D? Thanks.

Not sure maybe not. I've changed the milestone to future for sure.

See issue 48224 for much bigger memory leak. Maybe after that issue is
fixed, this one will obsolete.

Leaking mentioned in issue #48224 started since 27.08.2004, so I
believe it has no connection with this issue.

I guess it is better to file new bugs like #87433 rather than reopening this old
one. This was working and there are new bugs in this area.

v/c