metracer — New Release 1.2.0

New version of metracer 1.2.0 was just released. Main changes are:

# Change Description
1 Use of ASM for instrumentation  A move was made towards ASM instrumentation framework instead of Javassist. This allowed to:

  • increase performance
  • lower memory footprint
  • get rid of creation of proxy methods – now a tiny pieces of code are injected directly into target methods
2 Reporting of return values Now there is information of return values of instrumented methods, e.g.:metracer_return_value_
3 Extended reporting of exceptions Now the string representation of exception is printed for instrumented methods, e.g.:metracer_exceptions

With these changes metracer became more efficient, lightweight. Changes provide an opportunity for “hot” code instrumentation (without program restart).


metracer – Java Code Instrumentation and Stack Map Frames

Stack Map Frames in Java is a contradictory addition to the language: they speed up class loading but the same time make big troubles for a code instrumentation tools. During adoption of an ASM framework to a metracer I have stumbled with following main two issues:

  1. necessity to resolve a “common super class” during instrumentation which causes many ClassNotFoundException
  2. VerifyError exceptions with message like ‘Stack map does not match the one at exception handler’


metracer – Logging via org.slf4j.Logger

New version 1.1.0 of metracer was released: were many experiments, redesigns and code rewrites. Main changes are around tracing output – now it’s done via org.slf4j.Logger. (issue #8)


metracer – No Runtime Dependencies + Nice Indentation

Based on my experiments with adoption of metracer to JavaEE (link) a new version of metracer 1.0.5 was released. Source code of new 1.0.5 version: svn co


metracer – Adoption to Java EE

Main target audience of a metracer are meant to be enterprise Java applications – metracer must enhance logging of such applications. As such I’ve tried to adopt metracer to a production level Java EE application which runs under WildFly AS. Speaking in terms of RPG games – tons of experience was earned :-). Results of my experiments are below.


metracer — Support of Unannotated Code

An attempt to use metracer within an existing long-living project revealed major problem: code is not annotated with a @Traced. Adjusting all the code is tedious and hardly ever will pass a code review with team mates. One of the feasible options is to perform an automatic tracing of methods based on regex passed somehow from the outerworld. Use of regex is motivated because it allows to support complex rules (e.g. conditional includes / excludes) without the need to invent a complicated DSL. Details on this new feature are below.


metracer — Arguments Printing

Introduced metracer library is able to print entry / exit tags as well as call depth counter and exceptions. An expected improvement is to have arguments of methods to be printed. This would additionally ease postmortem analysis. Let’s see how it’s done.


metracer — Call Depth and Exceptions

Two of the most wanted features to metracer are a call depth tracking and reporting if method exited normally or by exception. Together they provide precious information for a postmortem analysis. Let’s see how this is implemented in a next version of a metracer library.


metracer — Methods Tracer in Java

Tracing of methods in logs shows when methods start and end theirs execution. Tracing allows to reconstruct program execution path and eases troubleshooting in production. In C++ it’s common to achive methods tracing via various RAII technichues but Java lacks pure RAII semantics. Under the cut is one of the approaches of how to get methods tracing in Java programs using a Metracer library.