First of all, what is JTI?
The HotSpot JVM is written in C + + and, at the operating system level, there is nothing special about the java.exe process and other processes. Any process that can load a third-party DLL,JTI is an interface that java.exe open to inject DLLs into the Java.exe process. That is to say, the developer according to JTI definition good specification, writes a DLL in C + +, this DLL can be loaded by the Java.exe process "to start the JVM to add-agentlib parameters."
JTI details are available at the following URL: http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html.
JNI doesn't have to say much.
What's interesting here is that if the JTI dll previously written by JNI, providing a direct calling interface to the Java program, the entire call path from the Java language to the JTI function is opened, as follows:
First, Java calls the methods in the JTI DLL through JNI.
We then write our own JTI DLL, access the JVM's internal structure through the JTI interface, and get internal information from the JVM and return.
Finally, the Java program obtains information inside the JVM.
So what internal information can JTI provide? Simply put, the Java debugger can get any information, JTI can be obtained, this is because the Java debugger is based on JTI write.
For two examples, the following are the two calling functions opened by JTI:
Getobjectsize: Gets the size of the memory that the specified object occupies.
Followreferences: Gets all objects that can be accessed from the specified object.
In other words, the Java code of the application layer can get the above function through the above call procedure, which is not on the common JDK.
Finally, the realization of this point does not know that there is no use, but it must be very interesting ...
JTI + JNI, providing a channel for Java programs to get internal information from the JVM