Using InterpreterOopMap

[Peter Helfer]

Ok, sorry to ask again:

If an oop is _not_ pointing to NULL (or similar), but really into mem, but
it is not recognized by oopDesc::is_oop(oop* p), this means, that I am
trying to access an object which has been garbage collected in the mean time
? Can Oops be _located_ within the stack (I dont assume so... its about the
second last OOP which is deemed not an OOP from is_oop, but not pointing to
zero)



Method signature: java.util.ResourceBundle.loadBundle
(Ljava/util/ResourceBundle$CacheKey;Ljava/util/List;Ljava/util/ResourceBundle$Control;Z)Ljava/util/ResourceBundle;
Figured out oldbcp (107) is at B1CD807B, newbcp (-1) is at B1CD8010
MAXLOCAL00 [AD6E7220]: ADB5B778
MAXLOCAL01 [AD6E721C]: 00000000
MAXLOCAL02 [AD6E7218]: 00000002
MAXLOCAL03 [AD6E7214]: 00000000
MAXLOCAL04 [AD6E7210]: B1CDD4D8
MAXLOCAL05 [AD6E720C]: ADB645B8
MAXLOCAL06 [AD6E7208]: B5BC9BB1
MAXLOCAL07 [AD6E7204]: AD6E7228
MAXLOCAL08 [AD6E7200]: AD6E7224
MAXLOCAL09 [AD6E71FC]: 00000000
MAXSTACK00 [AD6E71E0]: ADB61B40
MAXSTACK01 [AD6E71DC]: ADB645B8
MAXSTACK02 [AD6E71D8]: B5C7C227
MAXSTACK03 [AD6E71D4]: B5BC95AD
MAXSTACK04 [AD6E71D0]: AD6E7204
MAXSTACK05 [AD6E71CC]: AD6E71DC

oop map for {method} 'loadBundle'
'(Ljava/util/ResourceBundle$CacheKey;Ljava/util/List;Ljava/util/ResourceBundle$Control;Z)Ljava/util/ResourceBundle;'
in 'java/util/ResourceBundle' @ 107 = [10] { 0 1 2 4 5 8 9 }

Running closure...
OOP AT AD6E7030 PROPS: is_instance: true,   is_instanceRef: false,
is_array: false,  is_objArray: false,
NULL OOP AT AD6E721C (= POINTING TO 00000000) :
NULL OOP AT AD6E7218 (= POINTING TO 00000002) :
OOP AT AD6E7030 PROPS: is_instance: true,   is_instanceRef: false,
is_array: false,   is_objArray: false,
OOP AT AD6E7030 PROPS: is_instance: true,   is_instanceRef: false,
is_array: false,   is_objArray: false,
NULL OOP AT AD6E7200 (= POINTING TO AD6E7224) :
NULL OOP AT AD6E71FC (= POINTING TO 00000000) :


Second question: if no monitors are present, then the field atop of BCX
(absolute: below) points to itself, is that correct ? And if monitors are
present, how are they stored / accessed, in a low-level description ? When
looking at the layout in frame_i486.hpp and the operations defined in
frame.hpp, it doesnt look consistent to me


Regards, Peter




2007/12/4, Tom Rodriguez <Thomas.Rodriguez at sun.com>:
>
>
> > BTW, is there a method which verifies the oop in C as it is done in
> > verifyOop(Register) ?
>
> oopDesc::is_oop() will do tests similar to, but more powerful than, the
> verify_oop assembler macro.  Both of these can still be faked out in
> some rare cases but are very reliable in the debug and fastdebug VM.  We
> usually scrog the unused area of the heap which helps in detecting bad
> oops.
>
> tom
>
> >
> > #13 0x0644d708 in JVM_handle_linux_signal () at
> >
> /home/peterh/workspace/openjdk/hotspot/src/os_cpu/linux_i486/vm/os_linux_i486.cpp:461
> > #14 0x06447c8d in signalHandler (sig=11, info=0xad7259dc, uc=0xad725a5c)
> > at
> /home/peterh/workspace/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:3002
> > #15 <signal handler called>
> > #16 0x0611c292 in Klass::oop_is_instance () at
> > /home/peterh/workspace/openjdk/hotspot/src/share/vm/oops/klass.hpp:599
> > #17 0x0611c2ff in oopDesc::is_instance () at
> >
> /home/peterh/workspace/openjdk/hotspot/src/share/vm/oops/oop.inline.hpp:58
> > #18 0x064bbf60 in SpeculationReplaceClosure::do_oop () at
> >
> /home/peterh/workspace/openjdk/hotspot/src/share/vm/runtime/speculation.cpp:562
> >
> > #19 0x064c0f4a in MyInterpreterFrameClosure::offset_do () at
> >
> /home/peterh/workspace/openjdk/hotspot/src/share/vm/runtime/thread.hpp:1420
> > #20 0x0643ef77 in InterpreterOopMap::iterate_oop (this=0xad725e70,
> > oop_closure=0xad725e94)
> >     at
> >
> /home/peterh/workspace/openjdk/hotspot/src/share/vm/interpreter/oopMapCache.cpp:222
> > #21 0x064bc807 in Speculation::interpFrameAdaptSP (thread=0x8103c00,
> > rsp=0xad725f70, rbp=0xad725f9c, pc=0xb5b757ff "\213eøÇEø")
> >     at
> >
> /home/peterh/workspace/openjdk/hotspot/src/share/vm/runtime/speculation.cpp:806
> >
> >
> > caused by this code:
> >
> > void SpeculationReplaceClosure::do_oop(oop* p){
> >         #define PRINT_PROP(name) tty->print_cr("is_" #name
> > ":\t%s",(*p)->is_ ## name() ? "true" : "false")
> >         assert(!SafepointSynchronize::is_at_safepoint(), "invariant") ;
> >         if(p != NULL && (*p) != NULL){
> >         tty->print("SpecReplaceClosure: ref %08X:\n", p);
> >                 if((*p)->is_instance() ||
> >                    (*p)->is_instanceRef()  ||
> >                    (*p)->is_array() ||
> >                    (*p)->is_objArray()){
> >                         PRINT_PROP(instance);
> >                         PRINT_PROP(instanceRef);
> >                         PRINT_PROP(array);
> >                         PRINT_PROP(objArray);
> >                 }
> >                 else {
> >                         PRINT_PROP(klass);
> >                         PRINT_PROP(thread);
> >                         PRINT_PROP(method);
> >                         PRINT_PROP(constMethod);
> >                         PRINT_PROP(methodData);
> >                         PRINT_PROP(constantPool);
> >                         PRINT_PROP(typeArray);
> >                         PRINT_PROP(symbol);
> >                         PRINT_PROP(javaArray);
> >                         PRINT_PROP(compiledICHolder);
> >                 }
> >         } else {
> >                 tty->print("SpecReplaceClosure: INVALID OOP AT %08X
> > POINTING TO %08X :\n", p, *p);
> >         }
> >
> >
> >         #undef PRINT_PROP
> > }
> >
> >
> > Regards,
> > Peter
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20071205/a5842e9b/attachment.html