RE: [Swarm-Support] Time efficiency of at$createActionTo$message

[Marshall, James A R]

You really need to drop Selectors? The Swarm Javadocs show Selector
inheriting directly from java.lang.Object and not implementing drop itself.
If I compile the following code then an error is raised for the method drop:

Selector selector;
selector = new Selector(this.getClass(), "processEvents", false);
selector.drop();

So how do you drop Selectors?
Also the fact that the slowdown occurs even when the model is running well
within the allocated heap size makes me think that a memory leak isn't the
root of the problem.
I was worried I'd done something exceptionally stupid for a while though!
Maybe I have but I'm not sure this is it...
  Cheers,
        James

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



-----Original Message-----
From: Marcus G. Daniels [mailto:address@hidden
Sent: 18 February 2003 18:50
To: address@hidden
Subject: Re: [Swarm-Support] Time efficiency of
at$createActionTo$message


Marshall, James A R wrote:

>  is randomisation also an issue for inserting single actions into a
>schedule? I'm inserting actions singly into a schedule using the following
>code:
>
>mSchedule.at$createActionTo$message(day, SuperDelegate.getInstance(), new
>Selector(SuperDelegate.getInstance().getClass(), "deliverShipmentToPort",
>false), shipment);
>
>The thing is as the model progresses the argument day becomes progressively
>larger. 
>
If this scheduling happens again and again, you'll be leaking Selectors 
like crazy.
Java/Swarm objects are live until dropped (they have objects on the C 
side that are pinned-down, and the garbage collector can't touch them).



_______________________________________________
Support mailing list
address@hidden
http://www.swarm.org/mailman/listinfo/support