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.
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.
>
>
>
More information about the core-libs-dev
mailing list