From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18120 invoked by alias); 23 Sep 2008 23:39:52 -0000 Received: (qmail 18097 invoked by uid 48); 23 Sep 2008 23:39:51 -0000 Date: Tue, 23 Sep 2008 23:39:00 -0000 Message-ID: <20080923233951.18096.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libgcj/18266] GCJ: Using references drops finalizers causing all apps to eventually crash ( SIGSEGV in GC_register_finalizer_inner () ) In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "Hans dot Boehm at hp dot com" Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2008-q3/txt/msg00067.txt.bz2 ------- 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