Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1

[Tom Rodriguez]

>> I guess our choices are to back it out and go with the extra call in the unwind path or to try to find some way to make the unwind handler operate differently. Could we make the default exception handler special in some way.  The default exception handler block could be invisible to the rest of the system if it doesn't need to perform any unlocking since there are no values live into it, at least none that aren't bound.
> 
> I would prefer that the default exception handler of normal and synchronized methods are handled in the same way. The only difference is the unlock for synchronized methods,  but still the exception handler has no values flowing into it (because the unlock has not an instruction as the parameter, but always operates at lock 0).

It's true that in the final generated code we don't actually use the passed in object and instead retrieve it from the BasicObjectLock but the IR shows it as being used which is kind of misleading.  I might be tempted to remove it though it is helpful when reading the printed IR.

> 
> So the code you just sent should work. But if the method already has a catch-all handler (such as the one for synchronized methods), then the re-throw of this is handled again by the new default handler, basically leading to another round of exception-dispatch in the same method.

Any catch_all handler that terminates with a throw should trigger this logic in LIRGenerator::do_Throw:

  // check if the instruction has an xhandler in any of the nested scopes                                                                             
  bool unwind = false;
  if (info->exception_handlers()->length() == 0) {
    // this throw is not inside an xhandler                                                                                                           
    unwind = true;
  } else {

which will convert the throw into an unwind.  We will have an exception handler table entry that would dispatch it to the default handler but we will never perform the lookup so I think it's ok.

> A unified solution could be to always keep the synthetic exception handler, but don't generate all the unnecessary exception edges. Instead, it should be enough to just link it once from the the entry block (so that the exception handler is considered reachable). The entry point of this handler is then again remembered and faked into all exception handler tables.

I played a little bit with something like that but getting it properly hooked up seemed problematic.  I didn't try simply hooking it off the .  I do like the idea of a unified solution.  That's really what I was trying to get with the original changes.  Where do you think I would hook that up?  I'd have to do it at after parsing all the blocks wouldn't I?  Otherwise I assume that xhandler would propagate to following blocks.  Maybe hook it up just before the fill_sync_handler?

tom

> 
> Christian
>