[M3commit] CVS Update: cm3

[Jay]

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