[kaffe] tracing method calls

Dalibor Topic robilad at yahoo.com
Wed Nov 27 04:31:19 PST 2002

Hi Jim, hi Benoit,

--- Jim Pick <jim at kaffe.org> wrote:
> On Wed, 2002-11-27 at 09:19, Benoit Hubert wrote:
> > Hello
> > 
> > I'm working on a modified version of Kaffe, which
> uses
> > our own thread and socket subsystems. I use a test
> program
> > which hangs at some point, but I can't determine
> precisely where.
> > I think that in this situation, it would be
> helpful if I could trace
> > each method call made by the program. Before that,
> I tried to use gdb,
> > but as I use an alternate threading system, when I
> interrupt the
> > program under gdb, the stack I can examine is that
> of the threads
> > scheduler.
> > 
> > Can anyone provide me with some hints, regarding
> how I could modify
> > the JVM in order to make it trace each method call
> ?
> > 
> > Thanks a lot
> > 
> > Benoit
> I think the PocketLinux version of kaffe had a
> working -verbosecall
> switch (it doesn't work in the kaffe.org version). 
> I'm not sure, but
> I think I was told that it worked by JIT'ing each
> method, and but not
> storing the result (so it ran very slowly).

I have to disagree. At the moment, -verbosecall works
for me on current CVS from kaffe.org on i386-linux
with jit3 engine, I use it quite a lot during

It usually generates a lot of output. But it doesn't
tell you about native mathods thought. In order to
catch invocation of native class library methods, you
need to --enable-debug when you ./configure kaffe.
Running kaffe with -vmdebug list will give you a list
of debug output options. Then, running kaffe with
-verbosecall -vmdebug comma-separated-list-of-options
will give you a lot of output to go through.

You may also want to check out the threading & locking
tracing options in -vmdebug. Or add similar tracing
code to your output.

If you can assume that your code is running in
circles, as you could see by a high CPU utilization,
you could also run it with profiling enabled in a
separate Thread that gets killed after a while. The
method with the highest amount of time spent in it
should be a good start for your search for the bug.
You may also want to check out xprofiling for
profiling the VM itself, in case you're running in
circles inside the VM.

If you need to get down to the bytecode level,
configure kaffe to run --with-engine=intrp , and use
the bytecode execution tracing options available
through -vmdebug.

You may also want to give the bdbj debugger for kaffe
a try. I'm not too sure it would be useful in your
case, though.

Of course, none of the methods above will improve the
performance of your application, i.e. they might take
quite a lot of time to generate their output.
Especially interpreter tracing.

best regards,

dalibor topic

Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

More information about the kaffe mailing list