MemberName$Factory.resolve() and the Eclipse debugger.

[MacGregor, Duncan (GE Energy Management)]

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.