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


  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: link
Be 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).