On Sun, 05 Jun 2011 00:28:58 -0400, dsimcha <dsim...@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
