Here is a description of current JVM behavior:

"Private methods always get a vtable entry to handle backward compatibility
with classes - i.e. you can have the same name of a private method local to your class and also
inherit a method of from your superclass, which will get inherited around the private method, by
your child." http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-August/011500.html

But, it seems to be a waste of space, and a needless "surprise" in the code, to give vtable entries to private methods.  Surely there must be a better way to handle the relevant corner cases.

When the code in klassVtable::update_inherited_vtable encounters a private method, it does this:
  // private methods always have a new entry in the vtable
  // specification interpretation since classic has
  // private methods not overriding
  if (target_method is private) {
    return (probably true)
  }

In most case, a 'false' return value would be correct and would use less metadata space for vtables.

There may be a case where a vtable index would need to be assigned retroactively but this would only have to apply to subclasses that somehow manage to override to the private method (if that were possible).

In cases where the private method somehow manages to override a superclass method (if that were possible) then the vtable index would already be allocated in the superclass, and would not need to be re-allocated in the method holder class.