Re: Exception error
Thomas Pornin wrote:
It depends on the JVM implementation. For instance, it is fairly
standard for generational GC to maintain lists of generation-forward
pointers, i.e. pointers from an old to a younger generation. The simple
act of writing a reference into a field implies some handling of these
lists, which may trigger some heavy GC activity and an OutOfMemoryError.
The case in question would contain no actual bytecode of execution,
beyond a goto. No field references, therefore no chance to mess with GC.
Another possibility is that the JIT compiler may decide to switch from
interpreted to compiled code for that method precisely upon entering the
"try" block (e.g. it has reached its maximum count of interpreted
opcodes for that method); JIT compilation entails some dynamic
allocation. There are countless other possible sources of OOM.
The OpenJDK HotSpot VM appears to do JIT at method-level, which makes
the most sense to me; the only other JIT code I know about (Mozilla's
SpiderMonkey) also does at method-level.
Is OutOfMemoryError guaranteed to be called on the same thread which
made the allocation attempt?
I would be surprised -- internally, the JVM performs quite a lot of
memory-related activity, not all of which being on behalf of a specific
and well identified thread.
Reading the JLS:
If there is insufficient space to allocate the object, evaluation of the
class instance creation expression completes abruptly by throwing an
OutOfMemoryError (?15.9.6).
An (not necessarily `the', though) OutOfMemoryError therefore must be
thrown on the same thread. It could conceivably cause one to be thrown
on all threads, but the utility of this is circumspect.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth