RFR: 8219713: Reduce work in DefaultMethods::generate_default_methods

Lois Foltan lois.foltan at oracle.com
Fri Mar 1 14:44:26 UTC 2019

On 2/28/2019 9:38 PM, David Holmes wrote:
> 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. :(

Hi Claes,

I think this is a positive change but I too have some concerns with 
removing private static methods and would like a chance to discuss with 
Karen who is more familiar with this area.  Also, a change like this in 
my opinion would need more testing, for example at least hs-tier1-8 as 
well as JCK vm & lang.


> 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

More information about the hotspot-runtime-dev mailing list