Loading classes with many methods is very expensive

[Jeremy Manson]

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.

Jeremy

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.
>
>
>