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 Thu, 10 Jan 2008 15:19:22 GMT
Gregory Shimansky wrote:
> On 8 января 2008 Jimmy,Jing Lv wrote:
>> Hi All,
>>     I've done some study on the Harmony JDWP. The current JDWP is of
>> high quality and well-tested (really good job! :)).
>>     However compared with RI's implementation, I find RI has a
>> shared-memory transport (startup like "java
>> -agentlib:jdwp=transport=dt_shmem"). As Harmony's target is compatible
>> with RI, we may implement a shared-memory transport as well as RI
>> does. Do some one already has such plan? Or I'd like to implement in
>> the near future.
>>     A further study in windows API shows we may not use shared memory
>> directly, windows pipe api (pipe is also a kind of "shared memory", is
>> it?) may be a good alternative. In all we need to implement
>> open/read/write/select/close operations with pipe/shared-memory and
>> implement agent-load/unload shared-memory agent and error-handling
>> like socket-transport do.
> I think we should need the same method that the client (eclipse or whatever 
> IDE or debugger) use for connecting to the agent. Since clients are usually 
> written in Java the method should be done in the same way it is done in Java 
> API. I am not aware of however with a way for a Java application to use 
> shared memory or windows pipe API. Do you know some client debugger or 
> profiler that uses dt_shmem method and API that it uses for connection to the 
> debuggee?

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.

Anyone recall seeing a spec for it or is it non-standard?

>>     And I also notice that there' s some updates on JDWP-protocol in
>> java6, e.g, some new commands on
>> VirtualMachine/ReferenceType/ObjectReference/ThreadReference/CapabilitiesNe
>> w Command Set, which is necessary for Java6 implemetation. We may also
>> implement them in a tools Java6 branch (currently only classlib has Java6
>> branch, we may also build a repository for others? ) I'm not sure DRLVM has
>> a plan to update vmi/jvmti to java6 level, however I think update JDWP
>> first will do no harm.
> Well, eventually we'll have to have a version of DRLVM for Java6 (whether it 
> is going to be a branch, compile time define or some other way is a subject 
> for a separate discussion). In any case, JDWP agent should be working with 
> RI, so it is possible to add updates for new JDWP protocol functionality and 
> test it with RI for now. Again, maybe it will require a separate branch for 
> jdktools or build time define flag.
>>      Any suggestion/comments? I may start further study/plan and
>> implementation for this if no objection.
> I think it would be great to start supporting Java6 features not only in class 
> library!



View raw message