MaxBCEAEstimateSize and inlining clarification

[Krystal Mok]

On Thu, Sep 8, 2016 at 9:32 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

>
> By the way, and this is off-topic to this thread (apologies), but while
> we're discussing marking classes/methods final, are there any other
> footprint advantages to doing it even if CHA will devirt calls properly? So
> removing the need to register dependencies is one, and is good.  Are the
> vtables smaller for these cases? Anything else that's an added benefit
> (from JVM runtime standpoint)?
>

 Well...nothing that really stands out.

Removing the need for registering the dependencies is certainly a good
thing, but it doesn't really matter that much.

The vtable won't be necessarily be smaller, it depends. What's guaranteed
is that a final method won't need a *new* vtable entry.
Because "final" can be labeled on a method that's virtual in some base
class, and is only "final" on some derived class. That vtable slot in the
derived class is going to be inherited from the base class and then set to
the overriding target, so no saving at all in this case.

bool klassVtable::needs_new_vtable_entry(methodHandle target_method,
                                         Klass* super,
                                         Handle classloader,
                                         Symbol* classname,
                                         AccessFlags class_flags,
                                         TRAPS) {
  // ...

  if (target_method->is_final_method(class_flags) ||
      // a final method never needs a new entry; final methods can be
statically
      // resolved and they have to be present in the vtable only if they
override
      // a super's method, in which case they re-use its entry
      (target_method()->is_static()) ||
      // static methods don't need to be in vtable
      (target_method()->name() ==  vmSymbols::object_initializer_name())
      // <init> is never called dynamically-bound
      ) {
    return false;
  }

  // ...
}

The only thing that I can think of that improves *interpreter* performance
is the invoke_vfinal HotSpot internal bytecode. It allows the interpreter
in HotSpot to skip the vtable lookup and directly dispatch to the target
method, even when the original Java bytecode was invokevirtual. But it's
only an optimization for the interpreter, and it doesn't matter for the JIT
compilers.

- Kris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160908/8d2a5808/attachment.html>