[Exp] First prototype of new acmp bytecode (original) (raw)
Tobias Hartmann tobias.hartmann at oracle.com
Fri Feb 23 13:22:01 UTC 2018
- Previous message (by thread): [Exp] First prototype of new acmp bytecode
- Next message (by thread): hg: valhalla/valhalla: First transition step toward L-world experimentation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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: http://cr.openjdk.java.net/~thartmann/valhalla/exp/acmp.03/
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).
TODOs:
- JMH benchmarks
- Type speculation on (non-)nullness
- Fix changes in macro.cpp
- Convert test to jtreg format
Best regards, Tobias
- Previous message (by thread): [Exp] First prototype of new acmp bytecode
- Next message (by thread): hg: valhalla/valhalla: First transition step toward L-world experimentation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]