public inbox for java-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug java/16478] New: Hash synchronization deadlock with finalizers
@ 2004-07-11 20:47 mckinlay at redhat dot com
  2004-07-11 20:47 ` [Bug libgcj/16478] " mckinlay at redhat dot com
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: mckinlay at redhat dot com @ 2004-07-11 20:47 UTC (permalink / raw)
  To: java-prs

>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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libgcj/16478] Hash synchronization deadlock with finalizers
  2004-07-11 20:47 [Bug java/16478] New: Hash synchronization deadlock with finalizers mckinlay at redhat dot com
@ 2004-07-11 20:47 ` mckinlay at redhat dot com
  2004-07-11 21:31 ` cvs-commit at gcc dot gnu dot org
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: mckinlay at redhat dot com @ 2004-07-11 20:47 UTC (permalink / raw)
  To: java-prs



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|java                        |libgcj


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16478


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libgcj/16478] Hash synchronization deadlock with finalizers
  2004-07-11 20:47 [Bug java/16478] New: Hash synchronization deadlock with finalizers mckinlay at redhat dot com
  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
  4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu dot org @ 2004-07-11 21:31 UTC (permalink / raw)
  To: java-prs


------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-07-11 21:31 -------
Subject: Bug 16478

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	bryce@gcc.gnu.org	2004-07-11 21:31:06

Modified files:
	libjava        : ChangeLog 

Log message:
	2004-07-11  Bryce McKinlay  <mckinlay@redhat.com>
	
	PR libgcj/16478
	* prims.cc (_Jv_CreateJavaVM): Fix comment.
	* gnu/gcj/runtime/FinalizerThread.java (init): New. Native.
	(finalizerReady): Now native.
	(run): Likewise.
	(runFinalizers): Removed.
	* gnu/gcj/runtime/natFinalizerThread.cc (run): Implement here. Use
	a primitive lock, and don't hold it while running the finalizers.
	(runFinalizers): Implement. Don't aquire any Java lock.
	(finalizerReady): Use lock primitives to signal finalizer thread.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.2562.2.20&r2=1.2562.2.21



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16478


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libgcj/16478] Hash synchronization deadlock with finalizers
  2004-07-11 20:47 [Bug java/16478] New: Hash synchronization deadlock with finalizers mckinlay at redhat dot com
  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
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu dot org @ 2004-07-11 21:31 UTC (permalink / raw)
  To: java-prs


------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-07-11 21:31 -------
Subject: Bug 16478

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	bryce@gcc.gnu.org	2004-07-11 21:31:50

Modified files:
	libjava        : ChangeLog 

Log message:
	2004-07-11  Bryce McKinlay  <mckinlay@redhat.com>
	
	PR libgcj/16478
	* prims.cc (_Jv_CreateJavaVM): Fix comment.
	* gnu/gcj/runtime/FinalizerThread.java (init): New. Native.
	(finalizerReady): Now native.
	(run): Likewise.
	(runFinalizers): Removed.
	* gnu/gcj/runtime/natFinalizerThread.cc (run): Implement here. Use
	a primitive lock, and don't hold it while running the finalizers.
	(runFinalizers): Implement. Don't aquire any Java lock.
	(finalizerReady): Use lock primitives to signal finalizer thread.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.2922&r2=1.2923



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16478


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libgcj/16478] Hash synchronization deadlock with finalizers
  2004-07-11 20:47 [Bug java/16478] New: Hash synchronization deadlock with finalizers mckinlay at redhat dot com
                   ` (2 preceding siblings ...)
  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
  4 siblings, 0 replies; 6+ messages in thread
From: mckinlay at redhat dot com @ 2004-07-11 21:32 UTC (permalink / raw)
  To: java-prs


------- Additional Comments From mckinlay at redhat dot com  2004-07-11 21:32 -------
Fix checked in to HEAD and 3.4 branch.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |3.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16478


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libgcj/16478] Hash synchronization deadlock with finalizers
  2004-07-11 20:47 [Bug java/16478] New: Hash synchronization deadlock with finalizers mckinlay at redhat dot com
                   ` (3 preceding siblings ...)
  2004-07-11 21:32 ` mckinlay at redhat dot com
@ 2004-07-12  5:53 ` pinskia at gcc dot gnu dot org
  4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-07-12  5:53 UTC (permalink / raw)
  To: java-prs



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.5.0                       |3.4.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16478


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2004-07-12  5:53 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-07-11 20:47 [Bug java/16478] New: Hash synchronization deadlock with finalizers mckinlay at redhat dot com
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

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).