Add metadata to each field of an object?

[Xinwei Xie]

Hi All,
Thanks for your attention.

I'd like to know whether I can add some extra customized structure into current object layout. As far as I know, MiscHeader provides an alternative way to accomplish this, however, it lacks of flexibility and can only add words in the object level. My point is I want to do some profiling to each field of an object, for example, I want to trace when and who did an operation (read/write) to a corresponding field and update it at each access operation site.
class TraceInfo{
        int tid;
        int when;
}
Where can I add this extra information to each field of an object? Can I just add an instance of this structure to the RVMField? Or an alternative way is to add it into TIB?
Will it break the current object layout? How to initialize it correctly?
Thanks very much.

Regards,
--
Xinwei XIE

[Eliot Moss]

Xinwei Xie wrote:

> Hi All,
> Thanks for your attention.
>
> I'd like to know whether I can add some extra customized structure into
> current object layout. As far as I know, MiscHeader provides an alternative
> way to accomplish this, however, it lacks of flexibility and can only add
> words in the object level. My point is I want to do some profiling to each
> field of an object, for example, I want to trace when and who did an
> operation (read/write) to a corresponding field and update it at each access
> operation site.
> class TraceInfo{
> int tid;
> int when;
> }
> Where can I add this extra information to each field of an object? Can I
> just add an instance of this structure to the RVMField? Or an alternative
> way is to add it into TIB?
> Will it break the current object layout? How to initialize it correctly?
> Thanks very much.

Xinwie -- Why not write this information to a log? Trying to inject it into
the object format is going to be a lot more work, I suspect. You'll have to
modify the object layout part of the compiler. And then there's dealing
with the objects that get passed via JNI, and system internal objects,
etc. It could get tricky. Not so pleasant for arrays either.

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.

Overall I think logging will be easiest. What do you hope to do with the
information? Generally, the more you tell us about your real objective,
the more helpful the discussion list can be to you ....

Best wishes -- Eliot Moss

------------------------------------------------------------------------------
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

[Steve Blackburn]

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

------------------------------------------------------------------------------
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

[Xinwei Xie]

Hi Eliot,
Thanks for your reply.

I suppose maybe offline analysis is another option to me, however, not so attractive as online one. Is there some offline profiling example I can follow in JikesRVM? My aim is to use track info data structure to analyze the current access thread that whether it violates happens-before relationship with the last accessed one.

Cheers,
Xinwei

Eliot Moss wrote:

Xinwei Xie wrote:
> Hi All,
> Thanks for your attention.
>
> I'd like to know whether I can add some extra customized structure into
> current object layout. As far as I know, MiscHeader provides an alternative
> way to accomplish this, however, it lacks of flexibility and can only add
> words in the object level. My point is I want to do some profiling to each
> field of an object, for example, I want to trace when and who did an
> operation (read/write) to a corresponding field and update it at each access
> operation site.
> class TraceInfo{
> int tid;
> int when;
> }
> Where can I add this extra information to each field of an object? Can I
> just add an instance of this structure to the RVMField? Or an alternative
> way is to add it into TIB?
> Will it break the current object layout? How to initialize it correctly?
> Thanks very much.

Xinwie -- Why not write this information to a log? Trying to inject it into
the object format is going to be a lot more work, I suspect. You'll have to
modify the object layout part of the compiler. And then there's dealing
with the objects that get passed via JNI, and system internal objects,
etc. It could get tricky. Not so pleasant for arrays either.

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.

Overall I think logging will be easiest. What do you hope to do with the
information? Generally, the more you tell us about your real objective,
the more helpful the discussion list can be to you ....

Best wishes -- Eliot Moss

[Xinwei Xie]

Hi Steve,
Thanks for your help.
Does "shadow heap" mean that there is a shadow copy of each object maintained in a specific sanityTable? I still can't get that where I am supposed to start with. For example, how can I map this pattern into rvm code? 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?

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

[Steve Blackburn]

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

[Eliot Moss]

Xinwei Xie wrote:
> Hi Eliot,
> Thanks for your reply.
>
> I suppose maybe offline analysis is another option to me, however, not so
> attractive as online one. Is there some offline profiling example I can
> follow in JikesRVM? My aim is to use track info data structure to analyze
> the current access thread that whether it violates happens-before
> relationship with the last accessed one.

Maybe Steve's suggestions will help. Of course, if you are interested in
race conditions between threads, just about *anything* you do will
greatly perturb the system and give results that can differ vastly from
an uninstrumented system .....

Best wishes -- Eliot

------------------------------------------------------------------------------
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

[Michael Bond]

Hi Xinwei,

The suggestions by Steve and Eliot sound good.  Another possibility is to
add a single word to each header, using MiscHeader, and make this word be
a pointer to an array where there is one element in the array per field in
the object.  You can initialize this array at object allocation time, or
you can just do it lazily in your read and write barriers, i.e., if the
header word is null, create a new array on the first access, and use a CAS
to initialize the word to avoid racing.  (The latter approach has worked
for me; it has space advantages if you don't end up needing the metadata
for many objects.  It can be problematic because creating a new array
might trigger a GC.  I avoided this by having a per-thread flag that gets
set during such allocations, and by having Plan.poll() check this flag and
defer GC if the flag is set.  There's a similar existing mechanism to
avoid GCs due to remembered set updates.)

