Re: ||ism

[Nelson Minar]

Every once in awhile the "should Swarm be in Java" question comes
around. It's an anachronistic question because Swarm predates Java's
public release. But it's still interesting.

A major argument *for* Java for simulation software is its built-in
thread support. Basically, it's pretty cool to have synchronization
built right into the language. I would love to see some Java code that
writes a simulation with a one-thread-per-object paradigm. It's what
we always wanted to do with Swarm. To a certain extent, the scheduler
Roger wrote is an approximation of that. I'm sure he'll disagree with
me now that I said that :-)

But there are two big problems with Java's thread model. One is the
specification of thread priority and interoperation. The priority
scheme is completely broken. It's also not specified how the processor
will execute two threads with the same priority. You aren't even
guarateed thread-preemption, a mess of code for threads to yield
control of the CPU. I think it'd be pretty hard to write a threaded
discrete event program in Java with the amount of model control that
Swarm gives you.

The other problem is that most of the thread implementations in Java
Virtual Machines currently stink. I don't think there's a JVM out
there that will make use of symmetric multiprocessing on a machine.
Most JVMs don't use kernel-native threads. The situation is slowly
improving but it's not there yet.


Still, the promise of threads inside the language is powerful, as is
the paradigm of one thread-per-object. If anyone knows of simulation
systems that make use of these features, it'd be interesting to hear.


                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================