3

TLDR: Is there any way to reasonably write test cases to test finalizer behaviors?

I'm trying to implement a memory-sensitive canonicalizing map / cache in Go. Since there is no notion of "soft reference" (and because my object graph will always form a DAG), I'm accomplishing this with a tiny interface/framework that tracks counts of references in the userland:

type ReferenceCounted interface {
   RefCount() int
   IncRef()
   DecRef() (bool, error)
}

type Finalizable interface {
   ReferenceCounted
   Finalize()
}

type AbstractCounted struct {
     // unexported fields
}

The way this works is that you have a struct which embeds AbstractCounted, and implement Finalizable.Finalize() - these together make that struct receive the Finalizable interface. Then there is a function func MakeRef(obj Finalizable) *Reference which returns a pointer to a struct which receives a method func Get() Finalizable, which gets the reference target, and which is initialized by incrementing the ref count on the unerlying object, then setting a finalizer (via runtime.SetFinalizer()) which will decrement the reference. AbstractCounted's Finalizable implementation in turn calls Finalize() on the struct which embeds it when the ref count reaches zero.

So, everything is set up to work very much like soft references / ref queues in Java would now, with the exception that it's reference counting and not a mark/sweep rooted in active lexical scopes that is finding things "softly" reachable.

It seems to work great! But - I would like to write a test case...

I understand fully that finalizer invocation is deferred, and that no guarantees are made about running them per the reflect package docs. The situation is the same in other languages with runtime gc and finalizers (C#, VB, Java, Python, etc) as well.

However, in all of those other languages, requesting explicit GC (here through the runtime.GC() function) does seem to cause finalizers to get run. Since that's not the case in Go, I cannot figure out a way to write a test case that will trigger the finalizers.

Is there any trick or code fragment (I'm OK with this being current-implementation dependent, ie. could-break-in-future!) that will reliably trigger those finalizers so I can write my test?

BadZen
  • 4,083
  • 2
  • 25
  • 48
  • I assume you're talking about using runtime.SetFinalizer? I think you need to show some of your implementation. How are you holding the references within your data structure, since if there are any live pointers they won't be GC'ed and the finalizer won't be run. – JimB Jun 23 '15 at 19:50
  • @JimB - Yes, runtime.SetFinalizer(), edited above. – BadZen Jun 23 '15 at 19:52
  • @JimB - I'm not asking why finalizers are not being run in my cache implementation, they are (eventually). What I'm asking is how to "trigger" them to run on-demand so that I can write a test case with the "testing" package, rather than just having to observe them being cleaned up in the integrated, long-running, non-unit-test scenario.... – BadZen Jun 23 '15 at 19:54
  • Attempt at the unit test is here: http://pastebin.com/bZHjDaXc It's the last error that is happening, and the reference structure is just an int count and a reference to the object. (The object does not hold a reference to the reference - I mention this b/c the docs indicate finalizers will not be called on circular reference chians.) The equivalent condition in the "long running program" does not occur. – BadZen Jun 23 '15 at 19:56
  • 2
    In general, `runtime.GC` will trigger the finalizers, *eventually*. If you look at `runtime/mfinal_test.go`, you can see simple tests where they wait for the finalizer to be called via a channel after calling `runtime.GC`. – JimB Jun 23 '15 at 20:08
  • Awesome. So it's a time thing and not a memory use thing. Exactly what I was looking for, TYVM. Make this an answer! – BadZen Jun 23 '15 at 20:16
  • 1
    I remember reading somewhere that finalizers have a high chance of getting dumped after Go 1, just an FYI. – thwd Jun 23 '15 at 20:19
  • 1
    @thwd: well after go1, would be go2 which would be a different language that has no planned release date, so I don't think we need to worry about that at the moment. – JimB Jun 23 '15 at 20:21
  • @thwd Presumably go2 would have another mechanism for dealing with this sort of thing - there isn't even a spec yet, so no sense in planning for it. – BadZen Jun 23 '15 at 20:22

1 Answers1

4

You can't explicitly trigger a Finalizer, so the best you can manage is to make sure the GC is started with runtime.GC(), and wait for the finalizer to run.

If you look at runtime/mfinal_test.go, there are some tests that wait for finalizer calls via a channel:

runtime.SetFinalizer(y, func(z *objtype) { fin <- true })
runtime.GC()
select {
case <-fin:
case <-time.After(4 * time.Second):
    t.Errorf("finalizer of next string in memory didn't run")
}
JimB
  • 104,193
  • 13
  • 262
  • 255
  • Waiting here was the thing I wasn't doing! Tests work great now, thanks. (Compared to Java eg, gc request may be started but not finished when the gc request call returns) – BadZen Jun 23 '15 at 20:32