Interesting. Thanks for digging deep. > On Oct 31, 2014, at 8:36 AM, MacGregor, Duncan (GE Energy Management) > <duncan.macgre...@ge.com> wrote: > > Okay, I now know why the JVM is stuck for so long, just not why Eclipse is > doing what it does. > > At certain points during the loading of our application Eclipse will make > a large number (upto 10000) jdwp classesForSignature requests, each of > which causes the jdwp lib to trawl over a large number of classes (several > 10s of thousands), resulting in upto a couple hundred million jvmti > GetClassSignature calls, and is particularly pointless because it fails to > find any of these classes. > > That last bit gave me a clue. These large numbers of classesForSignature > requests occur when classes have been GCed, and a request is being issued > for every single class that has been successfully Gced. Since we¹re > careful to ensure that all the code we dynamically execute at startup is > done in temporary class loaders so that the everything can be Gced away, > and since variance LF stuff can also be Gced, the problem is much worse > than it would be in other applications. > > It¹s really bad in earlier 8 updates without the LF editor work because > there¹s more classes and more getting Gced, so I¹ve seen 3 minute long > pauses with that version. > > I guess this should be reported as a bug to the Eclipse debug team, but I > wonder if classesForSignature can¹t be made faster in some way. > > Regards, Duncan. > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
