Loading classes with many methods is very expensive
jeremymanson at google.com
Tue Oct 28 00:43:30 UTC 2014
Just want to reiterate: that patch has a few bugs in it. Don't review it
yet. I'll probably follow up tomorrow.
On Mon, Oct 27, 2014 at 4:37 PM, Jeremy Manson <jeremymanson at google.com>
> 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
>> > <
>> > 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:
>> ...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 :)
More information about the core-libs-dev