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
Mikhail,

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.

Evgueni

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

Mime
View raw message