Conditions for inlining methods by the HotSpot VM

Question

I was reading up on the optimization techniques that are applied by the HotSpot VM and found this presentation by Oracle where it names three possible conditions for when the HotSpot VM attempts to inline method calls:

1. Devirtualization (Prove there's only one target method)
2. Monomorphic inline caching
3. Profile-driven inline caching

By searching the Internet I believe that I understood that this meant the following:

1. The VM "proves" that a type does not currently have a sub type. Therefore, the virtual method call can be transformed into a non-virtual one what allows inlining of the method's code. A guard condition is added that checks that no sub type was loaded after the inline was performed.

2. A method is observed to be always invoked on a single type at a specific call site. (Bonus question: Does Java support polymorphic inline caching?) This allows to perform optimistic inlining where a guard condition checks if the type is not the one represented in the cache.

3. I could not find out what that was.

My questions are: Are there other major reasons for inlining method calls? Is my research correct? And what is profile-driven inline caching?

Answer 1

It doesn't matter how many sub-class a class has, the only thing which matter is how many methods could be called from a given line of code. e.g. a method could have two implementations across four class, but if only one is called, it will be as if the methods had only one implementation.

The get an idea of the cost based on the number of implementations which can be called. Performance of inlined virtual method invocations in Java

Profile driven inlining is likely to be inlining based on methods actually called.