harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm] Using JNI methods in VM's components. Part 2.
Date Fri, 27 Oct 2006 23:18:33 GMT
For helpers, we can let the owning components to initialize them
through VM interfaces if this is possible. And this is done when the
owning components are initialized by the VM.


On 10/27/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> VM gurus,
> In the previous thread called "[drlvm] Using JNI methods in VM's components"
> we have agreed that the best way for a component's Java code to communicate
> with a component's native code is to load the native library with "
> System.load/loadLibrary(..)" call.
> We have one more issue to discuss: Who is responsible to initiate this
> loading.
> The example: EMThreadSupport class creates a Java thread that is used for
> asynchronous profile checks and hot methods recompilation in EM.
> The question: Who will start the thread if I move EMThreadSupport out of the
> kernel classes?
> My proposal is to add the following service:
> 1. The VMStart class looks for all system properties with some reserved
> prefix name.
> 2. The VMStart class treats the value of the property as a name of some
> class.
> 3. The VMStart class calls predefined static method for the class: init
> 4. When VM is shutting down, the VMStart class performs steps 1-3 but calls
> deinit method instead of init.
> What do you think about this? Other ideas?
> ps.
> EMThreadSupport is not the only usecase. The fast-path helper classes is
> another usecase: the helper class must be initialized before use.
> --
> Mikhail Fursov

View raw message