Earlier quoted context omitted.
I feel with companies moving to cloud environment defending Java memory bloat will be harder and harder. Java's limited value types may be out by 2020-21 or so and it will be many more years libraries ecosystem start utilizing it. So we are still at least 10 years away from some form of Java value type available for general users.
1. Memory "bloat" is always a better use of resources than increased development time, regardless of how you have to pay for it. 2. How are Java's value types limited? 3. I find your calculation extremely pessimistic. Lambda expression are widespread a couple of years after their release, and I see no reason why value types will be different. I think that 5 years are a better estimate for wide use of value types.
> Except for pointer equality checks, forbidden operations will throw some sort of exception. How to control pointer equality checks is an open question with several possible answers.
And more:
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`)`