[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-hotspot-runtime-dev
Subject: Using InterpreterOopMap
From: peter.helfer.java () gmail ! com (Peter Helfer)
Date: 2007-12-10 17:24:27
Message-ID: ee73e03b0712100924h5cf94973y1033600a1db80244 () mail ! gmail ! com
[Download RAW message or body]
I do know, its not nice to repost, but anyway - I'm still seeing strange
Oops, I just want to be sure, that its really me who is doing nasty stuff
(copying frames around) has really done wrong:
a) if an Oop is not pointing to 0x0000 (or 0x0002 or similar), then this
location is valid, as long as I am not referring to the same location across
a safepoint.
Method signature: java.util.Collections$EmptyList
.<init>(Ljava/util/Collections$1;)V
Figured out oldbcp (1) is at B1D48B31, newbcp (-1) is at B1D48B30
MAXLOCAL00 [AD6F72A0]: B5C245AD
MAXLOCAL01 [AD6F729C]: AD6F72A8
MAXSTACK00 [AD6F7278]: ADBC1AA8
oopMap=oop map for {method} '<init>' '(Ljava/util/Collections$1;)V' in
'java/util/Collections$EmptyList' @ 1 = [2] { 0 1 }
Running closure
oop::is_oop - BAD NULL OOP AT AD6F72A0 (= POINTING TO B5C245AD)
os::address_is_in_vm(B5C245AD): false
thread::is_in_stack (B5C245AD): false
heap::is_in (B5C245AD): false
heap::in_closed_subs(B5C245AD): false
heap::is_permanent (B5C245AD): false
thread ptr & 0xFFFF0000 : false
oop::is_oop - BAD NULL OOP AT AD6F729C (= POINTING TO AD6F72A8)
os::address_is_in_vm(AD6F72A8): false
thread::is_in_stack (AD6F72A8): true
heap::is_in (AD6F72A8): false
heap::in_closed_subs(AD6F72A8): false
heap::is_permanent (AD6F72A8): false
thread ptr & 0xFFFF0000 : false
b) if no Java 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 & sorry for repost..
Peter
2007/12/5, Peter Helfer <peter.helfer.java at gmail.com>:
>
> 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/20071210/844511bc/attachment.html \
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic