[M3commit] CVS Update: cm3

[Jay]

[oops, addressing a larger point that maybe wasn't made]
 

I think getting the TRY out of fast paths is good even for after initialization.
Getting TRY out of even the slow paths is "needed" for initialization to not
crash, unless you contort other code, **for some subjective definition of contortion**.
 

If you leave try in the slow allocation path, then ThreadF.Init cannot use NEW
and/or PushEFrame has to do on-demand initialization -- like how pthread and
win32thread are now, but weren't for a long time and how userthread isn't.
 

With the RTCollector.m3 changes, ThreadPthread.m3 and ThreadWin32.m3 should
be able to go back to their historical arguably nicer slightly more efficient form,
where GetActivation does not initialize and where initialize uses regular NEW.
 

It is a tradeoff either way.

 
Another idea that I considered is to initialize the allocator a little "better"
such that the first allocation goes down a fast path. But I couldn't come
up with a nice way to do that.
 

Surely we agree getting TRY out of the fast path is reasonable?
 

I also considered reordering RTLinker.m3 or breaking up pieces but avoided those.
 
 
Avoiding TRY/RAISE/ is a bit contorted but to some extent unavoidable
since they rely on initialization.
__thread might help here too but I doubt we'll ever rely on that completely.

 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> To: jkrell at elego.de
> Date: Wed, 29 Apr 2009 07:45:51 +1000
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
>
> Huh? Don't let dubious premature optimizations distort the code
> base....
>
> On 28 Apr 2009, at 16:20, Jay Krell wrote:
>
>> CVSROOT: /usr/cvs
>> Changes by: jkrell at birch. 09/04/28 16:20:44
>>
>> Modified files:
>> cm3/m3-libs/m3core/src/runtime/common/: RTCollector.m3
>>
>> Log message:
>> module initializer is too late also, remove GetGCRatio for now
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0x28201100 (LWP 100094)]
>> 0x08089580 in RTHooks__PushEFrame (M3_AJWxb1_frame=0xbfbfeb80)
>> at ../src/thread/POSIX/ThreadPosix.m3:1599
>> 1599 f.next := self.context.handlers;
>> (gdb) bt
>> #0 0x08089580 in RTHooks__PushEFrame (M3_AJWxb1_frame=0xbfbfeb80)
>> at ../src/thread/POSIX/ThreadPosix.m3:1599
>> #1 0x08075819 in RTCollector__GetGCRatio () at ../src/runtime/
>> common/RTCollector.m3:2801
>> #2 0x08075f2e in RTCollector_M3 (M3_AcxOUs_mode=1) at ../src/
>> runtime/common/RTCollector.m3:2883
>> #3 0x08077928 in RTLinker__RunMainBody (M3_DjPxE3_m=0x80b0020)
>> at ../src/runtime/common/RTLinker.m3:399
>> #4 0x08076ce2 in RTLinker__AddUnitI (M3_DjPxE3_m=0x80b0020)
>> at ../src/runtime/common/RTLinker.m3:113
>> #5 0x08076d70 in RTLinker__AddUnit (M3_DjPxE5_b=0x80768fc)
>> at ../src/runtime/common/RTLinker.m3:122
>> #6 0x080769ea in RTLinker__InitRuntime (M3_AcxOUs_p_argc=1,
>> M3_AJWxb1_p_argv=0xbfbfecec,
>> M3_AJWxb1_p_envp=0xbfbfecf4, M3_AJWxb1_p_instance=0x0) at ../src/
>> runtime/common/RTLinker.m3:42
>> #7 0x0804af30 in main (argc=1, argv=0xbfbfecec, envp=0xbfbfecf4)
>> at _m3main.mc:3
>> (gdb)
>