From daniel.smith at oracle.com  Wed Sep  6 15:10:12 2023
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 6 Sep 2023 15:10:12 +0000
Subject: EG meeting *canceled* 2023-09-06
Message-ID: <275C2258-F2D9-438D-8F81-4951620CF161@oracle.com>

No new email traffic, so we'll cancel today's meeting.

We've been working on some details regarding <init> methods internally at Oracle, should have a solid plan to discuss next time.

From daniel.smith at oracle.com  Wed Sep 20 00:24:38 2023
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 20 Sep 2023 00:24:38 +0000
Subject: Rules for larval value object construction
Message-ID: <FE9AB715-5099-4B31-8EF4-BD66DC866D45@oracle.com>

We've spent some time investigating the idea of larval value object construction, and are enthusiastic about this change. Here are some details.

1) In the JVM, we no longer need the <vnew> special methods or the 'aconst_init' and 'withfield' instructions. Drop them.

2) Value objects are constructed just like identity objects, via field mutation. However, the "object" being mutated is in a larval state and we want to give implementations a lot of flexibility in how these larval objects are implemented. Thus, the language and JVM must ensure that a larval object is never observable?it can be written to but not read.

3) New language concept/modifier: a 'regulated' constructor. (Trying a name out here, haven't put a ton of thought into naming. Feel free to bikeshed.) The 'regulated' keyword can be applied to any constructor in any class.

4) A 'regulated' constructor promises not to make any use of 'this'. An error occurs if this promise is violated in any of a number of different ways: direct reference, instance field access (except for assignment targets), instance method invocation, implicit use as an enclosing instance, any of these occurring in an initializer expression/block, and, importantly, a 'super()' or 'this()' call to a different non-regulated constructor. These checks are very similar to the longstanding rules for "pre-construction contexts" clarified by JEP 447.

5) The no-arg constructor of 'Object' is 'regulated'. The default constructor of any other class (the one you get if you declare no constructor) is implicitly 'regulated' if the superclass's no-arg constructor is 'regulated'. (A slight incompatibility here that I think we can tolerate: if you have an implicit constructor but also an initializer that depends on 'this', an error occurs.)

6) Every constructor of a value class is implicitly 'regulated'. (Similar to the rule that says every instance field of a value class is 'final'.)

7) In the class file, there's an ACC_REGULATED flag for methods, only allowed to be applied to <init> methods.

8) At class loading, an ACC_VALUE class requires that its constructors all be ACC_REGULATED.

9) Verification ensures that 'this' is never read from or passed out of an ACC_REGULATED <init> method. Specifically, in such a method, the type of 'this' is 'uninitializedThis' even after the invokespecial super/this call. Verification also ensures that the target of an invokespecial super/this call is ACC_REGULATED. (See detailed rules below.)

10) The point at which control returns to a invokespecial of an <init> method that *doesn't* represent a super/this call is the point at which a larval object becomes promoted to a "real" value object and the verification type can be 'LValueClass;'. No spec changes here, other than conveying that concept.

-----

Some benefits of this approach:
- Garbage collecting special new opcodes and the <vnew> methods, a big simplification
- Full binary compatibility when a class is refactored from identity to new, or vice versa
- (I think) ability to translate an identity class to a value class by simply flipping a flag bit
- Surfacing of a useful general-purpose concept: constructors that can be counted on not to leak 'this'
- Fewer restrictions on value objects' superclass constructors: allow code, access control, and checked exceptions
- Support for instance fields in superclasses of value objects (!)*

(*We can logically allow for superclass fields, anyway. It's possible we'll decide there are implementation constraints that prevent implementing this immediately.)

One risk is that ACC_REGULATED methods must not be instrumented in ways that make use of 'this'. This restriction applies to the constructor of Object. What are the chances this breaks somebody's tooling?

-----

Suggested verification rule revisions:

