Re: FAQ, 4.1 OutOfMemoryException

[Artur Biesiadowski]

Sascha Brawer wrote:

> I was just re-reading the FAQ [1] -- what would speak against 
> pre-allocating thread-specific OutOfMemoryException objects when 
> creating a thread? (Probably more a VM-specific thing, but since it's 
> mentioned in the Classpath FAQ...)

You have basically two choices with implementing OOME. You can go 
stacktrace-less route (only throw it, do not provide entire stack trace 
with it) - then you can get away with single instance per entire jvm, as 
it has no state. Or you can try to fit stack in there - but place for it 
has to be preallocated. Memory usage can start to sum up if you will 
preallocate it for every thread out there. This looks like optimizing 
for very rare case for me and making more garbage in the heap that it is 
needed for all normal jvm runs.

I'm not sure if danger of many threads throwing OOME at the same time is 
really so big. Every sane jvm will trigger full gc before throwing OOME 
- and to have full gc going, there has to be some kind of 
synchronization on memory allocation between all threads. I suppose it 
should be possible to lock heap/gc for as long as it is needed to unwind 
stack to point where OOME is catched (if ever), perform another gc and 
only then unblock heap monitor. Of course, if somebody is 'smart' enough 
to catch OOME just after it is thrown and tries to print it out, it will 
probably produce another OOME - but it has nothing to do with multiple 
threads problem. I also think that things like people saving OOME in 
fields, producing another OOME and then using previously saved exception 
to print stack trace is not a case to worry about in general.

Artur