RFR: 8219713: Reduce work in DefaultMethods::generate_default_methods

[David Holmes]

Hi Claes,

On 28/02/2019 12:23 am, Claes Redestad wrote:
> Hi,
> 
> on modern, larger applications, DefaultMethods::generate_default_methods
> can show up prominently in startup profiles, so I took a stab at dealing
> with some apparent inefficiencies:
> 
> - java.lang.Object is scanned at least once for every interface in the
> hierarchy - this will be a no-op after the first so we should filter
> out Object except the first time we encounter it.

I can see the filtering but what I can't see is how Object is treated 
such that I can confirm that it is indeed a no-op on subsequent visits. 
(This is just the nature of of the code.)

> - the resolveNatives and <clinit> are added and checked for every
> class/interface scanned, but then explicitly filtered out later on. It
> seems that all static initializers and private static methods can be
> safely filtered out from the first pass since they wouldn't mask default
> methods anyhow.

I'm not sure what exactly you mean by this. At the language level this 
is true as you can't compile something that contravenes that. But what 
if you actually encounter such classfiles at runtime? It is not at all 
clear to me what should happen based on JVMS and what will happen based 
on your optimisation.

Perhaps my problem is that I don't understand sufficiently how 
generate_default_methods functions in the first place. :(

Thanks,
David
-----

> - a few minor cleanups and simplifications, e.g., removing never
> exercised code to cancel and reset an iteration.
> 
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8219713
> Webrev: http://cr.openjdk.java.net/~redestad/8219713/open.01/
> 
> Testing: tier1-3, measured a speed-up on certain startup application
> 
> Thanks!
> 
> /Claes