At 9:48 PM +0100 8/12/02, Nicholas Clark wrote:
>On Mon, Aug 12, 2002 at 04:04:40PM -0400, Jason Gloudon wrote:
>> On Mon, Aug 12, 2002 at 03:56:27AM -0400, Mike Lambert wrote:
>>
>> Here is a workaround for one hash related GC bug.
> ^^^^^^^^^^
>
>> + volatile Buffer *for_gc;
>> /* hash->buffer.flags |= BUFFER_report_FLAG; */
>>
>> /* We rely on the fact that expand_hash() will be called before
>> @@ -295,7 +296,12 @@
>> hash->max_chain = (HashIndex) -1;
>>
>> hash->entries = 0;
>> - hash->bucket_pool = new_buffer_header(interpreter);
>> +
>> + /* In order to keep the bucket_pool header from being
>> + * collected from expand_hash(), a pointer to it is put on
>> + * the system stack where the stack walking code can find it */
>> + for_gc = hash->bucket_pool = new_buffer_header(interpreter);
>> +
>
>This is a case of a temporary allocated value being only in a CPU register?
>If so, I believe that this is no solution of the cause, merely working round
>a symptom. The stack walking code needs custom assembler to find all values in
>the CPU registers that may not be on the stack.
It may also be the case where the values are on the stack, but at a
spot where the GC won't look, as they're allocated in the code that's
calling into the interpreter and not rooted. Which means we *must*
root the argv PMCs quickly.
>If I've misunderstood the cause of the above problem, oops, sorry.
>But I believe that we still need to check for pointers in the CPU registers,
>because on a register rich CPU is is not impossible that something has the
>only pointer to an in use value still only in a CPU register.
Yup. We have to do this, so we might as well go for it now.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
