On Thu, Mar 14, 2002 at 03:19:43PM -0500, Dan Sugalski wrote: > At 8:08 PM +0000 3/14/02, Nicholas Clark wrote: > >On Thu, Mar 14, 2002 at 06:17:01PM +0000, Piers Cawley wrote: > >> Dan Sugalski <[EMAIL PROTECTED]> writes: > > > >> > OTOH, exposing the controls for twidding does mean that we probably > >> > won't ever be able to unexpose them, which limits our potential > >> > flexibility in the future. > >> > > >> > Opinions, folks? > > > >> My gut feeling is that we should make them available, but fenced about > >> with caveats about the interface being subject to radical change if we > >> find a better GC mechanism, or even if you find yourself running in a > >> different environment. And if you're at the point where you're > >> tweaking the GC controls you're probably going to 're tweak' them when > >> you upgrade parrot too, and if the interface has changed, well, you > >> suck it up and get on with the job. > > > >I think Piers said here pretty much what I was thinking. If we expose > >the controls without some sort of "Under Construction" sign then it > >would preclude us from ever using a fundamentally different garbage > >collector later on, as it wouldn't have the same sort of controls that > >parrot had committed to providing. > > > >Hence I think I'd like GC controls exposed, but with this sort of warning on > >them. > > You and Piers have me convinced. I'll add access to them, and we'll > cover the things with danger signs.
Might be good to also provide "higher level" controls that just provide hints to the GC. Somewhat like the "use less qw(memory);" pragma that never quite happened for perl5, but with more appropriate attribute for GC in perl6. For example, an application might want to hint that it wouldn't like GC to cause a stall. Those kinds of GC hints shouldn't break across upgrades. Tim.
