On Mar 15, 2011, at 6:16 PM, Yang, Ming wrote:

> After some thought and a limited number of tests, I have decided to  
> use a similar approach to yours (I have found the true dynamic agent  
> creation seems to be slow and the operation of the agent creations  
> affects the other agents quite a bit. ) . What I have done is to use  
> two data collections to hold agents. At start, I produce more than  
> enough agents and put them in the “outside collection” and when I  
> need to “create” agents, instead of creating them on the fly, I just  
> move the agent from “outside collection” to the “inside collection”  
> and when an inside agent needs to be removed, I just do the opposite  
> and the agent again is ready to be  recycled “recreated” again.
> I think it should be computationally more efficient to have two data  
> collections because we only need to check  the “inside agent  
> collection” when network is called for.

Ming, what you're doing is generally known as creating an Object  
Pool.  Object pools dated at least since early in Lisp code back when  
it was expensive to allocate objects and perform garbage collection.   
Nowadays allocation and garbage collection is fast, so object pools  
are not used as much.

In MASON the primary costs for making an object would be (1) Java's  
object allocator, which is exceptionally fast (2) your constructor  
code (3) MASON's code for scheduling the object, which is O(lg n) so  
pretty fast (4) Java's garbage collector.  Of these four, you can  
check to see if the garbage collector is collecting too often -- just  
run as

	java -verbose:gc ...

You can increase the Java heap space and see if that helps things.  To  
push it to 500 megs (for example) you can do:

	java -Xmx500M -Xms500M ...

If it's not the GC then perhaps you've got complicated constructor  
code which isn't getting called if you just pull the object out of the  
pool?  You may want to double-check that.

At any rate if you go the object pool route, I strongly suggest that  
you store your agents with weak references or using a WeakHashMap:

	http://download.oracle.com/javase/6/docs/api/java/lang/ref/WeakReference.html
	http://download.oracle.com/javase/1.4.2/docs/api/java/util/WeakHashMap.html

That way if you get low on memory Java can reach into your object pool  
and deallocate objects as necessary.

Sean