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