[news.eclipse.platform.swt] Re: OutOfMemoryError on event-handling threa

[Ed Merks <merks@xxxxxxxxxx>]

David,

Comments below.

David Huebel wrote:

Ed Merks wrote:
  

David,

If the heap is out of memory, even constructing a new string to display
a message is likely to fail.  
    

Agreed; a properly-written handler would not allocate heap objects. 
  

Or, as suggested in the other post, you could allocate a bunch of storage up front as a reserve.  You might even release it so that your JVM could hobble along.

However, I have seen my Eclipse application pop up an error dialog
saying, "OutOfMemoryError:  Java heap space".  Surely the JVM must have
allocated some heap memory to accomplish that?  And I have (several times
at least) seen that OOMEs thrown and handled by Jobs, after which the
application continued to function normally.   
  

If suppose if a job is doing something and terminates that the memory that being used might well be collectible.

Running out of space in which to create 
new objects is definitely a sign of a JVM in its death throws.  
    

I think all it means is that a heap allocation operation failed. 

Yes, of course.

 If it is
possible to make some objects collectable without doing more heap
allocation, then the JVM should continue operating normally.
  

Indeed.  Though something is likely to have failed miserably and might have left things in not a great state. 

Sure 
someone could have requested 1/2 Gig of memory and failed (how likely is
that)
    

A slightly less exaggerated number is pretty likely in my case.  My users
typically have 2-4GB RAM, I set the JVM to use 1G of heap space.  A JVM can
evidently be quite "healthy" with just a few tens of megabytes of free
heap, which is small potatoes compared to the size of some of the datasets
my users want to look at.

Yes, and you could set that aside up front.

  I do allocate large arrays to hold the data --
though presumably most of the allocation done by SWT/JFace on the
event-handling thread to render my tables is of small objects.  
  

Typically you have lots of small objects and not so many really big ones.

, but hey could have ask for a 10 byte string and failed too (far 
more likely), so all bets are off once the heap is exhausted...
    

If an exception is thrown on the event-handling thread, I guess it would
likely be for a small object. 

Who knows.  An editor opening a really big file might well allocate some large arrays...

 Ideally, if some kind of error (such as on
OOME) prevented a table from being rendered, the objects that were
allocated for that purpose would remain in a collectable state. 

That depends on how the rest of the system is handling the failure.  Should an editor failing to open dispose itself and does it?

 I.e., a
Table couldn't be put in a state where it references objects that it isn't
using.  Much much easier said than done, of course, but odds are that at
least *some* heap objects would be referenced only from the stack, meaning
that by the time the OOME is caught, the garbage collector can free some
objects and relieve the heap pressure. 

If it's important to fail more gracefully, it's best to tip the odd in your favor rather than to rely on them hopefully being that way.

 Plus, if I can run a handler, I can
turn the most recently loaded dataset into garbage, which should free up
plenty of memory.
  

Yes, assuming that you have control of what's likely to fail.  But there's always the straw that breaks the camel's back, and it could be  a small straw.

I'm getting the sense that the answer to my question:

  

In any case, I still want to know what the SWT event-handling thread
      

does
  

with an OutOfMemoryError.
      

is that the behavior is unspecified.
  

I know exceptions that percolate outside of the event loop bring up a message box and I know stack overflow exceptions suggest that the process be shutdown (which I sometimes ignore when debugging).  It suppose it's also possible to detect impending heap exhaustion, so you might produce a warning up earlier or avoid taken an action likely to exhaust the heap (editing a large data set)...

- David