« Return to Thread: Add metadata to each field of an object?
Re: [rvm-research] Add metadata to each field of an object?
by Steve Blackburn
::
Rate this Message:
Hi Xinwei,
On 26/06/2009, at 3:06 PM, Xinwei Xie wrote:
> Does "shadow heap" mean that there is a shadow copy of each object
> maintained in a specific sanityTable?
"shadow heap" is an abstract idea.
The general idea is that somewhere, in the background, you maintain a
replica of the real heap, at some level of detail.
In the case of the sanity checker, it maintains a replica of the
object graph. Of course this can be expensive in both time and
space, but if the purpose is just debugging or analysis that's
probably fine.
In the case of Valgrind, you could literally have a shadow with a byte-
for-byte correspondence, just using a different part of the address
space. So for each byte in the heap there's a shadow byte. The
shadow byte could be used to store any kind of metadata. Then given
a heap object or field you can go and look up the metadata trivially
because you know the address it will be at. You can store whatever
you want in that metadata, though obviously with that approach you
would be limited by the size of the field; so a byte field could only
store one byte of metadata and an int field could only store four bytes.
The MMTk sanity checker does not use a direct mapping in virtual
memory (like I just described for Valgrind), but rather, it uses a
hash table (a large hash table! :-). You could do the same. Then
for any field of any object you can maintain the metadata for that
field in the huge hashmap. You can use "rawmemory" etc to get the
space for your hashmap without affecting the size of the application
heap (if that is important to you). Note that in MMTk we cannot use
new (since this is where new is implemented!), nor can we use the
standard collection classes, since they typically call new and other
things which are unsafe within a GC. So everything is done by
hand. It is not particularly hard to build a hash table from raw
memory. See the sanity checker code for ideas.
> I still can't get that where I am
> supposed to start with. For example, how can I map this pattern into
> rvm
> code?
What I meant when I said "map" and "pattern", was simply that you look
at those two examples, understand how they work, and then write
something new that suits your purposes, borrowing ideas from those
examples if you can. Exactly how you do it will depend on exactly
what it is you want to do. All I was doing was describing for you a
non-invasive way of associating metadata with fine grained information
such as object fields.
> Is it that I map each field into a table in a specific space
> preallocated in rvm and check each time of access from that table?
Perhaps. But this would depend entirely on what analysis you want to
do, and I'm not sure what that is. I'm just trying to provide you
with general ideas. The specific solution is up to you :-)
Cheers,
--Steve
>
> Regards,
> Xinwei
>
>
> Steve Blackburn wrote:
>>
>>
>> On 26/06/2009, at 11:33 AM, Eliot Moss wrote:
>>
>>> An alternative approach -- still not easy though -- would be to use
>>> a tool
>>> like valgrind. You'd have to notify it of object creations, etc., so
>>> it
>>> could keep shadow information. Again, probably a lot of work.
>>> Perhaps
>>> others can comment on the viability of that approach.
>>
>> I have done this kind of thing before. It is not particularly
>> difficult, though of course it requires you to become familiar with
>> valgrind (you could use PIN or any other such tool).
>>
>> Another alternative is to use a shadow heap within Jikes RVM (rather
>> than within another tool such as valgrind). This avoids the
>> unpleasantness of transmitting semantic information from the VM down
>> to the VMM (Valgrind). We already have something a little like this
>> in MMTk: the sanity checker (although the metadata there is at the
>> object granularity).
>>
>> Both approaches are what I call "shadow heaps" and they have the
>> distinct advantage of not relying on changing the object model etc.
>> They are more or less transparent to the system that uses them, which
>> can be a huge advantage.
>>
>> My recommendation would be that you take a peek at the source code
>> for
>> MMTk's sanity checker and the build something similar that operates
>> at
>> the field granularity. You'd probably build it in the main rvm code
>> base, not MMTk. The sanity checker is very robust and is a really
>> useful tool. I think you could build a very robust system by
>> following the same pattern.
>>
>> Cheers,
>>
>> --Steve
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Add-metadata-to-each-field-of-an-object--tp24213344p24215031.html
> Sent from the jikesrvm-researchers mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Jikesrvm-researchers mailing list
> Jikesrvm-researchers@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
------------------------------------------------------------------------------
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
On 26/06/2009, at 3:06 PM, Xinwei Xie wrote:
> Does "shadow heap" mean that there is a shadow copy of each object
> maintained in a specific sanityTable?
"shadow heap" is an abstract idea.
The general idea is that somewhere, in the background, you maintain a
replica of the real heap, at some level of detail.
In the case of the sanity checker, it maintains a replica of the
object graph. Of course this can be expensive in both time and
space, but if the purpose is just debugging or analysis that's
probably fine.
In the case of Valgrind, you could literally have a shadow with a byte-
for-byte correspondence, just using a different part of the address
space. So for each byte in the heap there's a shadow byte. The
shadow byte could be used to store any kind of metadata. Then given
a heap object or field you can go and look up the metadata trivially
because you know the address it will be at. You can store whatever
you want in that metadata, though obviously with that approach you
would be limited by the size of the field; so a byte field could only
store one byte of metadata and an int field could only store four bytes.
The MMTk sanity checker does not use a direct mapping in virtual
memory (like I just described for Valgrind), but rather, it uses a
hash table (a large hash table! :-). You could do the same. Then
for any field of any object you can maintain the metadata for that
field in the huge hashmap. You can use "rawmemory" etc to get the
space for your hashmap without affecting the size of the application
heap (if that is important to you). Note that in MMTk we cannot use
new (since this is where new is implemented!), nor can we use the
standard collection classes, since they typically call new and other
things which are unsafe within a GC. So everything is done by
hand. It is not particularly hard to build a hash table from raw
memory. See the sanity checker code for ideas.
> I still can't get that where I am
> supposed to start with. For example, how can I map this pattern into
> rvm
> code?
What I meant when I said "map" and "pattern", was simply that you look
at those two examples, understand how they work, and then write
something new that suits your purposes, borrowing ideas from those
examples if you can. Exactly how you do it will depend on exactly
what it is you want to do. All I was doing was describing for you a
non-invasive way of associating metadata with fine grained information
such as object fields.
> Is it that I map each field into a table in a specific space
> preallocated in rvm and check each time of access from that table?
Perhaps. But this would depend entirely on what analysis you want to
do, and I'm not sure what that is. I'm just trying to provide you
with general ideas. The specific solution is up to you :-)
Cheers,
--Steve
>
> Regards,
> Xinwei
>
>
> Steve Blackburn wrote:
>>
>>
>> On 26/06/2009, at 11:33 AM, Eliot Moss wrote:
>>
>>> An alternative approach -- still not easy though -- would be to use
>>> a tool
>>> like valgrind. You'd have to notify it of object creations, etc., so
>>> it
>>> could keep shadow information. Again, probably a lot of work.
>>> Perhaps
>>> others can comment on the viability of that approach.
>>
>> I have done this kind of thing before. It is not particularly
>> difficult, though of course it requires you to become familiar with
>> valgrind (you could use PIN or any other such tool).
>>
>> Another alternative is to use a shadow heap within Jikes RVM (rather
>> than within another tool such as valgrind). This avoids the
>> unpleasantness of transmitting semantic information from the VM down
>> to the VMM (Valgrind). We already have something a little like this
>> in MMTk: the sanity checker (although the metadata there is at the
>> object granularity).
>>
>> Both approaches are what I call "shadow heaps" and they have the
>> distinct advantage of not relying on changing the object model etc.
>> They are more or less transparent to the system that uses them, which
>> can be a huge advantage.
>>
>> My recommendation would be that you take a peek at the source code
>> for
>> MMTk's sanity checker and the build something similar that operates
>> at
>> the field granularity. You'd probably build it in the main rvm code
>> base, not MMTk. The sanity checker is very robust and is a really
>> useful tool. I think you could build a very robust system by
>> following the same pattern.
>>
>> Cheers,
>>
>> --Steve
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Add-metadata-to-each-field-of-an-object--tp24213344p24215031.html
> Sent from the jikesrvm-researchers mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Jikesrvm-researchers mailing list
> Jikesrvm-researchers@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
------------------------------------------------------------------------------
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
« Return to Thread: Add metadata to each field of an object?
| Free embeddable forum powered by Nabble | Forum Help |
