RFR: 8219713: Reduce work in DefaultMethods::generate_default_methods
david.holmes at oracle.com
Fri Mar 1 02:38:33 UTC 2019
On 28/02/2019 12:23 am, Claes Redestad wrote:
> 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. :(
> - 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
More information about the hotspot-runtime-dev