0

I have an application with AWT GUI, and I use JTextArea for logging output. If I erase the text with setText(null) or removeAll() or setText("") and then run garbage collector System.gc(), I notice that the whole text still in memory. How can I really delete the text?

I'm not very familiar with profiler, here is what I see in memory dump after setText(null):

profiler snapshot

trincot
  • 317,000
  • 35
  • 244
  • 286
Igor
  • 556
  • 3
  • 19
  • 3
    You may be dealing with a String that has been interred into the [String Pool](http://stackoverflow.com/questions/3801343/what-is-string-pool-in-java). I have to ask, why does this matter? Also why have an AWT GUI use a Swing component (JTextArea)? – Hovercraft Full Of Eels Jan 27 '13 at 16:57
  • 3
    JTextArea sounds like Swing and not AWT. – Dan D. Jan 27 '13 at 16:58
  • 3
    Also, please understand that you really don't have full control over what gets GC'd even if you try to run it. Also, is the String referred to by any other variables? – Hovercraft Full Of Eels Jan 27 '13 at 17:02
  • Was the initial value a string constant or it has been constructed on the fly? – Audrius Meškauskas Jan 27 '13 at 17:14
  • 1
    Have you tried looking if any object was still referencing your String? Usually, profilers are capable of providing such information. Btw, if your string is a static final constant of some class, it will never be GC'eed – Guillaume Polet Jan 27 '13 at 17:25
  • @Igor: Use your profiler's garbage collection button, as suggested [here](http://stackoverflow.com/a/14550869/230513). – trashgod Jan 27 '13 at 18:51
  • Thank you all very much. As assumed by some commentators, I used Swing instead of AWT component. I have replaced JTextArea (Swing) with TextArea (AWT) and now it works. – Igor Jan 29 '13 at 10:26

3 Answers3

4

Please have a read on: How Garbage Collection works in Java.

As per the docs System.gc():

Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects

NB - suggests. This means that the garbage collector is only suggested to do a clean up and not forced also it may entirely ignore your request, thus we cannot know when the garbage will be collected only that it will be in time.

NB - disgarded objects: this refers to all objects that are not static/final or in use/referenced by any other instances/classes/fields/variables etc.

Here is also an interesting question I found on the topic:

with the top answer going along the lines of:

The reason everyone always says to avoid System.gc() is that it is a pretty good indicator of fundamentally broken code. Any code that depends on it for correctness is certainly broken; any that rely on it for performance are most likely broken

and further there has even been a bug submitted for the bad phrasing of the documentation:

.

Community
  • 1
  • 1
David Kroukamp
  • 36,155
  • 13
  • 81
  • 138
4

As @DavidK notes System.gc() is not a useful way to examine this. Using the mechanism described here, most profilers can force garbage collection in a way that, subject to some limitations, is a useful debugging tool.

Community
  • 1
  • 1
trashgod
  • 203,806
  • 29
  • 246
  • 1,045
2

  1. if there are any String objects holding this content in your client program, please set them to null as well.

  2. Also you don't need to explicitly call the System.gc() mothod. JVM does garbage collects the orphaned objects when ever it needs more memory to allocate for other objects.

  3. you only need to worry about if you a see an out of memory / continuous heap memory increase usage etc.

Subba
  • 396
  • 2
  • 13