No-throw VirtualMachineError guarantees

Question

I've come to Java from C++. In the C++ world we pay attention to exception safety, and note that mutators can provide different guarantees in the face of exceptions thrown by the mutator itself or a method it delegates to (minimum, strong, no-throw). Implementing a method that has a strong exception guarantee requires that some basic operations are guaranteed never to throw an exception. The JLS makes statements about which operations can throw which kinds of exceptions, but the VirtualMachineError error presents a problem. Quoth the JLS:

an internal error or resource limitation prevents the Java virtual machine from implementing the semantics of the Java programming language; in this case, an instance of a subclass of VirtualMachineError is thrown.

The JLS says no more about VirtualMachineError. An "internal error" means a bug in the JVM, so I'm not interested in that case: in the face of bugs in the JVM, all bets are off. But what about the "resource limitation" case? Are there any operations that are guaranteed never to fail because of a resource limitation?

The closest thing to an answer would be `try { ... } catch (Throwable t) { }`. Of course if memory is exhausted any continuation will prove to be nearly impossible. Now that is not different in C++. — Joop Eggen, Jan 04 '12 at 15:06

score 16 · Accepted Answer · edited Nov 10 '17 at 07:55

16

Quoth the Java Virtual Machine Specification:

This specification cannot predict where internal errors or resource limitations may be encountered and does not mandate precisely when they can be reported. Thus, any of the VirtualMachineError subclasses defined below may be thrown at any time during the operation of the Java virtual machine:

In Java therefore no exception guarantees can be made with respect to VirtualMachineError exceptions. All exception guarantees must be subject to the qualification "... but not if a VirtualMachineError is thrown". This is one of the ways in which Java is different from C++.

This also suggests that there is not much point in catching a VirtualMachineError exception, because the program is in an undefined state if one has been thrown. That unfortunately includes OutOfMemoryError exceptions. Unfortunate, because if one of several tasks fails because it needs too much memory we might want to continue with the other tasks.

edited Nov 10 '17 at 07:55

Matthias Braun

24,493
16
114
144

answered Jan 04 '12 at 15:05

Raedwald

40,290
35
127
207

Are you answering your own question, or just adding to it? – skaffman Jan 04 '12 at 15:06
2

I am answering my own question. – Raedwald Jan 04 '12 at 15:15
Both VirtualMachineError and OutOfMemoryError are Errors. Rather than just crash, Java throws an Error in some abnormal conditions. That said, none of the Error subclasses are intended to be caught by most programs. Errors can be distinguished from Exceptions, which may be caught. The exception guarantees promoted by Herb Sutter can be applied to Java as well, for normal Exceptions. – Andy Thomas Jan 04 '12 at 15:57
See also: http://stackoverflow.com/questions/1692230/is-it-possible-to-catch-out-of-memory-exception-in-java – Raedwald Jan 10 '12 at 12:47
See also: http://stackoverflow.com/questions/3871278/how-do-i-make-the-jvm-exit-on-any-outofmemoryexception-even-when-bad-people-try – Raedwald Jul 08 '13 at 12:56

score 1 · Answer 2 · edited May 23 '17 at 12:10

1

If it is resource limitation, on the first place, no operations takes place. Here is link for perfect example to have VirtualMachineError. Virtual machine error

This error is not something like OutofMemoryError, where by that time some operations might be in progress.

edited May 23 '17 at 12:10

Community

1
1

answered Jan 04 '12 at 15:10

kosa

63,683
12
118
157

"no operations takes place". That would be the "strong exceptino guarantee". But no such guarantee is made. – Raedwald Jan 04 '12 at 15:14
If my interpretation is correct, based on above example, before VM get initiated, it was checking for defined resources like -Xmx parameters and it couldn't find defined size of memory and throw error. I agree with your point on no guarantee made, but don't know why. – kosa Jan 04 '12 at 15:19

score 1 · Answer 3 · answered Jan 04 '12 at 15:17

1

I see that you've answered your own question and I can understand why this would be mildly surprising to you, coming from a strict C++ background. This is just the reality of managed memory (virtual) machines and it's not limited to just java. Memory can run out, as the JVM is bounded to how much heap it can use (configurable on the java command line).

