Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 124715 - Memory leak in java caret listening factory
Memory leak in java caret listening factory
Status: RESOLVED DUPLICATE of bug 100753
Product: java
Classification: Unclassified
Component: Navigation
All All
: P2 (vote)
: 6.x
Assigned To: _ sandipchitale
Depends on:
Blocks: 121855
  Show dependency treegraph
Reported: 2008-01-04 15:13 UTC by Jaroslav Tulach
Modified: 2008-01-08 15:00 UTC (History)
0 users

See Also:
Issue Type: DEFECT


Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2008-01-04 15:13:39 UTC
After running test described in issue 121855 one gets following leak:

private static>>
Comment 1 Jan Lahoda 2008-01-04 15:54:38 UTC
The principal problem here is (I think) that the tasks are not unregistered from the very last JavaSource instance,
which is because the event about closing the very last file never comes: issue #100753 (I have copied the metainfo from
this issue into that issue). It is a bit surprising that this is the only dump about factories that we have (all
factories should be suffering from the same problem) - is only the shortest path from all "similar" paths considered?

Another problem is that the CaretListeningFactory holds reference to itself as a static field, which would prevent GC
for this class when a module is unloaded, but I do not think this is a huge problem.
Comment 2 Jan Lahoda 2008-01-04 16:29:10 UTC
Please disregard the part about unloading - the class (and the instance) can be generally unloaded in such a scenario.
Sorry for confusion.

*** This issue has been marked as a duplicate of 100753 ***
Comment 3 Jaroslav Tulach 2008-01-08 07:57:42 UTC
Re: "similar" - yes, only disjunctive leaks are reported.

I am not sure why you cannot fix this in CaretListeningFactory.file2JS by pointing to JavaSource using weak 

I disagree about the priority. We need issue 121855 pass, otherwise we cannot enable memory leak tests in commit 
validation. We either need this one to be fixed or you need to tell us a workaround to prevent it.

Also I am not sure why this is considered duplicate of issue 100753. The reference chain is completely different.
Comment 4 Jan Lahoda 2008-01-08 14:46:30 UTC
Please note that issue #100753 is a P2. I never said this shouldn't be fixed (did I). Workaround should be to open any
editor (plain text is enough).

Why I think this is a duplicate: CaretListeningFactory (and many other JavaSourceTaskFactories) listen on EditorRegistry
(through OpenedEditors class in java/source module). When a visible component is changed, it unregisters tasks from the
previous component (if any) and registers them to the new component. The problem is that there is no (reasonable) way to
recognize that the last component was closed from the EditorRegistry, so the factories never unregister the tasks from
the very last component. While it might be possible (although probably very difficult) to modify OpenedEditors to handle
such situation, it seems more appropriate to me to make more or less the same fix into the EditorRegistry for benefit of
all users of EditorRegistry (like HintsUI and others).
Comment 5 Jan Lahoda 2008-01-08 15:00:05 UTC
I do not think that making the reference to JS weak is a good solution:
-from API point of view, no client is required to hold the JavaSource instance for the currently opened editor - the
factories do currently this (from the API point of view). While a file is opened in the editor, having only one instance
of JavaSource is good: it does some caching and it listens on the document. If a JavaSource for the document would
disappear, noone would listen on the document and the file wouldn't be reparsed on next change.
-currently, the JavaSource itself holds JavaSource instances that have attached tasks, so making JS weak does not ensure
that the JavaSource instance is freed (this is an impl. detail, I think).

Sorry, but I still think that making the EditorRegistry fire a reasonable event when the very last component is closed
would be the most correct solution.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo