Why "jobject" in JNI part is always outside Java heap?

[Colin(Du Li)]

Thanks a lot!
I understand the jobject contains a point to a java object. So if GC moves
the corresponding java object, the content of the jobject can be updated,
and reference to the new location.
Thanks again.

Du Li

john.coomes wrote:
> 
> Colin(Du Li) (dawn2004 at gmail.com) wrote:
>> 
>> Hello, I have a question related to JNI of hotspot.
>> According to my undestanding, a jobject is representation of java object
>> in
>> JNI part, so it should reside in Java heap.
> 
> Because the garbage collector may move objects, addresses within the
> java heap cannot be visible to native (JNI) code.  There's no way for
> the GC to find java object pointers in native code and update them so
> they refer to the new locations.  So jobject is just an opaque data
> item that the JVM can use to identify the object--a level of
> indirection.  See JNIHandles::resolve() in jniHandles.hpp.
> 
> -John
> 
>> I check the "jobject" on stack, I find it is always outside the java
>> heap.
>> (I give an example as follows.)
>> Is it correct? 
>> 
>> e.g.
>> for the method: virtual jobject
>> java.lang.ClassLoader.findLoadedClass0(jobject)
>> The stack is below:
>>  - local  [0x73f37e40] ; #0
>>  - local  [0x73f38c80] ; #1
>>  - stack  [0x73f38c80] ; #1
>>  - stack  [0x73f37e40] ; #0
>>  - monitor[0xbfd21c78]
>>  - bcp    [0xb3f31194] ; @16
>>  - locals [0xbfd21cf4]
>>  - method [0xb3f311c0] ; virtual jobject
>> java.lang.ClassLoader.findLoadedClass(jobject)
>> 
>> We can see two jobjects' addresses are:0x73f38c80, 0x73f37e40
>> 
>> But at this time I dump the heap layout, get information as below:
>> 
>> Heap
>>  def new generation   total 7936K, used 285K [0x73f40000, 0x747d0000,
>> 0x7b100000)
>>   eden space 7104K,   4% used [0x73f40000, 0x73f874c0, 0x74630000)
>>   from space 832K,   0% used [0x74630000, 0x74630000, 0x74700000)
>>   to   space 832K,   0% used [0x74700000, 0x74700000, 0x747d0000)
>>  tenured generation   total 63360K, used 0K [0x7b100000, 0x7eee0000,
>> 0xae440000)
>>    the space 63360K,   0% used [0x7b100000, 0x7b100000, 0x7b100200,
>> 0x7eee0000)
>>  tenured generation   total 6976K, used 0K [0xae440000, 0xaeb10000,
>> 0xb3f40000)
>>    the space 6976K,   0% used [0xae440000, 0xae440000, 0xae440800,
>> 0xaeb10000)
>>  compacting perm gen  total 16384K, used 1826K [0xb3f40000, 0xb4f40000,
>> 0xb7f40000)
>>    the space 16384K,  11% used [0xb3f40000, 0xb41089a0, 0xb4108a00,
>> 0xb4f40000)
>> No shared spaces configured.
>> 
>> The java heap starts from 0x73f40000, so I can tell two jobjects'
>> addresses
>> (0x73f38c80, 0x73f37e40) reside outside Java heap.
>> -- 
>> View this message in context:
>> http://www.nabble.com/Why-%22jobject%22-in-JNI-part-is-always-outside-Java-heap--tp22939687p22939687.html
>> Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at
>> Nabble.com.
>> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Why-%22jobject%22-in-JNI-part-is-always-outside-Java-heap--tp22939687p22943493.html
Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com.