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