[M3devel] gettimeofday called from CheckLoadTracedRef?

Tony Hosking hosking at cs.purdue.edu
Mon May 25 01:43:06 CEST 2009


On 24 May 2009, at 06:34, Mika Nystrom wrote:

>
> Hi Modula-3ers, especially Tony,
>
> I'm seeing the following behavior a lot in a program I'm running:
>
> #0  0x68ecbba7 in gettimeofday () from /lib/libc.so.5
> #1  0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16
> #2  0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code  
> 30 in symbol table.
> ) at ../src/runtime/common/RTCollector.m3:674
> #3  0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46  
> in symbol table.
> ) at ../src/runtime/common/RTCollector.m3:2271
> #4  0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table.
> )
>    at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/ 
> libm3/src/sortedtable/SortedTable.mg:145
>
> Is it normal for CheckLoadTracedRef to make system calls?
>
> Hmm, why is it even doing CheckLoadTracedRef?  Here's the code (from  
> SortedTable.mg):
>
>
> PROCEDURE Get (           tbl : Default;
>               READONLY   k   : Key.T;
>               VAR(*OUT*) v   : Value.T): BOOLEAN =
>  VAR
>    x   : Node := tbl.h.hi;
>    cmp : Cmp;
>  BEGIN
>    WHILE (x # NIL) DO
>      cmp := tbl.keyCompare (k, x.key);
>      IF cmp = 0 THEN  v := x.value;  RETURN TRUE; END;
>      IF (cmp < 0)
>        THEN x := x.lo; (* line 145 *)

This line is loading a reference from the lo field of the x record in  
the heap.  To enter the call to the CheckLoadTracedRef routine x must  
have been marked gray (which means that it might contain references to  
white objects in the heap).  In GC parlance, a gray object is one that  
the collector has not yet scanned to process its references (and copy  
their targets).  White objects are uncopied (unmarked) objects, and so  
candidates for freeing at the end of the GC cycle.  Because we cannot  
control what mutators do with white references (to white objects) --  
i.e., where they store them, etc. -- we make sure that the mutator can  
never get a hold of one.

>
>        ELSE x := x.hi;
>      END;
>    END;
>    RETURN FALSE;
>  END Get;
>
> where Node is defined as
>
> TYPE
>  Node = REF RECORD
>    key     : Key.T;
>    value   : Value.T;
>    lo      : Node := NIL;
>    hi      : Node := NIL;
>    priority: INTEGER    (* random num; tree is a heap on these *)
>  END;
>
> It seems odd to me that, under these circumstances, x := x.lo would
> cause any sort of checking activity...
>
> I'm using a CM3 that's about a month old, on FreeBSD4.
>
>     Mika
>
> P.S. Needless to say, the code in question runs about 10x faster under
> PM3 than with this relatively new CM3...  but my m3gdb is having  
> trouble
> with PM3's LONGREALs for some reason.




More information about the M3devel mailing list