early steps on the road to customization
john.r.rose at oracle.com
Thu Aug 27 21:52:41 UTC 2020
On Aug 27, 2020, at 8:37 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> Since several of these require trusting final fields, and there already is a TNSFF hook, does enabling that affect the macro-observed performance, or are these things hidden behind bigger roadblocks?
There are other roadblocks, certainly. A ClassValue table is mutable,
like a MutableCallSite, so it requires some special logic.
Yesterday’s “early step” was the proposal of a plausible benchmark.
Teasing apart the multiple components of the slowdown (relative to
hand customization) is going to be some further work.
Probably getting the performance up is some combination of:
- trusted finals
- constant-folding through ClassValue (like MCS)
- method versioning
- assigning correct cache points to versioned methods
- inlining tuning (there’s always that, but it’s not the major element here)
The effects of each factor can be estimated by appropriate experiments:
- force final trusting
- use a ClassValue approximator that the JIT can constant-fold
- force method versioning by hand-injection of bridges (“version bridges”) and @ForceInline
- manually set cache points by version bridge placement
- crank up the inlining tuning flags (not a final solution: infinite inlining hurts real apps)
More information about the valhalla-dev