harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Popov" <ivan.g.po...@gmail.com>
Subject Re: [jdktools][JDWP]using portlib to support JDWP transport/agent?
Date Tue, 26 Feb 2008 04:14:11 GMT
JDWP agent and transport implementation was developed independent on
Harmony's drlvm and classlib implementations in order to be run easily
on top on any JVM. That's why it does not use any portlib support for
platform dependent code.

I agree, however, it would be better to re-use platform dependent
support from portlib to facilitate porting jdwp code to other
platforms. The only such code is TCP/IP sockets api used in dt_socket
transport and loading transport DLL in the agent itself. All other
code is based on standard JVMTI api and thus is platform independent.

I wish JVMTI spec to include support for loading DLLs in a platform
independent manner, this would make implementation of multi-layered
JVMTI agents (like JDWP agent) fully platform independent.

Thanks.
Ivan

On Mon, Feb 25, 2008 at 12:56 PM, Jimmy,Jing Lv <firepure@gmail.com> wrote:
> Hi All,
>
>      As I read the current JDWP transport/agent implementation I found
>  that it has two folders, which means now we have two copies of code
>  for windows and Linux. As we know, Harmony have a portlib which can
>  facilitate the development to various of platforms, so I believe maybe
>  we can use portlib to merge current 2  transport/agent into one?
>      IMHO, we will get following advantage if we use portlib in JDWP:
>  1. Harmony have various of customers on various of platform(e.g, I
>  remember some MacOS users do works on Harmony), we can use portlib to
>  support such users without any modification on code;
>  2. keep only one copy of code, omit unnecessary copies for various of
>  platforms. In this case, if any bug/improvement occurs, we can work on
>  only one codebase so that to facilitate the developement and avoid
>  some platform-specific errors.
>
>      And the current implementation shows we may need to refactor
>  network and memory APIs to with platform specific APIs, luckiely it
>  seems no much work.
>      Any comments/suggestions?
>
>  --
>
>  Best Regards!
>
>  Jimmy, Jing Lv
>  China Software Development Lab, IBM
>

Mime
View raw message