RFR: 8234863: Increase default value of MaxInlineLevel
Jason Zaugg
jzaugg at gmail.com
Tue Dec 10 06:18:52 UTC 2019
On Mon, 9 Dec 2019 at 07:42, Claes Redestad <claes.redestad at oracle.com>
wrote:
> Hi,
>
> increasing MaxInlineLevel can substantially improve performance in some
> benchmarks[1], and has been reported to help applications implemented in
> scala in particular.
>
> There is always some risk of regressions when tweaking the default
> inlining settings. I've done a number of experiments to ascertain that
> the effect of increasing this on a wide array of benchmarks. With 15 all
> benchmarks tested are show either neutral or positive results, with no
> observed regression w.r.t. compilation speed or code cache usage.
>
Great to see!
A few notes from the Scala perspective (I work on the Scala compiler and
library at Lightbend.)
Long chains of method calls arise in Scala applications for a few reasons:
- Standard library collections have generic bridge methods that arise
from refinement of the collection type constructor down the hierarchy. For
instance, a generic method returning `Coll[T]` can be overridden in a
subclass to return `MyCollection[...]`.
- The encoding of traits (interfaces with mixin behaviour and storage)
and singleton objects indirect calls through forwarder methods (these don't
adapt arguments/results)
- The collections hierarchy itself is relatively deep, so the chain of
super() calls can be problematic (as per Charle's message about JRuby).
- Symbolic method names in the collections API have alphanumeric aliases
(e.g. `+=` and `addOne`)
These factors tend to conspire to exhaust the default budget. Analysis with
JITWatch / JMH etc have led us to refactor the library code to keep
important use cases fast (example [1]).
I once experimented [2] with a change to Hotspot to consider our
bridge-like forwarder methods as exempt from the MaxInlineLevel budget, as
is the case for lambda form frames. That change alone delivered most of the
performance benefit of doubling MaxInlneLevel with an unmodified JVM.
Jason Zaugg
[1] https://github.com/scala/bug/issues/11627#issuecomment-514490505
[2] https://gist.github.com/retronym/d27090a68570485c3e329a52db0c7b25
More information about the hotspot-compiler-dev
mailing list