https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112011-10-28T12:53:10ZRuby Issue Tracking SystemRuby master - Feature #5494: Proposal: Improved Finalizer Semantics https://redmine.ruby-lang.org/issues/5494?journal_id=216052011-10-28T12:53:10Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>Hi,</p>
<p>In message "Re: <a href="/issues/5494">[ruby-core:40474]</a> [ruby-trunk - Feature <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: Proposal: Improved Finalizer Semantics (Rejected)" href="https://redmine.ruby-lang.org/issues/5494">#5494</a>][Open] Proposal: Improved Finalizer Semantics"<br>
on Fri, 28 Oct 2011 12:20:38 +0900, Kurt Stephens <a href="mailto:ks.ruby@kurtstephens.com" class="email">ks.ruby@kurtstephens.com</a> writes:</p>
<p>|This is a simpler protocol:<br>
|<br>
|* It removes the need for _id2ref in the finalizer procs.<br>
|* Prevents other complications: such as GC being reinvoked within a finalizer.<br>
|* Finalizers are invoked with the same "urgency" as before.</p>
<ul>
<li>_id2ref does not work in finalizers, since their corresponding<br>
objects are already freed.</li>
<li>finalizers are called after GC.</li>
</ul>
<p>Your proposal might be based on false assumption. If I were going to<br>
make an incompatible change to the finalizer in the future, I'd remove<br>
it altogether.</p>
<pre><code> matz.
</code></pre> Ruby master - Feature #5494: Proposal: Improved Finalizer Semantics https://redmine.ruby-lang.org/issues/5494?journal_id=216102011-10-28T14:16:34Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Rejected</i></li></ul><p>Even if the object has not been freed, other objects referred by the<br>
object might be freed already. It has to sort topologically the<br>
directed graph, even for simple cases. Not only this would be quite<br>
expensive, cyclic references cannot sort.</p> Ruby master - Feature #5494: Proposal: Improved Finalizer Semantics https://redmine.ruby-lang.org/issues/5494?journal_id=216122011-10-28T14:35:04Zkstephens (Kurt Stephens)
<ul></ul><p>Nobuyoshi Nakada wrote:</p>
<blockquote>
<p>Even if the object has not been freed, other objects referred by the<br>
object might be freed already. It has to sort topologically the<br>
directed graph, even for simple cases. Not only this would be quite<br>
expensive, cyclic references cannot sort.</p>
</blockquote>
<p>Good point. It would have to re-MARK the object and its references, recursively, to be safe.</p> Ruby master - Feature #5494: Proposal: Improved Finalizer Semantics https://redmine.ruby-lang.org/issues/5494?journal_id=218012011-11-02T03:57:34Zkstephens (Kurt Stephens)
<ul></ul><p>Kurt Stephens wrote:</p>
<blockquote>
<p>Nobuyoshi Nakada wrote:</p>
<blockquote>
<p>Even if the object has not been freed, other objects referred by the<br>
object might be freed already. It has to sort topologically the<br>
directed graph, even for simple cases. Not only this would be quite<br>
expensive, cyclic references cannot sort.</p>
</blockquote>
<p>Good point. It would have to re-MARK the object and its references, recursively, to be safe.</p>
</blockquote>
<p>Clarifications:</p>
<ul>
<li>The idea is to run finalizers (and re-MARK) after root marking, and before sweep. Thus, it would work with lazy sweep.</li>
<li>The MARK operation on the finalized object is the <em>exact</em> same recursive MARK operation that already exists in gc.c.</li>
<li>The semantics I described is exactly how (most) JVMs implement finalizations. It's also how I implemented finalizations in SMAL.</li>
<li>We can keep the proc.call(obj.id) API, until the proc.call(obj) API change is acceptable.</li>
</ul>