Version 10

    Profiler Documentation - Technical Summary


    This will be a technical description of JBoss Profiler. This document is a work in progress.


    What is a profiler?

    Some people might think of a profiler as a measuring tool which discovers how much memory and CPU a application is using. This is true, but it can do more than just show you some numbers.


    • By a profiler you have how the application behaves internally.

    • How the methods are related each other.

    • How the methods are related to the memory consumption

    • What are the memory leaks


    Main differences of JBossProfiler


    The main difference is to use binary log files captured from Interceptors, and process those files after a test-case, a scenario, or a user-problem has finished without consuming any resources from the application.


    In another words you can:


    • Analyze all events at the same time (Memory, CPU, Time, Graphs and Memory Leaks)


    Nice features like:


    • The profiler can stay in sleep mode without consuming any resources from the application until you really need it.

    • You can setup triggers for starting event capturing. For example, you can establish a trigger to start capturing data only after your Servlet.doRequest is being called.

    • Regular exclusion filters as well

    • Find which objects still are alive


    JBossProfiler has is based in OLAP Systems, where you capture events from a business and process them in structures you can analyze with filters and have information in a fancy time.


    This profiler it's exactly the same thing.


    We didn't use any complex data-structure for that besides an object model and an aggregation program that captures data from the interceptors.

    Using the object-model prepared by the processor class (org.jboss.profiler.engine.LogFileEngine) it's possible to create different front-ends. (for example: a WebApplication, a JBossIde Plugin, Ant Integration, etc...)




    JBossProfiler is a 100% Java application that analyzes data in a proprietary binary log format. From this format we can extract events for:

    • method entry/exit (CPU and Time)

    • object allocation

    • thread start/end

    • class loading

    • object release


    Those binary files are generated by interceptors that can be written in C/C++ capturing events from the JVM, or by instrumentating code and capturing events as well.




    We have now 2 versions of Interceptors.


    • JVMPI (which is being converted to JVMTI)

    • AOP


    We decided to have both versions because it's not possible to capture all the events just by using a 100% Java application (even by using AOP).


    There is some information we can only have by intercepting C++ calling from the JVM and that can be done by a relatively simple C++ program.


    The AOP version is good to have as well as in some sittuation you don't need to have all the JVM generated information. (at a production site for example)


    JVMPI - Java Virtual Machine Profiler Interface

    An experimental C++ interface to capture events directly from the JVM.

    Sun claims that JVMPI it an experimental interface, but it is being widely used by profiler implementors.

    A simple implementation should be very fast as the JVMPI method is called directly from the JVM class.


    Our current implementation of the native library it's based on JVMPI.


    JVMTI - Java Virtual Machine Tool Interface

    It's a new C++ interface which has support for profilers/debuggers.

    It has nice methods, and you have the possibility of easily instrumenting code with JVMTI.

    It's much easier to work with than JVMPI.


    We are working on converting to it.




    The good thing about using AOP is we can focus excatly on what we need and instrument only the classes we want to analyze.

    The bad thing is there are some classes you can't pointcut by definition and there are some events you can't work on.


    We already have an experimental working version of an AOP interceptor which needs to be improved. Probably we can extract more events after some improvement but a native API would always get more events from it.


    Getting Data into Production Environments


    It's possible to capture events from production evironments as the profiler can stay in sleep mode, or we can select events for a finite number of methods.



    Currently we have a web-based interface, and we are developing an ant integration which will generate reports that will extend functionality on JUnit.


    Data Model



    Web Application



    Ant Integration