review(S): 7058510: multinewarray with 6 dimensions uncommon traps in server compiler

[Tom Rodriguez]

Is there any easy way to just make C2 support a varargs style call for multianewarray?  C1 just does a funny calling convention where it passes a pointer a stack allocated array which is obviously possible with C2 though we don't have anything like it right now.  I can see how to do this by cons'ing up type signatures as need with extra count and pointer arguments and then modifying the c_calling_convention to switch to the stack only calling convention after the first two.  The only extra trick would be getting the address of the stack arguments into the call when it's converted into a MachCall.  We don't really have a way to express that using MachNodes since stack slots are virtual are that point.  Maybe it could simply be handled at the ad file level.

So something like a new MachCallRuntimeVarargsNode with an index indicating which argument is the last real one, the c_calling_convention modified to take an index indicating when it should force a switch to stack only, and the ins_encode for that match inserting the right address computation for the address.  Is that too complex for the limited benefit?  Maybe compared to the complexity of the existing machinery, it's not too bad.

As far as your webrev, I don't think you want to do this:

+           if (per_bc_reason == Reason_unhandled) {
+             make_not_compilable = true;
+           }

There are other uses of Reason_unhandled and it's not clear the stopping compilation is the right action for those other cases.  Maybe you need another action?  Or maybe the actions need to be interpreted specially for Reason_unhandled.  Doing a make_not_entrant doesn't seem like the right action for some of the other Reason_unhandleds.

I do like the trap_state changes if it allows us to move Reason_loop_predicate and Reason_loop_limit_check into the per bci section.

tom

On Jun 27, 2011, at 12:07 PM, Igor Veresov wrote:

> Problem: multinewarray with >= 6 dimensions is not supported by c2 and is plugged with uncommon trap. When executed in the main code path this yields performance far worse than even interpreter.
> 
> Solution: Count these traps per bci and when the number exceeds PerBytecodeTrapLimit make it not compilable. With tiered it would result in recompilation at level 1 (pure C1), with regular scheme the method will continue in the interpreter.
> 
> 
> Webrev: http://cr.openjdk.java.net/~iveresov/7058510/webrev.00/
> 
> 
> Thanks,
> igor