OutOfMemoryError cannot be caught

Question

There's a bug open on this (ID 4697804) but I thought I'd advertise it more widely because I've only just discovered it (at the worst possible time) and it's taken me completely by surprise; I'm stuck now as to what I'm meant to do.
The issue is that the OutOfMemoryError thrown when the VM cannot allocate space for an object cannot always be caught by the application. In fact, the comments on the bug report suggest that the error is never actually thrown in these circumstances: the VM is corrupt by that stage and unable to continue executing Java code, so it prints a message on the console as if the error had been thrown and then exits, leaving the application with no possibility of recovery.
This is depressingly easy to reproduce. I added this example to the bug report but it's small enough to be worth repeating here:
import java.util.*;
public class Bug4697804 {
    public static void main(String[] args) {
        try {
            create(2, 1024);
        catch (OutOfMemoryError err) {
            System.err.println("OutOfMemoryError - OK");
    private static Object create(int d, int n) {
        List x = new ArrayList(n);
        if (d > 0) {
            for (int i = 0; i < n; ++i) {
                x.add(create(d-1, n));
        return x;
}I'm using J2SE 1.4.0 on Windows 2000, but I don't think this is platform-specific. If you run the example with the default heap settings it's almost certain to work as expected:
java Bug4697804OutOfMemoryError - OKBut if, in anticipation of a larger memory requirement, you increase the maximum heap size and choose a number which is more than your machine can handle, you're in trouble:
java -Xmx512m Bug4697804Exception java.lang.OutOfMemoryError: requested 4112 bytesPicking a safe value for -Xmx is impossible. What matters is the amount of free memory available at the point where the VM tries to expand the heap, and that varies unpredictably depending on what else is running at the time. So when you start Java -- and that's the only opportunity you get to choose the heap size -- there may be lots of memory free, but by the time the VM comes to need that space it may have been consumed entirely by other applications. Even the default settings won't save you if your machine is heavily loaded.
The only strategy I can come up with to beat this bug is to pre-allocate a fixed-size heap by setting -Xms the same as -Xmx. This is a horrible thing to do because you're bound either to set the size too small and so limit the application's capacity even when there's plenty of free memory, or set it too large and waste the space, starving other applications instead. Also, I can't be certain there aren't other circumstances which will provoke the same behaviour.
I've looked at a lot of discussions in these forums about out of memory errors. Many correctly steer people towards the -Xmx option (which may not be such a good idea as it turns out). But in some there's a suggestion that an OutOfMemoryError is bound to indicate a problem with the program, that it's out of control in some sense, and that you can't expect to handle and recover from such an error. I think that's entirely wrong, in general, and I hope it's not a view which informs the way in which the VM treats its storage allocation.
In an end-user application with any degree of complexity, memory usage is ultimately determined by what users choose to do: how many objects they create and how complex they choose to make them. Placing any kind of limit on that is artificial and unnecessary. I'd expect any language runtime to continue allocating memory for as long as the operating system allows and then fail predictably when memory is exhausted. Granted, the operation in progress at the time is bound to be fatally compromised, but rudimentary programming safeguards can protect data that's been computed up to that point. As long as the application can handle the event and continue, there's hope of salvaging something. To exit without warning is unforgivable.
Anyway, since available memory is determined as much by what other applications do as by your own, even careful programming can't protect you from this problem. In low-memory situations, any API you ever call, if it happens to create objects, may terminate the VM. That's not a nice thought, really.

Answer 1

Okay, so what can we do about it?
In the app I'm writing, the user can get a bunch of data from the database, which is displayed in JTables. When a request for data is made, the client spawns a thread to talk to the server and get the data. If this thread runs out of memory, I'd like it to stop, dump everything it has, and report back to the user that the search was too large, please restrict it somehow.
Of course, I can always limit the search to N records, but this is overly restrictive. I have no idea how much RAM the user has on their client box, and some records are much larger than others anyway. As you said, this solution is unscalable and unacceptable.
In the thread's run() method, I catch OutOfMemoryError but it never seems to get here. It just prints "OutOfMemoryError" on the console and it's hosed. The user is left hung with an hourglass pointer forever. Is this console output coming from the crashed VM?
What can I do?
Thanks! --- Eric