# Failure analysis

The addition of the new APX registers results in less available space in register masks for method arguments. The (static) register mask size computation in RegisterForm::RegMask_Size does take the number of available registers into account, but also rounds up to an even number of 32-bit words. Specifically, the register mask size computation is

  (words_for_regs + 3 + 1) & ~1;

Adding the new APX registers correctly bumps `words_for_regs` from 18 to 19, but due to the rounding, the result is the same (22) as for a value of 18 for `words_for_regs`.

# Original description

JDK-8329032 introduced register allocation support for APX. APX adds 16 new 64 bit general purpose register. Thus, JDK-8329032 increased `Register::number_of_registers` from 16 to 32. As a result, ConcreteRegisterImpl::number_of_registers is now increased by 32. Consequently, the `VMRegImpl::FRIST_STACK` is also increased by 32 and `stack2reg()` starts at a number that is larger by 32 than before JDK-8329032.

This means that there is less stack space left to spill arguments to the stack. In `Matcher::warp_outgoing_stk_arg()`, we check with `RegMask::can_represent_arg(warped)` if there is enough space left on the stack for all argument and bail out if not.

Before JDK-8329032, we could C2 compile a method call with 54 arguments but now we are only able to compile with 38 arguments (see attached Test.java). This seems to be a regression and should be fixed even though there is JDK-8325467 which will generally solve the problem of bailing out with too many arguments.

While looking at JDK-8329032, I noticed that there is an additional method `Register::vailable_gp_registers()` which accounts for UseAPX. But it does not seem to be used in places where we use `Register::number_of_registers` (even when there is no APX support). Should this be fixed as well?

This was found while merging the change into Valhalla which caused some unexpected compilation bailouts (JDK-8342064).