On Fri, 29 May 2026 07:00:27 GMT, Quan Anh Mai <[email protected]> wrote:
>>> @jbhateja BTW: the fuzzer is not yet fully ready and reviewed - there are >>> some design questions over there. >>> >>> So I'm worried that if we now integrated this PR here, and took more time >>> for the fuzzer, the fuzzer would really have very little to no time to find >>> issues. >> >> Hi @eme64, >> >> First, thanks for building the template fuzzer — it has consistently proven >> to be an excellent tool for catching subtle codegen bugs, and we genuinely >> appreciate the effort you've put into it. That work is highly valued. >> >> That said, the fuzzer (#30997) is tracked separately from this PR, and any >> Float16-related issues it surfaces will be triaged and fixed in exactly the >> same way we handle fuzzer-found issues for the other lane types today. The >> in-tree validation in this PR already meets the bar we apply to other Vector >> API types >> >> Best Regards > > @jatin-bhateja Just because it meets the bar we apply to other Vector API > types does not mean it meets the bar to rush into JDK27. In fact, as our bar > for integration keeps being raised due to both the JDK and the Vector API > becoming more and more mature, it is only natural that what was accepted in > the past may not be accepted now. > > In general, we often freeze the integration of improvements when we are close > to branching off, this time it is also due to the incoming Valhalla. As a > result, I don't see a reason for this PR to be an exception. Hi @merykitty, @eme64, @robarto, Thank you for the thoughtful concerns. To summarize: PR #28002 has been under active review since long time, changes are mainly in core-libs, compiler side changes are minimal, got approvals from @PaulSandoz and @XiaohongGong (AArch64), and CSR JDK-8383355 is approved. Testing is green on mach5 tier1+tier2+tier3 across x86_64 (@xuemingshen-oracle) and AArch64 (@XiaohongGong), including the combined PR-28002 + PR-30997 workspace — matching the bar used for the other Vector API lane types. Float16Vector lands as incubating, so JDK 27 integration enables early adoption (Panama FP16 numerics, ML kernels, codecs). The template fuzzer (#30997) will land after @eme64's review comments on that PR are addressed, giving in-cycle soak for Float16Vector and the rest of the Vector API within JDK 27. I'm personally still in favor of landing this in JDK 27, I'll defer the final timing call to @xuemingshen-oracle and @PaulSandoz. Warm Regards ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-4573728925
