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
