On Fri, 1 May 2026 21:06:13 GMT, Ashutosh Mehra <[email protected]> wrote:
>>> It could be only performance issue. But we need to test it. >> >> I am not sure I understand how this can only be a perf issue. If the >> instruction encoding is not valid on a platform, it would result in crash, >> right? >> >>> Will it be easier if we record CPU vendor (Intel, AMD, ZX) and don't allow >>> mismatch? Then you don't need to worry about flags settings based on vendor. >> >> Yeah we can do that. But it makes the code cache vendor specific which would >> further reduces the portability. >> >>> For portability we will have to disable address nops >= 12. >> >> I think this makes sense. Its a good trade-off. We get to keep aot code >> cache portable across vendors (provided we don't come across more such >> issues) without sacrificing too much perf. > >> I am not sure I understand how this can only be a perf issue. If the >> instruction encoding is not valid on a platform, it would result in crash, >> right? > > I think I get it now. For nop >= 12 bytes, the encoding is done using two > sequences of multi-byte nops. > eg on intel 12 byte nop = 8 byte nop + 4 byte nop > on amd 12 byte nop = 6 byte + 6 byte > > So there are multiple ways to encode multibyte nops, but they all should be > valid encodings on all vendors, and may just differ in performance. > > I agree it looks like it can have an impact on performance only. Thank you @ashu-mehra for review. I will work on your suggestions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-5750634110
