[Bug libgcj/18266] GCJ: Using references drops finalizers causing all apps to eventually crash ( SIGSEGV in GC_register_finalizer_inner () )

[Hans dot Boehm at hp dot com]

------- Comment #19 from Hans dot Boehm at hp dot com  2008-09-23 23:39 -------
I looked at this a bit, trying to remind myself of the logic.  I'm not
positive, but it looks plausible to me that doing without the finalizer might
work for most applications.  Historically, the finalizer was the only cleanup
mechanism for heavy locks.  But that turned out to be insuficient, and
maybe_remove_all_heavy was added.  It tries to occasionally remove long lists
of heavy locks, that were still observed to accumulate in some cases.  That's
probably usually enough to keep the list from growing without bounds.

I would however worry about an application that holds one or more locks
indefinitely.  At that point, the heavy_count for the corresponding hash entry
never drops to zero, and maybe_remove_all_heavy won't do its job for that
entry.  Thus I think the list of heavy locks for that entry will grow without
(reasonable) bounds.

As a result, I don't think this is curently a fully general fix, though it may
work for many applications.

I'm not positive, but it seems likely to me that one might be able to avoid
this "poisoning" effect of a single-in-use lock by adding in-use bits to heavy
locks, which are protected on the lock bit by the hash entry.  This may allow
unused entries to be cleaned up even if one or two heavy locks in the chain are
held.  That might turn this into a real fix, if it's not possible to fix this
elsewhere.  It might also simplify the code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266