Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ a slightly modified version of this proposal made it into CVS in the
meantime ]
> At 10:54 AM +0200 8/24/04, Leopold Toetsch wrote:
>>
>> DOD_WRITE_BARRIER(interp, aggregate, old_item, new_item)
>>
>>For hash keys we might need either two such calls (the 2nd with keys) or
>>an extended form that both takes keys and PObj*.
> How 'bout instead we have:
> STORE_POINTER(interp, dest_pmc, address_to_write, value_to_write)
This should combine the barrier and the actual write?
>>[1] we might consider an explicit opcode C<unused {Px, Sx}> though,
>>which could be emitted for temporariers. I know that we had C<destroy>
>>some time ago (at that time I thought it would be unneeded ;) But it
>>could take pressure from the GC system.
> I'm all for putting destroy back in. It'll still be somewhat limited
> (the thing being destroyed can't go onto the free list until the DOD
> gets to it) but it'll be immediate and potentially gives the DOD
> fewer things to go trace.
It depends on the GC scheme: one implementing the strong tri-color
invariant can immediately set that to-be-destroyed object to white, when
it's gray. If it contains other white but reachable objects these must be
reachable by other paths.
A snapshot-at-beginning scheme (utilizing the weak tri-color invariant)
can't take advantage of the destroy opcode.
Should the opcode be really called C<destroy>, which would imply some
immediate destruction?
leo
