Re: JTextArea is a memory hog!

[Christian Pesch]

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

Re: JTextArea is a memory hog!

[Christian Pesch]

Joe Consumer wrote:


I can't believe this exists in Swing, but I've found
that when I loaded a 2MB file into JTextArea it
creates literally 394,000+ java.lang.ref.Finalizer
objects that hang around event after the JTextArea is
released.  What's worse is my memory usage spikes to 
65MB!  That's 30 times the size of the text string!  I
don't know what java.lang.ref.Finalizer object is, or
why it gets created. 

Its an Object that encapsulates Objects, that
have to be finalized by the Finalizer thread.

A short grep shows 3 finalize() methods in the
swing text package:

cd /opt/jdk/src/javax/swing/text/
grep -n finalize *java /dev/null
AbstractDocument.java:1461: * would call this in its finalize method.
AbstractDocument.java:1567:protected void finalize() throws Throwable {
GapContent.java:264: protected void finalize() throws Throwable {
StringContent.java:324:protected void finalize() throws Throwable {
StyleContext.java:390: * references.  This would typically be called 
by the finalize method

grep finished (5 matches found) at Thu Jan  9 12:33:00

I have a feeling it's wrapped up in AbstractDocument
code
not being very effecient in it's object allocation,
but I don't know.



No, its a huge amount of AbstractElement
objects, that have to be finalized. And the
finalizer thread is not fast enough.

This hasn't changed since early Swing days,
although the JVM supports alternatives like
WeakReferences for ages.

Until WebStart, one could patch the classes
and remove the finalize() methods. That has
some legal implications if you distribute,
but customers do not care, if their product
runs. 

--
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