HPC Java

Sun Feb 6 12:11:00 GMT 2005

Boehm, Hans wrote:
 >> What keeps Java (SE) from being a world-class HPC language?
 >> - No support for immortal (truly static) allocation. GC overhead
 >> considered excessive. Desirable if GC subsystem not present if all
 >> allocation is immortal.
 >> - "Allocate only" GC mode would be useful, as well as user-defined
 >> collection time. Desirable if GC subsystem cut down considerably
 >> if allocation-only mode.
 >
 >
 >
 > "Allocate only" mode more or less exists in gcj. (Set the GC_DONT_GC
 > environment variable or GC_dont_gc C variable. Not typically
recommended!)
Given that one can do user-defined collection as described below, I
suppose that is a better option in general. A mode where all memory is
statically (immortally) allocated, eliminating all the GC code from the
runtime, seems useful for some applications though.
 > User-defined collection times are also easy, though the general wisdom
 > in other domains is that users generally end up doing worse than the
 > system would have, especially given the simplistic System.gc()
 > interface, and the fact that there may be system threads running and
 > potentially allocating in the background.
I'd hope the "system threads running and allocating in the background"
can be eliminated for large classes of systems. An example of an
application where user-defined collection is necessary and desirable is
any interactive graphics application (such as flight simulation) where a
constant frame rate is desired. During the simulation factory patterns
or object pools can be used to recycle objects without any
allocation/deallocation overhead, or framerate-destroying GC pauses.
Once the interactive portion of the program is over (say after landing),
the user can be presented with a summary screen while GC happens if
necessary.
 > But I'm not sure that any of this addresses the real issue. The case
 > in which all memory is live until process exit is easy. It's also
 > unlikely, thanks to standard libraries that allocate and drop objects,
 > if nothing else. The harder issue is that programs which alternately
 > allocate and drop huge arrays inherently don't perform well with a GC,
 > especially if there is other stuff in the heap. You have to
 > garbage-collect frequently to collect those huge dead arrays because
 > you can't afford to keep them lying around. Explicit deallocation
 > would have been much cheaper in this case.
Once again a recycling approach seems more appropriate, though it might
not be easy with Java. One could pre-allocate a few hundred MB of double
array space for instance, and then provide a factory object that manages
that memory. Manual memory management, yes, but it avoids the problem
you're describing for hand-tuned scientific apps. One of the things that
concerned me about GC and scientific applications is that I'd read
sometime ago that the rule of thumb was to have two times the memory
available to the GC than the application was actually going to use (this
may be obsolete information at this point - I'd appreciate your view on
it). That seemed excessive in terms of "grande" applications that would
like to monopolize the entire resources of a supercomputer.
 > If this is really a critical issue, you might be able to provide some
 > sort of "explicitly managed array of double" data type, which at least
 > preserves type-safety in the presence of premature deallocations. You
 > should already be able to implement that in pure Java, though probably
 > not with acceptable performance.
Yes, one wonders if CNI (or even more efficient straight C bindings
mentioned on the list a few months ago) might be a better solution for gcj.
I appreciate your response, and all the work you and other gcj
contributers put in. I'd like to contribute, and will be evaluating how
I might best do that in the near term. I would have responded sooner,
but I spent quite a bit of time catching up with this mailing list over
the last couple of days (about 1500 total messages I'd skipped earlier).
I'll compose a message tomorrow with some thoughts gleaned from that
reading... Also I have some benchmark results coming in a followup soon.
Terry