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

[Colin(Du Li)]

Hello.
Surprisingly, I run the previous example for a couple of time, and I find
sometimes the object reference on the stack use raw reference instead of
jobjects. Is my observation wrong? I feel very confused. Then when does the
stack use raw reference, and when does the stack use jobjects?
Thanks a lot.

Another run of the previous example as follows, we tell they use raw object
reference because they point to java heap.
stack frame:

virtual jobject java.lang.ClassLoader.findLoadedClass0(jobject)

 - local  [0x7e7b7b90] ; #0
 - local  [0x7e7b89d0] ; #1
 - stack  [0x7e7b89d0] ; #1
 - stack  [0x7e7b7b90] ; #0
 - monitor[0xbfea1628]
 - bcp    [0xb3fb1194] ; @16
 - locals [0xbfea16a4]
 - method [0xb3fb11c0] ; virtual jobject
java.lang.ClassLoader.findLoadedClass(jobject)

Heap layout:
Heap
 def new generation   total 5504K, used 197K [0x7e790000, 0x7ed80000,
0x846a0000)
  eden space 4928K,   4% used [0x7e790000, 0x7e7c14d0, 0x7ec60000)
  from space 576K,   0% used [0x7ec60000, 0x7ec60000, 0x7ecf0000)
  to   space 576K,   0% used [0x7ecf0000, 0x7ecf0000, 0x7ed80000)
 tenured generation   total 43776K, used 0K [0x846a0000, 0x87160000,
0xaf380000)
   the space 43776K,   0% used [0x846a0000, 0x846a0000, 0x846a0200,
0x87160000)
 tenured generation   total 4864K, used 0K [0xaf380000, 0xaf840000,
0xb3f90000)
   the space 4864K,   0% used [0xaf380000, 0xaf380000, 0xaf380800,
0xaf840000)
 compacting perm gen  total 16384K, used 1826K [0xb3f90000, 0xb4f90000,
0xb7f90000)
   the space 16384K,  11% used [0xb3f90000, 0xb41589a0, 0xb4158a00,
0xb4f90000)
No shared spaces configured.


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--tp22939687p23043853.html
Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com.