A few tricky things: (1) It's important to modify GC tracing so it also
traces the header pointer :)  (2) If objects have differently sized
fields, it may be tricky to pick the array element that corresponds to a
field, but this can probably be figured out at compile time (when add read
and write barriers) by just counting the number of the field that's being
accessed by the read or write.  (In my case, I just needed one word per
word, which may be want you want for race detection?)

Hope that helps,
Mike

On Thu, 25 Jun 2009, Xinwei Xie wrote:

>
> Hi All,
> Thanks for your attention.
>
> I'd like to know whether I can add some extra customized structure into
> current object layout. As far as I know, MiscHeader provides an alternative
> way to accomplish this, however, it lacks of flexibility and can only add
> words in the object level. My point is I want to do some profiling to each
> field of an object, for example, I want to trace when and who did an
> operation (read/write) to a corresponding field and update it at each access
> operation site.
> class TraceInfo{
> int tid;
> int when;
> }
> Where can I add this extra information to each field of an object? Can I
> just add an instance of this structure to the RVMField? Or an alternative
> way is to add it into TIB?
> Will it break the current object layout? How to initialize it correctly?
> Thanks very much.
>
> Regards,
> --
> Xinwei XIE
> --
> View this message in context: http://www.nabble.com/Add-metadata-to-each-field-of-an-object--tp24213344p24213344.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

[Colin(Du Li)]

Hi, Michael,

    Which project did you use the MiscHeader? I would like to know more detail about the project.
    I also have two questions as follows.
    1. If we use MiscHeader to expand the object size, can GC automatically adapt to this changes, that is, can GC trace and collect objects using the new object size?
    2. Is that possible to expand header for part of objects (to save space), or all the objects should expand header?

    Thanks a lot!

    Du Li

Michael Bond wrote:

Hi Xinwei,

The suggestions by Steve and Eliot sound good.  Another possibility is to
add a single word to each header, using MiscHeader, and make this word be
a pointer to an array where there is one element in the array per field in
the object.  You can initialize this array at object allocation time, or
you can just do it lazily in your read and write barriers, i.e., if the
header word is null, create a new array on the first access, and use a CAS
to initialize the word to avoid racing.  (The latter approach has worked
for me; it has space advantages if you don't end up needing the metadata
for many objects.  It can be problematic because creating a new array
might trigger a GC.  I avoided this by having a per-thread flag that gets
set during such allocations, and by having Plan.poll() check this flag and
defer GC if the flag is set.  There's a similar existing mechanism to
avoid GCs due to remembered set updates.)

A few tricky things: (1) It's important to modify GC tracing so it also
traces the header pointer :)  (2) If objects have differently sized
fields, it may be tricky to pick the array element that corresponds to a
field, but this can probably be figured out at compile time (when add read
and write barriers) by just counting the number of the field that's being
accessed by the read or write.  (In my case, I just needed one word per
word, which may be want you want for race detection?)

Hope that helps,
Mike

On Thu, 25 Jun 2009, Xinwei Xie wrote:

>
> Hi All,
> Thanks for your attention.
>
> I'd like to know whether I can add some extra customized structure into
> current object layout. As far as I know, MiscHeader provides an alternative
> way to accomplish this, however, it lacks of flexibility and can only add
> words in the object level. My point is I want to do some profiling to each
> field of an object, for example, I want to trace when and who did an
> operation (read/write) to a corresponding field and update it at each access
> operation site.
> class TraceInfo{
> int tid;
> int when;
> }
> Where can I add this extra information to each field of an object? Can I
> just add an instance of this structure to the RVMField? Or an alternative
> way is to add it into TIB?
> Will it break the current object layout? How to initialize it correctly?
> Thanks very much.
>
> Regards,
> --
> Xinwei XIE
> --
> View this message in context: http://www.nabble.com/Add-metadata-to-each-field-of-an-object--tp24213344p24213344.html
> Sent from the jikesrvm-researchers mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Jikesrvm-researchers mailing list
> [e-mail]
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>

------------------------------------------------------------------------------
_______________________________________________
Jikesrvm-researchers mailing list
[e-mail]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

[Michael Bond]

On Fri, 11 Sep 2009, Colin(Du Li) wrote:

>    Which project did you use the MiscHeader? I would like to know more
> detail about the project.
>    I also have two questions as follows.
>    1. If we use MiscHeader to expand the object size, can GC automatically
> adapt to this changes, that is, can GC trace and collect objects using the
> new object size?

Hi Du Li,

I'm currently using MiscHeader for metadata for race detection, but I
don't think I've used it in any patches that are on the Research Archive.

Fortunately, GC and the rest of the VM will automatically use the new
object size if you add a word via MiscHeader.  You do need to modify the
GC if you want the header word traced as a reference.

>    2. Is that possible to expand header for part of objects (to save
> space), or all the objects should expand header?

Yeah, that's possible.  For example, Maria Jump added header words to a
dynamically chosen subset of objects for dynamic object sampling work from
ISMM 2004.  That's implemented in an older version of Jikes, though.
Does anyone know of or have a recent Jikes patch that does non-uniform
extra header words?

You might look at how Jikes does address-based hashing: for objects that
are copied after their Object.hashCode() method has been called, an extra
word is added to the object to store the old object address.  The extra
word is added either at the start or end of the object, depending on the
value of JavaHeaderConstants.DYNAMIC_HASH_OFFSET.

Mike

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers