[M3commit] CVS Update: cm3

[Tony Hosking]

I think I have a cleaner solution, which involves disabling GC until  
after thread initialization has taken place.  That way, allocation can  
work so long as it avoids TRY blocks.

On 6 May 2009, at 17:33, Jay wrote:

>
> Please give me a few hours on this.
>
>
> It can be fixed by moving the first activation back to "special"  
> allocation, either calloc or taking the address of the first element  
> of a char array.
>
>
> Fragility can be reduced by moving ThreadF.Init or at least part of  
> it earlier, to before the heap is initialized (I have to read the  
> rest of it, maybe split it in two; maybe make InitActivations the  
> public name of the first half, called by RTLinker, that should work  
> easily.)
>
>
> Functions with TRY or LOCK are admittedly already inefficient.
> I guess an extra instruction or two in them doesn't matter?
>
> (You think libunwind (as integrated into gcc/libgcc) is viable as  
> fairly portable stack walker? That makes this all so much nicer.)
>
>
> I'm conflicted.
> You know the explicit initialization order I mentioned in RTLinker?
> We agree it is fragile.
> Aren't we just seeing another form/part of that?
> Albeit maybe a surprising form? SUrprising that a language construct  
> (TRY) incurs a runtime dependency? You know, those modules that are  
> manually initialized, their initializers presumably can't call  
> anything initialized after them. One must be careful what those  
> modules call. One must be careful that those modules don't TRY  
> before TRY is initialized.
>
>
> "TRY is a module", something like that.
>
>
> Anyway let me look at it.
> I think we merely have to move InitActivations early and have it use  
> a static allocation and it will be fairly reasonable.
>
>
>
> - Jay
>
>
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> To: jay.krell at cornell.edu
>> Date: Wed, 6 May 2009 17:13:05 +1000
>> CC: m3commit at elegosoft.com
>> Subject: Re: [M3commit] CVS Update: cm3
>>
>> Jay,
>>
>> The fix you have put in to avoid the NIL-check in GetActivations/
>> SetActivations is hard to get rid of because we need to be able to  
>> ask
>> for an activation so early in the bootstrap process (e.g., for any  
>> TRY
>> block that happens to get called before we initialize the threads).
>> It seems pretty unreasonable not to have TRY blocks in the bootstrap
>> initialization. Or have you managed to eliminate them. The one place
>> remaining is to protect when CollectSome throws an OutOfMemory  
>> runtime-
>> error back to the slow allocation path -- this TRY block will be
>> executed on every allocation by the bootstrap initializers. I also
>> rely on GetActivation calling InitActivations on demand for that  
>> first
>> allocation. It seems hard to impose no NEW in bootstrap code up to
>> that point. So, upshot is that I would like to restore the on-demand
>> invocation of InitActivations at the cost of a NIL-check in the
>> GetActivation code. I think not doing so results in much more fragile
>> code. What do you think?
>>
>> -- Tony
>>
>> On 6 May 2009, at 10:39, Jay wrote:
>>
>>>
>>> Yes I definitely think so.
>>> That is most of the problem in "all of this" -- why user threads
>>> were failing on non-Linux platforms (without on-demand
>>> initialization), and why merging the thread locals caused "wierd"
>>> allocation to be used.
>>>
>>>
>>> I believe the way it works, is that any /function/ with a TRY or a
>>> RAISE or a FATAL pragma (GetGCRatio), no matter "how close in the
>>> function you get to the TRY/RAISE", incurs a PushEFrame.
>>>
>>>
>>> I like my proposed fix but I'll sit tight.
>>> It's a known somewhat ugly mechanical transform to push try/raise
>>> into separate functions.
>>>
>>>
>>> There is of course definitely the fragility that early allocations
>>> "must" succeed, else going down the slow path will fail. Perhaps
>>> that should be strengthened, perhaps.
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Wed, 6 May 2009 10:33:00 +1000
>>>> CC: m3commit at elegosoft.com; jay.krell at cornell.edu
>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>
>>>> PS I know how to fix it now, so just hold tight. It means burying
>>>> the TRY block lower down inside CollectEnough.
>>>>
>>>> On 6 May 2009, at 10:31, Tony Hosking wrote:
>>>>
>>>>> Do you mean we get PushEFrame outside the IF?
>>>>>
>>>>> On 6 May 2009, at 10:28, Jay wrote:
>>>>>
>>>>>>
>>>>>> I think this requires moving that path to a separate function,  
>>>>>> else
>>>>>> we'll die in startup (PushEFrame called before ThreadF.Init).
>>>>>>
>>>>>>
>>>>>> Like I had here:
>>>>>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/runtime/common/RTCollector.m3.diff?r1=1.52;r2=1.53
>>>>>>
>>>>>>
>>>>>> but I undid that since the next change subsumed it (though
>>>>>> incorrectly as you point out).
>>>>>>
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> Date: Wed, 6 May 2009 02:21:50 +0000
>>>>>>> To: m3commit at elegosoft.com
>>>>>>> From: hosking at elego.de
>>>>>>> Subject: [M3commit] CVS Update: cm3
>>>>>>>
>>>>>>> CVSROOT: /usr/cvs
>>>>>>> Changes by: hosking at birch. 09/05/06 02:21:50
>>>>>>>
>>>>>>> Modified files:
>>>>>>> cm3/m3-libs/m3core/src/runtime/common/: RTCollector.m3
>>>>>>>
>>>>>>> Log message:
>>>>>>> We must have a TRY block around CollectEnough in AllocTraced,
>>>>>>> because it can
>>>>>>> raise an OutOfMemory error.
>>>>>>>
>>>>>
>>>>
>>