On Fri, 29 May 2026 10:12:25 GMT, Jatin Bhateja <[email protected]> wrote:
>> @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 @jatin-bhateja the main push back is not the existing good work that has been done, I am very pleased with the outcome and how you managed to separate out the work, all this reduces the risk, makes it easier to review, and increases the quality. The push back is the risk of there being bugs introduced in HotSpot after RDP1, and those take time to emerge (over the large test matrix for HotSpot) and they become increasingly expensive to fix as we get closer to the release. Further, fixing such issues takes time away from other important work. What we need is time, and unfortunately we don't have it for 27, we do for 28. I approved this from a libraries perspective, but from a HotSpot perspective the compiler folks are right. Quan is makes a very good point about raising the bar, and Emanuel has been consistently doing so in careful reviews and increasing test coverage. So let's target 28. My recommendation is to push soon after RDP1 to mainline and follow up quickly with the fuzzer PR, then we have a good period time for testing and fixing issues the fuzzer may find or other tests may find (such as tests run in lower tiers with HotSpot under stress). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-4577330366
