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

[Christian Thalinger]

Interesting.  Thanks for digging deep.

> On Oct 31, 2014, at 8:36 AM, MacGregor, Duncan (GE Energy Management) <duncan.macgregor at 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 at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev