RFR: 8260355: AArch64: deoptimization stub should save vector registers

Nick Gasson nick.gasson at arm.com
Fri Jan 29 07:53:19 UTC 2021


On 01/28/21 17:48 pm, Andrew Haley wrote:
>
> It seems to me that save_vectors is only set here:
>
>    bool save_vectors = COMPILER2_OR_JVMCI != 0;
>
> which means that save_vectors is a static property of a build, not something
> that can vary. Therefore, there is nothing to be gained by passing save_vectors
> around. Could we simply have a save_vectors_on_deopt() function?
>

RegisterSaver is also used by generate_resolve_blob (which never saves
vectors) and generate_handler_blob (which saves vectors when poll_type
== POLL_AT_VECTOR_LOOP). How about we make RegisterSaver a class you can
instantiate, and pass whether to save vectors or not to the constructor?
That would look like:

  RegisterSaver reg_save(COMPILER2_OR_JVMCI != 0 /* save_vectors */);
  map = reg_save.save_live_registers(masm, 0, &frame_size_in_words);
  ...
  reg_save.restore_live_registers(masm);

Which avoids passing save_vectors around everywhere.

> Also, I'm wondering how much all of this complexity gains us for the sake
> of configurations without C2. I'd be very tempted to just leave a hole in
> the stack for these systems. How much stack would that cost?

For NEON the difference is 768 bytes vs 512, but SVE could be a lot
more.

  83 // FIXME -- this is used by C1
  84 class RegisterSaver {

Do you remember what this is referring to? That it's duplicating
save_live_registers() in c1_Runtime_aarch64.cpp?

--
Thanks,
Nick


More information about the hotspot-dev mailing list