At 10:12 AM 5/16/00 -0400, Dalton Calford wrote:

>JVM's are bloatware depending on the version.

This assertion has been made a number of times on this list, but I
have yet to see any analysis other than anecdotal musing.

A Java Virtual Machine allocates memory for the following:

1. Data structures to hold parsed class file information
(including link resolution).
2. A Java stack for each thread.
3. Memory for each Java object.
4. Memory to support complex "native" functions such
as AWT (which would not be present in an embedded
JVM).

Every object allocated in Java is the result of an explicit "new"
operator. Nothing in Java allocates objects automatically. The
memory usage of Java, like many languages, is a function of the
programmer, not the language.

The major difference between Java and C++ is object lifetime. In
C++, it is the programmer's responsibility to release memory when
it is no longer needed. If he fails to do so, there is a memory
leak. Java uses periodic garbage collection to release unreferenced
objects. Conceptually (at least) the garbage collector walks all
thread stacks and class variables recursively marking objects as
active, then performs a linear sweep of the object space to release
inactive objects for reuse. It is impossible to leak memory in
Java. A bad programmer can go out of his way to make class variables
that point to unneeded objects, but that's about it.

A Java object typically has a 20 byte overhead (16 for arrays)
compared with a 4 byte overhead for internal engine objects,
though Java objects have synchronization primitives built in. In
the future we will probably replace the 16 bit length field in the
internal block header with a 32 bit value to make Ann happy.

Although both the blr engine are interpreters, the granuality
is different. Blr requires are compiled into object trees before
interpretation, so the overhead compared with generated code is
actually quite small. A Java byte code interpreter incurs from 3:1
to 4:1 inefficiency. This can be eliminated with a Just in Time
compiler at the cost of complexity and portability (JIT compilers
are necessarily platform specific).



Jim Starkey