Attaching a Finalizer to a struct field holding a slice or the slice's underlying array

416 views
Skip to first unread message

John

unread,
Dec 29, 2019, 12:27:29 AM12/29/19
to golang-nuts
Looking for a little insight on if it is possible to do something:

Given this type:

type Blah struct {
    Payload []byte
}

What I'm looking for is to kick off a finalizer when a slice and all other slices backed by the same array get GC'd.

In lieu of that, whenver the pointer to the array backing a slice get's GC'd. I realize that in this case, the slice actually may stay around when the array is GC'd because an append creates a new array on the slice.

I don't think the first is possible, as you can't call SetFinalizer() on non-pointer types. And I can't use any wrappers or pointers to []byte in lieu of []byte for my use case.

I figure there is a way to use:

hdr := (*reflect.SliceHeader)(unsafe.Pointer(&b.Payload))

to set a finalizer on the underlying arrray.

But I'm not sure exactly how to convert the hdr.Data into the specific array type pointer to use in SetFinalizer().  It may not be possible.

To save some time on a few questions:  I'm aware of the flaws of SetFinalizer(), just looking to see if this can actually be done.

Thanks for any help.

Keith Randall

unread,
Dec 30, 2019, 12:16:53 AM12/30/19
to golang-nuts
It should work to just set the finalizer on the first byte of an allocation. i.e.:

s := make([]byte, N)
runtime.SetFinalizer(&s[0], func(b *byte) { ... })

Note that the spec of runtime.SetFinalizer doesn't actually guarantee that this will work. But I think in the current implementation it will.

> The argument obj must be a pointer to an object allocated by calling new, by taking the address of a composite literal, or by taking the address of a local variable.

The result of make isn't "an object created by calling new", but it it close.

John

unread,
Dec 30, 2019, 11:30:59 AM12/30/19
to golang-nuts
Thank you Keith, that is a very interesting technique, I doubt I would have come up with that.

Unfortunately, that lead me to another problem as I needed the finalizer to have access to the entire underlying data, which I did not state when I wrote my question.

I tried to extend this to provide the whole slice to the finalizer using the current scope:

type Blah struct {
        Payload []byte
}

func do() {
        b := &Blah{Payload: make([]byte, 100)}
        runtime.SetFinalizer(&b.Payload[0], func(o *byte){log.Println("finalized"); fmt.Println("b.Payload[1] })
        ...
}

That of course created a reference to the slice in the finalizer, which then prevents the slice from being GC'd, defeating the purpose.

The more I've dug into this, the more I can see that trying to do this is probably not possible, or at best, never going to be safe.  It was a nice thought experiment though.

Thanks for the help Keith. 

Michel Levieux

unread,
Dec 31, 2019, 5:53:26 AM12/31/19
to John, golang-nuts
Hi John,

I'm not sure what I'm about to say (i can't test anything right now), but in your last example, wouldn't it be that the finalizer is never called because the function you give it is a closure that holds a reference of b.Payload itself? Thus the GC would consider b.Payload never unreachable and never call its finalizer? Have you tried doing the same thing (print the finalized object) using the function parameter o, rather than an object of the surrounding scope?

Hope this helps

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/fb37ba35-9104-4278-96f3-92045a4ddb45%40googlegroups.com.

John

unread,
Dec 31, 2019, 11:09:25 AM12/31/19
to golang-nuts
Hey Michel,

In that example, it is indeed the reference to the Payload that causes it not to go out of scope.  But you can't print it with the function parameter o, because that is not the slice itself, but the pointer to the first byte of the slice.
I would either need a runtime call that removed the local reference, the oppositoe of KeepAlive() or there might be some way of using Unsafe on this to walk the array C style, but that just seems like a bad idea.
To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages