On Wed, 14 Jan 2026 08:59:14 GMT, Andrew Haley <[email protected]> wrote:
> It sounds rather complicated. It's important that the performance work we do > doesn't over complexify the implementation. Whatever we do should be > proportionate to the scale of the problem. Post-call NOPs are not a huge deal. > Why not use MOVN, and put the data into a stub at the end of the nmethod? If the data is stored in the stub code, the method size depends on whether `cb_offset`/`oopmap_index` fit in the respective post-call NOP - if I understand correctly, that would require calculating values of `cb_offset`/`oopmap_index` during the code generation because stub code size should be known prior to allocation in the code cache. It can't be postponed until `NativePostCallNop::patch`. Avoiding the estimation step would simplify the change. Also, referencing the stub code via MOVN - which can be used to store up to 18 bits of metadata - would limit the method size by approximately 1MB (`4 * (1 << 18)`). It might be a reasonable limit for a compiled method, however as far as I understand, right now the limit is `branch_range` (128MB). Would the 1MB limit be acceptable? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28855#issuecomment-3762774275
