--- Comment #14 from tromey at gcc dot gnu dot org 2006-03-08 19:27 ---
I've been looking into this a bit.
The current problem I see is that the heavyweight lock stuff
relies on the GC. This won't interact well with the current
code in natReference.cc, as those data structures are not
--- Additional Comments From ovidr at users dot sourceforge dot net
2005-07-19 15:06 ---
I've spent a lot of time trying to make a testcase of this, but no luck yet.
I can basically create a testapp with 2 threads. When they both access a
synchronized method, and are forced to wait
--- Additional Comments From ovidr at users dot sourceforge dot net
2005-06-20 16:25 ---
I've tried to create a testcase but can't seem to get a crash or infinite loop
lockup.
Anyway, I think I understand conceptually what must be done, but in practice
I'm still unsure of how to go
--- Additional Comments From ovidr at users dot sourceforge dot net
2005-06-08 21:14 ---
Since this bug seems a bit lost, I've been trying some things on my own without
success.
Can someone please explain:
If referent is just a RawData pointer to some Object, how are its previous
--- 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
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org
|dot org |
Status|NEW
--
What|Removed |Added
AssignedTo|daney at gcc dot gnu dot org|unassigned at gcc dot gnu
||dot org
Status|ASSIGNED
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02
13:42 ---
Confirmed based on Tromey's comments.
--
What|Removed |Added
Status|UNCONFIRMED
--- 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 tromey at gcc dot gnu dot org 2004-11-25
03:25 ---
Oops, I wasn't aware that the locks code was using finalizers.
We had to make special consideration in the reference code for
String.intern; we can do something similar for locks.
This is pretty important, I
--
What|Removed |Added
OtherBugsDependingO||17574
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266
--- 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 that the
--- Additional Comments From ovidr at users dot sourceforge dot net
2004-11-08 20:27 ---
Unforunately many variables seem not to be available:
GNU gdb 6.1
(gdb) p descr
Variable descr is not available.
(gdb) p current_p
$1 = (word *) 0x9acf618
(gdb) p type_descr
No symbol type_descr in
--- Additional Comments From ovidr at users dot sourceforge dot net
2004-11-08 03:00 ---
Recompiled with -g (and waited a few days..), but I'm not sure if this is the
same problem or not:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1106963376 (LWP 23098)]
--
What|Removed |Added
CC||Hans dot Boehm at hp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266
--- 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 on
--- Additional Comments From ovidr at users dot sourceforge dot net 2004-11-01
22:08 ---
The app uses many java.util.WeakHashMap s (usually with null values, just
storing objects in the keys ie: map.put(object, null), if that matters).
--
17 matches
Mail list logo
