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.
Thanks, xiaofeng On 10/27/06, Mikhail Fursov <[EMAIL PROTECTED]> 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
