Re: Instrumenting Java Library

[Manoj Plakal <plakal@cs.wisc.edu>]

Ondrej Lhotak wrote (Mon, Feb 02, 2004 at 09:36:45PM -0500) :
> On Sat, Jan 31, 2004 at 06:32:54PM -0500, KENNETH LELAND wrote:
> > I am having trouble instrumenting the java io and net libraries.  When i
> > instrument the library i get various problems ie: deadlocking,
> > exceptions, etc. when i run the instrumented code.  I am only adding a
> > call to a function that just returns. if anyone can post a smallest
> > example that works for instrumenting java libraries i would be
> > grateful.( the examples in the soot tutorials dont seem to work for the
> > libraries)
> 
> In my experience, instrumenting the standard libraries by modifying the
> bytecode is very messy. The two main problems I've encountered are:
> 
> 1) The VM makes assumptions about the libraries which are no longer true
> when you modify them. For example, adding a field to java.lang.Object
> causes several VMs to seg fault.
> 
> 2) It's often difficult to write the instrumentation code without using
> the part of the library that you are instrumenting.
> 

   In my work with Soot, I've applied generic instrumenters
   to bytecode of entire applications from the Olden suite, including 
   the standard libraries of JDK1.1.8. Instrumented applications
   seemed to run fine for me, at least for simple instrumenters
   such as method/basic-block/field-access profilers.

   Few caveats I discovered:
     - do not instrument java.lang.Object. VMs assume too
       much about layout of this class.

     - instrumentation code should not have side-effects
       that can affect the main program, or call methods
       that can have side-effects. Otherwise, you can
       mess up if the code you're instrumenting as well
       as the instrumentation (for example) acquire the
       same lock in some library routine.

     - instrumentation code should not call library methods
       when instrumenting the same library method, otherwise
       we have infinite loops (e.g., inserting a debugging println
       in the println method itself).

   Your safest bet for instrumenters is to have the instrumentation
   accumulate state in separate in-memory buffers, and then have
   epilogue code (instrument the return in main() and all calls
   to System.exit()) post-process the in-memory state (e.g., dump
   out the profile). A clean separation between application
   and instrumentation code and data will ensure safe runs.

   If at all your instrumentation needs to do real-time munging
   of data, then use your own uninstrumented code libraries
   (you write it or maybe a renamed copy of standard libraries).

  Manoj