From daniel.smith at oracle.com Wed Mar 5 02:04:54 2025 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 5 Mar 2025 02:04:54 +0000 Subject: EG meeting, 2025-03-05 Message-ID: We'll hold the EG meeting tomorrow in the usual time slot: March 5, 17:00 UTC (9am PST, 12pm EST, 6pm CET). We can discuss the Strict Field Initialization JEP. From daniel.smith at oracle.com Wed Mar 5 02:01:58 2025 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 05 Mar 2025 02:01:58 -0000 Subject: New JEP: Strict Field Initialization in the JVM Message-ID: <1F157E45-8AE9-49A3-8E4D-4B7A3213EC5A@oracle.com> As we've worked through the details of strictly-initialized fields, it has made sense to spin the feature off into its own JVM-only preview feature JEP: https://openjdk.org/jeps/8350458 The Value Classes and Objects JEP will depend on Strict Field Initialization in the JVM. The JEP covers all uses of ACC_STRICT: final and non-final, static and non-static. We've worked to unify these under a cohesive model, where all strict field initialization happens within a *larval initialization state*. Static field initialization rules are enforced dynamically, while instance field initialization rules are enforced by verification. A few months ago, the EG discussed the idea that, if we require all fields to be set in a basic block immediately before the 'super()' call, the verifier could enforce the initialization requirements without any changes to StackMapTable. We seriously considered that idea, but concluded that it was worthwhile to enhance StackMapTable to be able to express intermediate initialization states. So this JEP includes the 'assert_unset_fields' entry we discussed previously. This is a draft, feedback is welcome! From diegorosario2013 at gmail.com Thu Mar 27 16:59:02 2025 From: diegorosario2013 at gmail.com (Diego Antonio Rosario Palomino) Date: Thu, 27 Mar 2025 11:59:02 -0500 Subject: Using value classes to optimize erased generics Message-ID: Hi all, I?ve been thinking about whether we can optimize erased generics using only the already-finalized features of Project Valhalla?specifically, value classes. Even though generics are still erased, if the erased value is a value class, maybe the JVM could still store it without indirection. This wouldn?t require full specialization like the Parametric JVM, but could still improve performance in common cases. It?s similar in spirit to this issue in the Sixten language: https://github.com/ollef/sixten/issues/149 Also?could someone please point me to current resources or documentation about the Parametric JVM? I?d like to share them with some folks working on Scala and Idris2 backends to explore whether targeting it is practical. Thanks, Diego Antonio Rosario Palomino -------------- next part -------------- An HTML attachment was scrubbed... URL: