swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SwarmObject, MessageProbe and memory usage in Java


From: Marshall, James A R
Subject: SwarmObject, MessageProbe and memory usage in Java
Date: Tue, 24 Sep 2002 16:33:17 +0100

Hi,
  I've done some more investigation after my last posting ("RE: MessageProbe
interferes with Java garbage collection in pretest 6?"). Sorry to keep going
on about this but I think the results are interesting...
  Attached is a graph of memory consumption during and after execution of a
test program, below (sorry, I don't currently have any temporary web-space
to put this on). The program creates a list of objects, calls a method on
them, whether directly or through a MessageProbe, then attempts to free them
up for recycling by Java's garbage collector. Various permutations of the
program exist based on whether:
1. the objects created in the list extend SwarmObjectImpl or not
2. a MessageProbe is used to call the method of the objects in the list or
not
3. the drop method is called on the objects when they are no longer needed
or not
  These permutations can be recreated by changing the #defines in the code
below as appropriate, then running it through cpp before compilation. The
following permutations weren't tested:
1. no inheritance, probe, drop (can't call drop function as it hasn't been
inherited from SwarmObjectImpl)
2. no inheritance, no probe, drop (see above)
3. no probe, drop (crashes when calling drop)
  The results attached show memory consumed once all objects are created,
memory consumed once an attempt has been made to free all objects, and
whether or not the finalize method of the objects was called (should be
called by the Java garbage collector just before the object is recycled).
The most interesting results in my opinion are:
1. "no probe, no drop" appears to use additional memory rather than freeing
any up, despite the finalize method of all the objects being called?
2. "probe, drop", where the finalize method of the objects is called, is
less efficient at recycling than the equivalent case "probe, no drop" where
the finalize method isn't called
3. "no inheritance, probe" gives the best memory consumption during
execution and best memory recycling, despite (or because of) finalize not
being called on any of the objects
  (3) is the most important conclusion for me, and I've confirmed it by
applying it to my current simulation project, which was suffering from bad
memory leaks due to my use of probes.
  Unless I've made some elementary mistakes that I have overlooked, or this
has all been a bad dream, I think these results are correct, and hope they
will be useful for anyone else using MessageProbes extensively in Java. I
have to say that Java Swarm's behaviour in this area seems counter-intuitive
though, and an understanding of what's going on could be useful...
        James

 <<swarm_mem_usage.ps.gz>> 
import java.util.LinkedList;
import java.util.Iterator;
import swarm.objectbase.MessageProbe;
import swarm.objectbase.ProbeMap;
import swarm.objectbase.SwarmObject;
import swarm.objectbase.SwarmObjectImpl;
import swarm.Globals;

#define INHERITANCE
#define PROBE
#define DROP

#ifdef INHERITANCE
class Test extends SwarmObjectImpl
#else
class Test
#endif
{
        int mValue;

        public int getValue()
        {
                return mValue;
        }

        public Test(int value)
        {
                mValue = value;
        }

        public void finalize()
        {
                System.out.println("finalised" + mValue);
        }
}

class ITM
{
        public static void main(String args[])
        {
                LinkedList list;
                Iterator i;
                Test test = null;
                MessageProbe probe = null;
                ProbeMap probeMap = null;
                SwarmObject swarmObject;
                int l1 = 0, l2, value;
                long startMem;

                Globals.env.initSwarm("test", "0.0",
"address@hidden", args);
                Runtime.getRuntime().gc();
                startMem = Runtime.getRuntime().freeMemory();
                list = new LinkedList();
                for (l2 = 0; l2 < 100; l2++)
                {
                        test = new Test(l1 * 10 + l2);
#ifdef PROBE
                        if (probeMap == null)
                        {
                                probeMap =
Globals.env.probeLibrary.getCompleteProbeMapForObject(test);
                                probe =
probeMap.getProbeForMessage("getValue");
                        }
                        value = probe.longDynamicCallOn(test);
#endif
                        value = test.getValue();
                        list.addFirst(test);
                }
                System.out.println("Used memory: " + (startMem -
Runtime.getRuntime().freeMemory()));
                i = list.iterator();
                while (i.hasNext())
                {
#ifdef DROP
                        swarmObject = (SwarmObject) i.next();
#else
                        i.next();
#endif
                        i.remove();
#ifdef DROP
                        swarmObject.drop();
#endif
                }
                Runtime.getRuntime().gc();
                System.out.println("Used memory: " + (startMem -
Runtime.getRuntime().freeMemory()));
        }
}

---
Dr James A R Marshall
Container World Project - http://www.ese.ic.ac.uk/research/containerworld/
Department of Earth Sciences and Engineering, Imperial College, London
Tel: +44 (0)20 7594 7493
Fax: +44 (0)20 7594 7444


Attachment: swarm_mem_usage.ps.gz
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]