At 06:03 PM 11/4/2001 -0500, James Mastros wrote:
>On Sun, Nov 04, 2001 at 01:47:44PM -0500, Dan Sugalski wrote:
> > I've not made any promises as to what type of GC system we'll use. I'm
> > gearing things towards a copying collector, but I'm also trying to make
> > sure we don't lock ourselves out of a generational scheme.
>I'd really like to hear that you were planning on not locking us out of
>/any/ scheme. I'd like to see a lot of pluggablity here, so we can get
>custom solutions for those needing multiprocessor, huge memory optimized
>schemes, and with tiny machines with poor processors, or on a handheld with
>tiny memory. Hell, even segmented memory, if they're really brave.
I doubt there'll be GC pluggbility. (Unless you consider "Ripping out the
guts of resources.c and gc.c and replacing them" pluggability... :) If it
works out that way, great, but I don't know that it's really something I'm
shooting for.
> > I know things are a little fuzzy in the GC arena, but that's on purpose
> for
> > the moment.
>Hell. I've got very, very little knowlage about gc. But I'd love to see
>the GC pluggable to the point where different modules can have different
>GCs... but I don't think it's reasonably possible.
>
>Without doubt, there should be a way for parrot code to modify the
>properties of the GC, like the frequency of calling, and to specify "run the
>GC now".
That will be settable. I should go add the ops to the docs.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
