--- Comment #3 from Hans dot Boehm at hp dot com 2010-07-22 18:03 ---
Is there a plan for more complete C++0x/C1x atomics support? Something
eventually needs to implement the memory_order_acquire/memory_order_release
versions of these primitives? Nptl also seems to be in need
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Hans dot Boehm at hp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45025
org
ReportedBy: Hans dot Boehm at hp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42869
--- 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
--- Comment #2 from Hans dot Boehm at hp dot com 2007-09-18 22:26 ---
I assume the LOCKED bit in *he is actually set when gdb looks at it? What does
the rest of the hash entry look like? That might give you a hint as to the
culprit.
Clearly someone sets the LOCKED bit on a hash entry
--- Comment #4 from Hans dot Boehm at hp dot com 2007-08-29 00:53 ---
I'll make the %X1 change upstream. Are there similar issues with some of the
other routines?
(See
http://bdwgc.cvs.sourceforge.net/bdwgc/bdwgc/libatomic_ops-1.2/src/atomic_ops/sysdeps/gcc/powerpc.h?revision=1.3view
--- Comment #2 from Hans dot Boehm at hp dot com 2006-04-14 20:51 ---
Based on the thread 13 stack trace, it looks to me like we're calling dlopen
directly, when we should somehow be arranging to call GC_dlopen. GC_dlopen is
included in the GC to avoid this sort of deadlock.
(The way
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Hans dot Boehm at hp dot com
CC: gcc-bugs at gcc dot gnu
--- Additional Comments From Hans dot Boehm at hp dot com 2005-08-12 18:51
---
Could we reopen this as a documentation bug? I'm still confused, and the
amount of discussion suggests I'm not alone. Currently r is documented as
meaning general register, with no comments about operand
--- 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
--- Additional Comments From Hans dot Boehm at hp dot com 2005-04-08 00:18
---
The problem here is that _Jv_InitGC is called to late, and hence
GC_all_interior_pointers is cleared after the GC has been run. This is
documented not to work in gc.h.
In particular
--- Additional Comments From Hans dot Boehm at hp dot com 2005-02-14 19:38
---
I'd like to see USE_MMAP set in boehm-gc/configure.ac instead of gcconfig.h.
There's already a comment there that we're not setting NO_EXECUTE_PERMISSION
for this reason, where the upstream version does
--- Additional Comments From Hans dot Boehm at hp dot com 2005-02-10 00:33
---
I agree with Tom's interpretation. The define for USE_MMAP only affects
M68K/LINUX. Confirmed with strace on IA/64.
I'd prefer to see the USE_MMAP definition in a gcj-specific configuration
file. I'd
--- Additional Comments From Hans dot Boehm at hp dot com 2005-02-09 05:38
---
I believe that the GC alters permissions on the heap only if either
- It is running in incremental mode, or
- It is built with USE_MMAP, and thus uses mmap to allocate the heap.
I think we talked about always
--- Additional Comments From Hans dot Boehm at hp dot com 2004-11-29 18:18
---
I have not tried to reproduce this. This is purely conjecture:
All failures could be explained if the collector is no longer intercepting
pthread_create. Threads should be created with GC_pthread_create
--- Additional Comments From Hans dot Boehm at hp dot com 2004-11-25 01:50
---
After finally finding time to look at the code, it appears that my earlier
guesses were correct.
::java::lang::ref::Reference::create in natReference.cc calls
_Jv_RegisterFinalizer(referent ...), where
--- Additional Comments From Hans dot Boehm at hp dot com 2004-11-08 19:55
---
I think this could be explained by the same problem.
This time the collector is in the Java-specific finalization pass which
marks objects reachable from objects that are about to be finalized,
so
--- Additional Comments From Hans dot Boehm at hp dot com 2004-11-01 20:44 ---
This would be a lot easier if libgcj had been built with something like -O2 -g.
Based on approximate manual matching of the object code to finalize.s, I think
this is failing around line 452 of finalize.c
18 matches
Mail list logo
