Будет ли Go GC пытаться освободить «внешнюю кучу» от unsafe.Pointer в отражающей структуре .SliceHeader? - PullRequest
Новая
       15

Будет ли Go GC пытаться освободить «внешнюю кучу» от unsafe.Pointer в отражающей структуре .SliceHeader?

0 голосов
/ 09 сентября 2018

Итак, я узнал, как создать фрагмент из небезопасного указателя в Go: 

func cArray2ByteSlice(array unsafe.Pointer, len int) (list []byte) {
    sliceHeader := (*reflect.SliceHeader)((unsafe.Pointer(&list)))
    sliceHeader.Cap = len
    sliceHeader.Len = len
    sliceHeader.Data = uintptr(array)
    return list
}

У меня есть окно возможности доступа к памяти кучи на array unsafe.Pointer между вызовами внешнего C API lock и unlock.

GC в конечном итоге попытается собрать ломтик list []byte. Дело в том, что заголовок слайса находится в выделенной куче Голанга, а sliceHeader.Data - нет.

Достаточно ли умён GC, чтобы игнорировать распределение кучи без golang в этой ситуации, как в большинстве других?

После вызова unlock я хочу быть уверенным, что Go GC не пытается выпустить память кучи в sliceHeader.Data.

Также, если я хочу скопировать данные для использования вне периода lock / unlock, я предполагаю, что мог бы вместо этого вернуть эту переменную: 

 var safeList []byte = list[:]
...