------- 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 don't think we currently have a good test case. My impression is that natReference.cc already keeps a fairly elaborate data structure to which you should be able to add the prior finalization info, so that it can be invoked at the right point by the existing finalizer there. In general, the GC's data structures don't queue multiple finalizers. You need to register a new finalizer that knows it has to reregister the old one when it's done. The information that there was another finalizer needs to be kept off to the side somewhere in a separate table, or as part of the "client data" registered with the finalizer. The locking code also has to deal with opaque objects, but it again has its own hash table off to the side. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266
