https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
--- Comment #20 from daney at gcc dot gnu dot org 2008-09-26 15:58 ---
1) Create an object.
2) Enter a synchronized block on the object and do Object.wait().
3) In a second thread, enter a synchronized block on the object. There is lock
contention, heavy lock escalation is guaranteed
--- 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 was the onl
--- Comment #18 from daney at gcc dot gnu dot org 2008-09-23 17:40 ---
Created an attachment (id=16396)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16396&action=view)
Possible work-around
This is a patch against 3.4.3 that we are seriously considering using
internally. The theo
--- Comment #17 from daney at gcc dot gnu dot org 2008-09-22 23:56 ---
For me the testcase always gets a ConcurrentModificationException in w.clear()
very soon after starting. This is on GCC trunk 140563 on x86_64-pc-linux-gnu.
If I synchronize(w) for accesses to w there is no
Concurre
--- Comment #16 from daney at gcc dot gnu dot org 2008-09-22 20:08 ---
This is biting me now. Perhaps I may look at fixing it (or maybe not...).
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #15 from r_ovidius at eml dot cc 2006-11-03 22:58 ---
Updated summary. (Happy 2 year birthday, stupid stubborn bug.)
--
r_ovidius at eml dot cc changed:
What|Removed |Added
--
