[Exp] First prototype of new acmp bytecode

Tobias Hartmann tobias.hartmann at oracle.com
Fri Feb 23 13:22:01 UTC 2018

Hi John,

On 21.02.2018 22:04, John Rose wrote:
> You might even be able to get rid of the special node type (arity=3),
> if the cases where CmpP sees a derived oop can be recognized
> as perturbations.  I don't think we do CmpP on derived oops in
> any other circumstance (no C-style pointer/limit loops).

Yes, we only use CmpP with AddP inputs for raw pointer comparisons (for example, in
PhaseMacroExpand::expand_allocate_common) and we can easily filter these out.

Here's the new webrev:

Changes include:
- Using derived oops for perturbation
- Got rid of all CastX2P usages
- Removed additional input edge from CmpP
- Factored common code into separate methods
- Swap operand optimization to avoid null checks in new acmp
- Added code to ensure OrX is folded to null check or constant false if possible
- Interface supertype support

I've executed performance runs with -XX:-TieredCompilation -XX:ValueBasedClasses= -XX:+UseNewAcmp
and there is no significant performance difference with SPECjvm2008 and SPECjbb2015 (and some of our
internal benchmarks).

- JMH benchmarks
- Type speculation on (non-)nullness
- Fix changes in macro.cpp
- Convert test to jtreg format

Best regards,

More information about the valhalla-dev mailing list