DX Application Performance Management

Expand all | Collapse all

Why no InstrumentBootstrapClass matching all classes

Jump to Best Answer
  • 1.  Why no InstrumentBootstrapClass matching all classes

    Posted 06-16-2016 04:39 PM

    A couple weeks ago I was curious if a poor entropy in /dev/random would affect SSL performance and so created a pbd to trace java.security.SecureRandom.

    So I had this:

         IdentifyMatchingClassesAs: java.security.*  SecureRandom

         InstrumentBootstrapClass:  java.security.SecureRandom  true

    The last line made me think of a couple of things:

    • why isn't there an InstrumentBootstrapMatchingClassesAs:  java.security.* true ?
    • while in this case I can understand the need for the InstrumentBootstrapClass, but are there any patterns to know which classes require this from the class list when you start your jvm with  -verbose:class


  • 2.  Re: Why no InstrumentBootstrapClass matching all classes

    Posted 06-21-2016 06:37 AM

    Fred:

    No one has answered this question. If you wish to pursue, please open a case

     

    Thanks

    Hal German



  • 3.  Re: Why no InstrumentBootstrapClass matching all classes

    Posted 06-21-2016 07:59 AM

    Hi Hal,

    Actually support suggested this thread

    Regards,

    Fred



  • 4.  Re: Why no InstrumentBootstrapClass matching all classes

    Posted 06-21-2016 08:09 AM

    Fred:

    Sorry you are going through multiple places:-(

    . Adding Hiko_Davis Guenter_Grossberger Florian_Cheval to see if they can respond

     

    Thanks

    Hal



  • 5.  Re: Why no InstrumentBootstrapClass matching all classes
    Best Answer

    Posted 06-21-2016 10:47 AM

    Well it is an interesting question.

     

    A direct answer to this question would be “because it has never really been required” ☺

     

    I’ll explain a bit more.

     

    IdentifyMatchingClassesAs is rarely needed in the first place. If you look at our out of the box pbds, you should see that none of them actually make use of it. That’s because most of the time, instrumentation is applied to a set of classes either inheriting from a same parent or implementing a common interface. The number of situations where one has to instrument a bunch of “unrelated” classes is quite low.

     

    I had to use it once, because the customer’s application “business logic” layer consisted of a bunch of classes, with a common base package, but all they had in common was that their name would end with “Business”. If you ask me (and I don’t pretend to be a developer by any mean), that’s quite uncommon (and quite dirty, you don’t want your apps to look like that ☺).

     

    There is a pretty valid use case for IdentifyMatchingClassesAs, and that’s when you’re trying to refine the instrumentation for an application. You’re not a developer, you don’t have the source code, you just want to see the “long running” not instrumented methods in your application.

     

    This use case can now mostly be satisfied with Smart Instrumentation, so the need for this directive is even lower than it ever was.

     

    Now as for “Bootstrap” classes, we’re talking about the first classes the the JRE runs at startup. So really core java classes.

     

    I don’t know about you, but the ability to instrument these classes en masse definitely doesn’t seem like a good idea, unless you’re really trying to kill the app ☺

     

    So my question to you is: What are you trying to do? Why would you want to instrument a bunch of bootstrap classes at once?



  • 6.  Re: Why no InstrumentBootstrapClass matching all classes

    Posted 06-21-2016 02:03 PM

    The Matching * is useful when you don't know what you are looking for and saves you from typing incorrectly. Of course this is temporary and not for production

    In this case I was trying to discover the classes which might use "/dev/random" then instrument only these classes for a larger audience.

    So it made me wonder if there is a clear indication in the javadoc or elsewhere what is a bootstrap classes.

    Thanks,

    Fred



  • 7.  Re: Why no InstrumentBootstrapClass matching all classes

    Posted 06-22-2016 11:13 AM

    I wrote this the other day:

     

    Exact answer (but useless): A “Bootstrap” class is a class is loaded by the bootstrap class loader!

     

    Inaccurate answer but probably more useful: anything that starts with java. or possibly javax. are likely to require InstrumentBootStrapClass.

     

    How would you link a particular class/method to its use of “/dev/random”?



  • 8.  Re: Why no InstrumentBootstrapClass matching all classes

    Posted 06-22-2016 07:07 PM

    Actually I have no quick idea. In a roundabout way I set a JVM property to use /dev/random. Since I have a test host with an extra bad entropy I was hoping to quickly find the classes/method with Matching * then sorting the ones taking a few seconds.

    So far paid attention only to SecureRandom.  I need a more complex app and do some more  stack traces.