Joe Consumer <[EMAIL PROTECTED]>Joe Consumer wrote:
Christain,
Thanks for the info. THe problem seems to be that
OptimizeIt doesn't seem to show these objects being
GC'ed even at a slow pace.
The finalizer thread runs at a low priority
in the hot spot vm.
What is the fix?
Do not use AbstractDocument :-)
How do you patch AbstractDocument so
that it doesn't create all these AbstractElements?
You can't avoid creating the elements. But
you can avoid them to be finalized by removing
the finalize() method.
/**
* Finalizes an AbstractElement.
*/
// ## patched
// protected void finalize() throws Throwable {
// AttributeContext context = getAttributeContext();
// context.reclaim(attributes);
// }
My tests showed, that the memory impact of not
executing the finalizers is very low compared
to the objects hanging around.
You could still patch this because you could simply
implement the Document interface. Is it creating them
in createElement().
This means rewriting the complete javax.swing.text
package.
Why does it create them and then
all of a sudden ditch them?
May, the view creates a default document and the you set
another (your) document. The the default document is not
used anymore. Use a constructor which immediately sets your
document.
Shouldn't it create them
and hang onto them while the JTextArea is in use?
IMHO it does until the document changes. See scenario above
--
Christian Pesch - Product Maturity Manager
CoreMedia AG - http://www.coremedia.com - 0700-COREMEDIA
_______________________________________________
Advanced-swing mailing list
[EMAIL PROTECTED]
http://eos.dk/mailman/listinfo/advanced-swing
