Why does "jobject" on interpreter stack point to wield locations?
Thomas.Rodriguez at Sun.COM
Tue Apr 14 10:28:42 PDT 2009
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.
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
> All in all, how can I tell the reference on the stack is raw
> reference or
> Thanks again!
> Tom Rodriguez wrote:
>> That interpreter stack doesn't use jobjects. It contains raw
>> references to Java objects so just use them directly.
>> On Apr 13, 2009, at 9:21 PM, Colin(Du Li) wrote:
>>> 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
>>> 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[0xbff3f8c8]
>>> - bcp [0xb3f3fa4e] ; @2
>>> - locals [0xbff3f944]
>>> - method [0xb3f3fa78] ; virtual jobject
>>> According to the jvm specification, stack slot #0 should contain the
>>> "receiver", and stack slot to the parameter of method
>>> I use JNIHandles::resolve(obj) to resolve the two jobjects on the
>>> 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,
>>> The results confuse me. I assumed both of them pointed to some
>>> object is
>>> Could you give me some explanation for this question?
>>> I really need your help.
>>> Thanks a lot!
>>> View this message in context:
>>> 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.
More information about the hotspot-dev