Re: Runtime.traceMethodCalls()
> Brandon Anderson writes: Brandon> I've been trying to get the Runtime.traceMethodCalls() Brandon> and the Runtime.traceInstructions working in Java under Brandon> linux for quiet some time, and can't seem to figure out Brandon> what I'm doing wrong. Brandon> I'm starting to wonder if they are implemented at all in Brandon> the Linux version, or if I have to do some special Brandon> compile time switches... Brandon> I'm actually calling the functions doing a Brandon> Runtime.getRuntime().traceMethodCalls() and Brandon> Runtime.getRuntime().traceInstructions() but I've tried Brandon> with just straight Runtime.trace* and that doesn't seem Brandon> to work either. Brandon> Is it outputting it to a specific file somewhere that I'm Brandon> just not finding, or is this really not implemented on Brandon> the Linux version. The Java specs do say this is an Brandon> optional thing for the JVM to do, but it would be an Brandon> immensely useful debugging tool. Tracing only works with the debug version of java. Use 'java_g' instead of 'java'. Juergen -- Juergen Kreileder, Blackdown Java-Linux Porting Team http://www.blackdown.org/java-linux.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Benchmark results for Linux JVM's.
Raja Vallee-Rai <[EMAIL PROTECTED]> wrote: > We have formally evaluated the different virtual machines available for > Linux and thought it would be worthwhile to share the results with > the Linux community. Thanks. The results are so interesting. > ibmjit: speedup of the AlphaWorks IBM 1.1.8 JIT > (http://www.alphaworks.ibm.com) IBM JVM known as MMI (mixed mode interpreter) is different from Sun's one which is ported by Blackdown team. The difference should affect benchmark results. It's interesting to compare IBM's JVM and Sun's classic VM. And HotSpot VM and ExactVM if they can run on Linux. > We also evaluated shujit and tyajit, but they were unable to run > most of the benchmarks correctly. Products of IBM, Blackdown and Inprise have been tested well with JCK (Java Compatibility Kit). But authors of those JITs cannot access the JCK. Sun offers it only to commercial or special licensee. We have to develop free test suite such as Mauve (http://sourceware.cygnus.com/mauve/) if we want JVMs and JITs which we can control freely. Test code in Mauve is insufficient still more. Kazuyuki SHUDO Happy Hacking! Muraoka Lab., School of Sci. & Eng., Waseda Univ. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Runtime.traceMethodCalls()
Thanx (to everyone), That's an easier solution than I was hoping for. On 16 Oct 1999, Juergen Kreileder wrote: > > Brandon Anderson writes: > > Brandon> I've been trying to get the Runtime.traceMethodCalls() > Brandon> and the Runtime.traceInstructions working in Java under > Brandon> linux for quiet some time, and can't seem to figure out > Brandon> what I'm doing wrong. > > Brandon> I'm starting to wonder if they are implemented at all in > Brandon> the Linux version, or if I have to do some special > Brandon> compile time switches... > > Brandon> I'm actually calling the functions doing a > Brandon> Runtime.getRuntime().traceMethodCalls() and > Brandon> Runtime.getRuntime().traceInstructions() but I've tried > Brandon> with just straight Runtime.trace* and that doesn't seem > Brandon> to work either. > > Brandon> Is it outputting it to a specific file somewhere that I'm > Brandon> just not finding, or is this really not implemented on > Brandon> the Linux version. The Java specs do say this is an > Brandon> optional thing for the JVM to do, but it would be an > Brandon> immensely useful debugging tool. > > Tracing only works with the debug version of java. Use 'java_g' > instead of 'java'. > > > Juergen > > > -- > Juergen Kreileder, Blackdown Java-Linux Porting Team > http://www.blackdown.org/java-linux.html > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
java_g
Well, I tried to run my project with java_g as suggested. Unfortunately now I get a horrible RMI related thread dump. I was just wondering what exactly is the debug version of the jdk. Is it a development version or should it actually run correctly? Thanx again (in advance). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java_g
On Sat, 16 Oct 1999 15:47:02 -0600 (MDT), Brandon Anderson wrote: >Well, I tried to run my project with java_g as suggested. Unfortunately now I >get a horrible RMI related thread dump. I was just wondering what exactly is >the debug version of the jdk. Is it a development version or should it >actually run correctly? The debug version of the JDK is specifically to help debug programs. This also means that you need to have any RMI code built for debugging. -- Michael Sinz Technology and Engineering Director/Consultant "Starting Startups" mailto:[EMAIL PROTECTED] My place on the web ---> http://www.users.fast.net/~michael_sinz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java_g
I did recompile everything using javac_g, but that is when I get the nasty RMI thread dump. I would assume that the other code connecting through RMI doesn't have to be recompiled using the java_g. But that is pretty much irrelevant since I can't even get this program get to the point where it would accept RMI connections. I'm running the rmiregistry_g and all the code that is currently being used has been compiled with javac_g, so I just don't get what's wrong. On Sat, 16 Oct 1999, Michael Sinz wrote: > On Sat, 16 Oct 1999 15:47:02 -0600 (MDT), Brandon Anderson wrote: > > >Well, I tried to run my project with java_g as suggested. Unfortunately now I > >get a horrible RMI related thread dump. I was just wondering what exactly is > >the debug version of the jdk. Is it a development version or should it > >actually run correctly? > > The debug version of the JDK is specifically to help debug programs. > This also means that you need to have any RMI code built for debugging. > > -- > Michael Sinz Technology and Engineering Director/Consultant > "Starting Startups" mailto:[EMAIL PROTECTED] > My place on the web ---> http://www.users.fast.net/~michael_sinz > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java_g
At 19:47 10/16/99 -0400, Michael Sinz wrote: >On Sat, 16 Oct 1999 15:47:02 -0600 (MDT), Brandon Anderson wrote: > >>Well, I tried to run my project with java_g as suggested. Unfortunately now I >>get a horrible RMI related thread dump. I was just wondering what exactly is >>the debug version of the jdk. Is it a development version or should it >>actually run correctly? think of it as a build with asserts on, full symbol tables, and no optimization. >The debug version of the JDK is specifically to help debug programs. >This also means that you need to have any RMI code built for debugging. umm... RMI is implemented in Java, not C/C++; thus there is no debug version. What exactly is the exception? cabbey at home dot net <*> http://members.home.net/cabbey I want a binary interface to the brain! Today's opto-mechanical digital interfaces are just too slow! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java_g
OK, so I found out that not all the code is compiled with javac_g. Is there any way to get around having to compile all the code with javac_g. I'm connecting to a database via some jdbc drivers and they are not compiled with javac_g and I don't/can't have the source to them. Any ideas? On Sat, 16 Oct 1999, Brandon Anderson wrote: > I did recompile everything using javac_g, but that is when I get the nasty RMI > thread dump. I would assume that the other code connecting through RMI doesn't > have to be recompiled using the java_g. But that is pretty much irrelevant > since I can't even get this program get to the point where it would accept RMI > connections. > > I'm running the rmiregistry_g and all the code that is currently being used has > been compiled with javac_g, so I just don't get what's wrong. > > On Sat, 16 Oct 1999, Michael Sinz wrote: > > > On Sat, 16 Oct 1999 15:47:02 -0600 (MDT), Brandon Anderson wrote: > > > > >Well, I tried to run my project with java_g as suggested. Unfortunately now I > > >get a horrible RMI related thread dump. I was just wondering what exactly is > > >the debug version of the jdk. Is it a development version or should it > > >actually run correctly? > > > > The debug version of the JDK is specifically to help debug programs. > > This also means that you need to have any RMI code built for debugging. > > > > -- > > Michael Sinz Technology and Engineering Director/Consultant > > "Starting Startups" mailto:[EMAIL PROTECTED] > > My place on the web ---> http://www.users.fast.net/~michael_sinz > > > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java_g
Overkill my friend... overkill. the _g versions don't change how they interact with the outside world, only how they work internally. Class files generated from javac and javac_g are the same. Unless you're debugging a failure of rmiregistry there is no need for rmiregistry_g. Please send the stack. The only thing you have to do special for working with _g is compile debuggable versions of *your* *native* *libs*. usually a quick `ln -s libmine.so libmine_g.so` is all it takes. -=Chris cabbey at home dot net <*> http://members.home.net/cabbey I want a binary interface to the brain! Today's opto-mechanical digital interfaces are just too slow! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java_g
If that's the case than why does my program run correctly when I compile it and run it with javac/java but not when I compile it with javac_g/java_g? And how do I get Runtime.trace*() to work. I just simply want to know if those function work under the Linux JVM. They are not required to be implemented according to the Java 1.2 API. I don't want to debug the program, but I do want to add the feature of being able to dynamically turn on the output of debugging information in such a way that it doesn't hurt performance. (i.e. Send an RMI message to the program and it automatigically starts to output what functions its executes). On Sat, 16 Oct 1999, Weiqi Gao wrote: > Brandon Anderson wrote: > > > > OK, so I found out that not all the code is compiled with javac_g. Is > > there any way to get around having to compile all the code with javac_g. > > I'm connecting to a database via some jdbc drivers and they are not > > compiled with javac_g and I don't/can't have the source to them. > > On a logical level, javac_g is the debug version of javac. As a > consequence, javac_g works exactly the same as javac. Doing a "javac > Foo.java" and a "javac_g Foo.java" will produce exactly the same > output. Thus javac_g is useful to debug "javac the program" itself, > which application developers don't usually do. > > To compile your Java source into a debuggable version of class files, > use the -g switch, i.e., "java -g Foo.java". The resulting Foo.class > file can then be debugged with jdb. You can either run "java -debug > Foo" and then debug it over the network, or you can run "jdb Foo" to > debug it locally. > > Contrary to the situation with C programs, line numbers of source code > are always compiled into the class files, whether you use the -g switch > or not. It's the other stuff (local variable names, etc.) that's added > when you compile with the -g switch. > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java_g
OK, here is the thread dump, but like I already wrote in the previous
post I only get this while running java_g so I don't know if its really
relevant.
*** panic: "../../../../src/share/javavm/runtime/classresolver.c", line
1285: assertion failure
SIGABRT 6* abort (generated by abort(3) routine)
stackpointer=0xbfffe370
Full thread dump Classic VM (Linux_JDK_1.2_pre-release-v2, green threads):
"RMI ConnectionExpiration-[server.name.com:1099]" (TID:0x407d2548,
sys_thread_t:0x82a4398, state:CW) prio=5
at java.lang.Thread.sleep(Native Method)
at
sun.rmi.transport.tcp.TCPChannel$Reaper.run(TCPChannel.java:525)
at java.lang.Thread.run(Thread.java:479)
"RMI LeaseChecker" (TID:0x407d2460, sys_thread_t:0x82a0680, state:CW)
prio=5
at java.lang.Thread.sleep(Native Method)
at sun.rmi.transport.DGCImpl$LeaseChecker.run(DGCImpl.java:303)
at java.lang.Thread.run(Thread.java:479)
"RMI TCP Connection(2)-server.name.com/192.168.1.111"
(TID:0x407d0d18, sys_thread_t:0x828a780, state:CW) prio=5
at java.net.SocketInputStream.socketRead(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:90)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:190)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:229)
at java.io.BufferedInputStream.read(BufferedInputStream.java:285)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:190)
at java.io.BufferedInputStream.read(BufferedInputStream.java:208)
at java.io.DataInputStream.readByte(DataInputStream.java:224)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:428)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:607)
at java.lang.Thread.run(Thread.java:479)
"GC Daemon" (TID:0x407cd9e8, sys_thread_t:0x8243638, state:CW) prio=2
at java.lang.Object.wait(Native Method)
at sun.misc.GC$Daemon.run(GC.java:107)
"RMI Reaper" (TID:0x407cd818, sys_thread_t:0x8234fb0, state:CW) prio=5
at java.lang.Object.wait(Native Method)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:112)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:288)
at java.lang.Thread.run(Thread.java:479)
This continues for quite a while - atleast 2-3 pages worth of garbage. It
happens as soon as I try to connect to the database. This is the code
that it executes immediately before.
Class.forName("com.sybase.jdbc.SybDriver").newInstance();
String cInfo = "jdbc:sybase:Tds:server.name.com:20001";
Connection dbConn = DriverManager.getConnection( cInfo, _props );
But again, this may all be unnecessary since the only thing I want to do
is have a working version of Runtime.trace*() functions. They don't seem
to do anything normally, or I just don't know how to use them properly?
On Sat, 16 Oct 1999, Chris Abbey wrote:
> Overkill my friend... overkill. the _g versions don't change how they interact
> with the outside world, only how they work internally. Class files generated
> from javac and javac_g are the same. Unless you're debugging a failure of
> rmiregistry there is no need for rmiregistry_g. Please send the stack. The
> only thing you have to do special for working with _g is compile debuggable
> versions of *your* *native* *libs*. usually a quick `ln -s libmine.so
> libmine_g.so` is all it takes. -=Chris
>
>
> cabbey at home dot net <*> http://members.home.net/cabbey
>I want a binary interface to the brain!
> Today's opto-mechanical digital interfaces are just too slow!
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java_g
At 22:57 10/16/99 -0600, Brandon Anderson wrote: >If that's the case than why does my program run correctly when I compile >it and run it with javac/java but not when I compile it with untill you send us a stack trace and some actual concrete info about what you're doing and running, no one can answer that 'cept you. >javac_g/java_g? And how do I get Runtime.trace*() to work. I just simply use java_g >want to know if those function work under the Linux JVM. They are not they work in 117v1a on RH5.2, and 117v3 on RH6.0 >required to be implemented according to the Java 1.2 API. the 1.1 api said the same thing. >I don't want to debug the program, but I do want to add the feature of >being able to dynamically turn on the output of debugging information in >such a way that it doesn't hurt performance. then this isn't the solution you're going to want as it requires you to be running in java_g which doesn't perform well - by design. >(i.e. Send an RMI message to the program and it automatigically starts >to output what functions its executes). take a look at the JVMPI spec, or maybe write your own tracepoints in that check for a static flag. cabbey at home dot net <*> http://members.home.net/cabbey I want a binary interface to the brain! Today's opto-mechanical digital interfaces are just too slow! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java_g
At 23:21 10/16/99 -0600, Brandon Anderson wrote:
>
>OK, here is the thread dump, but like I already wrote in the previous
>post I only get this while running java_g so I don't know if its really
>relevant.
>
>*** panic: "../../../../src/share/javavm/runtime/classresolver.c", line
>1285: assertion failure
>
>SIGABRT 6* abort (generated by abort(3) routine)
>stackpointer=0xbfffe370
>
ahh... now I understand better based on your previous statement:
"I get the nasty RMI thread dump." I was assuming that you took an
RMI related exception. (RMI is one of my fields, I was hoping it was
something I could help with.)
>
>This continues for quite a while - atleast 2-3 pages worth of garbage. It
>happens as soon as I try to connect to the database. This is the code
>that it executes immediately before.
>
>
> Class.forName("com.sybase.jdbc.SybDriver").newInstance();
> String cInfo = "jdbc:sybase:Tds:server.name.com:20001";
>
> Connection dbConn = DriverManager.getConnection( cInfo, _props );
one of those threads in that stack should be the one going through this
code (I don't see it in the part you provided). See if you can find it and
see what it's doing. I suspect it is on the Class.forName() call which is
causing the class loader to blow up because sybase doesn't include
debuggable drivers (or so I'm told . . . anyone from Sybase listening?)
We have a similar problem at work with Oracle only providing dlls for Sun's
VM and not IBM's. Another possibility would be that the Sybase classes load
a native so and call a method in their static initializer that causes an
abort signal... but I don't think this is how the classloader would respond
to that case.
>But again, this may all be unnecessary since the only thing I want to do
>is have a working version of Runtime.trace*() functions. They don't seem
>to do anything normally, or I just don't know how to use them properly?
I suspect you do. Try this trivial test class out... if it works then you'll
prove to your self you've got your environment setup and that you know what
you're doing.
public class test {
public static void main(String[] args) {
System.out.println("running");
Runtime.getRuntime().traceMethodCalls(true);
System.out.println("trace
this call");
Runtime.getRuntime().traceMethodCalls(false);
System.out.println("done");
}
}
or try using the -tm command line arg with your favorite hello world.
cabbey at home dot net <*> http://members.home.net/cabbey
I want a binary interface to the brain!
Today's opto-mechanical digital interfaces are just too slow!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
