[Exp] First prototype of new acmp bytecode

[Tobias Hartmann]

Hi,

here is a first prototype of the new acmp bytecode required for L-World according to [1]:
http://cr.openjdk.java.net/~thartmann/valhalla/exp/acmp.00/

The interpreter implementation is a straight forward, I've focused on C2 (see GraphKit::new_acmp). The basic rule is
that in the case where both operands might be value types, we need to use the new acmp implementation. Otherwise, i.e.
if one operand is not a value type, we can use the old acmp implementation.

The basic scheme for cmp(a, b) looks like this:

if (a or b might be a value) {
  if (a or b is statically known to be a value) {
    // Only return true if both operands are null
    if (a or b is never null) {
      // Return constant false
    } else {
      // Check if both operands are null by or'ing oops
    }
  } else {
    // Use new acmp
  }
} else {
  // Use old acmp
}

The webrev contains a Test.java that verifies correctness and will be converted to a jtreg test later. I've verified
that if compiled, optimal code is generated by C2 for all test* methods.

For C2 experts: Since I've only implemented parse time optimizations, C2 will not generate optimal code in some cases
(for example, with late inlining or if exact type information is only available later). I'm now working on improving
this. I've tried several different approaches, including using a macro node for CmpP. The problem is that for the new
acmp we need to emit a null check before loading the klass and during macro expansion it's hard to modify/insert control
flow (for example, because the if branch might have been converted to a CMove). I'm therefore eagerly inserting the new
acmp code during parsing and will try to fold it later if more concrete type information is available. We still might
want to create a new node for that but I'm not convinced yet that this is really necessary.

Please let me know if you spot any problems or wrong assumptions. I don't plan to push this code now but just wanted to
give you an update.

Thanks,
Tobias

[1] http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-January/003722.html