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

[Colin(Du Li)]

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.
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.

[john.coomes]

Colin(Du Li) (dawn2004@...) 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.
>

[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, how can the content of the jobject be updated, and reference to the new location.
Thanks again.

Du Li

john.coomes wrote:

Colin(Du Li) ([e-mail]) 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.
>

[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) ([e-mail]) 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.
>