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
>

Reply via email to