Hi Amit, Welcome to the party, glad to hear that s390x is joining us!
Our code freeze date was pushed out a bit. We are in code freeze as of today, July 6th and running final internal testing with the aim of being ready to integrate once JEP 401 and JEP 539 are Proposed to Target and the CSRs for both JEPs are approved. We tentatively anticipate that to occur in the next two weeks so that puts us at integration either the week of July 20th or July 27th. At this point, I would suggest building your changes against https://github.com/openjdk/valhalla (lworld branch) for testing purposes but as you suggest prepare a PR against jdk/master and once Valhalla is integrated into jdk/master, rebase and upstream the s390x port. As per Loom, I have looked at the changes, and they are indeed mostly s390x specific with some s390x specific conditionalization in shared code. Alan Bateman and Patricio Chilano Mateo are Reviewers and are aware of the upcoming Valhalla integration. I think this is ok to integrate ahead of Valhalla but will confirm with them. Hope that makes sense, reach out anytime if you have questions. Thanks, Lois From: Amit Kumar <[email protected]> Date: Monday, July 6, 2026 at 9:14 AM To: Dan Smith <[email protected]>; David Simms <[email protected]>; Lois Foltan <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; Andrew Haley <[email protected]> Subject: [External] : Re: Porting to support JEP 401: Value Classes and Objects (Preview) Hi, We're a little late to the party, but we now have a stable, buildable implementation of Valhalla for s390x. I have a couple of questions: 1. What would be the preferred approach for upstreaming the s390x implementation? I understand that the code freeze happened on 19 June. Should we prepare a PR against the jdk/master branch, and once Valhalla is integrated into jdk/master, rebase and upstream the s390x port there? If there's a better approach, please let me know. The changes are almost entirely s390-specific, so they should not affect other platforms. 2. The s390 Loom port is currently under review [1] and has already received one approval. Once it receives a second approval, should we go ahead and integrate it into the mainline? It also consists primarily of architecture-specific changes. Or would it be preferable to wait until Valhalla has been integrated? Thanks, Amit [1]: https://github.com/openjdk/jdk/pull/31441<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/31441__;!!ACWV5N9M2RV99hQ!JalgLIfOn0uplODSHWu0xOiE0yU1JrKjPM5AZqAwiuZJCAM8itt1MdVIu3m8qTqhyCOY_E3nWOrNAUgWWGeW2q4$> On 6 Jan 2026, at 4:51 AM, Dan Smith <[email protected]> wrote: Hello, porters! The Valhalla project has been implementing JEP 401: Value Classes and Objects (Preview) in a branch of our Github repository. Over the next few months, we will be preparing to target and integrate the JEP. This will be a very large commit touching many components of HotSpot, so now is a good time to start aligning your ports with the anticipated changes and ensuring conformance with the updated specifications. Some pointers: Value Classes JEP: https://urldefense.proofpoint.com/v2/url?u=https-3A__openjdk.org_jeps_401&d=DwIFAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=7RO9jvVQexTA4NUAXW9Yl7_AQTInobe-A2QB7-jZ_OE&m=6dFX1UP3Y05K9_sq4LJnZpe8sSVx55wR790SawIlm7EAHLeh-Plfk_W-8hUnCZIh&s=QGlhfi5_5iGg6f3etjNkw5IjM-Xwj60abnLg5KOF82w&e= Supplementary strict field initialization JEP: https://urldefense.proofpoint.com/v2/url?u=https-3A__openjdk.org_jeps_8350458&d=DwIFAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=7RO9jvVQexTA4NUAXW9Yl7_AQTInobe-A2QB7-jZ_OE&m=6dFX1UP3Y05K9_sq4LJnZpe8sSVx55wR790SawIlm7EAHLeh-Plfk_W-8hUnCZIh&s=TrjbH37VxKToKTSJL87KlWBsgFXOsacxBrGaWplFw2U&e= JVMS changes (value classes): https://urldefense.proofpoint.com/v2/url?u=https-3A__cr.openjdk.org_-7Edlsmith_jep401_jep401-2D20251210_specs_value-2Dobjects-2Djvms.html&d=DwIFAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=7RO9jvVQexTA4NUAXW9Yl7_AQTInobe-A2QB7-jZ_OE&m=6dFX1UP3Y05K9_sq4LJnZpe8sSVx55wR790SawIlm7EAHLeh-Plfk_W-8hUnCZIh&s=vYHKRfAN2jEovRwUM6zvr-9BtxJoNLZkVjiSlG_dGNU&e= JVMS changes (field initialization): https://urldefense.proofpoint.com/v2/url?u=https-3A__cr.openjdk.org_-7Edlsmith_jep401_jep401-2D20251210_specs_strict-2Dfields-2Djvms.html&d=DwIFAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=7RO9jvVQexTA4NUAXW9Yl7_AQTInobe-A2QB7-jZ_OE&m=6dFX1UP3Y05K9_sq4LJnZpe8sSVx55wR790SawIlm7EAHLeh-Plfk_W-8hUnCZIh&s=5KpBwBULPL-UsTRVnozIgaq1-oZGs5lTEqXOQKXsFao&e= Git branch: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openjdk_valhalla_tree_lworld&d=DwIFAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=7RO9jvVQexTA4NUAXW9Yl7_AQTInobe-A2QB7-jZ_OE&m=6dFX1UP3Y05K9_sq4LJnZpe8sSVx55wR790SawIlm7EAHLeh-Plfk_W-8hUnCZIh&s=W9vqn6scIsbiIWq9Gx8eKcuVOCB65VLFHZ88X1bv1To&e= As a baseline, you may want to focus on *compliance* without adopting any of the value object *optimizations*. A compliant JVM will recognize and validate the ACC_IDENTITY and ACC_STRICT_INIT flags, and will follow the new semantics for 'acmp', 'ifnull', and 'monitorenter'; but can ignore the contents of 'LoadableDescriptors', and need not support scalarized or flattened object encodings. Please reach out to valhalla-dev, or to me personally, if you need any help or clarifications to align with these changes.
