JScrollPane not finalizing

[RocketRod9]

If you add a JScrollPane to a JFrame, neither gets 'finalised' by GC.
If you add a ScrollPane to a JFrame, they both get 'finalised'.

Using JDK 6 under Netbeans IDE 7.0.1.

[doWhile]

If you add a JScrollPane to a JFrame, neither gets 'finalised' by GC.
If you add a ScrollPane to a JFrame, they both get 'finalised'.

Using JDK 6 under Netbeans IDE 7.0.1.

How are you determining what gets finalized? Why are you comparing apples and oranges (Swing vs a combination of Swing/AWT)? More importantly, why do you care...are you having memory issues?

[RocketRod9]

I have 'extended' each of JScrollPane and ScrollPane, overridden the 'finalise' method for each to 'System.out.println(<mytelltale>)' message to confirm whether they are being finalised or not.

'apples' and 'oranges' - to isolate I believe the problem being with JScrollPane.

I market a commercial package for the Construction Industry written in java. Recently is has been used for Estimating Projects sometimes in the order of >$USD 1 billion, so the data gets extremely big. This is when it has become obvious that there are extensive 'memory leaks' occurring.

It has taken me nearly two weeks now to drill down to the cause - JScrollPane preventing data tables (JTable wrapped in a JScrollPane wrapped in a JFrame) from finalising and thus being flushed from heap.

[Fubarable]

Do you know that adding a finalize method to a class may delay it's garbage collection? So your testing may be skewing the result. For more on this, please check out this reference: The Truth About Garbage Collection

[RocketRod9]

I sure am aware that GC does not occur straight away and sometimes not at all.

I make sure it occurs by 'stressing' the test after disposing of the JFrame.

[doWhile]

I market a commercial package for the Construction Industry written in java. Recently is has been used for Estimating Projects sometimes in the order of >$USD 1 billion, so the data gets extremely big. This is when it has become obvious that there are extensive 'memory leaks' occurring.

Define leaks. Leaks as I see it result in OutOfMemoryExceptions because you hold onto references to objects, not some unpredictable output from overriding methods that, at least to me, seems like guessing in the dark. If you truly feel a memory leak occurs, reproduce it in smaller form as an SSCCE that can result in a more edifying discussion

[Tolls]

Overriding finalize is almost always a mistake.
It is even more of a mistake if you are using that in an attempt to trace a memory leak.

Do it properly and profile your app. First take several heap dumps and use something like Eclipse MAT to see where the culprit is. That will catch 99% of them. Once you knw which one it is then see if you can spot why they are multplying and not being collected.

[RocketRod9]

Sir,
without prejudice and with due respect, I have been programming in Java for quite a number of years now and I know what a memory leak is and I hope you do too.

I have in the past always shunned these forums because there tends to be a 'lot of battle of egos' going on behind the scenes, and quite a lot of mental gymnastics, and is quite unproductive for all concerned.

Importantly, I am not a casual programmer; I program for a commercial package, so my time is limited. At the moment I am 'tearing my hair out' with this issue and do really need CONSTRUCTIVE feedback.

Please look at my original post again with a more constructive view and if you think you CAN help please let us continue our dialog, otherwise thank you for your initial interest.

AS EVIDENCE:

Creating hog #1
Creating Frame #2
Creating hog #2
Creating Frame #3
Creating hog #3
Destroying hog #3
Finalizing Frame #3 with ScrollPane
Finalizing Frame #3
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOfRange(Arrays.java:3209)
at java.lang.String.<init>(String.java:215)
at java.lang.StringBuilder.toString(StringBuilder.jav a:430)
at testing.Main$memoryHog.<init>(Main.java:563)
at testing.Main$TestFrame.<init>(Main.java:535)
at testing.Main$TestWindow$1.mouseClicked(Main.java:1 99)
at java.awt.AWTEventMulticaster.mouseClicked(AWTEvent Multicaster.java:253)
at java.awt.Component.processMouseEvent(Component.jav a:6376)
at javax.swing.JComponent.processMouseEvent(JComponen t.java:3267)
at java.awt.Component.processEvent(Component.java:613 8)
at java.awt.Container.processEvent(Container.java:208 5)
at java.awt.Component.dispatchEventImpl(Component.jav a:4735)
at java.awt.Container.dispatchEventImpl(Container.jav a:2143)
at java.awt.Component.dispatchEvent(Component.java:45 65)
at java.awt.LightweightDispatcher.retargetMouseEvent( Container.java:4621)
at java.awt.LightweightDispatcher.processMouseEvent(C ontainer.java:4291)
at java.awt.LightweightDispatcher.dispatc

I am pressed for time at the moment but can provide you with the source code if relevant now.

Regards,

[DarrylBurke]

I am pressed for time at the moment but can provide you with the source code

Only if it's in the form of an SSCCE (Short, Self Contained, Compilable and Executable) example.

db

[Tolls]

Sir,
without prejudice and with due respect, I have been programming in Java for quite a number of years now and I know what a memory leak is and I hope you do too.

I have in the past always shunned these forums because there tends to be a 'lot of battle of egos' going on behind the scenes, and quite a lot of mental gymnastics, and is quite unproductive for all concerned.

Importantly, I am not a casual programmer; I program for a commercial package, so my time is limited. At the moment I am 'tearing my hair out' with this issue and do really need CONSTRUCTIVE feedback.

What do your heap dumps show?
If you can't say, then take some heap dumps and analyse them.
Until you do that you are flailing in the dark.
As I said above, trying to trace a memory leak using finalizers is just plain wrong.

[RocketRod9]

OK we need some focus - I obviously have not provided enough info, so here goes.

Chain of events:
1.received feedback that under stress, my application 'runs out of memory'
2.Investigated using Netbeans Profiler and JConsole to drill down and find culprit
3.As I said in my first post, I suspected the culprit to be JScrollPane
4.Set up a very small Test project simply comprising a JFrame, JTextArea, JScollPane, and 'Memory Hog' object to stress the program
5.To speed up testing, provided overridden 'finalise' methods to get quick responses of which classes were being 'finalised'. OVERRIDING THE FINALIZE METHOD IS A VALID TOOL IN JAVA TO CLEAN UP, JUST MAKE SURE YOU ALSO CALL THE SUPER CLASS AS WELL
6.Noticed JFrame and JScrollPane were not getting finalised by GC
7.Further investigated using Netbeans Profiler and JConsole and confirmed 6.
8.Replaced JScollPane with ScrollPane in the Test project, and finalisation of both JFrame and ScrollPane occurred

[Tolls]

I would argue point 5 is not a valid tool, since by over-riding the finalize you are fundamentally changing how and what gets garbage collected.
For point 3, I take it the heap dump showed a large number of JScrollPanes?

You could post the code here if it's a small test.

[RocketRod9]

Yes - these JScrollPane instances just kept building up and were never released.
You questioned point 5:
Garbage Collection involves two passes:
1st pass 'collects' the reference to all objects which no longer have references to them (garbage collection)
2nd pass removes them from heap, but before doing this, it calls the objects 'finalize()' method allowing the programmer to do any housekeeping/clean up necessary before actually destroying the object. In my case all I am doing is using these principles to monitor the objects destruction and by consequence it's removal from heap.

Code: I will clean up, simplify, and add comments then post it to you.
In the meantime I am trying to drill down into the JScrollPane components (maybe a listener or something) to see what is causing this.

Thanks again for your help.

[DarrylBurke]

1.received feedback that under stress, my application 'runs out of memory'

Why the vagueness? either the application crashes with an OOME or it doesn't.

If this is just about monitoring memory usage with Windows Task Manager or some other utility and observing an increasing trend, but the application never actually experiences OOME, I'd say it's not much worth bothering about -- and if considered important to the client, could probably be addressed with command line flags for gc tweaks.

db

[doWhile]

I have in the past always shunned these forums because there tends to be a 'lot of battle of egos' going on behind the scenes, and quite a lot of mental gymnastics, and is quite unproductive for all concerned.

Importantly, I am not a casual programmer; I program for a commercial package, so my time is limited. At the moment I am 'tearing my hair out' with this issue and do really need CONSTRUCTIVE feedback.

And you call us the one's with egos...its nice to know you feel our replies are unconstructive.

You get what you give. Provide vague information and get vague responses - we cannot read minds. Provide context to the situation, perhaps some code, and all exceptions and observations and you will get much more quality feedback.

[Tolls]

Yes - these JScrollPane instances just kept building up and were never released.
You questioned point 5:
Garbage Collection involves two passes:
1st pass 'collects' the reference to all objects which no longer have references to them (garbage collection)
2nd pass removes them from heap, but before doing this, it calls the objects 'finalize()' method allowing the programmer to do any housekeeping/clean up necessary before actually destroying the object. In my case all I am doing is using these principles to monitor the objects destruction and by consequence it's removal from heap.

Code: I will clean up, simplify, and add comments then post it to you.
In the meantime I am trying to drill down into the JScrollPane components (maybe a listener or something) to see what is causing this.

Thanks again for your help.

You have gc wrong.
Firstly, GC is generational, so what gets looked at entirely depends on how old it is (and therefore what pass is being conducted). Older stuff is held onto.
Secondly finalize is only handled on objects that have a finalize() method.
Those objects are taken out of the normal gc run and placed in a finalize queue, which can take a long time to actually execute since it is more intensive than a normal run, and can also result in side effects such as retention of otherwise removable objects.
So by giving your JScrollPane a finalize() method you are changing (fundamentally) how that object is collected.

[Tolls]

Code: I will clean up, simplify, and add comments then post it to you.
In the meantime I am trying to drill down into the JScrollPane components (maybe a listener or something) to see what is causing this.

Thanks again for your help.

It's unlikely be a listener, unless that listener is holding onto a reference to the pane.
Something is holding onto a reference.

[DarrylBurke]

It's unlikely be a listener, unless that listener is holding onto a reference to the pane.
Something is holding onto a reference.

I'd say the most likely candidate is a UI delegate ... especially if the OP's application uses some custom third-party LaF.

That's if the application is running into OOME -- something we still don't know for sure.

db

[Tolls]

I'd say the most likely candidate is a UI delegate ... especially if the OP's application uses some custom third-party LaF.

That's if the application is running into OOME -- something we still don't know for sure.

db

Fair point, as the only OOME we have been shown is the one from the test case, which is suspect anyway since it is working on the assumption that a finalize() is normally called, which is not the case.

[DarrylBurke]

Fair point, as the only OOME we have been shown is the one from the test case, which is suspect anyway since it is working on the assumption that a finalize() is normally called, which is not the case.

I remember a thread on the erstwhile Sun forums where OOME was triggered by adding and removing a JPanel to a JFrame in a tight loop -- and nothing else -- without retaining any reference to the panel. Somebody actually traced that the RepaintManager was holding on to a reference to each panel, patiently waiting for a chance to do the repainting and get it over with :)

In that case, since the code was running in the main(...) method -- not on the EDT -- a 20ms sleep(...) inside the loop gave the RepaintManager a chance to do its work on the EDT, and memory usage remained low.

Waiting for further, relevant information -- and the SSCCE.

db