[Exp] First prototype of new acmp bytecode (original) (raw)

Tobias Hartmann tobias.hartmann at oracle.com
Wed Feb 14 15:01:26 UTC 2018


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



More information about the valhalla-dev mailing list