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

Re: java policy for debian, shared libraries...



Ola Lundqvist wrote:

I currently develop jmp (http://www.khelekore.org/jmp/) a java profiler.
Java profilers are written in C/C++ and compiled to shared libraries, libjmp.so for jmp. Many profilers today have a java front end, jmp does not (it uses a gtk front end).
What exactly is a java profiler? A java debugging utility?
A java profiler is a library and/or program that show how much memory your java program allocates, where it allocates it. Whats java objects are currently on the heap. It also shows where your program spends time (how much time each method take). It is a sort of debugging utility, but not the normal one where you run your program to breakpoints...

Screenshots of jmp can be found at:
http://www.khelekore.org/jmp/screenshot.html

jmp is C code only.
jmp is compiled by gcc.
jmp has no binary (only libjmp.so is installed).
libjmp.so should probably go into /usr/lib/ or someplace like that.
According to this it has nothing to do with java.

Most other java profilers have a java front end, jmp does not. So some java debuggers and profilers will show up that in a way has nothing to do with java but are libraries that are run from inside the jvm.
They also require some java headers from the jvm to compile.

jmp needs a jvm to run (java -Xrunjmp my.fine.Program). The jvm loads the library with dlopen.
But this of course makes it java-related. Does it work with any jvm or
just some specific? Actually I do not think this has to be covered by the
java policy.

Jmp works well with the jvms from sun(1.3.x, 1.4.x), blackdown (1.3.x, most probably 1.4.x) and ibm (1.3.x). I havent tried any other jvm. Java profilers are coded according to the jvmpi specification.
http://java.sun.com/j2se/1.4.1/docs/guide/jvmpi/jvmpi.html

The java debugger also has a similar interface but I am not aware of any debugger that does not use any java classes. There probably exists more interfaces that use dynamic loading to do strange stuff with the jvm....

Where to this fit in?
In the normal debian policy. We just have to make sure that the
java-policy excludes this possibility. I just checked and I do
not think it does.

? should that not be: ... java-policy not excludes this....

Do you think something is needed in the policy?

Not sure, but I noted that there is no place for tools that extend the jvm with dynamic libraries...
What about external jits? (Just In time Compilers)? probably same thing....

/robo




Reply to: