Last I looked, it was a threshold of method invocations before a method is inlined by JIT/HotSpot.
It is also a useful refutation to the usual (but erroneous) claim that manual inlining is a performance enhancement (if anything, it is a degradation). It is also related to the fact that
Java cannot prove that its functions are pure (Java has functions, but they are disguised i.e. OO can be transformed into functional).
For example (a typical one), a lot of people will write code like this:
...believing it is a performance enhancement as opposed to
Since Java has only an English-stated specification that Collection.size() is a pure function (is referentially transparent), developers might not trust the implementation of that specification, and so perform a manual inline. Others might argue that it is more readable (which is subjective and I disagree that it is more readable); some think it is a performance enhancement - which it clearly (I hope) isn't.
In a pure functional language, Collection.size() (its analogous to be precise) is guaranteed to return the same value from now until the end of the universe/time (read: while computational progression exists) by the compiler/language, therefore, the fear of inadvertant specification failure goes away. Nevertheless, you need to trust that a specification implementation adheres to its contract anyway - even given the substandard tools - otherwise, you run into huge problems and specifically, laborious techniques.
It's all fun to watch at least