Why does "jobject" on interpreter stack point to wield locations?

[Colin(Du Li)]

Thanks a lot!
But you may take a look at this post:
http://www.nabble.com/Why-%22jobject%22-in-JNI-part-is-always-outside-Java-heap--td22939687.html.

In my first post, I actually found the stack held some references which
pointed outside java heap. I assumed these references are jobjects, but now
I'm not sure since you say "The interpreter stack always uses raw
references." But can you give me some explain why these references sometimes
(not always) point outside java heap. I'm really confused at this point.
Thanks again!

Colin.

Tom Rodriguez wrote:
> 
> There's some printing code that uses jobject as a placeholder for  
> java.lang.Object but it doesn't mean that it's really using a JNI  
> reference.  The interpreter stack always uses raw references.  When  
> creating frames for calling native methods we will pass JNI references  
> to that but the frame contains raw references and we pass the address  
> of those locations as JNI references.
> 
> tom
> 
> On Apr 14, 2009, at 10:03 AM, Colin(Du Li) wrote:
> 
>>
>> Thanks  a lot, Tom.
>> You are right!
>> But the question is when the stack use jobject? The method signature  
>> in the
>> previous example is "virtual jobject
>> java.lang.ClassLoader.loadClass(jobject)", which is quite confusing.
>> I know one possible answer is when the method is a "native" method,  
>> it will
>> use jobjects instead of raw reference.
>> However, I have observed it for a while. For the native method, stack
>> sometimes uses jobject, sometimes use raw references. Is my  
>> observation
>> right?
>> All in all, how can I tell the reference on the stack is raw  
>> reference or
>> jobject?
>> Thanks again!
>>
>> Colin
>>
>> Tom Rodriguez wrote:
>>>
>>> That interpreter stack doesn't use jobjects.  It contains raw
>>> references to Java objects so just use them directly.
>>>
>>> tom
>>>
>>> On Apr 13, 2009, at 9:21 PM, Colin(Du Li) wrote:
>>>
>>>>
>>>> Hello.
>>>> I'm playing with stack of c++ interpreter. I have some questions
>>>> about the
>>>> object reference on the stack.
>>>> Let's look at the following example:
>>>> When interpreter invoke("invokespecial") method  "virtual jobject
>>>> java.lang.ClassLoader.loadClass(jobject)", I print out stack frame
>>>> (last
>>>> frame), and the result is as follows:
>>>>
>>>> - local  [0x7e747b90] ; #0
>>>> - local  [0x7e7489d0] ; #1
>>>> - stack  [0x7e7489d0] ; #1
>>>> - stack  [0x7e747b90] ; #0
>>>> [ - obj
>>>> a 'sun/misc/Launcher$AppClassLoader'
>>>> - lock
>>>> monitor
>>>> - monitor[0xbff3f8c8]
>>>> - bcp    [0xb3f3fa4e] ; @2
>>>> - locals [0xbff3f944]
>>>> - method [0xb3f3fa78] ; virtual jobject
>>>> java.lang.ClassLoader.loadClassInternal(jobject)
>>>>
>>>> According to the jvm specification, stack slot #0 should contain the
>>>> "receiver", and stack slot to the parameter of method
>>>> "loadclass(jobject)".
>>>> I use JNIHandles::resolve(obj) to resolve the two jobjects on the
>>>> above
>>>> stack slot. The result of slot #0 is a reference pointing to another
>>>> slot of
>>>> the current stack. The result of slot #1 is a invalid address,  
>>>> "0x1".
>>>> The results confuse me. I assumed both of them pointed to some
>>>> object is
>>>> heap.
>>>> Could you give me some explanation for this question?
>>>> I really need your help.
>>>> Thanks a lot!
>>>>
>>>> Colin.
>>>> -- 
>>>> View this message in context:
>>>> http://www.nabble.com/Why-does-%22jobject%22-on-interpreter-stack-point-to-wield-locations--tp23033048p23033048.html
>>>> Sent from the OpenJDK Hotspot Virtual Machine mailing list archive
>>>> at Nabble.com.
>>>>
>>>
>>>
>>>
>>
>> -- 
>> View this message in context:
>> http://www.nabble.com/Why-does-%22jobject%22-on-interpreter-stack-point-to-wield-locations--tp23033048p23043577.html
>> Sent from the OpenJDK Hotspot Virtual Machine mailing list archive  
>> at Nabble.com.
>>
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Why-does-%22jobject%22-on-interpreter-stack-point-to-wield-locations--tp23033048p23045595.html
Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com.