Memory leak

[jvlmdr]

GCSpec fails because memory allocated using fftw_malloc is never freed.

[jvlmdr]

In order to fix this, I define a struct which is allocated using new(), and associate with it a finalizer which invokes fftw_free. However, this breaks the interface of returning []complex128.

[runningwild]

Are you sure there is a memory leak? I thought the way that the SliceHeader was constructed in Alloc1d makes it possible for the GC to collect it properly. The GCSpec certainly does not fail for me, what OS/version are you using?

[jvlmdr]

Fedora 15 and Go 1.1, and go-fftw commit d48c5e.

$ uname -mrs
Linux 2.6.43.8-1.fc15.x86_64 x86_64
$ go version
go version go1.1 linux/amd64

I'm running it in an environment which imposes a hard limit of 16GB on the process.

[jvlmdr]

From https://code.google.com/p/go-wiki/wiki/cgo

keep in mind that the Go garbage collector will not interact with this data

[bemasher]

According to http://godoc.org/runtime#SetFinalizer a finalizer should not be used for freeing memory since it's not guaranteed that a finalizer will be run before the program exits.

[jvlmdr]

I interpreted the doc differently.

typically they are useful only for releasing non-memory resources associated with an object during a long-running program

I took this simply to mean that it's not typical to use a finalizer with a memory resource because there is a garbage collector.

it would be a mistake to depend on a finalizer to flush an in-memory I/O buffer such as a bufio.Writer, because the buffer would not be flushed at program exit

I thought that this was only saying to avoid using it where it would change the effect of your program to not have the finalizer called. However this wouldn't be a problem for freeing memory.

The alternative is to always defer fftw.Free(), but it would be better if we could avoid this because it makes it messy to write functions which create and return an FFT.

[bemasher]

It's still a memory leak if the finalizer isn't guaranteed to be called. The GC won't touch data that isn't allocated by Go, it has to be freed somewhere.

[jvlmdr]

I understand. Yep, so the finalizer is not ideal since it will only be invoked when a garbage collection is triggered but the memory allocated by fftw_malloc will not count towards the total for this trigger. Are the only options then to either use "defer" with memory allocated by fftw_malloc or to use unaligned blocks of memory allocated by Go, there's no way to get the best of both worlds?

[bemasher]

In my testing Go's memory alignment isn't much of an issue for performance. Although I haven't been able to test on any other architectures or OS's other than windows and linux on amd64.

http://golang.org/ref/spec#Size_and_alignment_guarantees

In my own implementation I've been using defer with a Close method. It's not an issue since you have the same pattern as opening or creating a file when planning an FFT. Just needs to be clear in the examples and documentation that plans must be closed.

[jvlmdr]

Cool, that alignment spec basically makes it a non-issue then. Thanks! I don't mind using defer to clean up a plan because I think there should also be utility functions which hide the plans from the user, so they only have to deal with plans (and hence cleaning them up) if they're really concerned with performance.

[bemasher]

Although, plans must still be destroyed even if you provided your own input and output arrays.

[jvlmdr]

I made these changes to my fork too, cheers.