Why does "jobject" on interpreter stack point to wield locations?
Colin(Du Li)
dawn2004 at gmail.com
Wed Apr 15 09:53:21 PDT 2009
Thanks, and this is also the only explanation I can come up with.
Colin
Tom Rodriguez wrote:
>
> I think dumping frames that are used for invoking natives is probably
> going to give you strange results since they aren't really treated as
> regular interpreter frames for gc purposes.
>
> tom
>
> On Apr 14, 2009, at 11:45 AM, Colin(Du Li) wrote:
>
>>
>> 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.
>>
>
>
>
--
View this message in context: http://www.nabble.com/Why-does-%22jobject%22-on-interpreter-stack-point-to-wield-locations--tp23033048p23062816.html
Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com.
More information about the hotspot-dev
mailing list