2007/4/29, Tingpeng Wu <[EMAIL PROTECTED]>:
Hi, xiaofeng,
1. I also feel very unnatural to call it through MyRuntime class, but I don't
know how to call it directly. Since drlvm needs HotSpot to help it to compile
the java source code, if I don't call it though an instance, the HotSpot
couldn't distinguish it. If I let the Jit to add the free() call in a future
time, I will not need it any more.
:) Java static method can be called as SomeClass.StaticMethod, so your
program can be written as (it is nothing related with compiler)
public static void main(String[] args)
{
set(10);
System.out.println(get());
}
2. I added an method named "unsigned int get_object_addr(jobject jobj)" in
object_handle.cpp to return the address of jobj . I can call it directly to get the
object address in free() method. Since I could not assure whether it can get the right
address, so I add the get_obj_addr() for test purpose. I will delete it if it can work
corredtly.
Ah, I don't catch well here. Why do you need a free() function here?
If you alloc a java object (no matter in java or native), you can just
leave it alone and let GC do everything for you. Free() is too c-style
for Java developer :)
In the other way, if you want to alloc some memory for other use, for
an example, char array in c/c++, you can just keep its address(you can
keep a jlong as void* ) and free it at last(you'd better free in this
case or you'll get memory leak). It is such easier to keep/pass a
jlong value than jobject handle.
3. Another quesetion: where is runtime helper you speak of? I am afraid I need
do some investigation on it.
Thanks,
tingpeng
----- Original Message -----
From: "Xiao-Feng Li" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Sunday, April 29, 2007 4:05 PM
Subject: Re: problem about System.loadLibrary and object's address
> Tingpeng,
>
> 1. Your native is static native, why do you call it through an instance?
> 2. You probably need to use runtime helper for the object direct free
> in Java app, because the default JNI call path will save the object
> handle (and passes the reference address as a root entry during GC
> enumeration). For your purpose, there is no GC happening in free(),
> so it probably works with a stale object reference (freed) in the
> object handle.
> 3. You can use free() directly to retrieve its object address from the
> handle. Why do you need the get_obj_addr() method?
>
> Thanks,
> xiaofeng
>
> On 4/29/07, Tingpeng Wu <[EMAIL PROTECTED]> wrote:
>> Thanks, xiaofeng,
>> My test program is simple as follows:
>>
>> public class JNItest
>>
>> {
>>
>> static
>>
>> {
>>
>> System.loadLibrary("goodluck");
>>
>> }
>>
>>
>>
>> public native static int get();
>>
>> public native static void set(int i);
>>
>>
>>
>> public static void main(String[] args)
>>
>> {
>>
>> JNItest test = new JNItest();
>>
>> test.set(10);
>>
>> System.out.println(test.get());
>>
>> }
>>
>> }
>>
>> Then I use javah to produce JNItest.h and implement two method in JNItest.cpp. Then
use them to build goodluck.dll. I use the latest verson of drlvm to test it, there is still an
error which reports "Vm launcher meets error and needs shut up (this is translated from
chinese)".
>>
>> The reason I asked the second problem is I want to get the address of obj in
java to support the reclaimation. I plan to
>> MyRuntime class, which has a native method,
>> My thought now is as follows:
>> 1. provide a new class named MyRuntime which has two native methods.
>> class MyRuntime
>> {
>> static
>> {
>> System.loadLibrary("runtime");
>> }
>>
>> //public native static void alloc(……);
>>
>> public native static void get_obj_addr(Object obj);
>>
>> //public native static void free(Object obj);
>> }
>>
>> 2. export the get_object_addr(jobject jobj) in vmcore to support
MyRuntime.get_obj_addr(Object obj)
>> 3. export the free(unsigned size, void* address) in gc to support
MyRuntime.free(Object obj)
>> 4. if above is right, I can call MyRuntime.free(obj) in java method.
>>
>>
>>
>> Is it feasible to get address that way to support the reclaimation method?
>>
>> Thanks,
>> tingpeng
>>
>> ----- Original Message -----
>> From: "Xiao-Feng Li" <[EMAIL PROTECTED]>
>> To: <[email protected]>
>> Sent: Sunday, April 29, 2007 11:06 AM
>> Subject: Re: problem about System.loadLibrary and object's address
>>
>>
>> > Tingpeng, can you post your program if there is no legal issue? (e.g.,
>> > open a JIRA issue and attach your code there).
>> >
>> > For your second question, itis pretty the core part of JVM native
>> > interface design. Yes, the handle is used to access Java object
>> > indirectly. The idea is to support object movement during GC, then the
>> > real new address of the same object can be stored to the handle. It's
>> > not supposed to be used everywhere in the JVM, because that may break
>> > the protocol of JNI, causing GC to fail to update the object new
>> > address, e.g., if it is put into a register by your C compiler. You
>> > can access it in two ways: either always use JNI interface, or
>> > guarantee there is GC happening when you access it.
>> >
>> > Thanks,
>> > xiaofeng
>> >
>> > On 4/29/07, 吴廷鹏 <[EMAIL PROTECTED]> wrote:
>> >> Hi, all,
>> >> when I use drlvm to execute my program, I found that when program has System.loadLibrary
call, there is always an error which reports "java.lang.outofmemoryerror <no stack trace
available>". The same program can run on Hotspot. Why this happens and how to solve it?
>> >>
>> >> Another question, I read the implementation code of Object.clone method
in Object_generic.cpp.
>> >>
>> >> jobject object_clone(JNIEnv *jenv, jobject jobj)
>> >> {
>> >> ObjectHandle h = (ObjectHandle) jobj;
>> >>
>> >> //aquire the target address and assign it to variable named result
>> >>
>> >> memcpy(result, h->object, size);
>> >>
>> >> }
>> >> According to my comprehension, h->object is the address of java object.
Is it ture? Does this means I can use the same way to get the address of object in vmcore's
other place provided the necessary head file is included?
>> >>
>> >> Thanks,
>> >> tingpeng
>> >>
>> >
>> >
>> > --
>> > http://xiao-feng.blogspot.com
>> >
>
>
> --
> http://xiao-feng.blogspot.com
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
