xiaofeng, I have two major problems which need to be solved currently.
1. In my computer, Drlvm's java.exe couldn't run the java program which has 
loadLibrary call. I don't know whether it is for drlvm's reason or not. I don't 
know if others can run it correctly. It is a troublesome matter for me. 
2. Is it proper to use MyRuntime which was refered yesterday to support the 
free(obj) in the early work which is lack of support of JIT? I planned to 
verify it by an test program. But for above reason, I couldn't go on now.

Thanks,
tingpeng
  
----- Original Message ----- 
From: "Xiao-Feng Li" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, April 30, 2007 9:47 AM
Subject: Re: problem about System.loadLibrary and object's address


> Tingpeng, I think for first step test, you can use traditional JNI.
> The fast JNI is only for performance here.
> 
> Thanks,
> xiaofeng
> 
> On 4/29/07, Tingpeng Wu <[EMAIL PROTECTED]> wrote:
>> xiaofeng, very thank you for your help and valuable time. I will try your 
>> suggestion next.
>> ----- Original Message -----
>> From: "Xiao-Feng Li" <[EMAIL PROTECTED]>
>> To: <[email protected]>
>> Sent: Sunday, April 29, 2007 8:36 PM
>> Subject: Re: problem about System.loadLibrary and object's address
>>
>>
>> > On 4/29/07, LvJimmy,Jing <[EMAIL PROTECTED]> wrote:
>> >> 2007/4/29, Tingpeng Wu <[EMAIL PROTECTED]>:
>> >> >
>> >> > ----- Original Message -----
>> >> > From: "LvJimmy,Jing" <[EMAIL PROTECTED]>
>> >> > To: <[email protected]>
>> >> > Sent: Sunday, April 29, 2007 5:24 PM
>> >> > Subject: Re: problem about System.loadLibrary and object's address
>> >> >
>> >> >
>> >> > > 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.
>> >> > >
>> >> > My thesis is to redesign the heap layout, and provide the free() method 
>> >> > to support reclaiming the object explicitly. Then in jit module, I will 
>> >> > add some analysis to insert some free call to reclaim the dead object 
>> >> > in advance. The purpose is to try to improve the efficiency of 
>> >> > program's execution.
>> >> >
>> >>
>> >> Got it, I remember we've already discussed this problem (free() in
>> >> java) and IIRC, some expert mark this problem as "mission impossible"
>> >> ... :)
>> >> However study something about GC may benefit your thesis. :)
>> >
>> > Jimmy, it's possible to insert free() automatically in jitted code to
>> > reclaim some short-lived objects. This can be a supplementary to the
>> > GC, and probably improve the overall performance. Tingpeng had
>> > previous discussions with me on this topic actually.
>> >
>> > TingPeng, the runtime helper is a way in DRLVM for the VM to provide
>> > JIT certain supports, e.g.,  exception throwing, etc.  One of the
>> > important usages of runtime helper is to provide a way of fast native
>> > method invocation. That is, when you know a native method never causes
>> > GC, you probably can use a runtime helper for JIT to generate code to
>> > invoke this native method directly without going through the JNI
>> > stuff. This makes native call fast.
>> >
>> > You can find runtime helper code in jit_runtime_support related files.
>> > Please go search VM_RT_AASTORE in vm source code, you will see in
>> > vmcore/src/util/ia32/base/jit_runtime_support_ia32.cpp how aastore can
>> > implemented in native code to support JIT.    VM_RT_GC_HEAP_WRITE_REF
>> > is an example for write barrier native implementation
>> > gc_heap_slot_write_ref().
>> >
>> > Please let me know if you have any further questions.
>> >
>> > Thanks. xiaofeng
>> >
>> >> > >
>> >> > >> 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
>> >> > >
>> >>
>> >>
>> >> --
>> >>
>> >> Best Regards!
>> >>
>> >> Jimmy, Jing Lv
>> >> China Software Development Lab, IBM
>> >>
>> >
>> >
>> > --
>> > http://xiao-feng.blogspot.com
>> >
> 
> 
> -- 
> http://xiao-feng.blogspot.com
>

Reply via email to