On Dec 28, 2006, at 1:54 PM, Rana Dasgupta wrote:
GCV5 does not need a custom finalizer. That is what would impact
modularity.
In fact, even that would not, if the interface were standardised.
However, one would prefer GC's not to provide their own
implementations for
the interface since they are not fully aware of system load, and
the GC dll
can be unloaded in somewhat dynamic environments.
Exactly.
All that has happened is that working on GCV5 has caused the current
finalizer design/implementation to be reviewed.
I see. I was confused by the following from Xiao-Feng, which made me
think that the GVv5 had it's own finalizer subsystem.
On Dec 28, 2006, at 9:33 AM, Xiao-Feng Li wrote:
Very interesting. Thanks for the probation. I think GCv5 finalization
subsystem does similarly.
On 12/28/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Dec 28, 2006, at 11:33 AM, Rana Dasgupta wrote:
> On 12/28/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> >Well, we need a finalizer. I agree that we're overthinking
this a
>> >bit, but I'd like to understand why anyone thinks this belongs in
>> the
>> >GC - we keep claiming to do a modular VM, yet then do things like
>> >this... :)
>
>
> We can keep the minimal finalization implementation we have now ( a
> single
> high priority finalization thread ), and wait for use cases that
> need more.
> IMHO.
>
> The finalization subsystem is currently a VM component and the VM
> exposes
> the interface ( though minimal ) to the GC. This is the right way,
> and does
> not violate modularity or GC pluggability.
So I don't understand what we are discussing - you seem to agree with
me that it belongs in the VM, and not the GC.
This little discussion started because I was asking Xiaofeng why GCv5
had it's own finalization subsystem...
geir
