[M3commit] CVS Update: cm3

[Tony Hosking]

Yeah, I think it definitely makes sense to keep TRY out of the fast  
allocation path, and perhaps best also out of the slow path too.

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

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