harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject [drlvm] Using JNI methods in VM's components. Part 2.
Date Fri, 27 Oct 2006 06:59:07 GMT
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

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
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?

EMThreadSupport is not the only usecase. The fast-path helper classes is
another usecase: the helper class must be initialized before use.

Mikhail Fursov

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message