Re: RFR(s): 8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: RFR(s): 8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes

Kirk Pepperdine-2

> On Jun 6, 2018, at 6:05 PM, Thomas Stüfe <[hidden email]> wrote:
>
> Dear all,
>
> may I please have feedback and if possible reviews for this small addition:


I can see the need to visualize this but the output looks easily parsable so it all looks good from my perspective.

Not an official review
— Kirk

Reply | Threaded
Open this post in threaded view
|

Re: RFR(s): 8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes

Thomas Stüfe-2
Ping.

jdk-submit tests came back clean.

Thanks, Thomas

On Wed, Jun 6, 2018 at 6:05 PM, Thomas Stüfe <[hidden email]> wrote:

> Dear all,
>
> may I please have feedback and if possible reviews for this small addition:
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8203343
> Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/
>
> (Note: this patch goes atop of
> https://bugs.openjdk.java.net/browse/JDK-8203682, which is currently
> up for RFR).
>
> ---
>
> When analyzing situations involving a lot of reflection, one often
> stares at walls of "GeneratedXXXAccessorXXX" classes. These names are
> generated and not at all helpful in analyzing the problem (e.g. which
> component in a server node does this much reflection and hence uses so
> much metaspace).
>
> This patch adds the ability to print out invocation targets
> additionally to class names if the class is a generated accessor - for
> now this ability has been added to VM.metaspace, VM.classloaders and
> VM.class_hierarchy.
>
> Example output from "VM.class_hierarchy":
>
> <snip>
> |--jdk.internal.reflect.MagicAccessorImpl/null
> <snip>
> |  |--jdk.internal.reflect.ConstructorAccessorImpl/null
> |  |  |--jdk.internal.reflect.GeneratedConstructorAccessor18/0x00007f9ee8350c10
> (invokes: org/springframework/boot/context/properties/ConfigurationPropertiesBindingPostProcessorRegistrar::<init>
> ()V)
> |  |  |--jdk.internal.reflect.GeneratedConstructorAccessor17/0x00007f9ee8349c00
> (invokes: org/springframework/boot/context/properties/EnableConfigurationPropertiesImportSelector$ConfigurationPropertiesBeanRegistrar::<init>
> ()V)
> <snip>
> |  |--jdk.internal.reflect.MethodAccessorImpl/null
> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor23/0x00007f9ec8329b60
> (invokes: org/apache/tomcat/util/modeler/AttributeInfo::setIs (Z)V)
> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor22/0x00007f9ee831bc70
> (invokes: org/springframework/boot/autoconfigure/SpringBootApplication::exclude
> ()[Ljava/lang/Class;)
> <snip>
>
> See here more examples:
>
> "VM.class_hierarchy"
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.class_hierarchy.txt
>
> "VM.classloaders show-classes"
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.classloaders.txt
>
>
> ----
>
> Note: I am not sure if this is a fit for hotspot-runtime or
> serviceability. Sorry for crossposting.
>
> Thank you,
>
> Thomas
Reply | Threaded
Open this post in threaded view
|

Re: RFR(s): 8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes

coleen.phillimore

This change looks very useful.

http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/src/hotspot/share/oops/reflectionAccessorImplKlassHelper.hpp.html

Can you have a forward declaration of InstanceKlass and Klass and not
include instanceKlass.hpp ?  I don't need to see an additional webrev
for this change.

Otherwise, this looks good.  Thank you for removing (now) unnecessary
includes in

http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/src/hotspot/share/memory/metaspace/printMetaspaceInfoKlassClosure.cpp.udiff.html

Thanks,
Coleen

On 6/12/18 1:36 AM, Thomas Stüfe wrote:

> Ping.
>
> jdk-submit tests came back clean.
>
> Thanks, Thomas
>
> On Wed, Jun 6, 2018 at 6:05 PM, Thomas Stüfe <[hidden email]> wrote:
>> Dear all,
>>
>> may I please have feedback and if possible reviews for this small addition:
>>
>> CR: https://bugs.openjdk.java.net/browse/JDK-8203343
>> Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/
>>
>> (Note: this patch goes atop of
>> https://bugs.openjdk.java.net/browse/JDK-8203682, which is currently
>> up for RFR).
>>
>> ---
>>
>> When analyzing situations involving a lot of reflection, one often
>> stares at walls of "GeneratedXXXAccessorXXX" classes. These names are
>> generated and not at all helpful in analyzing the problem (e.g. which
>> component in a server node does this much reflection and hence uses so
>> much metaspace).
>>
>> This patch adds the ability to print out invocation targets
>> additionally to class names if the class is a generated accessor - for
>> now this ability has been added to VM.metaspace, VM.classloaders and
>> VM.class_hierarchy.
>>
>> Example output from "VM.class_hierarchy":
>>
>> <snip>
>> |--jdk.internal.reflect.MagicAccessorImpl/null
>> <snip>
>> |  |--jdk.internal.reflect.ConstructorAccessorImpl/null
>> |  |  |--jdk.internal.reflect.GeneratedConstructorAccessor18/0x00007f9ee8350c10
>> (invokes: org/springframework/boot/context/properties/ConfigurationPropertiesBindingPostProcessorRegistrar::<init>
>> ()V)
>> |  |  |--jdk.internal.reflect.GeneratedConstructorAccessor17/0x00007f9ee8349c00
>> (invokes: org/springframework/boot/context/properties/EnableConfigurationPropertiesImportSelector$ConfigurationPropertiesBeanRegistrar::<init>
>> ()V)
>> <snip>
>> |  |--jdk.internal.reflect.MethodAccessorImpl/null
>> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor23/0x00007f9ec8329b60
>> (invokes: org/apache/tomcat/util/modeler/AttributeInfo::setIs (Z)V)
>> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor22/0x00007f9ee831bc70
>> (invokes: org/springframework/boot/autoconfigure/SpringBootApplication::exclude
>> ()[Ljava/lang/Class;)
>> <snip>
>>
>> See here more examples:
>>
>> "VM.class_hierarchy"
>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.class_hierarchy.txt
>>
>> "VM.classloaders show-classes"
>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.classloaders.txt
>>
>>
>> ----
>>
>> Note: I am not sure if this is a fit for hotspot-runtime or
>> serviceability. Sorry for crossposting.
>>
>> Thank you,
>>
>> Thomas

Reply | Threaded
Open this post in threaded view
|

Re: RFR(s): 8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes

Thomas Stüfe-2
On Tue, Jun 12, 2018 at 4:58 PM,  <[hidden email]> wrote:
>
> This change looks very useful.
>

:) Thanks!

> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/src/hotspot/share/oops/reflectionAccessorImplKlassHelper.hpp.html
>
> Can you have a forward declaration of InstanceKlass and Klass and not
> include instanceKlass.hpp ?  I don't need to see an additional webrev for
> this change.
>

Sure.

> Otherwise, this looks good.  Thank you for removing (now) unnecessary
> includes in
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/src/hotspot/share/memory/metaspace/printMetaspaceInfoKlassClosure.cpp.udiff.html
>
> Thanks,
> Coleen
>
>

Thank you for the review,

..Thomas

> On 6/12/18 1:36 AM, Thomas Stüfe wrote:
>>
>> Ping.
>>
>> jdk-submit tests came back clean.
>>
>> Thanks, Thomas
>>
>> On Wed, Jun 6, 2018 at 6:05 PM, Thomas Stüfe <[hidden email]>
>> wrote:
>>>
>>> Dear all,
>>>
>>> may I please have feedback and if possible reviews for this small
>>> addition:
>>>
>>> CR: https://bugs.openjdk.java.net/browse/JDK-8203343
>>> Webrev:
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/
>>>
>>> (Note: this patch goes atop of
>>> https://bugs.openjdk.java.net/browse/JDK-8203682, which is currently
>>> up for RFR).
>>>
>>> ---
>>>
>>> When analyzing situations involving a lot of reflection, one often
>>> stares at walls of "GeneratedXXXAccessorXXX" classes. These names are
>>> generated and not at all helpful in analyzing the problem (e.g. which
>>> component in a server node does this much reflection and hence uses so
>>> much metaspace).
>>>
>>> This patch adds the ability to print out invocation targets
>>> additionally to class names if the class is a generated accessor - for
>>> now this ability has been added to VM.metaspace, VM.classloaders and
>>> VM.class_hierarchy.
>>>
>>> Example output from "VM.class_hierarchy":
>>>
>>> <snip>
>>> |--jdk.internal.reflect.MagicAccessorImpl/null
>>> <snip>
>>> |  |--jdk.internal.reflect.ConstructorAccessorImpl/null
>>> |  |
>>> |--jdk.internal.reflect.GeneratedConstructorAccessor18/0x00007f9ee8350c10
>>> (invokes:
>>> org/springframework/boot/context/properties/ConfigurationPropertiesBindingPostProcessorRegistrar::<init>
>>> ()V)
>>> |  |
>>> |--jdk.internal.reflect.GeneratedConstructorAccessor17/0x00007f9ee8349c00
>>> (invokes:
>>> org/springframework/boot/context/properties/EnableConfigurationPropertiesImportSelector$ConfigurationPropertiesBeanRegistrar::<init>
>>> ()V)
>>> <snip>
>>> |  |--jdk.internal.reflect.MethodAccessorImpl/null
>>> |  |
>>> |--jdk.internal.reflect.GeneratedMethodAccessor23/0x00007f9ec8329b60
>>> (invokes: org/apache/tomcat/util/modeler/AttributeInfo::setIs (Z)V)
>>> |  |
>>> |--jdk.internal.reflect.GeneratedMethodAccessor22/0x00007f9ee831bc70
>>> (invokes:
>>> org/springframework/boot/autoconfigure/SpringBootApplication::exclude
>>> ()[Ljava/lang/Class;)
>>> <snip>
>>>
>>> See here more examples:
>>>
>>> "VM.class_hierarchy"
>>>
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.class_hierarchy.txt
>>>
>>> "VM.classloaders show-classes"
>>>
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.classloaders.txt
>>>
>>>
>>> ----
>>>
>>> Note: I am not sure if this is a fit for hotspot-runtime or
>>> serviceability. Sorry for crossposting.
>>>
>>> Thank you,
>>>
>>> Thomas
>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR(s): 8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes

serguei.spitsyn@oracle.com
In reply to this post by Kirk Pepperdine-2
Hi Thomas,

It looks good to me.
But I'm not an expert in the area of Generated Accessors.

How was this tested?
Does it make sense to add a unit test for this?

Thanks,
Serguei


On 6/6/18 09:05, Thomas Stüfe wrote:

> Dear all,
>
> may I please have feedback and if possible reviews for this small addition:
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8203343
> Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/
>
> (Note: this patch goes atop of
> https://bugs.openjdk.java.net/browse/JDK-8203682, which is currently
> up for RFR).
>
> ---
>
> When analyzing situations involving a lot of reflection, one often
> stares at walls of "GeneratedXXXAccessorXXX" classes. These names are
> generated and not at all helpful in analyzing the problem (e.g. which
> component in a server node does this much reflection and hence uses so
> much metaspace).
>
> This patch adds the ability to print out invocation targets
> additionally to class names if the class is a generated accessor - for
> now this ability has been added to VM.metaspace, VM.classloaders and
> VM.class_hierarchy.
>
> Example output from "VM.class_hierarchy":
>
> <snip>
> |--jdk.internal.reflect.MagicAccessorImpl/null
> <snip>
> |  |--jdk.internal.reflect.ConstructorAccessorImpl/null
> |  |  |--jdk.internal.reflect.GeneratedConstructorAccessor18/0x00007f9ee8350c10
> (invokes: org/springframework/boot/context/properties/ConfigurationPropertiesBindingPostProcessorRegistrar::<init>
> ()V)
> |  |  |--jdk.internal.reflect.GeneratedConstructorAccessor17/0x00007f9ee8349c00
> (invokes: org/springframework/boot/context/properties/EnableConfigurationPropertiesImportSelector$ConfigurationPropertiesBeanRegistrar::<init>
> ()V)
> <snip>
> |  |--jdk.internal.reflect.MethodAccessorImpl/null
> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor23/0x00007f9ec8329b60
> (invokes: org/apache/tomcat/util/modeler/AttributeInfo::setIs (Z)V)
> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor22/0x00007f9ee831bc70
> (invokes: org/springframework/boot/autoconfigure/SpringBootApplication::exclude
> ()[Ljava/lang/Class;)
> <snip>
>
> See here more examples:
>
> "VM.class_hierarchy"
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.class_hierarchy.txt
>
> "VM.classloaders show-classes"
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.classloaders.txt
>
>
> ----
>
> Note: I am not sure if this is a fit for hotspot-runtime or
> serviceability. Sorry for crossposting.
>
> Thank you,
>
> Thomas

Reply | Threaded
Open this post in threaded view
|

Re: RFR(s): 8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes

coleen.phillimore

http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.01/webrev/test/hotspot/jtreg/serviceability/dcmd/vm/ShowReflectionTargetTest.java.html

Minor comment in copyright date.  Since it's a new test, it doesn't need
2014 as a start date.

Otherwise, looks good.
Thanks,
Coleen

On 6/13/18 6:32 AM, Thomas Stüfe wrote:

> Hi Serguei,
>
> thank you for your review!
>
> You are right, a regression test makes sense here. I wrote one. See
> updated webrev (only added the test, nothing else did change):
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.01/webrev/
>
> I am re-running the jdk-submit tests.
>
> Thanks & Best Regards, Thomas
>
> On Tue, Jun 12, 2018 at 11:01 PM, [hidden email]
> <[hidden email]> wrote:
>> Hi Thomas,
>>
>> It looks good to me.
>> But I'm not an expert in the area of Generated Accessors.
>>
>> How was this tested?
>> Does it make sense to add a unit test for this?
>>
>> Thanks,
>> Serguei
>>
>>
>>
>> On 6/6/18 09:05, Thomas Stüfe wrote:
>>> Dear all,
>>>
>>> may I please have feedback and if possible reviews for this small
>>> addition:
>>>
>>> CR: https://bugs.openjdk.java.net/browse/JDK-8203343
>>> Webrev:
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/
>>>
>>> (Note: this patch goes atop of
>>> https://bugs.openjdk.java.net/browse/JDK-8203682, which is currently
>>> up for RFR).
>>>
>>> ---
>>>
>>> When analyzing situations involving a lot of reflection, one often
>>> stares at walls of "GeneratedXXXAccessorXXX" classes. These names are
>>> generated and not at all helpful in analyzing the problem (e.g. which
>>> component in a server node does this much reflection and hence uses so
>>> much metaspace).
>>>
>>> This patch adds the ability to print out invocation targets
>>> additionally to class names if the class is a generated accessor - for
>>> now this ability has been added to VM.metaspace, VM.classloaders and
>>> VM.class_hierarchy.
>>>
>>> Example output from "VM.class_hierarchy":
>>>
>>> <snip>
>>> |--jdk.internal.reflect.MagicAccessorImpl/null
>>> <snip>
>>> |  |--jdk.internal.reflect.ConstructorAccessorImpl/null
>>> |  |
>>> |--jdk.internal.reflect.GeneratedConstructorAccessor18/0x00007f9ee8350c10
>>> (invokes:
>>> org/springframework/boot/context/properties/ConfigurationPropertiesBindingPostProcessorRegistrar::<init>
>>> ()V)
>>> |  |
>>> |--jdk.internal.reflect.GeneratedConstructorAccessor17/0x00007f9ee8349c00
>>> (invokes:
>>> org/springframework/boot/context/properties/EnableConfigurationPropertiesImportSelector$ConfigurationPropertiesBeanRegistrar::<init>
>>> ()V)
>>> <snip>
>>> |  |--jdk.internal.reflect.MethodAccessorImpl/null
>>> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor23/0x00007f9ec8329b60
>>> (invokes: org/apache/tomcat/util/modeler/AttributeInfo::setIs (Z)V)
>>> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor22/0x00007f9ee831bc70
>>> (invokes:
>>> org/springframework/boot/autoconfigure/SpringBootApplication::exclude
>>> ()[Ljava/lang/Class;)
>>> <snip>
>>>
>>> See here more examples:
>>>
>>> "VM.class_hierarchy"
>>>
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.class_hierarchy.txt
>>>
>>> "VM.classloaders show-classes"
>>>
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.classloaders.txt
>>>
>>>
>>> ----
>>>
>>> Note: I am not sure if this is a fit for hotspot-runtime or
>>> serviceability. Sorry for crossposting.
>>>
>>> Thank you,
>>>
>>> Thomas
>>

Reply | Threaded
Open this post in threaded view
|

Re: RFR(s): 8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes

Thomas Stüfe-2
Oh, copy paste error. I’ll correct that. Thanks, Coleen!

On Wed 13. Jun 2018 at 21:42, <[hidden email]> wrote:

>
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.01/webrev/test/hotspot/jtreg/serviceability/dcmd/vm/ShowReflectionTargetTest.java.html
>
> Minor comment in copyright date.  Since it's a new test, it doesn't need
> 2014 as a start date.
>
> Otherwise, looks good.
> Thanks,
> Coleen
>
> On 6/13/18 6:32 AM, Thomas Stüfe wrote:
> > Hi Serguei,
> >
> > thank you for your review!
> >
> > You are right, a regression test makes sense here. I wrote one. See
> > updated webrev (only added the test, nothing else did change):
> >
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.01/webrev/
> >
> > I am re-running the jdk-submit tests.
> >
> > Thanks & Best Regards, Thomas
> >
> > On Tue, Jun 12, 2018 at 11:01 PM, [hidden email]
> > <[hidden email]> wrote:
> >> Hi Thomas,
> >>
> >> It looks good to me.
> >> But I'm not an expert in the area of Generated Accessors.
> >>
> >> How was this tested?
> >> Does it make sense to add a unit test for this?
> >>
> >> Thanks,
> >> Serguei
> >>
> >>
> >>
> >> On 6/6/18 09:05, Thomas Stüfe wrote:
> >>> Dear all,
> >>>
> >>> may I please have feedback and if possible reviews for this small
> >>> addition:
> >>>
> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8203343
> >>> Webrev:
> >>>
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/
> >>>
> >>> (Note: this patch goes atop of
> >>> https://bugs.openjdk.java.net/browse/JDK-8203682, which is currently
> >>> up for RFR).
> >>>
> >>> ---
> >>>
> >>> When analyzing situations involving a lot of reflection, one often
> >>> stares at walls of "GeneratedXXXAccessorXXX" classes. These names are
> >>> generated and not at all helpful in analyzing the problem (e.g. which
> >>> component in a server node does this much reflection and hence uses so
> >>> much metaspace).
> >>>
> >>> This patch adds the ability to print out invocation targets
> >>> additionally to class names if the class is a generated accessor - for
> >>> now this ability has been added to VM.metaspace, VM.classloaders and
> >>> VM.class_hierarchy.
> >>>
> >>> Example output from "VM.class_hierarchy":
> >>>
> >>> <snip>
> >>> |--jdk.internal.reflect.MagicAccessorImpl/null
> >>> <snip>
> >>> |  |--jdk.internal.reflect.ConstructorAccessorImpl/null
> >>> |  |
> >>>
> |--jdk.internal.reflect.GeneratedConstructorAccessor18/0x00007f9ee8350c10
> >>> (invokes:
> >>>
> org/springframework/boot/context/properties/ConfigurationPropertiesBindingPostProcessorRegistrar::<init>
> >>> ()V)
> >>> |  |
> >>>
> |--jdk.internal.reflect.GeneratedConstructorAccessor17/0x00007f9ee8349c00
> >>> (invokes:
> >>>
> org/springframework/boot/context/properties/EnableConfigurationPropertiesImportSelector$ConfigurationPropertiesBeanRegistrar::<init>
> >>> ()V)
> >>> <snip>
> >>> |  |--jdk.internal.reflect.MethodAccessorImpl/null
> >>> |  |
> |--jdk.internal.reflect.GeneratedMethodAccessor23/0x00007f9ec8329b60
> >>> (invokes: org/apache/tomcat/util/modeler/AttributeInfo::setIs (Z)V)
> >>> |  |
> |--jdk.internal.reflect.GeneratedMethodAccessor22/0x00007f9ee831bc70
> >>> (invokes:
> >>> org/springframework/boot/autoconfigure/SpringBootApplication::exclude
> >>> ()[Ljava/lang/Class;)
> >>> <snip>
> >>>
> >>> See here more examples:
> >>>
> >>> "VM.class_hierarchy"
> >>>
> >>>
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.class_hierarchy.txt
> >>>
> >>> "VM.classloaders show-classes"
> >>>
> >>>
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.classloaders.txt
> >>>
> >>>
> >>> ----
> >>>
> >>> Note: I am not sure if this is a fit for hotspot-runtime or
> >>> serviceability. Sorry for crossposting.
> >>>
> >>> Thank you,
> >>>
> >>> Thomas
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR(s): 8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes

David Holmes
In reply to this post by serguei.spitsyn@oracle.com
Hi Thomas,

Just a nit in the test:

  54         // Do some reflection, enough times to hit the
sun.reflect.inflationThreshold and force
   55         // generation of reflection accessor classes.
    ...
   59         for (int i = 0; i < 100; i ++) {

The default threshold is only 15. The test is already assuming it knows
what the threshold is so it may as well only run 15 (16?) times; or else
explicitly set the threshold and use a loop count to match. Or even
better disable inflation and you don't need a loop at all.

I didn't look at anything else.

Cheers,
David

On 13/06/2018 8:32 PM, Thomas Stüfe wrote:

> Hi Serguei,
>
> thank you for your review!
>
> You are right, a regression test makes sense here. I wrote one. See
> updated webrev (only added the test, nothing else did change):
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.01/webrev/
>
> I am re-running the jdk-submit tests.
>
> Thanks & Best Regards, Thomas
>
> On Tue, Jun 12, 2018 at 11:01 PM, [hidden email]
> <[hidden email]> wrote:
>> Hi Thomas,
>>
>> It looks good to me.
>> But I'm not an expert in the area of Generated Accessors.
>>
>> How was this tested?
>> Does it make sense to add a unit test for this?
>>
>> Thanks,
>> Serguei
>>
>>
>>
>> On 6/6/18 09:05, Thomas Stüfe wrote:
>>>
>>> Dear all,
>>>
>>> may I please have feedback and if possible reviews for this small
>>> addition:
>>>
>>> CR: https://bugs.openjdk.java.net/browse/JDK-8203343
>>> Webrev:
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/
>>>
>>> (Note: this patch goes atop of
>>> https://bugs.openjdk.java.net/browse/JDK-8203682, which is currently
>>> up for RFR).
>>>
>>> ---
>>>
>>> When analyzing situations involving a lot of reflection, one often
>>> stares at walls of "GeneratedXXXAccessorXXX" classes. These names are
>>> generated and not at all helpful in analyzing the problem (e.g. which
>>> component in a server node does this much reflection and hence uses so
>>> much metaspace).
>>>
>>> This patch adds the ability to print out invocation targets
>>> additionally to class names if the class is a generated accessor - for
>>> now this ability has been added to VM.metaspace, VM.classloaders and
>>> VM.class_hierarchy.
>>>
>>> Example output from "VM.class_hierarchy":
>>>
>>> <snip>
>>> |--jdk.internal.reflect.MagicAccessorImpl/null
>>> <snip>
>>> |  |--jdk.internal.reflect.ConstructorAccessorImpl/null
>>> |  |
>>> |--jdk.internal.reflect.GeneratedConstructorAccessor18/0x00007f9ee8350c10
>>> (invokes:
>>> org/springframework/boot/context/properties/ConfigurationPropertiesBindingPostProcessorRegistrar::<init>
>>> ()V)
>>> |  |
>>> |--jdk.internal.reflect.GeneratedConstructorAccessor17/0x00007f9ee8349c00
>>> (invokes:
>>> org/springframework/boot/context/properties/EnableConfigurationPropertiesImportSelector$ConfigurationPropertiesBeanRegistrar::<init>
>>> ()V)
>>> <snip>
>>> |  |--jdk.internal.reflect.MethodAccessorImpl/null
>>> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor23/0x00007f9ec8329b60
>>> (invokes: org/apache/tomcat/util/modeler/AttributeInfo::setIs (Z)V)
>>> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor22/0x00007f9ee831bc70
>>> (invokes:
>>> org/springframework/boot/autoconfigure/SpringBootApplication::exclude
>>> ()[Ljava/lang/Class;)
>>> <snip>
>>>
>>> See here more examples:
>>>
>>> "VM.class_hierarchy"
>>>
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.class_hierarchy.txt
>>>
>>> "VM.classloaders show-classes"
>>>
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.classloaders.txt
>>>
>>>
>>> ----
>>>
>>> Note: I am not sure if this is a fit for hotspot-runtime or
>>> serviceability. Sorry for crossposting.
>>>
>>> Thank you,
>>>
>>> Thomas
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: RFR(s): 8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes

Thomas Stüfe-2
On Thu, Jun 14, 2018 at 7:11 AM, David Holmes <[hidden email]> wrote:

> Hi Thomas,
>
> Just a nit in the test:
>
>  54         // Do some reflection, enough times to hit the
> sun.reflect.inflationThreshold and force
>   55         // generation of reflection accessor classes.
>    ...
>   59         for (int i = 0; i < 100; i ++) {
>
> The default threshold is only 15. The test is already assuming it knows what
> the threshold is so it may as well only run 15 (16?) times; or else
> explicitly set the threshold and use a loop count to match. Or even better
> disable inflation and you don't need a loop at all.
>

Yes, you are right, that would be cleaner.

I was not sure how to set -Ds.r.noInflation, but I will check if this
can be done.

Thanks, Thomas

> I didn't look at anything else.
>
> Cheers,
> David
>
>
> On 13/06/2018 8:32 PM, Thomas Stüfe wrote:
>>
>> Hi Serguei,
>>
>> thank you for your review!
>>
>> You are right, a regression test makes sense here. I wrote one. See
>> updated webrev (only added the test, nothing else did change):
>>
>>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.01/webrev/
>>
>> I am re-running the jdk-submit tests.
>>
>> Thanks & Best Regards, Thomas
>>
>> On Tue, Jun 12, 2018 at 11:01 PM, [hidden email]
>> <[hidden email]> wrote:
>>>
>>> Hi Thomas,
>>>
>>> It looks good to me.
>>> But I'm not an expert in the area of Generated Accessors.
>>>
>>> How was this tested?
>>> Does it make sense to add a unit test for this?
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>>
>>> On 6/6/18 09:05, Thomas Stüfe wrote:
>>>>
>>>>
>>>> Dear all,
>>>>
>>>> may I please have feedback and if possible reviews for this small
>>>> addition:
>>>>
>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8203343
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/
>>>>
>>>> (Note: this patch goes atop of
>>>> https://bugs.openjdk.java.net/browse/JDK-8203682, which is currently
>>>> up for RFR).
>>>>
>>>> ---
>>>>
>>>> When analyzing situations involving a lot of reflection, one often
>>>> stares at walls of "GeneratedXXXAccessorXXX" classes. These names are
>>>> generated and not at all helpful in analyzing the problem (e.g. which
>>>> component in a server node does this much reflection and hence uses so
>>>> much metaspace).
>>>>
>>>> This patch adds the ability to print out invocation targets
>>>> additionally to class names if the class is a generated accessor - for
>>>> now this ability has been added to VM.metaspace, VM.classloaders and
>>>> VM.class_hierarchy.
>>>>
>>>> Example output from "VM.class_hierarchy":
>>>>
>>>> <snip>
>>>> |--jdk.internal.reflect.MagicAccessorImpl/null
>>>> <snip>
>>>> |  |--jdk.internal.reflect.ConstructorAccessorImpl/null
>>>> |  |
>>>>
>>>> |--jdk.internal.reflect.GeneratedConstructorAccessor18/0x00007f9ee8350c10
>>>> (invokes:
>>>>
>>>> org/springframework/boot/context/properties/ConfigurationPropertiesBindingPostProcessorRegistrar::<init>
>>>> ()V)
>>>> |  |
>>>>
>>>> |--jdk.internal.reflect.GeneratedConstructorAccessor17/0x00007f9ee8349c00
>>>> (invokes:
>>>>
>>>> org/springframework/boot/context/properties/EnableConfigurationPropertiesImportSelector$ConfigurationPropertiesBeanRegistrar::<init>
>>>> ()V)
>>>> <snip>
>>>> |  |--jdk.internal.reflect.MethodAccessorImpl/null
>>>> |  |
>>>> |--jdk.internal.reflect.GeneratedMethodAccessor23/0x00007f9ec8329b60
>>>> (invokes: org/apache/tomcat/util/modeler/AttributeInfo::setIs (Z)V)
>>>> |  |
>>>> |--jdk.internal.reflect.GeneratedMethodAccessor22/0x00007f9ee831bc70
>>>> (invokes:
>>>> org/springframework/boot/autoconfigure/SpringBootApplication::exclude
>>>> ()[Ljava/lang/Class;)
>>>> <snip>
>>>>
>>>> See here more examples:
>>>>
>>>> "VM.class_hierarchy"
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.class_hierarchy.txt
>>>>
>>>> "VM.classloaders show-classes"
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.classloaders.txt
>>>>
>>>>
>>>> ----
>>>>
>>>> Note: I am not sure if this is a fit for hotspot-runtime or
>>>> serviceability. Sorry for crossposting.
>>>>
>>>> Thank you,
>>>>
>>>> Thomas
>>>
>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR(s): 8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes

Thomas Stüfe-2
In reply to this post by Kirk Pepperdine-2
Hi all,

hopefully last changes, with feedback added from Coleen and David.

Only changes in the provided regression test: I run it now with
-Dsun.reflect.noInflation to make the test independent from the
reflection inflation threshold. I also corrected the copyright dates.

Delta: http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.01-to-02/webrev/
Full: http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.02/webrev/

Thank you,

Thomas


On Wed, Jun 6, 2018 at 6:05 PM, Thomas Stüfe <[hidden email]> wrote:

> Dear all,
>
> may I please have feedback and if possible reviews for this small addition:
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8203343
> Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/
>
> (Note: this patch goes atop of
> https://bugs.openjdk.java.net/browse/JDK-8203682, which is currently
> up for RFR).
>
> ---
>
> When analyzing situations involving a lot of reflection, one often
> stares at walls of "GeneratedXXXAccessorXXX" classes. These names are
> generated and not at all helpful in analyzing the problem (e.g. which
> component in a server node does this much reflection and hence uses so
> much metaspace).
>
> This patch adds the ability to print out invocation targets
> additionally to class names if the class is a generated accessor - for
> now this ability has been added to VM.metaspace, VM.classloaders and
> VM.class_hierarchy.
>
> Example output from "VM.class_hierarchy":
>
> <snip>
> |--jdk.internal.reflect.MagicAccessorImpl/null
> <snip>
> |  |--jdk.internal.reflect.ConstructorAccessorImpl/null
> |  |  |--jdk.internal.reflect.GeneratedConstructorAccessor18/0x00007f9ee8350c10
> (invokes: org/springframework/boot/context/properties/ConfigurationPropertiesBindingPostProcessorRegistrar::<init>
> ()V)
> |  |  |--jdk.internal.reflect.GeneratedConstructorAccessor17/0x00007f9ee8349c00
> (invokes: org/springframework/boot/context/properties/EnableConfigurationPropertiesImportSelector$ConfigurationPropertiesBeanRegistrar::<init>
> ()V)
> <snip>
> |  |--jdk.internal.reflect.MethodAccessorImpl/null
> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor23/0x00007f9ec8329b60
> (invokes: org/apache/tomcat/util/modeler/AttributeInfo::setIs (Z)V)
> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor22/0x00007f9ee831bc70
> (invokes: org/springframework/boot/autoconfigure/SpringBootApplication::exclude
> ()[Ljava/lang/Class;)
> <snip>
>
> See here more examples:
>
> "VM.class_hierarchy"
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.class_hierarchy.txt
>
> "VM.classloaders show-classes"
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.classloaders.txt
>
>
> ----
>
> Note: I am not sure if this is a fit for hotspot-runtime or
> serviceability. Sorry for crossposting.
>
> Thank you,
>
> Thomas
Reply | Threaded
Open this post in threaded view
|

Re: RFR(s): 8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes

coleen.phillimore

This was a good find of David's.  Thank you for fixing the test.
Coleen

On 6/14/18 7:30 AM, Thomas Stüfe wrote:

> Hi all,
>
> hopefully last changes, with feedback added from Coleen and David.
>
> Only changes in the provided regression test: I run it now with
> -Dsun.reflect.noInflation to make the test independent from the
> reflection inflation threshold. I also corrected the copyright dates.
>
> Delta: http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.01-to-02/webrev/
> Full: http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.02/webrev/
>
> Thank you,
>
> Thomas
>
>
> On Wed, Jun 6, 2018 at 6:05 PM, Thomas Stüfe <[hidden email]> wrote:
>> Dear all,
>>
>> may I please have feedback and if possible reviews for this small addition:
>>
>> CR: https://bugs.openjdk.java.net/browse/JDK-8203343
>> Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/
>>
>> (Note: this patch goes atop of
>> https://bugs.openjdk.java.net/browse/JDK-8203682, which is currently
>> up for RFR).
>>
>> ---
>>
>> When analyzing situations involving a lot of reflection, one often
>> stares at walls of "GeneratedXXXAccessorXXX" classes. These names are
>> generated and not at all helpful in analyzing the problem (e.g. which
>> component in a server node does this much reflection and hence uses so
>> much metaspace).
>>
>> This patch adds the ability to print out invocation targets
>> additionally to class names if the class is a generated accessor - for
>> now this ability has been added to VM.metaspace, VM.classloaders and
>> VM.class_hierarchy.
>>
>> Example output from "VM.class_hierarchy":
>>
>> <snip>
>> |--jdk.internal.reflect.MagicAccessorImpl/null
>> <snip>
>> |  |--jdk.internal.reflect.ConstructorAccessorImpl/null
>> |  |  |--jdk.internal.reflect.GeneratedConstructorAccessor18/0x00007f9ee8350c10
>> (invokes: org/springframework/boot/context/properties/ConfigurationPropertiesBindingPostProcessorRegistrar::<init>
>> ()V)
>> |  |  |--jdk.internal.reflect.GeneratedConstructorAccessor17/0x00007f9ee8349c00
>> (invokes: org/springframework/boot/context/properties/EnableConfigurationPropertiesImportSelector$ConfigurationPropertiesBeanRegistrar::<init>
>> ()V)
>> <snip>
>> |  |--jdk.internal.reflect.MethodAccessorImpl/null
>> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor23/0x00007f9ec8329b60
>> (invokes: org/apache/tomcat/util/modeler/AttributeInfo::setIs (Z)V)
>> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor22/0x00007f9ee831bc70
>> (invokes: org/springframework/boot/autoconfigure/SpringBootApplication::exclude
>> ()[Ljava/lang/Class;)
>> <snip>
>>
>> See here more examples:
>>
>> "VM.class_hierarchy"
>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.class_hierarchy.txt
>>
>> "VM.classloaders show-classes"
>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.classloaders.txt
>>
>>
>> ----
>>
>> Note: I am not sure if this is a fit for hotspot-runtime or
>> serviceability. Sorry for crossposting.
>>
>> Thank you,
>>
>> Thomas

Reply | Threaded
Open this post in threaded view
|

Re: RFR(s): 8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes

Thomas Stüfe-2
Thanks Coleen!

On Thu, Jun 14, 2018, 18:04 <[hidden email]> wrote:

>
> This was a good find of David's.  Thank you for fixing the test.
> Coleen
>
> On 6/14/18 7:30 AM, Thomas Stüfe wrote:
> > Hi all,
> >
> > hopefully last changes, with feedback added from Coleen and David.
> >
> > Only changes in the provided regression test: I run it now with
> > -Dsun.reflect.noInflation to make the test independent from the
> > reflection inflation threshold. I also corrected the copyright dates.
> >
> > Delta:
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.01-to-02/webrev/
> > Full:
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.02/webrev/
> >
> > Thank you,
> >
> > Thomas
> >
> >
> > On Wed, Jun 6, 2018 at 6:05 PM, Thomas Stüfe <[hidden email]>
> wrote:
> >> Dear all,
> >>
> >> may I please have feedback and if possible reviews for this small
> addition:
> >>
> >> CR: https://bugs.openjdk.java.net/browse/JDK-8203343
> >> Webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/
> >>
> >> (Note: this patch goes atop of
> >> https://bugs.openjdk.java.net/browse/JDK-8203682, which is currently
> >> up for RFR).
> >>
> >> ---
> >>
> >> When analyzing situations involving a lot of reflection, one often
> >> stares at walls of "GeneratedXXXAccessorXXX" classes. These names are
> >> generated and not at all helpful in analyzing the problem (e.g. which
> >> component in a server node does this much reflection and hence uses so
> >> much metaspace).
> >>
> >> This patch adds the ability to print out invocation targets
> >> additionally to class names if the class is a generated accessor - for
> >> now this ability has been added to VM.metaspace, VM.classloaders and
> >> VM.class_hierarchy.
> >>
> >> Example output from "VM.class_hierarchy":
> >>
> >> <snip>
> >> |--jdk.internal.reflect.MagicAccessorImpl/null
> >> <snip>
> >> |  |--jdk.internal.reflect.ConstructorAccessorImpl/null
> >> |  |
> |--jdk.internal.reflect.GeneratedConstructorAccessor18/0x00007f9ee8350c10
> >> (invokes:
> org/springframework/boot/context/properties/ConfigurationPropertiesBindingPostProcessorRegistrar::<init>
> >> ()V)
> >> |  |
> |--jdk.internal.reflect.GeneratedConstructorAccessor17/0x00007f9ee8349c00
> >> (invokes:
> org/springframework/boot/context/properties/EnableConfigurationPropertiesImportSelector$ConfigurationPropertiesBeanRegistrar::<init>
> >> ()V)
> >> <snip>
> >> |  |--jdk.internal.reflect.MethodAccessorImpl/null
> >> |  |
> |--jdk.internal.reflect.GeneratedMethodAccessor23/0x00007f9ec8329b60
> >> (invokes: org/apache/tomcat/util/modeler/AttributeInfo::setIs (Z)V)
> >> |  |
> |--jdk.internal.reflect.GeneratedMethodAccessor22/0x00007f9ee831bc70
> >> (invokes:
> org/springframework/boot/autoconfigure/SpringBootApplication::exclude
> >> ()[Ljava/lang/Class;)
> >> <snip>
> >>
> >> See here more examples:
> >>
> >> "VM.class_hierarchy"
> >>
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.class_hierarchy.txt
> >>
> >> "VM.classloaders show-classes"
> >>
> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.classloaders.txt
> >>
> >>
> >> ----
> >>
> >> Note: I am not sure if this is a fit for hotspot-runtime or
> >> serviceability. Sorry for crossposting.
> >>
> >> Thank you,
> >>
> >> Thomas
>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR(s): 8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes

serguei.spitsyn@oracle.com
In reply to this post by Thomas Stüfe-2
Hi Thomas,

The update looks good to me.

Thanks,
Serguei


On 6/14/18 04:30, Thomas Stüfe wrote:

> Hi all,
>
> hopefully last changes, with feedback added from Coleen and David.
>
> Only changes in the provided regression test: I run it now with
> -Dsun.reflect.noInflation to make the test independent from the
> reflection inflation threshold. I also corrected the copyright dates.
>
> Delta: http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.01-to-02/webrev/
> Full: http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.02/webrev/
>
> Thank you,
>
> Thomas
>
>
> On Wed, Jun 6, 2018 at 6:05 PM, Thomas Stüfe <[hidden email]> wrote:
>> Dear all,
>>
>> may I please have feedback and if possible reviews for this small addition:
>>
>> CR: https://bugs.openjdk.java.net/browse/JDK-8203343
>> Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/
>>
>> (Note: this patch goes atop of
>> https://bugs.openjdk.java.net/browse/JDK-8203682, which is currently
>> up for RFR).
>>
>> ---
>>
>> When analyzing situations involving a lot of reflection, one often
>> stares at walls of "GeneratedXXXAccessorXXX" classes. These names are
>> generated and not at all helpful in analyzing the problem (e.g. which
>> component in a server node does this much reflection and hence uses so
>> much metaspace).
>>
>> This patch adds the ability to print out invocation targets
>> additionally to class names if the class is a generated accessor - for
>> now this ability has been added to VM.metaspace, VM.classloaders and
>> VM.class_hierarchy.
>>
>> Example output from "VM.class_hierarchy":
>>
>> <snip>
>> |--jdk.internal.reflect.MagicAccessorImpl/null
>> <snip>
>> |  |--jdk.internal.reflect.ConstructorAccessorImpl/null
>> |  |  |--jdk.internal.reflect.GeneratedConstructorAccessor18/0x00007f9ee8350c10
>> (invokes: org/springframework/boot/context/properties/ConfigurationPropertiesBindingPostProcessorRegistrar::<init>
>> ()V)
>> |  |  |--jdk.internal.reflect.GeneratedConstructorAccessor17/0x00007f9ee8349c00
>> (invokes: org/springframework/boot/context/properties/EnableConfigurationPropertiesImportSelector$ConfigurationPropertiesBeanRegistrar::<init>
>> ()V)
>> <snip>
>> |  |--jdk.internal.reflect.MethodAccessorImpl/null
>> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor23/0x00007f9ec8329b60
>> (invokes: org/apache/tomcat/util/modeler/AttributeInfo::setIs (Z)V)
>> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor22/0x00007f9ee831bc70
>> (invokes: org/springframework/boot/autoconfigure/SpringBootApplication::exclude
>> ()[Ljava/lang/Class;)
>> <snip>
>>
>> See here more examples:
>>
>> "VM.class_hierarchy"
>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.class_hierarchy.txt
>>
>> "VM.classloaders show-classes"
>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.classloaders.txt
>>
>>
>> ----
>>
>> Note: I am not sure if this is a fit for hotspot-runtime or
>> serviceability. Sorry for crossposting.
>>
>> Thank you,
>>
>> Thomas

Reply | Threaded
Open this post in threaded view
|

Re: RFR(s): 8203343: VM.{metaspace|classloaders|classhierarchy...} jcmd should show invocation targets for Generated{Method|Constructor}AccessorImpl classes

David Holmes
In reply to this post by Thomas Stüfe-2
Test update looks good!

Thanks,
David

On 14/06/2018 9:30 PM, Thomas Stüfe wrote:

> Hi all,
>
> hopefully last changes, with feedback added from Coleen and David.
>
> Only changes in the provided regression test: I run it now with
> -Dsun.reflect.noInflation to make the test independent from the
> reflection inflation threshold. I also corrected the copyright dates.
>
> Delta: http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.01-to-02/webrev/
> Full: http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.02/webrev/
>
> Thank you,
>
> Thomas
>
>
> On Wed, Jun 6, 2018 at 6:05 PM, Thomas Stüfe <[hidden email]> wrote:
>> Dear all,
>>
>> may I please have feedback and if possible reviews for this small addition:
>>
>> CR: https://bugs.openjdk.java.net/browse/JDK-8203343
>> Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/
>>
>> (Note: this patch goes atop of
>> https://bugs.openjdk.java.net/browse/JDK-8203682, which is currently
>> up for RFR).
>>
>> ---
>>
>> When analyzing situations involving a lot of reflection, one often
>> stares at walls of "GeneratedXXXAccessorXXX" classes. These names are
>> generated and not at all helpful in analyzing the problem (e.g. which
>> component in a server node does this much reflection and hence uses so
>> much metaspace).
>>
>> This patch adds the ability to print out invocation targets
>> additionally to class names if the class is a generated accessor - for
>> now this ability has been added to VM.metaspace, VM.classloaders and
>> VM.class_hierarchy.
>>
>> Example output from "VM.class_hierarchy":
>>
>> <snip>
>> |--jdk.internal.reflect.MagicAccessorImpl/null
>> <snip>
>> |  |--jdk.internal.reflect.ConstructorAccessorImpl/null
>> |  |  |--jdk.internal.reflect.GeneratedConstructorAccessor18/0x00007f9ee8350c10
>> (invokes: org/springframework/boot/context/properties/ConfigurationPropertiesBindingPostProcessorRegistrar::<init>
>> ()V)
>> |  |  |--jdk.internal.reflect.GeneratedConstructorAccessor17/0x00007f9ee8349c00
>> (invokes: org/springframework/boot/context/properties/EnableConfigurationPropertiesImportSelector$ConfigurationPropertiesBeanRegistrar::<init>
>> ()V)
>> <snip>
>> |  |--jdk.internal.reflect.MethodAccessorImpl/null
>> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor23/0x00007f9ec8329b60
>> (invokes: org/apache/tomcat/util/modeler/AttributeInfo::setIs (Z)V)
>> |  |  |--jdk.internal.reflect.GeneratedMethodAccessor22/0x00007f9ee831bc70
>> (invokes: org/springframework/boot/autoconfigure/SpringBootApplication::exclude
>> ()[Ljava/lang/Class;)
>> <snip>
>>
>> See here more examples:
>>
>> "VM.class_hierarchy"
>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.class_hierarchy.txt
>>
>> "VM.classloaders show-classes"
>> http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/example-VM.classloaders.txt
>>
>>
>> ----
>>
>> Note: I am not sure if this is a fit for hotspot-runtime or
>> serviceability. Sorry for crossposting.
>>
>> Thank you,
>>
>> Thomas