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:
No one has answered this question. If you wish to pursue, please open a case
Actually support suggested this thread
Sorry you are going through multiple places:-(
. Adding Hiko_Davis Guenter_Grossberger Florian_Cheval to see if they can respond
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?
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.
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”?
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.