[M3commit] CVS Update: cm3

[Tony Hosking]

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