[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Instrumenting Java Library
[Resending, apologies if you receive duplicates]
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