MaxBCEAEstimateSize and inlining clarification

[Krystal Mok]

On Thu, Sep 8, 2016 at 3:13 PM, John Rose <john.r.rose at oracle.com> wrote:

> On Sep 8, 2016, at 2:48 PM, Krystal Mok <rednaxelafx at gmail.com> wrote:
>
>
> 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.
>
>
> HotSpot is overly generous with v-table entries.  IIRC even privates get
> their own entries, for convoluted reasons.
>
> Thanks for the tip, John! You're right. Yikes...

  // private methods in classes always have a new entry in the vtable
  // specification interpretation since classic has
  // private methods not overriding
  // JDK8 adds private  methods in interfaces which require invokespecial
  if (target_method()->is_private()) {
    return true;
  }

- Kris


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