Avoiding Garbage Collection

Hi,
Does anyone know of a general design pattern that allows an object to remain
in memory without being garbage collected ? I'm not clear whether or not
the singleton pattern fulfills this requirement. I basically want to have a
Global constants class (constants are loaded from a properties file) that
remains in memory so that it can be used by various components. The
constants are loaded from a properties file initialially. So if that class
gets garbage collected, then the next time that class is accessed, it will
have to reload from the props file. This is a performance issue, and I
would like to find a solution around it.
I will probably want to have other services such as a LoggingService,
JNDIService that I want started up, and for it to remain in memory. I know
you can register startup classes with WL, but do those classes remain in
memory ?
I'm been trying to find an answer to these questions. Hopefully someone
will have them.
Thanks.

One way to do it is to bind your constants class into JNDI during
start-up.
-- Rob
Jamie Tsao wrote:
>
Hi,
Does anyone know of a general design pattern that allows an object to remain
in memory without being garbage collected ? I'm not clear whether or not
the singleton pattern fulfills this requirement. I basically want to have a
Global constants class (constants are loaded from a properties file) that
remains in memory so that it can be used by various components. The
constants are loaded from a properties file initialially. So if that class
gets garbage collected, then the next time that class is accessed, it will
have to reload from the props file. This is a performance issue, and I
would like to find a solution around it.
I will probably want to have other services such as a LoggingService,
JNDIService that I want started up, and for it to remain in memory. I know
you can register startup classes with WL, but do those classes remain in
memory ?
I'm been trying to find an answer to these questions. Hopefully someone
will have them.
Thanks.--
Coming Soon: Building J2EE Applications & BEA WebLogic Server
by Michael Girdley, Rob Woollen, and Sandra Emerson
http://learnweblogic.com

Similar Messages

Use Garbage Collection Liberary in C++ application

I knew that Garbage Collection liberary was implemented using C++
Can I use it when I write C++ application to avoid any memory leak happens in my application.

