Byteman 3.0.5 released, Java bytecode injection tool

Byteman 3.0.5 is released, Java bytecode injection tool https://m.oschina.net/blog/375413
Scenario description A bug has occurred on the

productionbug, what is your general practice?

Use the println method to print (or log) to record the details?
Use remote debug?
Use the bytecode manipulation tool btrace?
Many times when there is a problem with the online application, we need to know more details of the running of the program, but it is impossible to print all the running details of the program to the log during development. Usually, what we can do at this time is Modify the code, redeploy, and then observe, but this method is not very good for online applications. On the other hand, if you encounter code that is not easy to change, such as other external packages that are referenced, it will be very troublesome. . Using remote debugging will cause the thread to hang, which is not acceptable for an online environment. Although the use of btrace bytecode tools can avoid the shortcomings of the above two methods, but btrace has too many restrictions, such as

cannot
cannot throw or catch exceptions,
cannot
, can
notCall the instance or static method of the target program
.
script cannot include outer, inner, and nested Class
. There can be no loops in the script, and no class, any interface, and assert statement can be inherited.
I've been using btrace for a while, but I haven't found a way to get local variables (if any netizen knows, you can teach me), which is the most unacceptable thing to me, because this scenario is widely used. If you also have this need and trouble, then byteman is your ideal choice.

Introduction

to Byteman Byteman is a project under jboss. It is a very convenient java analysis tool that can intercept bytecode execution, execute code and modify variables. It is a tool for diagnosing problems . It is very convenient to use under linux, without any modification to the target application, you can dynamically open the listening port of the target application, of course, it is limited to openjdk, hotspot and jrockit, ibm jdk does not support.
For details, see the original text




Using Byteman to locate the running system http://wangzaixiang.blogspot.com/2014/05/byteman.html
If there is a problem with a Java application in a production environment, what tools can we use to assist us What about positioning?
jstack can help us understand the thread status of this process, and some problems such as deadlock can get feedback by viewing the thread status. jmap can help us with positioning. (A very easy situation is the deadlock caused by the static initialization of the class. I have encountered a very strange case here. Normally, no deadlock occurs, but after Emma processing, it occurs. The phenomenon of deadlock, if there is a plan in the future, you can reproduce this phenomenon and make an in-depth analysis)
jmap/mat can help us grab the memory and perform a replay, which is a useful tool for locating memory leaks. Very effective tool. It should be noted that MAT will consume a lot of memory. Therefore, it is necessary to configure the heap settings of the jvm reasonably and prepare the server environment for running MAT: 64-bit is a must, and enough memory is also required.
jcmd can help us understand the startup flags, system properties and many other information of the Java process.
However, if you need to do some code-level debugging of the process, the above tools are not enough. And open a remote debugging tool, connect to this process, unless the relevant options are set at startup, otherwise, there is nothing you can do. Linux's strace can perform System Call tracing operations on a running process (this is also a sharp edge in system-level positioning), and Java can choose btrace to complete similar work. However, here, I would recommend a more powerful tool: Byteman (http://byteman.jboss.org/).

I personally don't have much practical experience with btrace, and I always feel that there are some inconveniences in using it. However, after coming into contact with byteman, I have a sense of intimacy. Of course, this may be related to my familiarity with Java bytecode, so Byteman The various entry points for me are a relatively natural technique. ByteMan has its own rule language for describing code entry (similar to drools, the earliest drools did not have its own grammar, and it was complicated to use), therefore, after a certain study, ByteMan's rule description will be simpler, readable.

ByteMan's code insertion capability is stronger than btrace, it seems that you can insert our trace code anywhere in the code (of course, you may need a certain understanding of Java code generation and bytecode), and The ability to access variables in the current method (including method parameters, local variables, and even the parameter values, return values, etc. of calling other functions), and btrace's ability in this regard is much weaker. If you are familiar with Java's bytecode knowledge, it is relatively simple to understand Byteman's set of entry points, even simpler and more direct than btrace.

However, it is recommended that if we want ByteMan to help us with our production fault location capabilities, we need to be as familiar as possible with Byteman in advance, and it is necessary to read its documentation. We should also do more testing in the development environment to establish Nice proficiency. If you wait until the real production problem needs to be located, and then learn and use it, it is probably too late. (Byteman's own expertise, and the urgency of the production environment, will keep you busy).

I composed some knowledge of ByteMan that I have learned and organized into a simple CheetSheet, which can be used as a refinement of personal learning, and can also be used as a quick reference for the follow-up.
RULE <rule-name>
CLASS <class-name> | INTERFACE <class-name-pattern>
METHOD <method-name>
HELPER <qualified-class-name>
<localtions>
BIND <bindings>
IF <condition>
DO <actions>
ENDRULE

<class-name-pattern>: HelloWorld | com.foo.HelloWorld | ^java.lang.Object
<locations>
AT ENTRY
AT EXIT
AT LINE number
AT READ [ type .
AT READ $var-or-idx [count | ALL ]
AFTER READ [ type .] field [count | ALL ]
AFTER READ $ var-or-idx [count | ALL ]
AT WRITE [ type .] field [count | ALL ]
AT WRITE $ var-or-idx [count | ALL ]
AFTER WRITE [ type .] field [count | ALL ]
AFTER WRITE $ var-or-idx [count | ALL ]
AT INVOKE [ type .] method [ ( argtypes ) ] [count | ALL ]
AFTER INVOKE [ type .] method [ ( argtypes ) ][count | ALL ]
AT SYNCHRONIZE [count | ALL ]
AFTER SYNCHRONIZE [count | ALL ]
AT THROW [count | ALL ]

BIND engine:CoordinatorEngine = $0;
     recovered:boolean = engine.isRecovered();
     identifier:String = engine.getId()

BIND Expression: $! (return value), $^(exception), $#(argc), $*(args for this method), $@(args for AT INVOKE), $CLASS(class name) and $METHOD(method signature)