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

[MacGregor, Duncan (GE Energy Management)]

On 29/10/2014 17:13, "Christian Thalinger"
<christian.thalinger at oracle.com> wrote:
>
>> On Oct 29, 2014, at 10:06 AM, MacGregor, Duncan (GE Energy Management)
>><duncan.macgregor at ge.com> wrote:
>> 
>> On 29/10/2014 16:55, "Christian Thalinger"
>> <christian.thalinger at oracle.com> wrote:
>>> 
>>>> On Oct 29, 2014, at 9:39 AM, MacGregor, Duncan (GE Energy Management)
>>>> <duncan.macgregor at ge.com> wrote:
>>>> 
>>>> When weąve tried to debug some of our Java core in the context of
>>>> running a large application weąve been seeing long pauses (sometime
>>>>very
>>>> long pauses of over a minute) due to
>>>> java.lang.invoke.MemberName$Factory.resolve() apparently taking ages
>>>>to
>>>> complete.
>>> 
>>> Over a minute?!?  What is the JVM doing during this time?  Class
>>>loading?
>>> Garbage collection?
>> 
>> Doesnąt seem to be doing any GC, not doing much of anything that I can
>> see. Iąve applied Daivdąs MemberName interning patches and will see if
>> they change the behaviour at all, and then build a JDK with debug
>>symbols
>> and see if connecting a debugger to the process sheds any light on
>>whatąs
>> going on inside the JVM.
>> 
>>> The only thing that comes to mind is that methods with breakpoints are
>>> not compiled but interpreted.  But even if you had a lot of breakpoints
>>> in core methods I donąt see how that would explain pauses of over a
>>> minute.
>> 
>> It happens even without breakpoints being set. Is it possibly due to the
>> avalanche of anonymous classes Lambdaforms produce?
>So you're running in Eclipse's debugger but without breakpoints set and
>no single-stepping?

Yep, I'm just trying to reproduce other team members' problems here. Just
running our app using "Debug As Java Application" in Eclipse.

Normally when I break stuff it's so early in the bootstrap process I never
get close to an app. :-)