[M3devel] gettimeofday called from CheckLoadTracedRef?

[Tony Hosking]

There is an inline fast path inserted by the compiler that checks the  
grayness of the object being loaded from.  The call to  
CheckLoadTracedRef should *not* occur on every pointer load from the  
heap, only on those from gray objects. The TRY block is necessary for  
now because the cleaner might throw and exception.  This is an area I  
am going to revisit soon, so hopefully we can dispense with it.

On 25 May 2009, at 15:39, jay.krell at cornell.edu wrote:

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