Hi Martin, On 23 okt 2014, at 00:53, Martin Buchholz <marti...@google.com> wrote:
> Here at Google we have both kinds of scalability problems - loading classes > from a classpath with 10,000 jars, and loading a single class file packed > with the maximal number of methods. This message is about the latter. > > If you have a class with ~64k methods with a superclass that also has ~64k > methods, class loading that single class will cost you ~30sec and calling > Class.getMethods another ~10sec. Both are unacceptably slow. I think both > are due to O(N^2) algorithms, the first in hotspot, and the second in > Class.java. Throw in lots of interfaces with lots of default methods and i suspect this can get even worse. I spent some time thinking about this when fixing an issue with reflection for default methods, reviewed here [1]. > I have the start of a fix for Class.java, but it makes the common case > slower. A really good fix is harder to find. In general, I think > Class.java could benefit from some performance-oriented rework. Is anyone > else working on class loading performance, especially in hotspot? > We have been thinking about replacing the duplication of the method lookup logic in j.l.Class with a call to the VM which should already have the information needed. I’m not sure why the logic was duplicated on the library side way back when this was written. This isn’t something we are actively working on though. As an aside, I often found myself wanting for the actual method descriptor when working with this, but considering there can be *a lot* of instances of Method/Constructor adding a descriptor field to Executable wasn’t an obvious win to me. cheers /Joel [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-May/026782.html
