JDK-4814214 : JTextArea creates thousands of java.lang.ref.Finalizers on large text strings
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2003-02-06
  • Updated: 2003-02-07
  • Resolved: 2003-02-07
Related Reports
Duplicate :  
Description

Name: jk109818			Date: 02/06/2003


FULL PRODUCT VERSION :
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :

I created a small test application that reads in a file
from disk and displays it in a JTextArea.  When the file is
around 2MB JTextArea eats up a whopping 65MB!  At 3MB I got
an OutOfMemoryError.  I looked at what was creating so many
objects in OptimizeIt, and there were over 394,000
java.lang.ref.Finalizer objects!  I'm not sure what this
object is because it's a package protected class that is
not documented anywhere in the JDK docs, or mentioned on
Sun's site.  What's worse is that I don't know when they
get GC'ed.  In my original program where I discovered this
problem these objects did not seem to get freed after the
dialog was dismissed which left my program with tons of
memory being used that I had no control over.

When I analyzed the allocation backtraces, the hotspots
were javax.swing.text.AbstractDocument.createLeafElement()
which was 33.32% of allocations and
javax.swing.text.GapContent.createPosition() which
accounted for 66.63% of allocations.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.  Create a large file say around 2MBs
2.  Modify the small program I included to read that file.
3.  Run the program and observe the memory usage.  Better
run it within OptimizeIt or another memory profiling tool
and see how many java.lang.ref.Finalizer objects that are
created!

EXPECTED VERSUS ACTUAL BEHAVIOR :
Much better use of memory!  This is insane how much memory
is chewed up with some undocumented object.  If I read in a
2MB file I hope to see memory usage change by 2-3MB not 20-
30 times that.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.*;
import java.io.*;

public class MemoryMonster {
    public static void main(String[] args) {
        JTextArea textAreaIps = new JTextArea( 50, 80 );
        JFrame frame = new JFrame();
        frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
        frame.setContentPane( new JScrollPane( textAreaIps ) );
        frame.pack();

        String strContents = "";
        try {
            File fileHost = new File("bigfile.txt");   // change this file to
point to your big file you created.
            int characterRead;
            Reader fis = new BufferedReader( new FileReader( fileHost ) );
            StringWriter writer = new StringWriter(
                new Long( fileHost.length() ).intValue() );
            while ( ( characterRead = fis.read() ) != -1 )
                writer.write( characterRead );
            strContents = writer.getBuffer().toString();

            System.out.println("String size is " + strContents.length() );
            textAreaIps.setText( strContents );
            frame.setVisible( true );
        } catch ( IOException e ) {
            JOptionPane.showMessageDialog( null, e.getMessage(), "ERROR",
JOptionPane.ERROR_MESSAGE );
        }
    }
}
---------- END SOURCE ----------

CUSTOMER WORKAROUND :
Doesn't seem to be one.  Maybe create your own Document
object that doesn't extends AbstractDocument.
(Review ID: 179612) 
======================================================================

Comments
EVALUATION Name: ik75403 Date: 02/07/2003 This bug is fixed already. see 4525843 closing this one as a dup of 4525843 ======================================================================
11-06-2004