[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