[M3devel] gettimeofday called from CheckLoadTracedRef?

[jay.krell at cornell.edu]

It looked to me it was not slow path but every run. Also always setjmp/ 
pushframe/popframe too. I need to understand libunwind -- it seems to  
promise pretty portable stack walking.

  - Jay (phone)

On May 24, 2009, at 4:13 PM, Tony Hosking <hosking at cs.purdue.edu> wrote:

> 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.
>
>