MaxBCEAEstimateSize and inlining clarification

[Vitaly Davidovich]

On Thursday, September 8, 2016, Krystal Mok <rednaxelafx at gmail.com> wrote:

> On Thu, Sep 8, 2016 at 9:32 AM, Vitaly Davidovich <vitalyd at gmail.com
> <javascript:_e(%7B%7D,'cvml','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.
>
I'll take it :).  I'm assuming you think it doesn't really matter because
it's only done for C2 compiled code (or C1 as well?), and that's not an
excessive number and this is only checked at class loading time which also
shouldn't happen much (if at all) once steady state is reached.  Or is
there something else/more to your reasoning?

>
> 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.
>
Yes, I meant for classes that declare the method, not inherit it.

> 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;
>   }
>
>   // ...
> }
>
Thanks for the code pointer.

>
> 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.
>
Yeah, don't care too much about interpreter :)

>
> - Kris
>
>
>

-- 
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160908/da32c7dc/attachment.html>