[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Instrumenting Java Library



On February 2, 2004 09:36 pm, Ondrej Lhotak wrote:
> 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.
>
> If you can be more specific about where exactly you are inserting the
> instrumentation and the kinds of exceptions you get and their stack
> traces, I might be able to make some guesses about what is going wrong.
>
> In general, if I need to instrument the libraries, I much prefer to do
> it without modifying bytecode. I am aware of two ways to do this:
>
> 1) Use JVMPI or the debugger interface. Bruno Dufour has a very nice
> tool for capturing and processing the information provided through
> JVMPI. It used to be called AdaptJ, but I think now he calls it StarJ.
> This is typically the easiest method, but only works if JVMPI provides
> the information that you need.

I am currently finishing the last pieces of *J, which I will release in a few 
days. Let me know if you are interested in using the tool. It's rather 
straightforward to use, but I would be glad provide assistance to anyone 
using it.

>
> 2) Instrument a VM. I've done this in the past with Kaffe and found it
> to be reasonably easy. The downside to Kaffe is that it doesn't run all
> benchmarks. SableVM would be another possibility. There's also JikesRVM,
> but it's more complicated, and it's difficult to separate the VM itself
> (which is written in Java and runs itself) from the code it's running on
> behalf of your benchmark. If you're planning to instrument a VM, you
> should still have a look at Bruno's tool. Last time I talked to him
> about it, he had plans to make it interface to a VM directly, so it
> could save you a lot of work.

This is unfortunately still part of my future work. Since JVMPI only offers a 
limited amount of information, I'd like to collect data by modifying SableVM 
in the future. *J itself is independent of the source of the data, so 
instrumenting any of the VMs Ondrej mentionned would be fine.

Regards,

	Bruno

>
> I hope this is helpful.
>
> Ondrej
>
> >  ken