Loading classes with many methods is very expensive

Peter Levart peter.levart at gmail.com
Sun Oct 26 22:53:40 UTC 2014


On 10/26/2014 09:25 PM, Peter Levart wrote:
> 19657 classes loaded in 1.987373401 seconds.
> 494141 methods obtained in 1.02493941 seconds.
>
> vs.
>
> 19657 classes loaded in 2.084409717 seconds.
> 494124 methods obtained in 0.915928578 seconds.

Hi,

As you might have noticed, the number of methods obtained from patched 
code differed from original code. I have investigated this and found 
that original code treats abstract class methods the same as abstract 
interface methods as far as multiple inheritance is concerned (it keeps 
them together in the returned array). So I fixed this and here's new 
webrev which behaves the same as original code:

http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods/webrev.02/

Comparing original vs. patched code still shows speed-up:

Original:

19657 classes loaded in 1.980493029 seconds.
494141 methods obtained in 0.976318927 seconds.
494141 methods obtained in 0.886504437 seconds.
494141 methods obtained in 0.911153722 seconds.
494141 methods obtained in 0.880550509 seconds.
494141 methods obtained in 0.875526704 seconds.
494141 methods obtained in 0.877258894 seconds.
494141 methods obtained in 0.871794344 seconds.
494141 methods obtained in 0.884159644 seconds.
494141 methods obtained in 0.892648522 seconds.
494141 methods obtained in 0.884581841 seconds.

Patched:

19657 classes loaded in 2.055697675 seconds.
494141 methods obtained in 0.853922188 seconds.
494141 methods obtained in 0.776203794 seconds.
494141 methods obtained in 0.858774803 seconds.
494141 methods obtained in 0.778178867 seconds.
494141 methods obtained in 0.760043997 seconds.
494141 methods obtained in 0.756352444 seconds.
494141 methods obtained in 0.740826372 seconds.
494141 methods obtained in 0.744264782 seconds.
494141 methods obtained in 0.73805894 seconds.
494141 methods obtained in 0.746852752 seconds.


55 java/lang/reflect jtreg tests still pass. As they did before, which 
means that we don't have a coverage for such cases. I'll see where I can 
add such a case (EnumSet for example, which inherits from Set interface 
and AbstractColection class via two different paths, so 
Set.size()/iterator() and AbstractCollection.size()/iterator() are both 
returned from getMethods())...


Regards, Peter




More information about the core-libs-dev mailing list