The Java HotSpot compiler will attempt to inline any method calls it considers "hot" (it copies the code of the target method into the caller method to eliminate the method invocation overhead).
If inlining the method would mean that the enlarged caller is above a certain size (default 325 bytes of bytecode) then the inlining will fail.
JITWatch (https://github.com/AdoptOpenJDK/jitwatch) has a JarScan tool that can statically examine a jar file and identify methods which will not be inlined (under default VM settings) due to their size.
Most of these are not going to be used in "hot" code so there is nothing to worry about but there are a few I would consider hot that could potentially benefit from being split into smaller methods so that they can be inlined.
One example is the methods from ComparableTimSort (the default Collection sorting algorithm). See https://www.chrisnewland.com/can-splitting-java-core-class-methods-increase-performance-374 for an experiment into refactoring it.
Here are the JarScan results for Java 7 and Java 8's jre/lib/rt.jar (on Linux x64)