RFR: 8359965: Enable paired pushp and popp instruction usage for APX enabled CPUs

Volodymyr Paprotski vpaprotski at openjdk.org
Thu Jul 3 15:14:42 UTC 2025


On Wed, 2 Jul 2025 23:28:42 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> @vamsi-parasa, It's better to make this as a subclass of MacroAssembler in src/hotspot/cpu/x86/macroAssembler_x86.hpp and pass Tracker as an argument to push / pop for a cleaner interface.
>
> Hi Jatin (@jatin-bhateja) and Vlad (@vpaprotsk),
> 
> There's one more issue to be considered. The C++ PushPopTracker code will be run during the stub generation time. There are code bocks which do a single push onto the stack but due to multiple exit paths, there will be multiple pops as illustrated below. Will this reference counting approach not fail in such a scenario as the stub code is generated all at once during the stub generation phase?
> 
> 
> #begin stack frame
> push(r21)
> 
> #exit condition 1
> pop(r21)
> 
> # exit condition 2
> pop(r21)

Now that I had my fun writing an array-backed stack.. (and with David's comment too..) I can admit that the point of the entire C++ Tracker class is to 'just' add an assert; doesn't actually functionally add to the original code, but does add better JIT/stub compile-time checking.

@vamsi-parasa you are right.. if there are ifs and multiple exit paths in the assembler itself.. the Tracker wont be able to catch it (multiple exits paths in the generator are just fine though); I was thinking about this problem too last night... a hack/'solution' would be to disable such checking with a default flag in the constructor... 'fairly trivial' but just adds to the complexity even more. And the assert was the point of the class to begin with... I do think such stubs are rare?

There is some value in improved checking, but enough? Writing stubs is already an 'you should know assembler very well' thing so those checks only improve things marginally overall? As David says, its for the compiler folks to decide :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25889#discussion_r2183043350


More information about the hotspot-dev mailing list