On Sat, 17 Jan 2026 06:21:27 GMT, Ruben <[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.
It doesn't have to be hard. We can just guess. In the odd instance that the guess is wrong, emit zeroes. > 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? Yes, 1M is plenty. Andrew. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28855#issuecomment-3768728964
