[M3commit] CVS Update: cm3

[Tony Hosking]

On 29 Apr 2009, at 08:57, Jay wrote:

>
> This occurs before ThreadF.Init().
>  (err, not clear from below, but I think so).
> Would you rather that ThreadF.Init() do initialization on demand,
> as pthread and win32thread currently do,
> and PushEFrame forever have to check for that case and ThreadF.Init
> continue to avoid NEW(), as it currently does?
>
>
> It isn't great either way but I think this is the preferable path.
>
>
> Code has to be contorted to avoid circularities..
> try/raise/ depend on some initialization unfortunately.
>
>
> We'll trade contortions. Avoid try/raise/ in a few places,
> get back to not having on-demand initialization nor having to use
> calloc directly in place of NEW.
> PushEFrame will be slightly faster for all callers, not just during
> initialization. But just very slightly.

This sounds like the best plan, yes.  Any bootstrap code like this  
should probably avoid TRY/RAISE as much as possible.

>
>
> - Jay
>
>
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> To: jkrell at elego.de
>> Date: Wed, 29 Apr 2009 07:44:50 +1000
>> CC: m3commit at elegosoft.com
>> Subject: Re: [M3commit] CVS Update: cm3
>>
>> I don't care if there are extra instances of PushEFrame at startup.
>> Let's improve performance of steady-state rather than bootstrapping.
>>
>> On 28 Apr 2009, at 15:38, Jay Krell wrote:
>>
>>> CVSROOT: /usr/cvs
>>> Changes by: jkrell at birch. 09/04/28 15:38:44
>>>
>>> Modified files:
>>> cm3/m3-libs/m3core/src/runtime/common/: RTType.m3
>>>
>>> Log message:
>>> Remove at least one instance of PushEFrame from early  
>>> initialization.
>>> You know, maybe PushEFrame can avoid doing initialization on-demand
>>> and we can instead initialize things a little more deliberately
>>> in an order that works, maybe. Win32 and pthreads do in on-demand
>>> but user threads doesn't yet, maybe we can fix it and then optimize
>>> the others slightly.
>>>
>>> #0 0x08089490 in RTHooks__PushEFrame (M3_AJWxb1_frame=0xbfbfe9fc)
>>> at ../src/thread/POSIX/ThreadPosix.m3:1599
>>> #1 0x0807fe09 in RTType__Calloc (M3_AcxOUs_n=1024,
>>> M3_AcxOUs_n_bytes=4)
>>> at ../src/runtime/common/RTType.m3:815
>>> #2 0x0807f84d in RTType__Expand (M3_DaARCY_m=0x80b238c) at ../src/
>>> runtime/common/RTType.m3:724
>>> #3 0x0807f715 in RTType__FindSlot (M3_DaARCY_m=0x80b238c,
>>> M3_AcxOUs_key=-1025633461,
>>> M3_AJWxb1_aux=0x0) at ../src/runtime/common/RTType.m3:699
>>> #4 0x0807e2a1 in RTTypeSRC__AddTypecell (M3_Eic7CK_def=0x80ac9f4,
>>> M3_DjPxE3_m=0x80ac9c0)
>>> at ../src/runtime/common/RTType.m3:163
>>> #5 0x08077395 in RTLinker__DeclareModuleTypes
>>> (M3_DjPxE3_m=0x80ac9c0)
>>> at ../src/runtime/common/RTLinker.m3:280
>>> #6 0x08077115 in RTLinker__FixTypes () at ../src/runtime/common/
>>> RTLinker.m3:234
>>> #7 0x08076bee in RTLinker__AddUnitI (M3_DjPxE3_m=0x80b0020)
>>> at ../src/runtime/common/RTLinker.m3:112
>>> #8 0x08076c94 in RTLinker__AddUnit (M3_DjPxE5_b=0x8076820)
>>> at ../src/runtime/common/RTLinker.m3:122
>>> #9 0x0807690e in RTLinker__InitRuntime (M3_AcxOUs_p_argc=1,
>>> M3_AJWxb1_p_argv=0xbfbfec84,
>>> M3_AJWxb1_p_envp=0xbfbfec8c, M3_AJWxb1_p_instance=0x0) at ../src/
>>> runtime/common/RTLinker.m3:42
>>> #10 0x0804ae60 in main (argc=1, argv=0xbfbfec84, envp=0xbfbfec8c)
>>> at _m3main.mc:3
>>