harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [jdktools][JDWP] proposal to improve JDWP with shared memory and update to java6
Date Mon, 14 Jan 2008 15:55:21 GMT
Ivan Popov wrote:
>> I believe that the Eclipse JDT debugger team wrote their own JDWP client
>> code, but not sure if it supports the shmem transport.  I can go over
>> and ask.
> 
> Eclipse JDT Debugger uses its own JDI implementation (JDWP client
> code), which includes JDI connectors only over TCP/IP socket transport
> and don't support shmem transport. There is no support in Eclipse for
> using any other JDI connectors, even if they are provided by
> underlying JDK.

Yes.

> Netbeans debugger and Sun's jdb demo use JDI connectors provided by
> underlying JDK, and thus may occasionally use shmem transport running
> with RI (they use some internal algorithm for choosing appropriate
> transport).

I wonder if they will 'fall back' to using dt_socket if dt_shmem is 
unavailable.

> I'm not sure if commercial debuggers, e.g., integrated
> into Idea and JBuilder environments, use JDI connectors from
> underlaying JDK and allow choosing particular connector. Most likely
> they behave the same way.

Sorry, do you mean there is a JDI client implementation in Sun's JDK for 
applications to use?

>> Anyone recall seeing a spec for it or is it non-standard?
> 
> Any transport layer used for JDWP connection should be supported on
> both debugger and debuggee sides [1]. On JDWP agent's side it should
> follow jdwpTransport spec [2]. On debugger's side (JDI front-end) it
> should provide a set of JDI connectors over given JDWP transport that
> follow JDI Pluggable Connectors and Transports API
> (com.sun.jdi.connect.*, com.sun.jdi.connect.spi.* in JDI spec) [3].
> 
> The problem is that implementation of the same JDWP transport in
> different JDK should be compatible. Otherwise it may break
> interoperability between debugger and debuggee if they are started on
> different JDKs (e.g., debugger started on RI tries to connect to
> debuggee running on Harmony). Implementation of socket transport is
> based on well known sockets API and thus is de-facto compatible
> between different JDKs. For shmem transport provided by RI
> implementation is not evident and is not documented anywhere, so it's
> hard to implement it in a compatible manner even following these
> specifications.

Yes, that's what I'm trying to figure out here.  If it is not part of a 
spec then I guess it is not part of Java compliance, even though we may 
want to do it for compatibility with the RI.

> If someone likes to make independent implementation of shmem JDWP
> transport, e.g., based on pipes, he probably should give it different
> name - dt_pipes or so, in order to distinguish it from RI's dt_shmem
> implementation and avoid compatibility issues. But I doubt that any
> popular Java debugger will be able to use such a non-standard
> transport, at least without special tricks.

Yes, but I think in this case we probably should be trying to so the 
dt_shmem transport first.

Thanks for your useful comments.

Regards,
Tim

> [1] http://java.sun.com/j2se/1.5.0/docs/guide/jpda/conninv.html
> [2] http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdwpTransport.html
> [3] http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdi/index.html
> 

Mime
View raw message