<br><br>On Thursday, September 8, 2016, Krystal Mok <<a href="mailto:rednaxelafx@gmail.com">rednaxelafx@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 8, 2016 at 9:32 AM, Vitaly Davidovich <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','vitalyd@gmail.com');" target="_blank">vitalyd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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)? </div></div></div></div></blockquote><div><br></div><div> Well...nothing that really stands out.</div><div><br></div><div>Removing the need for registering the dependencies is certainly a good thing, but it doesn't really matter that much.</div></div></div></div></blockquote><div>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?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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.</div></div></div></div></blockquote><div>Yes, I meant for classes that declare the method, not inherit it.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><div><br></div><div><div><font face="monospace, monospace">bool klassVtable::needs_new_vtable_<wbr>entry(methodHandle target_method,</font></div><div><font face="monospace, monospace">                                         Klass* super,</font></div><div><font face="monospace, monospace">                                         Handle classloader,</font></div><div><font face="monospace, monospace">                                         Symbol* classname,</font></div><div><font face="monospace, monospace">                                         AccessFlags class_flags,</font></div><div><font face="monospace, monospace">                                         TRAPS) {</font></div><div><font face="monospace, monospace">  // ...</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">  if (target_method->is_final_<wbr>method(class_flags) ||</font></div><div><font face="monospace, monospace">      // a final method never needs a new entry; final methods can be statically</font></div><div><font face="monospace, monospace">      // resolved and they have to be present in the vtable only if they override</font></div><div><font face="monospace, monospace">      // a super's method, in which case they re-use its entry</font></div><div><font face="monospace, monospace">      (target_method()->is_static()) ||</font></div><div><font face="monospace, monospace">      // static methods don't need to be in vtable</font></div><div><font face="monospace, monospace">      (target_method()->name() ==  vmSymbols::object_<wbr>initializer_name())</font></div><div><font face="monospace, monospace">      // <init> is never called dynamically-bound</font></div><div><font face="monospace, monospace">      ) {</font></div><div><font face="monospace, monospace">    return false;</font></div><div><font face="monospace, monospace">  }</font></div></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">  // ...</font></div><div><font face="monospace, monospace">}</font></div><div></div></div></div></div></blockquote><div>Thanks for the code pointer.<span></span> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div>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.</div></div></div></div></blockquote><div>Yeah, don't care too much about interpreter :) </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>- Kris</div><div><br></div><div><br></div></div></div></div>
</blockquote><br><br>-- <br>Sent from my phone<br>