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

[MacGregor, Duncan (GE Energy Management)]

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?

>> Testing with an openjdk build I see the reported line number in thread
>>dumps is 962 of MemberName.java, which is where Factory.resolve() calls
>>MethodHandleNatives.resolve().
>> 
>> Anybody else seen this, and is it even worth investigating further
>>without David¹s change to intern MemberNames?
>> 
>> 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