Re: JTextArea is a memory hog!
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!
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. What is the fix? How do you patch AbstractDocument so that it doesn't create all these AbstractElements? You could still patch this because you could simply implement the Document interface. Is it creating them in createElement(). Why does it create them and then all of a sudden ditch them? Shouldn't it create them and hang onto them while the JTextArea is in use? charlie --- Christian Pesch <[EMAIL PROTECTED]> wrote: > 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 > > > __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Advanced-swing mailing list [EMAIL PROTECTED] http://eos.dk/mailman/listinfo/advanced-swing
Re: JTextArea is a memory hog!
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