rewrittenUninitializedType(uninitializedThis, Environment, MethodClass, **Descriptor,** MethodClass) :-
	MethodClass = class(MethodClassName, CurrentLoader),
	thisClass(Environment, MethodClass),
	**Environment = (_, CurrentMethod, _, _, _, _),**
	**\+ isRegulated(CurrentMethod).**

rewrittenUninitializedType(uninitializedThis, Environment, MethodClass, **Descriptor,** uninitializedThis) :-
	MethodClass = class(MethodClassName, CurrentLoader),
	thisClass(Environment, MethodClass),
	**Environment = (_, CurrentMethod, _, _, _, _),**
	**isRegulated(CurrentMethod),**
	**isRegulatedTarget(MethodClass, Descriptor).**

rewrittenUninitializedType(uninitializedThis, Environment, MethodClass, **Descriptor,** MethodClass) :-
	MethodClass = class(MethodClassName, CurrentLoader),
	thisClass(Environment, class(thisClassName, thisLoader)),
	superclassChain(thisClassName, thisLoader, [MethodClass | Rest]),
	**Environment = (_, CurrentMethod, _, _, _, _),**
	**\+ isRegulated(CurrentMethod).**

rewrittenUninitializedType(uninitializedThis, Environment, MethodClass, **Descriptor,** uninitializedThis) :-
	MethodClass = class(MethodClassName, CurrentLoader),
	thisClass(Environment, class(thisClassName, thisLoader)),
	superclassChain(thisClassName, thisLoader, [MethodClass | Rest]),
	**Environment = (_, CurrentMethod, _, _, _, _),**
	**isRegulated(CurrentMethod),**
	**isRegulatedTarget(MethodClass, Descriptor).**

**isRegulatedTarget(MethodClass, Descriptor) :-**
	**declaredMethod(MethodClass, '<init>', Descriptor, TargetMethod),**
	**isRegulated(TargetMethod).**

**isRegulatedTarget(MethodClass, Descriptor) :-**
	**\+ declaredMethod(MethodClass, '<init>', Descriptor, TargetMethod).**
	// target method is missing, verification can proceed but resolution will cause NSME

-----

Some observations made from a corpus analysis of constructor declarations:

- About ? of abstract classes are stateless, and almost 80% of these have implicit constructors, so could be automatically converted to get a 'regulated' constructor (conditional on the superclass becoming 'regulated' as well). Almost all of the remaining 20% could be made 'regulated' by applying a keyword?'this' dependency is very rare (<0.3% of value candidates, rarer in other cases).

- Among the stateful abstract classes, most are mutable, but 22% are potential value superclasses (about half as many, by raw count, as the stateless abstract value candidates). Around 20% of abstract stateful classes have implicit constructors. There's a fairly high rate of 'this' dependency?around 17%, both overall and among value candidates. Per some spot checking, I imagine most of these can be easily refactored, if it's worth the trouble to make the stateful class value-compatible.

- Summarizing: among abstract classes intended to be subclassed, 56% are disqualified from being a value class super (based on mutability/concrete super), 23% can be made value-compatible with recompilation, 18% can be made value-compatible with source modifier opt-in, and 3% would require some refactoring.

- Standard concrete stateless classes tend to be things like singletons. 95% appear to be migratable to value classes without any source changes except the 'value' modifier (assuming they don't get subclassed and are okay with being made 'final').

- Mutable classes dominate the space of standard concrete stateful classes, but around ? of standard stateful classes are value candidates, and 93% of these appear to be migratable to value classes without any source changes except the 'value' modifier. Again, the remaining 7% will tend to be classes with constructors that can be easily refactored, plus a few with 'this' dependencies that can't be easily removed.


From daniel.smith at oracle.com  Wed Sep 20 14:42:17 2023
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 20 Sep 2023 14:42:17 +0000
Subject: EG meeting 2023-09-20
Message-ID: <DCEE677C-1409-4A5B-AC88-9D25C6FA1531@oracle.com>

An EG meeting will be held today, September 20, at 4pm UTC (9am PDT, 12pm EDT).

To discuss:

- "Rules for larval value object construction", describing how we can implement value class construction via <init> methods