[drlvm] Using JNI methods in VM's components. Part 2.

[Mikhail Fursov <mi...@gmail.com>]

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

Re: [drlvm] Using JNI methods in VM's components. Part 2.

[Xiao-Feng Li <xi...@gmail.com>]

Ok, sounds like there is a cyclic dependence to let the components to
initialize the Java code. Perhaps your solution is good at the moment.

Thanks,
xiaofeng

On 10/28/06, Mikhail Fursov <mi...@gmail.com> wrote:
> Resolution of a class is not enough. We need class initialization
> too, because helper classes can use static final variables.
> Another example: EMThreadSupport class - it's part of EM profile collection
> framework written in Java.
>
>
> On 10/28/06, Xiao-Feng Li <xi...@gmail.com> wrote:
> >
> > Mikhail, what methods should the initialization call for helpers? I
> > think only class loading is enough. Right?
> >
> > Thanks,
> > xiaofeng
> >
> >
>
>
> --
> Mikhail Fursov
>
>

Re: [drlvm] Using JNI methods in VM's components. Part 2.

[Mikhail Fursov <mi...@gmail.com>]

Resolution of a class is not enough. We need class initialization
too, because helper classes can use static final variables.
Another example: EMThreadSupport class - it's part of EM profile collection
framework written in Java.


On 10/28/06, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> Mikhail, what methods should the initialization call for helpers? I
> think only class loading is enough. Right?
>
> Thanks,
> xiaofeng
>
>


-- 
Mikhail Fursov

Re: [drlvm] Using JNI methods in VM's components. Part 2.

[Xiao-Feng Li <xi...@gmail.com>]

Mikhail, what methods should the initialization call for helpers? I
think only class loading is enough. Right?

Thanks,
xiaofeng

On 10/28/06, Mikhail Fursov <mi...@gmail.com> wrote:
> On 10/28/06, Xiao-Feng Li <xi...@gmail.com> wrote:
> >
> > 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.
> >
>
> Components are initialized before any Java code is executed. So it's unsafe
> to call Java method during components initialization.
> IMO the good point to initialize helper class is to do it in VMStart class.
>
>
> --
> Mikhail Fursov
>
>

Re: [drlvm] Using JNI methods in VM's components. Part 2.

[Mikhail Fursov <mi...@gmail.com>]

On 10/28/06, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> 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.
>

Components are initialized before any Java code is executed. So it's unsafe
to call Java method during components initialization.
IMO the good point to initialize helper class is to do it in VMStart class.


-- 
Mikhail Fursov

Re: [drlvm] Using JNI methods in VM's components. Part 2.

[Xiao-Feng Li <xi...@gmail.com>]

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 <mi...@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
>
>

Re: [drlvm] Using JNI methods in VM's components. Part 2.

[Mikhail Fursov <mi...@gmail.com>]

On 10/27/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>
> On 10/27/06, Mikhail Fursov <mi...@gmail.com> wrote:
> > On 10/27/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >
> > >
> > > Why just not use JNI to start required threads?
> >
> >
> > I think because JNIEnv is VM private data.
> Certanly not. Any java thread has JNIEnv. It can be easily obtained by
> GetEnv method.
>

And this is the problem: we need a Java thread to be initialized and run for
a component..

+ Some of the tasks I have do not need new Java threads. Example:
fast-helpers classes need only class initializer to be executed at the early
stage (after all necessarily bootstrap code is loaded but user's code have
not been executed yet).

-- 
Mikhail Fursov

Re: [drlvm] Using JNI methods in VM's components. Part 2.

[Evgueni Brevnov <ev...@gmail.com>]

On 10/27/06, Mikhail Fursov <mi...@gmail.com> wrote:
> On 10/27/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >
> >
> > Why just not use JNI to start required threads?
>
>
> I think because JNIEnv is VM private data.
Certanly not. Any java thread has JNIEnv. It can be easily obtained by
GetEnv method.

> And another quesiton is when to do it..

Technically it can be done any time once you obtatined JNIEnv :-)
Unfortunatelly, I don't know enough details to decide about your
particular case....

Evgueni

>
>
> --
> Mikhail Fursov
>
>

Re: [drlvm] Using JNI methods in VM's components. Part 2.

[Mikhail Fursov <mi...@gmail.com>]

On 10/27/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>
>
> Why just not use JNI to start required threads?


I think because JNIEnv is VM private data. And another quesiton is when to
do it..


-- 
Mikhail Fursov

Re: [drlvm] Using JNI methods in VM's components. Part 2.

[Evgueni Brevnov <ev...@gmail.com>]

This may be a stupid question, but

Why just not use JNI to start required threads?

On 10/27/06, Mikhail Fursov <mi...@gmail.com> wrote:
> On 10/27/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >
> > Mikhail,
> >
> > Could you give some info on:
> >
> > 1) What is the reason behined moving EMThreadSupport out of kernel
> > classes?
>
>
> Because it is the part of EM component, but not VM.
>
> 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.
>
>
> This could be a complete solution if you tell me when a component can do it
> and how it can :)
>
> --
> Mikhail Fursov
>
>

Re: [drlvm] Using JNI methods in VM's components. Part 2.

[Mikhail Fursov <mi...@gmail.com>]

On 10/27/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>
> Mikhail,
>
> Could you give some info on:
>
> 1) What is the reason behined moving EMThreadSupport out of kernel
> classes?


Because it is the part of EM component, but not VM.

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.


This could be a complete solution if you tell me when a component can do it
and how it can :)

-- 
Mikhail Fursov

Re: [drlvm] Using JNI methods in VM's components. Part 2.

[Evgueni Brevnov <ev...@gmail.com>]

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 <mi...@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
>
>