Function inlining is a compiler transformation that replaces a function call
with the body of the function being called. Such transformation eliminates the
overhead of calling a function and increases the scope for method-level compiler
optimizations. However, inlining increases method size, which negatively impacts
Just-In-Time (JIT) compilers by increasing the time spent in compilation and
optimization routines. To decide which callsite-method pairs will minimize
runtime of a jitted program, an inlining strategy, i.e., a criteria for
discriminating callsite-method pairs, must take into account the advantages and
disadvantages of inlining. However, coming up with a benefit and cost metric is
non-trivial.

While using frequency information to discriminate has been shown to provide good
inlining results, frequency information does not take into account inlining's role
in increasing the scope for method-level compiler optimizations.
We propose using abstract interpretation to identify method-level compiler
optimization opportunities that will be unlocked after inlining takes place.
The abstract interpreter iterates over Java bytecode instructions and safely
approximates run time values by encoding them as constraints.
Using these approximations to run time values, it is possible to determine
whether or not common place compiler transformations, e.g. branch folding and
partial evaluation, can take place after inlining.
The results of the abstract interpreter complement traditional data used by
inlining strategies, e.g. method invocation frequency, to better discriminate
between callsite-method pairs.