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

[George Marrows]

Does anyone here know the best way to engage with the Eclipse developers on
this kind of thing?
We will try their mailing list (
http://dev.eclipse.org/mhonarc/lists/jdt-debug-dev/), but it's eerily
quiet....

George

On Tue, Nov 18, 2014 at 3:29 PM, MacGregor, Duncan (GE Energy Management) <
duncan.macgregor at ge.com> wrote:

> https://bugs.eclipse.org/bugs/show_bug.cgi?id=449791
>
>
> On 18/11/2014 14:06, "Marcus Lagergren" <marcus.lagergren at oracle.com>
> wrote:
>
> >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
> >
> >_______________________________________________
> >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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20141118/22236bad/attachment-0001.html>