On 2/28/08, Jimmy,Jing Lv <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
> > Jimmy,Jing Lv said the following on 26.02.2008 12:15:
> >
> > > Hi,
> > >
> > > 2008/2/26, Ivan Popov <[EMAIL PROTECTED]>:
> > >> 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
