Re: Commentary on Industry Move to C++

[James Rogers <jimmaureenrogers@worldnet.att.net>]

Al Christians wrote:
> 
> James Rogers wrote:
> >
> >
> > I assume Sun has some reasons for insisting you know not to use Java
> > for these purposes.
> >
> 
> They say it's because of timing -- ie because of garbage collection
> -- they can't make it a sure thing that it will accomplish anything
> in a given amount of time.  But they also say that it's not an
> admission that it's likely to crash or give the wrong answers.
> 
> That's really a JVM issue, not a Java issue -- there are many
> languages running on JVM these days.

Timing is a JVM issue. It is also a Java issue.

My experience is that the Java language in general, and Java standard
API classes in particular, are relatively inefficient. Java
static data members are allocated on a stack. All other Java non
primitive data items are allocated dynamically. 

Aside from the fact that additional overhead is involved in
marking and deallocating dynamic memory, the most common Java
programming models allocate a lot of memory when other languages
like Ada, C, Basic, Pascal, etc will not need to allocate memory.
This addiction to allocation produces performance problems that
affect both timing and memory utilization.

For instance, using a Java collection, such as a HashMap to store
values associated with unique keys requires that all items stored
must be instances of classes, not primitive types. How, then, do
you store numeric types in a HashMap? Simple. You convert the
numeric type to its corresponding wrapper class.

The primary reason to use a HashMap is for rapid access to the
values contained therein. If you want to total values read from
an input stream by key value you will need to increment the values
stored in the HashMap. Unfortunately, the numeric wrapper classes
are incapable of performing math operations. You must convert the
wrapper class object to a primitive type, perform the 
calculations, then create a new numeric wrapper object and put it
in the HashMap under the same key. All this conversion, allocation,
and reassignment is expensive. Timing is affected greatly.

(Of course, each of those objects must be eventually deallocated
or "collected" by the GC, which even if it were deterministic would
still have a serious affect on timing.)

Java also demonstrates plenty of unpredictability with its thread
model. Releasing a thread from a "wait" call is accomplished by
having another thread call the "notify" or the "notifyAll"
method. The "notify" method causes the virtual machine to release
one thread from the wait state. There is no sense of a queue in
the "wait" state corresponding to an Ada entry queue. You have no
way of knowing which thread will be affected by a "notify" 
call. It may be one that must immediately return to the "wait"
state because its boundary condition has not been satisfied. If
so, then you can encounter a deadlock because the expected
thread was not activated.

The common wisdom is that one should never use "notify". Instead,
one should always use "notifyAll". "notifyAll" releases all
threads from the "wait" state. This avoids deadlock, because one
of the waiting threads will discover a satisfied boundary
condition and continue. All other threads will have to return to
the "wait" state. This approach avoids deadlocks but produces
timing variations, depending on the number of threads in the
"wait" state. Java provides no remedy for this timing issue.

Jim Rogers
Colorado Springs, Colorado USA