Joe Consumer wrote:
I can't believe this exists in Swing, but I've foundIts an Object that encapsulates Objects, that
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.
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
No, its a huge amount of AbstractElementI have a feeling it's wrapped up in AbstractDocument code not being very effecient in it's object allocation, but I don't know.
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
