Loading classes with many methods is very expensive

Jeremy Manson jeremymanson at google.com
Mon Oct 27 23:37:37 UTC 2014

Jeremy has already filed a bug (8062116), and is just finishing up the
patch (I jumped the gun a bit by attaching it to the bug - it has a few
bugs in it).  I'll probably have something in reasonable shape to review
tomorrow (I've submitted it internally, and I want to let it spend a day or
so having our test infrastructure throw things at it).

It's actually a JVMTI performance regression.  The data structure that is
being used to store jmethodids isn't great.  I've refactored it a bit to
improve its performance, but it should really be a closed hash table.
There isn't a handy one in HS, so I just made it O(1) for writes.  It's
still O(n) for reads, though, which is nasty.

We can have the real conversation when I post the RFR, though.


On Mon, Oct 27, 2014 at 12:45 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 27.10.2014 22:01, Martin Buchholz wrote:
> > I'm having trouble keeping up with this thread I started, but I did
> > update the test/benchmark
> >
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Class.getMethods-benchmark/
> > <
> http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/Class.getMethods-benchmark/
> >
> >
> > I added a test *LoadAllClassesAndMethods *that does what its name says.
> > Although originally written as just a benchmark,
> In our recent Nashorn classloading work, we did this benchmark:
>  http://cr.openjdk.java.net/~shade/8053904/ClassLoaderBenchmark.java
> ...which, I think can be easily exploded to call getMethods() as well.
> > Jeremy is independently working on yet another performance problem
> > exposed by *LoadAllClassesAndMethods*
> Does Jeremy have a reportable outline? Submit the bug to make this
> thread short :)
> Thanks,
> -Aleksey.

More information about the core-libs-dev mailing list