Review Request JDK-8181443: Replace usages of jdk.internal.misc.Unsafe with MethodHandles.Lookup.defineClass

Alan Bateman Alan.Bateman at
Sat Oct 6 07:43:16 UTC 2018

On 05/10/2018 17:14, Rafael Winterhalter wrote:
> :
> To make sure that this is considered properly, I want to lay out a 
> simple but common instrumentation use case once again to show how the 
> current API suggestion is too limited. Consider a basic 
> instrumentation for monitoring the runtime of a business transaction 
> that spans to classes. I keep it fairly simple but this is not too far 
> off to how some monitoring tools are actually implemented.
This discussion always comes to down to what the Instrumentation API is 
intended for. Some of these apparently "simple" cases aren't really 
simple as they are trying to use Instrumentation API in ways that were 
never intended. As we explained in the discussions on 
serviceability-dev, the intention was to support cases where code is 
instrumented with calls into agent provided supporting classes and 
reduce any dependence that can lead to circularity issues. It maybe that 
the current appendToXXXSearch is too limited as it doesn't help with 
cases where the agent is spinning the supporting classes at run-time, in 
which case there may be a useful discussion there. The 
serviceability-dev list is the right place for that.


More information about the core-libs-dev mailing list