[Biojava-l] Java Resource Management [a semi troll...]

[Phillip Lord]

>>>>> "Ewan" == Ewan Birney <birney at ebi.ac.uk> writes:

  Ewan> On Mon, 10 Feb 2003, Bill Torcaso wrote:

  >> Ewan,
  >>
  >> As an old-time C programmer who never learned C++ but is very
  >> happy with Java, I have a question about your comment, "my
  >> algorithms try to use all the memory of the machine".  What do
  >> you do about malloc() and free()?  It seems to me that the most
  >> significant part of the "contract" between elements in a C
  >> program is the discipline regarding the calls to free(), and the
  >> best-written programs have clear and sensible rules about when
  >> that happens.  It is an essential part of writing a component to
  >> be used by someone other than the author/team that created it.

  Ewan> Often my programs will probe the machine (harder than you
  Ewan> think) or by provided by the user with a memory size. The
  Ewan> algorithm will then use all the memory (via malloc).


  Ewan> I agree with you that for people who are used to it, C
  Ewan> malloc/free is not so bad (in particular when valgrind is
  Ewan> around...) but I have to admit that garbage collection is
  Ewan> generally a good thing. What I don't like is unnecessary
  Ewan> hidden overhead in libraries/and or runtime.


  Ewan> But... I am clearly very comfortable in C, and not in Java,
  Ewan> so... just interested to hear how people handle the version
  Ewan> churn and memory aspects of JVMs

There isn't a really good way. At one stage there was a method which
allowed you to probe the memory usage of the JVM, and get back a flag
(green, orange, or red), so that you knew how much memory you had to
play with. It got removed before a full release, because of technical
issues, probably because GC algorithm makes it very hard to predict
this. 

I've tried producing memory sensitive caches, using SoftReferences. I
did this for a program that loaded a lot of images, and I wanted to
cache them in memory, but GC them before the JVM blew up. This worked
quite well in 1.2 days. But then hotspot came along, and its
generational GC was so efficient, that the images got GC'd straight
away (actually this produced a really pretty effect on screen, with
images blinking on as they got loaded, and then off again as they got
GC'd. I solved the problem by holding hard references to those images
on screen). 

In short, using all the memory you possibly can, but without actually
crashing the JVM is fairly hard in Java. Or, if I am more honest, I
never found a good way of doing it. Perhaps someone else has.

Cheers

Phil