[M3devel] Re: RTHooks CheckStoreTraced and CheckLoadTraced

[Tony Hosking]

On Apr 18, 2007, at 9:37 PM, Darko wrote:

> Not actually using that code, but I did see your helpful commit on  
> it some time ago. It seems that the problem I described earlier is  
> due to another bug. The code I'm working on does a lot of reading  
> and writing of traced references and I was hoping to get a better  
> understanding of situations I need to be aware of and how to use  
> those RTHooks calls more efficiently.

You SHOULD NOT need to use these calls so long as you are accessing  
using properly typed references (as in my example earlier).  This is  
not an issue for SAFE code, only in UNSAFE modules must you be  
careful how you use LOOPHOLE to cast references.

> So say I have two traced objects and I am copying a traced  
> reference from a field in one to the other. What set of calls would  
> be normally required there?

How are you copying the references?  I would like to see your code  
for this.  So long as you properly type things then the calls to  
RTHooks.CheckLoadTracedRef and RTHooks.CheckStoreTraced will be  
generated by the compiler.

Anyway...

RTHooks.CheckLoadTracedRef is generated by the compiler whenever you  
access a traced reference in memory (e.g., via dereference or from a  
shared variable).  Its job is to prevent mutators from acquiring  
references to "gray" objects (that are reachable but still to be  
scanned for the traced references that they contain).  The check  
turns the object from gray to black by scanning its references and  
making sure none of them refer to white objects (that are not known  
to be reachable by the collector).

RTHooks.CheckStoreTraced is generated by the compiler whenever a  
traced reference is stored (or might be stored, e.g., for VAR) into a  
traced object.  The check makes sure that the generational GC knows  
that the object has been modified.  It needs to know this for objects  
in the older genration.

Again, I reiterate that it is not my intention that programmers  
actually call these runtime hooks explicitly!  I am certain I can  
rewrite any code you might have so that you do not need to call them  
explicitly.  Instead, properly typed references will result in the  
checks being generated for you by the compiler.  Please feel free to  
send me code snippets for review.

> I'm sure you haven't got time to go into the minutiae of the  
> runtime system, but any hints would be appreciated.
>
> Cheers,
> Darko.
>
>
> On 18/04/2007, at 4:34 PM, Tony Hosking wrote:
>
>> I assume you have an apply method for your RTTypeMap.Visitor that  
>> takes "field: ADDRESS" and treats it as "REF REFANY".   This is  
>> wrong.  When reading a REF field you should use the following idiom:
>>
>> WITH ref = LOOPHOLE(field, UNTRACED REF REFANY) DO
>>   ... access field via ref^ ...
>> END;
>>
>> This will automatically insert a call to the appropriate runtime  
>> routines on accessing the reference field.
>>
>> There should be no need for you to call the runtime routines  
>> directly.
>>
>> On Apr 17, 2007, at 9:51 PM, Darko wrote:
>>
>>> Hi,
>>>
>>> Wondering if you can explain the use of these calls a little  
>>> more. I'm currently using type maps to read and write fields from  
>>> traced objects. Reading a traced reference from inside a traced  
>>> object into a local variable is not working as it should. Should  
>>> I use CheckLoadTraced and if so when and how? Looking at your  
>>> changes to RTTypeMap, writing references into objects means you  
>>> need to call CheckStoreTraced on the object written inside of,  
>>> before it is written?
>>>
>>> Cheers,
>>> Darko.
>>