Infrastructure for immutable objects, in support of value types.
Such objects are created privately mutable, and then locked for publication.
See <http://blogs.oracle.com/jrose/entry/value_types_in_the_vm>
and <http://blogs.oracle.com/jrose/entry/larval_objects_in_the_vm>.
For more general background, see [Rich Hickey's talk on Values](http://www.infoq.com/presentations/Value-Values).

The term _immutable_ is a general term for certain classes of data structures.
Inside the JVM, we need a specific, positive term for an object which has been made immutable.
We could say it has been made _final_ or _frozen_, but instead will repurpose the term _locked_.
This is not a perfect choice, since immutability is only partially related to synchronization.
The term allows intuitive API names like `Arrays.lockedCopyOf` or `Objects.cloneAsLocked`.
An object which is immutable is called _permanently locked_, or (if there is no ambiguity) simply _locked_.

Rules for permanently locked objects:

- restrictions on classes of locked objects
    - all non-static fields must be final
    - there must be no finalizer method (no override to `Object.finalize`)
    - these restrictions apply to any superclasses as well
    - an array can be marked locked, but then (of course) its elements cannot be stored to
    - if not an array, the object's class must implement the marker type `PermanentlyLockable` (is this a good idea?)
- restricted operations on locked objects (could be enforced, or else documented as producing undefined results)
    - do not use any astore or putfield instructions, nor their reflective equivalents, to change any field
    - do not lock (you may get a hang or a LockedObjectException)
    - do not test for pointer equality; use Object.equals instead (there may be a test for this)
    - do not ask for an identity hash code; use Object.hashCode instead (there may be a test for this)
    - do not call wait, notify, or notifyAll methods in Object
    - at the time it is marked locked, an object's monitor must not be locked (in fact, should never have been?)
- side effects
    - elements of locked arrays are stably available to readers just like final object fields (i.e., there is a memory fence)
    - a locked object can be locked again, with no additional effect
    - any attempt to mutate a permanently locked object raises java.lang.LockedObjectException
    - any attempt to synchronize on a permanently locked object raises java.lang.LockedObjectException
- object lifecycle
    - all objects are initially created in a normal (unlocked) state
    - an object marked locked cannot be "unlocked" (reverted to a normal state)
    - an object marked locked must be unreferenced by any other thread (can we enforce this?)
    - the reference returned from the (unsafe) marking primitive must be used for all future accesses
    - any previous references (including the one passed to the marking primitive) must be unused
    - in practice, this means you must mark an object locked immediately after constructing it
- API
    - the method `lockPermanently` is used to lock an object permanently
    - there is a predicate `isLockedPermanently` which can test whether an object is locked or not
    - for initial experiments, these methods are in `sun.misc.Unsafe`; perhaps they belong on `Object` (cf. `clone`)