Hi Jim, hi Benoit, --- Jim Pick <[EMAIL PROTECTED]> 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 debugging. 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. http://mailplus.yahoo.com _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe