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

[Marcus Lagergren]

Nicely done, Duncan. Do you have a link to the issue report?

Regards
Marcus

> On 03 Nov 2014, at 16:48, MacGregor, Duncan (GE Energy Management) <duncan.macgregor at ge.com> wrote:
> 
> I’ve reported an Eclipse bug. Doesn’t look like their debugger has ever
> done quite the right thing, unless the behaviour of the JVM has changed
> significantly.
> 
> On 03/11/2014 15:33, "Christian Thalinger"
> <christian.thalinger at oracle.com> wrote:
> 
>> 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
>> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev