Hi Lim, JFR specific feedback can be posted to: hotspot-jfr-...@openjdk.java.net
Thanks Markus -----Original Message----- From: Lim <lim.chainz11+mail...@gmail.com> Sent: den 28 april 2021 12:18 To: Markus Gronlund <markus.gronl...@oracle.com> Cc: Ron Pressler <ron.press...@oracle.com>; security-dev@openjdk.java.net Subject: Re: JEP411: Missing use-case: Monitoring / restricting libraries Hi Markus, thank you for giving me the guidance for performing the JFR programmatically. I am able to test if my use case is suitable. Where do I provide my feedback/issue of using the streamed JFR? On Wed, Apr 21, 2021 at 10:32 PM Markus Gronlund <markus.gronl...@oracle.com> wrote: > If the existing event probes in the JDK does not give you the information you > need, like the name of URL's, it can be a reached by building your own > "custom events" via the Events API [3]. It can be harder to add events to > unknown code dynamically, but it can be done and you can use > java.lang.Instrument to build an agent to inject the custom event. I understand that new events can be added in code that I have control of using the Events API but in this case, which is the name of URLs is not feasible. Firstly, using a Java agent to instrument bytecode cannot be scaled because there are a lot of HTTP libraries, including the built in Java APIs and 3rd parties such as Apache HTTP, OkHttp. They can also roll their own "HTTP wrapper" if the author doesn't want dependency. In addition, these 3rd party libraries can be shaded and relocated, making it harder to target via instrumentation. Obfuscation can also have an impact on reliability of instrumentation, since obfuscation can be changed in every version and what if the obfuscation has "anti-tamper/anti-debug" features? This is not scalable if we need to monitor for each library that might call URLs. > If there is a general problem area and provides a good scaling factor, and > the URL information might just be such a case, it can make sense to > investigate if this information can be provided directly by the JDK, by > extending existing or new JFR events. I believe that the majority of the HTTP libraries, and code that roll their own are using the built in Java APIs, thus monitoring the built in API that is used for making URLs calls make sense. Then, it can be scaled to most of the libraries compared to instrumenting each one which has its own problem stated above.
