[M3commit] CVS Update: cm3

[Jay]

Um, I also realize now I've been confusing the thread libraries--I thought they all had "this problem" but it seems only user threads does.
The activations are untraced for pthreads and win32 threads.
 
 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Wed, 6 May 2009 07:34:09 +0000
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
>
>
> ps: I realize now my proposed fix is inadequate, duh.
>
> - Jay
>
>
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> CC: m3commit at elegosoft.com
>> Subject: RE: [M3commit] CVS Update: cm3
>> Date: Wed, 6 May 2009 07:33:24 +0000
>>
>>
>> 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.
>>>>>>>>
>>>>>>
>>>>>
>>>