Somewhat analogous, but not equivalent, in the C++/machine-code world would be a GENERAL_PROTECTION_FAULT (or SEGMENTATION_FAULT if you're on *NIX) that you would get when attempting to address memory that has not been allocated or is outside your virtual address space. Providing a "strong exception guarantee" in the face of that scenario is equally difficult as the cause may be either a bug in code or completely outside the control of the program.

answered Jan 04 '12 at 15:17

pap

25,288
6
37
46

A SEGV indicates a bug in the program. Its analogy in Java is `NullPointerException`. – Raedwald Jan 04 '12 at 15:25
I do not see how this is a general feature of a managed virtual machine. The JVMS allows `OutOfMemoryError` to be thrown even when you are not using `new` or trying to load a class. – Raedwald Jan 04 '12 at 15:27
@Raedwald you will only get a NPE when you try to reference `null`. You will only get OutOfMemoryError after you attempt to allocate more memory (or you call a method which does) and the GC has run and not enough memory is freed. – Peter Lawrey Jan 04 '12 at 15:30
1

"You will only get OutOfMemoryError after you attempt to allocate more memory" This is the intutive meaning: only *you* can cause it. But that is not what the JVMS says: the JVM may throw it any *any* time. – Raedwald Jan 04 '12 at 15:36
3

Well, we're in to semantics here. OutOfMemoryError can be thrown at any time, that is correct. One of the most common occurrences of OutOfMemoryError is the "GC overhead limit exceeded" scenario, which is thrown when the GC is consuming an inordinate amount of CPU-time due to not being able to free enough memory in each pass. What is the chicken and egg, "new" or GC? GC triggering is non-deterministic, but trying to allocate memory (via "new") is definitely a strong incentive for it to run so while "new" may not be the immediate proximal cause, of course it's the root cause. – pap Jan 04 '12 at 17:07

score 0 · Answer 4 · edited Jan 04 '12 at 15:41

0

In Java, you can call Thread.stop() or stop(Throwable) at any time. Most errors are considered so critical that you should not try to handle them unless you really know what you are doing.

Having developed server side Java application for 12 years, I can say I have never heard of anyone worrying about random exceptions being thrown. I suspect its just not an issue you need to worry about with Java.

Can you give an example of why you believe you need a guarantee, as there is likely to be another way to solve the problem?

edited Jan 04 '12 at 15:41

Andy Thomas

78,842
10
93
142

answered Jan 04 '12 at 15:19

Peter Lawrey

498,481
72
700
1,075

2

The `OutOfMemoryError` exception is the most interesting case. As I say in my own answer: Unfortunate, because if one of several tasks fails because it needs too much memory we might want to continue with the other tasks. But if the JVM can throw a `OutOfMemoryError`, we can not rely on our program being in a valid state when we catch a `OutOfMemoryError`. This makes a try-catch-discard approach unreliable. – Raedwald Jan 04 '12 at 15:39
Added missing "NOT" before "try to handle them." – Andy Thomas Jan 04 '12 at 15:41
2

@Raedwald You are right that discarding the OOME is unreliable. What you have to do is define the maximum memory at which you would expect the whole JVM to fail (not just a soft limit) and avoid performing operations which could fail because you have no idea how much memory they use. In the worse case, you need to use a separate process which can be killed re-started as required. (This also protect against bug in JNI libraries) – Peter Lawrey Jan 04 '12 at 15:44
3

@PeterLawrey That sort of strategy is quite popular with apps like Google Chrome where all the heavy lifting is done in separate processes which somehow render back into the real window. It would be nice if there were a convenient way to do that sort of thing in Java. As it stands today in most apps, the GUI is handled by the EDT running in a single process and if something GUI-side hits an OOME (e.g. you try to sort a table which is too big), all you can do is catch it and hope that it didn't break some other thread doing important stuff. – Trejkaz Apr 07 '14 at 12:40

No-throw VirtualMachineError guarantees

4 Answers4

Linked