Re: [Squeak-VMdev] Versiojn 4 changes

[John M M. <jo...@sm...>]

Well we only trigger a GC because of allocation count, or some other  
condition, or if in fact we've run out of memory.
Certainly I think you could change that to allow growth of the image if  
the VM support it, but not to trigger GC activity.
If growth fails and we can't find the memory then exit to shell I'd  
guess. I seem to recall we aren't very good at post checking object  
allocation in primitives and handing failure cases so failure (write  
the stack to stdout) is ok.

Could then get rid of the remapping logic I'd guess that handles the  
current messy details of oops moving during allocation in prim.

On Apr 7, 2004, at 6:46 PM, Andreas Raab wrote:

> Which reminds about something totally unrelated but potentially  
> *hugely*
> helpful:
>
> How about if we disable GC in primitives?
>
> This idea came back recently when we were talking about chasing GC
> problems - I don't even want to know how many places we have that  
> aren't GC
> safe. And I wonder if it's even worthwhile to do this in primitives.  
> If it
> is, we could still have a flag that basically "turns GC back on" (and  
> this
> could be the default for quick-indexed primitives). Or maybe we just  
> turn it
> off for any kind of named primitives.
>
> Thoughts?
>
>   - Andreas
>
> ----- Original Message -----
> From: "Ian Piumarta" <ian...@in...>
> To: "Andreas Raab" <and...@gm...>
> Cc: <squ...@li...>
> Sent: Thursday, April 08, 2004 3:02 AM
> Subject: Re: [Squeak-VMdev] Versiojn 4 changes
>
>
>> On 08 Apr 2004, at 02:39, Andreas Raab wrote:
>>
>>> Which reminds of something else we were talking about in the past:
>>> Passing
>>> primitive arguments as C arguments instead of the Smalltalk stack.
>>
>> Which reminds me of something else Dan & I talked about in the past:
>> evaluating arguments from right to left.  Saves an awful lot of  
>> tedious
>> peeking into the middle of the stack to pick up the receiver.
>> (Combined with the above, potentially wins Really Big for 386 too.
>> OTOH, the tradeoffs for register architectures are a little more
>> complex.)
>>
>> Cheers,
>> Ian
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Squeak-VMdev mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squeak-vmdev
>
>
--
======================================================================== 
===
John M. McIntosh <jo...@sm...> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===