Re: [drlvm] Using JNI methods in VM's components. Part 2.
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.
On 10/28/06, Xiao-Feng Li [EMAIL PROTECTED] 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, what methods should the initialization call for helpers? I think only class loading is enough. Right? Thanks, xiaofeng On 10/28/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/28/06, Xiao-Feng Li [EMAIL PROTECTED] 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.
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 [EMAIL PROTECTED] 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, 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 [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
Re: [drlvm] Using JNI methods in VM's components. Part 2.
On 10/27/06, Evgueni Brevnov [EMAIL PROTECTED] 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.
This may be a stupid question, but Why just not use JNI to start required threads? On 10/27/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/27/06, Evgueni Brevnov [EMAIL PROTECTED] 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.
On 10/27/06, Evgueni Brevnov [EMAIL PROTECTED] 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.
On 10/27/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/27/06, Evgueni Brevnov [EMAIL PROTECTED] 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.
On 10/27/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: On 10/27/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/27/06, Evgueni Brevnov [EMAIL PROTECTED] 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.
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
Re: [drlvm] Using JNI methods in VM's components.
Mikhail, can relative path be specified in -Dvm.gc_dll/-Dvm.em_dll? If so, the path should be extended to represent full path. Regards, On 10/21/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/21/06, Gregory Shimansky [EMAIL PROTECTED] wrote: This is the reason I've corrected the code. Doesn't it mean that is you specified something in -Dvm.em_dll on command line that System.getProperty would return non null value, and then you shall use System.load instead of System.loadLibrary? That is if you change gc to em in the code above. Gregory, I have completely forgotten about System.load() and System.loadLibrary() differences. So the problem is solved and I have even tested the code :) -- Mikhail Fursov -- Pavel Pervov, Intel Enterprise Solutions Software Division
Re: [drlvm] Using JNI methods in VM's components.
Mikhail, What i've meant is that we should account for all interchangeable components which can/want/should provide fast-path helpers. Pavel. On 10/21/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Pavel, I'm sorry I do not understand what the replacement do you mean? I said that only about a part of a component could be written in Java (e.g . EM, helpers), but not the whole component... On 10/20/06, Pavel Pervov [EMAIL PROTECTED] wrote: What about TM replacement (although it is almost impossible at the moment)? -- Mikhail Fursov -- Pavel Pervov, Intel Enterprise Solutions Software Division
Re: [drlvm] Using JNI methods in VM's components.
On Monday 23 October 2006 14:15 Pavel Pervov wrote:
Mikhail,
can relative path be specified in -Dvm.gc_dll/-Dvm.em_dll? If so, the path
should be extended to represent full path.
So it should be something like
class GCv5Magics {
static {
String gcPath = System.getProperty(vm.gc_dll);
if (gcPath != null) {
try {
gcPath = (new File(gcPath)).getCanonicalName();
} catch (IOException e) {
System.err.println(Failed to find library specified in
\vm.gc_dll\ property: + e);
System.loadLibrary(gc);
return;
}
System.load(gcPath);
}
else {
System.loadLibrary(gc);
}
}
}
On 10/21/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/21/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
This is the reason I've corrected the code. Doesn't it mean that is you
specified something in -Dvm.em_dll on command line that
System.getProperty
would return non null value, and then you shall use System.load instead
of
System.loadLibrary? That is if you change gc to em in the code above.
Gregory, I have completely forgotten about System.load() and
System.loadLibrary() differences. So the problem is solved and I have
even tested the code :)
--
Mikhail Fursov
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm] Using JNI methods in VM's components.
What about TM replacement (although it is almost impossible at the moment)?
Pavel.
On 10/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/20/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Yeap.
The following addresse both your issues.
class GCv5Magics {
static {
String gcPath = System.getProperty(vm.gc_dll);
if (gcPath == null) {
System.load(gcPath);
}
else {
System.loadLibrary(gc.dll);
}
}
}
I like this approach! :)
Pavel ?
--
Mikhail Fursov
Re: [drlvm] Using JNI methods in VM's components.
On 10/21/06, Gregory Shimansky [EMAIL PROTECTED] wrote: This is the reason I've corrected the code. Doesn't it mean that is you specified something in -Dvm.em_dll on command line that System.getProperty would return non null value, and then you shall use System.load instead of System.loadLibrary? That is if you change gc to em in the code above. Gregory, I have completely forgotten about System.load() and System.loadLibrary() differences. So the problem is solved and I have even tested the code :) -- Mikhail Fursov
Re: [drlvm] Using JNI methods in VM's components.
Pavel, I'm sorry I do not understand what the replacement do you mean? I said that only about a part of a component could be written in Java (e.g. EM, helpers), but not the whole component... On 10/20/06, Pavel Pervov [EMAIL PROTECTED] wrote: What about TM replacement (although it is almost impossible at the moment)? -- Mikhail Fursov
Re: [drlvm] Using JNI methods in VM's components.
Mikhail,
You certainly can. Just add System.loadLibrary(component name) to the
static initialization block of a class, which declares that method and call
clinit for such class.
Example.
--
Component: gcv5.dll
Class, implementing fast path magics: GCv5Magics
Class source:
class GCv5Magics {
static {
System.loadLibrary(gcv5.dll);
}
// ... the rest of magics for GC v5
}
Regards,
Pavel.
P.S. clinit is not called for such classes now, but magics are all
something new to add to VM.
On 10/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
All,
AFAIK today I can't add JNI method to a component (em library, gc library,
jit library) and call the method from Java.
Is there any reason why do we have this limitation?
I have only the one, but IMO very serious reason why to allow it: a part
of
a component could be written in Java.
The example is EMThreadSupport.java class. This class is a part of the
kernel classes but this is wrong.
I can't extend its functionality without modification of VM-EM native
interface.
?
--
Mikhail Fursov
Re: [drlvm] Using JNI methods in VM's components.
Pavel,
I do this workaround for my local needs.
The problem in your solution is dll name: gcv5
I can built my own version of GC - gcv5_plus_some_features and put it into
any directory I want (-Dvm.gc_dll ?)
Should I fix the Java sources in this case?
The possible solution could be to set up system property: -
Dgcv5.my_current_location and read it from Java, but I see 2 problems:
1) A component (GC) must know its library name
2) java.library.path must be modified before the load and restored after
the load, because System.loadLibrary is not able to load library with fully
qualified path.
Any other ideas?
On 10/20/06, Pavel Pervov [EMAIL PROTECTED] wrote:
Mikhail,
You certainly can. Just add System.loadLibrary(component name) to the
static initialization block of a class, which declares that method and
call
clinit for such class.
Example.
--
Component: gcv5.dll
Class, implementing fast path magics: GCv5Magics
Class source:
class GCv5Magics {
static {
System.loadLibrary(gcv5.dll);
}
// ... the rest of magics for GC v5
}
Regards,
Pavel.
P.S. clinit is not called for such classes now, but magics are all
something new to add to VM.
On 10/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
All,
AFAIK today I can't add JNI method to a component (em library, gc
library,
jit library) and call the method from Java.
Is there any reason why do we have this limitation?
I have only the one, but IMO very serious reason why to allow it: a part
of
a component could be written in Java.
The example is EMThreadSupport.java class. This class is a part of the
kernel classes but this is wrong.
I can't extend its functionality without modification of VM-EM native
interface.
?
--
Mikhail Fursov
--
Mikhail Fursov
Re: [drlvm] Using JNI methods in VM's components.
Mikhail.
If you make your own version of GC (presumably, modifying it's sources), you
surely can modify one string in Java file too.
More interesting is the fact that the library can reside anywhere in the
system. As loading and initializing components happens at early stage
of starting VM - there is only one thread at that time, and we can safely
change any system properties (restoring it afterwards) before calling to
component's helpers class static initializer, your idea of changing
java.library.path will do the trick.
Also, it is not only GC, which can be replaced at start time. Which means,
this interface (to load helpers JAR file for a particular component) should
be available through VM Core for other components.
Regards,
Pavel.
On 10/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Pavel,
I do this workaround for my local needs.
The problem in your solution is dll name: gcv5
I can built my own version of GC - gcv5_plus_some_features and put it into
any directory I want (-Dvm.gc_dll ?)
Should I fix the Java sources in this case?
The possible solution could be to set up system property: -
Dgcv5.my_current_location and read it from Java, but I see 2 problems:
1) A component (GC) must know its library name
2) java.library.path must be modified before the load and restored after
the load, because System.loadLibrary is not able to load library with
fully
qualified path.
Any other ideas?
On 10/20/06, Pavel Pervov [EMAIL PROTECTED] wrote:
Mikhail,
You certainly can. Just add System.loadLibrary(component name) to the
static initialization block of a class, which declares that method and
call
clinit for such class.
Example.
--
Component: gcv5.dll
Class, implementing fast path magics: GCv5Magics
Class source:
class GCv5Magics {
static {
System.loadLibrary(gcv5.dll);
}
// ... the rest of magics for GC v5
}
Regards,
Pavel.
P.S. clinit is not called for such classes now, but magics are all
something new to add to VM.
On 10/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
All,
AFAIK today I can't add JNI method to a component (em library, gc
library,
jit library) and call the method from Java.
Is there any reason why do we have this limitation?
I have only the one, but IMO very serious reason why to allow it: a
part
of
a component could be written in Java.
The example is EMThreadSupport.java class. This class is a part of the
kernel classes but this is wrong.
I can't extend its functionality without modification of VM-EM native
interface.
?
--
Mikhail Fursov
--
Mikhail Fursov
Re: [drlvm] Using JNI methods in VM's components.
Mikhail Fursov :
Pavel,
I do this workaround for my local needs.
The problem in your solution is dll name: gcv5
I can built my own version of GC - gcv5_plus_some_features and put it into
any directory I want (-Dvm.gc_dll ?)
Should I fix the Java sources in this case?
The possible solution could be to set up system property: -
Dgcv5.my_current_location and read it from Java, but I see 2 problems:
1) A component (GC) must know its library name
2) java.library.path must be modified before the load and restored after
the load, because System.loadLibrary is not able to load library with fully
qualified path.
Any other ideas?
Yeap.
The following addresse both your issues.
class GCv5Magics {
static {
String gcPath = System.getProperty(vm.gc_dll);
if (gcPath == null) {
System.load(gcPath);
}
else {
System.loadLibrary(gc.dll);
}
}
}
--
Thanks,
Alex
On 10/20/06, Pavel Pervov [EMAIL PROTECTED] wrote:
Mikhail,
You certainly can. Just add System.loadLibrary(component name) to the
static initialization block of a class, which declares that method and
call
clinit for such class.
Example.
--
Component: gcv5.dll
Class, implementing fast path magics: GCv5Magics
Class source:
class GCv5Magics {
static {
System.loadLibrary(gcv5.dll);
}
// ... the rest of magics for GC v5
}
Regards,
Pavel.
P.S. clinit is not called for such classes now, but magics are all
something new to add to VM.
On 10/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
All,
AFAIK today I can't add JNI method to a component (em library, gc
library,
jit library) and call the method from Java.
Is there any reason why do we have this limitation?
I have only the one, but IMO very serious reason why to allow it: a
part
of
a component could be written in Java.
The example is EMThreadSupport.java class. This class is a part of the
kernel classes but this is wrong.
I can't extend its functionality without modification of VM-EM native
interface.
?
--
Mikhail Fursov
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Using JNI methods in VM's components.
Alex Astapchuk :
Mikhail Fursov :
Pavel,
I do this workaround for my local needs.
The problem in your solution is dll name: gcv5
I can built my own version of GC - gcv5_plus_some_features and put it
into
any directory I want (-Dvm.gc_dll ?)
Should I fix the Java sources in this case?
The possible solution could be to set up system property: -
Dgcv5.my_current_location and read it from Java, but I see 2 problems:
1) A component (GC) must know its library name
2) java.library.path must be modified before the load and restored
after
the load, because System.loadLibrary is not able to load library with
fully
qualified path.
Any other ideas?
Yeap.
The following addresse both your issues.
class GCv5Magics {
static {
String gcPath = System.getProperty(vm.gc_dll);
if (gcPath == null) {
... and the patch already exists... :-)
if (gcPath != null) {
System.load(gcPath);
}
else {
System.loadLibrary(gc.dll);
System.loadLibrary(gc);
}
}
}
--
Thanks,
Alex
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Using JNI methods in VM's components.
Mikhail Fursov :
On 10/20/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Yeap.
The following addresse both your issues.
class GCv5Magics {
static {
String gcPath = System.getProperty(vm.gc_dll);
if (gcPath == null) {
System.load(gcPath);
}
else {
System.loadLibrary(gc.dll);
}
}
}
I like this approach! :)
You will like it even more with a patch (already posted) ;-)
--
Thanks,
Alex
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Using JNI methods in VM's components.
Alex Astapchuk wrote:
Mikhail Fursov :
On 10/20/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Yeap.
The following addresse both your issues.
class GCv5Magics {
static {
String gcPath = System.getProperty(vm.gc_dll);
if (gcPath == null) {
System.load(gcPath);
}
else {
System.loadLibrary(gc.dll);
}
}
}
I like this approach! :)
You will like it even more with a patch (already posted) ;-)
I like this way too. I didn't know about System.load method, it fits
perfectly here. One small correction, it should be
System.loadLibrary(gc) without .dll.
--
Gregory Shimansky, Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Using JNI methods in VM's components.
One thing to care about is to take correct corresponding jar file for
each gc library. How this can be solved?
--
Ivan
On 10/20/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
Alex Astapchuk wrote:
Mikhail Fursov :
On 10/20/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Yeap.
The following addresse both your issues.
class GCv5Magics {
static {
String gcPath = System.getProperty(vm.gc_dll);
if (gcPath == null) {
System.load(gcPath);
}
else {
System.loadLibrary(gc.dll);
}
}
}
I like this approach! :)
You will like it even more with a patch (already posted) ;-)
I like this way too. I didn't know about System.load method, it fits
perfectly here. One small correction, it should be
System.loadLibrary(gc) without .dll.
--
Gregory Shimansky, Intel Middleware Products Division
--
Ivan
Intel Enterprise Solutions Software Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Using JNI methods in VM's components.
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: One thing to care about is to take correct corresponding jar file for each gc library. How this can be solved? This is one of the main problems in helpers fast-path inlining task! I thought about the following: GC sets system variable gc.helper_class if it wants JIT to use java helpers. JIT runs the resolution if the property is set. Is it ok? -- Mikhail Fursov
Re: [drlvm] Using JNI methods in VM's components.
Alex,
we still have a problem with your solution :(
System.loadLibrary does not accept full paths, but -Dvm.em_dll could be a
full path to a library. IMO the workaround with parsing the path and
adjusting java.library.path before loading a library is bad solution.
Any thoughts?
All,
Are there any potential security or compatibility problems to add native C
method to allow to a component to register itself as library in
bootclassloader context?
On 10/20/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Mikhail Fursov :
On 10/20/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Yeap.
The following addresse both your issues.
class GCv5Magics {
static {
String gcPath = System.getProperty(vm.gc_dll);
if (gcPath == null) {
System.load(gcPath);
}
else {
System.loadLibrary(gc.dll);
}
}
}
I like this approach! :)
You will like it even more with a patch (already posted) ;-)
--
Thanks,
Alex
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mikhail Fursov
Re: [drlvm] Using JNI methods in VM's components.
On 10/21/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
I think there is a mistake in the code which Alex wrote (or it would
simply throw NPE). It should be
class GCv5Magics {
static {
String gcPath = System.getProperty(vm.gc_dll);
-if (gcPath == null) {
+if (gcPath != null) {
System.load(gcPath);
}
else {
-System.loadLibrary(gc.dll);
+System.loadLibrary(gc);
}
}
}
because it makes sense to call System.load only when there is a property
specified on the command line and System.loadLibrary in the default
case. The same should be done for EM. Or am I missing something?..
Gregory, your fix is right (BTW I have not tried Alex's code yet, if I'd try
I would rewrite it without copying)
The problem is with fully qualified names for libraries that could be
provided with
-Dvm.em_dll option. You can't load it with System.loadLibrary(..) from Java
:(
--
Mikhail Fursov
Re: [drlvm] Using JNI methods in VM's components.
On Saturday 21 October 2006 01:26 Mikhail Fursov wrote:
On 10/21/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
I think there is a mistake in the code which Alex wrote (or it would
simply throw NPE). It should be
class GCv5Magics {
static {
String gcPath = System.getProperty(vm.gc_dll);
-if (gcPath == null) {
+if (gcPath != null) {
System.load(gcPath);
}
else {
-System.loadLibrary(gc.dll);
+System.loadLibrary(gc);
}
}
}
because it makes sense to call System.load only when there is a property
specified on the command line and System.loadLibrary in the default
case. The same should be done for EM. Or am I missing something?..
Gregory, your fix is right (BTW I have not tried Alex's code yet, if I'd
try I would rewrite it without copying)
The problem is with fully qualified names for libraries that could be
provided with
-Dvm.em_dll option. You can't load it with System.loadLibrary(..) from Java
:(
This is the reason I've corrected the code. Doesn't it mean that is you
specified something in -Dvm.em_dll on command line that System.getProperty
would return non null value, and then you shall use System.load instead of
System.loadLibrary? That is if you change gc to em in the code above.
--
Gregory Shimansky, Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
