On Fri, 29 May 2026 16:05:24 GMT, Paul Sandoz <[email protected]> wrote:
>> 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 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). > Hi @PaulSandoz , Thanks for the clear direction. Will do — I'll integrate > this patch next week, soon after the JDK 27 RDP1 fork, and then work closely > with @eme64 on the fuzzer (#30997), since he architected that tool. Hi > @xuemingshen-oracle , All your comments have been addressed; looking forward > to your approval. Best Regards Thank you for understanding the situation and being flexible. For integration we will still require a review from a compiler engineer. I see discussion on the fuzzer PR which is encouraging. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-4579192750
