Ben Rowland

<p>
Both invokeLater() and invokeAndWait() cause the Runnable instance to be executed by the Swing event dispatching thread, regardless of which thread calls the method.
</p>
<p>
These methods are used if you want to update a Swing GUI from (e.g.) the Main thread. Quote from the Sun 'How to Use Threads' tutorial:
<blockquote>
To avoid the possibility of deadlock, you must take extreme care that Swing components and models are created, modified, and queried only from the event-dispatching thread.
</blockquote>
</p>
<p>
By the way I'd recommend that Sun tutorial.
</p>

Good idea ... Browsing through the CVS and the JAR listing it doesn't look like it though.

While browsing though, I found that it uses MemoryMappedFile classes, with use of the new I/O channels - looks interesting.

If these chunks of 'anonymous memory' DO relate to a memory leak then it has to be something slightly off the standard Java curve - after all, we don't do memory leaks in Java

I'll post more if I find anything.

Repost with correct formatting!

Follow-up ... in case anyone else encounters this problem here is some useful stuff.

This command:

<code>
pmap <process id>
</code>

will identify whether there are anonymous memory regions in a java process.

This technote from Sun seems to point the finger at memory leaks.

Follow-up ... in case anyone else encounters this problem here is some useful stuff.

This command:

<code>
pmap <process-id>
</code>

will identify whether there is anonymous memory regions in a java process.

This technote from Sun seems to point the finger at memory leaks.

Thankyou for your reply, I hadn't thought about threads. Yes, you would imagine that objects would be shared throughout threads. Unfortunately, the 348MB RAM usage is confirmed in top, which I believe is quite reliable.

HOWEVER ... I've done a bit more research and it turns out that there's a bug in gnome-system-monitor that causes multiple references to a library or JAR when there shouldn't be. It turns out that the Java process allocates a whole chunk of 'anonymous memory' - the gnome system monitor fills in the library name with the last value it had rather than blanking it out. Hence the duplications.

Thing is, the RAM usage definitely is 348MB right now, verified in top, so I just need to figure out what this 'anonymous memory' is and why there's so much of it allocated!

Thanks for your help,

Ben

Hi,


I have a problem here that I can't get my head around. I'm running a Java program on Linux (SuSE 9.1), and it is taking up an exorbitant amount of RAM (350-400MB).


Being a little curious, I looked in the System Monitor, right-clicked the Java process and clicked Memory Map.


Now the results of this are very interesting - I can see the JAR files that are loaded into RAM. It seems that the same JAR file is loaded in multiple times, taking up way more RAM than it should, intuitively.


Here is an extract of the memory map (the program happens to be the bittorrent client Azureus)



/usr/share/azureus/plugins/azupdater/azupdaterpatcher_1.6.3.jar VM Size = 82876K


/usr/share/azureus/plugins/azupdater/azupdaterpatcher_1.6.3.jar VM Size = 53760K


/usr/share/azureus/plugins/azupdater/azupdaterpatcher_1.6.3.jar VM Size = 38148K


This is the best example of this multiple classloading issue - there are other examples within the process. I've seen it occur with other JAR files, including the 'pango' GNOME font rendering library.


Is this normal, and could it be leading to the overusage of RAM? I have an intermediate knowledge of Linux/Java and haven't really studied the JVM much so I can only use my intuition here.


Over on the Azureus help forums they seem to be clueless so I'm imagining it's a JVM/OS thing.


By the way I'm running the following JVM:


java version "1.4.2_03"

Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)

Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)


Any ideas?