pm_kirkham wrote:
-Kayaman- wrote:
kavon89 wrote:
pm_kirkham wrote:
James_Vagabond wrote:
morgalr wrote:... Java with C syntax.You make it sound as if garbage collection is a Java thing. In fact it was in the earliest OO programming language. See Simula
You make it sound as if garbage collection is an OO thing. In fact it was in the second oldest programming language. See LISP
You make it sound as if garbage collection is a computer thing. In fact it pre-dates computers. See [Waste collector|http://en.wikipedia.org/wiki/Waste_collector] .
You make it sound as if collection is a garbage thing. In fact it pre-dates waste management. See [Tax collector|http://en.wikipedia.org/wiki/Tax_collector].
You make it sound as if collecting stuff together is a human thing. In fact it is instrumental in aggregating a dust cloud into stars and planets. See the [formation of the solar system|http://en.wikipedia.org/wiki/Formation_and_evolution_of_the_Solar_System].
So that's what we are; just garbage on the heap?

Garbage-collecting the cloned objects

public class Clone implements Cloneable {
public static void main(String[] arg) {
Clone i0, i1;
i0 = new Clone();
System.out.println("Created: " + i0);
try{
i1 = (Clone)i0.clone();
System.out.println("Cloned: " + i1);
} catch(CloneNotSupportedException e){
e.printStackTrace();
i0 = null;
i1 = null;
System.gc();
public Object clone() throws CloneNotSupportedException {
return super.clone();
public void finalize() {
System.out.println("Finalizing " + this);
With the example above you can notify that with Hotspot VM of JDK1.3 the
finalize() method will not be called for the cloned object; though,
running the sample with the classic VM, the finalize() will be
called for both objects.
Bypassing the finalize() can be made intended, in order to avoid
multiple "release" or "close" calls on the same object, eg. if the
finalize() has to close a file or a JDBC-connnection. But then why
is it called in the classic VM? Is it sure that the cloned object
too will be garbage-collected?

Here's the proper way to write a clone() method:
public Object clone() {
    try {
        return super.clone();
    } catch (CloneNotSupportedException e) {
        throw new RuntimeException(e);
}There's no reason for a clone() method to declare that it throws CloneNotSupportedException. Doing so just makes code that uses the clone() method more complicated unnecessarily.
Here's the proper way to write a finalizer:
protected void finalize() {
    try {
        // perform subclass cleanup
    } finally {
        super.finalize();
You should always make finalize() protected to help ensure that only the garbage collector calls it, and it should always call super.finalize() to ensure that the superclass finalization can happen.
Now, to your question. There's no way to guarantee that an object will be garbage collected or finalized. In fact, finalizers are so notoriously hard to write correctly that Java 2 added PhantomReferences to allow a simpler way to clean up objects.
If you want an object to release resources, such as closing a file or releasing a database connection, provide a close() or dispose() or release() method in the class and close the resources there. Even if you could guarantee that your finalizer is called or if you used PhantomReference queues to perform cleanup, this cleanup would probably not happen in a timely manner. Finalizers are not C++ destructors -- if you need to release resources, add a method to do that.

GUI Garbage Collection

Hi Everyone.
This is very urgent. I need to perform a possible garbage collection of a heavy GUI stuff when it is not in use. Each of the GUI stuff is created from an action listener for the various menu items. I did try using WeakReference but its very hard to know that when the collection will take place.
Here is the code snippet for the situation...
//this is application's main frame class...
public class MyApplication extends JFrame
JMenuItem menu1, menu2;
WeakReference ref_MyPanel;
//earlier it was a strong reference of MyPanel over here
public static void main(String [] args)
//instantiating this class and showing that here ...
//This is called from menu1's action listener..
void showGUI()
JFrame f = new JFrame();
if(ref_MyPanel.get()!=null)
f.getContentPane().add((MyPanel)ref_MyPanel.get());
else
MyPanel mp = new MyPanel();
ref_MyPanel=new WeakReference(mp);
f.getContentPane().add(mp);
mp=null;//clearing the strong refernce
f.show();
//A GUI class which needs to be reclaimed when done
class MyPanel extends JPanel
double [] a;
MyPanel1()
a = new double [1000000]; //making the panel instance heavy
What i want is to reclaim the memory occupied by MyPanel instance after its Frame being closed. I even tried calling the System.gc() from the MyPanel instance's parent frame's WindowListener -> windowClosed() but it didn't help. Actually this is suffering me a lot as there are several menu items and several GUIs are being instantiated similar to those of MyPanel as shown above. Do i need to change this design to achieve the objective?
Can anyone help?

We saw a significant memory improvement in our system when we used this
utility. Try using this handy class to recursively remove each component
For JFrames & JApplets I think it was
ComponentCleaner.cleanComponent ( myFrame.getContentPane() );
For Frames & Applets
ComponentCleaner.cleanComponent ( myFrame );
Also, for every addActionListener(), addComponentListener() etc call,
you want a removeActionListener(), removeComponentListener() call.
The listeners store references to the visual components if I remember rightly. So avoid anonymous listener classes, and have proper cleanup methods to remove the listeners.
(code below)
regards,
Owen
import java.awt.Container;
import java.awt.Component;
import javax.swing.RootPaneContainer;
public class ComponentCleaner
    public static void cleanComponent(Component baseComponent)
        if (baseComponent == null) // recursion terminating clause
            return ;
        Container cont;
        Component[] childComponents;
        int numChildren;
        // clean up component containers
        if(baseComponent instanceof Container)
            // now clean up container instance variables
            if (baseComponent instanceof RootPaneContainer)
               // Swing specialised container
                cont = (Container)baseComponent;
                numChildren = cont.getComponentCount();
                childComponents = cont.getComponents();
                for(int i = 0;i < numChildren;i++)
                    // remove each component from the current container
                    // each child component may be a container itself
                    cleanComponent(childComponents);
((RootPaneContainer)cont).getContentPane().remove(childComponents[i]);
((RootPaneContainer)cont).getContentPane().setLayout(null);
else
{ // General Swing, and AWT, Containers
cont = (Container)baseComponent;
numChildren = cont.getComponentCount();
childComponents = cont.getComponents();
for(int i = 0;i < numChildren;i++)
// remove each component from the current container
// each child component may be a container itself
cleanComponent(childComponents[i]);
cont.remove(childComponents[i]);
cont.setLayout(null);
} // if component is also a container

BufferedWriter I/O Garbage Collection!?

Ack! I cannot come up with an I/O solution that doesn't produce a lot of objects for collection. I'm sure there has to be a way, but at this point I'm at a loss. I recently noticed after downloading Optimizeit and watching object creation, that everytime I write to an output stream (in my case it's BufferedWriter going out to a socket), it creates new byte[] objects in large quantities, which are then available for garbage collection. This normally wouldn't be an issue, but if I wrap my code around a for loop that outputs a lot of data, I've generated quite a lot of instances. (I have a memory leak somewhere in my code, looking at object creation is about all I can do to find it)
For example, assume I have a StringBuffer _Buffmessage.
I also have a character array out_message.
os is my outputStream.
os = new BufferedWriter(new OutputStreamWriter(clientSocket.getOutputStream()));
//loop through StringBuffer and copy into a character array to prevent creation of String object
//(alternative to using toString() method of StringBuffer
for(int i = 0 ; i < _Bufmessage.length(); i ++)
out_message[i] = _Bufmessage.charAt(i);
//write out character array to client
os.write(out_message, 0, _Bufmessage.length());
os.newLine();
os.flush();If I run this code around 2000 times, I end up generating thousands of instances of byte[] ready for collection after running os.flush(); There HAS to be a way around this, or should I even be concerned about this? Am I somehow creating an object for each byte in the stream?

Here's a follow up and the solution I found. The two suggestions I recieved were:
Suggestion 1:
StringBuffer input;
OutputStream out;
out.write( input.toString().getBytes());
out.close();and Suggestion 2:
StringBuffer input;
OutputStream out;
byte[] outArray = input.toString().getBytes();
out.write(outArray,0,outArray.length );
out.close();However a combination of my original solution as well as the suggested solutions resulted in the fix. In Suggestion 1, every call to write would create an instance of string (bad) and then write the byte array. In Suggestion 2, every call would result in the creation of a string (bad), creation of a byte array(bad), and a dupe of that array into write (ick). This was really an issue since I was outputting around 3-4 thousand times. My final solution is as follows; creates no new instances and is able to write out to my outputstream:
byte[] outArray = new byte[2000]; //byte array for output
OutputStream os = clientSocket.getOutputStream(); //this is the socket outputstream to write to
//for loop here, processing data......
try
//fill the byte array with chars from StringBuffer - reuse the existing array to
//avoid multiple instances being created
for(count = 0 ; count < _Bufmessage.length(); count ++)
   outArray[count] = (byte)_Bufmessage.charAt(count);
//cast a new line byte to the output
outArray[count] = (byte)'\n';
//write out the length of the string
os.write(outArray,0,_Bufmessage.length());
}viola my memory leak was plugged - data is written to output, no char[] or byte[], nor String instances are generated, and I can sleep! As a sidenote, I did end up converting to NIO, and the new I/O classes eliminate these problems. I thought I'd share the solution anyway. Thanks to you three who gave me suggestions and didn't give me a hard time being a first time poster ;)

Low Latency Garbage Collection

Hi,
What is the best garbage collector configuration for a low latency system?
Multi-threaded server process running on a multi-core box (say 8 cores). Reading and writing messages to the network, no disk. Want all messages to be processed in as timely a manner as possible wrt their individual latencies. Want to avoid some messages being delayed by a garbage collection pause. What will give me the 'fairest' latency time amongst the messages?
I should add, Java SE 1.6 recent version.
Thanks in advance for you suggestions.
Rupert Smith
Edited by: rupertlssmith on Dec 2, 2009 10:17 AM

The simplest approach is don't create any objects in your critical path. (Or keep them to a minimum) Javolution and Joda-time have a libraries which helps.
You can try the concurrent mark sweep or G1 collectors to see if they help.
You can get the GC low enough that you will see other delays such as the SMC or network jitter or memory bank effects instead.
i.e. If your server is simple enough, you can see more jitter from the hardware/OS than Java itself.
Edited by: Peter__Lawrey on 02-Dec-2009 20:45

Garbage Collection facilitation by assigning variables to null

Hello,
I understand Garbage Collection (GC) can be facilitated by assigning variables to null. Is this true for all variables?
I have a class and there are some member variables which are strings. Also i have some methods with some string variables declared and defined inside the method. I am assigning null to class member variables and also the string variables of the method.
is it correct to assign null and faciliate GC for the string variables declared and defined inside the method?
Class A {
String t1;
public void test() {
String t2 = "test";
// processing
t2 = null; // Will this facilitate GC?
public static void main (String[] args) {
test();
A obj = new A();
A.t1 = "testclass";
A.t1 = null; // Will this faciliate GC?
Thanks, Aravinth

In fact, the java heap is divided into a space for new allocations, and two survivor spaces. The algorithm for when collection occurs in each space is complex, and tuning GC is an interesting topic all its own. Follow the best advice you have been given ... chillax. The JVM has GC under control.
<think/> Of course, having said this, you can have memory leaks if you create references that never go out of scope, even if they are no longer used. Avoid this.
� {�

Runtime.getRuntime().exec() and Garbage Collection

I am programming a piece of software in both Java and C that has some strict real time requirements. Garbage collection, which pauses all threads in Java, sometimes causes loss of incoming data. In order to get around this, I am thinking to start another process using Runtime.getRuntime().exec("c_program") and using interprocess controls (in a UNIX environment) to retrieve data from the new process.
My only worry is that the Process created by the above call would be a child process of whatever JVM thread created it, (as far as I understand, the JVM implementation in Unix uses multiple processes) and would also be paused when garbage collection occurs. Does anyone know the implementation of the exec functionality and the JVM well enough to say that this will or will not happen?
Thanks in advance,
Benjamin

You're going to create a whole new process? I don't
know what a "child process" means, but Runtime.exec()
gets the operating system to produce an entirely new
process, outside the JVM. However if it produces
output on stdout or stderr, you're going to have
threads in your JVM that read that output, otherwise
that process will hang.
Why is your idea better than just calling the C
program via JNI?Thank you both for your replies. My plan was to create a whole new process, yes. In UNIX, a process C is created by another process P using fork() or the exec() family. Process P is then the parent of process C, and process C is the child of Process P. P has an amount of control over C since it can send various signals to pause, kill, etc to C.
My concern was that the JVM implementation would use these signals to implement the pause of all threads before garbage collecting. If it did, it may also pause the Process that it spawned from the Runtime.exec() call. Pausing my C program in this manner would cause the loss of data I was trying to avoid in the first place.
My plan for the new process was not to produce anything on stdout or stderr, but to pass data back to the JVM using ipc (interprocess communication) resources of UNIX. I would have to use the JNI to access these resources.
The whole reason for wanting to do this is to avoid the pause during garbage collection that all Java Threads experience. If I were just to call the C program through the JNI with a normal Java Thread as I think you were suggesting, this Java Thread would still be paused during garbage collection.
To the second reply about RTSJ, I had heard about this but couldn't find info about it! Thanks for the link. I'm checking it out at the moment. The java runtime must be considerably different for the specifications I see that they guarantee.
Again, thanks for the replies,
Benjamin

Hotspot core dumping during JVM garbage collection ?

We have an application which calls a 3rd party supplied server API which has recently been upgraded to use Java 1.5
We are getting the following error reported by our client application. The application is also now running Java 1.5 but references many classes in jar files which would have quite old code in.
The supplier of the API has stated that the problem requires us to recompile all our jar files using v 1.5 ( including things like jconnect and jms ?!?!? ). This sounds like a bit of a cop-out to me, not to mention being impossible since we don't have the source for things like jconnect.
I suspect that there is a garbage collection problem at the bottom of all this, but I'm not sure how I can "prove" this, nor do I currently have any real clue as to how to fix any GC problem that may exist.
The application is supposed to wait for a message on a MQSeries queue and then transforms it via Xalan XSLT and sends it to a Server application. I've tried playing around with heap sizes etc but that just seems to make it worse. If I leave it at the settings that the previous version used then the client at least manages to process a couple of messages before core dumping. There doesn't seem to be a consistent trigger event to cause the core dump ( it's not a message arriving on a queue for example ) but it does seem to be fairly consistent timewise, i.e. after
Any ideas gratefully accepted.
Here's a logfile excerpt from my applications showing the Hotspot error message :
=====================================================================================
08-Jul-2008 10:01:05 Waiting for messages from COLT.BBFS
08-Jul-2008 10:02:05 Waiting for messages from COLT.BBFS
08-Jul-2008 10:03:05 Waiting for messages from COLT.BBFS
405.815: [GC [PSYoungGen: 17331K->9244K(37632K)] 111702K->103615K(192128K), 0.1615910 secs]
405.977: [Full GC#
# An unexpected error has been detected by HotSpot Virtual Machine:
# SIGBUS (0xa) at pc=0xfe141348, pid=2600, tid=8
# Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
# Problematic frame:
# V [libjvm.so+0x141348]
# An error report file with more information is saved as hs_err_pid2600.log
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
=====================================================================================
The logfile referred to in the error message contains the following.
=====================================================================================
# An unexpected error has been detected by HotSpot Virtual Machine:
# SIGBUS (0xa) at pc=0xfe141348, pid=2600, tid=8
# Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
# Problematic frame:
# V [libjvm.so+0x141348]
--------------- T H R E A D ---------------
Current thread (0x001484d8): VMThread [id=8]
siginfo:si_signo=10, si_errno=0, si_code=1, si_addr=0x0000080f
Registers:
O0=0x00487588 O1=0xfe7d6454 O2=0x000079b0 O3=0x00007800
O4=0x00008868 O5=0x00147d48 O6=0xf8781460 O7=0xfe0f7938
G1=0xe52aaae8 G2=0x00000003 G3=0x00000003 G4=0x001484d8
G5=0xf8781d98 G6=0x00000002 G7=0xf8781d98 Y=0x805683e2
PC=0xfe141348 nPC=0xfe14134c
Top of Stack: (sp=0xf8781460)
0xf8781460: fe786000 00c6ba20 fe10013c e54bab68
0xf8781470: 0000080f e54bab6c 0000080f 00000004
0xf8781480: 00487588 00000134 e54bab6c 00000004
0xf8781490: 00000001 00000000 f87814c0 fe17aef4
0xf87814a0: fe6485b4 fe7d899c 001484d8 0011da40
0xf87814b0: 00148988 00148c10 00148d7c f8781880
0xf87814c0: 007c3389 007c3c0e 00000f87 00008868
0xf87814d0: 00008800 00487588 fe141310 fe7d6454
Instructions: (pc=0xfe141348)
0xfe141338: ec 06 c0 1a 80 a5 a0 00 22 40 00 0a ba 07 60 01
0xfe141348: f2 05 a0 00 ae 0e 60 03 80 a5 e0 03 22 40 00 05
Stack: [0xf8702000,0xf8781d98), sp=0xf8781460, free space=509k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x141348]
V [libjvm.so+0x17aefc]
V [libjvm.so+0x2d557c]
V [libjvm.so+0x300ef8]
V [libjvm.so+0x301e84]
V [libjvm.so+0x2ff950]
V [libjvm.so+0x29df30]
V [libjvm.so+0x362b44]
V [libjvm.so+0x6436f0]
VM_Operation (0xe03012b0): parallel gc system gc, mode: safepoint, requested by thread 0x0031bca0
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x00b2c028 JavaThread "Thread-4" [_thread_in_native, id=85]
0x007f5048 JavaThread "Thread-0" [_thread_blocked, id=84]
0x00c27cf0 JavaThread "Notification Delivery" [_thread_blocked, id=81]
0x0026fa08 JavaThread "RMI LeaseChecker" daemon [_thread_blocked, id=73]
0x00821048 JavaThread "RMI RenewClean-[162.11.2.32:44425]" daemon [_thread_blocked, id=70]
0x0031bca0 JavaThread "GC Daemon" daemon [_thread_blocked, id=67]
0x00cd5d28 JavaThread "RMI Reaper" [_thread_blocked, id=66]
0x003c9300 JavaThread "Timer-0" daemon [_thread_blocked, id=65]
0x00929fe0 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=64]
0x0089bf18 JavaThread "SeedGenerator Thread" daemon [_thread_blocked, id=42]
0x00c47248 JavaThread "Pool thread #7" daemon [_thread_blocked, id=38]
0x00c466a0 JavaThread "Pool thread #6" daemon [_thread_blocked, id=37]
0x00311850 JavaThread "Pool thread #5" daemon [_thread_blocked, id=36]
0x00287a40 JavaThread "Pool thread #4" daemon [_thread_blocked, id=35]
0x00286e98 JavaThread "Pool thread #3" daemon [_thread_blocked, id=34]
0x00c134b0 JavaThread "Pool thread #2" daemon [_thread_blocked, id=33]
0x00ad09e0 JavaThread "Pool thread #1" daemon [_thread_blocked, id=32]
0x00286cd8 JavaThread "PoolThreadManager" daemon [_thread_blocked, id=31]
0x00c129e0 JavaThread "Channel Reaper" daemon [_thread_blocked, id=30]
0x00c669e8 JavaThread "ORB Daemon Thread" daemon [_thread_blocked, id=29]
0x00b10170 JavaThread "Worker for ServerProtocol: (iiop) /0.0.0.0:20168" daemon [_thread_blocked, id=22]
0x008a17e0 JavaThread "Syn~ Client" daemon [_thread_blocked, id=21]
0x003dc378 JavaThread "PoolScavenger0" daemon [_thread_blocked, id=20]
0x0015a928 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=15]
0x00159880 JavaThread "CompilerThread1" daemon [_thread_blocked, id=14]
0x00158a18 JavaThread "CompilerThread0" daemon [_thread_blocked, id=13]
0x00157b98 JavaThread "AdapterThread" daemon [_thread_blocked, id=12]
0x00156dc8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=11]
0x0014ccd8 JavaThread "Finalizer" daemon [_thread_blocked, id=10]
0x0014ad90 JavaThread "Reference Handler" daemon [_thread_blocked, id=9]
0x00038238 JavaThread "main" [_thread_in_native, id=1]
Other Threads:
=>0x001484d8 VMThread [id=8]
0x0015c3b0 WatcherThread [id=16]
VM state:at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x00037728/0x00037758] Threads_lock - owner thread: 0x001484d8
[0x00033650/0x00037ba8] Heap_lock - owner thread: 0x0031bca0
Heap
PSYoungGen total 37632K, used 9244K [0xf2eb0000, 0xf7ba0000, 0xf8400000)
eden space 28352K, 0% used [0xf2eb0000,0xf2eb0000,0xf4a60000)
from space 9280K, 99% used [0xf4a60000,0xf5367080,0xf5370000)
to space 25216K, 0% used [0xf6300000,0xf6300000,0xf7ba0000)
PSOldGen total 154496K, used 94371K [0xe8400000, 0xf1ae0000, 0xf2eb0000)
object space 154496K, 61% used [0xe8400000,0xee028e78,0xf1ae0000)
PSPermGen total 35584K, used 18260K [0xe4400000, 0xe66c0000, 0xe8400000)
object space 35584K, 51% used [0xe4400000,0xe55d5158,0xe66c0000)
Dynamic libraries:
0x00010000      /dsdvlp/java/jvm/jdk1.5.0_03/bin/java
0xff350000      /usr/lib/libthread.so.1
0xff340000      /usr/lib/libdl.so.1
0xff200000      /usr/lib/libc.so.1
0xff390000      /usr/platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1
0xfe000000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/server/libjvm.so
0xff1e0000      /usr/lib/libsocket.so.1
0xff2d0000      /usr/lib/libsched.so.1
0xff1b0000      /usr/lib/libCrun.so.1
0xff160000      /usr/lib/libm.so.1
0xff080000      /usr/lib/libnsl.so.1
0xff060000      /usr/lib/libmp.so.2
0xff030000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/native_threads/libhpi.so
0xfdfc0000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libverify.so
0xfdf80000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libjava.so
0xfdf50000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libzip.so
0xfb7e0000      /usr/lib/locale/en_GB.ISO8859-1/en_GB.ISO8859-1.so.2
0xe4190000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libnet.so
0xe3bd0000      /dsdvlp/lib/5/libSolarisNatives.so
0xe3e90000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/librmi.so
VM Arguments:
jvm_args: -Djava.ext.dirs=/dsdvlp/java/tmijar/firs7/lib/cli:/dsdvlp/java/tmijar/firs7/lib/cli/ext:/dsdvlp/java/tmijar/firs7/lib/cmn/OpenORB:/dsdvlp/java/tmijar/firs7/lib/cmn/OpenORB/ext:/dsdvlp/java/tmijar/firs7/lib/cmn:/dsdvlp/java/tmijar/firs7/lib/cmn/ext:/dsdvlp/java/tmijar/firs7/daemonlib -Duser.dir=/dsdvlp/java/tmijar/firs7 -Dopenorb.config=file:/dsdvlp/java/tmijar/firs7/configs/OpenORB/config/SynOpenORB.xml -Dopenorb.home=file:/dsdvlp/java/tmijar/firs7/configs/OpenORB -Dcom.coexis.syn.general.orbbinding=com.coexis.syn.general.orbbinding.openorb.OpenORBBinding_1_4 -Dsun.rmi.dgc.client.gcInterval=360000 -Dsun.rmi.dgc.server.gcInterval=360000000 -Xms32m -Xmx256m -Dcom.coexis.syn.clientcommandsconfiglocation=file://localhost//dsdvlp/java/tmijar/firs7/configs/clientcommands.xml -Dcom.coexis.syn.clientconfiglocation=file://localhost//dsdvlp/java/tmijar/firs7/configs/fsbbtd_client.xml -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
java_command: com.coexis.syn.mqmessaging.daemon.RunDaemon -p /dsdvlp/bin/5/lndsfsd_fsbbtd.properties start
Environment Variables:
JAVA_HOME=/dsdvlp/java/jvm/jdk150
CLASSPATH=.:/dsdvlp/java/jar/jconnect520.jar:/dsdvlp/java/jar/vbjapp340.jar:/dsdvlp/java/jar/vbjorb340.jar:/dsdvlp/java/jar/javax_jndi120.jar
PATH=/usr/local/etc:/usr/lang:/usr/openwin/bin:/usr/ucb:/bin:/usr/etc:/usr/local/5/bin:/dsdvlp/bin/5:/dsdvlp/bin/4:/home/app/sybase/5/bin:/home/app/sybase/5/localscripts:/home/app/sybase/5/sqr:/home/app/lang:/home/app/lang/SC2.0.1:/usr/ccs/bin:/usr/local/opt/Acrobat3/bin:/dsdvlp/bin:.
LD_LIBRARY_PATH=/dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/server:/dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc:/dsdvlp/java/jvm/jdk1.5.0_03/jre/../lib/sparc:/usr/lib:/usr/openwin/lib:/usr/local/5/lib:/dsdvlp/lib/5:/dstest/lib/5:/home/app/sybase/5/lib:/dstest/cats/sun4/lib:/tmitest/Opus/opus/lib
SHELL=/bin/csh
DISPLAY=CLI00184.mfil.local:1.0
OS=5
--------------- S Y S T E M ---------------
OS: Solaris 8 2/02 s28s_u7wos_08a SPARC
Copyright 2002 Sun Microsystems, Inc. All Rights Reserved.
Assembled 18 December 2001
uname:SunOS 5.8 Generic_117350-20 sun4u (T1 libthread)
rlimit: STACK 8192k, CORE 9216k, NOFILE 4096, AS infinity
load average:2.24 2.67 2.68
CPU:total 4 has_v8, has_v9, has_vis1, has_vis2, is_ultra3
Memory: 8k page, physical 8388608k(166384k free)
vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for solaris-sparc, built on Apr 13 2005 03:31:26 by unknown with unknown Workshop:0x550

The very first suggestion I have is to move your VM to a more recent update of 1.5.0.
It looks like you are crashing with 5.0u3, and I'm pretty sure 5.0u16 is available. You
don't want to waste your time chasing a bug that's already been fixed.

High Eden Java Memory Usage/Garbage Collection

Hi,
I am trying to make sure that my Coldfusion Server is optomised to the max and to find out what is normal limits.
Basically it looks like at times my servers can run slow but it is possible that this is caused by a very old bloated code base.
Jrun can sometimes have very high CPU usage so I purchased Fusion Reactor to see what is going on under the hood.
Here are my current Java settings (running v6u24):
java.args=-server -Xmx4096m -Xms4096m -XX:MaxPermSize=256m -XX:PermSize=256m -Dsun.rmi.dgc.client.gcInterval=600000 -Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.io.useCanonCaches=false -XX:+UseParallelGC -Xbatch ........
With regards Memory, the only memory that seems to be running a lot of Garbage Collection is the Eden Memory Space. It climbs to nearly 1.2GB in total just under every minute at which time it looks like GC kicks in and the usage drops to about 100MB.
Survivor memory grows to about 80-100MB over the space of 10 minutes but drops to 0 after the scheduled full GC runs. Old Gen memory fluctuates between 225MB and 350MB with small steps (~50MB) up or down when full GC runs every 10 minutes.
I had the heap set to 2GB initally in total giving about 600MB to the Eden Space. When I looked at the graphs from Fusion Reactor I could see that there was (minor) Garbage Collection about 2-3 times a minute when the memory usage maxed out the entire 600MB which seemed a high frequency to my untrained eye. I then upped the memory to 4GB in total (~1.2GB auto given to Eden space) to see the difference and saw that GC happened 1-2 times per minute.
Is it normal in Coldfusion that the Eden memory would grow so quickly and have garbage collection run so often? i.e do these graphs look normal?
Also should I somehow redistribute the memory available to give the Eden memory more since it seems to be where all the action is?
Any other advice for performance improvements would be much appreciated.
Note: These graphs are not from a period where jrun had high CPU.
Here are the graphs:
PS Eden Space Graph
PS Survivor Space Graph
PS Old Gen Graph
PS Perm Gen Graph
Heap Memory Graph
Heap/Non Heap Memory Graph
CPU Graph
Request Average Execution Time Graph
Request Activity Graph
Code Cache Graph

Hi,
>Is it normal in Coldfusion that the Eden memory would grow so quickly and have garbage collection run so often?
Yes normal to garbage collect Eden often. That is a minor garbage collection.
>Also should I somehow redistribute the memory available to give the Eden memory more since it seems to be where all the action is?
Sometimes it is good to set Eden (Eden and its two Survivor Spaces combined make up New or Young Generation part of JVM heap) to a smaller size. I know your thinking - what make it less, but I want to make it bigger. Give less a try (sometimes less = more, bigger not = better) and monitor the situation. I like to use -Xmn switch, some sources say to use other method/s. Perhaps you could try java.args=-server -Xmx4096m -Xms4096m -Xmn172m etc. I better mention make a backup copy of jvm.config before applying changes. Having said that now you know how you can set the size to bigger if you want.
I think the JVM is perhaps making some poor decisions with sizing the heap. With Eden growing to 1Gb then being evacuated not many objects are surviving and therefore not being promoted to Old Generation. This ultimately means the object will need to be loaded again latter to Eden rather than being referenced in the Old generation part of the heap. Adds up to poor performance.
>Any other advice for performance improvements would be much appreciated.
You are using Parallel garbage collector. Perhaps you could enable that to run multi-threaded reducing the time duration of the garbage collections, jvm args ...-XX:+UseParallelGC -XX:ParallelGCThreads=N etc where N = CPU cores (eg quad core = 4).
HTH, Carl.

High cpu usage for garbage collection (uptime vs total gc time)

Hi Team,
We have a very high cpu usage issue in the production.
When we restart the server, the cpu idle time would be around 95% and it comes down as days goes by. Today idle cpu is 30% and it is just 6th day after the server restart.
Environemnt details:
Jrockit version:
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
BEA WebLogic JRockit(TM) 1.4.2_05 JVM R24.4.0-1 (build ari-38120-20041118-1131-linux-ia32, Native Threads, GC strategy: parallel)
Gc Algorithm: JRockit Garbage Collection System currently running strategy: Single generational, parallel mark, parallel sweep
Number Of Processors: 4
Max Heap Size: 1073741824
Total Garbage Collection Time: 21:43:56.5
Uptime: 114:33:4.1
Total Garbage Collection Count: 420872
Total Number Of Threads: 198
Number Of Daemon Threads: 191
Can you guys please tell me what would be problem in the server which causing the high cpu usage?
One more thing I would like to know is that why the total number of threads is 198 when we specified the Executor pool size as 25? I agree that weblogic would create some threads for its maintenance but around 160 threads!!! something is wrong I guess.
Santhosh.
[email protected]

Hi,
I'm having a similar problem, but haven't been able to resolve it yet. Troubleshooting is made even harder by the fact that this is only happening on our production server, and I've been unable to reproduce it in the lab.
I'll post whatever findings I have and hopefully we'll be able to find a solution with the help of BEA engineers.
In my case, I have a stand-alone Tomcat server that runs fine for about 1-2 days, and then the JVM suddenly starts using more CPU, and as a result, the server load shoots up (normal CPU utilization is ~5% but eventually goes up to ~95%; load goes from 0.1 to 4+).
What I have found so far is that this corresponds to increased GC activity.
Let me list my environment specs before I proceed, though:
CPU: Dual Xeon 3.06GHz
RAM: 2GB
OS: RHEL4.4 (2.6.9-42.0.2.ELsmp)
JVM build 1.5.0_03-b07 (BEA JRockit(R) (build dra-45238-20050523-2008-linux-ia32, R25.2.0-28))
Tomcat version 5.5.12
JAVA_OPTS="-Xms768m -Xmx768m -XXtlasize16k -XXlargeobjectlimit16k -Xverbose:memory,cpuinfo -Xverboselog:/var/log/tomcat5/jvm.log -Xverbosetimestamp"
Here are excerpts from my verbose log (I'm getting some HT warning, not sure if that's a problem):
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Detected SMP with 2 CPUs that support HT.
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to determine if HT is enabled.
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to read from /dev/cpu/0/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: Failed to read from /dev/cpu/0/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to read from /dev/cpu/1/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: Failed to read from /dev/cpu/1/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] HT is: supported by the CPU, not enabled by the OS, enabled in JRockit.
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: HT enabled even though OS does not seem to support it.
[Fri Oct 20 15:54:55 2006][22855][memory ] GC strategy: System optimized over throughput (initial strategy singleparpar)
[Fri Oct 20 15:54:55 2006][22855][memory ] heap size: 786432K, maximal heap size: 786432K
[Fri Oct 20 16:07:30 2006][22855][memory ] Changing GC strategy to generational, parallel mark and parallel sweep
[Fri Oct 20 16:07:30 2006][22855][memory ] 791.642-791.874: GC 786432K->266892K (786432K), 232.000 ms
[Fri Oct 20 16:08:02 2006][22855][memory ] 824.122: nursery GC 291998K->274164K (786432K), 175.873 ms
[Fri Oct 20 16:09:51 2006][22855][memory ] 932.526: nursery GC 299321K->281775K (786432K), 110.879 ms
[Fri Oct 20 16:10:24 2006][22855][memory ] 965.844: nursery GC 308151K->292222K (786432K), 174.609 ms
[Fri Oct 20 16:11:54 2006][22855][memory ] 1056.368: nursery GC 314718K->300068K (786432K), 66.032 ms
[Sat Oct 21 23:21:09 2006][22855][memory ] 113210.427: nursery GC 734274K->676137K (786432K), 188.985 ms
[Sat Oct 21 23:30:41 2006][22855][memory ] 113783.140: nursery GC 766601K->708592K (786432K), 96.007 ms
[Sat Oct 21 23:36:15 2006][22855][memory ] 114116.332-114116.576: GC 756832K->86835K (786432K), 243.333 ms
[Sat Oct 21 23:48:20 2006][22855][memory ] 114841.653: nursery GC 182299K->122396K (786432K), 175.252 ms
[Sat Oct 21 23:48:52 2006][22855][memory ] 114873.851: nursery GC 195060K->130483K (786432K), 142.122 ms
[Sun Oct 22 00:01:31 2006][22855][memory ] 115632.706: nursery GC 224096K->166618K (786432K), 327.264 ms
[Sun Oct 22 00:16:37 2006][22855][memory ] 116539.368: nursery GC 246564K->186328K (786432K), 173.888 ms
[Sun Oct 22 00:26:21 2006][22855][memory ] 117122.577: nursery GC 279056K->221543K (786432K), 170.367 ms
[Sun Oct 22 00:26:21 2006][22855][memory ] 117123.041: nursery GC 290439K->225833K (786432K), 69.170 ms
[Sun Oct 22 00:29:10 2006][22855][memory ] 117291.795: nursery GC 298947K->238083K (786432K), 207.200 ms
[Sun Oct 22 00:39:05 2006][22855][memory ] 117886.478: nursery GC 326956K->263441K (786432K), 87.009 ms
[Sun Oct 22 00:55:22 2006][22855][memory ] 118863.947: nursery GC 357229K->298971K (786432K), 246.643 ms
[Sun Oct 22 01:08:17 2006][22855][memory ] 119638.750: nursery GC 381744K->322332K (786432K), 147.996 ms
[Sun Oct 22 01:11:22 2006][22855][memory ] 119824.249: nursery GC 398678K->336478K (786432K), 93.046 ms
[Sun Oct 22 01:21:35 2006][22855][memory ] 120436.740: nursery GC 409150K->345186K (786432K), 81.304 ms
[Sun Oct 22 01:21:38 2006][22855][memory ] 120439.582: nursery GC 409986K->345832K (786432K), 153.534 ms
[Sun Oct 22 01:21:42 2006][22855][memory ] 120443.544: nursery GC 410632K->346473K (786432K), 121.371 ms
[Sun Oct 22 01:21:44 2006][22855][memory ] 120445.508: nursery GC 411273K->347591K (786432K), 60.688 ms
[Sun Oct 22 01:21:44 2006][22855][memory ] 120445.623: nursery GC 412391K->347785K (786432K), 68.935 ms
[Sun Oct 22 01:21:45 2006][22855][memory ] 120446.576: nursery GC 412585K->348897K (786432K), 152.333 ms
[Sun Oct 22 01:21:45 2006][22855][memory ] 120446.783: nursery GC 413697K->349080K (786432K), 70.456 ms
[Sun Oct 22 01:34:16 2006][22855][memory ] 121197.612: nursery GC 437378K->383392K (786432K), 165.771 ms
[Sun Oct 22 01:37:37 2006][22855][memory ] 121398.496: nursery GC 469709K->409076K (786432K), 78.257 ms
[Sun Oct 22 01:37:37 2006][22855][memory ] 121398.730: nursery GC 502490K->437713K (786432K), 65.747 ms
[Sun Oct 22 01:44:03 2006][22855][memory ] 121785.259: nursery GC 536605K->478156K (786432K), 132.293 ms
[Sun Oct 22 01:44:04 2006][22855][memory ] 121785.603: nursery GC 568408K->503635K (786432K), 71.751 ms
[Sun Oct 22 01:50:39 2006][22855][memory ] 122180.985: nursery GC 591332K->530811K (786432K), 131.831 ms
[Sun Oct 22 02:13:52 2006][22855][memory ] 123573.719: nursery GC 655566K->595257K (786432K), 117.311 ms
[Sun Oct 22 02:36:04 2006][22855][memory ] 124905.507: nursery GC 688896K->632129K (786432K), 346.990 ms
[Sun Oct 22 02:50:24 2006][22855][memory ] 125765.715-125765.904: GC 786032K->143954K (786432K), 189.000 ms
[Sun Oct 22 02:50:26 2006][22855][memory ] 125767.535-125767.761: GC 723232K->70948K (786432K), 225.000 ms
vvvvv
[Sun Oct 22 02:50:27 2006][22855][memory ] 125768.751-125768.817: GC 712032K->71390K (786432K), 64.919 ms
[Sun Oct 22 02:50:28 2006][22855][memory ] 125769.516-125769.698: GC 711632K->61175K (786432K), 182.000 ms
[Sun Oct 22 02:50:29 2006][22855][memory ] 125770.753-125770.880: GC 709632K->81558K (786432K), 126.000 ms
[Sun Oct 22 02:50:30 2006][22855][memory ] 125771.699-125771.878: GC 708432K->61368K (786432K), 179.000 ms
So, I'm running with the default GC strategy which lets the GC pick the most suitable approach (single space or generational). It seems to switch to generational almost immediately and runs well - most GC runs are in the nursery, and only once in a while it goes through the older space.
Now, if you look at [Sun Oct 22 02:50:27 2006], that's when everything changes. GC starts running every second (later on it's running 3 times a second) doing huge sweeps. It never goes through the nursery again, although the strategy is still generational.
It's all downhill from this point on, and it's a matter of hours (maybe a day) before we restart the server.
I guess my only question is: What would cause such GC behavior?
I would appreciate your ideas/comments!
Thanks,
Tenyo

IncompatibleClassChangeError. Caused by garbage collection?

The problem occurs on JDK 1.3.1-b24 compiled in JBuilder Windows and
running on Sun Solaris with identical JDK version.
The application is a relatively complex RMI server.
An error recovery function in the server runs in a Thread every two
minutes. Most of the time it has nothing to do and ends without
incident.
Occasionally conditions require recovery that may not be successful
for many attempts.
Part of the recovery is a simple debug display of parameters involved
in the recovery. There will be multiple displays during a single
recovery cycle.
In a recent example of problem, the recovery executed every two
minutes for over two hours with the debug display working
successfully.
Suddenly one display works successfully and 5 milliseconds later the
same display fails with a IncompatibleClassChangeError.
The last part of the stack trace is:
java.lang.IncompatibleClassChangeError
     at [class name].toString([class name].java:74)
     at java.lang.String.valueOf(String.java:1947)
     at java.lang.StringBuffer.append(StringBuffer.java:370)
     at java.util.AbstractMap.toString(AbstractMap.java:567)
     at java.lang.String.valueOf(String.java:1947)
line 74 of class is
public String toString()
return _responses.toString();
where _responses is an ArrayList that has been stored on Map that
contains the parameters that is being display as part of the debug
information.
Once the failure occurs, it will always occur until the JVM is
restarted. This suggests to me that something in the JVM, maybe garbage collection, has either corrupted the in-memory copy of the class or some internal table used by the JVM has become corrupted.
Anybody else have ideas?

java.lang.IncompatibleClassChangeError
     at [class name].toString([class name].java:74)
     at java.lang.String.valueOf(String.java:1947)
at
java.lang.StringBuffer.append(StringBuffer.java:370)
at
java.util.AbstractMap.toString(AbstractMap.java:567)
     at java.lang.String.valueOf(String.java:1947)
Problem: The IncompatiableClassChangeError is a Symbolic resolution problem. In lamen's terms a package,class,method,or a variable name is corrupted.
Possible problem location: Are you using a Custom ClassLoader? Do you Load and compile on the fly?
where _responses is an ArrayList that has been stored
on Map that
I would look hard at the following methods in your MAP Interface:
public void clear();
public Object put(Object key,Object value);
public void putAll(Map t);
public Object remove(Object key);Is it possible that your MAP interface is corrupting your ArrayList using one of the above methods? Then, when you are building the strings using the AbstractMap's.toString() method, you are getting the IncompatiableClassChangeError?
This is word for word listing of the MAP Interface...V1.41.
Some map implementations have restrictions on the keys and values they may contain. For example, some implementations prohibit null keys and values, and some have restrictions on the types of their keys.
This puzzles me
Attempting to insert an ineligible key or value throws an unchecked exception, typically NullPointerException or ClassCastException.
What's this, they state above that you should get a unchecked Exception, but the first sentence below makes me assume they are pulling a query on an ineligible key or value???
Attempting to query the presence of an ineligible key or value may throw an exception, or it may simply return false; some implementations will exhibit the former behavior and some will exhibit the latter.
Oh,OK. They are basically saying it totally depends on how you implement this Interface <grin>
More generally, attempting an operation on an ineligible key or value whose completion would not result in the insertion of an ineligible element into the map may throw an exception or it may succeed, at the option of the implementation.
The "optional" they are talking about are the methods that I listed above.
Such exceptions are marked as "optional" in the specification for this interface.
Well you asked for ideas, so there's a brain fart for you?
...Hope this helps

URL class is not being garbage collected

I have created two instances of the URL class to specify a file location for each image. I use com.symantec.itools.javax.swing.icons.ImageIcon class to display images specified by each URL instance as icons inside a button. The setImageLocation method(URL location) of the ImageIcon class sets the location to be displayed by this icon. The following is the code snippets used to create the ImageIcon instances:
private URL greenIconURL;
private URL redIconURL;
com.symantec.itools.javax.swing.icons.ImageIcon green_icon = new com.symantec.itools.javax.swing.icons.ImageIcon();
com.symantec.itools.javax.swing.icons.ImageIcon red_icon = new com.symantec.itools.javax.swing.icons.ImageIcon();
try
greenIconURL = new java.net.URL
("file:./images/greenline.gif");
green_icon.setImageLocation(greenIconURL);
catch (java.net.MalformedURLException error) { }
try
redIconURL = new java.net.URL
("file:./images/redline.gif");
red_icon.setImageLocation(redIconURL);
catch (java.net.MalformedURLException error) { }
I am using JProbe 5.0.1 Memory to determine the loitering objects when I remove the button from the JInternalFrame. I am using Java 1.2.2_08 version. The JProbe Memory Leak Doctor indicates that each URL instance has a reference to an entry in a HashMap table. The reference graph from the root set has a reference to SoftCache to HashMap to HashMap$Entry. To make this URL instance eligible for garbage collection, JProbe Memory Leak Doctor indicates I must remove the entry from the HashMap. How do I get access to this HashMap to remove the entry? If this is a problem with the version of the JDK, please let me know. Thank you in advance for your assistance.

<root>Statics
-->sun.misc.SoftCache->java.util.HashMap->java.util.Has
Map$Entry[]->java.util.HashMap$Entry->java.net.URL
I do not an instance of HashMap in my class.
Therefore, the HashMap is either created by URLclass
or the
com.symantec.itools.javax.swing.icons.ImageIcon
class.SoftCache seems to have a normal HashMap inside
it/* Hash table mapping keys to ValueCells */
private Map hash;but if that is the HashMap in JProbe
information then the URL would have to be a key in
the map - otherwise there'd be another object in the
chain of class SoftCache.ValueCell
are you certain that the java.net.URL's in that
hashmap are your ones?
out of curiosity - are you certain that the URL's are
the/a problem (are you getting an OutOfMemoryError?)
asjfThe button that contains the URL's is the only one on the JInternalFrame. The JProbe Memory Debugger displays the java.net package name, the URL class name, the count (2), and the Count Change (+2). When I remove the button from the JInternalFrame, the aforementioned numbers on the Instance Summary remain the same. The snapshot of the Java Heap reveals that the two instances of the URL class are still there. The Memory Leak Doctor shows the reference graph from the root set:
<root>Statics->SoftCache->HashMap->HashMap$Entry[]->HashMap$Entry->URL
When I right click on the arrow between HashMap$Entry[] and HashMap$Entry to remove the reference, I receive the message: "Congratulations this object can be garbage collected..." It appears like private instance of Map in SoftCache is holding a strong reference.
I am not getting an OutOfMemoryError exception.

Remove / unload external swf file(s) from the main flash file and load a new swf file and garbage collection from memory.

I can't seem to remove / unload the external swf files e.g when the carousel.swf (portfolio) is displayed and I press the about button the about content is overlapping the carousel (portfolio) . How can I remove / unload an external swf file from the main flash file and load a new swf file, while at the same time removing garbage collection from memory?
This is the error message(s) I am receiving: "TypeError: Error #2007: Parameter child must be non-null.
at flash.display::DisplayObjectContainer/removeChild()
at index_fla::MainTimeline/Down3()"
import nl.demonsters.debugger.MonsterDebugger;
var d:MonsterDebugger=new MonsterDebugger(this);
stage.scaleMode=StageScaleMode.NO_SCALE;
stage.align=StageAlign.TOP_LEFT;
stage.addEventListener(Event.RESIZE, resizeHandler);
// loader is the loader for portfolio page swf
var loader:Loader;
var loader2:Loader;
var loader3:Loader;
var loader1:Loader;
// resize content
function resizeHandler(event:Event):void {
    // resizes portfolio page to center
loader.x = (stage.stageWidth - loader.width) * .5;
loader.y = (stage.stageHeight - loader.height) * .5;
// resizes about page to center
loader3.x = (stage.stageWidth - 482) * .5 - 260;
loader3.y = (stage.stageHeight - 492) * .5 - 140;
/*loader2.x = (stage.stageWidth - 658.65) * .5;
loader2.y = (stage.stageHeight - 551.45) * .5;*/
addEventListener(Event.ENTER_FRAME, onEnterFrame,false, 0, true);
function onEnterFrame(ev:Event):void {
var requesterb:URLRequest=new URLRequest("carouselLoader.swf");
loader = null;
loader = new Loader();
loader.name ="carousel1"
//adds gallery.swf to stage at begining of movie
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioError);
function ioError(event:IOErrorEvent):void {
trace(event);
try {
loader.load(requesterb);
} catch (error:SecurityError) {
trace(error);
addChild(loader);
loader.x = (stage.stageWidth - 739) * .5;
loader.y = (stage.stageHeight - 500) * .5;
// stop gallery.swf from duplication over and over again on enter frame
removeEventListener(Event.ENTER_FRAME, onEnterFrame);
//PORTFOLIO BUTTON
//adds eventlistner so that gallery.swf can be loaded
MovieClip(root).nav.portfolio.addEventListener(MouseEvent.MOUSE_DOWN, Down, false, 0, true);
function Down(event:MouseEvent):void {
// re adds listener for contact.swf and about.swf
MovieClip(root).nav.info.addEventListener(MouseEvent.MOUSE_DOWN, Down1, false, 0, true);
MovieClip(root).nav.about.addEventListener(MouseEvent.MOUSE_DOWN, Down3, false, 0, true);
//unloads gallery.swf from enter frame if users presses portfolio button in nav
var requester:URLRequest=new URLRequest("carouselLoader.swf");
    loader = null;
loader = new Loader();
loader.name ="carousel"
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioError);
function ioError(event:IOErrorEvent):void {
trace(event);
try {
loader.load(requester);
} catch (error:SecurityError) {
trace(error);
addChild(loader);
loader.x = (stage.stageWidth - 739) * .5;
loader.y = (stage.stageHeight - 500) * .5;
removeChild( getChildByName("about") );
removeChild( getChildByName("carousel1") );
// remove eventlistner and prevents duplication of gallery.swf
MovieClip(root).nav.portfolio.removeEventListener(MouseEvent.MOUSE_DOWN, Down);
//INFORMATION BUTTON
//adds eventlistner so that info.swf can be loaded
MovieClip(root).nav.info.addEventListener(MouseEvent.MOUSE_DOWN, Down1, false, 0, true);
function Down1(event:MouseEvent):void {
//this re-adds the EventListener for portfolio so that end user can view again if they wish.
MovieClip(root).nav.portfolio.addEventListener(MouseEvent.MOUSE_DOWN, Down, false, 0, true);
MovieClip(root).nav.about.addEventListener(MouseEvent.MOUSE_DOWN, Down3, false, 0, true);
var requester:URLRequest=new URLRequest("contactLoader.swf");
loader2 = null;
loader2 = new Loader();
loader2.name ="contact"
loader2.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioError);
function ioError(event:IOErrorEvent):void {
trace(event);
try {
loader2.load(requester);
} catch (error:SecurityError) {
trace(error);
addChild(loader2);
loader2.x = (stage.stageWidth - 658.65) * .5;
loader2.y = (stage.stageHeight - 551.45) * .5;
// remove eventlistner and prevents duplication of info.swf
MovieClip(root).nav.info.removeEventListener(MouseEvent.MOUSE_DOWN, Down1);
//ABOUT BUTTON
//adds eventlistner so that info.swf can be loaded
MovieClip(root).nav.about.addEventListener(MouseEvent.MOUSE_DOWN, Down3, false, 0, true);
function Down3(event:MouseEvent):void {
//this re-adds the EventListener for portfolio so that end user can view again if they wish.
MovieClip(root).nav.portfolio.addEventListener(MouseEvent.MOUSE_DOWN, Down, false, 0, true);
MovieClip(root).nav.info.addEventListener(MouseEvent.MOUSE_DOWN, Down1, false, 0, true);
var requester:URLRequest=new URLRequest("aboutLoader.swf");
loader3 = null;
loader3 = new Loader();
loader3.name ="about"
loader3.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioError);
function ioError(event:IOErrorEvent):void {
trace(event);
try {
loader3.load(requester);
} catch (error:SecurityError) {
trace(error);
addChild(loader3);
loader3.x = (stage.stageWidth - 482) * .5 - 260;
loader3.y = (stage.stageHeight - 492) * .5 - 140;
removeChild( getChildByName("carousel") );
removeChild( getChildByName("carousel1") );
// remove eventlistner and prevents duplication of info.swf
MovieClip(root).nav.about.removeEventListener(MouseEvent.MOUSE_DOWN, Down3);
stop();

Andrei1,
Thank you for the helpful advice. I made the changes as you suggested but I am receiving a #1009 error message even though my site is working the way I wan it to work. I would still like to fix the errors so that my site runs and error free. This is the error I am receiving:
"TypeError: Error #1009: Cannot access a property or method of a null object reference."
I'm sure this is not the best method to unload loaders and I am guessing this is why I am receiving the following error message.
     loader.unload();
     loader2.unload();
     loader3.unload();
I also tried creating a function to unload the loader but received the same error message and my portfolio swf was not showing at all.
     function killLoad():void{
     try { loader.close(); loader2.close; loader3.close;} catch (e:*) {}
     loader.unload(); loader2.unload(); loader3.unload();
I have a question regarding suggestion you made to set Mouse Event to "null". What does this do setting the MouseEvent do exactly? Also, since I've set the MouseEvent to null do I also have to set the loader to null? e.g.
---- Here is my updated code ----
// variable for external loaders
var loader:Loader;
var loader1:Loader;
var loader2:Loader;
var loader3:Loader;
// makes borders resize with browser size
function resizeHandler(event:Event):void {
// resizes portfolio page to center
     loader.x = (stage.stageWidth - loader.width) * .5;
     loader.y = (stage.stageHeight - loader.height) * .5;
// resizes about page to center
     loader3.x = (stage.stageWidth - 482) * .5 - 260;
     loader3.y = (stage.stageHeight - 492) * .5 - 140;
//adds gallery.swf to stage at begining of moviie
     Down();
//PORTFOLIO BUTTON
//adds eventlistner so that gallery.swf can be loaded
     MovieClip(root).nav.portfolio.addEventListener(MouseEvent.MOUSE_DOWN, Down, false, 0, true);
function Down(event:MouseEvent = null):void {
// re adds listener for contact.swf and about.swf
     MovieClip(root).nav.info.addEventListener(MouseEvent.MOUSE_DOWN, Down1, false, 0, true);
     MovieClip(root).nav.about.addEventListener(MouseEvent.MOUSE_DOWN, Down3, false, 0, true);
//unloads gallery.swf from enter frame if users presses portfolio button in nav
     var requester:URLRequest=new URLRequest("carouselLoader.swf");
     loader = new Loader();
     loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioError);
     function ioError(event:IOErrorEvent):void {
     trace(event);
     try {
     loader.load(requester);
     } catch (error:SecurityError) {
     trace(error);
     this.addChild(loader);
     loader.x = (stage.stageWidth - 739) * .5;
     loader.y = (stage.stageHeight - 500) * .5;
// sure this is not the best way to do this - but it is unload external swfs
     loader.unload();
     loader2.unload();
     loader3.unload();
// remove eventlistner and prevents duplication of gallery.swf
     MovieClip(root).nav.portfolio.removeEventListener(MouseEvent.MOUSE_DOWN, Down);
//INFORMATION BUTTON
     //adds eventlistner so that info.swf can be loaded
     MovieClip(root).nav.info.addEventListener(MouseEvent.MOUSE_DOWN, Down1, false, 0, true);
     function Down1(event:MouseEvent = null):void {
     //this re-adds the EventListener for portfolio so that end user can view again if they wish.
     MovieClip(root).nav.portfolio.addEventListener(MouseEvent.MOUSE_DOWN, Down, false, 0, true);
     MovieClip(root).nav.about.addEventListener(MouseEvent.MOUSE_DOWN, Down3, false, 0, true);
     var requester:URLRequest=new URLRequest("contactLoader.swf");
     loader2 = null;
     loader2 = new Loader();
     loader2.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioError);
     function ioError(event:IOErrorEvent):void {
     trace(event);
     try {
     loader2.load(requester);
}      catch (error:SecurityError) {
     trace(error);
     addChild(loader2);
     loader2.x = (stage.stageWidth - 658.65) * .5;
     loader2.y = (stage.stageHeight - 551.45) * .5;
loader.unload();
loader2.unload();
loader3.unload();
     // remove eventlistner and prevents duplication of info.swf
     MovieClip(root).nav.info.removeEventListener(MouseEvent.MOUSE_DOWN, Down1);
//ABOUT BUTTON
     //adds eventlistner so that info.swf can be loaded
     MovieClip(root).nav.about.addEventListener(MouseEvent.MOUSE_DOWN, Down3, false, 0, true);
     function Down3(event:MouseEvent = null):void {
     //this re-adds the EventListener for portfolio so that end user can view again if they wish.
     MovieClip(root).nav.portfolio.addEventListener(MouseEvent.MOUSE_DOWN, Down, false, 0, true);
     MovieClip(root).nav.info.addEventListener(MouseEvent.MOUSE_DOWN, Down1, false, 0, true);
     var requester:URLRequest=new URLRequest("aboutLoader.swf");
     loader3 = null;
     loader3 = new Loader();
     loader3.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioError);
     function ioError(event:IOErrorEvent):void {
     trace(event);
     try {
     loader3.load(requester);
}      catch (error:SecurityError) {
     trace(error);
     addChild(loader3);
     loader3.x = (stage.stageWidth - 482) * .5 - 260;
     loader3.y = (stage.stageHeight - 492) * .5 - 140;
     loader.unload();
     loader2.unload();
     loader3.unload();
     // remove eventlistner and prevents duplication of info.swf
     MovieClip(root).nav.about.removeEventListener(MouseEvent.MOUSE_DOWN, Down3);
     stop();

Garbage collection of objects created inside a method

I have method and inside the method I create new Objects I mean I instantiate objects using new and call some methods on these objects.
once the method execution is completed and control goes to caller of the method will all the object created inside the method will be garbage collected ?
here with code
           public List<StgAuditGeneral> getAudits(
          List<StgAuditGeneral> audits= new ArrayList<StgAuditGeneral>();
              for(Map<String, String> result :results ){
               audits.add(new MapToObject<StgAuditGeneral>() {
                    @Override
                    public StgAuditGeneral getObject() {
                                         StgAuditGeneral stg= new StgAuditGeneral();
                         return stg;
               }.getObject());
          }in the above method I cam creating tons of objects wil they be garbage collected immediatedly after jvm leaves the method ?

user11138293 wrote:
I have method and inside the method I create new Objects I mean I instantiate objects using new and call some methods on these objects.
once the method execution is completed and control goes to caller of the method will all the object created inside the method will be garbage collected ?If there are no reachable references, to those objects, then when the method ends, they become eligible for GC. If and when they are actually collected is something we can't know or control, and generally don't care about. The only guarantee is that everything that can be collected will be collected before an OutOfMemoryError is thrown. So from our perspective, once it's eligible for collection, it is effectively collected.
If you pass references to those objects to something else that holds onto them after the method ends, then they are still reachable, and not eligible for collection.
However, you almost never need to even think about whether something is eligible for GC or not. It works pretty intuitively.

Avoiding Garbage Collection

Similar Messages

Maybe you are looking for