Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of ivan.g.popov@gmail.com
 designates 209.85.134.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=BAYy4LZiVcJg4pEQmlSfAhW7qxFWwutdbcFHBbMRQ4m1Ah4gfgk71rBUzCQUC8nWUZCJrVdAoPIsjUFuoIQaNiZzoPr6pamFU8xE30e7fqYq7UCEQEgM11ZKew0qn/3tVC9RccxfBHih9XQ7Ia7tt4wsvx3LivezlFMQp/8ZjGk=
Message-ID: <b6cb498e0801160712n444505f5l77be870f716fbb34@mail.gmail.com>
Date: Wed, 16 Jan 2008 21:12:50 +0600
From: "Ivan Popov" <ivan.g.popov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [jdktools][JDWP] proposal to improve JDWP with shared memory and
 update to java6
In-Reply-To: <478B85E9.8010607@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <5c8e69f0801080006l6e927e24s72146219943a6f35@mail.gmail.com>
	 <200801082204.11457.gshimansky@apache.org>
	 <4786377A.1080306@gmail.com>
	 <b6cb498e0801110648s1d765abfna9dd5022f6e9546d@mail.gmail.com>
	 <478B85E9.8010607@gmail.com>

> > 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 doubt so. They probably rely on the standard set of connectors and
transports and apply some heuristics for choosing most appropriate
one.

I experimented a bit with NetBeans debugger and Sun's JDB demo. JDB
running with -attach or -listen option uses dt_shmem transport on
Windows, and thus cannot connect to application started on Harmony. On
Linux only dt_socket trrnsport is available and it is used by default.
However, it's is always possible to use option -connect and specify
any available connector and transport, but in a much more
sophisticated syntax.

NetBeans 5.5.1 looks using socket connector by default while launching
application locally on both Windows and Linux platforms, and thus
works well with Harmony. In attaching to a remote application it
allows user to choose any available connector and transport, so both
dt_socket and dt_shmem are supported. However, I'm not sure if
NetBeans is able to recognize and use any other pluggable connectors,
apart of standard ones, if they are provided by JDK or available as a
pluggable module.

> > 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?

Yes, JDI implementation based on JDWP protocol is included in Sun's
JDK (located in JDK/lib/tools.jar), as well as in other commercial
JDKs. Starndard connectors and transports are also included into
tools.jar, though since 1.5 they're made pluggable. JDK also provides
jdb tool as an example of a Java debugger based on JDI and JDWP.
Running "JDK/bin/jdb -listconnectors" prints list of connectors and
transports supported by this JDK.

> > 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.

Yes, number and internal implementation of JDI conectors and transport
services are not a part of JPDA specifications, it depends on JDK
wendor.

I think it's assumed that JDI connectors and transport are pluggable,
and thus can be used transparently on any JDK or JRE participated in
debugging session. However, in practice, JDI connectors and transports
are not provided as a pluggable module and are included into each JDK
or JRE, and thus should be compatible between different JDK's.

> > 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.

This will require investigation of internal behavior of dt_shmem
transport. [1] just mentions that shared memory transport "uses a
shared memory region", but does not provide details.

BTW, I missed link to a good description of development and deploying
transport service [4].

> > [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

[4] http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jpda_spis.html

Thanks.
Ivan