Proposal: ClassInfo hasFinalizer field

Steven Schveighoffer schveiguy at yahoo.com
Mon Jun 6 07:01:17 PDT 2011


On Sun, 05 Jun 2011 00:28:58 -0400, dsimcha <dsimcha at yahoo.com> wrote:

> On 6/4/2011 11:45 PM, Walter Bright wrote:
>>
>> One issue is that if someone derives from a class and adds a finalizer.
>
> One issue I did forget, though, is that these "empty" finalizers do  
> deallocate the object's monitor.  (For those not familiar with these  
> details, D classes contain a hidden monitor field that is null  
> initially.  When you do synchronized(someClass), the monitor is lazily  
> initialized.)  I guess we could get around this by setting the finalize  
> bit in the monitor initialization code rather than upfront, for classes  
> that don't do any other finalization.  This would almost always be more  
> efficient than the status quo since very few classes use monitors.

What about this idea:

Store the bit saying whether the class instance has any finalizers in the  
monitor field.  That is, you still set the hasFinalizer bit in the GC  
block, but you check the monitor area.  For example, if the monitor's lsb  
is set to 1 (not possible for a pointer), then the optimal case of no  
monitor, no finalizer is registered as true.

What is the big slowdown in rt_finalize?  The loop moving up the dtors?   
Or is it simply calling rt_finalize at all?

-Steve


More information about the Digitalmars-d mailing list