JFYI The current GC-finalization Subsystem interface and intercommoning communication described in DevGuide. And now there are two finalization implementation: multithreading one based on java thread and the other new (created for GC5), based on 1 native thread.
On usual, multithreading implementation 1 "permanent" thread with normal priority is created and this is enough. In heavy workloads additional treads are created, but not many. For example not more 4 under DeCapo on my machine. And it's pretty good on HT P4. Only in very stress situation more threads are created. Also I know (by experiments) that 1 finalizer thread with any priority on multi core machine is not enough. Thanks Pavel Afremov. On 12/28/06, Rana Dasgupta <[EMAIL PROTECTED]> 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. All that has happened is that working on GCV5 has caused the current finalizer design/implementation to be reviewed. 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 > > > >
