[M3commit] CVS Update: cm3

[Jay]

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.

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