The SoftReferences approach works, but I had to refine it a bit: I
allocate a 5 megabyte chunk of memory, stick it in a SoftReference, and
then I monitor the ReferenceQueue to see when the chunk is deleted; at
that point, I enter a loop where I repeatedly check
Runtime.freeMemory() + RunTime.maxMemory() - RunTime.totalMemory() to
see whether it is safe to re-allocate the chunk (I consider it safe
when 10 megabytes is available).
Further, when the 5 MB chunk is deleted *and* there is insufficient
memory to re-allocate it immediately, the memory monitoring thread
pauses all active table-loading threads, and of course presents a
warning to the user.
Once enough free memory is available, start the whole process from the
beginning.

N.B. For reasons beyond the scope of this discussion, I have to load
entire tables at once; using more memory-efficient alternatives such as
scrollable result sets is not an option at this point. Fortunately, the
app already supports pausing and re-starting long table loads, so
suspending such loads programmatically in low-memory situations is easy
to implement and fits nicely within the existing design.

It should be noted that the JVM will clear SoftReferences even when it
doesn't have to. I noticed my 5 MB chunk getting cleared while my
program was trying to allocate 1 MB, with more than 15 MB of free
memory still being available. So, the SoftReference approach is better
than constantly polling free memory, but the fact that the reference is
cleared is *not* a reliable indication that memory is low. (Of course
as long as the reference is *not* cleared, that *is* a reliable
indication that memory is not low, and that's something.)
(All this probably depends on exactly which JVM you're using; I use
Sun's JDK 1.5.0_05 on Linux and Windows 2000 & XP).

So far my implementation of the SoftReference approach seems robust,
and I'm pretty happy with it. The Macintosh approach I mentioned in my
original post would still be preferable IMHO (but sadly Java does not
support this directly). I'm puzzled why Steve calls it "dubious"; I
would rather call it "perfect" because it provides a *reliable* way of
receiving advance warning that memory is running low -- and with zero
computational overhead. Of course it will only protect you as long as
you're trying to allocate memory in chunks that are smaller than the
"reserve" chunk, but in the case of my old Mac application, that was no
problem; I made the reserve 64kB, and in the one or two places where
memory was allocated in larger chunks, I just made sure to explicitly
check for allocation failures.

- Thomas