On Wed, 3 Jun 2026 09:22:10 GMT, Alan Bateman <[email protected]> wrote:

>> David Simms has updated the pull request with a new target base due to a 
>> merge or a rebase. The pull request now contains 2754 commits:
>> 
>>  - Merge remote-tracking branch 'valhalla/lworld' into 
>> jep401_sub_review_8317279
>>  - Merge
>>    
>>    Merge jdk-27+24
>>  - 8385674: [lworld] TestNullableInlineTypes.java fails after JDK-8325632
>>    
>>    Reviewed-by: mchevalier
>>  - 8385652: [lworld] RedefineClasses should use stack map frame name
>>    
>>    Reviewed-by: fparain
>>  - 8384107: [lworld] Update runtime/contended tests to run the same testing 
>> for value classes
>>    
>>    Reviewed-by: fparain, lmesnik
>>  - 8385600: [lworld] DA/DU issues with strict fields
>>    
>>    Reviewed-by: vromero
>>  - 8384897: [lworld] this.staticField should be restricted in early 
>> construction context
>>    
>>    Reviewed-by: liach, vromero
>>  - 8385601: [lworld] Update testing documentation for the ValueClassPlugin 
>> jtreg option
>>    
>>    Reviewed-by: lmesnik
>>  - 8385569: [lworld] Apply JDK-8343767 to Valhalla specific StubRoutines
>>    
>>    Reviewed-by: fparain, vlivanov
>>  - 8385581: [lworld] Remove the experimental JVMCI feature
>>    8382708: [lworld] JVMCI support for Value Objects
>>    8372605: [lworld] 
>> compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJava*.java
>>  fail with --enable-preview
>>    
>>    Reviewed-by: thartmann
>>  - ... and 2744 more: https://git.openjdk.org/jdk/compare/2c7efc08...9e804255
>
> src/java.base/share/classes/java/lang/IdentityException.java line 36:
> 
>> 34:  * or any type of {@link java.lang.ref.Reference}.
>> 35:  *
>> 36:  * @since Valhalla
> 
> I assume the `@since` tags will be fixed up at some point.

Indeed, we should update them when JEP 401 is proposed to target or targeted. 
We also need to remove `--ignoreSince Valhalla` in `JavaBaseCheckSince` test 
later.

> src/java.base/share/classes/jdk/internal/reflect/MethodHandleBooleanFieldAccessorImpl.java
>  line 65:
> 
>> 63:                 return (boolean) getter.invokeExact(obj);
>> 64:             }
>> 65:         } catch 
>> (IllegalArgumentException|IllegalStateException|NullPointerException e) {
> 
> Is this part of strict initialization to catch an attempt to read before 
> initialized explicitly?

Yes, in the [provisional strict fields JEP 
spec](https://cr.openjdk.org/~dlsmith/jep401/jep401-20260518/specs/strict-fields-jvms.html):

> Otherwise, execution of the class or interface initialization method, if any, 
> has completed normally. Check whether each strictly-initialized static field 
> declared by C has been set. If any such field has been left unset, acquire 
> LC, transition C to the erroneous state, notify all waiting threads, release 
> LC, and complete this procedure abruptly with an IllegalStateException as the 
> reason.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/31123#discussion_r3349585322
PR Review Comment: https://git.openjdk.org/jdk/pull/31123#discussion_r3349573398

Reply via email to