public inbox for java-prs@sourceware.org help / color / mirror / Atom feed
From: "Hans dot Boehm at hp dot com" <gcc-bugzilla@gcc.gnu.org> To: java-prs@gcc.gnu.org Subject: [Bug libgcj/18266] GCJ: Using references drops finalizers causing all apps to eventually crash ( SIGSEGV in GC_register_finalizer_inner () ) Date: Tue, 23 Sep 2008 23:39:00 -0000 [thread overview] Message-ID: <20080923233951.18096.qmail@sourceware.org> (raw) In-Reply-To: <bug-18266-7936@http.gcc.gnu.org/bugzilla/> ------- 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
next prev parent reply other threads:[~2008-09-23 23:39 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-18266-7936@http.gcc.gnu.org/bugzilla/> 2006-03-08 19:27 ` [Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner () tromey at gcc dot gnu dot org 2006-11-03 22:58 ` [Bug libgcj/18266] GCJ: Using references drops finalizers causing all apps to eventually crash ( SIGSEGV in GC_register_finalizer_inner () ) r_ovidius at eml dot cc 2008-09-22 20:08 ` daney at gcc dot gnu dot org 2008-09-22 23:56 ` daney at gcc dot gnu dot org 2008-09-23 17:40 ` daney at gcc dot gnu dot org 2008-09-23 23:39 ` Hans dot Boehm at hp dot com [this message] 2008-09-26 15:58 ` daney at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20080923233951.18096.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=java-prs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).