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] SIGSEGV in GC_register_finalizer_inner () Date: Thu, 09 Jun 2005 05:11:00 -0000 [thread overview] Message-ID: <20050609051042.31683.qmail@sourceware.org> (raw) In-Reply-To: <20041101172052.18266.ovidr@users.sourceforge.net> ------- Additional Comments From Hans dot Boehm at hp dot com 2005-06-09 05:10 ------- Unfortunately, I haven't had time to pursue this. I think that in order to get this to fail, you want lots of weak references to objects which are also sobject to lock contention or wait/notify calls. I don't think we currently have a good test case. My impression is that natReference.cc already keeps a fairly elaborate data structure to which you should be able to add the prior finalization info, so that it can be invoked at the right point by the existing finalizer there. In general, the GC's data structures don't queue multiple finalizers. You need to register a new finalizer that knows it has to reregister the old one when it's done. The information that there was another finalizer needs to be kept off to the side somewhere in a separate table, or as part of the "client data" registered with the finalizer. The locking code also has to deal with opaque objects, but it again has its own hash table off to the side. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266
next prev parent reply other threads:[~2005-06-09 5:11 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-11-01 17:21 [Bug libgcj/18266] New: " ovidr at users dot sourceforge dot net 2004-11-01 17:22 ` [Bug libgcj/18266] " ovidr at users dot sourceforge dot net 2004-11-01 20:44 ` Hans dot Boehm at hp dot com 2004-11-01 22:08 ` ovidr at users dot sourceforge dot net 2004-11-08 3:00 ` ovidr at users dot sourceforge dot net 2004-11-08 19:56 ` Hans dot Boehm at hp dot com 2004-11-08 20:27 ` ovidr at users dot sourceforge dot net 2004-11-25 1:50 ` Hans dot Boehm at hp dot com 2004-11-25 3:25 ` tromey at gcc dot gnu dot org 2004-11-25 3:26 ` tromey at gcc dot gnu dot org 2004-12-02 13:43 ` pinskia at gcc dot gnu dot org 2005-05-17 20:40 ` daney at gcc dot gnu dot org 2005-05-17 20:47 ` pinskia at gcc dot gnu dot org 2005-06-08 21:14 ` ovidr at users dot sourceforge dot net 2005-06-09 5:11 ` Hans dot Boehm at hp dot com [this message] 2005-06-20 16:25 ` ovidr at users dot sourceforge dot net 2005-07-19 15:06 ` ovidr at users dot sourceforge dot net [not found] <bug-18266-7936@http.gcc.gnu.org/bugzilla/> 2006-03-08 19:27 ` tromey 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=20050609051042.31683.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).