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
JTextArea is a memory hog!
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. It's a package protected object,
and there is no documenation about it anywhere! 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.
Here is my bug report I submitted to Sun. It's not
yet approved, but since they take forever to evaluate
some bug reports much less fix them. I thought I'd
seek some insight into how I could make my own
Document object more
effecient.
Does anyone have any expertise in this area to help me
write a Document class to replace AbstractDocument
that could fix this problem?
thanks
charlie
Your report has been assigned an internal review ID
of: 179612
This review ID is NOT visible on the "Java Developer
Connection"
(JDC).
We greatly appreciate your interest in improving the
quality
of Java(tm) Technology from Sun Microsystems.
Please be aware that the large volume of reports we
receive
sometimes prevents us from responding individually to
each
message.
We currently have a three week response time for
responding to
Bug Reports. If the information is determined to be a
new bug,
or a duplicate of a known bug, you will receive a
followup email
containing a seven digit bug number. You may search
for this bug
number on the "Java Developer Connection" (JDC) at
this URL:
http://developer.java.sun.com/developer/bugParade/index.html.
If you just reported an issue that could have a major
impact on your project and you require a response,
please consider purchasing one of the support
offerings
at this URL:
http://java.sun.com/support/index.html
--
dateCreated: Fri Jan 03 16:06:03 MST 2003
type:bug
cust_name: Charlie Hubbard
cust_email: [EMAIL PROTECTED]
jdcid: charlie76
status: Waiting
category:java
subcategory: classes_swing
company: other
release: 1.4.1
hardware:x86
OSversion: windows_2000
priority:4
synopsis:JTextArea creates thousands of
java.lang.ref.Finalizers
on
large text strings
description: 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 --
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 )
);
StringWrit
