JVM JIT可以专门化子类中的非重写方法吗？

Question

Well, that title along can't get the idea across but basically what I mean is that given some method m() in a class Base , which is not overridden in some subclass Derived , are the JIT compilers in current JVMs ¹ capable of "specializing" ⁰ m() anyway when it makes sense, or will derived who inherit and don't override Base.m() share the same compiled code?

This specialization makes sense, where the derived class defines something that makes m() much simpler. For example and for the purposes of discussion, let's say m() calls another member function n() and in the derived class n() is defined such that when n() is inlined into m() the latter is greatly simplified.

To be concrete, consider following the two non-abstract methods in the following class (which are both m() -type methods, while the abstract methods are the corresponding n() methods):

public class Base {

  abstract int divisor();
  abstract boolean isSomethingEnabled();

  int divide(int p) {
    return p / divisor();
  }

  Object doSomething() {
    if (isSomethingEnabled()) {
      return slowFunction();
    } else {
      return null;
  }
}

Both rely on abstract methods. Lets say you now have a Derived like this:

public class Derived extends Base {

  final int divisor() {
    return 2;
  }

  final boolean isSomethingEnabled() {
    return false;
  }
}

Now the effective behavior of the divide() and doSomething() methods are very simply, the divide is not a full division by an arbitrary number, but a simply halving that can be done with bit-operations. The doSomething() method always returns false . I assume that when the JIT goes to compile divide() or doSomething() if Derived is the only subclass, all is good: there exists (currently) only one possible implementation for the two abstract calls, and CHA will kick in and inline the only possible implementations and all is good.

In the more general case that other derived classes exist, however, it isn't clear to me if the JVM will only compile one ² version of the methods in Base with an invokevirtual call to the abstract methods, or if it is smart enough to say, "Hey, even though Derived doesn't override divisor() I should compile a version specifically for it 'cause it's going to be much simpler".

Of course, even without specialized recompilation aggressive inlining often makes it work out fine anyway (ie, when you call divide() on a class that is known or even just likely to be a Derived , inlining is likely to give you the good implementation anyway, but, equally, there are plenty of cases where such inlining isn't done.

---

⁰ My specializing I don't mean anything specific beyond compiling another version of the function appropriate in some restricted domain, in the same sense that say inlining is a form of specialization to a specific call site, or in the same way that most functions are somewhat specialized to the current context (eg, loaded classes, assumptions about nullness, etc).

¹ In particular, when one says "Can the JVM blah, blah?" one is usually talking about Hotspot, and I'm also mostly in Hotspot but also whether any other JVM can do this too.

² OK sure, you might have several version of a function, for on-stack-replacement, for different compiler levels, when deoptimization occurs, etc...

Answer 1

1. HotSpot JVM has at most one current, entrant version of compiled method. This is obvious from one-to-one relationship between Method and nmethod entities in the source code. However, there can be multiple non-entrant previous versions (eg nmethods compiled at lower tier and OSR stubs).

2. This single compiled version is often optimized for the most common case basing on run-time profiling. For example, when during profiling of Base.doSomething() JIT sees that isSomethingEnabled() is always invoked on Derived instance (even if there are more subclasses), it will optimize the call for the fast case, leaving an uncommon trap for a slow one. After this optimization doSomething() will look like

     if (this.getClass() != Derived.class) { uncommon_trap(); // this causes deoptimization } return false; 

3. Profile data is collected separately for each branch and for each call site. This makes possible to optimize (specialize) a part of a method for one receiver, and the other part for a different receiver.
4. If two different receivers were detected during profiling, JIT can inline both callees guarded by a type check.
5. A virtual call with more than two receivers will be compiled using vtable lookup.

To see the method profile data use -XX:+PrintMethodData option available in debug builds of JVM.

Answer 2

No, my understanding is that the JVM would not specialize a method on its own but rather optimize the base class function if it finds during profile optimization that divisor() often resolves to a certain method.

Have you tried to print from diagnostics to see what happens?

Rather than trying to guess what the JIT is doing, you can take a peek at what's happening by turning on java command line flags: -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining (from Java JIT compiler inlining )

Answer 3

According to the OpenJDK Wiki :

• Methods are often inlined. This increases the compiler's "horizon" of optimization.
• Static, private, final, and/or "special" invocations are easy to inline.
• Virtual (and interface) invocations are often demoted to "special" invocations, if the class hierarchy permits it. A dependency is registered in case further class loading spoils things.
• Virtual (and interface) invocations with a lopsided type profile are compiled with an optimistic check in favor of the historically common type (or two types).

That is, for the two most frequent receiver types, the derived methods would be inlined into their caller (if small enough, which should be the case here), and unreachable branches pruned.

Also, if the base method is small enough for inlining into its caller, it will be optimized for that caller's two most frequent receiver types.

That is, the Hotspot JVM specializes code if it is small enough for inlining for the two most frequent receiver types of that call site.

Answer 4

The JVM doesn't define nor redefine types. It interprets running implementations of behaviors. It's the compiler, ie, the source language that deals in types. The JVM is the low level, the "metal" of the Java universe. Types and their instances are instructions to create a series of observable events influenced by inputs. That series of inputs and observable events over time constitute what computer scientists call the "semantics" of a program.

It's up to the JVM to figure out ways to carry out those instructions while preserving the semantics. It will, at times, destroy a class structure entirely, in effect. Conceptually a class instance lives in heap memory with labeled attributes. For some period of time, until the semantics prohibit it because of some state change, the JVM might keep two active values in registers, not even in RAM, and ignore the whole rest of the defined class. Is that "specializing" the method?

No, it is not. There is no new definition, no new set of Java-level instructions, no ephemeral type in the JVM. There's just a temporary, compiled and optimized way in the moment to fulfill the instructions. When the optimization no longer works, or matters as much, the JVM even reverts to interpreting bytecode. And bytecode won't contain any new types, either. It's an assembly language, and redefining what the high-level code demands is above its pay grade.

Bottom line, the only types in the program are those mandated in the source code, not the bytecode or JVM. All the semantics come from the source.