Re: [Squeak-VMdev] Versiojn 4 changes

[Andreas R. <and...@gm...>]

John,

Yup, that's pretty much what I had in mind, e.g.,

* when we go into a primitive we set a disableGC flag
* if there is allocation we fall through in sufficientSpaceToAllocate:
  (possibly growing mem if needed but not GCing)
* upon primitive return we do the allocation check and GC if necessary

That's all. We would effectively continue to run everything else as it is
today, and the red zone we have for signaling low-space as well as the
ability to grow/shrink will be able to deal with the remaining situations.
Effectively, all we need to do is to make sure we have "enough headroom for
the primitive", and I would be surprised if we *ever* had more than 1k
allocation per primitive except in #new: - and those primitives might be
marked "gc-safe" to begin with (e.g., resetting the disableGC flag and
dealing with remapping). This would add an extra check at the end of
primitive returns but to me, this is acceptable if I consider all the
potential and yet undiscovered GC hazards we potentially have right now. And
heck, we might be able to hack this right away... really there is no need to
wait for V4 to get this going.

And yes, the point would be to get away from the messy remappings - I was
recently reviewing some primitive code and not surprisingly I found three
potential GC problems in the one method I was looking at. I think GC
problems is the single biggest issue we have for writing prims, followed by
argument passing and stack imbalance.

Cheers,
  - Andreas

----- Original Message ----- 
From: "John M McIntosh" <jo...@sm...>
To: <squ...@li...>
Sent: Thursday, April 08, 2004 6:25 AM
Subject: Re: [Squeak-VMdev] Versiojn 4 changes


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