Hi Martin, Glad to hear the PPC64 port is on its way! In answer to your questions:
1. If you can create a PR next week, I would create it against the Valhalla repo. Next week still gives you time to integrate into the ‘lworld’ branch once reviewed and then the port will become part of the integration to openjdk/jdk mainline repo in July. Caution though, there will be a point early in the week of June 22nd that a full code freeze will be in effect for ‘lworld’ and any changes will have to wait until after integration. 2. Tailoring the flags for your implementation in vm_version_ppc.cpp sounds like the best approach. 3. I think most Valhalla specific tests are not run unless the port is included in the @requires simpleArch test. I can double check on that and get back to you. 4. Report bugs/enhancements in JBS with the affectsVersion “repo-valhalla”. For now, we also include “[lworld]” at the beginning of the JBS issue title. Once in mainline we will update all the [lworld] specific issues to mainline issues. Reach out if you have anymore questions. Thanks, Lois From: Doerr, Martin <[email protected]> Date: Friday, June 12, 2026 at 8:34 AM To: Dan Smith <[email protected]>; David Simms <[email protected]>; Lois Foltan <[email protected]> Cc: [email protected] <[email protected]>; porters-dev <[email protected]>; Reingruber, Richard <[email protected]> Subject: [External] : Re: Porting to support JEP 401: Value Classes and Objects (Preview) Hello, we are currently preparing the PPC64 Valhalla port. The main functionality (without --enable-preview) is basically repaired and we are porting the basic Valhalla functionality. We would like to avoid complete breakage of the port when Valhalla enters mainline. We have some issues and questions: 1. Should we create a PR in the Valhalla Repo next week or provide a PR which can be merged into https://github.com/openjdk/jdk/pull/31122<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/31122__;!!ACWV5N9M2RV99hQ!OyiXsiUya6ZAWiomkGkjp8utaBcNqnMZgxWIPAh9j7D_j-4i_Iav5Sf8KGXBsiptluWmylPCC-MX1pVppxXXPw$> one week later? 2. We were told to skip Valhalla features which are not strictly required. So, we could disable the following flags in vm_version_ppc.cpp: InlineTypePassFieldsAsArgs, InlineTypeReturnedAsFields, UseArrayFlattening, UseFieldFlattening, UseNullFreeNonAtomicValueFlattening, UseNullableAtomicValueFlattening, UseNullFreeAtomicValueFlattening, UseNullableNonAtomicValueFlattening, UseArrayLoadStoreProfile, UseACmpProfile, UseAcmpFastPath Does that make sense or are there other proposals to keep optional optimizations off? 3. What is the recommendation to get the JTREG tests green? Can we get more @requires checks for optional Valhalla features such that tests which need them don't complain? 4. What is the recommended way to report bugs in shared code or improvement proposals? I have added comments to the PR. Thanks for any advice and help! Best regards, Martin Von: porters-dev <[email protected]> im Auftrag von Dan Smith <[email protected]> Datum: Dienstag, 6. Januar 2026 um 00:22 An: [email protected] <[email protected]> Betreff: Porting to support JEP 401: Value Classes and Objects (Preview) 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://openjdk.org/jeps/401 Supplementary strict field initialization JEP: https://openjdk.org/jeps/8350458 JVMS changes (value classes): https://cr.openjdk.org/~dlsmith/jep401/jep401-20251210/specs/value-objects-jvms.html JVMS changes (field initialization): https://cr.openjdk.org/~dlsmith/jep401/jep401-20251210/specs/strict-fields-jvms.html Git branch: https://github.com/openjdk/valhalla/tree/lworld<https://urldefense.com/v3/__https://github.com/openjdk/valhalla/tree/lworld__;!!ACWV5N9M2RV99hQ!OyiXsiUya6ZAWiomkGkjp8utaBcNqnMZgxWIPAh9j7D_j-4i_Iav5Sf8KGXBsiptluWmylPCC-MX1pX0UkTuOw$> 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.
