[e-lang] Non-local Exits vs Defensive Consistency - Tyler Close

[Mark Miller]

---------- Forwarded message ----------
From: Close, Tyler J. <tyler.close at hp.com>
Date: Jan 26, 2007 3:54 PM
Subject: VirtualMachineError


At the Friday morning cap meeting today we spent a lot of time thinking
about programming for defensive consistency in Joe-E, in the presence of
VirtualMachineError. The conclusion was that it's not feasible with the
current Joe-E rules, and some form of amendment is needed.

Any allocation could cause a java.lang.OutOfMemoryError. Memory
allocations happen frequently in Java and often implicitly, either due
to Java syntax, or predefined APIs, like java.lang.reflect.Proxy which
allocates an array for the invocation arguments. When such an error
occurs, the right thing to do is to abort the current transaction
entirely. Unfortunately, we don't have a convenient way of expressing
this logic if our caller can catch a VirtualMachineError. By catching
such a VirtualMachineError, the caller could trap the callee in an
inconsistent state. For example:

    this.a = ...    // Initial update step
    new Object()    // OutOfMemoryError
    this.b = ...    // Final update step not done

In some cases, it might not be possible to structure the code such that
all allocations happen before all variable updates. Even if it were
possible, it would be awfully error prone.

We went through a bunch of proposals for fixing this before deciding
that the best thing to do is forbid catching of a VirtualMachineError,
and forbid finally clauses (since they can result in a
VirtualMachineError being silently dropped). We found coding idioms to
replace the common uses of finally clauses, so that although extreme,
this loss is survivable.

The finally clause could be added back to Joe-E if MarkM's JSR
suggestion for adding a Keeper API to Java goes through.

MarkM and I really think this is a necessary change to Joe-E. What do
you guys think?

Tyler