The pit of script in the javaagent parameter of Btrace

In short, this article is just a note to commemorate my youth struggling with btrace parameters... (well..., I don't seem to be young anymore)

Write the conclusion first: in the windows environment, the javaagent method of the instrument does not support the full path method of win, here refers to the script parameter, because it will be separated by :, and there will be problems with the drive letter. You can use scriptdir instead, it will scan all classes files in this folder, thinking it is your btrace script

==== Dividing line, if you want to see the process and some other instructions, you can continue to read below =========

In btrace scenarios, in most cases, it may be a runtime attach, which is generally ok, but there are also very few scenarios that need to be instrumented when starting (I don't know how to translate this word...).

What kind of scene? For example: the project has introduced a large number of jar packages, a thread pool is started in a jar but not closed..., it is still an unnamed thread pool, there are so many people, where can I find...

Generally, a feasible solution is to scan all the classes that can be loaded in your own project, and scan the loaded classes (such as bytecode) to see if there are thread pool classes used. bingo, came out, but the problem is..., he may be referenced by dozens or dozens of classes. Then turn the code one by one, I am afraid that the efficiency is extremely low. Even if you exclude some, there are about ten left. The problem is that these classes are not referenced by yourself, which means that they may be indirect references, so..., it is another time-consuming and laborious drudgery.

Here, I have thought of several solutions. I won't mention them one by one here. Generally speaking, you can replace the thread pool class of jdk, use your own, play jstack, or weave into the thread pool class, etc...

Here, the method I actually use is btrace, because btrace's non-intrusive debug code ability is very strong, and in addition to the runtime phase instrument, it provides the javaagent method instrument. (javaagent will not be expanded)

So, I try to add javaagent when the code starts, probably like this:

-javaagent:D:/Dev/btrace-bin-1.3.9/build/btrace-agent.jar=noServer=true,debug=true,stdout=true,script=d:/script/Pool.class

As a result, brache happily tells you that d is not a precompiled class, and reports xxx/Pool.class file not found.

The initial suspicion is that the btrace code is separated. In order to support multiple scripts, I check the btrace source code. Sure enough, he did this, the source code is as follows:

        if (script != null) {
            StringTokenizer tokenizer = new StringTokenizer(script, ":");
            if (isDebug()) {
                debugPrint(((tokenizer.countTokens() == 1) ? "initial script is " : "initial scripts are ") + script);
            }
            while (tokenizer.hasMoreTokens()) {
                loadBTraceScript(tokenizer.nextToken(), traceToStdOut);
            }
        }

So..., incomprehensible...

So, seeing that there is another parameter scriptdir, then specify this folder, put the classes file below and it will be solved

Of course, when this parameter is used, he will scan all the files below and consider them to be btrace scripts. If it does not conform to the specification (such as no @Btrace annotation), an error will be reported, OVER!

Another: to add, in fact, btrach directly new File (scriptFilePath) by default, if it can't find it, it will try META-INF/btrace/scriptFilePath to find it once, and it will FileNotFound if it doesn't work.

The pit of script in the javaagent parameter of Btrace

Guess you like