[1399] in java-interest
Re: Performance questions
daemon@ATHENA.MIT.EDU (Tim Lindholm)
Thu Aug 31 18:17:53 1995
Date: Thu, 31 Aug 1995 12:36:49 -0700
From: lindholm@scndprsn.Eng.Sun.COM (Tim Lindholm)
To: java-interest@java.Eng.Sun.COM, sasebb@unx.sas.com
> From daemon@java Thu Aug 31 12:19:36 1995
> From: Edmund Burnette <sasebb@unx.sas.com>
> Subject: Performance questions
> To: java-interest@java
> Date: Thu, 31 Aug 1995 14:39:16 -0400 (EDT)
> Sender: owner-java-interest@java
>
> I have a few questions on the performance of current implementations
> of java:
>
> 1. How bad does array bounds checking hurt performance on critical
> routines with inner loops?
"How bad" depends on your perspective. If you're trying to get maximum
performance for intensive vector calculations, then you may not want to
use the current implementation of Java. However, if the performance of
the current implementation is perceived as generally adequate, the cost
of bounds checking is probably negligable compared to other overheads
like the interpreter's opcode decoding and dispatch.
The check does approximately what you'd expect on every load and store
to an array:
#define obj_length(o) \
(((unsigned long) (o)->methods) >> METHOD_FLAG_BITS)
...
if (index < 0 || index >= obj_length(arrh)) {
...raise an exception...
}
...
> 2. Does the memory allocation degrade over a long session?
Java's runtime uses a conservative, compacting garbage collector. The
compaction tends to reduce fragmentation and return the heap to a pristine
state. But conservativism means that it is possible to the heap to be
artificially fragmented due to unlucky values appearing in places where
we can't be sure whether the thing is a heap pointer or just an attractive
bit pattern. We don't dare relocate such values on compaction, so we
must leave the objects that are apparently referenced where they are. We
refer to those objects as "pinned" in place in the heap.
The specific pinning that occurs at a given GC is usually based on what
exactly is going on at the time of the GC, classically the contents of
the C stacks of the threads. That stuff changes over time, so an object
that must be considered pinned for a given GC run is likely to no longer
be pinned for the next one. Thus, pinning often does not cause the state
of the heap to degrade over time, although at any given moment things
may not be what we'd like. In the beta runtime the Java heap will be
expandable, so even in cases where pinning has fragmented your memory
temporarily, you can expand the heap to satisfy the immediate request
and hopefully not be pinned in the same way the next GC.
> Edmund Burnette, Portable Debugging | (919)677-8000x7772, 677-8123(Fax)
> Development, SAS Institute Inc. | sasebb@unx.sas.com (W)
> SAS Campus Drive, Cary, NC 27513 | ebb@mercury.interpath.net (H)
> ........He is Bob/Ready for Fun/He Wears a Smile/Everybody Run........
-- Tim
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
