Last week Tom Whittaker and I visited Unidata to discuss
VisAD design issues, and the issues were interesting enough
to be shared with this mailing list.
1. Tom Yoksas spotted that VisAD was using too much CPU
while idle. It turns out that some threads were calling
'wait(2000)' when they should have called 'wait()'. This
caused them to wake up every two seconds even when they
had no work to do. It has been fixed and should reduce
idle CPU usage.
2. During some spread sheet demos we noticed 'memory leak'
type behavior. Tom Whittaker reminded me that Graphics
contexts are persistent unless you explicitly call 'dispose'.
While the Java2D display code did this properly, many of the
user interface components in java/util did not. This has
been fixed.
3. Our demos showed that there are many more swing bugs if
you set up your account with non-default X Resources. This
makes sense, if you consider that Sun's debugging efforts are
driven by bug reports from users, most of whom use default X
Resources. Until Java 1.2 matures, we recommend running with
default X Resources.
4. There was a thought provoking discussion of the singleton
design pattern. A singleton is a class that only allows one
instance, for example for a print spooler.
VisAD is designed for a distributed object environment (using
Java RMI) and I believe this alters the design rules for
singletons and other design patterns.
A singleton is an example of a static variable, and I believe
that static variables that are not constant across all JVMs
(Java Virtual Machines) should be avoided (Section 6.1 of
the VisAD Developers Guide warns against them). A non-
constant static variable has the same value within each JVM
but may vary between JVMs. This seems to me an unecessary
constraint on application designs. Given the ease of
multi-threading in Java (used heavily by VisAD) it is quite
plausible that an application design may include multiple
JVMs with multiple users per JVM. It is an arbitrary
constraint that users on the same JVM must share the same
value for the non-constant static variable, while users on
different JVMs may have different values.
Static variables that are constant across all JVMs are
different. A good example is java.lang.Math.PI. Static
methods are also not a problem (although an object-oriented
design will have mostly non-static methods).
5. Banishing non-constant static variables can make life
difficult. For example, it would be nice if sampling_mode
and error_mode for mathematical operations on VisAD Data
objects could be set in a static variable that could be
accessed deep in the calling stack of mathematical operations.
However, mathematical operations may involve Data objects
from multiple JVMs and the calling stack may migrate between
JVMs so that, if sampling_mode and error_mode are static
variables, different parts of the computation would use
different values of sampling_mode and error_mode in very
unpredictable and uncontrollable ways. Thus sampling_mode
and error_mode must be arguments to VisAD mathematical
methods and are passed down the calling stack so that they
can be used consistently even when computations migrate
around the network.
In general, banishing non-constant static variables means
that such values must be instead passed as method arguments.
There are two examples in VisAD where this may be complex:
Displays and data Forms (these provide methods for moving
data between VisAD Data objects and files). In both cases
applications interact directly with only one or two classes
whose implementation involves a large number of classes. An
application can display data using just the DisplayImplJ3D
and ScalarMap classes, and an application can read a netCDF
file using just the Plain class.
One useful design convention in cases like this is for all
instances of the helper classes to have, or be able to get,
a reference to the DisplayImpl or Plain instance they are
associated with. Then the application can pass any sort of
mode variable to the DisplayImpl or Plain instance for it
to store in an instance variable, and any method of a helper
class down in the calling stack can get it from the
DisplayImpl or Plain instance. This design convention saves
the effort of passing the mode variable down the calling
stack. However, this design convention only works if access
of the DisplayImpl or Plain instance is synchronous (so that
the value of the mode variable stored as an instance in the
DisplayImpl or Plain instance cannot be changed by another
thread in the middle of an operation).
6. This raised the question of thread safeness for data
Form classes. This is a real issue, since for example the
spread sheet uses a static DefaultFamily to access files
and (I believe) each cell uses its own thread for accessing
files. I have added the synchronized keyword to the save,
add, open(String id), open(URL url) and getForms methods in
GIFForm, Vis5DForm, Plain, FitsForm and HdfeosDefault. I
have also added the synchronized keyword to the save, add,
open(String id) and open(URL url) methods in DefaultFamily.
7. I wanted to discuss these issues in a message to the
visad-list because they illustrate the ways that distributed
objects make VisAD different from previous system designs.
In the future all uses of computers will be like the web,
with users and even application programs unaware of the
existence of individual computers. Users and application
programs will just see a shared space of objects with
dynamically changing connections. Similar to the web, but
much more active.
Currently, we think of 'starting' scientific applications.
However, we don't 'start' the web - its always just there and
we 'join' it. In the future, it will be more like 'joining'
scientific application than 'starting' them. For example, an
atmospheric chemist may attach her chemistry model to a running
weather model, connect a display to visualize the coupled model,
and invite her weather modeling colleague to connect an identical
display for collaborative visualization and computational
experiments. The user interface for making these connections
might involve some sort of broswer with JavaBean visual
programming.
While we are a ways from realizing this vision, VisAD is
designed to support this vision, as network bandwidths improve
and science domain packages are developed based on VisAD (the
key designs are distributed objects via Java RMI, and a data
model applicable to virtually any numerical data).
While distributed objects and intensive use of multi-threading
pose some difficult design problems for the developers of
VisAD, I think this difficulty is justified by the vision we
are pursuing.
Cheers,
Bill
----------------------------------------------------------
Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI 53706
whibbard@xxxxxxxxxxxxx 608-263-4427 fax: 608-263-6738
http://www.ssec.wisc.edu/~billh/vis.html
"kill cross-platform Java by growing the polluted Java market"
- from an internal Microsoft planning document
