Java was initially designed as a safe, managed environment. Nevertheless, Java HotSpot VM contains a “backdoor” that provides a number of low-level operations to manipulate memory and threads directly. This backdoor – sun.misc.Unsafe – is widely used by JDK itself in the packages like java.nio or java.util.concurrent. It is hard to imagine a Java developer who uses this backdoor in any regular development because this API is extremely dangerous, non portable, and volatile. Nevertheless, Unsafe provides an easy way to look into HotSpot JVM internals and do some tricks. Sometimes it is simply funny, sometimes it can be used to study VM internals without C++ code debugging, sometimes it can be leveraged for profiling and development tools.
Obtaining Unsafe
The sun.misc.Unsafe class is so unsafe that JDK developers added special checks to restrict access to it. Its constructor is private and caller of the factory method getUnsafe() should be loaded by Bootloader (i.e. caller should also be a part of JDK):
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
publicfinalclassUnsafe {
...
privateUnsafe() {}
privatestaticfinalUnsafe theUnsafe =newUnsafe();
...
publicstaticUnsafe getUnsafe() {
Class cc = sun.reflect.Reflection.getCallerClass(2);
if(cc.getClassLoader() !=null)
thrownewSecurityException("Unsafe");
returntheUnsafe;
}
...
}
|
Fortunately there is theUnsafe field that can be used to retrieve Unsafe instance. We can easily write a helper method to do this via reflection:
|
1
2
3
4
5
6
7
|
publicstaticUnsafe getUnsafe() {
try{
Field f = Unsafe.class.getDeclaredField("theUnsafe");
f.setAccessible(true);
return(Unsafe)f.get(null);
}catch(Exception e) {/* ... */}
}
|
In the next sections we will study several tricks that become possible due to the following methods of Unsafe:
- long getAddress(long address) and void putAddress(long address, long x) that allows to read and write dwords directly from memory.
- int getInt(Object o, long offset) , void putInt(Object o, long offset, int x), and other similar methods that allows to read and write data directly from C structure that represents Java object.
- long allocateMemory(long bytes) which can be considered as a wrapper for C’s malloc().
sizeof() Function
The first trick we will do is C-like sizeof() function, i.e. function that returns shallow object size in bytes. Inspecting JVM sources of JDK6 and JDK7, in particular src/share/vm/oops/oop.hpp and src/share/vm/oops/klass.hpp, and reading comments in the code, we can notice that size of class instance is stored in _layout_helper which is the fourth field in C structure that represents Java class. Similarly, /src/share/vm/oops/oop.hpp shows that each instance (i.e. object) stores pointer to a class structure in its second field. For 32-bit JVM this means that we can first take class structure address as 4-8 bytes in the object structure and next shift by 3×4=12 bytes inside class structure to capture_layout_helper field which is instance size in bytes. These structures are shown in the picture below:
As so, we can implement sizeof() as follows:
|
1
2
3
4
5
6
7
8
9
|
publicstaticlongsizeOf(Object object) {
Unsafe unsafe = getUnsafe();
returnunsafe.getAddress( normalize( unsafe.getInt(object, 4L) ) + 12L );
}
publicstaticlongnormalize(intvalue) {
if(value >=0)returnvalue;
return(~0L >>>32) & value;
}
|
We need to use normalize() function because addresses between 2^31 and 2^32 will be automatically converted to negative integers, i.e. stored in complement form. Let’s test it on 32-bit JVM (JDK 6 or 7):
|
1
2
3
4
5
|
// sizeOf(new MyStructure()) gives the following results:
classMyStructure { }// 8: 4 (start marker) + 4 (pointer to class)
classMyStructure {intx; }// 16: 4 (start marker) + 4 (pointer to class) + 4 (int) + 4 stuff bytes to align structure to 64-bit blocks
classMyStructure {intx;inty; }// 16: 4 (start marker) + 4 (pointer to class) + 2*4
|
This function will not work for array objects, because _layout_helper field has another meaning in that case. Although it is still possible to generalize sizeOf() to support arrays.
Direct Memory Management
Unsafe allows to allocate and deallocate memory explicitly via allocateMemory and freeMemory methods. Allocated memory is not under GC control and not limited by maximum JVM heap size. In general, such functionality is safely available via NIO’s off-heap bufferes. But the interesting thing is that it is possible to map standard Java reference to off-heap memory:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
MyStructure structure =newMyStructure();// create a test object
structure.x =777;
longsize = sizeOf(structure);
longoffheapPointer = getUnsafe().allocateMemory(size);
getUnsafe().copyMemory(
structure, // source object
0, // source offset is zero - copy an entire object
null, // destination is specified by absolute address, so destination object is null
offheapPointer,// destination address
size
);// test object was copied to off-heap
Pointer p =newPointer();// Pointer is just a handler that stores address of some object
longpointerOffset = getUnsafe().objectFieldOffset(Pointer.class.getDeclaredField("pointer"));
getUnsafe().putLong(p, pointerOffset, offheapPointer);// set pointer to off-heap copy of the test object
structure.x =222;// rewrite x value in the original object
System.out.println( ((MyStructure)p.pointer).x );// prints 777
....
classPointer {
Object pointer;
}
|
So, it is virtually possible to manually allocate and deallocate real objects, not only byte buffers. Of course, it’s a big question what may happen with GC after such cheats.
Inheritance from Final Class and void*
Imagine the situation when one has a method that takes a string as an argument, but it is necessary to pass some extra payload. There are at least two standard ways to do it in Java: put payload to thread local or use static field. With Unsafe another two possibilities appears: pass payload address as a string and inherit payload class from String class. The first approach is pretty close to what we see in the previous section – one just need obtain payload address using Pointer and create a new Pointer to payload inside the called method. In other words, any argument that can carrier an address can be used as analog of void* in C. In order to explore the second approach we start with the following code which is compilable, but obviously produces ClassCastException in run time:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
Carrier carrier =newCarrier();
carrier.secret =777;
String message = (String)(Object)carrier;// ClassCastException
handler( message );
...
voidhandler(String message) {
System.out.println( ((Carrier)(Object)message).secret );
}
...
classCarrier {
intsecret;
}
|
To make it work, one need to modify Carrier class to simulate inheritance from String. A list of superclasses is stored in Carrier class structure starting from position 28, as it shown in the figure. Pointer to object goes first and pointer to Carrier itself goes after it (at position 32) since Carrier is inherited from Object directly. In principle, it is enough to add the following code before the line that casts Carrier to String:
|
1
2
3
|
longcarrierClassAddress = normalize( unsafe.getInt(carrier, 4L) );
longstringClassAddress = normalize( unsafe.getInt("", 4L) );
unsafe.putAddress(carrierClassAddress +32, stringClassAddress);// insert pointer to String class to the list of Carrier's superclasses
|
Now cast works fine. Nevertheless, this transformation is not correct and violates VM contracts. More careful approach should include more steps:
- Position 32 in Carrier class actually contains a pointer to Carrier class itself, so this pointer should be shifted to position 36, not simply overwritten by the pointer to the String class.
- Since Carrier is now inherited from String, final markers in String class should be removed.
Conclusion
sun.misc.Unsafe provides almost unlimited capabilities for exploring and modification of VM’s runtime data structures. Despite the fact that these capabilities are almost inapplicable in Java development itself, Unsafe is a great tool for anyone who want to study HotSpot VM without C++ code debugging or need to create ad hoc profiling instruments.
3102
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
