MaxBCEAEstimateSize and inlining clarification

Krystal Mok rednaxelafx at
Thu Sep 8 23:28:29 UTC 2016

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

> On Sep 8, 2016, at 2:48 PM, Krystal Mok <rednaxelafx at> wrote:
> On Thu, Sep 8, 2016 at 9:32 AM, Vitaly Davidovich <vitalyd at>
> 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: <>

More information about the hotspot-compiler-dev mailing list