harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm] Using JNI methods in VM's components. Part 2.
Date Fri, 27 Oct 2006 07:16:48 GMT

Could you give some info on:

1) What is the reason behined moving EMThreadSupport out of kernel classes?
2) Why VM core in particular VMStart class should care about
loading/initializing user's classes? I think it would be better if
component which needs EMThreadSupport loads the class by it self.


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