At 7:42 PM +0000 3/15/02, Nicholas Clark wrote:
>On Fri, Mar 15, 2002 at 12:58:19AM +0000, Alex Gough wrote:
>> On Fri, 15 Mar 2002, Tim Bunce wrote:
>> > 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.
>>
>> Are we allowing bytecode compiled under an earlier version to continue
>> working on a later version of the interpreter, as the answer to that
>> question pretty much limits where the line has to be drawn.
>
>I think you're talking byte code, and Tim's meaning source code.
>I think he's right; I would like to be able to write a perl6 script that
>says "don't make GC stall" and still have it work when I ran it on a perl6
>implementation with a different sort of GC.
>[and if that GC never stalled, or at least didn't have a choice of speed vs
>compactness, it would just politely ignore my request because it was
>irrelevant]
I think we've two things mingled here.
The disabling/enabling of garbage collection or dead object
detection, or explicit triggering of either, is one thing. The
"collect" opcode will always trigger a collection, and "sweep" will
always make a DOD sweep.
What I'm talking about was more at the level of fine control. When
we've run out of PMC headers in our arena, how many do we allocate in
the new arena? When we need more memory from the system how big a
chunk do we ask for? How many times do we allocate new arenas/memory
pools before we trigger off an automatic GC or DOD run? Things like
that.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
