Hi John,

How can we use bmcheck.sh to check rules in loaded web application in web server.

Err, like this maybe ...

$ bash ${BYTEMAN_HOME}/bin/bmcheck.sh

:-)

Alternatively, if you want to be able to run ti directly and without having to specify a path

$ chmod u+x ${BYTEMAN_HOME}/bin/bmcheck.sh
$ export PATH=$PATH:${BYTEMAN_HOME}/bin
$ bmcheck.sh

Of course, in order for this to work you need to have installed the Byteman agent into your web server with the agent listener enabled (you can only talk to the Byteman agent if it is installed and  listening for requests on a socket). If you install the agent using bminstall.sh then the listener will have been enabled automatically. If you  are using -javaagent on the command line you need to add listener:true to the options list following the = sign e.g. add something which looks like the following option to the command line

java -javaagent:${BYTEMAN_HOME}/lib/byteman=script:/path/to/myscript.btm,listener:true ...

Hi John,

As this is open source project can I get design document and flow diagram of project so i can understand very well.

Hmm, as this is an open source project I am afraid not . . . :-)

There are no separate design documents or flow diagrams for this project. Pretty much all the existing documentation is provided  in the Byteman code as javadoc comments and other code comments. I implemented most of the code (including all the really tricky bits) on my own between 2009 and 2011. So, there has not been any significant discussion of design discussions on the design forum. Some details of how Byteman works are provided in the paper I presented at the AOSD 2011. You can obtain a copy from the ACM's digitial library.

The same applies for the packages it relies on (Java SE JVMTI Java agent libraries, ASM 3.3 bytecode manipulation libraries and JavaCUP/JFlex parser generator libaries).

If you want to ask specific questions about how the code is designed please do so by posting them to the design forum. I am very happy to explain what the code is doing to anyone who is at all interested. I would also welcome the opportunity that will provide to write down some of the more important aspects of how Byteman has been built and how it operates.

As for what is already documented for you to read now:

All of the tricky algorithms implemented specifically for Byteman are described very carefully by comments in the code -- never mind anyone else, I cannot maintain it without a reminder of how it is works. That is true even though I invented some of the algorithms myself (n.b. I don't think any of them are truly original -- they are all based, to some degree, on known compiler design techniques). For the same reason, in most of the remaining non-obvious cases I have documented: what methods are supposed to do; what classes are used for; what specific field values represent; and so on. Common Java coding idioms and basic knowledge of how bytecode is organized plus how certain parser and compiler algorithms/data representations are defined is assumed in some parts of the code (see below for where to acquire that understanding).  Don't let that put you off. Most of the code is straightforward bread and butter programming -- I only spend time complicating code when there is a reason (like algorithmic complexity, provable correctness or performance).

The JVM API that Byteman relies on (JVMTI Java agent APIs) is described in the Java SE documentation for package java.lang.instrument which you can find on Oracle's site for JDK6 and upwards (the API has not changed since Java 6).

The ASM package used to manipulate bytecode is described in the ASM code. The code contains many example programs which show you how to use the package. Reading it is a good introduction to bytecode if you don't already know about how it works. If you want more details you need to study the Java VM specification.

The JavaCUP and JFLex libraries are Java equivalents to the C programs Bison and Flex and are used to implement an LALR shift-reduce  parser and regexp based tokeniser which are combined to implement a parser for the body of Byteman rules (everything from IF to ENDRULE). I used this in preference to the more common choice (in Java circles) of recursive descent parsers (usually  ANTLR) because my experience is that LALR grammars provide clearer operator handling, more readable grammars and better error handling than the grammars handled by shift-reduce parsers. If you want to understand how both types of grammar work and what the differences between them are consult the Dragon book -- Aho, Sethi and Ullman's Compilers: Principles, Techniques, and Tools, the standard book on compiler design -- or, better still, Aho and Ullman's 2 volumes entitled The Theory of Parsing, Translation and Compiling. The latter is one of the truly great pinnacles of 1960s computer science (indeed, of all time) and deserves to be much better known and read than it currently is.

regards,

Andrew Dinn