harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy,Jing Lv" <firep...@gmail.com>
Subject Re: [jdktools][JDWP]using portlib to support JDWP transport/agent?
Date Thu, 28 Feb 2008 06:24:41 GMT

     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?
2. we call the portib hysl_open_shared_library() to load the library,
if it does work well for it.

     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

View raw message