incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bobrovsky, Konstantin S" <konstantin.s.bobrov...@intel.com>
Subject RE: Conference call
Date Thu, 30 Apr 2009 08:25:06 GMT
Hello Stuart,

> Is it true to say that a reference, implementation wise, could always be 
> reported as a pointer?

Just in case: I assume a "reference" is always an address of a location in memory where an
entity uniquely identifying a Java object (usually its address on heap) resides. With this
assumption - yes (to the best of my knowledge).

Important side note (does not directly relate to the derived pointer discussion): object addresses
stored in fields, arrays of reference types, etc. may be "compressed" in real 64-bit VMs (I
know this is true for Hotspot, JRockit). That means that to get real object's address on heap
from its compressed representation one has to "decode" it. (In Hotspot this is real_addr =
heap_base + compressed_addr * 8). Not sure if this can affect the API. Probably not, as JavaReference
can abstract away "compressed-ness" of the target object. But I just wanted to bring this
up in case you would guess other places in the API where changes could be desired.

> Would that satisfy your requirement for direct pointer? 

I think yes, pretty much. Just few notes:

(1) Can getReferenceType() return something like REFERENCE_DERIVED (or REFERENCE_DIRECT in
your terms) so that it is easily distinguishable via an integer comparison rather than via
String.equals()?

(2) If an array element is of a reference type, how do we get the Java object the element
contains? getTarget()'s semantics is already occupied to return the base. Maybe the base could
be returned through getSource(), and getTarget() would obey current contract to return referenced
object (or additionally throw an exception if the element type is not a reference Java type)?

(3) [Small terminology question] I never heard "direct pointer" term to be used to describe
a derived pointer. The only terms I heard were "derived" or "interior" (meaning the pointer
points to an interior part of some Java object). But if you think "direct" is better - that's
OK.

> Would it make sense in other situations too?

Do you mean in situations involving derived pointers other than "array element pointer - array
base"? Yes, it would. The other situations which I can think of are "instance field pointer
- enclosing Java object", " static field pointer - enclosing Java class object", "class or
vtable pointer in a Java object header - the class or vtable object"

Thanks,
Konst


-----Original Message-----
From: Stuart Monteith [mailto:stukato@stoo.me.uk] 
Sent: Wednesday, April 29, 2009 7:40 PM
To: kato-spec@incubator.apache.org
Subject: Re: Conference call

Hello Konstantin,
    I understand what you mean. The API could report that there was a 
reference to the array, but nothing about where it the array it was 
referencing, like so:

JavaReference:
    getDescription() - "Direct reference".
    getReferenceType() - REFERENCE_UNKNOWN
    getRootType() - HEAP_ROOT_THREAD
    getSource() - null
    getTarget() - reference to the JavaObject representing the array
   
The API doesn't report anything more specific than the existence of the 
reference, its type and its destination.. The description string could 
have anything put into it, but I would expect the string contents to be 
constant.

Is it true to say that a reference, implementation wise, could always be 
reported as a pointer?

Expanding the above scenario:

JavaReference:
    getDescription() - "Direct reference".
    getReferenceType() - REFERENCE_UNKNOWN
    getRootType() - HEAP_ROOT_THREAD
    getSource() - null
    getTarget() - reference to the JavaObject representing the array
    getPointer() - actual reference value.

Such that normally ((JavaObject)JavaReference.getTarget()).getID() would 
be the base pointer and this would be equal to 
JavaReference.getPointer(). But for direct references getTarget() would 
report the JavaObject for the array, which would be the base, but 
getPointer() would return a pointer within that JavaObject array.

Would that satisfy your requirement for direct pointer? Would it make 
sense in other situations too?

Regards,
    Stuart


Bobrovsky, Konstantin S wrote:
>> - I will provide more explanations about my comment on derived pointer
>> support early next week.
>>     
>
> First, let me describe what I mean by "derived pointer" (might be well-known term to
those who worked with the Hotspot JVM)
> This is a pointer which is logically bound to some "base" java object. For example, pointer
to a memory location holding an array element (regardless of the element type) is a derived
pointer, and the array object itself is the base object. Derived pointers are "produced" by
JIT-ed code (e.g. to quickly access array elements, current element's address might be kept
in a register), and during GC their value must be updated whenever the GC moves the base object
(basically, derived pointer value should change by the same number the address of the base
object changes). To support that, derived pointer is reported to GC as "live" always together
with its base (whose live range is sometimes artificially stretched to match one of the derived
pointer). At least two VMs I worked with employ this concept: Hotspot and Harmony.
>
> My comment was whether it is possible to find/identify live derived pointers + bases
through a JavaStackFrame instance. It might be interesting for an engineer analyzing a post-mortem
dump to learn where the derived pointers and their bases are for the same reasons as it might
be interesting for him to find "usual" heap roots.
>
>
> Hope this helps,
> Konst
>  
> Intel Novosibirsk
> Closed Joint Stock Company Intel A/O
> Registered legal address: Krylatsky Hills Business Park, 
> 17 Krylatskaya Str., Bldg 4, Moscow 121614, 
> Russian Federation
>  
>
> -----Original Message-----
> From: Bobrovsky, Konstantin S 
> Sent: Friday, April 24, 2009 11:13 PM
> To: 'kato-spec@incubator.apache.org'; kato-dev@incubator.apache.org
> Subject: RE: Conference call
>
> Hello all,
>
> Quick follow up to the meeting:
> - JavaMethod
> In many VMs each method may have multiple compiled versions (even co-existing at the
same time). I think the API should provide access to all of them. Will client be able to access
all of them via getCompiledSections()?
>
> - ImageStackFrame
> It would be good if the API would support architectures with additional register stack
(such as Itanium). E.g. through an additional pointer to the base of the register stack frame.
>
> - I will provide more explanations about my comment on derived pointer support early
next week.
>
> Thanks,
> Konst
>  
> Intel Novosibirsk
> Closed Joint Stock Company Intel A/O
> Registered legal address: Krylatsky Hills Business Park, 
> 17 Krylatskaya Str., Bldg 4, Moscow 121614, 
> Russian Federation
>  
>
> -----Original Message-----
> From: Stuart Monteith [mailto:stukato@stoo.me.uk] 
> Sent: Friday, April 24, 2009 8:32 PM
> To: kato-dev@incubator.apache.org; kato-spec@incubator.apache.org
> Subject: Conference call
>
> Hello all,
>     I have posted the presentation that we will be going through on the 
> Kato Wiki.
> You can link to it here: 
> http://cwiki.apache.org/confluence/display/KATO/API+Walkthrough
> The recording will be made available in the same place, at the very 
> least the transcription and notes will be there.
>
> If you are unable to join the meeting on Sametime Unyte here: 
> https://www.webdialogs.com/join/ you will should be able to go through 
> the presentation from the wiki.
>
> Speak to you at 1500.
>
>     Stuart
>
>
>   

Mime
View raw message