[M3devel] gettimeofday called from CheckLoadTracedRef?

[Tony Hosking]

The syscall is on the slow path in the barrier, but still perhaps too  
frequent.  I will delete the accounting from the barrier (it's not  
really very useful there anyway).  I hope the result is a big speedup!

On 25 May 2009, at 04:15, Mika Nystrom wrote:

> It makes a syscall.  A slow one!
>
>    Mika
>
> Jay writes:
>>
>> It does appear to be making policy decisions based on elapsed time,  
>> not just collecting times to report.
>>
>> Does gettimeofday on your system make a syscall or read a global?
>>
>> - Jay
>>
>> Maybe since the intent is just to process one object/page, the  
>> CollectorOn/Off calls can be replaced by just
>> collectorOn := TRUE or FALSE
>>
>> ? For CollectorOff that isn't clear since it does more, but  
>> CollectorOn is just that plus time recording plus an assertion.  
>> Still, given that the intent is some limited processing, I think  
>> the time collection could be avoided and might not even be a good  
>> thing?
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> To: m3devel at elegosoft.com
>>> Date: Sat, 23 May 2009 13:34:16 -0700
>>> From: mika at async.caltech.edu
>>> CC: mika at camembert.async.caltech.edu
>>> Subject: [M3devel] gettimeofday called from CheckLoadTracedRef?
>>>
>>>
>>> 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 *)
>>> 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.