public inbox for java-prs@sourceware.org help / color / mirror / Atom feed
From: "mckinlay at redhat dot com" <gcc-bugzilla@gcc.gnu.org> To: java-prs@gcc.gnu.org Subject: [Bug java/16478] New: Hash synchronization deadlock with finalizers Date: Sun, 11 Jul 2004 20:47:00 -0000 [thread overview] Message-ID: <20040711204728.16478.mckinlay@redhat.com> (raw) >From Hans Boehm and Jacob Gladish: The problem is in thread 8. I doubt it has been fixed, but I didn't check. Basically we have _Jv_MonitorEnter acquires lock bit on lightweight lock entry notices it needs to allocate heavyweight lock calls eventually alloc_heavy. alloc_heavy call GC_local_gcj_malloc GC_local_gcj_malloc is out of free list entries AND is first allocation to run since GC, which results in a call to FinalizerThread.finalizerReady, which is currently unrestricted Java code. It then calls _Jv_MonitorEnter which tries to acquire the same lock table entry it already owns ==> deadlock Is it hard to make FinalizerThread.finalizerReady a small piece of C++ code, which does not acquire Java locks, e.g. by just doing a pthread_cond_signal equivalent? The alternative would be to avoid allocation calls with the lock bit on a lock table entry set. (I think that registering a finalizer is OK. That allocates internally, but I don't think it can invoke finalizer notification.) But that looks a bit messy and more expensive: You'd have to preallocate the heavyweight object before acquiring the lock bit, and then drop it if you didn't need it. Or I guess we could add a GC allocation call which didn't do the finalizer notification check. I'm also not sure that running Java code during finalizer notification is otherwise safe. This can happen during arbitrary allocations, with locks held, etc. Hans >> -----Original Message----- >> From: java-owner@gcc.gnu.org >> [mailto:java-owner@gcc.gnu.org]On Behalf Of >> Jacob Gladish >> Sent: Thursday, July 08, 2004 2:32 PM >> To: java@gcc.gnu.org >> Subject: hash synchronization on linux >> >> >> I've suspected a problem with the hash synchronization for >> some time now >> and decided that I might be able to reproduce the problem with a unit >> test, and think that I have stumbled onto something. >> I've attached two classes that can be run against gcc-3.1 and very >> quickly deadlock. To make this happen you must rebuild with a changed >> hash_entry table size of 2. I suspected a race with bucket >> access (heavy >> lock chain) so reducing the size increased the likelihood that I would >> be able to reproduce this easily. This is being run on Linux >> SMP 2.4.18 >> (machine has two procs). >> I've also included the backtrace of all the threads in this state. No >> threads ever return from _Jv_MonitorEnter. I know the 3.1 release is >> pretty old at this point, but I'm in the middle of building 3.4.1 with >> the hash_entry table size shrunk to 2 and am going to see if >> it behaves >> the same. I was also under the impression that the >> hash_synchronization >> code has basically been untouched for a while. >> Thanks >> Jake >> -- Summary: Hash synchronization deadlock with finalizers Product: gcc Version: 3.5.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mckinlay at redhat dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16478
next reply other threads:[~2004-07-11 20:47 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-07-11 20:47 mckinlay at redhat dot com [this message] 2004-07-11 20:47 ` [Bug libgcj/16478] " mckinlay at redhat dot com 2004-07-11 21:31 ` cvs-commit at gcc dot gnu dot org 2004-07-11 21:31 ` cvs-commit at gcc dot gnu dot org 2004-07-11 21:32 ` mckinlay at redhat dot com 2004-07-12 5:53 ` pinskia 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=20040711204728.16478.mckinlay@redhat.com \ --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).