Draft JEP Announcement: "Computed Constants"

[Remi Forax]

Hi all, 
I've spent some time to try to improve the API given the constraints, 
- an API instead of a language feature, 
- distangle the fields initialized lazily from the ones initialized in the <clinit>, 
- the initialization code is made thread safe and executed exactly once, 
- as fast as a static final constant when c2 optimize the code, 
- condenser friendly, 
- can evolve to a langage feature in the future. 

I've re-used the idea of John of having one method able to initialize all the computed/autonomous fields, but it uses strings instead of ints because ints are not very user friendly :) 
I have one central object per class, i've called it FieldInit but I'm sure there is a better name. It it only able to initialize the field of the lookup class taken as parameter (I hope the current class). 
It has one method get(fieldName) that takes a field name as parameter and return the corresponding value lazily initialized. There are also overloads for all primitive types but it's more for convenience than anything else. The semantics for the initialization is the same as with a computed constant (I hope I get this right). 

public class Main { 
private static final FieldInit FIELD_INIT = FieldInit . ofStatic ( MethodHandles . lookup ()); 

private static Object $staticFieldInit$ ( String fieldName) { 
return switch (fieldName) { 
case "X" -> 42 ; 
case "HELLO" -> "hello field init !" ; 
default -> throw new AssertionError( "unknown " + fieldName); 
}; 
} 

private static int X ; 
private static String HELLO ; 

public static void main ( String [] args) { 
System . out .println( FIELD_INIT .getInt( "X" ));  // 42 
System . out .println( FIELD_INIT .< String >get( "HELLO" ));  // hello field init 
} 
} 

Major issues with that API, 
- it's string based so a renaming of one of the computed/autonomous field will make the corresponding FieldInit.get() to fail at runtime with a NoSuchFieldError, 
- it's not typesafe, a user can ask for the value of an int field as a String, it will fail at runtime with a ClassCastException, 
- if a code that directly access to a computed/autonomous field instead of using FieldInit.get() may see either the default value or the intialized value (don't do that), 
- the implementation put a lot more pressure to the JIT so the time to steady state may be delayed compared to a solution without computed/autonomous fields. 

The implementation is available here: 
https://github.com/forax/computed-constant/tree/master/field-init/src/main/java/com/github/forax/concurrent/constant 

The time to access to static final constant and to access to static constant through FieldInit.get() is identical once c2 JIT the code. 
Benchmark Mode Cnt Score Error Units 
Benchmarks.static_constant_get_42 avgt 5 0.316 ± 0.001 ns/op 
Benchmarks.static_constant_get_null avgt 5 0.316 ± 0.001 ns/op 
Benchmarks.static_field_init_get_42 avgt 5 0.315 ± 0.001 ns/op 
Benchmarks.static_field_init_get_null avgt 5 0.316 ± 0.001 ns/op 

I've not implemented the initialization of the instance field, mostly because I want feedback on this proposal before going further and unlike with a computed constant, there is a problem to make the difference between an uninitialized value and a default value of an instance field. 
regards, 
Rémi 

PS: There is also possible implementation using a template processor especially if it implements TemplatedString.Processor.Linkage. Something like FieldInitProcessor."X". Sadly, FieldInitProcessor.<Integer>"X" is not legal, there is no easy way to specify a return type. 

> From: "Per-Ake Minborg" <per-ake.minborg at oracle.com>
> To: "leyden-dev" <leyden-dev at openjdk.org>
> Sent: Thursday, July 27, 2023 5:52:46 PM
> Subject: Draft JEP Announcement: "Computed Constants"

> Hi all,

> Maurizio and I have drafted a JEP for computed constants, which are
> immutable value holders that are initialized at most once. They offer
> the performance and safety benefits of final fields while offering
> greater flexibility as to the timing of initialization. In the
> context of Leyden, they could be one basis for shifting computation
> both forward and backward in time.

> The draft is here: [ https://openjdk.org/jeps/8312611 |
> https://openjdk.org/jeps/8312611 ]

> Now that the Leyden repo is open, I’ll publish the prototype code to a
> new branch there shortly.

> Comments are welcome!

> Best, Per
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230730/08c8cd29/attachment.htm>