2

I have a personal project which I implement using the Boehm GC. I need to implement a sort of event type, which should hold references to other events. But I also need to ensure that the events pointed to are still collectable, thus I need weak references for this.

Let's say we have events A, B and C. I configure these events to signal event X whenever any of them is signaled. This means A, B and C must hold a reference to event X. What I want is that if event X is unreachable the events A, B and C don't need to signal it anymore. Thus a weak reference is what I thought of.

Is there any other way to do this? I don't want to change the GC but if necessary (the allocation interface remains clean) I could.

The project is written in C. If need be, I will provide more info. Notably, if there is any way to implement such events directly with this semantics, there's no need for actual weak references (events MAY have a reference cycle though while they are not signaled).

Paul Stelian
  • 1,381
  • 9
  • 27

1 Answers1

4

The Boehm GC does not have a concept of weak references per se. However, it does not scan memory allocated by the system malloc for references to managed objects, so pointers stored in such memory do not prevent the pointed-to object from being collected. Of course, that approach means that the objects containing the pointers will not be managed by the collector.

Alternatively, it should be possible to abuse GC_MALLOC_ATOMIC() or GC_malloc_explicitly_typed() to obtain a managed object that can contain pointers to other managed objects without preventing those other objects from being collected. That involves basically lying to GC about whether some members are pointers, so as to prevent them from being scanned.

Either way, you also require some mechanism for receiving notice when weakly-referenced objects are collected, so as to avoid attempting to access them afterward. GC has an interface for registering finalizer callbacks to be invoked before an object is collected, and that looks like your best available option for the purpose.

Overall, I think what you're asking for is doable, but with a lot of DIY involved. At a high level,

  • use GC_MALLOC_ATOMIC() to allocate a wrapper object around a pointer to the weakly referenced object. Allocating it this way allows the wrapper to itself be managed by GC, without the pointer within being scanned during GC's reachability analyses.
  • use GC_register_finalizer to register a finalizer function that sets the wrapper's pointer to NULL when GC decides that the pointed-to object is inaccessible.
  • users of the wrapper are obligated to check whether the pointer within is NULL before attempting to dereference it.
John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • So basically I should make a sort of handle object, store the actual reference into an area that the collector doesn't look in, register a finalizer (how do I get the handle object instead of the actual being-finalized object?) and use that to zero out the pointer whenever that object is collected? – Paul Stelian May 01 '19 at 14:42
  • Also, is that GC_register_disappearing_link going to do anything useful for me? – Paul Stelian May 01 '19 at 14:43
  • No, I don't think `GC_register_disappearing_link` is going to be useful to you for this purpose. It causes a pointer to be zeroed out when *the object containing it* is found to be inaccessible, but you want to clear pointers when *the object they point to* becomes inaccessible, which of course doesn't happen as long as a pointer that GC knows about points to that object. – John Bollinger May 01 '19 at 14:50
  • Apparently GC_register_finalizer takes a pointer to my handle object, so that's done. Then simply I should allocate the contents of the handle object with GC_MALLOC_ATOMIC, set to zero (I think BOEHM does it for me), register a finalizer that zeroes out when the object itself is collected and then set the contents of the handler object... I think this may work as an answer. – Paul Stelian May 01 '19 at 14:50
  • I would like you to put it in your answer then for future reference. The design if not actual code. – Paul Stelian May 01 '19 at 14:52
  • (I wonder if it's actually thread safe though... It should, but I'll still ponder on it) – Paul Stelian May 01 '19 at 14:53
  • 1
    Ok, @PaulStelian, I have updated the answer with a high-level outline of the suggested approach. – John Bollinger May 01 '19 at 15:01
  • That's perfect, thanks. When I'll actually be working on the project I'll implement it. – Paul Stelian May 01 '19 at 15:07