Category: OpenJDK

Simple Patching Tool has been updated with a couple of minor enhancements:

• jtreg (Java Regression Test Harness) is now supported
  • You can patch any class in the context of a jtreg test
• Bug fix to use Object data types in Hooker class methods
  • Any object can be sent by parameter to a Hooker class method. From the ASM side, you push the object to the stack. From the Hooker side, you receive an Object (java.lang.Object class) to be cast to the expected class.

Download here.

Quarkslab folks proposed a challenge:  modify any compiler to generate code with some obfuscation but valid semantics. In other words, add some noise but keep the program logic valid.

Time to have some fun with C1: OpenJDK’s 1st tier JIT compiler.

Obfuscation “noise” can be added at different stages of the compilation process. Adding it early may be useful to target multiple architectures but it’s necessary to check if following optimization passes revert the effect.

Continue reading “Some noise to C1 JIT compiler for x86_64 (OpenJDK JVM – Hotspot)”

When writing OpenJDK tests in Java, I sometimes need to mock methods or set specific values on static fields in order to execute the paths of my interest. Even though using internal APIs is not ideal from a dependencies point of view, there is sometimes no choice. In example, a test that only uses public APIs may not be reliable enough to trigger a race condition bug; or may not return a constant value which can be compared against an expected one.

A few weeks ago I had to modify java.net.DatagramSocket default constructor to use a fixed port number, instead of getting a random one from the OS. Instrumenting Java bytecode with ASM was a good option back then. However, some modifications require more logic and implementing it with ASM can be harsh.

Continue reading “Simple Patching Tool v1.0 (OpenJDK)”

In the previous article we explored a couple of strategies to debug the OpenJDK JVM bytecodes interpreter. I will now present a procedure to debug JIT compiled code.

There are some JVM arguments useful to get information about JIT compiled methods:

Note: +PrintAssembly argument can be used to disassemble compiled code but requires a plugin library called hsdis in some JDK releases such as 8. In hotspot/src/share/tools/hsdis directory you will find the plugin code. To build it, open a command line and run:

Once built, copy build/linux-amd64/hsdis-amd64.so library to jre/lib/amd64 and jre/lib/amd64/server directories.

Continue reading “How to debug JIT compiled methods in OpenJDK JVM?”

Debugging the CPython VM interpreter is not different than any C application: you attach or launch with a debugger, set a breakpoint in the opcodes interpreter main loop and that’s all. Doing the same in the OpenJDK JVM is not as straight forward: the x86_64 interpreter is a collection of assembly chunks generated in run time.

Simplifying the process, a set of C++ functions -whose names look like pseudo-assembly- is used to generate a stream of architecture instructions. These instructions, allocated in executable memory, are the bytecodes interpreter. There are entry points from the interpreter to C++ functions, intended for more complex and slow-path operations.

Continue reading “Debugging the OpenJDK JVM interpreter in Linux x86_64”