Paolo Ciccone wrote:

> > Does the Inprise JDK have all parts of JPDA?
>
> I'm not an expert in JPDA but the Sun/Inprise JDK does have JPDA fully
> working.

I've confirmed Inprise JDK has dynamic libraries and a
JAR file which implement JPDA, libjdwp.so,
libdt_socket.so and jpda.jar.

A JDPA implementation 1.0 for Solaris
(jpda-solsparc.zip) also contains them.
It is available at http://java.sun.com/products/jpda/.

> That is a requirement for the JBuilder debugger,
> local and remote, to work.

I consent to you. Working JBuilder is an evidence of
JPDA implementation.

> > And I suppose only JDI requires an additional JAR file
> > named jpda.jar, which contains the following packages.
>
> Check.

I noticed jpda.jar which included in Inprise JDK is
different from it provided by Sun such as JPDA 1.0. The
Inprise's jpda.jar contains more classes than Sun's.

Will the difference be contributed to developers other
than Inprise?


And I have more questions about JVMDI. Does Inprise JIT
(libjavacomp.so) support JVMDI? And how about Sun's
(libsunwjit.so)? I suppose Sun JIT does not and Inprise
JIT may possibly do. If Inprise JIT does not, JBuilder
should suffer it. Or is debugging possible as far as JIT
is disabled?

JIT compilers have to support JVMDI to make it
work. Some functions of JVMDI need JIT support. For
instance, access to local variables and location
(a.k.a. program counter) in a stack frame. The functions
cannot work correctly without JIT support because native
code generated by JIT has its own execution context
which differ from the context for JVM as a stack machine.

Note that we have to diable JIT when we use Sun's JPDA
1.0. A paragraph in JPDA documents "Starting a VM with a
JVMDI Client" says, you have to disable JIT if you'd
like to debug because the classic VM does not support
debugging with the JIT enabled.

I don't know about other JVM specifically. But HotSpot
VM can support debugging. In other words it will support
JVMDI. The HotSpot VM has a feature called "On stack
replacement". The function can convert the execution
context in compiled code to the context in JVM. And IBM
JIT can also do it as far as I heard.


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]

Reply via email to