harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Wu" <wuyue...@gmail.com>
Subject Re: [jdktools][JDWP]using portlib to support JDWP transport/agent?
Date Thu, 28 Feb 2008 08:48:55 GMT
On 2/28/08, Jimmy,Jing Lv <firepure@gmail.com> wrote:
> Hi,
>
>     Thanks Gregory, I find it may not be proper to using java code at
> that phase.
>     I search the current DRLVM to find what does System.loadLibrary()
> exactly do, it traces to kernel_classes
> (java_lang_System,java_lang_VMExecutionEngine,etc) and class_support
> (classloader),  at last, natives_load_library() in natives_support.cpp
> was invoked and called port_dso_load_ex(), then apr_dso_load() (which
> was in dso.cpp). This seems a APR method which was implemented in both
> windows and linux.
>     What's more, I check Harmony PortLib, and find
> hysl_open_shared_library(in hysl.c) which was used to load library for
> zlib in Harmony. So it seems good for our use to load library for all
> platforms(please correct me if I'm wrong).
>     To sum up, I'd like to raise 2 possible way to solve the problem IMO:
> 1. we call the vm method natives_load_library() to load library, which
> may requires the vm to export such method and drlvm guru may offer
> help for that?
How to handle the other VMs? I think it's not a public api.

> 2. we call the portib hysl_open_shared_library() to load the library,
> if it does work well for it.
+1 to portlib. Anyway we have the portlib in classlib already

>
>     IMHO, option 2 is better, which makes no dependence on VM and
> APR, but only on Harmony Portlib itself.
>     Comments/suggestions? Thanks! :)
>
> 2008/2/26, Gregory Shimansky <gshimansky@apache.org>:
> > Jimmy,Jing Lv said the following on 26.02.2008 12:15:
> >
> > > Hi,
> >  >
> >  > 2008/2/26, Ivan Popov <ivan.g.popov@gmail.com>:
> >  >> 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 notice the DLL loading as well. I have an idea here that shall we
> >  > start with java-level lib loading process? For Java code it may be
> >  > quite easy to do such work as:
> >  >      System.loadLibrary("libname");
> >  >
> >  > We can do similar things. What does native code do in this
> >  > "System.loadLibrary", does vm/classlib native code support such API
> >  > for work? If so, we may
> >  > 1) directly call that API  to load lib and avoid  platform differences
> >  > If no, we may
> >  > 2) create a java class to do the such work, reflect in the native
> >  > TransportManager. Though it may be a little strange and slower in
> >  > performance, it may also works.
> >  >
> >  > Any VM guru know what's happening in the System.loadLibrary()? Would
> >  > it be used without java-level call?
> >
> >
> > I am not sure that using Java is possible here. First, agent's
> >  initialization happens in ON_LOAD phase [1] where VM doesn't allow to
> >  execute any Java code yet.
> >
> >  Second, even if you make a call to System.loadLibrary (Java or
> >  underlying native function) you'd need the library handle to obtain
> >  (with a platform dependent function) function pointers from it.
> >
> >  [1] http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#GetPhase
> >
> >  --
> >
> > Gregory
> >
> >
>
>
> --
>
> Best Regards!
>
> Jimmy, Jing Lv
> China Software Development Lab, IBM
>


-- 
Tony Wu
China Software Development Lab, IBM

Mime
View raw message